From turners@ieca.com Tue Oct 2 06:09:37 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4964C21F86EB for ; Tue, 2 Oct 2012 06:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.804 X-Spam-Level: X-Spam-Status: No, score=-100.804 tagged_above=-999 required=5 tests=[AWL=-1.139, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9csJsFQV9hi for ; Tue, 2 Oct 2012 06:09:36 -0700 (PDT) Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [69.93.37.21]) by ietfa.amsl.com (Postfix) with ESMTP id DDBEC21F86EA for ; Tue, 2 Oct 2012 06:09:36 -0700 (PDT) Received: by gateway03.websitewelcome.com (Postfix, from userid 5007) id C8B3E2F832DB6; Tue, 2 Oct 2012 08:09:37 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway03.websitewelcome.com (Postfix) with ESMTP id B0DE02F832D20 for ; Tue, 2 Oct 2012 08:09:37 -0500 (CDT) Received: from [108.18.174.220] (port=59156 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TJ2EC-0004uE-2E for saag@ietf.org; Tue, 02 Oct 2012 08:09:36 -0500 Message-ID: <506AE78F.3050607@ieca.com> Date: Tue, 02 Oct 2012 09:09:35 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.18.174.220]:59156 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [saag] Call for SAAG presentation topics X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 13:09:37 -0000 Folks, Stephen and I are putting together the SAAG agendas for Atlanta. The agenda traditionally includes one or two invited presentations after the working group reports. We would appreciate submission of presentation topics that you believe would be of interest to the community. If you can identify an appropriate presenter (not necessarily yourself) that would be helpful. Thanks, spt [1] Thanks for your suggestion Paul. From rafiee@hpi.uni-potsdam.de Sun Oct 7 02:22:05 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3C321F8484 for ; Sun, 7 Oct 2012 02:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcy4eESg0RBd for ; Sun, 7 Oct 2012 02:22:04 -0700 (PDT) Received: from mail3.hpi.uni-potsdam.de (mail3.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17b]) by ietfa.amsl.com (Postfix) with ESMTP id 780BD21F847A for ; Sun, 7 Oct 2012 02:22:04 -0700 (PDT) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail3.hpi.uni-potsdam.de (Postfix) with ESMTP id 94507169E53 for ; Sun, 7 Oct 2012 11:22:03 +0200 (CEST) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Sun, 7 Oct 2012 11:22:03 +0200 From: "Rafiee, Hosnieh" To: "saag@ietf.org" Date: Sun, 7 Oct 2012 11:22:02 +0200 Thread-Topic: request for comments - draft-rafiee-cga-tsig-00 Thread-Index: Ac2kbTV/YQ4hH8EiRGKjN4gcftB0OQ== Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_EA738325B0580041A50A364F5F76B68924CD4EAE768MXMA1Rhpiuni_" MIME-Version: 1.0 Subject: [saag] request for comments - draft-rafiee-cga-tsig-00 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 09:22:05 -0000 --_000_EA738325B0580041A50A364F5F76B68924CD4EAE768MXMA1Rhpiuni_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please take a look at my RFC draft and share your comments with me so that = I might improve it. I would like discuss this draft in IETF meetings in Atl= anta. Thanks, Hosnieh A new version of I-D, draft-rafiee-cga-tsig-00.txt has been successfully su= bmitted by Hosnieh Rafiee and posted to the IETF repository. Filename: draft-rafiee-cga-tsig Revision: 00 Title: Transaction SIGnature (TSIG) using CGA Algorith= m in IPv6 Creation date: 2012-09-30 WG ID: Individual Submission Number of pages: 13 URL: http://www.ietf.org/internet-drafts/draft-rafiee-cga-tsig-= 00.txt Status: http://datatracker.ietf.org/doc/draft-rafiee-cga-tsig Htmlized: http://tools.ietf.org/html/draft-rafiee-cga-tsig-00 Abstract: The first step of Transaction SIGnature (TSIG) (RFC 2845) is to generate a shared secret and exchange it manually between a DNS server and a host. This document, CGA-TSIG, proposes a possible way to automate the now manual process for the authentication of a node with a DNS server during the DNS Update process by using the same parameters as are used in generating a secure address in IPv6 networks, i.e., Cryptographically Generated Addresses (CGA) (RFC 3972). CGA-TSIG facilitates this authentication process and reduces the time needed for DNS Updates. The current signature generation process and verification mechanism in TSIG are thus replaced with CGA. This algorithm is added, as an extension, to TSIG to eliminate the human intervention needed for generation and exchange of keys between a DNS server and a host when SEcure Neighbor Discovery (SEND) (RFC 3971) is used. --_000_EA738325B0580041A50A364F5F76B68924CD4EAE768MXMA1Rhpiuni_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

Plea= se take a look at my RFC draft and share your comments with me so that I mi= ght improve it. I would like discuss this draft in IETF meetings in Atlanta= .

Thanks,

Hosnieh

 

=

 

 <= /o:p>

A new version of I-D, draft-rafiee-cga-tsi= g-00.txt has been successfully submitted by Hosnieh Rafiee and posted to th= e IETF repository.

 <= /p>

Filename:      &nb= sp;     draft-rafiee-cga-tsig

Revision:         = ;     00

Title:&n= bsp;            = ;         Transaction SIGnature (TS= IG) using CGA Algorithm in IPv6

Creat= ion date:   2012-09-30

WG I= D:            &= nbsp;     Individual Submission

Number of pages: 13

U= RL:            = http://www.ietf.org/internet-drafts/draft-rafiee-cga-tsig-00.txt

Status:     &nb= sp;    http://datatracker.ietf.org/doc/draft-rafiee-cga-tsig=

Htmlized:     &n= bsp;  = http://tools.ietf.org/html/draft-rafiee-cga-tsig-00

 

 =

Abstract:

   The first step of Transaction SIGnature (TSIG) (RFC 284= 5) is to

   generate a shar= ed secret and exchange it manually between a DNS

   server and a host. This document, CGA-TSIG, propos= es a possible way

  to auto= mate the now manual process for the authentication of a node

=

   with a DNS server during the DNS Updat= e process by using the same

 &nb= sp; parameters as are used in generating a secure address in IPv6

   networks, i.e., Cryptographically= Generated Addresses (CGA) (RFC

 = ;  3972). CGA-TSIG facilitates this authentication process and reduces=

   the time needed for DNS= Updates. The current signature generation

   process and verification mechanism in TSIG are thus repl= aced with

   CGA. This algo= rithm is added, as an extension, to TSIG to eliminate

   the human intervention needed for generation = and exchange of keys

   bet= ween a DNS server and a host when SEcure Neighbor Discovery (SEND)

   (RFC 3971) is used.

 

= --_000_EA738325B0580041A50A364F5F76B68924CD4EAE768MXMA1Rhpiuni_-- From henry.story@bblfish.net Mon Oct 8 10:01:31 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD4B21F87E5 for ; Mon, 8 Oct 2012 10:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QE9wzV188qHh for ; Mon, 8 Oct 2012 10:01:29 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 60DBB21F84D4 for ; Mon, 8 Oct 2012 10:01:29 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so2586895wgb.13 for ; Mon, 08 Oct 2012 10:01:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:resent-from:date:cc :resent-date:message-id:resent-to:to:x-mailer:x-gm-message-state; bh=qjXhrDLSoqObfO26jEJdi+y0Qm/8i9tFgXHjItfon1o=; b=nKjvogEft/cPIaITD10KjPsQi4jKicXg9BBf3AnMBXx7oN/cLlleR8EiapIlarmLFE 65xG4DRmGsZwDC3BG+mia8SpRxp3QaKK9ljmr5DYiJ9gnmBNRj2QDbUfo1D3mz0QOfn6 4iz9zZAeBar+DjpdJROzgBgfU8m8811E+GABmMm2zul8Z69H6X4ZwnFEkv0h82e/vIpo OKkF2rhAYAOaTk5kqwPn88XGH2Wm11qlS0v2X07IPVkKNzJjj6SG7uyKNJ0XslHFONtA cpT3ZUBOSCe/jKqSUPH9clpNYLwh+Ec9YRuHvkAtLFpOQsImY4xcEb/a4fAwPnDoRa0X rzgA== Received: by 10.180.87.132 with SMTP id ay4mr23331972wib.5.1349715688239; Mon, 08 Oct 2012 10:01:28 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-329-35.w83-114.abo.wanadoo.fr. [83.114.96.35]) by mx.google.com with ESMTPS id w8sm20508745wif.4.2012.10.08.10.01.18 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Oct 2012 10:01:26 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: multipart/signed; boundary="Apple-Mail=_B5CDDCC9-4108-4E92-B8B2-FB428062FB48"; protocol="application/pkcs7-signature"; micalg=sha1 From: Henry Story Resent-From: Henry Story Date: Sat, 6 Oct 2012 15:49:12 +0200 Resent-Date: Mon, 8 Oct 2012 19:01:16 +0200 Message-Id: <88F98DFD-EF7D-4444-A9C2-FB8E15F5DA89@bblfish.net> Resent-To: saag@ietf.org To: "public-webid@w3.org" , "public-identity@w3.org" , public-privacy@w3.org X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQndv38P7Nwmte6dbOQc9rWSjivaeDiqNykr492EJMR6+gGB1MOo7IpihwIRPbqlpO2Qq0aM Resent-Message-Id: <20121008170129.60DBB21F84D4@ietfa.amsl.com> Cc: "public-philoweb@w3.org" Subject: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 17:01:31 -0000 --Apple-Mail=_B5CDDCC9-4108-4E92-B8B2-FB428062FB48 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Notions of unlinkability of identities have recently been deployed=20 in ways that I would like to argue, are often much too simplistic,=20 and in fact harmful to wider issues of privacy on the web. I would like to show this in two stages: 1. That linkability of identity is essential to electronic privacy=20 on the web 2. Show an example of an argument by Harry Halpin relating to=20 linkability, and by pulling it apart show how careful one has=20 to be with taking such arguments at face value Because privacy is the context in which the linkability or non = linkability of identities is important, I would like to start with a simple working=20= definition of what constitutes privacy with the following minimal=20 criterion [0] that I think everyone can agree on: "A communication between two people is private if the only people=20 who are party to the conversation are the two people in question.=20 One can easily generalise to groups: a conversation between groups=20 of people is private (to the group) if the only people who can=20 participate/read the information are members of that group" Note that this does not deal with issues of people who were privy to=20 the conversation later leaking information voluntarily. We cannot=20 technically legislate good behaviour, though we can make it possible=20 for people to express context. [1] 1. On the importance of linkability of identities to privacy=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=3D A. Issues of Centralisation --------------------------- We can put this with the following thought experiment which I put to Ben Laurie recently [0]. First imagine that we all are on one big social network, where=20 all of our home pages are at the same URL. Nobody could link to our profile page in any meaningful way. The bigger the network the more different people that one URL could refer to. People=20 that were part of the network could log in, and once logged in communicate with others in their unlinkable channels.=20 But this would not necessarily give users of the network privacy:=20 simply because the network owner would be party to the conversation=20 between any two people or any group of people. Conversations=20 that do not wish the network owner to be party to the conversation cannot work within that framework.=20 At the level of our planet it is clear that there will always be a=20 huge number of agents that cannot for legal or other reasons allow one=20= global network owner to be party to all their conversations. We are=20 therefore socio-logically forced into the social web. B. Linkability and the Social Web --------------------------------- Secondly imagine that we now all have Freedom Boxes [4], where each of us has full control over the box, its software, and the data on it. (We take this extreme individualistic case to emphasise the contrast, not because we don't acknowledge the importance of many intermediate cases as useful) Now we want to create a=20 distributed social network - the social web - where each of us can=20 publish information and through access control rules limit who can=20 access each resource. We would like to limit access to groups such as: - friends=20 - friends of friends - family - business colleagues - ...=20 Limit access means, that we need to determine when accessing a=20 resource who is accessing it. For this we need a global identifier so that can check with the information available to us, if the=20 referent of that identifier is indeed a member of one of those=20 groups. We can't have a local identifier, for that would require that the person we were dealing with had an account on our private box - which will be extremely unlikely. We therefore need a way=20 to identify - pseudonymously if be - agents in a global space. Take the following example. Imagine you come to the WebID TPAC meeting [6] and I take a picture of everyone present. I would like to first restrict access to the picture to only those members who were present. Clearly if I only used local identifiers, I would have to get each one of you to first create an account on my machine. But=20 how would I then know that the accounts created on the FBox correspond to the people who were at the party? It is much easier if we could create a party members group and publish it like this http://www.w3.org/2005/Incubator/webid/team.n3 Then I could drag and drop this group on the access control panel of my FBox admin console to restrict access to only those members. This shows how through linkability I can restrict access and=20 increase privacy by making it possible to link identities in a = distributed web. It would be quite possible furthermore for the above team.n3 resource to be protected by access control. 2. Example of how Unlinkability can be used to spread FUD=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 So here I would like to show how fears about linkability can then bring intelligent people like Harry Halpin to make some seemingly plausible arguments. Here is an example [2] of Harry arguing against W3C WebID CG's http://webid.info/spec/=20 [[ Please look up "unlinkability" (which is why I kept referencing the=20 aforementioned IETF doc [sic [3] below it is a draft] which I saw=20 referenced earlier but whose main point seemed missed). Then explain=20 how WebID provides unlinkability.=20 Looking at the spec - to me, WebID doesn't as it still requires=20 publishing your public key at a URI and then having the relying party go=20= to your identity provider (i.e. your personal homepage in most cases,=20 i.e. what it is that hosts your key) in order to verify your cert, which=20= must provide that URI in the SAN in the cert. Thus, WebID does not=20 provide unlinkability. There's some waving of hands about guards and=20 access control, but that would not mediate the above point, as the HTTP=20= GET to the URI for the key is enough to provide the "link". In comparison, BrowserID provides better privacy in terms of=20 unlinkability by having the browser in between the identity provider and=20= the relying party, so the relying party doesn't have to ping the=20 identity provider for identity-related transactions. That definitely=20 helps provide unlinkability in terms of the identity provider not=20 needing to knowing every time the user goes to a relying party. ]] If I can rephrase the point seems to be the following: A WebID = verification=20 requires that the site your are authenticating to ( The Relying Party ) = verify your identity by dereferencing ( let me add: anonymously ) your profile=20= page, which might only contain as much as your public key publicly. The = yellow=20 box in the picture here: http://www.w3.org/2005/Incubator/webid/spec/#the-webid-protocol The leakage of information then would not be towards the Relying Party - = the site you are logging into - because that site is the one you just = wilfully=20 sent a proof of your identity to. The leakage of information is (drum = roll)=20 towards your profile page server! That server might discover ( through = IP address=20 sniffing presumably ) which sites you might be visiting.=20 One reasonable answer to this problem would be for the Relying Party to = fetch=20 this information via Tor which would remove the ip address sniffing = problem. But let us develop the picture of who we are loosing (potentially)=20 information to. There are a number of profile server scenarios:=20 A. Profile on My Freedom Box [4] The FreedomBox is a personal machine that I control, running free software that I can inspect. Here the only person who has access to the Freedom Box is me. So if I discover that I logged in somewhere that should come as no surprise to me. I might even be interested in this information as a way of gathering information about where I logged in - and perhaps also if anything had been=20 logging in somewhere AS me. (Sadly it looks like it might be difficult to get much good information there as things stand=20 currently with WebID.) B. Profile on My Company/University Profile Server As a member of a company, I am part of a larger agency, namely the=20 Company or University who is backing my identity as member of that institution. A profile on a University web site can mean a lot more than a profile on some social network, because it is in part backed by that institution. Of course as a member of that institution we are part of a larger agent hood. And so it is not clear that the = institution and me are in that context that different. This is also why it is=20 often legally required that one not use one's company identity for private business. C. A Social Network ( Google+, Facebook, ... ) It is a bit odd that people who are part of these networks, and who are "liking" pretty much everything on the web in a way that is clearly visible and is encouraged by those networks to be visible to the=20 network, would have an issue with those sites knowing-perhaps (if the=20 RP does not use Tor or a proxy) where they are logging into. It is = certainly not the way the OAuth, OpenID or other protocols that are in extremely=20= wide use now have been developed and are used by those sites. If we look then at BrowserId [7] Now Mozilla Persona, the only = difference=20 really with WebID ( apart from it not being decentralised until crypto = in the browser really works ) is that the certificate is updated at short = notice=20 - once a day - and that relying parties verify the signature. Neither of = course can the relying party get much interesting attributes this way, and if = it did then the whole of the unlinkability argument would collapse immediately. 3. Conclusion =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Talking about privacy is like talking about security. It is a breeding = ground=20 for paranoia, which tend to make it difficult to notice important solutions to the problem we actually have. Linkability or unlinkability = as defined in draft-hansen-privacy-terminology-03 [3] come with complicated = definitions, and are I suppose meant to be applied carefully. But the choice of = "unlinkable" as a word tends to help create rhethorical short cuts that are apt to = hide the=20 real problems of privacy. By trying too hard to make things unlinkable = we are moving=20 inevitably towards a centralised world where all data is in big = brother's hands.=20 I want to argue that we should all *Like* Linkability. We should do it aware that we can protect ourselves with access control (and TOR)=20= and realise that we don't need to reveal anything more than anyone knew=20= before hand in our linkable profiles. To create a Social Web we need a Linkable ( and likeable ) social web. We may need other technologies for running Wikileaks type set ups, but the clearly cannot be the basic for an architecture of privacy - even if it is an important element in the political landscape. Henry [0] this is from a discussion with Ben Laurie = http://lists.w3.org/Archives/Public/public-webid/2012Oct/att-0022/privacy-= def-1.pdf [1] Oshani's Usage Restriction paper=20 http://dig.csail.mit.edu/2011/Papers/IEEE-Policy-httpa/paper.pdf [2] = http://lists.w3.org/Archives/Public/public-identity/2012Oct/0036.html [3] https://tools.ietf.org/html/draft-hansen-privacy-terminology-03 [4] http://www.youtube.com/watch?v=3DSzW25QTVWsE [6] http://www.w3.org/2012/10/TPAC/ [7] A Comparison between BrowserId and WebId = http://security.stackexchange.com/questions/5406/what-are-the-main-advanta= ges-and-disadvantages-of-webid-compared-to-browserid Social Web Architect http://bblfish.net/ --Apple-Mail=_B5CDDCC9-4108-4E92-B8B2-FB428062FB48 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPDTCCByMw ggYLoAMCAQICAwTQYzANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEyMDgyOTAxNDU1NloXDTEzMDgzMDA5MjM0MFowZTEZMBcGA1UEDRMQazQ2eDlvOXJDRE5m VzMwYzEgMB4GA1UEAwwXaGVucnkuc3RvcnlAYmJsZmlzaC5uZXQxJjAkBgkqhkiG9w0BCQEWF2hl bnJ5LnN0b3J5QGJibGZpc2gubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArHXp EmiifOSpudkJn1vAnFdZsuaLuYYLbdWL47o1rKD/kg8/RJUmTIM2ara4e/MOxR16mu2fyAca3H1U oIXNNXDbYQDu2PkfLoNSM5JGAoYbfB0nXBK//ZecidVMZ8eExd02/vFzo5vj9kQNaAPSYirid5xe 1cV9Y1RFjlEozuYAUhU8zi3taf22JM45ii2YrCEgVjDdez8yio0QoJeKEEL3JhL4tqpkbfIOHmdi HYx00S6YcCogDfxXc3zOJ3jcIj/F61eXG1qWX/lq9RAyoBjYHLWE2iHQPwdzum03ubcvOTlohqOR +/cVzvx10l6bJ46KitfbydXMh8HoY7QcmwIDAQABo4IDsjCCA64wCQYDVR0TBAIwADALBgNVHQ8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQRbT9qwRblII9x nAN2FlEMUD1LQzAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAiBgNVHREEGzAZgRdo ZW5yeS5zdG9yeUBiYmxmaXNoLm5ldDCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIw ggH/MC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsG AQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEF BQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9u IHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZv ciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5 IG9ibGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBTZWUg c2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5 LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3Js MIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20v c3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29t L2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALj/A19bRLmI7sMf0lVRrdN23NuRC7/UFSLZ DfcxrR1wOtQgAbrFlFLY+Otn6UWYIiWQpv2v5Ploqw9rMam5W8seC3TUt83StohXCmZ0EDmK87If B6kpd7FwJ0RFGCxn22hPU2kuhp2mbjJzCTrd3jWsXw63MXDUzHuucWGX2mY1Ji+zRECh568N7iWA 5jn9kWT+h7o7ywKbHc4qAnksghLYAnTfoCx1IPkT4/8A5hf38imhf9NcNGibrvt/e49sacf6GjRH Ot/lOCrEX2fh2YvTB5sdEKM5tjKCKNpFSqnRCKhsWZ9N9ZP7mRZfCOBjAMsm3CW2ygwlWXc54lgf p1UwggfiMIIFyqADAgECAgENMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQy MTAxNTRaFw0xMjEwMjIyMTAxNTRaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP 6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu 2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyU GHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmt xWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMB AAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUU3Ltkpzg2ssB XHx+ljVO8tS4UYIwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0 YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHmCAQEwCQYDVR0SBAIwADA9BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYB BQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMw JxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmls aXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29t IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRD FkFTdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENl cnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAqprh4FuMzh0b/B3GLDAgoLeTJv3xArbNESi/ Kf/HMM//gf8FzwUUNOCglH6dfYuLQQ/dTtOyMb4JoiL3T7xiVKEAOmQ+t+b/xLOMa0m18zoRqW4k 6Glyoyvc7LMrdpgYk/lEh5nq8tPd9BoNmwiiheXphIVH/QelTgUkNzTC7IVpmYVsKuNOnxE1jJFZ NNfqZZK/5Oto7C6PfOut11KmBQSLZarAz0b/mjghdBsYfHuhdO8vrOvD0g5g7dA4pkOAU2Ed4pSC owBSItyD/5aFwZ75ji6Yq7GCG3BpiyAP9st8h+inc0L+7kmrAMJaLMAmu6GZs5Xgsbzn0wUJvbD9 h5jnnMM9UaZDcxl2uLB04quGUWM6NiKGabbxQc680PYbeQrQu+e6J4uqNAxzoa5RxkBA5a/3qlbg F9uJBekCqJswx5vQ9khJrs8UTMaIFzbEC5VGQziQH3/6KJ4DUP85OJEnCx/quShWA6w318LDnba3 M6a5V+KoNLhsVi/TSxf90UbBqwdRR/cOwuGkNJh16NvvhIqO26osMg64CbZsDVrEDr7uSMV40ieB JTo49Iyt77ECOhz/pyhowa2EUP6aKav+L/wXzAPB3LNqzujGR0K1pbyFWKvyYmdungJtySWUMw+R 5DqpA2bFIOE56pfWPLHZxOL+8+r79PLFX+y2V6ExggNvMIIDawIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRp ZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1l ZGlhdGUgQ2xpZW50IENBAgME0GMwCQYFKw4DAhoFAKCCAa8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMDA4MTcwMTE3WjAjBgkqhkiG9w0BCQQxFgQUBn0OMv6U FU74z5bTEls1epSbTFswgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgME0GMwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0ECAwTQYzANBgkqhkiG9w0BAQEFAASCAQBeJPIQpyC8diqDPa4NKPXNMUYFJKD9/vwx12gT DR1O7miHN1jofE1q7SQLCHt8tIPcvOaGQCtW49XkWQlWeC+JpleFKTp4v7k7JJJuFN8SR4/gGrOG 9N3SPgCHcPio+sDKvvLCObedJC8tpT4IfhZnvykjMKdoQn9of8iSFK9P+sqTK1Ah0oTdgMDFHY+X TPZ0iVpn5GDEYopkmnajswKiFYmphviYrqsE3fovQnnvtAy7Hs/6eG0pBvNQp7EGd4fHuJe/hVDE 3U3baU8mYcf35NFqYMWbUuupt9NXVzed7o2hkhFQtB4ggy6kqSrWxrFLRj7wRpkHCFl8IpNgfbTY AAAAAAAA --Apple-Mail=_B5CDDCC9-4108-4E92-B8B2-FB428062FB48-- From Jeff.Hodges@KingsMountain.com Mon Oct 8 11:37:53 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A599E21F8829 for ; Mon, 8 Oct 2012 11:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.616 X-Spam-Level: X-Spam-Status: No, score=-99.616 tagged_above=-999 required=5 tests=[AWL=-0.610, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUQXzdCaQrpr for ; Mon, 8 Oct 2012 11:37:52 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id C173921F8821 for ; Mon, 8 Oct 2012 11:37:52 -0700 (PDT) Received: (qmail 24752 invoked by uid 0); 8 Oct 2012 18:37:44 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy7.bluehost.com with SMTP; 8 Oct 2012 18:37:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=NDm6RIGFftscPn8/krZuSaGW79SplHRYcmjwJxT5XyI=; b=VyAXBCkyc+AwfWkmVrrtZOCH1TZs/2cja1SaDaVOmacdkMOBNPYkRow6YdJZOOr4rpvtPg1YqoW4aExLJuBgbZ7rVAeK8/IoR4Y0zG/YZc105QsEAFVJqvd0t5gG1kZ6; Received: from [216.113.168.128] (port=43504 helo=[10.244.137.180]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TLID1-0006kM-Mh; Mon, 08 Oct 2012 12:37:43 -0600 Message-ID: <50731D75.9060108@KingsMountain.com> Date: Mon, 08 Oct 2012 11:37:41 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: IETF Security Area Advisory Group , IETF PKIX WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: [saag] fyi: CA/Browser Forum (CABF) Organisational Reform vote results X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 18:37:53 -0000 Greetings again, As I'd pointed out earlier this year [1][2], the CA/Browser Forum (CABF) was entertaining organisational reform proposals. It recently completed its final voting exercise [3] and decided on a governance reform proposal [4]. Also, the CABF has created a publicly readable email distribution list [5]. One overall assessment of the reform voting results is here.. Certificate Authorities asked to step up for Internet security; CABF takes a step back instead. (5-Oct-2012) =JeffH [1] Re: [saag] fyi: CA/Browser Forum Announces Organizational Reform Working Group https://www.ietf.org/mail-archive/web/saag/current/msg03585.html [2] [saag] fyi: CA/Browser Forum (CABF) reform voting (corrected) https://www.ietf.org/mail-archive/web/saag/current/msg04015.html [3] [cabfpub] Tally Results on Ballot 90 https://cabforum.org/pipermail/public/2012-September/000544.html [4] https://www.cabforum.org/governance/Trend_Micro_Governance_Proposal.pdf [5] https://cabforum.org/mailman/listinfo/public Note: only CABF members may post to this list. Others may subscribe and receive list traffic. The archives are publicly readable. From rafiee@hpi.uni-potsdam.de Tue Oct 9 04:13:42 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB1921F84F0; Tue, 9 Oct 2012 04:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNGaPDApEs1w; Tue, 9 Oct 2012 04:13:41 -0700 (PDT) Received: from mail3.hpi.uni-potsdam.de (mail3.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17b]) by ietfa.amsl.com (Postfix) with ESMTP id F349F21F84F1; Tue, 9 Oct 2012 04:13:38 -0700 (PDT) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail3.hpi.uni-potsdam.de (Postfix) with ESMTP id 6B774169E7B; Tue, 9 Oct 2012 13:13:33 +0200 (CEST) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Tue, 9 Oct 2012 13:13:33 +0200 From: "Rafiee, Hosnieh" To: "dnsext@ietf.org" Date: Tue, 9 Oct 2012 13:13:32 +0200 Thread-Topic: [dnsext] draft-rafiee-cga-tsig-00 - call for more comments Thread-Index: Ac2lkN6YCNqEW9kdTEm8XD7GV2kI9AAfe1VA Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "DNSOP@ietf.org" , "Int-area@ietf.org" , "v6ops@ietf.org" , "ipv6@ietf.org" , "saag@ietf.org" Subject: Re: [saag] [dnsext] draft-rafiee-cga-tsig-00 - call for more comments X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 11:13:42 -0000 More ideas and comments would be greatly apprecitated as I want to upload a= new version of my draft RFC in which I will incorporate applicable comment= s. -----Original Message----- From: Rafiee, Hosnieh=20 Sent: Thursday, October 04, 2012 9:28 AM To: 'Mark Andrews' Cc: dnsext@ietf.org Subject: RE: [dnsext] draft-rafiee-cga-tsig-00 - request for comments Thank you, I will change it and move the whole CGA-TSIG DATA inside the Other DATA. -----Original Message----- From: Mark Andrews [mailto:marka@isc.org]=20 Sent: Thursday, October 04, 2012 9:15 AM To: Rafiee, Hosnieh Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-rafiee-cga-tsig-00 - request for comments In message , "Rafiee, Hosnieh" writes: > Hello Mark, > Thank you for your comment. Yes can be,=3D20 But the reason is the TSIG= =20 > parsers need to be adapted with this new algori=3D thm and it is not=20 > different whether to put it in Other DATA or after Other =3D DATA field.= =20 > Because Other Data has variable length too like the CGA-TSIG DA=3D TA. > If I missed something please advise. It is different. Examine the behaviour of CGA-TSIG client talking to a non= CGA-TSIG aware server. The response to using a unknown algorithm should b= e BADKEY not FORMERR because the server couldn't parse the TSIG record. Mark > Thank you. > Hosnieh > -----Original Message----- > From: Mark Andrews [mailto:marka@isc.org]=3D20 > Sent: Thursday, October 04, 2012 8:45 AM > To: Rafiee, Hosnieh > Cc: dnsext@ietf.org > Subject: Re: [dnsext] draft-rafiee-cga-tsig-00 - request for comments >=20 >=20 > Why are the CGA parameters not part of other data? That field was=20 > added to=3D TSIG to hold stuff similar to CGA parameters. By making it= =20 > a seperate fie=3D ld you break all existing TSIG parsers. The CGA=20 > parameters could just be d=3D efined to be the initial part of other data= . >=20 > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From henry.story@bblfish.net Tue Oct 9 06:19:31 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B1021F88A4 for ; Tue, 9 Oct 2012 06:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.445 X-Spam-Level: X-Spam-Status: No, score=-3.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YBw+GqYEPv4 for ; Tue, 9 Oct 2012 06:19:29 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 387A121F8714 for ; Tue, 9 Oct 2012 06:19:29 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so4006329wib.13 for ; Tue, 09 Oct 2012 06:19:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=nOjk4b262dcMe3rQSsKozF/6IDKiCQkWkbiXpEhDh60=; b=cuj22VWMrYJYRy8GCjoXw7bnnMLo5vRsF86KYiWumqrvWR5ZIrGwfMD5MbR7Cyl5pD FB1TJz/kK+3ILOVcM888qkOWfI8S+x9Kqh7cK6szEGrWfCH2FPKLYe2vVJP3yPd+xc6e mhLQSsmywaMe0+c9Tn1Dw7o5dwmgWb5jvr0J8SA2xbptcGxkfT/BCqDvIYIFERNzLqon vuvNFtMNr6bgx+5R3f7AFWtE198tVXrooomyceYUU0RWS3KsG/Kuvf8npaMNNQZGlex3 iel7RMKxZXbXTCjS0aJ2hByk8K/xsCJLKOzXZ/ST1tXeCYrE4G7I2lrCCOuF6Fwelb62 QCWA== Received: by 10.180.85.99 with SMTP id g3mr4737429wiz.5.1349788767765; Tue, 09 Oct 2012 06:19:27 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-329-35.w83-114.abo.wanadoo.fr. [83.114.96.35]) by mx.google.com with ESMTPS id q7sm28179258wiy.11.2012.10.09.06.19.23 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Oct 2012 06:19:25 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_375F559F-541E-4354-B110-860323605FB0"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Henry Story In-Reply-To: <7E1636E02F313F4BA69A428B314B77C708217189@xmb-aln-x12.cisco.com> Date: Tue, 9 Oct 2012 15:19:21 +0200 Message-Id: <7ABCD095-4B09-40DD-A084-1BBE761CA72F@bblfish.net> References: <88F98DFD-EF7D-4444-A9C2-FB8E15F5DA89@bblfish.net> <3757D928-C3AE-4630-98E7-E30B5CC604B0@cisco.com> <7E1636E02F313F4BA69A428B314B77C708217189@xmb-aln-x12.cisco.com> To: "Klaas Wierenga (kwiereng)" X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQk9i3q3P1pB7+OCWPQ2RkKVq2/EEWXgKWNxzEYpVBI26B8t01BCdGHAc+Lfh05RPtAubp2L Cc: "public-identity@w3.org" , "public-philoweb@w3.org" , "saag@ietf.org" , "public-webid@w3.org" , "public-privacy@w3.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 13:19:32 -0000 --Apple-Mail=_375F559F-541E-4354-B110-860323605FB0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 9 Oct 2012, at 14:29, "Klaas Wierenga (kwiereng)" = wrote: > Hi Henry, >=20 > (adding saag, had not realised that it was a resend) >=20 > On Oct 9, 2012, at 12:05 AM, Henry Story = wrote: >=20 >>=20 >> On 8 Oct 2012, at 20:27, "Klaas Wierenga (kwiereng)" = wrote: >>=20 >>> Hi Henry, >>>=20 >>> I think your definition of what constitutes a private conversation = is a bit limited, especially in an electronic day and age. I consider = the simple fact that we are having a conversation, without knowing what = we talk about, a privacy sensitive thing. Do you want your wife to know = that you are talking to your mistress, or your employer that you have a = job interview? >>> And do you believe that the location where you are does not = constitute a privacy sensitive attribute? >>=20 >> Ok I think my definition still works: If someone knows that you are = communicating with someone then they know something about the = conversation. In my definition that does constitute a privacy violation = at least for that bit of information. >=20 > ehm, I think that you need quite a bit of fantasy to read that in your = definition ;-) So if you mean also "or are aware of the communication" = you should perhaps include that, but, as you point out below, that does = complicate things big time. It was meant to be a working definition.=20 For a much more detailed work on Privacy of course you would go to read "Privacy in Context: Technology, Policy, and the Integrity of Social = Life" by=20 Helen Nissenbaum=20 http://www.sup.org/book.cgi?id=3D8862 The philoweb and the public-privacy groups should ( perhaps with saag ) = work=20 on building up a reading list of philosophical, technical and legal = books=20 on the subject, with perhaps short summaries that we technicians can = read - a great exit route also for those technicians who get bored with coding = - it=20 can happen to the best! Helen brings in the notion of context as a very important element in the=20= understanding of what privacy is. Privacy there does not mean secrecy, = it=20 means a lot more something akin to respecting the context in which = information=20 was given initially - eg banking details such as someone's home should = not be=20 divulged because the same information can be gotten from other sources, = but=20 should remain protected because they were given as part of a context. = (This=20 was a supreme court ruling according to Nissenbaum.) So I think my working definition is good enough and should easily be=20 extendable to be able to cover other cases like the one you mention. It = does not cover context for example but work by Oshani on usage restriction = shows one way one can go: http://dig.csail.mit.edu/2011/Papers/IEEE-Policy-httpa/paper.pdf also remember I explained it as a minimal criteria we could agree on for=20= privacy, not a full definition. >=20 >> Though I think you exaggerate what they know. Your wife won't know = that you are talking to your mistress, just that you are talking to = another server (If it is a freedom box, they could narrow it down to an = individual). Information about it being a mistress cannot be found just = by seeing information move over the wire. Neither does an employer know = you have a job interview just because you are communicating with some = server x from a different company. But he could be worried. >=20 > I think you are now digressing from the general case, whilst your = definition was meant to be very generic (I believe?). I am not talking = about implementations, but about the general principle. The fact that = there is an xmpp session between klaas@cisco.com and = compensation@apple.com may indicate to my manager that I am looking for = another job. yes, though if the session were peer to peer, and you were communicating = in a way that only the connection from one server to another could be = deduced, then=20 the information about the precise address would be hidden. I am not sure = about xmpp in this respect. But with WebID once the TLS connection is made the = HTTP=20 layer is encrypted, and so it should be impossible to see if you are = doing a GET,=20 PUT, POST or DELETE and even on which resource you were acting. Still other things are visible...=20 > My manager might also be worried if he sees me entering the Google = premises, but that is much less likely (even though I have helped = applicants get out of the building through the emergency exit because a = colleague had arrived in the reception area in the past ;-) The reason I = brought these examples up is that I believe something has changed with = the ubiquity of online databases and online communication. When I didn't = want to be overheard in the past I would go for a walk with someone and = we could talk with reasonable assurance. Now I have to trust that say = Skype is not listening in to my conversation and that Twitter will not = hand my tweets to DHS. So the simple fact that I use an encrypted = channel is not sufficient. Of course. The important thing is that those not part of the = conversation=20 not be able to gather information about the conversation. One can be = more=20 or less strict on the limits here - in some cases it will matter that = even=20 knowing who is communicating with whom be hidden, in other cases it may = not=20 be that important. >=20 >>=20 >> So if I apply this to WebID ( http://webid.info/ ) - which is I think = why you bring it up - WebID is currently based on TLS, which does make = it possible to track connections between servers. But remember that the = perfect is the enemy of the good. How come? Well, put things in context: = by failing to create simple distributed systems which protect privacy of = content pretty well, that works with current deployed technologies (e.g. = browsers, and servers), we have allowed large social networks to grow to = sizes unimaginable in any previous surveillance society. So even a non = optimal system like TLS can still bring huge benefits over the current = status quo. If only in educating people in how to build such reasonably = safe distributed systems. >=20 > I was not referring to WebID in particular. I applaud your effort, and = do realise that perfect will not happen. However I think that your = definition of privacy should either be scoped tightly to particular use = cases or is too broad a brush. I tend to think that one single = definition of privacy is not very useful, and rather like to think about = different forms of privacy, location privacy, encrypted channels, = plausible deniability etc. yes. there are a lot of subcases. The point I was trying to make if we = can get=20 back to the "Liking Linkability" argument of the thread (and not get = lost=20 in counting the number of angels on a privacy pin head) is that in order = to=20 create systems where you can be as flexible as possible with whome you = want to share your resources with -ie. without placing yourself in a = situation where someone else is listening in - you need to allow for linkability of = identity, and resources as that is the only way to create a distributed social = web. As such worries about people being able to see that I am communicating = with someone in another company are laudable, but if put in perspective with the = really big issues of loss of privacy, is completely irrelevant for most use cases. But as I say, those uses cases can be addressed with technologies such = as Tor... >=20 >>=20 >> But having put that in context, the issue of tracking what servers = are communicating remains. There are technologies designed to make that = opaque, such as Tor. I still need to prove that one can have .onion = WebIDs, and that one can also connect with browsers using TLS behind Tor = - but it should not be difficult to do. Once one can show this then it = should be possible to develop protocols that make this a lot more = efficient. Would that convince you? >=20 > Ehm, what actually concerns me more is not the fact that *it is = possible* to design > proper protocols as much as that I would like to provide guidance to = protocol developers > to *prevent improper protocols*. Does that make sense? yes, but don't make linkability an a priori bad thing, since it is the = most important=20 building block for creating distributed co-operative structures, and so = to privacy. That is the point of this thread.=20 You may not be doing that btw, but if you look at Harry Halpin's = arguments you'll see a good example of how terminology of unlinkability as proposed in=20 http://tools.ietf.org/html/draft-iab-privacy-terminology-01 can be misused. But to be fair it does say at the end of the document [[ Achieving anonymity, unlinkability, and undetectability may enable extreme data minimization. Unfortunately, this would also prevent a certain class of useful two-way communication scenarios. Therefore, for many applications, a certain amount of linkability and detectability is usually accepted while attempting to retain unlinkability between the data subject and his or her transactions. This is achieved through the use of appropriate kinds of pseudonymous identifiers. These identifiers are then often used to refer to established state or are used for access control purposes ]] Still in my conversations I have found that many people in security = spaces=20 just don't seem to be able to put the issues in context, and can get = sidetracked=20 into not wanting any linkability at all. Not sure how to fix that. >=20 > Klaas >=20 >>=20 >>>=20 >>> Klaas >>>=20 >>> Sent from my iPad >>>=20 >>> On 8 okt. 2012, at 19:01, "Henry Story" = wrote: >>>=20 >>>>=20 >>>> Notions of unlinkability of identities have recently been deployed=20= >>>> in ways that I would like to argue, are often much too simplistic,=20= >>>> and in fact harmful to wider issues of privacy on the web. >>>>=20 >>>> I would like to show this in two stages: >>>> 1. That linkability of identity is essential to electronic privacy=20= >>>> on the web >>>> 2. Show an example of an argument by Harry Halpin relating to=20 >>>> linkability, and by pulling it apart show how careful one has=20 >>>> to be with taking such arguments at face value >>>>=20 >>>> Because privacy is the context in which the linkability or non = linkability >>>> of identities is important, I would like to start with a simple = working=20 >>>> definition of what constitutes privacy with the following minimal=20= >>>> criterion [0] that I think everyone can agree on: >>>>=20 >>>> "A communication between two people is private if the only people=20= >>>> who are party to the conversation are the two people in question.=20= >>>> One can easily generalise to groups: a conversation between groups=20= >>>> of people is private (to the group) if the only people who can=20 >>>> participate/read the information are members of that group" >>>>=20 >>>> Note that this does not deal with issues of people who were privy = to=20 >>>> the conversation later leaking information voluntarily. We cannot=20= >>>> technically legislate good behaviour, though we can make it = possible=20 >>>> for people to express context. [1] >>>>=20 >>>>=20 >>>> 1. On the importance of linkability of identities to privacy=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=3D >>>>=20 >>>> A. Issues of Centralisation >>>> --------------------------- >>>>=20 >>>> We can put this with the following thought experiment which I put >>>> to Ben Laurie recently [0]. >>>>=20 >>>> First imagine that we all are on one big social network, where=20 >>>> all of our home pages are at the same URL. Nobody could link >>>> to our profile page in any meaningful way. The bigger the network >>>> the more different people that one URL could refer to. People=20 >>>> that were part of the network could log in, and once logged in >>>> communicate with others in their unlinkable channels.=20 >>>>=20 >>>> But this would not necessarily give users of the network privacy:=20= >>>> simply because the network owner would be party to the conversation=20= >>>> between any two people or any group of people. Conversations=20 >>>> that do not wish the network owner to be party to the conversation >>>> cannot work within that framework.=20 >>>>=20 >>>> At the level of our planet it is clear that there will always be a=20= >>>> huge number of agents that cannot for legal or other reasons allow = one=20 >>>> global network owner to be party to all their conversations. We are=20= >>>> therefore socio-logically forced into the social web. >>>>=20 >>>> B. Linkability and the Social Web >>>> --------------------------------- >>>>=20 >>>> Secondly imagine that we now all have Freedom Boxes [4], where >>>> each of us has full control over the box, its software, and the >>>> data on it. (We take this extreme individualistic case to emphasise >>>> the contrast, not because we don't acknowledge the importance of >>>> many intermediate cases as useful) Now we want to create a=20 >>>> distributed social network - the social web - where each of us can=20= >>>> publish information and through access control rules limit who can=20= >>>> access each resource. We would like to limit access to groups such >>>> as: >>>>=20 >>>> - friends=20 >>>> - friends of friends >>>> - family >>>> - business colleagues >>>> - ...=20 >>>>=20 >>>> Limit access means, that we need to determine when accessing a=20 >>>> resource who is accessing it. For this we need a global identifier >>>> so that can check with the information available to us, if the=20 >>>> referent of that identifier is indeed a member of one of those=20 >>>> groups. We can't have a local identifier, for that would require >>>> that the person we were dealing with had an account on our private >>>> box - which will be extremely unlikely. We therefore need a way=20 >>>> to identify - pseudonymously if be - agents in a global space. >>>>=20 >>>> Take the following example. Imagine you come to the WebID TPAC >>>> meeting [6] and I take a picture of everyone present. I would like >>>> to first restrict access to the picture to only those members who >>>> were present. Clearly if I only used local identifiers, I would = have >>>> to get each one of you to first create an account on my machine. = But=20 >>>> how would I then know that the accounts created on the FBox = correspond >>>> to the people who were at the party? It is much easier if we could >>>> create a party members group and publish it like this >>>>=20 >>>> http://www.w3.org/2005/Incubator/webid/team.n3 >>>>=20 >>>> Then I could drag and drop this group on the access control panel >>>> of my FBox admin console to restrict access to only those members. >>>> This shows how through linkability I can restrict access and=20 >>>> increase privacy by making it possible to link identities in a = distributed >>>> web. It would be quite possible furthermore for the above team.n3 >>>> resource to be protected by access control. >>>>=20 >>>>=20 >>>> 2. Example of how Unlinkability can be used to spread FUD=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 >>>>=20 >>>>=20 >>>> So here I would like to show how fears about linkability can >>>> then bring intelligent people like Harry Halpin to make some = seemingly >>>> plausible arguments. Here is an example [2] of Harry arguing = against >>>> W3C WebID CG's http://webid.info/spec/=20 >>>>=20 >>>> [[ >>>> Please look up "unlinkability" (which is why I kept referencing the=20= >>>> aforementioned IETF doc [sic [3] below it is a draft] which I saw=20= >>>> referenced earlier but whose main point seemed missed). Then = explain=20 >>>> how WebID provides unlinkability.=20 >>>>=20 >>>> Looking at the spec - to me, WebID doesn't as it still requires=20 >>>> publishing your public key at a URI and then having the relying = party go=20 >>>> to your identity provider (i.e. your personal homepage in most = cases,=20 >>>> i.e. what it is that hosts your key) in order to verify your cert, = which=20 >>>> must provide that URI in the SAN in the cert. Thus, WebID does not=20= >>>> provide unlinkability. There's some waving of hands about guards = and=20 >>>> access control, but that would not mediate the above point, as the = HTTP=20 >>>> GET to the URI for the key is enough to provide the "link". >>>>=20 >>>> In comparison, BrowserID provides better privacy in terms of=20 >>>> unlinkability by having the browser in between the identity = provider and=20 >>>> the relying party, so the relying party doesn't have to ping the=20 >>>> identity provider for identity-related transactions. That = definitely=20 >>>> helps provide unlinkability in terms of the identity provider not=20= >>>> needing to knowing every time the user goes to a relying party. >>>> ]] >>>>=20 >>>> If I can rephrase the point seems to be the following: A WebID = verification=20 >>>> requires that the site your are authenticating to ( The Relying = Party ) verify >>>> your identity by dereferencing ( let me add: anonymously ) your = profile=20 >>>> page, which might only contain as much as your public key publicly. = The yellow=20 >>>> box in the picture here: >>>>=20 >>>> http://www.w3.org/2005/Incubator/webid/spec/#the-webid-protocol >>>>=20 >>>> The leakage of information then would not be towards the Relying = Party - the >>>> site you are logging into - because that site is the one you just = wilfully=20 >>>> sent a proof of your identity to. The leakage of information is = (drum roll)=20 >>>> towards your profile page server! That server might discover ( = through IP address=20 >>>> sniffing presumably ) which sites you might be visiting.=20 >>>>=20 >>>> One reasonable answer to this problem would be for the Relying = Party to fetch=20 >>>> this information via Tor which would remove the ip address sniffing = problem. >>>>=20 >>>> But let us develop the picture of who we are loosing (potentially)=20= >>>> information to. There are a number of profile server scenarios:=20 >>>>=20 >>>> A. Profile on My Freedom Box [4] >>>>=20 >>>> The FreedomBox is a personal machine that I control, running >>>> free software that I can inspect. Here the only person who has >>>> access to the Freedom Box is me. So if I discover that I logged >>>> in somewhere that should come as no surprise to me. I might even >>>> be interested in this information as a way of gathering information >>>> about where I logged in - and perhaps also if anything had been=20 >>>> logging in somewhere AS me. (Sadly it looks like it might be >>>> difficult to get much good information there as things stand=20 >>>> currently with WebID.) >>>>=20 >>>> B. Profile on My Company/University Profile Server >>>>=20 >>>> As a member of a company, I am part of a larger agency, namely the=20= >>>> Company or University who is backing my identity as member of that >>>> institution. A profile on a University web site can mean a lot more >>>> than a profile on some social network, because it is in part backed >>>> by that institution. Of course as a member of that institution we >>>> are part of a larger agent hood. And so it is not clear that the = institution >>>> and me are in that context that different. This is also why it is=20= >>>> often legally required that one not use one's company identity for >>>> private business. >>>>=20 >>>> C. A Social Network ( Google+, Facebook, ... ) >>>>=20 >>>> It is a bit odd that people who are part of these networks, and who >>>> are "liking" pretty much everything on the web in a way that is = clearly >>>> visible and is encouraged by those networks to be visible to the=20 >>>> network, would have an issue with those sites knowing-perhaps (if = the=20 >>>> RP does not use Tor or a proxy) where they are logging into. It is = certainly >>>> not the way the OAuth, OpenID or other protocols that are in = extremely=20 >>>> wide use now have been developed and are used by those sites. >>>>=20 >>>> If we look then at BrowserId [7] Now Mozilla Persona, the only = difference=20 >>>> really with WebID ( apart from it not being decentralised until = crypto in the >>>> browser really works ) is that the certificate is updated at short = notice=20 >>>> - once a day - and that relying parties verify the signature. = Neither of course >>>> can the relying party get much interesting attributes this way, and = if it did >>>> then the whole of the unlinkability argument would collapse = immediately. >>>>=20 >>>>=20 >>>> 3. Conclusion >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>=20 >>>> Talking about privacy is like talking about security. It is a = breeding ground=20 >>>> for paranoia, which tend to make it difficult to notice important >>>> solutions to the problem we actually have. Linkability or = unlinkability as defined in >>>> draft-hansen-privacy-terminology-03 [3] come with complicated = definitions, >>>> and are I suppose meant to be applied carefully. But the choice of = "unlinkable" >>>> as a word tends to help create rhethorical short cuts that are apt = to hide the=20 >>>> real problems of privacy. By trying too hard to make things = unlinkable we are moving=20 >>>> inevitably towards a centralised world where all data is in big = brother's hands.=20 >>>>=20 >>>> I want to argue that we should all *Like* Linkability. We should >>>> do it aware that we can protect ourselves with access control (and = TOR)=20 >>>> and realise that we don't need to reveal anything more than anyone = knew=20 >>>> before hand in our linkable profiles. >>>>=20 >>>> To create a Social Web we need a Linkable ( and likeable ) social = web. >>>> We may need other technologies for running Wikileaks type set ups, = but >>>> the clearly cannot be the basic for an architecture of privacy - = even >>>> if it is an important element in the political landscape. >>>>=20 >>>> Henry >>>>=20 >>>> [0] this is from a discussion with Ben Laurie >>>> = http://lists.w3.org/Archives/Public/public-webid/2012Oct/att-0022/privacy-= def-1.pdf >>>> [1] Oshani's Usage Restriction paper=20 >>>> http://dig.csail.mit.edu/2011/Papers/IEEE-Policy-httpa/paper.pdf >>>> [2] = http://lists.w3.org/Archives/Public/public-identity/2012Oct/0036.html >>>> [3] https://tools.ietf.org/html/draft-hansen-privacy-terminology-03 >>>> [4] http://www.youtube.com/watch?v=3DSzW25QTVWsE >>>> [6] http://www.w3.org/2012/10/TPAC/ >>>> [7] A Comparison between BrowserId and WebId >>>> = http://security.stackexchange.com/questions/5406/what-are-the-main-advanta= ges-and-disadvantages-of-webid-compared-to-browserid >>>>=20 >>>>=20 >>>> Social Web Architect >>>> http://bblfish.net/ >>>>=20 >>>> _______________________________________________ >>>> saag mailing list >>>> saag@ietf.org >>>> https://www.ietf.org/mailman/listinfo/saag >>=20 >> Social Web Architect >> http://bblfish.net/ >>=20 >=20 Social Web Architect http://bblfish.net/ --Apple-Mail=_375F559F-541E-4354-B110-860323605FB0 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPDTCCByMw ggYLoAMCAQICAwTQYzANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEyMDgyOTAxNDU1NloXDTEzMDgzMDA5MjM0MFowZTEZMBcGA1UEDRMQazQ2eDlvOXJDRE5m VzMwYzEgMB4GA1UEAwwXaGVucnkuc3RvcnlAYmJsZmlzaC5uZXQxJjAkBgkqhkiG9w0BCQEWF2hl bnJ5LnN0b3J5QGJibGZpc2gubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArHXp EmiifOSpudkJn1vAnFdZsuaLuYYLbdWL47o1rKD/kg8/RJUmTIM2ara4e/MOxR16mu2fyAca3H1U oIXNNXDbYQDu2PkfLoNSM5JGAoYbfB0nXBK//ZecidVMZ8eExd02/vFzo5vj9kQNaAPSYirid5xe 1cV9Y1RFjlEozuYAUhU8zi3taf22JM45ii2YrCEgVjDdez8yio0QoJeKEEL3JhL4tqpkbfIOHmdi HYx00S6YcCogDfxXc3zOJ3jcIj/F61eXG1qWX/lq9RAyoBjYHLWE2iHQPwdzum03ubcvOTlohqOR +/cVzvx10l6bJ46KitfbydXMh8HoY7QcmwIDAQABo4IDsjCCA64wCQYDVR0TBAIwADALBgNVHQ8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQRbT9qwRblII9x nAN2FlEMUD1LQzAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAiBgNVHREEGzAZgRdo ZW5yeS5zdG9yeUBiYmxmaXNoLm5ldDCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIw ggH/MC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsG AQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEF BQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9u IHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZv ciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5 IG9ibGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBTZWUg c2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5 LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3Js MIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20v c3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29t L2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALj/A19bRLmI7sMf0lVRrdN23NuRC7/UFSLZ DfcxrR1wOtQgAbrFlFLY+Otn6UWYIiWQpv2v5Ploqw9rMam5W8seC3TUt83StohXCmZ0EDmK87If B6kpd7FwJ0RFGCxn22hPU2kuhp2mbjJzCTrd3jWsXw63MXDUzHuucWGX2mY1Ji+zRECh568N7iWA 5jn9kWT+h7o7ywKbHc4qAnksghLYAnTfoCx1IPkT4/8A5hf38imhf9NcNGibrvt/e49sacf6GjRH Ot/lOCrEX2fh2YvTB5sdEKM5tjKCKNpFSqnRCKhsWZ9N9ZP7mRZfCOBjAMsm3CW2ygwlWXc54lgf p1UwggfiMIIFyqADAgECAgENMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQy MTAxNTRaFw0xMjEwMjIyMTAxNTRaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP 6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu 2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyU GHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmt xWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMB AAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUU3Ltkpzg2ssB XHx+ljVO8tS4UYIwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0 YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHmCAQEwCQYDVR0SBAIwADA9BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYB BQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMw JxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmls aXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29t IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRD FkFTdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENl cnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAqprh4FuMzh0b/B3GLDAgoLeTJv3xArbNESi/ Kf/HMM//gf8FzwUUNOCglH6dfYuLQQ/dTtOyMb4JoiL3T7xiVKEAOmQ+t+b/xLOMa0m18zoRqW4k 6Glyoyvc7LMrdpgYk/lEh5nq8tPd9BoNmwiiheXphIVH/QelTgUkNzTC7IVpmYVsKuNOnxE1jJFZ NNfqZZK/5Oto7C6PfOut11KmBQSLZarAz0b/mjghdBsYfHuhdO8vrOvD0g5g7dA4pkOAU2Ed4pSC owBSItyD/5aFwZ75ji6Yq7GCG3BpiyAP9st8h+inc0L+7kmrAMJaLMAmu6GZs5Xgsbzn0wUJvbD9 h5jnnMM9UaZDcxl2uLB04quGUWM6NiKGabbxQc680PYbeQrQu+e6J4uqNAxzoa5RxkBA5a/3qlbg F9uJBekCqJswx5vQ9khJrs8UTMaIFzbEC5VGQziQH3/6KJ4DUP85OJEnCx/quShWA6w318LDnba3 M6a5V+KoNLhsVi/TSxf90UbBqwdRR/cOwuGkNJh16NvvhIqO26osMg64CbZsDVrEDr7uSMV40ieB JTo49Iyt77ECOhz/pyhowa2EUP6aKav+L/wXzAPB3LNqzujGR0K1pbyFWKvyYmdungJtySWUMw+R 5DqpA2bFIOE56pfWPLHZxOL+8+r79PLFX+y2V6ExggNvMIIDawIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRp ZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1l ZGlhdGUgQ2xpZW50IENBAgME0GMwCQYFKw4DAhoFAKCCAa8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMDA5MTMxOTIyWjAjBgkqhkiG9w0BCQQxFgQUho9/Is/1 l4Svmop1vU7TskEnI8MwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgME0GMwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0ECAwTQYzANBgkqhkiG9w0BAQEFAASCAQBCnAFvPNzXlsOyU8z/Q0TKCAVLVue6t4Y0VMiw mqK3hBzwBnuGwC9z/p+gFE+2YjsMfh5Fw6jZ59z2ekPs5ra5xp7CwDudm1JqxcjGnyTpUP9F8Yf3 u+W+jrwbyMnvGdDUkY7kvomfS38YpxLzFHB4hFVP6W3yRQZfwvUDgXR4H9Jk7hcL/MMx4hCMyOVY NZ5X7ktbh2GavvludBNKOyWg51cdJKWVmPSkO9VNVCdZm5QpODltxeSpums28VLmtgjiOyqaTW8u +GSMEXWl3fkHJYaY7fHl6FwCmhLrZ/4aGmIpeZ8fjFhpsE+F08si1pVAWyceAnU1hdRl1RC0072x AAAAAAAA --Apple-Mail=_375F559F-541E-4354-B110-860323605FB0-- From henry.story@bblfish.net Tue Oct 9 06:27:01 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1015D11E810D for ; Tue, 9 Oct 2012 06:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.928 X-Spam-Level: X-Spam-Status: No, score=-2.928 tagged_above=-999 required=5 tests=[AWL=-0.398, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JdmZtb4k+jN for ; Tue, 9 Oct 2012 06:26:59 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 243D611E810A for ; Tue, 9 Oct 2012 06:26:58 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so3574335wey.31 for ; Tue, 09 Oct 2012 06:26:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:resent-from:date :cc:resent-date:message-id:references:resent-to:to:x-mailer :x-gm-message-state; bh=KGbf5blr+QHw6Oj/qHVx6Iw2U8iNJQWV42TkhYPgDD0=; b=KFpae4nT/Y8V9nJzp5YgtvTAYxCZnRE0Kv9fdPkQbzZ0C7r4KSz1CgsGkRFQ3IQupF sXflJxG81oQHMS20/NIfAOFB0H0000VSX3V4TvZF90SJ5MQPh73LT05ZuHmzPn6VAyGy /OYGTxa7mM7DkG8SQpK7vvTzBR2PRWtQwcMR7/jprOcds44wdFdiwKVzpDkCCv97s3OK PSIpaT6LT0serAja3Dtkr62/d03WKko83LhLUt+CGFxs4YmsdnlhSbRvVn55oZ4rKbM1 /inj9AQJx2Gsh6VqKaydjKqhuf32a6OLw6j+fFZA04Kt4FxAR8Mm6TjJJ50n9O+Duxx5 05Xg== Received: by 10.180.91.71 with SMTP id cc7mr4798547wib.2.1349789218058; Tue, 09 Oct 2012 06:26:58 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-329-35.w83-114.abo.wanadoo.fr. [83.114.96.35]) by mx.google.com with ESMTPS id ei1sm27817589wid.7.2012.10.09.06.26.43 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Oct 2012 06:26:55 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: multipart/signed; boundary="Apple-Mail=_9A73EEC4-EA06-4BC3-9AAB-D8149471E756"; protocol="application/pkcs7-signature"; micalg=sha1 From: Henry Story In-Reply-To: <3757D928-C3AE-4630-98E7-E30B5CC604B0@cisco.com> Resent-From: Henry Story Date: Tue, 9 Oct 2012 00:05:18 +0200 Resent-Date: Tue, 9 Oct 2012 09:05:23 +0200 Message-Id: References: <88F98DFD-EF7D-4444-A9C2-FB8E15F5DA89@bblfish.net> <3757D928-C3AE-4630-98E7-E30B5CC604B0@cisco.com> Resent-To: "saag@ietf.org" To: "Klaas Wierenga (kwiereng)" X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnq1DXNyQboZiolShiXBPEPZ6y2SAOzQKLeYjK3SC3tbKCS+VI4FoE7Z3Eze1eJfrTt+HpI Resent-Message-Id: <20121009132659.243D611E810A@ietfa.amsl.com> Cc: "public-identity@w3.org" , "public-philoweb@w3.org" , "public-webid@w3.org" , "public-privacy@w3.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 13:27:01 -0000 --Apple-Mail=_9A73EEC4-EA06-4BC3-9AAB-D8149471E756 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 8 Oct 2012, at 20:27, "Klaas Wierenga (kwiereng)" = wrote: > Hi Henry, >=20 > I think your definition of what constitutes a private conversation is = a bit limited, especially in an electronic day and age. I consider the = simple fact that we are having a conversation, without knowing what we = talk about, a privacy sensitive thing. Do you want your wife to know = that you are talking to your mistress, or your employer that you have a = job interview? > And do you believe that the location where you are does not constitute = a privacy sensitive attribute? Ok I think my definition still works: If someone knows that you are = communicating with someone then they know something about the = conversation. In my definition that does constitute a privacy violation = at least for that bit of information. Though I think you exaggerate what they know. Your wife won't know that = you are talking to your mistress, just that you are talking to another = server (If it is a freedom box, they could narrow it down to an = individual). Information about it being a mistress cannot be found just = by seeing information move over the wire. Neither does an employer know = you have a job interview just because you are communicating with some = server x from a different company. But he could be worried. So if I apply this to WebID ( http://webid.info/ ) - which is I think = why you bring it up - WebID is currently based on TLS, which does make = it possible to track connections between servers. But remember that the = perfect is the enemy of the good. How come? Well, put things in context: = by failing to create simple distributed systems which protect privacy of = content pretty well, that works with current deployed technologies (e.g. = browsers, and servers), we have allowed large social networks to grow to = sizes unimaginable in any previous surveillance society. So even a non = optimal system like TLS can still bring huge benefits over the current = status quo. If only in educating people in how to build such reasonably = safe distributed systems. But having put that in context, the issue of tracking what servers are = communicating remains. There are technologies designed to make that = opaque, such as Tor. I still need to prove that one can have .onion = WebIDs, and that one can also connect with browsers using TLS behind Tor = - but it should not be difficult to do. Once one can show this then it = should be possible to develop protocols that make this a lot more = efficient. Would that convince you? >=20 > Klaas >=20 > Sent from my iPad >=20 > On 8 okt. 2012, at 19:01, "Henry Story" = wrote: >=20 >>=20 >> Notions of unlinkability of identities have recently been deployed=20 >> in ways that I would like to argue, are often much too simplistic,=20 >> and in fact harmful to wider issues of privacy on the web. >>=20 >> I would like to show this in two stages: >> 1. That linkability of identity is essential to electronic privacy=20 >> on the web >> 2. Show an example of an argument by Harry Halpin relating to=20 >> linkability, and by pulling it apart show how careful one has=20 >> to be with taking such arguments at face value >>=20 >> Because privacy is the context in which the linkability or non = linkability >> of identities is important, I would like to start with a simple = working=20 >> definition of what constitutes privacy with the following minimal=20 >> criterion [0] that I think everyone can agree on: >>=20 >> "A communication between two people is private if the only people=20 >> who are party to the conversation are the two people in question.=20 >> One can easily generalise to groups: a conversation between groups=20 >> of people is private (to the group) if the only people who can=20 >> participate/read the information are members of that group" >>=20 >> Note that this does not deal with issues of people who were privy to=20= >> the conversation later leaking information voluntarily. We cannot=20 >> technically legislate good behaviour, though we can make it possible=20= >> for people to express context. [1] >>=20 >>=20 >> 1. On the importance of linkability of identities to privacy=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=3D >>=20 >> A. Issues of Centralisation >> --------------------------- >>=20 >> We can put this with the following thought experiment which I put >> to Ben Laurie recently [0]. >>=20 >> First imagine that we all are on one big social network, where=20 >> all of our home pages are at the same URL. Nobody could link >> to our profile page in any meaningful way. The bigger the network >> the more different people that one URL could refer to. People=20 >> that were part of the network could log in, and once logged in >> communicate with others in their unlinkable channels.=20 >>=20 >> But this would not necessarily give users of the network privacy:=20 >> simply because the network owner would be party to the conversation=20= >> between any two people or any group of people. Conversations=20 >> that do not wish the network owner to be party to the conversation >> cannot work within that framework.=20 >>=20 >> At the level of our planet it is clear that there will always be a=20 >> huge number of agents that cannot for legal or other reasons allow = one=20 >> global network owner to be party to all their conversations. We are=20= >> therefore socio-logically forced into the social web. >>=20 >> B. Linkability and the Social Web >> --------------------------------- >>=20 >> Secondly imagine that we now all have Freedom Boxes [4], where >> each of us has full control over the box, its software, and the >> data on it. (We take this extreme individualistic case to emphasise >> the contrast, not because we don't acknowledge the importance of >> many intermediate cases as useful) Now we want to create a=20 >> distributed social network - the social web - where each of us can=20 >> publish information and through access control rules limit who can=20 >> access each resource. We would like to limit access to groups such >> as: >>=20 >> - friends=20 >> - friends of friends >> - family >> - business colleagues >> - ...=20 >>=20 >> Limit access means, that we need to determine when accessing a=20 >> resource who is accessing it. For this we need a global identifier >> so that can check with the information available to us, if the=20 >> referent of that identifier is indeed a member of one of those=20 >> groups. We can't have a local identifier, for that would require >> that the person we were dealing with had an account on our private >> box - which will be extremely unlikely. We therefore need a way=20 >> to identify - pseudonymously if be - agents in a global space. >>=20 >> Take the following example. Imagine you come to the WebID TPAC >> meeting [6] and I take a picture of everyone present. I would like >> to first restrict access to the picture to only those members who >> were present. Clearly if I only used local identifiers, I would have >> to get each one of you to first create an account on my machine. But=20= >> how would I then know that the accounts created on the FBox = correspond >> to the people who were at the party? It is much easier if we could >> create a party members group and publish it like this >>=20 >> http://www.w3.org/2005/Incubator/webid/team.n3 >>=20 >> Then I could drag and drop this group on the access control panel >> of my FBox admin console to restrict access to only those members. >> This shows how through linkability I can restrict access and=20 >> increase privacy by making it possible to link identities in a = distributed >> web. It would be quite possible furthermore for the above team.n3 >> resource to be protected by access control. >>=20 >>=20 >> 2. Example of how Unlinkability can be used to spread FUD=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 >>=20 >>=20 >> So here I would like to show how fears about linkability can >> then bring intelligent people like Harry Halpin to make some = seemingly >> plausible arguments. Here is an example [2] of Harry arguing against >> W3C WebID CG's http://webid.info/spec/=20 >>=20 >> [[ >> Please look up "unlinkability" (which is why I kept referencing the=20= >> aforementioned IETF doc [sic [3] below it is a draft] which I saw=20 >> referenced earlier but whose main point seemed missed). Then explain=20= >> how WebID provides unlinkability.=20 >>=20 >> Looking at the spec - to me, WebID doesn't as it still requires=20 >> publishing your public key at a URI and then having the relying party = go=20 >> to your identity provider (i.e. your personal homepage in most cases,=20= >> i.e. what it is that hosts your key) in order to verify your cert, = which=20 >> must provide that URI in the SAN in the cert. Thus, WebID does not=20= >> provide unlinkability. There's some waving of hands about guards and=20= >> access control, but that would not mediate the above point, as the = HTTP=20 >> GET to the URI for the key is enough to provide the "link". >>=20 >> In comparison, BrowserID provides better privacy in terms of=20 >> unlinkability by having the browser in between the identity provider = and=20 >> the relying party, so the relying party doesn't have to ping the=20 >> identity provider for identity-related transactions. That definitely=20= >> helps provide unlinkability in terms of the identity provider not=20 >> needing to knowing every time the user goes to a relying party. >> ]] >>=20 >> If I can rephrase the point seems to be the following: A WebID = verification=20 >> requires that the site your are authenticating to ( The Relying Party = ) verify >> your identity by dereferencing ( let me add: anonymously ) your = profile=20 >> page, which might only contain as much as your public key publicly. = The yellow=20 >> box in the picture here: >>=20 >> http://www.w3.org/2005/Incubator/webid/spec/#the-webid-protocol >>=20 >> The leakage of information then would not be towards the Relying = Party - the >> site you are logging into - because that site is the one you just = wilfully=20 >> sent a proof of your identity to. The leakage of information is (drum = roll)=20 >> towards your profile page server! That server might discover ( = through IP address=20 >> sniffing presumably ) which sites you might be visiting.=20 >>=20 >> One reasonable answer to this problem would be for the Relying Party = to fetch=20 >> this information via Tor which would remove the ip address sniffing = problem. >>=20 >> But let us develop the picture of who we are loosing (potentially)=20 >> information to. There are a number of profile server scenarios:=20 >>=20 >> A. Profile on My Freedom Box [4] >>=20 >> The FreedomBox is a personal machine that I control, running >> free software that I can inspect. Here the only person who has >> access to the Freedom Box is me. So if I discover that I logged >> in somewhere that should come as no surprise to me. I might even >> be interested in this information as a way of gathering information >> about where I logged in - and perhaps also if anything had been=20 >> logging in somewhere AS me. (Sadly it looks like it might be >> difficult to get much good information there as things stand=20 >> currently with WebID.) >>=20 >> B. Profile on My Company/University Profile Server >>=20 >> As a member of a company, I am part of a larger agency, namely the=20 >> Company or University who is backing my identity as member of that >> institution. A profile on a University web site can mean a lot more >> than a profile on some social network, because it is in part backed >> by that institution. Of course as a member of that institution we >> are part of a larger agent hood. And so it is not clear that the = institution >> and me are in that context that different. This is also why it is=20 >> often legally required that one not use one's company identity for >> private business. >>=20 >> C. A Social Network ( Google+, Facebook, ... ) >>=20 >> It is a bit odd that people who are part of these networks, and who >> are "liking" pretty much everything on the web in a way that is = clearly >> visible and is encouraged by those networks to be visible to the=20 >> network, would have an issue with those sites knowing-perhaps (if the=20= >> RP does not use Tor or a proxy) where they are logging into. It is = certainly >> not the way the OAuth, OpenID or other protocols that are in = extremely=20 >> wide use now have been developed and are used by those sites. >>=20 >> If we look then at BrowserId [7] Now Mozilla Persona, the only = difference=20 >> really with WebID ( apart from it not being decentralised until = crypto in the >> browser really works ) is that the certificate is updated at short = notice=20 >> - once a day - and that relying parties verify the signature. Neither = of course >> can the relying party get much interesting attributes this way, and = if it did >> then the whole of the unlinkability argument would collapse = immediately. >>=20 >>=20 >> 3. Conclusion >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Talking about privacy is like talking about security. It is a = breeding ground=20 >> for paranoia, which tend to make it difficult to notice important >> solutions to the problem we actually have. Linkability or = unlinkability as defined in >> draft-hansen-privacy-terminology-03 [3] come with complicated = definitions, >> and are I suppose meant to be applied carefully. But the choice of = "unlinkable" >> as a word tends to help create rhethorical short cuts that are apt to = hide the=20 >> real problems of privacy. By trying too hard to make things = unlinkable we are moving=20 >> inevitably towards a centralised world where all data is in big = brother's hands.=20 >>=20 >> I want to argue that we should all *Like* Linkability. We should >> do it aware that we can protect ourselves with access control (and = TOR)=20 >> and realise that we don't need to reveal anything more than anyone = knew=20 >> before hand in our linkable profiles. >>=20 >> To create a Social Web we need a Linkable ( and likeable ) social = web. >> We may need other technologies for running Wikileaks type set ups, = but >> the clearly cannot be the basic for an architecture of privacy - even >> if it is an important element in the political landscape. >>=20 >> Henry >>=20 >> [0] this is from a discussion with Ben Laurie >> = http://lists.w3.org/Archives/Public/public-webid/2012Oct/att-0022/privacy-= def-1.pdf >> [1] Oshani's Usage Restriction paper=20 >> http://dig.csail.mit.edu/2011/Papers/IEEE-Policy-httpa/paper.pdf >> [2] = http://lists.w3.org/Archives/Public/public-identity/2012Oct/0036.html >> [3] https://tools.ietf.org/html/draft-hansen-privacy-terminology-03 >> [4] http://www.youtube.com/watch?v=3DSzW25QTVWsE >> [6] http://www.w3.org/2012/10/TPAC/ >> [7] A Comparison between BrowserId and WebId >> = http://security.stackexchange.com/questions/5406/what-are-the-main-advanta= ges-and-disadvantages-of-webid-compared-to-browserid >>=20 >>=20 >> Social Web Architect >> http://bblfish.net/ >>=20 >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag Social Web Architect http://bblfish.net/ --Apple-Mail=_9A73EEC4-EA06-4BC3-9AAB-D8149471E756 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPDTCCByMw ggYLoAMCAQICAwTQYzANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEyMDgyOTAxNDU1NloXDTEzMDgzMDA5MjM0MFowZTEZMBcGA1UEDRMQazQ2eDlvOXJDRE5m VzMwYzEgMB4GA1UEAwwXaGVucnkuc3RvcnlAYmJsZmlzaC5uZXQxJjAkBgkqhkiG9w0BCQEWF2hl bnJ5LnN0b3J5QGJibGZpc2gubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArHXp EmiifOSpudkJn1vAnFdZsuaLuYYLbdWL47o1rKD/kg8/RJUmTIM2ara4e/MOxR16mu2fyAca3H1U oIXNNXDbYQDu2PkfLoNSM5JGAoYbfB0nXBK//ZecidVMZ8eExd02/vFzo5vj9kQNaAPSYirid5xe 1cV9Y1RFjlEozuYAUhU8zi3taf22JM45ii2YrCEgVjDdez8yio0QoJeKEEL3JhL4tqpkbfIOHmdi HYx00S6YcCogDfxXc3zOJ3jcIj/F61eXG1qWX/lq9RAyoBjYHLWE2iHQPwdzum03ubcvOTlohqOR +/cVzvx10l6bJ46KitfbydXMh8HoY7QcmwIDAQABo4IDsjCCA64wCQYDVR0TBAIwADALBgNVHQ8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQRbT9qwRblII9x nAN2FlEMUD1LQzAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAiBgNVHREEGzAZgRdo ZW5yeS5zdG9yeUBiYmxmaXNoLm5ldDCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIw ggH/MC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsG AQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEF BQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9u IHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZv ciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5 IG9ibGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBTZWUg c2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5 LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3Js MIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20v c3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29t L2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALj/A19bRLmI7sMf0lVRrdN23NuRC7/UFSLZ DfcxrR1wOtQgAbrFlFLY+Otn6UWYIiWQpv2v5Ploqw9rMam5W8seC3TUt83StohXCmZ0EDmK87If B6kpd7FwJ0RFGCxn22hPU2kuhp2mbjJzCTrd3jWsXw63MXDUzHuucWGX2mY1Ji+zRECh568N7iWA 5jn9kWT+h7o7ywKbHc4qAnksghLYAnTfoCx1IPkT4/8A5hf38imhf9NcNGibrvt/e49sacf6GjRH Ot/lOCrEX2fh2YvTB5sdEKM5tjKCKNpFSqnRCKhsWZ9N9ZP7mRZfCOBjAMsm3CW2ygwlWXc54lgf p1UwggfiMIIFyqADAgECAgENMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQy MTAxNTRaFw0xMjEwMjIyMTAxNTRaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP 6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu 2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyU GHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmt xWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMB AAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUU3Ltkpzg2ssB XHx+ljVO8tS4UYIwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0 YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHmCAQEwCQYDVR0SBAIwADA9BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYB BQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMw JxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmls aXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29t IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRD FkFTdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENl cnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAqprh4FuMzh0b/B3GLDAgoLeTJv3xArbNESi/ Kf/HMM//gf8FzwUUNOCglH6dfYuLQQ/dTtOyMb4JoiL3T7xiVKEAOmQ+t+b/xLOMa0m18zoRqW4k 6Glyoyvc7LMrdpgYk/lEh5nq8tPd9BoNmwiiheXphIVH/QelTgUkNzTC7IVpmYVsKuNOnxE1jJFZ NNfqZZK/5Oto7C6PfOut11KmBQSLZarAz0b/mjghdBsYfHuhdO8vrOvD0g5g7dA4pkOAU2Ed4pSC owBSItyD/5aFwZ75ji6Yq7GCG3BpiyAP9st8h+inc0L+7kmrAMJaLMAmu6GZs5Xgsbzn0wUJvbD9 h5jnnMM9UaZDcxl2uLB04quGUWM6NiKGabbxQc680PYbeQrQu+e6J4uqNAxzoa5RxkBA5a/3qlbg F9uJBekCqJswx5vQ9khJrs8UTMaIFzbEC5VGQziQH3/6KJ4DUP85OJEnCx/quShWA6w318LDnba3 M6a5V+KoNLhsVi/TSxf90UbBqwdRR/cOwuGkNJh16NvvhIqO26osMg64CbZsDVrEDr7uSMV40ieB JTo49Iyt77ECOhz/pyhowa2EUP6aKav+L/wXzAPB3LNqzujGR0K1pbyFWKvyYmdungJtySWUMw+R 5DqpA2bFIOE56pfWPLHZxOL+8+r79PLFX+y2V6ExggNvMIIDawIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRp ZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1l ZGlhdGUgQ2xpZW50IENBAgME0GMwCQYFKw4DAhoFAKCCAa8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMDA5MDcwNTI0WjAjBgkqhkiG9w0BCQQxFgQU1QkijInO MZRR5b1AG0VI7XhwvoAwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgME0GMwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0ECAwTQYzANBgkqhkiG9w0BAQEFAASCAQCUhkqNOJoYA/SG2Yh0WCLS1HOTNAtNM2P+s30q f7T6wLqOs7gs3IgLG5BPE0xkXP0NmvBkYyrYoKYAYPsPrvvVxRgix+yMDTcgTqS9RxJUw0f4gn9k p0xWePFNbuTKfM/P/ZpNsT9IIlkNUnqKHKHNlMgMRhRp+JkMHKqDt6GCFBhHqcsoEReMVFlIYsHv 27vL4jTZWf/PlXSG+IH43kwqRqBtKKcH7x6Scmg8K2VRnOsPZUTOEvjvEUi/qADw7b/IRfNie2fr jySMXU4y/B007v2wocFSGsna21v4wss1iI9/S9Y3JQZyOBLCXrODhxVQx+sImsJeKUjVIesr4nlb AAAAAAAA --Apple-Mail=_9A73EEC4-EA06-4BC3-9AAB-D8149471E756-- From barryleiba@gmail.com Wed Oct 17 19:13:17 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4B471F0417 for ; Wed, 17 Oct 2012 19:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.064 X-Spam-Level: X-Spam-Status: No, score=-103.064 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4G49UvCZ1ovk for ; Wed, 17 Oct 2012 19:13:16 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFF11F0381 for ; Wed, 17 Oct 2012 19:13:16 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so9049680vbb.31 for ; Wed, 17 Oct 2012 19:13:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=M2n2m7PcvaxW/1rHQB9lPJR93UZOnUD6ncGGdaJPxjs=; b=eO/Fi1UlVdk5d+wGOkU7jy4bF+4eTjy7EWqMICDvmwSSEWblmTqmdD8PiYRBJWSfqt AfFJkq1dm0NvGzRYYjgoKGrlyfKuCW0yzYljmAOF5fNb0GKOzyRwctrvFgZ6/iJvL4vG b+rlFqoQP2O6mR5k5/HkxPKUhilZtVN2u6hILoMUNUIuj+2vM9EkyhBpq8ykrnjZIxKf PhW2chLhcgY52dkynZo4QZn46b8yo9p6qZDZxegnBrANW6+zuEzKOQRdWAbsvs98+SMQ oZTRh5WyemkJiAh+lKgr547AU3j3rlXyf2+kebV1wHxq3SCT9Bvd2OTbB/eU3H02Ijzr IRIg== MIME-Version: 1.0 Received: by 10.52.65.51 with SMTP id u19mr10153962vds.3.1350526395631; Wed, 17 Oct 2012 19:13:15 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.58.28.231 with HTTP; Wed, 17 Oct 2012 19:13:15 -0700 (PDT) Date: Wed, 17 Oct 2012 22:13:15 -0400 X-Google-Sender-Auth: sbcG49MeyDHoNc6SlrVkvSjzLFw Message-ID: From: Barry Leiba To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [saag] Input for conflict review of draft-secure-cookie-session-protocol X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 02:13:17 -0000 A document titled "Secure Cookie Sessions for HTTP" has been submitted to the Independent Stream Editor (ISE): http://datatracker.ietf.org/doc/draft-secure-cookie-session-protocol/ The IESG has been asked to review the document, as specified in RFC 5742, Section 3. The Security and Applications Area Directors are looking for input for that review. Please post any relevant comments to this list, , as soon as possible, and at least by 1 November 2012. Please read RFC 5742, Section 3, and be aware that we are not looking for detailed comments on the document itself (see below). We specifically need input on whether this document is in conflict with work that's being done in the IETF. Look at the five possible responses specified in that section, and help us determine whether any of 2 through 5 applies. Please be specific in your response. In addition to this, we're sure that the authors and the ISE would appreciate comments about the document. If you have those, you may send them directly to the authors at and to the ISE at . General discussion of the document on this list will likely not get to the authors or the ISE. Barry Leiba, Applications AD From barryleiba@gmail.com Thu Oct 18 04:15:05 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACF5721F8530 for ; Thu, 18 Oct 2012 04:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.093 X-Spam-Level: X-Spam-Status: No, score=-103.093 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9qEiFZoMGxN for ; Thu, 18 Oct 2012 04:15:04 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 92E9C21F8599 for ; Thu, 18 Oct 2012 04:15:03 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so9554374vbb.31 for ; Thu, 18 Oct 2012 04:15:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=WtE95nmSzaDqp2n83TtMNz6XLK+QjqMhtoweN3VSqtY=; b=G6u/QGun4n5u4dX7t2f46JyZgWVt5nOAJIouyQEino42pqksBYmdZiIE3fcHVAYKsG Paizoxl6y5beZ8ifEaRfKh8JwsIRLi+z2yjNrtLpwQB2+2y1u2kpzJ1ijiG+0bw32wid Y0jwmTObuiCTnpaJ0YcqBOQAdE7ZB8bkW0/xtfCnbqDaPP8er1xw8sqktOOh3/yHYyTb bJV/kx78oyIUGm7W4bWads+S77gPU0byMdRcI4VRnzf+lBv2J0qmJO3PvRVaFidsqmoH en1Um4nHDiRjwrENeQTdjalOa41dmvH+5A98K5enbyXmyLzXdg7KlU/1wjNlEcpq3DAR OXvw== MIME-Version: 1.0 Received: by 10.52.65.51 with SMTP id u19mr11547773vds.3.1350558903099; Thu, 18 Oct 2012 04:15:03 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.58.28.231 with HTTP; Thu, 18 Oct 2012 04:15:03 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FDE435E7@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114FDE435E7@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 18 Oct 2012 07:15:03 -0400 X-Google-Sender-Auth: 1h9nctkVOv8ggc_dC9iUxbzWXt8 Message-ID: From: Barry Leiba To: "Manger, James H" Content-Type: text/plain; charset=ISO-8859-1 Cc: "saag@ietf.org" Subject: Re: [saag] [apps-discuss] Input for conflict review of draft-secure-cookie-session-protocol X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 11:15:05 -0000 > jose@ietf.org was one group NOT included in your email asking for conflict review. Thanks; I will correct that now. Barry From kwiereng@cisco.com Tue Oct 9 05:29:56 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62CC21F8855 for ; Tue, 9 Oct 2012 05:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luQLe+FkUbnI for ; Tue, 9 Oct 2012 05:29:55 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id D1B0221F8625 for ; Tue, 9 Oct 2012 05:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18418; q=dns/txt; s=iport; t=1349785795; x=1350995395; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=noTwqxjzbIYqD8Qd3rLa/2zuEiT0MTOXxZaOGJUopZ0=; b=J5XyFI64wnAFdm7NHl/zInOTzCN/5EjpwQeKvblUn4dmXf2oPqsue3PA sMahUKFc9KtdTbO032yMHkhdny9gT0/0mDodDwwrTB0v0lVb5JG70o478 Su02JqkdA+DIPgLrnZfGgDp2d26ttdXnFcOzniiXQzfyLIJEKjr7uPvOo Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAIQYdFCtJV2a/2dsb2JhbAA7AQm/LoEIDwGCEAEBAQIBAQEBAQ8BJzQGBQULAgEIEgYKCwQCAxAnAQoXDgIEDgMCCBMHhW+BbgYLmxCPVoIOji6LOQEPAQMBglEWBwKCLmADkA+CKoEEg0KKEYMfgWuCbT5/HQEBBzQ X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="129700882" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 09 Oct 2012 12:29:47 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q99CTlZX026059 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Oct 2012 12:29:47 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.49]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.001; Tue, 9 Oct 2012 07:29:46 -0500 From: "Klaas Wierenga (kwiereng)" To: Henry Story Thread-Topic: [saag] Liking Linkability Thread-Index: AQHNpXaTk0ORLk0j/kq9MaAE3ZH1SJevukyngACQmQCAAPGLgA== Date: Tue, 9 Oct 2012 12:29:46 +0000 Message-ID: <7E1636E02F313F4BA69A428B314B77C708217189@xmb-aln-x12.cisco.com> References: <88F98DFD-EF7D-4444-A9C2-FB8E15F5DA89@bblfish.net> <3757D928-C3AE-4630-98E7-E30B5CC604B0@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.86.88] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19254.003 x-tm-as-result: No--29.233800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <7BD774B64AE90442A4D8911353D73EAE@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 18 Oct 2012 08:03:40 -0700 Cc: "public-identity@w3.org" , "public-philoweb@w3.org" , "saag@ietf.org" , "public-webid@w3.org" , "public-privacy@w3.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 12:29:56 -0000 Hi Henry, (adding saag, had not realised that it was a resend) On Oct 9, 2012, at 12:05 AM, Henry Story wrote: >=20 > On 8 Oct 2012, at 20:27, "Klaas Wierenga (kwiereng)" = wrote: >=20 >> Hi Henry, >>=20 >> I think your definition of what constitutes a private conversation is a = bit limited, especially in an electronic day and age. I consider the simple= fact that we are having a conversation, without knowing what we talk about= , a privacy sensitive thing. Do you want your wife to know that you are tal= king to your mistress, or your employer that you have a job interview? >> And do you believe that the location where you are does not constitute a= privacy sensitive attribute? >=20 > Ok I think my definition still works: If someone knows that you are commu= nicating with someone then they know something about the conversation. In m= y definition that does constitute a privacy violation at least for that bit= of information. ehm, I think that you need quite a bit of fantasy to read that in your defi= nition ;-) So if you mean also "or are aware of the communication" you shou= ld perhaps include that, but, as you point out below, that does complicate = things big time. > Though I think you exaggerate what they know. Your wife won't know that = you are talking to your mistress, just that you are talking to another serv= er (If it is a freedom box, they could narrow it down to an individual). In= formation about it being a mistress cannot be found just by seeing informat= ion move over the wire. Neither does an employer know you have a job interv= iew just because you are communicating with some server x from a different = company. But he could be worried. I think you are now digressing from the general case, whilst your definitio= n was meant to be very generic (I believe?). I am not talking about impleme= ntations, but about the general principle. The fact that there is an xmpp s= ession between klaas@cisco.com and compensation@apple.com may indicate to m= y manager that I am looking for another job. My manager might also be worri= ed if he sees me entering the Google premises, but that is much less likely= (even though I have helped applicants get out of the building through the = emergency exit because a colleague had arrived in the reception area in the= past ;-) The reason I brought these examples up is that I believe somethin= g has changed with the ubiquity of online databases and online communicatio= n. When I didn't want to be overheard in the past I would go for a walk wit= h someone and we could talk with reasonable assurance. Now I have to trust = that say Skype is not listening in to my conversation and that Twitter will= not hand my tweets to DHS. So the simple fact that I use an encrypted chan= nel is not sufficient. >=20 > So if I apply this to WebID ( http://webid.info/ ) - which is I think wh= y you bring it up - WebID is currently based on TLS, which does make it pos= sible to track connections between servers. But remember that the perfect i= s the enemy of the good. How come? Well, put things in context: by failing = to create simple distributed systems which protect privacy of content prett= y well, that works with current deployed technologies (e.g. browsers, and s= ervers), we have allowed large social networks to grow to sizes unimaginabl= e in any previous surveillance society. So even a non optimal system like = TLS can still bring huge benefits over the current status quo. If only in e= ducating people in how to build such reasonably safe distributed systems. I was not referring to WebID in particular. I applaud your effort, and do r= ealise that perfect will not happen. However I think that your definition o= f privacy should either be scoped tightly to particular use cases or is too= broad a brush. I tend to think that one single definition of privacy is no= t very useful, and rather like to think about different forms of privacy, l= ocation privacy, encrypted channels, plausible deniability etc. >=20 > But having put that in context, the issue of tracking what servers are c= ommunicating remains. There are technologies designed to make that opaque, = such as Tor. I still need to prove that one can have .onion WebIDs, and tha= t one can also connect with browsers using TLS behind Tor - but it should n= ot be difficult to do. Once one can show this then it should be possible to= develop protocols that make this a lot more efficient. Would that convinc= e you? Ehm, what actually concerns me more is not the fact that *it is possible* t= o design proper protocols as much as that I would like to provide guidance = to protocol developers to *prevent improper protocols*. Does that make sens= e? Klaas >=20 >>=20 >> Klaas >>=20 >> Sent from my iPad >>=20 >> On 8 okt. 2012, at 19:01, "Henry Story" wrote: >>=20 >>>=20 >>> Notions of unlinkability of identities have recently been deployed=20 >>> in ways that I would like to argue, are often much too simplistic,=20 >>> and in fact harmful to wider issues of privacy on the web. >>>=20 >>> I would like to show this in two stages: >>> 1. That linkability of identity is essential to electronic privacy=20 >>> on the web >>> 2. Show an example of an argument by Harry Halpin relating to=20 >>> linkability, and by pulling it apart show how careful one has=20 >>> to be with taking such arguments at face value >>>=20 >>> Because privacy is the context in which the linkability or non linkabil= ity >>> of identities is important, I would like to start with a simple working= =20 >>> definition of what constitutes privacy with the following minimal=20 >>> criterion [0] that I think everyone can agree on: >>>=20 >>> "A communication between two people is private if the only people=20 >>> who are party to the conversation are the two people in question.=20 >>> One can easily generalise to groups: a conversation between groups=20 >>> of people is private (to the group) if the only people who can=20 >>> participate/read the information are members of that group" >>>=20 >>> Note that this does not deal with issues of people who were privy to=20 >>> the conversation later leaking information voluntarily. We cannot=20 >>> technically legislate good behaviour, though we can make it possible=20 >>> for people to express context. [1] >>>=20 >>>=20 >>> 1. On the importance of linkability of identities to privacy=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=3D >>>=20 >>> A. Issues of Centralisation >>> --------------------------- >>>=20 >>> We can put this with the following thought experiment which I put >>> to Ben Laurie recently [0]. >>>=20 >>> First imagine that we all are on one big social network, where=20 >>> all of our home pages are at the same URL. Nobody could link >>> to our profile page in any meaningful way. The bigger the network >>> the more different people that one URL could refer to. People=20 >>> that were part of the network could log in, and once logged in >>> communicate with others in their unlinkable channels.=20 >>>=20 >>> But this would not necessarily give users of the network privacy:=20 >>> simply because the network owner would be party to the conversation=20 >>> between any two people or any group of people. Conversations=20 >>> that do not wish the network owner to be party to the conversation >>> cannot work within that framework.=20 >>>=20 >>> At the level of our planet it is clear that there will always be a=20 >>> huge number of agents that cannot for legal or other reasons allow one= =20 >>> global network owner to be party to all their conversations. We are=20 >>> therefore socio-logically forced into the social web. >>>=20 >>> B. Linkability and the Social Web >>> --------------------------------- >>>=20 >>> Secondly imagine that we now all have Freedom Boxes [4], where >>> each of us has full control over the box, its software, and the >>> data on it. (We take this extreme individualistic case to emphasise >>> the contrast, not because we don't acknowledge the importance of >>> many intermediate cases as useful) Now we want to create a=20 >>> distributed social network - the social web - where each of us can=20 >>> publish information and through access control rules limit who can=20 >>> access each resource. We would like to limit access to groups such >>> as: >>>=20 >>> - friends=20 >>> - friends of friends >>> - family >>> - business colleagues >>> - ...=20 >>>=20 >>> Limit access means, that we need to determine when accessing a=20 >>> resource who is accessing it. For this we need a global identifier >>> so that can check with the information available to us, if the=20 >>> referent of that identifier is indeed a member of one of those=20 >>> groups. We can't have a local identifier, for that would require >>> that the person we were dealing with had an account on our private >>> box - which will be extremely unlikely. We therefore need a way=20 >>> to identify - pseudonymously if be - agents in a global space. >>>=20 >>> Take the following example. Imagine you come to the WebID TPAC >>> meeting [6] and I take a picture of everyone present. I would like >>> to first restrict access to the picture to only those members who >>> were present. Clearly if I only used local identifiers, I would have >>> to get each one of you to first create an account on my machine. But=20 >>> how would I then know that the accounts created on the FBox correspond >>> to the people who were at the party? It is much easier if we could >>> create a party members group and publish it like this >>>=20 >>> http://www.w3.org/2005/Incubator/webid/team.n3 >>>=20 >>> Then I could drag and drop this group on the access control panel >>> of my FBox admin console to restrict access to only those members. >>> This shows how through linkability I can restrict access and=20 >>> increase privacy by making it possible to link identities in a distribu= ted >>> web. It would be quite possible furthermore for the above team.n3 >>> resource to be protected by access control. >>>=20 >>>=20 >>> 2. Example of how Unlinkability can be used to spread FUD=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 >>>=20 >>>=20 >>> So here I would like to show how fears about linkability can >>> then bring intelligent people like Harry Halpin to make some seemingly >>> plausible arguments. Here is an example [2] of Harry arguing against >>> W3C WebID CG's http://webid.info/spec/=20 >>>=20 >>> [[ >>> Please look up "unlinkability" (which is why I kept referencing the=20 >>> aforementioned IETF doc [sic [3] below it is a draft] which I saw=20 >>> referenced earlier but whose main point seemed missed). Then explain=20 >>> how WebID provides unlinkability.=20 >>>=20 >>> Looking at the spec - to me, WebID doesn't as it still requires=20 >>> publishing your public key at a URI and then having the relying party g= o=20 >>> to your identity provider (i.e. your personal homepage in most cases,=20 >>> i.e. what it is that hosts your key) in order to verify your cert, whic= h=20 >>> must provide that URI in the SAN in the cert. Thus, WebID does not=20 >>> provide unlinkability. There's some waving of hands about guards and=20 >>> access control, but that would not mediate the above point, as the HTTP= =20 >>> GET to the URI for the key is enough to provide the "link". >>>=20 >>> In comparison, BrowserID provides better privacy in terms of=20 >>> unlinkability by having the browser in between the identity provider an= d=20 >>> the relying party, so the relying party doesn't have to ping the=20 >>> identity provider for identity-related transactions. That definitely=20 >>> helps provide unlinkability in terms of the identity provider not=20 >>> needing to knowing every time the user goes to a relying party. >>> ]] >>>=20 >>> If I can rephrase the point seems to be the following: A WebID verifica= tion=20 >>> requires that the site your are authenticating to ( The Relying Party )= verify >>> your identity by dereferencing ( let me add: anonymously ) your profile= =20 >>> page, which might only contain as much as your public key publicly. The= yellow=20 >>> box in the picture here: >>>=20 >>> http://www.w3.org/2005/Incubator/webid/spec/#the-webid-protocol >>>=20 >>> The leakage of information then would not be towards the Relying Party = - the >>> site you are logging into - because that site is the one you just wilfu= lly=20 >>> sent a proof of your identity to. The leakage of information is (drum r= oll)=20 >>> towards your profile page server! That server might discover ( through = IP address=20 >>> sniffing presumably ) which sites you might be visiting.=20 >>>=20 >>> One reasonable answer to this problem would be for the Relying Party to= fetch=20 >>> this information via Tor which would remove the ip address sniffing pro= blem. >>>=20 >>> But let us develop the picture of who we are loosing (potentially)=20 >>> information to. There are a number of profile server scenarios:=20 >>>=20 >>> A. Profile on My Freedom Box [4] >>>=20 >>> The FreedomBox is a personal machine that I control, running >>> free software that I can inspect. Here the only person who has >>> access to the Freedom Box is me. So if I discover that I logged >>> in somewhere that should come as no surprise to me. I might even >>> be interested in this information as a way of gathering information >>> about where I logged in - and perhaps also if anything had been=20 >>> logging in somewhere AS me. (Sadly it looks like it might be >>> difficult to get much good information there as things stand=20 >>> currently with WebID.) >>>=20 >>> B. Profile on My Company/University Profile Server >>>=20 >>> As a member of a company, I am part of a larger agency, namely the=20 >>> Company or University who is backing my identity as member of that >>> institution. A profile on a University web site can mean a lot more >>> than a profile on some social network, because it is in part backed >>> by that institution. Of course as a member of that institution we >>> are part of a larger agent hood. And so it is not clear that the instit= ution >>> and me are in that context that different. This is also why it is=20 >>> often legally required that one not use one's company identity for >>> private business. >>>=20 >>> C. A Social Network ( Google+, Facebook, ... ) >>>=20 >>> It is a bit odd that people who are part of these networks, and who >>> are "liking" pretty much everything on the web in a way that is clearly >>> visible and is encouraged by those networks to be visible to the=20 >>> network, would have an issue with those sites knowing-perhaps (if the=20 >>> RP does not use Tor or a proxy) where they are logging into. It is cert= ainly >>> not the way the OAuth, OpenID or other protocols that are in extremely= =20 >>> wide use now have been developed and are used by those sites. >>>=20 >>> If we look then at BrowserId [7] Now Mozilla Persona, the only differen= ce=20 >>> really with WebID ( apart from it not being decentralised until crypto = in the >>> browser really works ) is that the certificate is updated at short noti= ce=20 >>> - once a day - and that relying parties verify the signature. Neither o= f course >>> can the relying party get much interesting attributes this way, and if = it did >>> then the whole of the unlinkability argument would collapse immediately= . >>>=20 >>>=20 >>> 3. Conclusion >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>> Talking about privacy is like talking about security. It is a breeding = ground=20 >>> for paranoia, which tend to make it difficult to notice important >>> solutions to the problem we actually have. Linkability or unlinkability= as defined in >>> draft-hansen-privacy-terminology-03 [3] come with complicated definitio= ns, >>> and are I suppose meant to be applied carefully. But the choice of "unl= inkable" >>> as a word tends to help create rhethorical short cuts that are apt to h= ide the=20 >>> real problems of privacy. By trying too hard to make things unlinkable = we are moving=20 >>> inevitably towards a centralised world where all data is in big brother= 's hands.=20 >>>=20 >>> I want to argue that we should all *Like* Linkability. We should >>> do it aware that we can protect ourselves with access control (and TOR= )=20 >>> and realise that we don't need to reveal anything more than anyone knew= =20 >>> before hand in our linkable profiles. >>>=20 >>> To create a Social Web we need a Linkable ( and likeable ) social web. >>> We may need other technologies for running Wikileaks type set ups, but >>> the clearly cannot be the basic for an architecture of privacy - even >>> if it is an important element in the political landscape. >>>=20 >>> Henry >>>=20 >>> [0] this is from a discussion with Ben Laurie >>> http://lists.w3.org/Archives/Public/public-webid/2012Oct/att-0022/priv= acy-def-1.pdf >>> [1] Oshani's Usage Restriction paper=20 >>> http://dig.csail.mit.edu/2011/Papers/IEEE-Policy-httpa/paper.pdf >>> [2] http://lists.w3.org/Archives/Public/public-identity/2012Oct/0036.ht= ml >>> [3] https://tools.ietf.org/html/draft-hansen-privacy-terminology-03 >>> [4] http://www.youtube.com/watch?v=3DSzW25QTVWsE >>> [6] http://www.w3.org/2012/10/TPAC/ >>> [7] A Comparison between BrowserId and WebId >>> http://security.stackexchange.com/questions/5406/what-are-the-main-adva= ntages-and-disadvantages-of-webid-compared-to-browserid >>>=20 >>>=20 >>> Social Web Architect >>> http://bblfish.net/ >>>=20 >>> _______________________________________________ >>> saag mailing list >>> saag@ietf.org >>> https://www.ietf.org/mailman/listinfo/saag >=20 > Social Web Architect > http://bblfish.net/ >=20 From James.H.Manger@team.telstra.com Wed Oct 17 22:08:29 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF9621F85B1 for ; Wed, 17 Oct 2012 22:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.872 X-Spam-Level: X-Spam-Status: No, score=-0.872 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MITZMCYfnBn for ; Wed, 17 Oct 2012 22:08:28 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 354A821F8599 for ; Wed, 17 Oct 2012 22:08:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,605,1344175200"; d="scan'208";a="104324485" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipoani.tcif.telstra.com.au with ESMTP; 18 Oct 2012 16:08:24 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6868"; a="43296317" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcani.tcif.telstra.com.au with ESMTP; 18 Oct 2012 16:08:24 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Thu, 18 Oct 2012 16:08:23 +1100 From: "Manger, James H" To: "saag@ietf.org" , Barry Leiba Date: Thu, 18 Oct 2012 16:08:22 +1100 Thread-Topic: [apps-discuss] Input for conflict review of draft-secure-cookie-session-protocol Thread-Index: Ac2s19rcyLmes8slSgS2DAE46H2uPQAEq41A Message-ID: <255B9BB34FB7D647A506DC292726F6E114FDE435E7@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 18 Oct 2012 08:03:40 -0700 Subject: Re: [saag] [apps-discuss] Input for conflict review of draft-secure-cookie-session-protocol X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 05:08:29 -0000 QmFycnksDQoNCmRyYWZ0LXNlY3VyZS1jb29raWUtc2Vzc2lvbi1wcm90b2NvbC0wOCBpcyBmYWly bHkgY2xvc2UgdG8gdGhlIElFVEYgSk9TRSB3b3JraW5nIGdyb3Vw4oCZcyBKU09OIFdlYiBFbmNy eXB0aW9uIChKV0UpIGZvcm1hdCBbZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWVuY3J5cHRpb25d Lg0KDQpqb3NlQGlldGYub3JnIHdhcyBvbmUgZ3JvdXAgTk9UIGluY2x1ZGVkIGluIHlvdXIgZW1h aWwgYXNraW5nIGZvciBjb25mbGljdCByZXZpZXcuDQoNCg0KZHJhZnQtc2VjdXJlLWNvb2tpZS1z ZXNzaW9uLXByb3RvY29sLTA4Og0KKiBhIHNtYWxsaXNoIHRleHQgc3RyaW5nIHdpdGggY29uZmlk ZW50aWFsaXR5IGFuZCBpbnRlZ3JpdHkgcHJvdGVjdGlvbjsgYXMgZG9lcyBKV0UNCiogc3ltbWV0 cmljIGtleTsgd2hpY2ggaXMgb25lIEpXRSBvcHRpb24NCiogYXJiaXRyYXJ5IGJpbmFyeSBjb250 ZW50OyBzYW1lIGFzIEpXRQ0KKiB1c2VzIGJhc2U2NHVybCBlbmNvZGluZzsgc2FtZSBhcyBKV0UN CiogdXNlcyAifCIgYXMgYSBzZXBhcmF0b3I7IEpXRSB1c2VzICIuIg0KKiBkZWZsYXRlIGNvbXBy ZXNzaW9uOyBzYW1lIGFzIEpXRQ0KKiBpbmNsdWRlcyB0aGUgdGltZTsgc2lnbmluZy10aW1lIGZp ZWxkIGhhcyBiZWVuIHByb3Bvc2VkIGZvciBKV0UNCiogc2luZ2xlIGlkIGluZGljYXRlcyBrZXlz IGFuZCBhbGdvcml0aG1zOyBKV0UgaGFzIHNlcGFyYXRlIGFsZyBpZCwgYW5kIChicm9rZW4pIGtl eSBpZA0KKiANCg0KQXMgdG8gd2hldGhlciBkcmFmdC1zZWN1cmUtY29va2llLXNlc3Npb24tcHJv dG9jb2wtMDgg4oCcY291bGQgcG90ZW50aWFsbHkgZGlzcnVwdCB0aGUgSUVURiB3b3JrIGRvbmUg aW4gV0figJ0gSk9TReKApiB1aG1tLiBQcm9iYWJseSBub3QuDQoNCg0KDQotLQ0KSmFtZXMgTWFu Z2VyDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBhcHBzLWRpc2N1 c3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmFwcHMtZGlzY3Vzcy0NCj4gYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEJhcnJ5IExlaWJhDQo+IFNlbnQ6IFRodXJzZGF5LCAxOCBPY3Rv YmVyIDIwMTIgMToyNSBQTQ0KPiBUbzogaHR0cC1zdGF0ZUBpZXRmLm9yZzsgd2Vic2VjQGlldGYu b3JnOyBpZXRmLWh0dHAtd2dAdzMub3JnOyBhcHBzLQ0KPiBkaXNjdXNzQGlldGYub3JnOyBvYXV0 aEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBbYXBwcy1kaXNjdXNzXSBJbnB1dCBmb3IgY29uZmxpY3Qg cmV2aWV3IG9mIGRyYWZ0LXNlY3VyZS0NCj4gY29va2llLXNlc3Npb24tcHJvdG9jb2wNCj4gDQo+ IEEgZG9jdW1lbnQgdGl0bGVkICJTZWN1cmUgQ29va2llIFNlc3Npb25zIGZvciBIVFRQIiBoYXMg YmVlbiBzdWJtaXR0ZWQNCj4gdG8gdGhlIEluZGVwZW5kZW50IFN0cmVhbSBFZGl0b3IgKElTRSk6 DQo+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc2VjdXJlLWNvb2tpZS1z ZXNzaW9uLXByb3RvY29sLw0KPiANCj4gVGhlIElFU0cgaGFzIGJlZW4gYXNrZWQgdG8gcmV2aWV3 IHRoZSBkb2N1bWVudCwgYXMgc3BlY2lmaWVkIGluIFJGQw0KPiA1NzQyLCBTZWN0aW9uIDMuICBU aGUgU2VjdXJpdHkgYW5kIEFwcGxpY2F0aW9ucyBBcmVhIERpcmVjdG9ycyBhcmUNCj4gbG9va2lu ZyBmb3IgaW5wdXQgZm9yIHRoYXQgcmV2aWV3LiAgUGxlYXNlIHBvc3QgYW55IHJlbGV2YW50IGNv bW1lbnRzDQo+IHRvIHRoZSBTZWN1cml0eSBBcmVhIGxpc3QsIDxzYWFnQGlldGYub3JnPiwgYXMg c29vbiBhcyBwb3NzaWJsZSwgYW5kIGF0DQo+IGxlYXN0IGJ5IDEgTm92ZW1iZXIgMjAxMi4NCj4g DQo+IE5vdGU6IFBsZWFzZSBkbyBOT1QgcG9zdCByZXNwb25zZXMgdG8gYW55IG9mIHRoZXNlIG1h aWxpbmcgbGlzdHMuDQo+IFJlc3BvbmQgb25seSB0byA8c2FhZ0BpZXRmLm9yZz4gKHVzaW5nIHRo ZSBzdWJqZWN0IGxpbmUgb2YgdGhpcw0KPiBtZXNzYWdlKS4NCj4gDQo+IFBsZWFzZSByZWFkIFJG QyA1NzQyLCBTZWN0aW9uIDMsIGFuZCBiZSBhd2FyZSB0aGF0IHdlIGFyZSBub3QgbG9va2luZw0K PiBmb3IgZGV0YWlsZWQgY29tbWVudHMgb24gdGhlIGRvY3VtZW50IGl0c2VsZiAoc2VlIGJlbG93 KS4gIFdlDQo+IHNwZWNpZmljYWxseSBuZWVkIGlucHV0IG9uIHdoZXRoZXIgdGhpcyBkb2N1bWVu dCBpcyBpbiBjb25mbGljdCB3aXRoDQo+IHdvcmsgdGhhdCdzIGJlaW5nIGRvbmUgaW4gdGhlIElF VEYuICBMb29rIGF0IHRoZSBmaXZlIHBvc3NpYmxlDQo+IHJlc3BvbnNlcyBzcGVjaWZpZWQgaW4g dGhhdCBzZWN0aW9uLCBhbmQgaGVscCB1cyBkZXRlcm1pbmUgd2hldGhlciBhbnkNCj4gb2YgMiB0 aHJvdWdoIDUgYXBwbGllcy4gIFBsZWFzZSBiZSBzcGVjaWZpYyBpbiB5b3VyIHJlc3BvbnNlLg0K PiANCj4gSW4gYWRkaXRpb24gdG8gdGhpcywgd2UncmUgc3VyZSB0aGF0IHRoZSBhdXRob3JzIGFu ZCB0aGUgSVNFIHdvdWxkDQo+IGFwcHJlY2lhdGUgY29tbWVudHMgYWJvdXQgdGhlIGRvY3VtZW50 LiAgSWYgeW91IGhhdmUgdGhvc2UsIHlvdSBtYXkNCj4gc2VuZCB0aGVtIGRpcmVjdGx5IHRvIHRo ZSBhdXRob3JzIGF0IDxkcmFmdC1zZWN1cmUtY29va2llLXNlc3Npb24tDQo+IHByb3RvY29sQHRv b2xzLmlldGYub3JnPg0KPiBhbmQgdG8gdGhlIElTRSBhdCA8cmZjLWlzZUByZmMtZWRpdG9yLm9y Zz4uDQo+IEdlbmVyYWwgZGlzY3Vzc2lvbiBvZiB0aGUgZG9jdW1lbnQgb24gdGhlc2UgbGlzdHMg b3IgdGhlIHNhYWcgbGlzdCB3aWxsDQo+IGxpa2VseSBub3QgZ2V0IHRvIHRoZSBhdXRob3JzIG9y IHRoZSBJU0UuDQo+IA0KPiBCYXJyeSBMZWliYSwgQXBwbGljYXRpb25zIEFEDQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGFwcHMtZGlzY3VzcyBt YWlsaW5nIGxpc3QNCj4gYXBwcy1kaXNjdXNzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNzDQo= From w@1wt.eu Wed Oct 17 23:48:11 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F86F21F85F3 for ; Wed, 17 Oct 2012 23:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.034 X-Spam-Level: X-Spam-Status: No, score=-5.034 tagged_above=-999 required=5 tests=[AWL=-2.991, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHS4UEO1bFcK for ; Wed, 17 Oct 2012 23:48:10 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4BC21F85EF for ; Wed, 17 Oct 2012 23:48:09 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q9I6m5Tj008940 for saag@ietf.org; Thu, 18 Oct 2012 08:48:05 +0200 Date: Thu, 18 Oct 2012 08:48:05 +0200 From: Willy Tarreau To: saag@ietf.org Message-ID: <20121018064805.GI7517@1wt.eu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Thu, 18 Oct 2012 08:03:40 -0700 Subject: Re: [saag] Input for conflict review of draft-secure-cookie-session-protocol X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 06:48:11 -0000 Hello, I just checked the following document and have one main concern : On Wed, Oct 17, 2012 at 10:25:16PM -0400, Barry Leiba wrote: > A document titled "Secure Cookie Sessions for HTTP" has been submitted > to the Independent Stream Editor (ISE): > http://datatracker.ietf.org/doc/draft-secure-cookie-session-protocol/ Section 3.3.1.1. mandates the use of the Expires field : SCS cookies MUST include an Expires attribute which shall be set to a value consistent with session_max_age. This means that these cookies will necessarily be stored, they're not just session cookies that expire at the end of the browsing session. But later it is clearly stated in section 8.2.1 that nothing is possible to prevent a stolen cookie from being replayed. This is a big concern because with normal cookies where the server owns the state, the user just has to logout when he suspects a cookie disclosure, this causes his session to terminate and the associated cookie cannot be used anymore. With SCS, it looks like when the user knows his cookie has been stolen, all he can do is wait for its maximum life time to expire. Right now stolen cookies are the main security issue on the web. Banking applications have to live with malware which steal user cookies so that other people can remotely browse on their account. Some malware even do the work in parallel with the user, or wait for the user to become idle to do some operations before he closes the browser. With SCS, it looks like the malware will not need to install in the browser anymore, it will just have to steal the stored cookie and use it at any time even when the browser is closed, since the user has no way to revoke it. Hence, I'm failing to see what specific use case this protocol covers, however I see a risk that it is adopted by users who don't completely understand its security implications. The focus is clearly set on how the cookie contents are secured but not that much on what it should or should not be used for. Regards, Willy PS: please CC me in responses, I'm not subscribed to saag@. From benl@google.com Thu Oct 18 08:34:09 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC1321F8450 for ; Thu, 18 Oct 2012 08:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOIJYJStQW+s for ; Thu, 18 Oct 2012 08:34:07 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id E824621F845C for ; Thu, 18 Oct 2012 08:34:06 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so1841595wib.13 for ; Thu, 18 Oct 2012 08:34:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=wAbhudDh5F977wju3ZS43C6djvES5oFNFQ3fG70ddJg=; b=Av0j4IfEepE+j03k9jKyuj66PpgsLgp8bp5z3u+CMlKRS4cDuTU6qD6S8PG/xzSasY rcyKfKhFb2DiDNxcR4aTxYIIP2qgvrwIj0eThe8+/i1Z7Fq/sPF4aaMbFkA7za81JStM foCXgSubYPGauXtCp6eBgU8NJgZ4iZtZ3IItbSsUE2mlHzBDCpis9Q62dgXrnsgBU8DV XByhH3zaoXIlzPESFMlsv3f7IT0PKPZNvJpqB8/lfJFGQgIImVz2uY5cWj+enaxhKtVJ s5T+Bnl44qG4hZeBIKusf/4siO+k/Mp6cVGBt16RjkSjqsDYc/FlB7aCScm7o4VMDibp Rv6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=wAbhudDh5F977wju3ZS43C6djvES5oFNFQ3fG70ddJg=; b=jMep6UzhGS1MsnxDo8LovZA/InmJ9+AlQGLDU1yLvARZVReKF1kngGw6By7CS9KFL9 lSS9ErDXjRxGMc/qDEkj2chmWD4wszFmh0gI3Ni5NGncUdgit1g7fosNzMXyRwakLSnm PUeiD06vZ6kLG0KHkdj6rAfEamQIqFNjov0RAya90DPXmOngHlgmt4sfoEG0Uadlcb95 kouIvXSX5AT6LzhtDy6rYgVSHwPI5QZlcxLqwi+G/iZ7HujZfUyMZMwDE0LyiwlZVJsJ JT8hRaSWVUJHlgAI4y02IpDhU7L+K+zejnYQSLMMKZPlC3p8zFBs6FaugjqQm2MSXwo2 WQ6g== MIME-Version: 1.0 Received: by 10.180.87.34 with SMTP id u2mr12200639wiz.3.1350574445909; Thu, 18 Oct 2012 08:34:05 -0700 (PDT) Received: by 10.216.236.201 with HTTP; Thu, 18 Oct 2012 08:34:05 -0700 (PDT) In-Reply-To: <7ABCD095-4B09-40DD-A084-1BBE761CA72F@bblfish.net> References: <88F98DFD-EF7D-4444-A9C2-FB8E15F5DA89@bblfish.net> <3757D928-C3AE-4630-98E7-E30B5CC604B0@cisco.com> <7E1636E02F313F4BA69A428B314B77C708217189@xmb-aln-x12.cisco.com> <7ABCD095-4B09-40DD-A084-1BBE761CA72F@bblfish.net> Date: Thu, 18 Oct 2012 16:34:05 +0100 Message-ID: From: Ben Laurie To: Henry Story Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnlY/+oYH57un+V5P5S9+0hTY+7PbLZREZb1lEaqlfCmMV+ulavBZeiFjwrNZzu2HQ46OAPKqPtDjQ8qs2+tT3uX0I9XYL5OwcUguRrRKZoGqYZDvu21MVjQttpS513SSmEZ4erHrcj2jayDDUJt88t1HuKceE3qmIHyKUmbeM/a2/dg+VKWUNSO6AQYITyhgAkTVhs Cc: "public-philoweb@w3.org" , "public-identity@w3.org" , "saag@ietf.org" , "public-privacy@w3.org" , "Klaas Wierenga \(kwiereng\)" , "public-webid@w3.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 15:34:09 -0000 On 9 October 2012 14:19, Henry Story wrote: > Still in my conversations I have found that many people in security spaces > just don't seem to be able to put the issues in context, and can get sidetracked > into not wanting any linkability at all. Not sure how to fix that. You persist in missing the point, which is why you can't fix it. The point is that we want unlinkability to be possible. Protocols that do not permit it or make it difficult are problematic. I have certainly never said that you should always be unlinked, that would be stupid (in fact, I once wrote a paper about how unpleasant it would be). As I once wrote, anonymity should be the substrate. Once you have that, you can the build on it to be linked when you choose to be, and not linked when you choose not to be. If it is not the substrate, then you do not have this choice. From benl@google.com Thu Oct 18 09:06:13 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABDF11F0417 for ; Thu, 18 Oct 2012 09:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAJSYW7jLAGm for ; Thu, 18 Oct 2012 09:06:13 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id EFAB521F8842 for ; Thu, 18 Oct 2012 09:06:12 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so10681176vcb.31 for ; Thu, 18 Oct 2012 09:06:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=3H7fgmV5hfLC5znkXY78YxL2k5v94vZVtRl0qIawWqg=; b=kOjVEN2zYZjkm5xUZit+hlVvSSZpDY8we4cfanZLVo/bB0EnJ2tbGCKAWLXPOXANPU oZ9an/GRS8Yyb/h+tEWz+WRiRXQMuoJHGqhpfo5Rh+h0gpIuyp2riVhlos04vq7mAAUe FuMg8WJ06+1zCbu1xtH+8UCghSwkk6OROzP8Z0Er5sYtnvwoziwTZO3tvSwITWIDGfSv tqd5LffcD/U7Fd/ArNAg6owPwYO68cxPuAo5K5JRk7eRvWNuf6zEGaXnl8dipKdUMK0y Z12A1Jbis00QszvsQi3+zoXPm4LFzAMLAujujeKq0Mj1TiqDtJpKmZOZMTHjqOp8balz 4Oag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=3H7fgmV5hfLC5znkXY78YxL2k5v94vZVtRl0qIawWqg=; b=MR3CvcKXzSBv/OEDajRdjKKjb2x0B7Hgu+ZM+IM6Wxu6X6bjcuynvcykqQur0CeJdg hju1E4KOV9hTdgXSyRPYqBkG2pIRD/zNP27JrhzzGcU+tnQU2xFCoYS2qtL0EEFjKKE6 Uz8xaLqrBq1Lh4PFtY90BSqhKts/fQ8KLrHVfXGKH+Wb5v5//SKX3E1jUoCkdd1kr1rl i6c4TOvr1SSRcDgSms20lHcSbICG9+6z0paOTx38ndjHeph8chAwa/plz3gWMm8+Q/2N 8BR+jucLt9fjZ4hIwJqqtXQj8uT+Ez7S3aS56jnm+62m7OsY3o4QjuW1pwOrcwZxoVaY 7q2w== MIME-Version: 1.0 Received: by 10.58.172.167 with SMTP id bd7mr16652073vec.15.1350576370400; Thu, 18 Oct 2012 09:06:10 -0700 (PDT) Received: by 10.220.155.132 with HTTP; Thu, 18 Oct 2012 09:06:10 -0700 (PDT) In-Reply-To: <50802328.70205@openlinksw.com> References: <88F98DFD-EF7D-4444-A9C2-FB8E15F5DA89@bblfish.net> <3757D928-C3AE-4630-98E7-E30B5CC604B0@cisco.com> <7E1636E02F313F4BA69A428B314B77C708217189@xmb-aln-x12.cisco.com> <7ABCD095-4B09-40DD-A084-1BBE761CA72F@bblfish.net> <50802328.70205@openlinksw.com> Date: Thu, 18 Oct 2012 17:06:10 +0100 Message-ID: From: Ben Laurie To: Kingsley Idehen Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQl8AVgjZ3FlCp5efnh9MsuNAYvQYhPmogEvbFXRR5Zx40eNX18/diSAQo2g727AEzgACAa9ezRg+BW5fgc4/alZY0APgnE03tzFidc032cMHgdeLqdwnQuI09edS31CZatJrQMwLaGgGeQ8FLKYcbjeCupY8ZnR4VV5Iqw2zp4Ez7tFLgc2VxDTc1+S0CWTSJTa2vvL Cc: "public-philoweb@w3.org" , "public-identity@w3.org" , "saag@ietf.org" , "public-privacy@w3.org" , "Klaas Wierenga \(kwiereng\)" , "public-webid@w3.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 16:06:13 -0000 On 18 October 2012 16:41, Kingsley Idehen wrote: > On 10/18/12 11:34 AM, Ben Laurie wrote: >> >> On 9 October 2012 14:19, Henry Story wrote: >>> >>> Still in my conversations I have found that many people in security >>> spaces >>> just don't seem to be able to put the issues in context, and can get >>> sidetracked >>> into not wanting any linkability at all. Not sure how to fix that. >> >> You persist in missing the point, which is why you can't fix it. The >> point is that we want unlinkability to be possible. Protocols that do >> not permit it or make it difficult are problematic. I have certainly >> never said that you should always be unlinked, that would be stupid >> (in fact, I once wrote a paper about how unpleasant it would be). >> >> As I once wrote, anonymity should be the substrate. Once you have >> that, you can the build on it to be linked when you choose to be, and >> not linked when you choose not to be. If it is not the substrate, then >> you do not have this choice. >> >> >> >> > > Do you have example of what you describe? By that question I mean: implicit > anonymity as a functional substrate of some realm that we experience today? That's what selective disclosure systems like U-Prove and the PRIME project are all about. From Josh.Howlett@ja.net Thu Oct 18 09:08:44 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEB521F842D for ; Thu, 18 Oct 2012 09:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJcrwoUR0Mjb for ; Thu, 18 Oct 2012 09:08:43 -0700 (PDT) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8342B21F842F for ; Thu, 18 Oct 2012 09:08:37 -0700 (PDT) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 247D61A9C183_802984B; Thu, 18 Oct 2012 16:08:36 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id E8C641A9C17F_802983F; Thu, 18 Oct 2012 16:08:35 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.02.0247.003; Thu, 18 Oct 2012 17:08:35 +0100 From: Josh Howlett To: Ben Laurie , Henry Story Thread-Topic: [saag] Liking Linkability Thread-Index: AQHNpiCxfMrJ2+zuvUm2vI8PORxVbpe/Lv6AgAAaXwA= Date: Thu, 18 Oct 2012 16:08:34 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <1F64BC1CC84FF14CA28E462192F694E8@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Klaas Wierenga \(kwiereng\)" , "public-identity@w3.org" , "saag@ietf.org" , "public-privacy@w3.org" , "public-philoweb@w3.org" , "public-webid@w3.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 16:08:44 -0000 >As I once wrote, anonymity should be the substrate. Once you have >that, you can the build on it to be linked when you choose to be, and >not linked when you choose not to be. If it is not the substrate, then >you do not have this choice. +1 -- unlinked must be the default, with the option to link. Anything else is untenable. Josh. Janet is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From sm@resistor.net Thu Oct 18 10:02:49 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007F921F877D for ; Thu, 18 Oct 2012 10:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plPYev91h+JT for ; Thu, 18 Oct 2012 10:02:48 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3290421F875C for ; Thu, 18 Oct 2012 10:02:48 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q9IH2InO004725; Thu, 18 Oct 2012 10:02:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1350579743; bh=Wth8x54pHCQesSBuyX53TVsNaQSQkTDmyBhRGf36840=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=cKxVwrnENjNr/XpS4KPTkFyPca1VaFDlHvyVHI598ZEs8v4xM/32ds3vMYkS3S9H3 CeV2ZaGxbVahI0Pb51GUCNFJ1zUb/nvyfo1sk11vc93tN+O2MY0CiYnHNfBy+jJ2Ea ZhTOB51TNfwfipTe37UeO9ii+WrHbwBoHln/kAYY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1350579743; i=@resistor.net; bh=Wth8x54pHCQesSBuyX53TVsNaQSQkTDmyBhRGf36840=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=eLl7o+I8eqjdkI5fko3VtDxbhLTBX3Es3Z16k0FtLyrl9x+J2DnxHiWP/WRZT8Mzt 4JFILbVrVBuLnOTkSR6VzxpJnXejR9/pCpaWE0yL5/aWKrBkd3D6Odca3XDWmuT431 bCOSo0eosDdJYN08dEs9GqVqzsa7GQR0uXmIyIPc= Message-Id: <6.2.5.6.2.20121018092011.0ab6fed0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 18 Oct 2012 09:37:35 -0700 To: Willy Tarreau From: SM In-Reply-To: <20121018064805.GI7517@1wt.eu> References: <20121018064805.GI7517@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: saag@ietf.org Subject: Re: [saag] Input for conflict review of draft-secure-cookie-session-protocol X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 17:02:49 -0000 Hi Willy, At 23:48 17-10-2012, Willy Tarreau wrote: >Hence, I'm failing to see what specific use case this protocol covers, >however I see a risk that it is adopted by users who don't completely >understand its security implications. The focus is clearly set on how >the cookie contents are secured but not that much on what it should or >should not be used for. The draft is supposed to be published through in the Independent Submissions stream. What that means is that the document won't be an IETF specification or IETF "standard". The question was whether the document conflicts with existing IETF work as the publication of the document as a RFC might be blocked or a note might be added to it. A conflict review does not get into whether a protocol is "good" or "bad". It may be better to send the above comment to draft-secure-cookie-session-protocol.all@tools.ietf.org Regards, -sm From barryleiba.mailing.lists@gmail.com Thu Oct 18 10:03:04 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF66A21F8790 for ; Thu, 18 Oct 2012 10:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.089 X-Spam-Level: X-Spam-Status: No, score=-103.089 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpoEKb-Au9Sn for ; Thu, 18 Oct 2012 10:03:04 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id D7EF521F8794 for ; Thu, 18 Oct 2012 10:03:03 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so6816220lbo.31 for ; Thu, 18 Oct 2012 10:03:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=2YLeoariAfNvZWfuY6KvoanoEq8nHvnSQO5Zmz2CVTE=; b=OA3ztnOx/AXVWb8SEyroD4IByKF9mRsCmTZLS6AQpuAFA3jCQ/tCb4xbGm8b7bgdxP de0SckwK5hYG4dIRksC+WxXEyZxKmYlkmAWZCIY6Et7Ty0XxsG1YWHuuFp5wBEMw95ep ZhU/FuutRCxMlH4DUXhpH28W3EGpoQSUI8gnOvHux1G3pNhjVlgLfZvx2ygpj28WjFDF Kb3ZmA3BOG9S3y2FdM9KhzeY4RRsM61kCNAM1VU3iEY7PxPhU3Bq6wSorDwr+2uZdyVI hAenqbOFnJkqXGaUymwa5fiUrKgvfehJKpzwkw6Qvp6nYn7yKf/Kimef1MYxr1gcQgHh DIUw== MIME-Version: 1.0 Received: by 10.152.162.97 with SMTP id xz1mr19052522lab.38.1350579782824; Thu, 18 Oct 2012 10:03:02 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.150.194 with HTTP; Thu, 18 Oct 2012 10:03:02 -0700 (PDT) In-Reply-To: <20121018064805.GI7517@1wt.eu> References: <20121018064805.GI7517@1wt.eu> Date: Thu, 18 Oct 2012 13:03:02 -0400 X-Google-Sender-Auth: yo9W52JzXmbaazpouXP0MRefhWk Message-ID: From: Barry Leiba To: Willy Tarreau Content-Type: text/plain; charset=ISO-8859-1 Cc: saag@ietf.org Subject: Re: [saag] Input for conflict review of draft-secure-cookie-session-protocol X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 17:03:04 -0000 > I just checked the following document and have one main concern : ... > Hence, I'm failing to see what specific use case this protocol covers, > however I see a risk that it is adopted by users who don't completely > understand its security implications. Willy, did you read my note carefully? In particular: > Please read RFC 5742, Section 3, and be aware that we are not looking > for detailed comments on the document itself (see below). We > specifically need input on whether this document is in conflict with > work that's being done in the IETF. Look at the five possible > responses specified in that section, and help us determine whether any > of 2 through 5 applies. Please be specific in your response. Your response is not related to whether this conflicts with existing IETF work, but is addressing issues in the document. You need to take these up with the authors and the Independent Stream Editor. Again from my note: > In addition to this, we're sure that the authors and the ISE would > appreciate comments about the document. If you have those, you may > send them directly to the authors at > > and to the ISE at . > General discussion of the document on these lists or the saag list will > likely not get to the authors or the ISE. Barry From barryleiba@gmail.com Thu Oct 18 10:22:39 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6490721F876A for ; Thu, 18 Oct 2012 10:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.088 X-Spam-Level: X-Spam-Status: No, score=-103.088 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQLjALjQxawh for ; Thu, 18 Oct 2012 10:22:39 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id BC62F21F875C for ; Thu, 18 Oct 2012 10:22:38 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so10695001oag.31 for ; Thu, 18 Oct 2012 10:22:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Wz6oN2d+MOrYt9NI95j434wvQYgXQvnjn3DQEvcP9PY=; b=vHDTQDJzP4uv8MSYRAA/NOfZnsmkEQHQsr6UbON8DO8a8NnoIu3JuniRTRkVlXyIa7 QecwEtLOFxa+oFoKIrG3VRYInPE424yftmzzosv9WhORiNGdsOGZCDJ5co1kbXFNtQFJ kcsvW5yHgLUIG/CtwXHpAPcTaXlM2hUGWwTa+0MtrzK5mA+7cNKMskuBAvWMwQDSBmtO bYAJzWd4buxxRsdfDrmWDQjZwEy4uktDVPxW6lpD73g/Tg+JuqeGLjWODyijFqbT9KyP 3yuxRn0EAP5AbLNSXGZ84dc7zx3UErUxPduu8K3fVNMEq5Y6M63ntdNNgaNr0VexwGoH kuow== MIME-Version: 1.0 Received: by 10.182.145.9 with SMTP id sq9mr17991519obb.42.1350580958429; Thu, 18 Oct 2012 10:22:38 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.76.82.5 with HTTP; Thu, 18 Oct 2012 10:22:38 -0700 (PDT) In-Reply-To: <20121018171129.GO9392@1wt.eu> References: <20121018064805.GI7517@1wt.eu> <20121018171129.GO9392@1wt.eu> Date: Thu, 18 Oct 2012 13:22:38 -0400 X-Google-Sender-Auth: mw-TNYX936nGMFffVBIebyjqxq4 Message-ID: From: Barry Leiba To: Willy Tarreau Content-Type: text/plain; charset=ISO-8859-1 Cc: saag@ietf.org Subject: Re: [saag] Input for conflict review of draft-secure-cookie-session-protocol X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 17:22:39 -0000 > Well, maybe it's a matter of point of view. Adam took great care to > rework the cookie spec and achieve RFC6265 with a number of usage > recommendations to use cookies in the safest way. Since this draft > suggests a usage which seems totally insecure to me, I found it > appropriate to raise it as conflicting with the intended use of > cookies. Maybe I was wrong, and if so please accept my apologises. > Then it's unclear to me what kind of conflict should be raised :-/ True, and it's sometimes unclear to us as well. I'll see your :-/ and raise you a :-( What we're looking for is this sort of thing: - Is this document in direct conflict with current work in a working group? Which one(s)? - Should this be handled by an existing working group? Which one? - Should a new working group be chartered for this, rather than doing it as an Independent Submission? - Does it appear that the authors are trying to get around the system by submitting this to the ISE? - Is this spec proposing something sufficiently harmful that it needs proper IETF review to fix it? I suppose your comments could be arguing for that last one. But look at the list in RFC 5742, Section 3, and comment here on which of the five responses you think applies to this document. And then definitely give your other feedback on the document to the ISE and the document authors. Thanks, Willy. Barry From hartmans@mit.edu Thu Oct 18 11:51:16 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5092F21F84B6 for ; Thu, 18 Oct 2012 11:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.712 X-Spam-Level: X-Spam-Status: No, score=-95.712 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bo1qF3V0VkLB for ; Thu, 18 Oct 2012 11:51:15 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id D3EC621F84B5 for ; Thu, 18 Oct 2012 11:51:15 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (unknown [23.30.188.246]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id D75E220115; Thu, 18 Oct 2012 14:41:32 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9D70A4AD5; Thu, 18 Oct 2012 14:41:47 -0400 (EDT) From: Sam Hartman To: Josh Howlett References: Date: Thu, 18 Oct 2012 14:41:47 -0400 In-Reply-To: (Josh Howlett's message of "Thu, 18 Oct 2012 16:08:34 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Klaas Wierenga \(kwiereng\)" , "public-identity@w3.org" , "saag@ietf.org" , "public-privacy@w3.org" , "public-philoweb@w3.org" , "public-webid@w3.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 18:51:16 -0000 >>>>> "Josh" == Josh Howlett writes: >> As I once wrote, anonymity should be the substrate. Once you have >> that, you can the build on it to be linked when you choose to be, >> and not linked when you choose not to be. If it is not the >> substrate, then you do not have this choice. Josh> +1 -- unlinked must be the default, with the option to Josh> link. Anything else is untenable. Josh> Josh. If you're looking for real unlinkability, that implies no fingerprinting. Unfortunately, that rules out a lot of things we generally think of as good design practices. It tends to rule out future extensibility, configuration option that can be remotely observed, and implementation flexibility that can be remotely observed. Unfortunately, I think that's too high of a price to pay for unlinkability. So I've come to the conclusion that anonymity will depend on protocols like TOR specifically designed for it. If you're talking about some weak form of anonymity/unlinkability that does not involve forbidding fingerprinting, I'd like to better understand what you mean by unlinkability and what the expected advantages of this system are. Then we can evaluate whether it achieves them. From mouse@Sparkle.Rodents-Montreal.ORG Thu Oct 18 12:04:50 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6BEC21F852A for ; Thu, 18 Oct 2012 12:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.988 X-Spam-Level: X-Spam-Status: No, score=-9.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0siVT4s8SwVs for ; Thu, 18 Oct 2012 12:04:50 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id E6E4D21F854F for ; Thu, 18 Oct 2012 12:04:49 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id PAA07773; Thu, 18 Oct 2012 15:04:25 -0400 (EDT) Date: Thu, 18 Oct 2012 15:04:25 -0400 (EDT) From: Mouse Message-Id: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Thu, 18 Oct 2012 14:54:36 -0400 (EDT) To: Sam Hartman , "public-identity@w3.org" , "saag@ietf.org" , "public-privacy@w3.org" , "public-philoweb@w3.org" , "public-webid@w3.org" In-Reply-To: References: Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 19:04:50 -0000 > [...] > Unfortunately, I think that's too high of a price to pay for > unlinkability. > So I've come to the conclusion that anonymity will depend on > protocols like TOR specifically designed for it. Is it my imagination, or is this stuff confusing anonymity with pseudonymity? I feel reasonably sure I've missed some of the thread, but what I have seem does seem to be confusing the two. This whole thing about linking, for example, seems to be based on linking identities of some sort, implying that the systems in question *have* identities, in which case they are (at best) pseudonymous, not anonymous. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From henry.story@bblfish.net Thu Oct 18 12:20:18 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C05D721F86F3 for ; Thu, 18 Oct 2012 12:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkFcpZIKgXqS for ; Thu, 18 Oct 2012 12:20:17 -0700 (PDT) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id B6E9921F845D for ; Thu, 18 Oct 2012 12:20:16 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id k13so2495177eaa.31 for ; Thu, 18 Oct 2012 12:20:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=ysAXMD9Kx2SEboz/i0LLBpHctinCg6eh6RWtVHQkW9M=; b=ZJSzhqcp/d9ijo/nfv9VuChceAS1yCiGwjkvyb5i3EBV2kcZV0Q39HoOwi/jMhlm+W kN1ePLQwmDcN/ARExJBDqJEnCrSmVnALwhW9dKMlJXS7Lso5xu9ZqI1YtzIRXYw8jtWV 7+DuAVtUBjU/rVFmNwLfKsUIn+Gz0tMQukA4MpjqO1nKgss0dFJpycFUXhsDwbBrG7Hr EobRhvdzullIn4BxGcImrGvFYQFsX/Q5KHBemIbBSRhXeEz32j8lbnPfaNVEu6z0gGSQ ZiPQpe/KzH+NMKTDHe4namOGLkuAFuW4Janx4vcMFKPpZwaqQTj3nrTc5avfS4i0zHzF yyWg== Received: by 10.14.194.72 with SMTP id l48mr33565558een.9.1350588015795; Thu, 18 Oct 2012 12:20:15 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-132-122.w86-198.abo.wanadoo.fr. [86.198.99.122]) by mx.google.com with ESMTPS id c6sm41447273eep.17.2012.10.18.12.20.11 (version=SSLv3 cipher=OTHER); Thu, 18 Oct 2012 12:20:13 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_6C2CB0E3-8C40-4BA7-9F6B-636E922ECD20"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Henry Story In-Reply-To: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> Date: Thu, 18 Oct 2012 21:20:09 +0200 Message-Id: References: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> To: Mouse X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkR9nZJTcMLEv559L33WJz0OdLpyNXw1KB/e+YdseHM7CVWN7+KGeobyHwjFwLb9PaULA3Z Cc: "public-philoweb@w3.org" , "public-identity@w3.org" , "saag@ietf.org" , "public-privacy@w3.org" , Sam Hartman , "public-webid@w3.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 19:20:19 -0000 --Apple-Mail=_6C2CB0E3-8C40-4BA7-9F6B-636E922ECD20 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 18 Oct 2012, at 21:04, Mouse wrote: >> [...] >> Unfortunately, I think that's too high of a price to pay for >> unlinkability. >> So I've come to the conclusion that anonymity will depend on >> protocols like TOR specifically designed for it. > > Is it my imagination, or is this stuff confusing anonymity with > pseudonymity? I feel reasonably sure I've missed some of the thread, > but what I have seem does seem to be confusing the two. > > This whole thing about linking, for example, seems to be based on > linking identities of some sort, implying that the systems in question > *have* identities, in which case they are (at best) pseudonymous, not > anonymous. With WebID ( http://webid.info/ ) you have a pseudonymous global identifier, that is tied to a document on the Web that need only reveal your public key. That WebID can then link to further information that is access controlled, so that only your friends would be able to see it. The first diagram in the spec shows this well http://webid.info/spec/#publishing-the-webid-profile-document If you put WebID behind TOR and only have .onion WebIDs - something that should be possible to do - then nobody would know WHERE the box hosting your profile is, so they would not be able to just find your home location from your ip-address. But you would still be able to link up in an access controlled manner to your friends ( who may or may not be serving their pages behind Tor ). You would then be unlinkable in the sense of http://tools.ietf.org/html/draft-iab-privacy-considerations-03 [[ Within a particular set of information, the inability of an observer or attacker to distinguish whether two items of interest are related or not (with a high enough degree of probability to be useful to the observer or attacker). ]] from any person that was not able to access the resources. But you would be linkable by your friends. I think you want both. Linkability by those authorized, unlinkability for those unauthorized. Hence linkability is not just a negative. Henry > > /~\ The ASCII Mouse > \ / Ribbon Campaign > X Against HTML mouse@rodents-montreal.org > / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag Social Web Architect http://bblfish.net/ --Apple-Mail=_6C2CB0E3-8C40-4BA7-9F6B-636E922ECD20 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPDTCCByMw ggYLoAMCAQICAwTQYzANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEyMDgyOTAxNDU1NloXDTEzMDgzMDA5MjM0MFowZTEZMBcGA1UEDRMQazQ2eDlvOXJDRE5m VzMwYzEgMB4GA1UEAwwXaGVucnkuc3RvcnlAYmJsZmlzaC5uZXQxJjAkBgkqhkiG9w0BCQEWF2hl bnJ5LnN0b3J5QGJibGZpc2gubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArHXp EmiifOSpudkJn1vAnFdZsuaLuYYLbdWL47o1rKD/kg8/RJUmTIM2ara4e/MOxR16mu2fyAca3H1U oIXNNXDbYQDu2PkfLoNSM5JGAoYbfB0nXBK//ZecidVMZ8eExd02/vFzo5vj9kQNaAPSYirid5xe 1cV9Y1RFjlEozuYAUhU8zi3taf22JM45ii2YrCEgVjDdez8yio0QoJeKEEL3JhL4tqpkbfIOHmdi HYx00S6YcCogDfxXc3zOJ3jcIj/F61eXG1qWX/lq9RAyoBjYHLWE2iHQPwdzum03ubcvOTlohqOR +/cVzvx10l6bJ46KitfbydXMh8HoY7QcmwIDAQABo4IDsjCCA64wCQYDVR0TBAIwADALBgNVHQ8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQRbT9qwRblII9x nAN2FlEMUD1LQzAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAiBgNVHREEGzAZgRdo ZW5yeS5zdG9yeUBiYmxmaXNoLm5ldDCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIw ggH/MC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsG AQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEF BQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9u IHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZv ciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5 IG9ibGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBTZWUg c2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5 LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3Js MIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20v c3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29t L2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALj/A19bRLmI7sMf0lVRrdN23NuRC7/UFSLZ DfcxrR1wOtQgAbrFlFLY+Otn6UWYIiWQpv2v5Ploqw9rMam5W8seC3TUt83StohXCmZ0EDmK87If B6kpd7FwJ0RFGCxn22hPU2kuhp2mbjJzCTrd3jWsXw63MXDUzHuucWGX2mY1Ji+zRECh568N7iWA 5jn9kWT+h7o7ywKbHc4qAnksghLYAnTfoCx1IPkT4/8A5hf38imhf9NcNGibrvt/e49sacf6GjRH Ot/lOCrEX2fh2YvTB5sdEKM5tjKCKNpFSqnRCKhsWZ9N9ZP7mRZfCOBjAMsm3CW2ygwlWXc54lgf p1UwggfiMIIFyqADAgECAgENMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQy MTAxNTRaFw0xMjEwMjIyMTAxNTRaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP 6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu 2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyU GHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmt xWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMB AAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUU3Ltkpzg2ssB XHx+ljVO8tS4UYIwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0 YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHmCAQEwCQYDVR0SBAIwADA9BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYB BQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMw JxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmls aXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29t IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRD FkFTdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENl cnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAqprh4FuMzh0b/B3GLDAgoLeTJv3xArbNESi/ Kf/HMM//gf8FzwUUNOCglH6dfYuLQQ/dTtOyMb4JoiL3T7xiVKEAOmQ+t+b/xLOMa0m18zoRqW4k 6Glyoyvc7LMrdpgYk/lEh5nq8tPd9BoNmwiiheXphIVH/QelTgUkNzTC7IVpmYVsKuNOnxE1jJFZ NNfqZZK/5Oto7C6PfOut11KmBQSLZarAz0b/mjghdBsYfHuhdO8vrOvD0g5g7dA4pkOAU2Ed4pSC owBSItyD/5aFwZ75ji6Yq7GCG3BpiyAP9st8h+inc0L+7kmrAMJaLMAmu6GZs5Xgsbzn0wUJvbD9 h5jnnMM9UaZDcxl2uLB04quGUWM6NiKGabbxQc680PYbeQrQu+e6J4uqNAxzoa5RxkBA5a/3qlbg F9uJBekCqJswx5vQ9khJrs8UTMaIFzbEC5VGQziQH3/6KJ4DUP85OJEnCx/quShWA6w318LDnba3 M6a5V+KoNLhsVi/TSxf90UbBqwdRR/cOwuGkNJh16NvvhIqO26osMg64CbZsDVrEDr7uSMV40ieB JTo49Iyt77ECOhz/pyhowa2EUP6aKav+L/wXzAPB3LNqzujGR0K1pbyFWKvyYmdungJtySWUMw+R 5DqpA2bFIOE56pfWPLHZxOL+8+r79PLFX+y2V6ExggNvMIIDawIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRp ZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1l ZGlhdGUgQ2xpZW50IENBAgME0GMwCQYFKw4DAhoFAKCCAa8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMDE4MTkyMDEwWjAjBgkqhkiG9w0BCQQxFgQUIViZMHqD CWP2JalsKzJ1kwhoMzYwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgME0GMwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0ECAwTQYzANBgkqhkiG9w0BAQEFAASCAQA3aaGD09WRnXxvYCkz1VlDeTys1cwOL1wfzKDN qEVEhvudayMtOy4jXh+oL/TnOqYSuqQHkd3GsKdlezaT0H+nJb2iAxGkKEbrLjuCJhLHhiRvASym 9EG0CsvYtc4vGo4vTUN/e2GR10GGZ7hlDIX/IiEduVzIFlkhrCSJznIK0uyZJ9VeNHhXCguJQA4O f1jFl2LdgoM5kzZfMylM62IcZY3RFOhWj4lRajtb2y32xbwPG5Od042rwPV6uYd9IXQRyw/dnAmr DAyFtgfiGCOyMuCuO/svS80s/sCcoyFUadGO+1UDU4nBnY21vdkZVCJYJnVcK+Ap98tMf0iRewbY AAAAAAAA --Apple-Mail=_6C2CB0E3-8C40-4BA7-9F6B-636E922ECD20-- From benlaurie@gmail.com Thu Oct 18 12:29:39 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5BCB21F84DD for ; Thu, 18 Oct 2012 12:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKg9C2U1i762 for ; Thu, 18 Oct 2012 12:29:39 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 10A1321F84BE for ; Thu, 18 Oct 2012 12:29:38 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so10963778vcb.31 for ; Thu, 18 Oct 2012 12:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=2XDvH7GK8Z261iao6ozvQw9NVrTWFNCYXelomm+pJNc=; b=0xE9T8wikCDnHDlmyLMBTwHN0rSdeDWQ06XYmic3LfBwt4HVIGDxiTI1aZzDUXD3AF h1pZtoxNEuSP+9WRmCss4oUVY30YItR/tvXAHtvYqaow/TrzIEx5Uszqs4lEn8zHLnTU XAM0JmxsRkD1zElk9SRtIm0dQEanMbM3diYwsCBkZTLmZ/cUlWGdfBSSI/3bkGlzo4Qv pzAoe51cp4BTt6X2IQ5THuyy7R/JRjkYguZYdlpyTYDx2aADFetIsf+0ueyCDJzOIbML KK8zy51+4UBpG3qRn2Ml5UOR2UPyGIcGkiTXnui/cq5fFKmTjZvNefrpd1rxt9bRLqEa t1Gg== MIME-Version: 1.0 Received: by 10.52.33.130 with SMTP id r2mr13168338vdi.43.1350588577605; Thu, 18 Oct 2012 12:29:37 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.58.18.235 with HTTP; Thu, 18 Oct 2012 12:29:37 -0700 (PDT) In-Reply-To: References: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> Date: Thu, 18 Oct 2012 20:29:37 +0100 X-Google-Sender-Auth: sdY5WJUbQiqnfTlGZXDd8dcKofo Message-ID: From: Ben Laurie To: Henry Story Content-Type: text/plain; charset=ISO-8859-1 Cc: "public-philoweb@w3.org" , "public-identity@w3.org" , "public-privacy@w3.org" , Sam Hartman , "public-webid@w3.org" , "saag@ietf.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 19:29:40 -0000 On Thu, Oct 18, 2012 at 8:20 PM, Henry Story wrote: > > On 18 Oct 2012, at 21:04, Mouse wrote: > >>> [...] >>> Unfortunately, I think that's too high of a price to pay for >>> unlinkability. >>> So I've come to the conclusion that anonymity will depend on >>> protocols like TOR specifically designed for it. >> >> Is it my imagination, or is this stuff confusing anonymity with >> pseudonymity? I feel reasonably sure I've missed some of the thread, >> but what I have seem does seem to be confusing the two. >> >> This whole thing about linking, for example, seems to be based on >> linking identities of some sort, implying that the systems in question >> *have* identities, in which case they are (at best) pseudonymous, not >> anonymous. > > With WebID ( http://webid.info/ ) you have a pseudonymous global identifier, > that is tied to a document on the Web that need only reveal your public key. > That WebID can then link to further information that is access controlled, > so that only your friends would be able to see it. > > The first diagram in the spec shows this well > > http://webid.info/spec/#publishing-the-webid-profile-document > > If you put WebID behind TOR and only have .onion WebIDs - something that > should be possible to do - then nobody would know WHERE the box hosting your > profile is, so they would not be able to just find your home location > from your ip-address. But you would still be able to link up in an access > controlled manner to your friends ( who may or may not be serving their pages > behind Tor ). > > You would then be unlinkable in the sense of > http://tools.ietf.org/html/draft-iab-privacy-considerations-03 > > [[ > Within a particular set of information, the > inability of an observer or attacker to distinguish whether two > items of interest are related or not (with a high enough degree of > probability to be useful to the observer or attacker). > ]] > > from any person that was not able to access the resources. But you would > be linkable by your friends. I think you want both. Linkability by those > authorized, unlinkability for those unauthorized. Hence linkability is not > just a negative. I really feel like I am beating a dead horse at this point, but perhaps you'll eventually admit it. Your public key links you. Access control on the rest of the information is irrelevant. Indeed, access control on the public key is irrelevant, since you must reveal it when you use the client cert. Incidentally, to observers as well as the server you connect to. From tobias.gondrom@gondrom.org Thu Oct 18 13:37:37 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5741521F8434 for ; Thu, 18 Oct 2012 13:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.362 X-Spam-Level: X-Spam-Status: No, score=-95.362 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfasivJr2a5t for ; Thu, 18 Oct 2012 13:37:36 -0700 (PDT) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2C39821F84F0 for ; Thu, 18 Oct 2012 13:37:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=YsUcgUmSIksh/7Ymp7Eh9fpxCxQz1J2F8T6KmPrfJWS9zt2Nb1ytlyUFg6VVr5dnvvqBURxR8O8TFrKcYJNlDq62K1yYbgcwdiuFmHBQ9K+rKpsXbrgq6XLdsyTUC78F; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 1269 invoked from network); 18 Oct 2012 22:37:34 +0200 Received: from 188-223-113-88.zone14.bethere.co.uk (HELO ?192.168.1.65?) (188.223.113.88) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 18 Oct 2012 22:37:34 +0200 Message-ID: <5080688D.4090802@gondrom.org> Date: Thu, 18 Oct 2012 21:37:33 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: barryleiba@computer.org References: <20121018064805.GI7517@1wt.eu> <20121018171129.GO9392@1wt.eu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: w@1wt.eu, saag@ietf.org Subject: Re: [saag] Input for conflict review of draft-secure-cookie-session-protocol X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 20:37:37 -0000 Hello, after a brief review of the draft, I got quite a bit of headache with this draft. Answers inline. Tobias On 18/10/12 18:22, Barry Leiba wrote: >> Well, maybe it's a matter of point of view. Adam took great care to >> rework the cookie spec and achieve RFC6265 with a number of usage >> recommendations to use cookies in the safest way. Since this draft >> suggests a usage which seems totally insecure to me, I found it >> appropriate to raise it as conflicting with the intended use of >> cookies. Maybe I was wrong, and if so please accept my apologises. >> Then it's unclear to me what kind of conflict should be raised :-/ > True, and it's sometimes unclear to us as well. I'll see your :-/ and > raise you a :-( > > What we're looking for is this sort of thing: > - Is this document in direct conflict with current work in a working > group? Which one(s)? Not to my knowledge. (talking about websec) But it may be in conflict with use cases for cookies. > - Should this be handled by an existing working group? Which one? Yes. IMHO this is actually very dangerous stuff. The implied use case/proposal is to not store state on a server at all and store and trust it on the client only, which would be a major paradigm shift. And actually would go against many security recommendations I have given and received in the past. > - Should a new working group be chartered for this, rather than doing > it as an Independent Submission? No. No new WG, but I think we should try to fit it into one of the existing working groups. > - Does it appear that the authors are trying to get around the system > by submitting this to the ISE? > - Is this spec proposing something sufficiently harmful that it needs > proper IETF review to fix it? Yes. As explained above: In my view this can be playing with fire. I believe such a paradigm deserves (and needs) IETF review. > > I suppose your comments could be arguing for that last one. > > But look at the list in RFC 5742, Section 3, and comment here on which > of the five responses you think applies to this document. And then > definitely give your other feedback on the document to the ISE and the > document authors. > > Thanks, Willy. > > Barry > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From benl@google.com Fri Oct 19 04:21:50 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A28221F8532 for ; Fri, 19 Oct 2012 04:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4tQMXbPVP8P for ; Fri, 19 Oct 2012 04:21:49 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 41F9F21F846F for ; Fri, 19 Oct 2012 04:21:49 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so223300wey.31 for ; Fri, 19 Oct 2012 04:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=jzuSGLhgrPRyVoanRI3/AVjVPiaISms9g/EGnO22mi8=; b=hW+/zrPAwq9dlTTG6ULuYAgdfWOeh9+nT/fYYgx5w2EmuJ6ScsdiW4238Mcyh1UDLd 3a7qJEhwMpr/l7ZzKbU+1EyqQaAGwDvuhiv28KWWRnMWbsnfSmp09BViLHKC4rPAYM6e kV7dpq9HDaRayYJGMpJdYROQ5PimckuEIfwp8owG/cyUmfm8fOJ5quWg/9l/IYnJdGeb XG0BiBHKsCUlV0oqmR0REeDI+NZfDr/zKBGFkflzy3AXD94L9J2+qn5cEGZaGe2OE0qu tz7RNEYHIR8lakR25zenkwz+YPrzMwzmVI8puIoTD7Q1fcwapOgEQGYmOQ5Gr/9vQmvt 9irA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=jzuSGLhgrPRyVoanRI3/AVjVPiaISms9g/EGnO22mi8=; b=RSxsgVYj+YbHgfa2/fFKiFW/7ktuf5mRUpNjQHwKKIhYLH09ciwaS/B7Uxo85YiDWB bOgAN0Tit6Q/GpStxYCv5lsNUEnbK5JWnS5qgUr7sK3tACJH54x2kywM+Ov8A32BTprg VHG0xxzHoLcTudY81fGYgEvqnRHRlVYiEohJfKJ+34D2I5sPxtIaubGwy+TyXpJylJvg tZmx+xR3aVcnBe2yH0BUK7ileU+GMTZlViW6aZsKYL64EzAs6pcpg/PpwxUoM4cXwb8e FyZEEVVKzUpNAcbdC1JPicomVkevR86obuchyY7gb5Mw2lGzHc0/8AtEPmcCOChldUiI nz6A== MIME-Version: 1.0 Received: by 10.216.131.161 with SMTP id m33mr657098wei.13.1350645707821; Fri, 19 Oct 2012 04:21:47 -0700 (PDT) Received: by 10.216.236.201 with HTTP; Fri, 19 Oct 2012 04:21:47 -0700 (PDT) In-Reply-To: <508033C3.1010205@openlinksw.com> References: <88F98DFD-EF7D-4444-A9C2-FB8E15F5DA89@bblfish.net> <3757D928-C3AE-4630-98E7-E30B5CC604B0@cisco.com> <7E1636E02F313F4BA69A428B314B77C708217189@xmb-aln-x12.cisco.com> <7ABCD095-4B09-40DD-A084-1BBE761CA72F@bblfish.net> <50802328.70205@openlinksw.com> <508033C3.1010205@openlinksw.com> Date: Fri, 19 Oct 2012 12:21:47 +0100 Message-ID: From: Ben Laurie To: Kingsley Idehen Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQlxC8b588d/u3D5rjPVes0WYMx/7SL/Tl4wEZ06w11zq8eJQijo8dSTJX9LVRd8rfjpYkGmEdXel58ecj8f+r99iQMQRV6G+tyB9k6aLHvN9qAcDy2lWJu8hiXmeaXa0AEe54hNfiGMFl6zBkMMDQE2NaWkJ0Tu59T6H1D4GZ0kX7XFdnO0lWGSgViub6GI6vnFw82/ Cc: "public-philoweb@w3.org" , "public-identity@w3.org" , "saag@ietf.org" , "public-privacy@w3.org" , "Klaas Wierenga \(kwiereng\)" , "public-webid@w3.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 11:21:50 -0000 On 18 October 2012 17:52, Kingsley Idehen wrote: > On 10/18/12 12:06 PM, Ben Laurie wrote: >> >> On 18 October 2012 16:41, Kingsley Idehen wrote= : >>> >>> On 10/18/12 11:34 AM, Ben Laurie wrote: >>>> >>>> On 9 October 2012 14:19, Henry Story wrote: >>>>> >>>>> Still in my conversations I have found that many people in security >>>>> spaces >>>>> just don't seem to be able to put the issues in context, and can get >>>>> sidetracked >>>>> into not wanting any linkability at all. Not sure how to fix that. >>>> >>>> You persist in missing the point, which is why you can't fix it. The >>>> point is that we want unlinkability to be possible. Protocols that do >>>> not permit it or make it difficult are problematic. I have certainly >>>> never said that you should always be unlinked, that would be stupid >>>> (in fact, I once wrote a paper about how unpleasant it would be). >>>> >>>> As I once wrote, anonymity should be the substrate. Once you have >>>> that, you can the build on it to be linked when you choose to be, and >>>> not linked when you choose not to be. If it is not the substrate, then >>>> you do not have this choice. >>>> >>>> >>>> >>>> >>> Do you have example of what you describe? By that question I mean: >>> implicit >>> anonymity as a functional substrate of some realm that we experience >>> today? >> >> That's what selective disclosure systems like U-Prove and the PRIME >> project are all about. >> >> >> > Ben, > > How is the following incongruent with the fundamental points we've been > trying to make about the combined effects of URIs, Linked Data, and Logic= en > route to controlling privacy at Web-scale? > > Excerpt from Microsoft page [1]: > > A U-Prove token is a new type of credential similar to a PKI certificate > that can encode attributes of any type, but with two important difference= s: > > 1) The issuance and presentation of a token is unlinkable due to the spec= ial > type of public key and signature encoded in the token; the cryptographic > =93wrapping=94 of the attributes contain no correlation handles. This pre= vents > unwanted tracking of users when they use their U-Prove tokens, even by > colluding insiders. > > 2) Users can minimally disclose information about what attributes are > encoded in a token in response to dynamic verifier policies. As an exampl= e, > a user may choose to only disclose a subset of the encoded attributes, pr= ove > that her undisclosed name does not appear on a blacklist, or prove that s= he > is of age without disclosing her actual birthdate. > > > Why are you assuming that a hyperlink based pointer (de-referencable URI) > placed in the SAN of minimalist X.509 certificate (i.e., one that has now > personally identifiable information) can't deliver the above and more? Because it contains "correlation handles" to use the terminology of the quo= te. > Please note, WebID is a piece of the picture. Linked Data, Entity > Relationship Semantics and Logic are other critical parts. That's why the= re > isn't a golden ontology for resource access policies, the resource publis= her > can construct a plethora of resource access policies en route to leveragi= ng > the power of machine discernible entity relationship semantics and > first-order logic. > > In a most basic super paranoid scenario, if I want to constrain access to= a > resource to nebulous entity "You" I would share a PKCS#12 document with t= hat > entity. I would also have an access policy in place based on the data in > said document. I would also call "You" by phone to give you the password = of > that PKCS#12 document. Once that's all sorted, you can open the document, > get your crytpo data installed in your local keystore and then visit the > resource I've published :-) > > Links: > > 1. http://research.microsoft.com/en-us/projects/u-prove/ > 2. http://en.wikipedia.org/wiki/Zero-knowledge_proof -- I don't see anyth= ing > about that being incompatible with what the combined use of de-referencab= le > URIs based names, Linked Data, Entity Relationship Semantics, Reasoning, = and > existing PKI deliver. > > > -- > > Regards, > > Kingsley Idehen > Founder & CEO > OpenLink Software > Company Web: http://www.openlinksw.com > Personal Weblog: http://www.openlinksw.com/blog/~kidehen > Twitter/Identi.ca handle: @kidehen > Google+ Profile: https://plus.google.com/112399767740508618350/about > LinkedIn Profile: http://www.linkedin.com/in/kidehen > > > > > From henry.story@bblfish.net Fri Oct 19 05:01:11 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4029F21F86AB for ; Fri, 19 Oct 2012 05:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVyJToLAkVZb for ; Fri, 19 Oct 2012 05:01:10 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id CF9E521F8630 for ; Fri, 19 Oct 2012 05:01:09 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so195082eek.31 for ; Fri, 19 Oct 2012 05:01:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=/ChK0EXlHCHYrqfeWvOFvFhksmWKWfn5ecNaME/p+7U=; b=QTdsKGvbYQFYxcHmiJDszfqztCPd4ec1jR8aPIADvv7GkiInr9gbnqjt1rB76e0kZA /2s0k+6ndVg8lVNPS6fwHuccm8sUQlDL2s0y0OYKRnEAKZslpWrngwsjuSlkfwrJeBdz sEYYB7rCi+H62sIvHasJVdH6gSidW225jls2cTPE2FUyQ/3rxPyJ/kYFpxae1Hc8Ydg3 3CN14m0OoU+kEt2nferoob8J/gD+Zqk+ooWOy4pxS9luTcFfQ4BW84WfDgVEthj3KufV pDGLaUtcsn+t4tT8kNMZbB/xj0WDxby2wLKyab3SDs/SsjyBL/nUzq0aS9hCaG9GbzfO i2Qw== Received: by 10.14.172.195 with SMTP id t43mr1470895eel.17.1350648068668; Fri, 19 Oct 2012 05:01:08 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-132-122.w86-198.abo.wanadoo.fr. [86.198.99.122]) by mx.google.com with ESMTPS id z43sm2254188een.16.2012.10.19.05.01.05 (version=SSLv3 cipher=OTHER); Fri, 19 Oct 2012 05:01:06 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_0CC5E56D-9FF2-4E11-A5C2-4C08E3DC6E99"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Henry Story In-Reply-To: Date: Fri, 19 Oct 2012 14:01:04 +0200 Message-Id: <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> References: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> To: Ben Laurie X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlYZdHgtq+nkoqJRMXltj37JJsAt7799pNIcCOmickpkwFRLofbX6oUQIFuO9NIqUUCmiGR Cc: "public-philoweb@w3.org" , "public-identity@w3.org" , "public-privacy@w3.org" , Sam Hartman , "public-webid@w3.org" , "saag@ietf.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 12:01:11 -0000 --Apple-Mail=_0CC5E56D-9FF2-4E11-A5C2-4C08E3DC6E99 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 18 Oct 2012, at 21:29, Ben Laurie wrote: > On Thu, Oct 18, 2012 at 8:20 PM, Henry Story = wrote: >>=20 >> On 18 Oct 2012, at 21:04, Mouse wrote: >>=20 >>>> [...] >>>> Unfortunately, I think that's too high of a price to pay for >>>> unlinkability. >>>> So I've come to the conclusion that anonymity will depend on >>>> protocols like TOR specifically designed for it. >>>=20 >>> Is it my imagination, or is this stuff confusing anonymity with >>> pseudonymity? I feel reasonably sure I've missed some of the = thread, >>> but what I have seem does seem to be confusing the two. >>>=20 >>> This whole thing about linking, for example, seems to be based on >>> linking identities of some sort, implying that the systems in = question >>> *have* identities, in which case they are (at best) pseudonymous, = not >>> anonymous. >>=20 >> With WebID ( http://webid.info/ ) you have a pseudonymous global = identifier, >> that is tied to a document on the Web that need only reveal your = public key. >> That WebID can then link to further information that is access = controlled, >> so that only your friends would be able to see it. >>=20 >> The first diagram in the spec shows this well >>=20 >> http://webid.info/spec/#publishing-the-webid-profile-document >>=20 >> If you put WebID behind TOR and only have .onion WebIDs - something = that >> should be possible to do - then nobody would know WHERE the box = hosting your >> profile is, so they would not be able to just find your home location >> from your ip-address. But you would still be able to link up in an = access >> controlled manner to your friends ( who may or may not be serving = their pages >> behind Tor ). >>=20 >> You would then be unlinkable in the sense of >> http://tools.ietf.org/html/draft-iab-privacy-considerations-03 >>=20 >> [[ >> Within a particular set of information, the >> inability of an observer or attacker to distinguish whether two >> items of interest are related or not (with a high enough degree = of >> probability to be useful to the observer or attacker). >> ]] >>=20 >> from any person that was not able to access the resources. But you = would >> be linkable by your friends. I think you want both. Linkability by = those >> authorized, unlinkability for those unauthorized. Hence linkability = is not >> just a negative. >=20 > I really feel like I am beating a dead horse at this point, but > perhaps you'll eventually admit it. Your public key links you. The question is to whom? What is the scenario you are imagining, and who = is the attacker there? > Access > control on the rest of the information is irrelevant. Indeed, access > control on the public key is irrelevant, since you must reveal it when > you use the client cert. You are imagining that the server I am connecting to, and that I have decided to identify myself to, is the one that is attacking me? Right? Because otherwise I cannot understand your issue.=20 But then I still do not understand your issue, since I deliberately did connect to that site in an identifiable manner with a global id. I could have created a locally valid ID only, had I wanted to not=20 connect with a globally valid one. So your issue boils down to this: if I connect to a web site = deliberately with a global identifier, then I am globally identified by that web = site. Which is what I wanted. So perhaps it is up to you to answer: why should I not want that?=20 > Incidentally, to observers as well as the > server you connect to. Not when you re-negotiation I think.=20 And certainly not if you use Tor, right? Social Web Architect http://bblfish.net/ --Apple-Mail=_0CC5E56D-9FF2-4E11-A5C2-4C08E3DC6E99 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPDTCCByMw ggYLoAMCAQICAwTQYzANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEyMDgyOTAxNDU1NloXDTEzMDgzMDA5MjM0MFowZTEZMBcGA1UEDRMQazQ2eDlvOXJDRE5m VzMwYzEgMB4GA1UEAwwXaGVucnkuc3RvcnlAYmJsZmlzaC5uZXQxJjAkBgkqhkiG9w0BCQEWF2hl bnJ5LnN0b3J5QGJibGZpc2gubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArHXp EmiifOSpudkJn1vAnFdZsuaLuYYLbdWL47o1rKD/kg8/RJUmTIM2ara4e/MOxR16mu2fyAca3H1U oIXNNXDbYQDu2PkfLoNSM5JGAoYbfB0nXBK//ZecidVMZ8eExd02/vFzo5vj9kQNaAPSYirid5xe 1cV9Y1RFjlEozuYAUhU8zi3taf22JM45ii2YrCEgVjDdez8yio0QoJeKEEL3JhL4tqpkbfIOHmdi HYx00S6YcCogDfxXc3zOJ3jcIj/F61eXG1qWX/lq9RAyoBjYHLWE2iHQPwdzum03ubcvOTlohqOR +/cVzvx10l6bJ46KitfbydXMh8HoY7QcmwIDAQABo4IDsjCCA64wCQYDVR0TBAIwADALBgNVHQ8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQRbT9qwRblII9x nAN2FlEMUD1LQzAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAiBgNVHREEGzAZgRdo ZW5yeS5zdG9yeUBiYmxmaXNoLm5ldDCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIw ggH/MC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsG AQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEF BQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9u IHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZv ciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5 IG9ibGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBTZWUg c2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5 LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3Js MIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20v c3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29t L2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALj/A19bRLmI7sMf0lVRrdN23NuRC7/UFSLZ DfcxrR1wOtQgAbrFlFLY+Otn6UWYIiWQpv2v5Ploqw9rMam5W8seC3TUt83StohXCmZ0EDmK87If B6kpd7FwJ0RFGCxn22hPU2kuhp2mbjJzCTrd3jWsXw63MXDUzHuucWGX2mY1Ji+zRECh568N7iWA 5jn9kWT+h7o7ywKbHc4qAnksghLYAnTfoCx1IPkT4/8A5hf38imhf9NcNGibrvt/e49sacf6GjRH Ot/lOCrEX2fh2YvTB5sdEKM5tjKCKNpFSqnRCKhsWZ9N9ZP7mRZfCOBjAMsm3CW2ygwlWXc54lgf p1UwggfiMIIFyqADAgECAgENMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQy MTAxNTRaFw0xMjEwMjIyMTAxNTRaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP 6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu 2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyU GHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmt xWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMB AAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUU3Ltkpzg2ssB XHx+ljVO8tS4UYIwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0 YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHmCAQEwCQYDVR0SBAIwADA9BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYB BQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMw JxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmls aXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29t IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRD FkFTdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENl cnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAqprh4FuMzh0b/B3GLDAgoLeTJv3xArbNESi/ Kf/HMM//gf8FzwUUNOCglH6dfYuLQQ/dTtOyMb4JoiL3T7xiVKEAOmQ+t+b/xLOMa0m18zoRqW4k 6Glyoyvc7LMrdpgYk/lEh5nq8tPd9BoNmwiiheXphIVH/QelTgUkNzTC7IVpmYVsKuNOnxE1jJFZ NNfqZZK/5Oto7C6PfOut11KmBQSLZarAz0b/mjghdBsYfHuhdO8vrOvD0g5g7dA4pkOAU2Ed4pSC owBSItyD/5aFwZ75ji6Yq7GCG3BpiyAP9st8h+inc0L+7kmrAMJaLMAmu6GZs5Xgsbzn0wUJvbD9 h5jnnMM9UaZDcxl2uLB04quGUWM6NiKGabbxQc680PYbeQrQu+e6J4uqNAxzoa5RxkBA5a/3qlbg F9uJBekCqJswx5vQ9khJrs8UTMaIFzbEC5VGQziQH3/6KJ4DUP85OJEnCx/quShWA6w318LDnba3 M6a5V+KoNLhsVi/TSxf90UbBqwdRR/cOwuGkNJh16NvvhIqO26osMg64CbZsDVrEDr7uSMV40ieB JTo49Iyt77ECOhz/pyhowa2EUP6aKav+L/wXzAPB3LNqzujGR0K1pbyFWKvyYmdungJtySWUMw+R 5DqpA2bFIOE56pfWPLHZxOL+8+r79PLFX+y2V6ExggNvMIIDawIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRp ZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1l ZGlhdGUgQ2xpZW50IENBAgME0GMwCQYFKw4DAhoFAKCCAa8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMDE5MTIwMTA0WjAjBgkqhkiG9w0BCQQxFgQUINq/3vCW /Q9A5nAUxm7gIWNP78MwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgME0GMwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0ECAwTQYzANBgkqhkiG9w0BAQEFAASCAQASzL20pc+kbIJzHZvoNfmgKPCxVW7mNNqVdYxT fX8vJWadwMoKdE5fO7PLUt1o5yYQ668OTuPOGvnrE3pWDYxxN2pi2bBrrSOdLaOz+jW2t0OzE/dT I0tWEMGxcO2Gy8TuBdYGNMVKC03+7Z80CeMz0O+7F/FEb8IzPnmozT7pGSO7Chg616vysGIbxwlf 7h7xUl7D7HrkgLxBswTX1GLEot0VsDzLBbm4ILwIWiQLt0ot+1QPXG83yVGoykRpVZs/BDbd6wGu ZbLVclC5t6R4QiGRVbcgM1IgmWQNLR5OhJkX8v1EHASeaFY4M7TtnTutpV7RuRMkVlA7f3Oozi0Z AAAAAAAA --Apple-Mail=_0CC5E56D-9FF2-4E11-A5C2-4C08E3DC6E99-- From henry.story@bblfish.net Fri Oct 19 06:14:09 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4993B21F85ED for ; Fri, 19 Oct 2012 06:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thkorMfzG9X0 for ; Fri, 19 Oct 2012 06:14:08 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id F2BAA21F85E7 for ; Fri, 19 Oct 2012 06:14:07 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so211469bkc.31 for ; Fri, 19 Oct 2012 06:14:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=RCIpokvPpEhkdcUQIu58aeYf1abo7JNtgh8575KZksI=; b=Q1kv4oGYf/gH60dIhinnMm8Q4bMT1yy0miy76FDNd8dH/07f2QfnXjzPbPeluwFEXv 4teLT9jUiLZtgsW+Wj+pJF/91SQ6nHq8xcn6d1gv6y1lq/LJl0RaXl5HManMIM+I+xkj /y3MZFVQ2Rbpz4b8x7DW+dC0GgJDk+qyemRynGU6AQKK7E2xkXT43+VG3Pym9xzxJyKw U3cULdtbxqU/wuXodhHC2TQmqkzv5QJQRn63Vrd3yn7eY0Uywpkc1wie0FvmWQahlDQJ hsNdpGpNWiJ3k+9FI89bC5S3WpYQyrFmBWknJC8uB+RwlkrpJGvl0ESYXfPWNfztghgn phYg== Received: by 10.204.147.82 with SMTP id k18mr428894bkv.48.1350652446922; Fri, 19 Oct 2012 06:14:06 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-132-122.w86-198.abo.wanadoo.fr. [86.198.99.122]) by mx.google.com with ESMTPS id k21sm1017675bkv.1.2012.10.19.06.13.43 (version=SSLv3 cipher=OTHER); Fri, 19 Oct 2012 06:13:54 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_C9B6A6A8-A076-472F-AEB4-1773D7392B5E"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Henry Story In-Reply-To: <546498C3-5D1F-484A-8BC6-17BB356B8DF7@cisco.com> Date: Fri, 19 Oct 2012 15:13:42 +0200 Message-Id: References: <88F98DFD-EF7D-4444-A9C2-FB8E15F5DA89@bblfish.net> <3757D928-C3AE-4630-98E7-E30B5CC604B0@cisco.com> <7E1636E02F313F4BA69A428B314B77C708217189@xmb-aln-x12.cisco.com> <7ABCD095-4B09-40DD-A084-1BBE761CA72F@bblfish.net> <50802328.70205@openlinksw.com> <508058EE.4020700@telia.com> <546498C3-5D1F-484A-8BC6-17BB356B8DF7@cisco.com> To: Klaas Wierenga X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmfx6Ktb5eKRDvZjHncIw9DaUxBwOURoxE4/WR78OPFGfK4EsYWvaTc7TcqrhQnNBsKOMm/ Cc: Anders Rundgren , public-identity@w3.org, "saag@ietf.org" , Kingsley Idehen , "public-webid@w3.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 13:14:09 -0000 --Apple-Mail=_C9B6A6A8-A076-472F-AEB4-1773D7392B5E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 19 Oct 2012, at 14:43, Klaas Wierenga wrote: > Hi, >=20 > (as a side note: shouldn't this be on the privacy list rather than the = saag list?) It kind of covers both, security and privacy. They are closely related. = Also WebID is a protocol that uses IETF's TLS so closely that I like to have = the IETF people in the loop. We're kind of between two institutions here. (I am = used to that: my mother is Austrian, my father British, lived in the US for a = long time, and was brought up in France :-). >=20 > On Oct 18, 2012, at 9:30 PM, Anders Rundgren = wrote: >=20 >> On 2012-10-18 18:06, Ben Laurie wrote: >>>>=20 >>>> Do you have example of what you describe? By that question I mean: = implicit >>>> anonymity as a functional substrate of some realm that we = experience today? >>>=20 >>> That's what selective disclosure systems like U-Prove and the PRIME >>> project are all about. >>>=20 >>=20 >> Which will never be of any practical use because without a reference >> back you cannot really get anything useful done. The search service >> monopoly your employer (Google) runs is clearly among the largest = threats >> to privacy there is so I don't understand what you are blabbing = about. >>=20 >> Is this about theory versus practice :-) >=20 > Let's refrain from ad hominem attacks in a technical discussion=85. agree.=20 But I think the fear expressed by that attack is justified and is really = part of what this thread is about. By focusing one unlinkability of = identifiers one in fact creates the space for large mega providers that have a = Panopoticon-like oversight over huge numbers of users to emerge. While I do wish to = applaud those services for the bold vision they have displayed in making us conscious = of=20 the advantages to be gained by working together on such a scale, I wish = to enlarge=20 that vision to a much larger space allowing the same to be done by = players that do not wish or cannot legally allow those players as intermediaries.=20 >=20 > I don't think anyone has argued that linkability is a bad thing per = se, what I believe is the crux is whether the links exists -by default- = (like locators for a person that can be looked up by 3d parties in DNS) = rather than -by choice-. It is the difference between being listed in = the phone directory versus giving someone your phone number. I think the = likes of Tor are not sufficient here, if the norm is that you are = linkable than someone that is using Tor is by definition suspicious=85 It is helpful to bring Tor into the discussion because it helps show = what types of technology can fix that type of problem. > David Chadwick rightfully remarks that there is a balance that you = need to strike based on a risk analysis, for me the question is how much = of that risk analysis you want to leave to the protocol designer versus = the end-user. In risk analysis you need to also consider the other side of the = question: what do you do if you don't have linkability? The answer is = that you have to go to a central provider. > As an end-user I like to have sufficient control over my privacy = without having to understand how to do Tor. If Tor, or something similar became widespread, you'd have no trouble = using it, just like most people using Apple's products have no trouble = using Unix (it used to be argued that Unix was impossibly difficult to = use) Anyway, we have a continuum: 1. you use a mega provider with one login to it a. the mega provider can read all your mail, and everything you are = communicating with other people b. the telcos can tell you are using the mega provider - but not what = you are communicating about (assuming you use TLS) 2. You use WebID over TLS + Access Controlled Read Write Web a. you can communicate only with the people/organisation you want to=20= ( no need for a mega provider, though they are not excluded ) b. the telcos can see where your traffic is going more precisely - = but they can't read your messages 3. You use WebID + ACLed RWW + Tor a. you can communicate with the people/orgs you want to (and only = them) b. the telcos can't see where your traffic is going =20 That is the continuum. So currently we are at 1. WebID adds the choice = of 2 and 3, to increase the options for privacy. >=20 > Klaas >=20 Social Web Architect http://bblfish.net/ --Apple-Mail=_C9B6A6A8-A076-472F-AEB4-1773D7392B5E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPDTCCByMw ggYLoAMCAQICAwTQYzANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEyMDgyOTAxNDU1NloXDTEzMDgzMDA5MjM0MFowZTEZMBcGA1UEDRMQazQ2eDlvOXJDRE5m VzMwYzEgMB4GA1UEAwwXaGVucnkuc3RvcnlAYmJsZmlzaC5uZXQxJjAkBgkqhkiG9w0BCQEWF2hl bnJ5LnN0b3J5QGJibGZpc2gubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArHXp EmiifOSpudkJn1vAnFdZsuaLuYYLbdWL47o1rKD/kg8/RJUmTIM2ara4e/MOxR16mu2fyAca3H1U oIXNNXDbYQDu2PkfLoNSM5JGAoYbfB0nXBK//ZecidVMZ8eExd02/vFzo5vj9kQNaAPSYirid5xe 1cV9Y1RFjlEozuYAUhU8zi3taf22JM45ii2YrCEgVjDdez8yio0QoJeKEEL3JhL4tqpkbfIOHmdi HYx00S6YcCogDfxXc3zOJ3jcIj/F61eXG1qWX/lq9RAyoBjYHLWE2iHQPwdzum03ubcvOTlohqOR +/cVzvx10l6bJ46KitfbydXMh8HoY7QcmwIDAQABo4IDsjCCA64wCQYDVR0TBAIwADALBgNVHQ8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQRbT9qwRblII9x nAN2FlEMUD1LQzAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAiBgNVHREEGzAZgRdo ZW5yeS5zdG9yeUBiYmxmaXNoLm5ldDCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIw ggH/MC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsG AQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEF BQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9u IHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZv ciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5 IG9ibGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBTZWUg c2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5 LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3Js MIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20v c3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29t L2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALj/A19bRLmI7sMf0lVRrdN23NuRC7/UFSLZ DfcxrR1wOtQgAbrFlFLY+Otn6UWYIiWQpv2v5Ploqw9rMam5W8seC3TUt83StohXCmZ0EDmK87If B6kpd7FwJ0RFGCxn22hPU2kuhp2mbjJzCTrd3jWsXw63MXDUzHuucWGX2mY1Ji+zRECh568N7iWA 5jn9kWT+h7o7ywKbHc4qAnksghLYAnTfoCx1IPkT4/8A5hf38imhf9NcNGibrvt/e49sacf6GjRH Ot/lOCrEX2fh2YvTB5sdEKM5tjKCKNpFSqnRCKhsWZ9N9ZP7mRZfCOBjAMsm3CW2ygwlWXc54lgf p1UwggfiMIIFyqADAgECAgENMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQy MTAxNTRaFw0xMjEwMjIyMTAxNTRaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP 6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu 2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyU GHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmt xWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMB AAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUU3Ltkpzg2ssB XHx+ljVO8tS4UYIwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0 YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHmCAQEwCQYDVR0SBAIwADA9BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYB BQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMw JxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmls aXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29t IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRD FkFTdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENl cnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAqprh4FuMzh0b/B3GLDAgoLeTJv3xArbNESi/ Kf/HMM//gf8FzwUUNOCglH6dfYuLQQ/dTtOyMb4JoiL3T7xiVKEAOmQ+t+b/xLOMa0m18zoRqW4k 6Glyoyvc7LMrdpgYk/lEh5nq8tPd9BoNmwiiheXphIVH/QelTgUkNzTC7IVpmYVsKuNOnxE1jJFZ NNfqZZK/5Oto7C6PfOut11KmBQSLZarAz0b/mjghdBsYfHuhdO8vrOvD0g5g7dA4pkOAU2Ed4pSC owBSItyD/5aFwZ75ji6Yq7GCG3BpiyAP9st8h+inc0L+7kmrAMJaLMAmu6GZs5Xgsbzn0wUJvbD9 h5jnnMM9UaZDcxl2uLB04quGUWM6NiKGabbxQc680PYbeQrQu+e6J4uqNAxzoa5RxkBA5a/3qlbg F9uJBekCqJswx5vQ9khJrs8UTMaIFzbEC5VGQziQH3/6KJ4DUP85OJEnCx/quShWA6w318LDnba3 M6a5V+KoNLhsVi/TSxf90UbBqwdRR/cOwuGkNJh16NvvhIqO26osMg64CbZsDVrEDr7uSMV40ieB JTo49Iyt77ECOhz/pyhowa2EUP6aKav+L/wXzAPB3LNqzujGR0K1pbyFWKvyYmdungJtySWUMw+R 5DqpA2bFIOE56pfWPLHZxOL+8+r79PLFX+y2V6ExggNvMIIDawIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRp ZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1l ZGlhdGUgQ2xpZW50IENBAgME0GMwCQYFKw4DAhoFAKCCAa8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMDE5MTMxMzQyWjAjBgkqhkiG9w0BCQQxFgQUM9vRE1gr IW5QWxe86a40HeheaRUwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgME0GMwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0ECAwTQYzANBgkqhkiG9w0BAQEFAASCAQCqP+gOTSTuge3yh6Unr0YAqMDAlOG7wKJ5JNH0 Y27skEbpHZInpJ0Hq4qbBQIRMuA6k6Psm6hp5HxaxIXdvxfpXJtx0BHxT8BiiHXctB3k2quINyOn RvOUhUBKsbDm10pFxfCPoOdkFm/ApfTKC9v1zWqz0eSNmPx258dOamMtA+wUU3g68YLG15RDhI6W pxtlJ0qfX8RVKNrJJARqD+qqj1TmS9SrtTIzPBvQufDH9qeHuM+SaRJxmhwVpXDt/+EG0zrqrHpn XoHKKEczMPZpV/rkitFlwF3IoZSCWGt0cxrIqOqr8He3ZGQaMI0UGylg4uWf0mGmA/oqOG/IFpKf AAAAAAAA --Apple-Mail=_C9B6A6A8-A076-472F-AEB4-1773D7392B5E-- From benl@google.com Fri Oct 19 06:31:11 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CBD21F868A for ; Fri, 19 Oct 2012 06:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kccpsNRYblrC for ; Fri, 19 Oct 2012 06:31:10 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 16B8F21F8685 for ; Fri, 19 Oct 2012 06:31:09 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so199012wib.13 for ; Fri, 19 Oct 2012 06:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=cJuJDjS5GQAaFQ2z3LB9isti1fkGBtDjO3o0k4Nuwqk=; b=QNnupJjtVrkFk6Ap7xdaXnMiyiVFTZOEj/Pg7yL/NZLAQX+l4gKDAbgUj84mgo7D7T kNB9kR5DGkcdaIPMg3YrJO6sSgX7wyotlTXjrrrEYfwUyrorVRygX9tqkFyHXCbLax+l +Q26rKAsTcniG6iUPlUeoZI0NEywcoHWU0aDBhKW2JEs8RyfVdEeuyY+ly1+QT0bUJAV pn5t2xc5a9DVaaK5UFiUK1QelO4MB/sIIUUvyIlnyFFKxMfelI6p2bt2BecUZiTCnN5Y bs9nobImOUxug7d9f1lW3HadNzJ0hgDzqzcn/9qp6CG2OjLHsSXUd81SyOYI6Hy779pv 9Mug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=cJuJDjS5GQAaFQ2z3LB9isti1fkGBtDjO3o0k4Nuwqk=; b=AJRgRrSwKK5OsC2HYkF3+C4+/67yAGrPBbmwtZdJ5dFQIOzd+9ru47suF25KAip0zP wuWR9+b+agJOElhWCqtz0XY1wNFg9qHleV2xjVmC4LgFe0Uy4z+1PMl2Zw3amppM0oAs En/LbBYjupOphcfi5LXWJXTdKg2kmcdYEYxl53dSU00Ish4aXjxakK3KVMkZgNsAMB4+ OZNxpbmF0brX8LaOu5DN0UswujwLMbAzZoFivip2xDzk+x2rT6JB1QuMeSkdRw8WPAER gbD/Rbl+M4KN9Q/5Yjmrrx+AHAVPLCdRFHVhquYYdf6drmyMaapjU3EKXNeJHANmwlLs 0CFA== MIME-Version: 1.0 Received: by 10.180.85.99 with SMTP id g3mr3332413wiz.5.1350653469032; Fri, 19 Oct 2012 06:31:09 -0700 (PDT) Received: by 10.216.236.201 with HTTP; Fri, 19 Oct 2012 06:31:08 -0700 (PDT) In-Reply-To: <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> References: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> Date: Fri, 19 Oct 2012 14:31:08 +0100 Message-ID: From: Ben Laurie To: Henry Story Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlMxBj5GQmy3Lvqbqai2FXXtOpwjmBvVITAhAKVxZGAwMVDTwbp5XM+SIjKjCx3zMzR5dYD3dWjv1zUG305wOk3uz8+9pQf+zf9aRog52p8ymtSIs3svLF2Qg60/aZMyxaSDg9kVEumtFJGweGfM1vtwhBnYZAJo+HOgjd16M0HwT9K3d2d7LyehQaxqsn9HL1/S8BK Cc: "public-philoweb@w3.org" , "public-identity@w3.org" , "saag@ietf.org" , "public-privacy@w3.org" , Sam Hartman , "public-webid@w3.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 13:31:11 -0000 On 19 October 2012 13:01, Henry Story wrote: > > On 18 Oct 2012, at 21:29, Ben Laurie wrote: > >> On Thu, Oct 18, 2012 at 8:20 PM, Henry Story wrote: >>> >>> On 18 Oct 2012, at 21:04, Mouse wrote: >>> >>>>> [...] >>>>> Unfortunately, I think that's too high of a price to pay for >>>>> unlinkability. >>>>> So I've come to the conclusion that anonymity will depend on >>>>> protocols like TOR specifically designed for it. >>>> >>>> Is it my imagination, or is this stuff confusing anonymity with >>>> pseudonymity? I feel reasonably sure I've missed some of the thread, >>>> but what I have seem does seem to be confusing the two. >>>> >>>> This whole thing about linking, for example, seems to be based on >>>> linking identities of some sort, implying that the systems in question >>>> *have* identities, in which case they are (at best) pseudonymous, not >>>> anonymous. >>> >>> With WebID ( http://webid.info/ ) you have a pseudonymous global identifier, >>> that is tied to a document on the Web that need only reveal your public key. >>> That WebID can then link to further information that is access controlled, >>> so that only your friends would be able to see it. >>> >>> The first diagram in the spec shows this well >>> >>> http://webid.info/spec/#publishing-the-webid-profile-document >>> >>> If you put WebID behind TOR and only have .onion WebIDs - something that >>> should be possible to do - then nobody would know WHERE the box hosting your >>> profile is, so they would not be able to just find your home location >>> from your ip-address. But you would still be able to link up in an access >>> controlled manner to your friends ( who may or may not be serving their pages >>> behind Tor ). >>> >>> You would then be unlinkable in the sense of >>> http://tools.ietf.org/html/draft-iab-privacy-considerations-03 >>> >>> [[ >>> Within a particular set of information, the >>> inability of an observer or attacker to distinguish whether two >>> items of interest are related or not (with a high enough degree of >>> probability to be useful to the observer or attacker). >>> ]] >>> >>> from any person that was not able to access the resources. But you would >>> be linkable by your friends. I think you want both. Linkability by those >>> authorized, unlinkability for those unauthorized. Hence linkability is not >>> just a negative. >> >> I really feel like I am beating a dead horse at this point, but >> perhaps you'll eventually admit it. Your public key links you. > > The question is to whom? What is the scenario you are imagining, and who is > the attacker there? > >> Access >> control on the rest of the information is irrelevant. Indeed, access >> control on the public key is irrelevant, since you must reveal it when >> you use the client cert. > > You are imagining that the server I am connecting to, and that I have > decided to identify myself to, is the one that is attacking me? Right? > Because otherwise I cannot understand your issue. > > But then I still do not understand your issue, since I deliberately > did connect to that site in an identifiable manner with a global id. > I could have created a locally valid ID only, had I wanted to not > connect with a globally valid one. > > So your issue boils down to this: if I connect to a web site deliberately > with a global identifier, then I am globally identified by that web site. > Which is what I wanted. > > So perhaps it is up to you to answer: why should I not want that? I am not saying you should not want that, I am saying that ACLs on the resources do not achieve unlinkability. >> Incidentally, to observers as well as the >> server you connect to. > > Not when you re-negotiation I think. That's true, but is not specified in WebID, right? Also, because of the renegotiation attack, this is currently insecure in many cases. > And certainly not if you use Tor, right? Tor has no impact on the visibility of the communication at the server end. > > > Social Web Architect > http://bblfish.net/ > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From henry.story@bblfish.net Fri Oct 19 06:46:21 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087FA21F868A for ; Fri, 19 Oct 2012 06:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ph-WvqodvV31 for ; Fri, 19 Oct 2012 06:46:20 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id A312A21F8685 for ; Fri, 19 Oct 2012 06:46:19 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so250502eek.31 for ; Fri, 19 Oct 2012 06:46:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=8smhACMCB7BhPwKS7jOpB9dpORfXoVbWXjkGwwYKTCA=; b=TEb4h5cg9T2pvZkElxq4yvSYYUj1M03EEP2SEAYQtZpV94Qx/lSTJ6vUkxHU1Rww+m B6q7w3a7qNRwxZEG7JREw77TkDHA61LAYrONy4k//5MgAH17QSXdVPzbnnqt43+X+rJP YFG/hCNUVmZO6d2tMgC8Xc9c5gxWETBStuu2/qw/dBjzc4ZRCg8/nlMIvhFMQZjjfpCQ THdJOqklD+hAX1DhFtqVoM++SxH7gCPXPFcoFrSukw+dlFOP/cdswC2kaHLSOChbKELE L/dKQAsdSXzi8YwvSXa5QZD8a39kx6Z7GI69B/N/XmFzvQpmtIwMDGnvwzIzsM2HtSqx Fp3Q== Received: by 10.14.221.194 with SMTP id r42mr1971739eep.25.1350654378692; Fri, 19 Oct 2012 06:46:18 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-132-122.w86-198.abo.wanadoo.fr. [86.198.99.122]) by mx.google.com with ESMTPS id z3sm1151178eeo.13.2012.10.19.06.46.06 (version=SSLv3 cipher=OTHER); Fri, 19 Oct 2012 06:46:16 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_67F87271-93EA-4689-8738-2E9478DFAEE8"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Henry Story In-Reply-To: Date: Fri, 19 Oct 2012 15:46:03 +0200 Message-Id: <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> References: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> To: Ben Laurie X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkew22TpBGNh5rIwPQCpDqwPBRakgdDuAsb31/3lJv06IYpBAFYf62rB0qwtQ5TyW3IN+bP Cc: "public-philoweb@w3.org" , "public-identity@w3.org" , "saag@ietf.org" , "public-privacy@w3.org" , Sam Hartman , "public-webid@w3.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 13:46:21 -0000 --Apple-Mail=_67F87271-93EA-4689-8738-2E9478DFAEE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 19 Oct 2012, at 15:31, Ben Laurie wrote: > On 19 October 2012 13:01, Henry Story wrote: >>=20 >> On 18 Oct 2012, at 21:29, Ben Laurie wrote: >>=20 >>> On Thu, Oct 18, 2012 at 8:20 PM, Henry Story = wrote: >>>>=20 >>>> On 18 Oct 2012, at 21:04, Mouse wrote: >>>>=20 >>>>>> [...] >>>>>> Unfortunately, I think that's too high of a price to pay for >>>>>> unlinkability. >>>>>> So I've come to the conclusion that anonymity will depend on >>>>>> protocols like TOR specifically designed for it. >>>>>=20 >>>>> Is it my imagination, or is this stuff confusing anonymity with >>>>> pseudonymity? I feel reasonably sure I've missed some of the = thread, >>>>> but what I have seem does seem to be confusing the two. >>>>>=20 >>>>> This whole thing about linking, for example, seems to be based on >>>>> linking identities of some sort, implying that the systems in = question >>>>> *have* identities, in which case they are (at best) pseudonymous, = not >>>>> anonymous. >>>>=20 >>>> With WebID ( http://webid.info/ ) you have a pseudonymous global = identifier, >>>> that is tied to a document on the Web that need only reveal your = public key. >>>> That WebID can then link to further information that is access = controlled, >>>> so that only your friends would be able to see it. >>>>=20 >>>> The first diagram in the spec shows this well >>>>=20 >>>> http://webid.info/spec/#publishing-the-webid-profile-document >>>>=20 >>>> If you put WebID behind TOR and only have .onion WebIDs - something = that >>>> should be possible to do - then nobody would know WHERE the box = hosting your >>>> profile is, so they would not be able to just find your home = location >>>> from your ip-address. But you would still be able to link up in an = access >>>> controlled manner to your friends ( who may or may not be serving = their pages >>>> behind Tor ). >>>>=20 >>>> You would then be unlinkable in the sense of >>>> http://tools.ietf.org/html/draft-iab-privacy-considerations-03 >>>>=20 >>>> [[ >>>> Within a particular set of information, the >>>> inability of an observer or attacker to distinguish whether two >>>> items of interest are related or not (with a high enough degree = of >>>> probability to be useful to the observer or attacker). >>>> ]] >>>>=20 >>>> from any person that was not able to access the resources. But you = would >>>> be linkable by your friends. I think you want both. Linkability by = those >>>> authorized, unlinkability for those unauthorized. Hence linkability = is not >>>> just a negative. >>>=20 >>> I really feel like I am beating a dead horse at this point, but >>> perhaps you'll eventually admit it. Your public key links you. >>=20 >> The question is to whom? What is the scenario you are imagining, and = who is >> the attacker there? >>=20 >>> Access >>> control on the rest of the information is irrelevant. Indeed, access >>> control on the public key is irrelevant, since you must reveal it = when >>> you use the client cert. >>=20 >> You are imagining that the server I am connecting to, and that I have >> decided to identify myself to, is the one that is attacking me? = Right? >> Because otherwise I cannot understand your issue. >>=20 >> But then I still do not understand your issue, since I deliberately >> did connect to that site in an identifiable manner with a global id. >> I could have created a locally valid ID only, had I wanted to not >> connect with a globally valid one. >>=20 >> So your issue boils down to this: if I connect to a web site = deliberately >> with a global identifier, then I am globally identified by that web = site. >> Which is what I wanted. >>=20 >> So perhaps it is up to you to answer: why should I not want that? >=20 > I am not saying you should not want that, I am saying that ACLs on the > resources do not achieve unlinkability. Can you expand on what the dangers are? >=20 >>> Incidentally, to observers as well as the >>> server you connect to. >>=20 >> Not when you re-negotiation I think. >=20 > That's true, but is not specified in WebID, right? Also, because of > the renegotiation attack, this is currently insecure in many cases. WebID on TLS does rely on TLS. Security is not a goal one can reach, it is a way of travelling. So I do expect every security protocol to have issues. These ones are being fixed, and if more people build on=20 them, the priority of the need to fix them will grow faster. >=20 >> And certainly not if you use Tor, right? >=20 > Tor has no impact on the visibility of the communication at the server = end. You really need to expand on what the danger is. Because again I think you are thinking of the site I am connecting to as the attacker. But I may be wrong. >=20 >>=20 >>=20 >> Social Web Architect >> http://bblfish.net/ >>=20 >>=20 >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >>=20 Social Web Architect http://bblfish.net/ --Apple-Mail=_67F87271-93EA-4689-8738-2E9478DFAEE8 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPDTCCByMw ggYLoAMCAQICAwTQYzANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEyMDgyOTAxNDU1NloXDTEzMDgzMDA5MjM0MFowZTEZMBcGA1UEDRMQazQ2eDlvOXJDRE5m VzMwYzEgMB4GA1UEAwwXaGVucnkuc3RvcnlAYmJsZmlzaC5uZXQxJjAkBgkqhkiG9w0BCQEWF2hl bnJ5LnN0b3J5QGJibGZpc2gubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArHXp EmiifOSpudkJn1vAnFdZsuaLuYYLbdWL47o1rKD/kg8/RJUmTIM2ara4e/MOxR16mu2fyAca3H1U oIXNNXDbYQDu2PkfLoNSM5JGAoYbfB0nXBK//ZecidVMZ8eExd02/vFzo5vj9kQNaAPSYirid5xe 1cV9Y1RFjlEozuYAUhU8zi3taf22JM45ii2YrCEgVjDdez8yio0QoJeKEEL3JhL4tqpkbfIOHmdi HYx00S6YcCogDfxXc3zOJ3jcIj/F61eXG1qWX/lq9RAyoBjYHLWE2iHQPwdzum03ubcvOTlohqOR +/cVzvx10l6bJ46KitfbydXMh8HoY7QcmwIDAQABo4IDsjCCA64wCQYDVR0TBAIwADALBgNVHQ8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQRbT9qwRblII9x nAN2FlEMUD1LQzAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAiBgNVHREEGzAZgRdo ZW5yeS5zdG9yeUBiYmxmaXNoLm5ldDCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIw ggH/MC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsG AQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEF BQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9u IHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZv ciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5 IG9ibGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBTZWUg c2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5 LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3Js MIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20v c3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29t L2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALj/A19bRLmI7sMf0lVRrdN23NuRC7/UFSLZ DfcxrR1wOtQgAbrFlFLY+Otn6UWYIiWQpv2v5Ploqw9rMam5W8seC3TUt83StohXCmZ0EDmK87If B6kpd7FwJ0RFGCxn22hPU2kuhp2mbjJzCTrd3jWsXw63MXDUzHuucWGX2mY1Ji+zRECh568N7iWA 5jn9kWT+h7o7ywKbHc4qAnksghLYAnTfoCx1IPkT4/8A5hf38imhf9NcNGibrvt/e49sacf6GjRH Ot/lOCrEX2fh2YvTB5sdEKM5tjKCKNpFSqnRCKhsWZ9N9ZP7mRZfCOBjAMsm3CW2ygwlWXc54lgf p1UwggfiMIIFyqADAgECAgENMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQy MTAxNTRaFw0xMjEwMjIyMTAxNTRaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP 6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu 2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyU GHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmt xWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMB AAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUU3Ltkpzg2ssB XHx+ljVO8tS4UYIwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0 YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHmCAQEwCQYDVR0SBAIwADA9BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYB BQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMw JxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmls aXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29t IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRD FkFTdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENl cnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAqprh4FuMzh0b/B3GLDAgoLeTJv3xArbNESi/ Kf/HMM//gf8FzwUUNOCglH6dfYuLQQ/dTtOyMb4JoiL3T7xiVKEAOmQ+t+b/xLOMa0m18zoRqW4k 6Glyoyvc7LMrdpgYk/lEh5nq8tPd9BoNmwiiheXphIVH/QelTgUkNzTC7IVpmYVsKuNOnxE1jJFZ NNfqZZK/5Oto7C6PfOut11KmBQSLZarAz0b/mjghdBsYfHuhdO8vrOvD0g5g7dA4pkOAU2Ed4pSC owBSItyD/5aFwZ75ji6Yq7GCG3BpiyAP9st8h+inc0L+7kmrAMJaLMAmu6GZs5Xgsbzn0wUJvbD9 h5jnnMM9UaZDcxl2uLB04quGUWM6NiKGabbxQc680PYbeQrQu+e6J4uqNAxzoa5RxkBA5a/3qlbg F9uJBekCqJswx5vQ9khJrs8UTMaIFzbEC5VGQziQH3/6KJ4DUP85OJEnCx/quShWA6w318LDnba3 M6a5V+KoNLhsVi/TSxf90UbBqwdRR/cOwuGkNJh16NvvhIqO26osMg64CbZsDVrEDr7uSMV40ieB JTo49Iyt77ECOhz/pyhowa2EUP6aKav+L/wXzAPB3LNqzujGR0K1pbyFWKvyYmdungJtySWUMw+R 5DqpA2bFIOE56pfWPLHZxOL+8+r79PLFX+y2V6ExggNvMIIDawIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRp ZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1l ZGlhdGUgQ2xpZW50IENBAgME0GMwCQYFKw4DAhoFAKCCAa8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMDE5MTM0NjA0WjAjBgkqhkiG9w0BCQQxFgQUdncb8Gqx 786KZRhClHuP3TBl8tcwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgME0GMwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0ECAwTQYzANBgkqhkiG9w0BAQEFAASCAQBmhvZCCiMz9qts8pnRsMucLBlpbEKw0jxHUssA LnVHKor0GbaY2BK6JST+LuGjUEX2LR0bVKw4rZ5dklRAY1HlCR45eOqDoQDHSmptI0AwkcdovieT r8ODUV5D/4fcoDlMH2kLvSZVze7dFX3/UkKh7ePOQCzOk2Jm8LADSfk1aPqem2Gj/qTvMG6qFqgJ YgPF/MPM98uxFLYkY6+6ZIdVrO8YYtxnY0SPz1z95vdz1TS5J1zbD7fY51SDwD5Nf+Is1qAcJinA d7uLIWe89WAc+mz+26mhAbQIg6le3R+S6PfXuyxu9gHOrOMlgoWHR7PQmX5UDxGcsxF8/mVvkVs/ AAAAAAAA --Apple-Mail=_67F87271-93EA-4689-8738-2E9478DFAEE8-- From benl@google.com Fri Oct 19 06:52:31 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC69321F84F8 for ; Fri, 19 Oct 2012 06:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTv7-OueixFo for ; Fri, 19 Oct 2012 06:52:30 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5B621F86E3 for ; Fri, 19 Oct 2012 06:52:26 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so259873wgb.13 for ; Fri, 19 Oct 2012 06:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=9xEqwtHm4ZhXCUqnAkGT2SAiw9k2c6iaDCqz9Pi4E9k=; b=LnoBovTCu8+1b4I1ajVZn21u43yagOp41mrcLxQCiG1+gyn1jWpQHvOQgtdLBe0roN qMJGK6bT1kvRzPvVnLJ6Jyw1WdPtnexvA1kOs1HWxMjVGoX7nL7p9svIFT5kZKerfzmh hh2RtqBIGXqfaTCrVWGfmncyt8kpXNX+KvwtW9SJNmKmnxmxo+hd8zN4RwPDWlXfpVBN RfVJKr7EyZJRiB7JgVAuehqrcBSAXj6w3iHi59W60MkD4Q9EB50VlHDVPSzqNl+9ZCZ1 sw63DDNDC4ITcKh6X+4zK/4KVVAuFtVsyg7KJtbm+KjqDfQt6o1DsfXp92AqxzrsTgQO 1ZAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=9xEqwtHm4ZhXCUqnAkGT2SAiw9k2c6iaDCqz9Pi4E9k=; b=WOrE8lNneINKNsFsc81rF2b9rFqPya7g7DcU3xzqpYdgAXQjFd6AlqyaXU7GeM3tyq WMka56AvExhg9JT8q2u2iT+SO9rtpe3Pr7XrqRfKvJiuH0WvmeEXFA5fK5JFFcbhewLA vX6PaiI/iI1qRFXkG7zhTCqH3MLUwEUtAjrWSJoyQxCetwUZuZZyalvX6eFsFY+Efy8n r5mInLydXP1e03l/DLZc+2CUfZx/j6MPzxIBFsCbKbNVQ+zgpYKqn2XWePHcmepWeXkm 0sLVL6HiAcD2YvOg3yaWLtVxaCMmmUO89s9hKl8kiH4Dzjzb5o9PHRkC9NWW6DHn/w68 irsw== MIME-Version: 1.0 Received: by 10.180.85.99 with SMTP id g3mr3465948wiz.5.1350654745927; Fri, 19 Oct 2012 06:52:25 -0700 (PDT) Received: by 10.216.236.201 with HTTP; Fri, 19 Oct 2012 06:52:25 -0700 (PDT) In-Reply-To: <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> References: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> Date: Fri, 19 Oct 2012 14:52:25 +0100 Message-ID: From: Ben Laurie To: Henry Story Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkAPEHA3HR8rnGIwoROUSBtGJdcL9E6dhw3S3Imae8f/YjWfothO98iTAUgJObKhUe0io6vowZVfP2cjnml1q7XaShFm1RFcHoaUHRaDaC8O3Vyd46lrgX9zAVVjJQw71V/Uwwa4suUwJ8KC7XJ8Wxu5KNgyHzXZwnFGwC6YdDWzkUbc4wNUtw2ezgpDvYLZhU7/vXw Cc: "public-philoweb@w3.org" , "public-identity@w3.org" , "saag@ietf.org" , "public-privacy@w3.org" , Sam Hartman , "public-webid@w3.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 13:52:31 -0000 On 19 October 2012 14:46, Henry Story wrote: > > On 19 Oct 2012, at 15:31, Ben Laurie wrote: > >> On 19 October 2012 13:01, Henry Story wrote: >>> >>> On 18 Oct 2012, at 21:29, Ben Laurie wrote: >>> >>>> On Thu, Oct 18, 2012 at 8:20 PM, Henry Story wrote: >>>>> >>>>> On 18 Oct 2012, at 21:04, Mouse wrote: >>>>> >>>>>>> [...] >>>>>>> Unfortunately, I think that's too high of a price to pay for >>>>>>> unlinkability. >>>>>>> So I've come to the conclusion that anonymity will depend on >>>>>>> protocols like TOR specifically designed for it. >>>>>> >>>>>> Is it my imagination, or is this stuff confusing anonymity with >>>>>> pseudonymity? I feel reasonably sure I've missed some of the thread, >>>>>> but what I have seem does seem to be confusing the two. >>>>>> >>>>>> This whole thing about linking, for example, seems to be based on >>>>>> linking identities of some sort, implying that the systems in question >>>>>> *have* identities, in which case they are (at best) pseudonymous, not >>>>>> anonymous. >>>>> >>>>> With WebID ( http://webid.info/ ) you have a pseudonymous global identifier, >>>>> that is tied to a document on the Web that need only reveal your public key. >>>>> That WebID can then link to further information that is access controlled, >>>>> so that only your friends would be able to see it. >>>>> >>>>> The first diagram in the spec shows this well >>>>> >>>>> http://webid.info/spec/#publishing-the-webid-profile-document >>>>> >>>>> If you put WebID behind TOR and only have .onion WebIDs - something that >>>>> should be possible to do - then nobody would know WHERE the box hosting your >>>>> profile is, so they would not be able to just find your home location >>>>> from your ip-address. But you would still be able to link up in an access >>>>> controlled manner to your friends ( who may or may not be serving their pages >>>>> behind Tor ). >>>>> >>>>> You would then be unlinkable in the sense of >>>>> http://tools.ietf.org/html/draft-iab-privacy-considerations-03 >>>>> >>>>> [[ >>>>> Within a particular set of information, the >>>>> inability of an observer or attacker to distinguish whether two >>>>> items of interest are related or not (with a high enough degree of >>>>> probability to be useful to the observer or attacker). >>>>> ]] >>>>> >>>>> from any person that was not able to access the resources. But you would >>>>> be linkable by your friends. I think you want both. Linkability by those >>>>> authorized, unlinkability for those unauthorized. Hence linkability is not >>>>> just a negative. >>>> >>>> I really feel like I am beating a dead horse at this point, but >>>> perhaps you'll eventually admit it. Your public key links you. >>> >>> The question is to whom? What is the scenario you are imagining, and who is >>> the attacker there? >>> >>>> Access >>>> control on the rest of the information is irrelevant. Indeed, access >>>> control on the public key is irrelevant, since you must reveal it when >>>> you use the client cert. >>> >>> You are imagining that the server I am connecting to, and that I have >>> decided to identify myself to, is the one that is attacking me? Right? >>> Because otherwise I cannot understand your issue. >>> >>> But then I still do not understand your issue, since I deliberately >>> did connect to that site in an identifiable manner with a global id. >>> I could have created a locally valid ID only, had I wanted to not >>> connect with a globally valid one. >>> >>> So your issue boils down to this: if I connect to a web site deliberately >>> with a global identifier, then I am globally identified by that web site. >>> Which is what I wanted. >>> >>> So perhaps it is up to you to answer: why should I not want that? >> >> I am not saying you should not want that, I am saying that ACLs on the >> resources do not achieve unlinkability. > > Can you expand on what the dangers are? > >> >>>> Incidentally, to observers as well as the >>>> server you connect to. >>> >>> Not when you re-negotiation I think. >> >> That's true, but is not specified in WebID, right? Also, because of >> the renegotiation attack, this is currently insecure in many cases. > > WebID on TLS does rely on TLS. Security is not a goal one can reach, > it is a way of travelling. So I do expect every security protocol to > have issues. These ones are being fixed, and if more people build on > them, the priority of the need to fix them will grow faster. > >> >>> And certainly not if you use Tor, right? >> >> Tor has no impact on the visibility of the communication at the server end. > > You really need to expand on what the danger is. Because again > I think you are thinking of the site I am connecting to as the attacker. > But I may be wrong. I'm getting quite tired of this: the point is, you cannot achieve unlinkability with WebID except by using a different WebIDs. You made the claim that ACLs on resources achieve unlinkability. This is incorrect. So yes, the scenario is there are two sites that I connect to using WebID and I want each of them to not be able to link my connections to the other. To do this, I need two WebIDs, one for each site. ACLs do not assist. > >> >>> >>> >>> Social Web Architect >>> http://bblfish.net/ >>> >>> >>> _______________________________________________ >>> saag mailing list >>> saag@ietf.org >>> https://www.ietf.org/mailman/listinfo/saag >>> > > Social Web Architect > http://bblfish.net/ > From henry.story@bblfish.net Fri Oct 19 07:16:28 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA19E21F86A0 for ; Fri, 19 Oct 2012 07:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfmQGMssyR-I for ; Fri, 19 Oct 2012 07:16:27 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 62AEF21F85E7 for ; Fri, 19 Oct 2012 07:16:27 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so265926eek.31 for ; Fri, 19 Oct 2012 07:16:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=RQkvGOw4UUzro/pd7YbRycfT3SRM62e/GrhqjilTtA4=; b=C+KIbMye/afI50IXB7rUYJXbxwzH7uylW2g4NJPFNTG2XBlyGdYcsIpdO3BplXnPqr 0fX/j52LZXEBrxkyX7jwZ1fYA7axAeMYD2f85+ccyYScJoQDJ0Lk3DbYI84bwbyrCN8p VREHyuyilKFf2XhIlcWdP+k6EbpM4S/iDnZtT1YtR6wzg24hAmS4dFUglsvCtLcUfY52 bWUE/xBN264+JyZ7hiElBmprfyD9V5UfT2DfPs2zUQmVucosr6W3/6LdCWTYggHPw0CV umqrf0nnabIjUPA/5Ie4nzpcoxP5xj8mrSF8lqHLwW5SCmqFzVevR1wGuS7FbiuWx+T2 3eVA== Received: by 10.14.194.72 with SMTP id l48mr2155997een.9.1350656186420; Fri, 19 Oct 2012 07:16:26 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-132-122.w86-198.abo.wanadoo.fr. [86.198.99.122]) by mx.google.com with ESMTPS id t7sm2782832eel.14.2012.10.19.07.16.15 (version=SSLv3 cipher=OTHER); Fri, 19 Oct 2012 07:16:16 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_C2472782-3D6F-43C5-A3FE-E77CC86442EE"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Henry Story In-Reply-To: Date: Fri, 19 Oct 2012 16:16:13 +0200 Message-Id: <67F4F93A-BE4C-4AF0-BA02-0096930820E1@bblfish.net> References: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> To: Ben Laurie X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnwBsW2DjlxbSSVXCT+DoK50kpjSEXSqzDa0SycOfLhFZrTwjDAPeyPn16Oy7B7BaOY1hFT Cc: "public-philoweb@w3.org" , "public-identity@w3.org" , "saag@ietf.org" , "public-privacy@w3.org" , Sam Hartman , "public-webid@w3.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 14:16:29 -0000 --Apple-Mail=_C2472782-3D6F-43C5-A3FE-E77CC86442EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 19 Oct 2012, at 15:52, Ben Laurie wrote: > On 19 October 2012 14:46, Henry Story wrote: >>=20 >> On 19 Oct 2012, at 15:31, Ben Laurie wrote: >>=20 >>> On 19 October 2012 13:01, Henry Story = wrote: >>>>=20 >>>> On 18 Oct 2012, at 21:29, Ben Laurie wrote: >>>>=20 >>>>> On Thu, Oct 18, 2012 at 8:20 PM, Henry Story = wrote: >>>>>>=20 >>>>>> On 18 Oct 2012, at 21:04, Mouse = wrote: >>>>>>=20 >>>>>>>> [...] >>>>>>>> Unfortunately, I think that's too high of a price to pay for >>>>>>>> unlinkability. >>>>>>>> So I've come to the conclusion that anonymity will depend on >>>>>>>> protocols like TOR specifically designed for it. >>>>>>>=20 >>>>>>> Is it my imagination, or is this stuff confusing anonymity with >>>>>>> pseudonymity? I feel reasonably sure I've missed some of the = thread, >>>>>>> but what I have seem does seem to be confusing the two. >>>>>>>=20 >>>>>>> This whole thing about linking, for example, seems to be based = on >>>>>>> linking identities of some sort, implying that the systems in = question >>>>>>> *have* identities, in which case they are (at best) = pseudonymous, not >>>>>>> anonymous. >>>>>>=20 >>>>>> With WebID ( http://webid.info/ ) you have a pseudonymous global = identifier, >>>>>> that is tied to a document on the Web that need only reveal your = public key. >>>>>> That WebID can then link to further information that is access = controlled, >>>>>> so that only your friends would be able to see it. >>>>>>=20 >>>>>> The first diagram in the spec shows this well >>>>>>=20 >>>>>> http://webid.info/spec/#publishing-the-webid-profile-document >>>>>>=20 >>>>>> If you put WebID behind TOR and only have .onion WebIDs - = something that >>>>>> should be possible to do - then nobody would know WHERE the box = hosting your >>>>>> profile is, so they would not be able to just find your home = location >>>>>> from your ip-address. But you would still be able to link up in = an access >>>>>> controlled manner to your friends ( who may or may not be serving = their pages >>>>>> behind Tor ). >>>>>>=20 >>>>>> You would then be unlinkable in the sense of >>>>>> http://tools.ietf.org/html/draft-iab-privacy-considerations-03 >>>>>>=20 >>>>>> [[ >>>>>> Within a particular set of information, the >>>>>> inability of an observer or attacker to distinguish whether = two >>>>>> items of interest are related or not (with a high enough = degree of >>>>>> probability to be useful to the observer or attacker). >>>>>> ]] >>>>>>=20 >>>>>> from any person that was not able to access the resources. But = you would >>>>>> be linkable by your friends. I think you want both. Linkability = by those >>>>>> authorized, unlinkability for those unauthorized. Hence = linkability is not >>>>>> just a negative. >>>>>=20 >>>>> I really feel like I am beating a dead horse at this point, but >>>>> perhaps you'll eventually admit it. Your public key links you. >>>>=20 >>>> The question is to whom? What is the scenario you are imagining, = and who is >>>> the attacker there? >>>>=20 >>>>> Access >>>>> control on the rest of the information is irrelevant. Indeed, = access >>>>> control on the public key is irrelevant, since you must reveal it = when >>>>> you use the client cert. >>>>=20 >>>> You are imagining that the server I am connecting to, and that I = have >>>> decided to identify myself to, is the one that is attacking me? = Right? >>>> Because otherwise I cannot understand your issue. >>>>=20 >>>> But then I still do not understand your issue, since I deliberately >>>> did connect to that site in an identifiable manner with a global = id. >>>> I could have created a locally valid ID only, had I wanted to not >>>> connect with a globally valid one. >>>>=20 >>>> So your issue boils down to this: if I connect to a web site = deliberately >>>> with a global identifier, then I am globally identified by that web = site. >>>> Which is what I wanted. >>>>=20 >>>> So perhaps it is up to you to answer: why should I not want that? >>>=20 >>> I am not saying you should not want that, I am saying that ACLs on = the >>> resources do not achieve unlinkability. >>=20 >> Can you expand on what the dangers are? >>=20 >>>=20 >>>>> Incidentally, to observers as well as the >>>>> server you connect to. >>>>=20 >>>> Not when you re-negotiation I think. >>>=20 >>> That's true, but is not specified in WebID, right? Also, because of >>> the renegotiation attack, this is currently insecure in many cases. >>=20 >> WebID on TLS does rely on TLS. Security is not a goal one can reach, >> it is a way of travelling. So I do expect every security protocol to >> have issues. These ones are being fixed, and if more people build on >> them, the priority of the need to fix them will grow faster. >>=20 >>>=20 >>>> And certainly not if you use Tor, right? >>>=20 >>> Tor has no impact on the visibility of the communication at the = server end. >>=20 >> You really need to expand on what the danger is. Because again >> I think you are thinking of the site I am connecting to as the = attacker. >> But I may be wrong. >=20 > I'm getting quite tired of this: the point is, you cannot achieve > unlinkability with WebID except by using a different WebIDs. You made > the claim that ACLs on resources achieve unlinkability. This is > incorrect. The definition of unlinkability higher up is relative to the notion of an attacker. That is why you cannot just make a statement that WebID cannot achieve unlinkability without specifying who the attackers are. Such a sentence is incomplete. >=20 > So yes, the scenario is there are two sites that I connect to using > WebID and I want each of them to not be able to link my connections to > the other. To do this, I need two WebIDs, one for each site. ACLs do > not assist. Thanks for filling in the picture. So the difference between us is that your are considering situations where you wish to identify to a web site which you think of as an attacker. There WebID is not the right technology, and indeed very few technologies may be right - indeed it may be impossible for that to be used by a large public, since most such attacking sites would=20 ask a user for his e-mail address, or a few pieces of information that together are linkable, and link him/her. In the situations we are considering with WebID the sites we are=20 connecting to are not thought of as the enemy. Now I agree we should=20 add a privacy/security section to the spec ( ISSUE-68 [1] ) that makes this limitation clear. In some situations this is problematic. But for creating a distributed SocialWeb which is what I am interested in doing, I think this is = essential.=20 We want to be able to allow friends of friends to work together, create ad hoc working groups of people with distributed identities, etc... = These are the types of things people do one social networks, we just want to = do those on a global scale with no center of control. Does that make sense? Would adding that to a privacy section be = satisfactory to you? Henry [1] http://www.w3.org/2005/Incubator/webid/track/issues/68 Social Web Architect http://bblfish.net/ --Apple-Mail=_C2472782-3D6F-43C5-A3FE-E77CC86442EE Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPDTCCByMw ggYLoAMCAQICAwTQYzANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEyMDgyOTAxNDU1NloXDTEzMDgzMDA5MjM0MFowZTEZMBcGA1UEDRMQazQ2eDlvOXJDRE5m VzMwYzEgMB4GA1UEAwwXaGVucnkuc3RvcnlAYmJsZmlzaC5uZXQxJjAkBgkqhkiG9w0BCQEWF2hl bnJ5LnN0b3J5QGJibGZpc2gubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArHXp EmiifOSpudkJn1vAnFdZsuaLuYYLbdWL47o1rKD/kg8/RJUmTIM2ara4e/MOxR16mu2fyAca3H1U oIXNNXDbYQDu2PkfLoNSM5JGAoYbfB0nXBK//ZecidVMZ8eExd02/vFzo5vj9kQNaAPSYirid5xe 1cV9Y1RFjlEozuYAUhU8zi3taf22JM45ii2YrCEgVjDdez8yio0QoJeKEEL3JhL4tqpkbfIOHmdi HYx00S6YcCogDfxXc3zOJ3jcIj/F61eXG1qWX/lq9RAyoBjYHLWE2iHQPwdzum03ubcvOTlohqOR +/cVzvx10l6bJ46KitfbydXMh8HoY7QcmwIDAQABo4IDsjCCA64wCQYDVR0TBAIwADALBgNVHQ8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQRbT9qwRblII9x nAN2FlEMUD1LQzAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAiBgNVHREEGzAZgRdo ZW5yeS5zdG9yeUBiYmxmaXNoLm5ldDCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIw ggH/MC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsG AQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEF BQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9u IHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZv ciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5 IG9ibGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBTZWUg c2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5 LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3Js MIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20v c3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29t L2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALj/A19bRLmI7sMf0lVRrdN23NuRC7/UFSLZ DfcxrR1wOtQgAbrFlFLY+Otn6UWYIiWQpv2v5Ploqw9rMam5W8seC3TUt83StohXCmZ0EDmK87If B6kpd7FwJ0RFGCxn22hPU2kuhp2mbjJzCTrd3jWsXw63MXDUzHuucWGX2mY1Ji+zRECh568N7iWA 5jn9kWT+h7o7ywKbHc4qAnksghLYAnTfoCx1IPkT4/8A5hf38imhf9NcNGibrvt/e49sacf6GjRH Ot/lOCrEX2fh2YvTB5sdEKM5tjKCKNpFSqnRCKhsWZ9N9ZP7mRZfCOBjAMsm3CW2ygwlWXc54lgf p1UwggfiMIIFyqADAgECAgENMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQy MTAxNTRaFw0xMjEwMjIyMTAxNTRaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP 6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu 2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyU GHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmt xWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMB AAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUU3Ltkpzg2ssB XHx+ljVO8tS4UYIwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0 YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHmCAQEwCQYDVR0SBAIwADA9BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYB BQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMw JxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmls aXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29t IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRD FkFTdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENl cnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAqprh4FuMzh0b/B3GLDAgoLeTJv3xArbNESi/ Kf/HMM//gf8FzwUUNOCglH6dfYuLQQ/dTtOyMb4JoiL3T7xiVKEAOmQ+t+b/xLOMa0m18zoRqW4k 6Glyoyvc7LMrdpgYk/lEh5nq8tPd9BoNmwiiheXphIVH/QelTgUkNzTC7IVpmYVsKuNOnxE1jJFZ NNfqZZK/5Oto7C6PfOut11KmBQSLZarAz0b/mjghdBsYfHuhdO8vrOvD0g5g7dA4pkOAU2Ed4pSC owBSItyD/5aFwZ75ji6Yq7GCG3BpiyAP9st8h+inc0L+7kmrAMJaLMAmu6GZs5Xgsbzn0wUJvbD9 h5jnnMM9UaZDcxl2uLB04quGUWM6NiKGabbxQc680PYbeQrQu+e6J4uqNAxzoa5RxkBA5a/3qlbg F9uJBekCqJswx5vQ9khJrs8UTMaIFzbEC5VGQziQH3/6KJ4DUP85OJEnCx/quShWA6w318LDnba3 M6a5V+KoNLhsVi/TSxf90UbBqwdRR/cOwuGkNJh16NvvhIqO26osMg64CbZsDVrEDr7uSMV40ieB JTo49Iyt77ECOhz/pyhowa2EUP6aKav+L/wXzAPB3LNqzujGR0K1pbyFWKvyYmdungJtySWUMw+R 5DqpA2bFIOE56pfWPLHZxOL+8+r79PLFX+y2V6ExggNvMIIDawIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRp ZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1l ZGlhdGUgQ2xpZW50IENBAgME0GMwCQYFKw4DAhoFAKCCAa8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMDE5MTQxNjE0WjAjBgkqhkiG9w0BCQQxFgQUhYXrBUy5 t2CWECZx+2n7X8Lh0IQwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgME0GMwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0ECAwTQYzANBgkqhkiG9w0BAQEFAASCAQCC5He1AYzmRHQXSumOZx/or/r6SKKThXtAfrnK K7hZwzXJWBuIUjklbdDyvDjLmgLWnNgu3peo/z+HQxNiTJpO/AUhrjsNfkecZhC7VwLr60HYdu+s h+lU+mM02p1V2yW+/L5IcL/I+Bg9jZB1H/f+M43uQTkQu7ZWZAltml5WQGxedhujZ2PS2IYAcdP4 GQfj539WU8r9zL8Pba8f6WjOp4wyvH8rn4bqbxKu+oMX5JUj10S28E+uDNsYoEmUX/ij4FRXIObT CQhUEqLm+czadAKGSw3rsjJjGOn0VyZ7ZhFrMf+DAU5ZomXVZTEQV4e/2fm3qZBo1YGaZN5ajI+4 AAAAAAAA --Apple-Mail=_C2472782-3D6F-43C5-A3FE-E77CC86442EE-- From tho@koanlogic.com Fri Oct 19 07:32:53 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E0721F86E9 for ; Fri, 19 Oct 2012 07:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kS26GP29ofnF for ; Fri, 19 Oct 2012 07:32:53 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCA121F86E6 for ; Fri, 19 Oct 2012 07:32:53 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id 25so164742qao.10 for ; Fri, 19 Oct 2012 07:32:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=YS3Q0raSVNjqBALc3I4NgEwtxMH7nce3VqOQ1VOcdMw=; b=gVsqf1Y5d0WY2pTbjbcJeRDqK6HT8rmDpg8wr8XutzRJo2HPbp3YacVdZcCh2X4ktY nr6CCEEiwps+R9VpVJNXcReRJuEzFeXS8H3bwYsOku9EI9WNOmE2P0VOupnkmdo1k4vT gemCkujJwAdTCrGCBrb0RM2PIe66pLKikS6Uwjcscs9/Zjeo6RYv7yNwwdt+mHEZJLGr UFD+6mFXLIWHETMLUiRGdX11eYkdTodVfZdqYaBqkcUWPd0udId/ScPp9oPQ+e3qkKLr tNw1svyYLuLOwext9aUByrVACKU3FHWyn+qXfbzYmCZ92l1CAHuQEq5Nxb+T+8fmlG3m HLgA== MIME-Version: 1.0 Received: by 10.49.103.162 with SMTP id fx2mr838867qeb.1.1350657172607; Fri, 19 Oct 2012 07:32:52 -0700 (PDT) Received: by 10.49.26.170 with HTTP; Fri, 19 Oct 2012 07:32:52 -0700 (PDT) X-Originating-IP: [81.134.152.4] In-Reply-To: References: Date: Fri, 19 Oct 2012 15:32:52 +0100 Message-ID: From: Thomas Fossati To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlFNk9tr++dwjx847RDxCaoRiGBVx9CF06XSyEaw/fdKsrCMdxxBDlKeCOfGvtEiYUrvOT5 Subject: [saag] Input for conflict review of draft-secure-cookie-session-protocol X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 14:32:54 -0000 Hi Tobias, >> - Should this be handled by an existing working group? Which one? > Yes. A little bit of context, to hopefully give everyone the reasons why and how we are here. SCS was presented for the first time (to get expert review/feedback) to IRTF CFRG in September 2006: http://www.ietf.org/mail-archive/web/cfrg/current/msg01307.html Then after a long pause, I brought it to the IETF (http-state WG) in February 2011: http://www.ietf.org/mail-archive/web/http-state/current/msg01227.html where I've tried to propose it as a working group item, with no avail. (Please note that this pre-dates JOSE BoF which was held in March 2011 IIRC.) So, the natural outcome was to go through ISE, which I've done in December 2011. In these years, in different occasions it has received extensive review by a couple of well known and respected security guys -- David Wagner and Jim Schaad. The whole shebang is nothing new, just a simple bearer token format which is suitable for use in HTTP (in cookies and URIs, or any other HTTP header value). With the added value that it can be traced back to a provably secure authenticated encryption scheme. I've taken the trouble to publish as I though it could provide a solid and reusable building block for developers, that, as a bonus, are also given a reference open-source implementation. The Security Consideration has plenty of material about the possible risks and related countermeasures / mitigations. If there's something that really needs to be said and it's not already there, please state it precisely and I'll do the needed editing. I like to hear solid technical comments, I really like it, and I'm totally open to modify the I-D as long as the proposed modifications makes it a better document. This is the sole purpose of going through the IETF process, after all. Thanks, Thomas. From henry.story@bblfish.net Fri Oct 19 10:47:38 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1192B21F8794 for ; Fri, 19 Oct 2012 10:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeCYrF0bT2O0 for ; Fri, 19 Oct 2012 10:47:37 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id CA30E21F8538 for ; Fri, 19 Oct 2012 10:47:36 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so442030wey.31 for ; Fri, 19 Oct 2012 10:47:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=thRPhYcff7B0JSKJh2gFRMTc51vteQP1PMilBT+E9p0=; b=e7OAu5uupshTMTTbj1OBs5F0n8Bw6YLXByWR8bv9uLlJgyftAhUDxasnPL9i8e6LhW lKpu1aw8qh1S/UyVAvMwgEbqBb5VO71dRXRPZxSIBywXzVW5nHn9tApm7WaKa8RBUduj hoFfBFNDDwM55XDbhxxMDUwslNRVC1yP4rZTMYUBsOHLU3lWa6q2Z+A+6oDN9rufXrx+ D5tidCQg6mZDaUxRexTMGD7btWaAAd1NmCYRbnwYIjBw75kF+Da8GM9bxxPFs3EOKnsY 6Ndj8/J+yltxdZYR8uQhXDSbWxiECx0RAJnWTnyxQF79Z2fONcqmdrnGWJVluce/0e6I Z39A== Received: by 10.216.227.102 with SMTP id c80mr1185850weq.112.1350668855598; Fri, 19 Oct 2012 10:47:35 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-132-122.w86-198.abo.wanadoo.fr. [86.198.99.122]) by mx.google.com with ESMTPS id b7sm35863793wiz.3.2012.10.19.10.47.25 (version=SSLv3 cipher=OTHER); Fri, 19 Oct 2012 10:47:33 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_C87CC88A-2143-4DA3-845D-4C1732934459"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Henry Story In-Reply-To: <50818E4F.3040104@openlinksw.com> Date: Fri, 19 Oct 2012 19:47:23 +0200 Message-Id: References: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <50818E4F.3040104@openlinksw.com> To: Kingsley Idehen X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQk2kgjhQsHgXItiMlE7uW9mJ1wldTRAPglDCxUaHte0bYnOqem38TLfFMmo1+MHSTGaqnLD Cc: "public-philoweb@w3.org" , "public-identity@w3.org" , "saag@ietf.org" , "public-privacy@w3.org" , Sam Hartman Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 17:47:38 -0000 --Apple-Mail=_C87CC88A-2143-4DA3-845D-4C1732934459 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 19 Oct 2012, at 19:30, Kingsley Idehen = wrote: > On 10/19/12 9:31 AM, Ben Laurie wrote: >>> >So perhaps it is up to you to answer: why should I not want that? >> I am not saying you should not want that, I am saying that ACLs on = the >> resources do not achieve unlinkability. >>=20 >=20 > You keep on saying this but I simply don't agree. I gave you an = example of a PKCS#12 file sent to you and a phone call during which its = access password is exchanged. How do you the recipient of that data even = understand the basis of the data access policy associated with the = protected resource to which it will provide access? You don't know the = nature of my data access policy. It doesn't say: grant access to the = subject of this certificate. But seem to assume that it can only test = that claim when you repeat the claim above. Kingsley: Ben is saying that you don't achieve unlinkability because the = situations Ben Laurie is thinking of are those such as Wikileaks where = you need to consider the site you are connecting to as the enemy. Even = if all knew were your public key it could report that it has proven that = someone knowing the private key of public key PK has connected. Ben makes this clear in the e-mail here: = http://lists.w3.org/Archives/Public/public-privacy/2012OctDec/0079.html The answer is simple:=20 that is just a use case that WebID is not meant for. For such use = cases any linkability is problematic. But we are trying to build a = social web, so clearly linkability at some level is necessary for what = we want to do. Before you argue with someone about "linkability" problem, just ask them = who they consider to be the enemy. Say if you considered yourself in the = future to be the enemy, you'd have even more trouble coming up with a = good solution. :-) >=20 > You don't know the logic behind my assessment of your nebulous = identity. You aren't in my head. The beauty of logic is that it allows = me express a good chunk of what's in my head via notation. >=20 > A machine is linkable via DNS. A document is linkable via an HTTP URL, = I am not linkable because I (like you and every other human) is endowed = with cognitive powers and the ability to exploit temporality. We are = really difficult to pin down, even more so with the explosion of = networking devices, software etc.. that are loosely associated with us. >=20 > I can't stop you using the words, but I can assure you that you claims = are refutable via logic. >=20 > What I would really like you to do is point us to an working example = of something that meets your goals. Then we have something to compare. = Bottom line, somebody will learn something useful and everyone will be = ultimately be better off etc.. >=20 > Links: >=20 > 1. = http://www.guardian.co.uk/commentisfree/belief/2009/jul/27/heidegger-being= -time-philosophy=20 > 2. http://twitpic.com/1g03vo/full -- you can't really pin down the = entity depicted in that image, contrary to what you might think due to = Web perception illusion. >=20 > --=20 >=20 > Regards, >=20 > Kingsley Idehen > Founder & CEO > OpenLink Software > Company Web: http://www.openlinksw.com > Personal Weblog: http://www.openlinksw.com/blog/~kidehen > Twitter/Identi.ca handle: @kidehen > Google+ Profile: https://plus.google.com/112399767740508618350/about > LinkedIn Profile: http://www.linkedin.com/in/kidehen >=20 >=20 > --=20 >=20 > Regards, >=20 > Kingsley Idehen=09 > Founder & CEO > OpenLink Software > Company Web: http://www.openlinksw.com > Personal Weblog: http://www.openlinksw.com/blog/~kidehen > Twitter/Identi.ca handle: @kidehen > Google+ Profile: https://plus.google.com/112399767740508618350/about > LinkedIn Profile: http://www.linkedin.com/in/kidehen >=20 >=20 >=20 >=20 >=20 Social Web Architect http://bblfish.net/ --Apple-Mail=_C87CC88A-2143-4DA3-845D-4C1732934459 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPDTCCByMw ggYLoAMCAQICAwTQYzANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEyMDgyOTAxNDU1NloXDTEzMDgzMDA5MjM0MFowZTEZMBcGA1UEDRMQazQ2eDlvOXJDRE5m VzMwYzEgMB4GA1UEAwwXaGVucnkuc3RvcnlAYmJsZmlzaC5uZXQxJjAkBgkqhkiG9w0BCQEWF2hl bnJ5LnN0b3J5QGJibGZpc2gubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArHXp EmiifOSpudkJn1vAnFdZsuaLuYYLbdWL47o1rKD/kg8/RJUmTIM2ara4e/MOxR16mu2fyAca3H1U oIXNNXDbYQDu2PkfLoNSM5JGAoYbfB0nXBK//ZecidVMZ8eExd02/vFzo5vj9kQNaAPSYirid5xe 1cV9Y1RFjlEozuYAUhU8zi3taf22JM45ii2YrCEgVjDdez8yio0QoJeKEEL3JhL4tqpkbfIOHmdi HYx00S6YcCogDfxXc3zOJ3jcIj/F61eXG1qWX/lq9RAyoBjYHLWE2iHQPwdzum03ubcvOTlohqOR +/cVzvx10l6bJ46KitfbydXMh8HoY7QcmwIDAQABo4IDsjCCA64wCQYDVR0TBAIwADALBgNVHQ8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQRbT9qwRblII9x nAN2FlEMUD1LQzAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAiBgNVHREEGzAZgRdo ZW5yeS5zdG9yeUBiYmxmaXNoLm5ldDCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIw ggH/MC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsG AQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEF BQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9u IHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZv ciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5 IG9ibGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBTZWUg c2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5 LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3Js MIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20v c3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29t L2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALj/A19bRLmI7sMf0lVRrdN23NuRC7/UFSLZ DfcxrR1wOtQgAbrFlFLY+Otn6UWYIiWQpv2v5Ploqw9rMam5W8seC3TUt83StohXCmZ0EDmK87If B6kpd7FwJ0RFGCxn22hPU2kuhp2mbjJzCTrd3jWsXw63MXDUzHuucWGX2mY1Ji+zRECh568N7iWA 5jn9kWT+h7o7ywKbHc4qAnksghLYAnTfoCx1IPkT4/8A5hf38imhf9NcNGibrvt/e49sacf6GjRH Ot/lOCrEX2fh2YvTB5sdEKM5tjKCKNpFSqnRCKhsWZ9N9ZP7mRZfCOBjAMsm3CW2ygwlWXc54lgf p1UwggfiMIIFyqADAgECAgENMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQy MTAxNTRaFw0xMjEwMjIyMTAxNTRaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP 6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu 2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyU GHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmt xWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMB AAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUU3Ltkpzg2ssB XHx+ljVO8tS4UYIwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0 YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHmCAQEwCQYDVR0SBAIwADA9BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYB BQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMw JxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmls aXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29t IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRD FkFTdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENl cnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAqprh4FuMzh0b/B3GLDAgoLeTJv3xArbNESi/ Kf/HMM//gf8FzwUUNOCglH6dfYuLQQ/dTtOyMb4JoiL3T7xiVKEAOmQ+t+b/xLOMa0m18zoRqW4k 6Glyoyvc7LMrdpgYk/lEh5nq8tPd9BoNmwiiheXphIVH/QelTgUkNzTC7IVpmYVsKuNOnxE1jJFZ NNfqZZK/5Oto7C6PfOut11KmBQSLZarAz0b/mjghdBsYfHuhdO8vrOvD0g5g7dA4pkOAU2Ed4pSC owBSItyD/5aFwZ75ji6Yq7GCG3BpiyAP9st8h+inc0L+7kmrAMJaLMAmu6GZs5Xgsbzn0wUJvbD9 h5jnnMM9UaZDcxl2uLB04quGUWM6NiKGabbxQc680PYbeQrQu+e6J4uqNAxzoa5RxkBA5a/3qlbg F9uJBekCqJswx5vQ9khJrs8UTMaIFzbEC5VGQziQH3/6KJ4DUP85OJEnCx/quShWA6w318LDnba3 M6a5V+KoNLhsVi/TSxf90UbBqwdRR/cOwuGkNJh16NvvhIqO26osMg64CbZsDVrEDr7uSMV40ieB JTo49Iyt77ECOhz/pyhowa2EUP6aKav+L/wXzAPB3LNqzujGR0K1pbyFWKvyYmdungJtySWUMw+R 5DqpA2bFIOE56pfWPLHZxOL+8+r79PLFX+y2V6ExggNvMIIDawIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRp ZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1l ZGlhdGUgQ2xpZW50IENBAgME0GMwCQYFKw4DAhoFAKCCAa8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMDE5MTc0NzI0WjAjBgkqhkiG9w0BCQQxFgQUD2I9tLYC G29j8RH5TsRy0wggrywwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgME0GMwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0ECAwTQYzANBgkqhkiG9w0BAQEFAASCAQBj/wVeYFw0eg8GqciTLB00/+qafmBpImPNI7GD BV0gau4zdJNCH9pxFqRCa32KYR7sdj566OyGsPGWIrtTcGAyqqNzAFJwhkBF7MWxFZq7xp5f2jb5 zv2iyDPcwVZtw4CjkJUFLml+KNA5zSNeVa/6wsPiVI9xsahmgHOA7sL+uQGYSvIF9jMg1yyiMYFB 9GEHs8JuwC6vgRu3FpA4MIVL9j4j9krpf5otDu9qr9W1fC98qOJkQySJJcOcEBhfTFwdqeK0UUNz vtclK/lcY8eZKmlxIsSOy4M+n2FuFhNLvqv1sdcvs0fla3zN4Cf22duWxFsn+z5DDGIhNeQi89G+ AAAAAAAA --Apple-Mail=_C87CC88A-2143-4DA3-845D-4C1732934459-- From tobias.gondrom@gondrom.org Sat Oct 20 02:29:06 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15AC321F8532 for ; Sat, 20 Oct 2012 02:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.362 X-Spam-Level: X-Spam-Status: No, score=-95.362 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIvWaZueocRo for ; Sat, 20 Oct 2012 02:29:05 -0700 (PDT) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id D6DEE21F850B for ; Sat, 20 Oct 2012 02:29:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=tQzk4hHZSBd5ZMMH36MFPjw7gi1QgHhMPT/vRvUX/oWxm1BejeLqjFGzvdwt6EmAY5Pcc2l+aGG+ILrDNDU/fEOI7zhWbwZ2SYrbE7qSzM7KwgOD6zUEqkB1x1NZp2JG; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 9507 invoked from network); 20 Oct 2012 11:29:02 +0200 Received: from 188-223-113-88.zone14.bethere.co.uk (HELO ?192.168.1.65?) (188.223.113.88) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 20 Oct 2012 11:29:02 +0200 Message-ID: <50826EDE.6000509@gondrom.org> Date: Sat, 20 Oct 2012 10:29:02 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: tho@koanlogic.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: saag@ietf.org Subject: Re: [saag] Input for conflict review of draft-secure-cookie-session-protocol X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 09:29:06 -0000 Hi Thomas, thank you for providing the background about this. Obviously I didn't know about the IRTF CFRG, as I did not attend that IRTF group meeting at the time. And I can imagine it can be quite frustrating for you having to explain the history and your draft again and again to the different audiences and groups over the years. ;-) Maybe some thoughts on why I think this would benefit from IETF review: I can see the underlying idea and understand the potential use case of storing state on the client in an encrypted container. However, I see quite a few potential issues that could arise with this draft. I am not saying "don't do it", all I am saying is that I really think this deserves IETF review (either in saag, or even better an IETF WG (not IRTF). Just as an example: already the very first sentence in the introduction some assumptions are half-true/half-false (like e.g. that cookies would be "... un-authenticated and sent in clear text." In many applications (though not all of them) cookies are in fact transmitted over HTTPS and in an authenticated session and not in clear-text...) A number of questions with this drafts make me suggest that IETF review is a good thing (including the question whether IETF wants to do this at all): - is the underlying use case valid for the draft? I am not sure of that. - the text of the draft would hint towards status as Experimental, not as Informational? Why Informational? - Is there the vision of interoperability between different implementations for this? Please note, that I don't deny at all, that there is a security considerations section - and in the case of this draft, I actually like that it is quite detailed on security implications compared to some other drafts I've reviewed in the past years, but I would question whether in fact suggesting to store server state only in a client is a good idea at all, as it opens quite a number of security problems. All this leads me to the recommendation to apply IETF review for this draft to avoid trouble. However, this is only IMHO, for you, saag and the ADs to consider. And I have the highest regard for Jim and our other reviewers. So consider this just as my 5cents and I will hand over to others on saag (including Jim) to comment and decide on whether we should give this more IETF review or not... Best regards, Tobias On 19/10/12 15:32, Thomas Fossati wrote: > Hi Tobias, > >>> - Should this be handled by an existing working group? Which one? >> Yes. > A little bit of context, to hopefully give everyone the reasons why > and how we are here. > > SCS was presented for the first time (to get expert review/feedback) > to IRTF CFRG in September 2006: > > http://www.ietf.org/mail-archive/web/cfrg/current/msg01307.html > > Then after a long pause, I brought it to the IETF (http-state WG) in > February 2011: > > http://www.ietf.org/mail-archive/web/http-state/current/msg01227.html > > where I've tried to propose it as a working group item, with no avail. > (Please note that this pre-dates JOSE BoF which was held in March 2011 IIRC.) > > So, the natural outcome was to go through ISE, which I've done in December 2011. > > > In these years, in different occasions it has received extensive > review by a couple of well known and respected security guys -- David > Wagner and Jim Schaad. > > The whole shebang is nothing new, just a simple bearer token format > which is suitable for use in HTTP (in cookies and URIs, or any other > HTTP header value). With the added value that it can be traced back > to a provably secure authenticated encryption scheme. > > I've taken the trouble to publish as I though it could provide a solid > and reusable building block for developers, that, as a bonus, are also > given a reference open-source implementation. > > The Security Consideration has plenty of material about the possible > risks and related countermeasures / mitigations. If there's something > that really needs to be said and it's not already there, please state > it precisely and I'll do the needed editing. > > I like to hear solid technical comments, I really like it, and I'm > totally open to modify the I-D as long as the proposed modifications > makes it a better document. This is the sole purpose of going through > the IETF process, after all. > > Thanks, Thomas. > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From hannes.tschofenig@gmx.net Sat Oct 20 03:17:26 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F09421F855B for ; Sat, 20 Oct 2012 03:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.404 X-Spam-Level: X-Spam-Status: No, score=-102.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9TbwcGQfzTI for ; Sat, 20 Oct 2012 03:17:25 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 28D6B21F84FE for ; Sat, 20 Oct 2012 03:17:24 -0700 (PDT) Received: (qmail invoked by alias); 20 Oct 2012 10:17:23 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.216.191] by mail.gmx.net (mp031) with SMTP; 20 Oct 2012 12:17:23 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/po7Rz7gHpj9stSz4JEXeoDlBLxkgX9UnsKsOEhy CZBVxDxxnXX/do Message-ID: <50827A2A.8000804@gmx.net> Date: Sat, 20 Oct 2012 13:17:14 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Tobias Gondrom References: <50826EDE.6000509@gondrom.org> In-Reply-To: <50826EDE.6000509@gondrom.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: saag@ietf.org Subject: Re: [saag] Input for conflict review of draft-secure-cookie-session-protocol X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 10:17:26 -0000 Is it correct to summarize the proposal in the following way: * The server can encrypt and integrity protect a cookie before it sends it to the client. * No updates are required on the client side, i.e., the client does not perform any cryptographic computation Ciao Hannes On 10/20/2012 12:29 PM, Tobias Gondrom wrote: > Hi Thomas, > > thank you for providing the background about this. > Obviously I didn't know about the IRTF CFRG, as I did not attend that > IRTF group meeting at the time. > And I can imagine it can be quite frustrating for you having to explain > the history and your draft again and again to the different audiences > and groups over the years. ;-) > > Maybe some thoughts on why I think this would benefit from IETF review: > I can see the underlying idea and understand the potential use case of > storing state on the client in an encrypted container. > > However, I see quite a few potential issues that could arise with this > draft. I am not saying "don't do it", all I am saying is that I really > think this deserves IETF review (either in saag, or even better an IETF > WG (not IRTF). > > Just as an example: already the very first sentence in the introduction > some assumptions are half-true/half-false (like e.g. that cookies would > be "... un-authenticated and sent in clear text." In many applications > (though not all of them) cookies are in fact transmitted over HTTPS and > in an authenticated session and not in clear-text...) > > A number of questions with this drafts make me suggest that IETF review > is a good thing (including the question whether IETF wants to do this at > all): > - is the underlying use case valid for the draft? I am not sure of that. > - the text of the draft would hint towards status as Experimental, not > as Informational? Why Informational? > - Is there the vision of interoperability between different > implementations for this? > > Please note, that I don't deny at all, that there is a security > considerations section - and in the case of this draft, I actually like > that it is quite detailed on security implications compared to some > other drafts I've reviewed in the past years, but I would question > whether in fact suggesting to store server state only in a client is a > good idea at all, as it opens quite a number of security problems. > > All this leads me to the recommendation to apply IETF review for this > draft to avoid trouble. > > However, this is only IMHO, for you, saag and the ADs to consider. And I > have the highest regard for Jim and our other reviewers. So consider > this just as my 5cents and I will hand over to others on saag (including > Jim) to comment and decide on whether we should give this more IETF > review or not... > > Best regards, Tobias > > > > On 19/10/12 15:32, Thomas Fossati wrote: >> Hi Tobias, >> >>>> - Should this be handled by an existing working group? Which one? >>> Yes. >> A little bit of context, to hopefully give everyone the reasons why >> and how we are here. >> >> SCS was presented for the first time (to get expert review/feedback) >> to IRTF CFRG in September 2006: >> >> http://www.ietf.org/mail-archive/web/cfrg/current/msg01307.html >> >> Then after a long pause, I brought it to the IETF (http-state WG) in >> February 2011: >> >> http://www.ietf.org/mail-archive/web/http-state/current/msg01227.html >> >> where I've tried to propose it as a working group item, with no avail. >> (Please note that this pre-dates JOSE BoF which was held in March 2011 >> IIRC.) >> >> So, the natural outcome was to go through ISE, which I've done in >> December 2011. >> >> >> In these years, in different occasions it has received extensive >> review by a couple of well known and respected security guys -- David >> Wagner and Jim Schaad. >> >> The whole shebang is nothing new, just a simple bearer token format >> which is suitable for use in HTTP (in cookies and URIs, or any other >> HTTP header value). With the added value that it can be traced back >> to a provably secure authenticated encryption scheme. >> >> I've taken the trouble to publish as I though it could provide a solid >> and reusable building block for developers, that, as a bonus, are also >> given a reference open-source implementation. >> >> The Security Consideration has plenty of material about the possible >> risks and related countermeasures / mitigations. If there's something >> that really needs to be said and it's not already there, please state >> it precisely and I'll do the needed editing. >> >> I like to hear solid technical comments, I really like it, and I'm >> totally open to modify the I-D as long as the proposed modifications >> makes it a better document. This is the sole purpose of going through >> the IETF process, after all. >> >> Thanks, Thomas. >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From benlaurie@gmail.com Sun Oct 21 03:18:44 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0570C21F88BD for ; Sun, 21 Oct 2012 03:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.727 X-Spam-Level: X-Spam-Status: No, score=-2.727 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUeGns2vjElY for ; Sun, 21 Oct 2012 03:18:43 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6355321F846C for ; Sun, 21 Oct 2012 03:18:43 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so2167819vcb.31 for ; Sun, 21 Oct 2012 03:18:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3mj8GxzZ8OouDVJLOa8nSfrS3QwTmAL7RT9OUhPMk+A=; b=Yr3csMErcBOKJdSvLKNg88VU0E6Yuk5pX2pZZdZ3UJENdN6Or1bO08Mwi0aFjLiq8u azNGWxd60tuOhyrhCPVAMZlZU01ZQzYmRVhc0hDn4nZFboGDdYeGH6iiViGZpF3hkSOd +EPtu4CGQKOABIm4eO1brHzxJBbIafZ2vpXBikScu0R0TdPHQDFgzthN9mrFXGZGZYqX gmVcIXmpQTW6Qlu8HaqpbS6V+VOaKUqlh4EagdYqF8nb4rQXeU3XQXuRzw7NAAlkd4YH x3qhsYIBCWwKU98bsHEkiG0s2iCdTQjJyR4oloq9x7QxsFP/3gzvDQEisDhebqCxVB7f jKIQ== MIME-Version: 1.0 Received: by 10.52.33.130 with SMTP id r2mr7385083vdi.43.1350814722624; Sun, 21 Oct 2012 03:18:42 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.58.18.235 with HTTP; Sun, 21 Oct 2012 03:18:42 -0700 (PDT) In-Reply-To: References: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> Date: Sun, 21 Oct 2012 11:18:42 +0100 X-Google-Sender-Auth: Zeqyde4RPASQEx_elog_QTyWJa0 Message-ID: From: Ben Laurie To: Mo McRoberts Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "public-philoweb@w3.org" , "public-identity@w3.org" , "saag@ietf.org" , "public-privacy@w3.org" , Sam Hartman , "public-webid@w3.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 10:18:44 -0000 On Sun, Oct 21, 2012 at 9:24 AM, Mo McRoberts wrot= e: > > On 18 Oct 2012, at 20:29, Ben Laurie wrote: > >> I really feel like I am beating a dead horse at this point, but >> perhaps you'll eventually admit it. Your public key links you. Access >> control on the rest of the information is irrelevant. Indeed, access >> control on the public key is irrelevant, since you must reveal it when >> you use the client cert. Incidentally, to observers as well as the >> server you connect to. > > > Right, but that's the nature of a persistent identifier which is (surely)= a prerequisite for auth =97 assuming one doesn't wish to remain anonymous = and have some auth, you could hypothetically avoid the cross-domain linkabi= lity issue by having a key-per-site, which could be semi-automated on the c= lient side. > > What I can't see is how you can maintain persistence on the server side w= ithout something which ultimately boils down to (or otherwise allows the st= orage of) a persistent identifier. Obviously. I'm talking about linkability across sites. > > M. > > -- > Mo McRoberts - Technical Lead - The Space > 0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E, > Zone 1.08, BBC Scotland, Pacific Quay, Glasgow, G51 1DA > Project Office: Room 7083, BBC Television Centre, London W12 7RJ > > > > ----------------------------- > http://www.bbc.co.uk > This e-mail (and any attachments) is confidential and > may contain personal views which are not the views of the BBC unless spec= ifically stated. > If you have received it in > error, please delete it from your system. > Do not use, copy or disclose the > information in any way nor act in reliance on it and notify the sender > immediately. > Please note that the BBC monitors e-mails > sent or received. > Further communication will signify your consent to > this. Oh really? Further communication will signify your agreement to send me =A3= 10,000. From stephen.farrell@cs.tcd.ie Sun Oct 21 04:24:22 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440FD21F844C for ; Sun, 21 Oct 2012 04:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bd3LQQNjg9zg for ; Sun, 21 Oct 2012 04:24:21 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 2334621F843B for ; Sun, 21 Oct 2012 04:24:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 9237417147B; Sun, 21 Oct 2012 12:24:18 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1350818657; bh=TPAvBSusKG8tHN JTzsG6QI6yHGseNc3EzBHcBGk0os8=; b=wEMare2r3PRwH0/Y943GDXAjXWZvGj inReuKAA52t5tQWZ8doR3iWZOiXvRSKdwtejblXrzw4DiFN5IVhFyU7UIFCKRmci 2xjMDpuVa8Kbti0cCYlQ4FKzRY5UNJflqXNz0K+DGJ+9W7osFI+7/tiud4t3jGlO Fo7SHdr2SypYGkpgTeSZegTWUMMewPQPMOVoXQYyxbrtKQmiLv+X6YIlxQVrTX6F z5mjUPi4qVSoGxskxTiUpelq7jR/QOQ0XQtFDS1zaUXJ52dTztLYGXveVdKucoCQ OYDW/UPku8C45EA6uxXTxI3cTykT9QO2z6U9Cry1qGCKcvNy2C4Pi/zQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id tI2cOqmyOdPz; Sun, 21 Oct 2012 12:24:17 +0100 (IST) Received: from [10.87.48.4] (unknown [86.41.0.97]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 594C4171478; Sun, 21 Oct 2012 12:24:11 +0100 (IST) Message-ID: <5083DB5B.6010401@cs.tcd.ie> Date: Sun, 21 Oct 2012 12:24:11 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121017 Thunderbird/16.0.1 MIME-Version: 1.0 To: saag@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-secure-cookie-session-protocol@tools.ietf.org, Nevil Brownlee Subject: Re: [saag] Input for conflict review of draft-secure-cookie-session-protocol X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 11:24:22 -0000 So looking at the mails on this, it strikes me that maybe if the document had a slightly different title that might resolve all the 5742 concerns about whether or not it conflicts with IETF work. If it were called "KoanLogic's Secure cookie Sessions for HTTP" would that then be ok? IMO, it ought. That way, the independent-stream RFC won't confuse anyone into thinking that the IETF as a whole has developed this, but if some IETF WG wants to do similar work, this could be useful input. (And adding one word seems likely quicker than organising and coming to IETF rough consensus;-) What do folks (incl. authors) think of that? I realise that the above suggested name isn't quite on the button, since no doubt a lot of sites manage cookies in almost the same way. But maybe its good-enough. Cheers, S. On 10/18/2012 03:13 AM, Barry Leiba wrote: > A document titled "Secure Cookie Sessions for HTTP" has been submitted > to the Independent Stream Editor (ISE): > http://datatracker.ietf.org/doc/draft-secure-cookie-session-protocol/ > > The IESG has been asked to review the document, as specified in RFC > 5742, Section 3. The Security and Applications Area Directors are > looking for input for that review. Please post any relevant comments > to this list, , as soon as possible, and at least by 1 > November 2012. > > Please read RFC 5742, Section 3, and be aware that we are not looking > for detailed comments on the document itself (see below). We > specifically need input on whether this document is in conflict with > work that's being done in the IETF. Look at the five possible > responses specified in that section, and help us determine whether any > of 2 through 5 applies. Please be specific in your response. > > In addition to this, we're sure that the authors and the ISE would > appreciate comments about the document. If you have those, you may > send them directly to the authors at > > and to the ISE at . > General discussion of the document on this list will likely not get to the > authors or the ISE. > > Barry Leiba, Applications AD > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > From housley@vigilsec.com Sun Oct 21 07:37:44 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D65F21F897A for ; Sun, 21 Oct 2012 07:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.62 X-Spam-Level: X-Spam-Status: No, score=-102.62 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEA9oSYcFzPZ for ; Sun, 21 Oct 2012 07:37:43 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id BE6A721F89C4 for ; Sun, 21 Oct 2012 07:37:43 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 808C59A4002 for ; Sun, 21 Oct 2012 10:37:48 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 6kLZps276U6a for ; Sun, 21 Oct 2012 10:37:40 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-37-162.washdc.fios.verizon.net [96.255.37.162]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id DFD1D9A4001 for ; Sun, 21 Oct 2012 10:37:45 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 21 Oct 2012 10:37:39 -0400 References: <20121020231931.10454.3134.idtracker@ietfa.amsl.com> To: IETF SAAG Message-Id: Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [saag] Fwd: I-D Action: draft-iab-identifier-comparison-05.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 14:37:44 -0000 This document is in the final stages. If you have last minute comments, = please send them to iab@iab.org very soon. Russ > From: internet-drafts@ietf.org > Date: October 20, 2012 7:19:31 PM EDT > To: i-d-announce@ietf.org > Cc: iab@iab.org > Subject: [IAB] I-D Action: draft-iab-identifier-comparison-05.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Internet Architecture Board Working = Group of the IETF. >=20 > Title : Issues in Identifier Comparison for Security = Purposes > Author(s) : Dave Thaler > Filename : draft-iab-identifier-comparison-05.txt > Pages : 23 > Date : 2012-10-20 >=20 > Abstract: > Identifiers such as hostnames, URIs, and email addresses are often > used in security contexts to identify security principals and > resources. In such contexts, an identifier supplied via some > protocol is often compared against some policy to make security > decisions such as whether the principal may access the resource, = what > level of authentication or encryption is required, etc. If the > parties involved in a security decision use different algorithms to > compare identifiers, then failure scenarios ranging from denial of > service to elevation of privilege can result. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-iab-identifier-comparison >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-iab-identifier-comparison-05 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-iab-identifier-comparison-05 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 From benlaurie@gmail.com Sun Oct 21 09:49:56 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D01921F89C6 for ; Sun, 21 Oct 2012 09:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6gl9TaD97vd for ; Sun, 21 Oct 2012 09:49:55 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 719C021F89B7 for ; Sun, 21 Oct 2012 09:49:55 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so2382874vbb.31 for ; Sun, 21 Oct 2012 09:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=rfb9/xVYAP3v288ew7gJxuHEHttBHAcoaFcwmK0cD0Y=; b=DJEL2gExIBZYlZkF34MFl8IBHKmgNrNIjeuDU1m+/1c6xijEVTFwzyuedwWKH9uvYi S+JD5C5c4H4nDMt2lrGhRrDu2mVEuUblpZ9oEfUTEtRxS0259WPtxsS/p4ufMkg4Lslc c9HmaNjwpzgzvHWMI6e2XRg6AZCui5wsOEvGBB0cwoMaZRbp7L/MQ8tJ+6rJ+uk/Rys9 rFdST3Bg8zFpqKn6VSn6Ut6UCCLtlPOSc+JrZWKgD/rzUsFmiED8ftj0qdOcbwbD3p7t 8uJXHJBjJCRa8+xIuUwSZe4rJUXNUoGos9XS8IRltqdtfR2UW/97etL8S6hw9y/e0FoN w8tw== MIME-Version: 1.0 Received: by 10.220.39.206 with SMTP id h14mr654386vce.41.1350838194873; Sun, 21 Oct 2012 09:49:54 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.58.18.235 with HTTP; Sun, 21 Oct 2012 09:49:54 -0700 (PDT) In-Reply-To: <5084238D.9040106@openlinksw.com> References: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <5084238D.9040106@openlinksw.com> Date: Sun, 21 Oct 2012 17:49:54 +0100 X-Google-Sender-Auth: pcROWQz6YSVsn_8ROwG_iRngD08 Message-ID: From: Ben Laurie To: Kingsley Idehen Content-Type: text/plain; charset=ISO-8859-1 Cc: "public-philoweb@w3.org" , "public-identity@w3.org" , "saag@ietf.org" , "public-privacy@w3.org" , Sam Hartman , "public-webid@w3.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 16:49:56 -0000 On Sun, Oct 21, 2012 at 5:32 PM, Kingsley Idehen wrote: > On 10/18/12 3:29 PM, Ben Laurie wrote: >>> >>> from any person that was not able to access the resources. But you would >>> >be linkable by your friends. I think you want both. Linkability by those >>> >authorized, unlinkability for those unauthorized. Hence linkability is >>> > not >>> >just a negative. >> >> I really feel like I am beating a dead horse at this point, but >> perhaps you'll eventually admit it. Your public key links you. Access >> control on the rest of the information is irrelevant. Indeed, access >> control on the public key is irrelevant, since you must reveal it when >> you use the client cert. Incidentally, to observers as well as the >> server you connect to. >> >> >> >> > A public key links to a private key. > > It could also link to a machine -- due to resolvable machine names on the > Internet due to DNS . > > It could also link to composite of a machine, user agent, and referrer > document -- due to resolvable document names on the Web of Documents due to > HTTP. > > It doesn't provide the high precision link that you speculate about > (repeatedly) re. a Web of Linked Data -- since the referent of a Linked Data > URI is potentially nebulous e.g., entities "You" and "I" . Ah, I agree that the key does not inherently link back to a particular person. What it links is the various interactions that occur under the identity represented by that key. As we know from various anonymity disasters (the AOL search terms and Netflix incidents being the best known), it is not hard, in practice, to go back from those interactions to the person behind them. To be clear: linkability does _not_ refer to the ability to link events to people (or machines). It refers to the ability to link events to each other. The reason linkability is a privacy problem is that it turns out that in practice you do not need very many linked events to figure out who was behind them. I am sorry if that has not been clear from the start. > I know you don't want to concede this reality, but stop making it sound like > those that oppose your view are simply being obstinate. You are the one > being utterly obstinate here. I encourage you to make you point with clear > examples so that others can juxtapose your views and ours. > > Back to you. > > > > -- > > Regards, > > Kingsley Idehen > Founder & CEO > OpenLink Software > Company Web: http://www.openlinksw.com > Personal Weblog: http://www.openlinksw.com/blog/~kidehen > Twitter/Identi.ca handle: @kidehen > Google+ Profile: https://plus.google.com/112399767740508618350/about > LinkedIn Profile: http://www.linkedin.com/in/kidehen > > > > > From tho@koanlogic.com Sun Oct 21 12:49:06 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E46C21F8A75 for ; Sun, 21 Oct 2012 12:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uh9UwaoUyxmw for ; Sun, 21 Oct 2012 12:49:06 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id EE1A821F8722 for ; Sun, 21 Oct 2012 12:49:05 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id s14so1369949qcg.31 for ; Sun, 21 Oct 2012 12:49:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=JdkZRy/ZVzzipZIHSSvKq0hhwgTJTj+wjCr7vc2BKOs=; b=Cjwt1XTfBYCEYSLpVRXJBL3R30Cv4Ms4Cq2tRuPQx2uRHl9dtOEICKE7Pfez8hYJpz WKvsSgKHTI4c07pQAP5ly5sDviaffGLcMISNGQPugknklavxfhsZYWPCW8fbeaVCvsIj E2HYfEqv0ZGogJd75nONFxkjaXuN8pJXRlhdoaTZ2QVisqCD5TjoGNzQfaPLnFgyYxuY g71EXareEpZ4hKvPPnqCP8C6VAaXc+vo87PxANOZFhrAa7ixg2+4da/rsMobORQ3pd6T QZ+iXmsV3f7xxq46CEAyjzh7ZNBR/k+D1nX6AVypZcUo+67o+qXUj+TGOUaK3WniEer2 zFxA== MIME-Version: 1.0 Received: by 10.49.49.234 with SMTP id x10mr3832223qen.53.1350848945012; Sun, 21 Oct 2012 12:49:05 -0700 (PDT) Received: by 10.49.26.170 with HTTP; Sun, 21 Oct 2012 12:49:04 -0700 (PDT) X-Originating-IP: [79.46.233.174] In-Reply-To: <5083DB5B.6010401@cs.tcd.ie> References: <5083DB5B.6010401@cs.tcd.ie> Date: Sun, 21 Oct 2012 20:49:04 +0100 Message-ID: From: Thomas Fossati To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkqHbwbnBl6rnW2YDesi0ZjFtNH5MGBmNYGyxS7R/TT4au9HPkxQNBuJNazaFoFdzZIRPZK Cc: draft-secure-cookie-session-protocol@tools.ietf.org, saag@ietf.org, Nevil Brownlee Subject: Re: [saag] Input for conflict review of draft-secure-cookie-session-protocol X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 19:49:06 -0000 Hi Stephen, On Sun, Oct 21, 2012 at 12:24 PM, Stephen Farrell wrote: > What do folks (incl. authors) think of that? I think you've hit the point, and (as author) I share the proposed way-out. I only have a bit of concern about sticking the name of a company in the title, which seems quite an unusual practice... Would "HTTP-friendly authentication tokens" be a less controversial synthesis for what SCS actually is ? From stephen.farrell@cs.tcd.ie Sun Oct 21 14:00:05 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841D721F869C for ; Sun, 21 Oct 2012 14:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8W5w-1KqRrKh for ; Sun, 21 Oct 2012 14:00:00 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 613FB21F8435 for ; Sun, 21 Oct 2012 14:00:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 823A117147A; Sun, 21 Oct 2012 21:59:58 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1350853198; bh=V/C+T6pq1WQ1tH Mm3T93DK8YltDrrFHYijBNpysGUm0=; b=5e84nwM0s40OfG61LiyIxrVk+xHwzp vPavMd/7EHI47uCdMbFWjFp408pblB2J0gxcoMxjrMOPT0IZUTTLGV5Tku57KKuF j7nPoT3eWP+QE184x4T8UaUM9CUkjUJv3azUQfgjuxBbl+gsQvG3PNoWYaqioBPz G5+BKr1b3O87uAyvmTr5SsPCuCtprmURBE1IOrfCKYJlkzqK1jiG7tuiZIf1F85b DwdoAssNa8Zpu0uv3qi1WfhJVl9qcEmG341rMGTw0BRi8z2Oqd/OuLqIXdst7WUM V4bv+HrTdK4m/6KkosKn2+d+qSodAJ27egn5JWKP5+75VQ2KZsDSS9TA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id jauLb-UtSBMg; Sun, 21 Oct 2012 21:59:58 +0100 (IST) Received: from [10.87.48.4] (unknown [86.44.64.186]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id B6528171478; Sun, 21 Oct 2012 21:59:52 +0100 (IST) Message-ID: <50846248.5090403@cs.tcd.ie> Date: Sun, 21 Oct 2012 21:59:52 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121017 Thunderbird/16.0.1 MIME-Version: 1.0 To: Thomas Fossati References: <5083DB5B.6010401@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-secure-cookie-session-protocol@tools.ietf.org, saag@ietf.org, Nevil Brownlee Subject: Re: [saag] Input for conflict review of draft-secure-cookie-session-protocol X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 21:00:05 -0000 Hi Thomas, On 10/21/2012 08:49 PM, Thomas Fossati wrote: > Hi Stephen, > > On Sun, Oct 21, 2012 at 12:24 PM, Stephen Farrell > wrote: >> What do folks (incl. authors) think of that? > > I think you've hit the point, and (as author) I share the proposed way-out. > I only have a bit of concern about sticking the name of a company in > the title, which seems quite an unusual practice... Actually, its relatively common for independent-stream RFCs that specify protocols to be called "'s protocol" S. > Would > "HTTP-friendly authentication tokens" be a less controversial > synthesis for what SCS actually is ? > From henry.story@bblfish.net Mon Oct 22 03:33:21 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D89E21F88FC for ; Mon, 22 Oct 2012 03:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmodJRgc4usc for ; Mon, 22 Oct 2012 03:33:20 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3B16B21F8798 for ; Mon, 22 Oct 2012 03:33:19 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so806353bkc.31 for ; Mon, 22 Oct 2012 03:33:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=jnsVPx4NCR1kU9y6fsg282xNrM4Ae3+QdeeXw4tmnAU=; b=VUlmaKu9nFZwJ4MDx72pjHUAq1TFlI9OCYoEAU6ZoXWWo9CGLuUGUK7gIgfbCz0tmm bxfNXUlU9bnFBIkuOrft/ZInVNkYSNIYUdJfOjiIipYVaMaUESLP9MubeFKsiyCUMdWZ gbEEv0EM3tOSYH7yyS69d5QFGJnX/EsiMHf066w/4/AkenFdNqN7Fxm5ixC4QRGem+Ju QO6jIBIKxJZzzG15etE7/PJndizWhXmIi79ibNOI/vb9F0ZMvZdCQS8t/YTTAlX2+3ZZ zoqchydrAb+9cozdYKs+m2GPawDLCPGoxboPWsIJXYsw/VBcDT4hQJshvvNobsBheUS0 dOxg== Received: by 10.204.146.10 with SMTP id f10mr2434855bkv.98.1350901999006; Mon, 22 Oct 2012 03:33:19 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-132-122.w86-198.abo.wanadoo.fr. [86.198.99.122]) by mx.google.com with ESMTPS id ia2sm3095496bkc.11.2012.10.22.03.33.08 (version=SSLv3 cipher=OTHER); Mon, 22 Oct 2012 03:33:09 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E42F4074-0A40-49D7-B029-5B8C9E3FEBC4"; protocol="application/pkcs7-signature"; micalg=sha1 From: Henry Story In-Reply-To: Date: Mon, 22 Oct 2012 12:33:06 +0200 Message-Id: <7F0FE9D3-995B-4B32-97CB-3B82F590FE92@bblfish.net> References: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <5083CCCF.2060407@webr3.org> <50842789.3080301@openlinksw.com> <50845268.4010509@webr3.org> <5084AC77.8030600@openlinksw.com> <50851512.9090803@webr3.org> To: Ben Laurie X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnAqQjyqk4nhyYqQ5qVCZkqsfl+86hId89xZ+RRa5mN6z3cs6Uf5SxiTbOoUix9VbTsR1q6 Cc: public-identity@w3.org, saag@ietf.org, public-webid@w3.org, "public-privacy@w3.org list" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 10:33:21 -0000 --Apple-Mail=_E42F4074-0A40-49D7-B029-5B8C9E3FEBC4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [cutting down on the mailing lists] On 22 Oct 2012, at 11:54, Ben Laurie wrote: > Where we came in was me pointing out that if you disconnect your > identities by using multiple WebIDs, then you have a UI problem, and > since then the aim seems to have been to persuade us that multiple > WebIDs are not needed. There is a happy medium on UI experience. For the UI experience there are two seperate issues, one of which I proposed a fix for and the other of which is a browser UI issue. A. Number of WebIDs ------------------- 1. WebID per web site: You don't want to have one WebID per site you go to, since the point=20 of WebID is to allow you to authenticate across sites using the same=20 ID ( in the case of TLS, a URL embedded in an X509 Certificate's SAN=20 field ). 2. One and only one WebID for the whole internet per person WebID does not force any such restrictions (neither would OpenId or BrowserId for that matter ).=20 3. As many WebID's for the whole web as the user feels worth investing = in The first sentence of the spec says so ( http://webid.info/spec/ ) [[ The WebID protocol enables secure, efficient and maximally user friendly = authentication on the Web. It enables people to authenticate onto any = site by simply clicking on one of the certificates proposed to them by = their browser. These certificates can be created by any Web Site for = their users in one click. The identifier, known as the WebID, is a URI = whose sense can be found in the associated Profile Page, a type of web = page that any Social Network user is familiar with. ]]=20 ( so we are looking for help improving the wording) Finally, (3) above does not mean that the user can only use WebID. He = can still use all the existing technologies for authenticating to web sites where he=20= wishes to have non cross-site linkable identities - e.g. cookies, with = username password for example if needed, ... UI Experience ------------- There are two elements to the UI experience 1. Certificate selection If the server requesting the certificate from the user makes a = CertificateRequest by leaving the certificate_authorities field blank ( or null, not sure = what the correct wording is ) as explained by the spec currently = http://www.w3.org/2005/Incubator/webid/spec/#requesting-the-client-certifi= cate then users with multiple certificates - some of which may not be WebID = enabled - then those users will be presented with a selection box containing = certificates that are not in fact ones the server will accept - leading to confusion = and a=20 bad UI. I just proposed on the WebID mailing list that WebID certificate = chains be signed (at some point) by CN=3DWebID,O=3D=E2=88=85 to solve this = issue. http://lists.w3.org/Archives/Public/public-webid/2012Oct/0188.html 2. Transparency of Identity It is not clear currently when you go to a web site if you are = authenticated or not, or with what identities you are. Even Google Chromes' Profile feature = does not do so. This is something I really hope they will fix by inspiring themselves = from Aza Raskin's work=20 http://www.azarask.in/blog/post/identity-in-the-browser-firefox/ I hope this helps, Henry Social Web Architect http://bblfish.net/ --Apple-Mail=_E42F4074-0A40-49D7-B029-5B8C9E3FEBC4 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPDTCCByMw ggYLoAMCAQICAwTQYzANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEyMDgyOTAxNDU1NloXDTEzMDgzMDA5MjM0MFowZTEZMBcGA1UEDRMQazQ2eDlvOXJDRE5m VzMwYzEgMB4GA1UEAwwXaGVucnkuc3RvcnlAYmJsZmlzaC5uZXQxJjAkBgkqhkiG9w0BCQEWF2hl bnJ5LnN0b3J5QGJibGZpc2gubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArHXp EmiifOSpudkJn1vAnFdZsuaLuYYLbdWL47o1rKD/kg8/RJUmTIM2ara4e/MOxR16mu2fyAca3H1U oIXNNXDbYQDu2PkfLoNSM5JGAoYbfB0nXBK//ZecidVMZ8eExd02/vFzo5vj9kQNaAPSYirid5xe 1cV9Y1RFjlEozuYAUhU8zi3taf22JM45ii2YrCEgVjDdez8yio0QoJeKEEL3JhL4tqpkbfIOHmdi HYx00S6YcCogDfxXc3zOJ3jcIj/F61eXG1qWX/lq9RAyoBjYHLWE2iHQPwdzum03ubcvOTlohqOR +/cVzvx10l6bJ46KitfbydXMh8HoY7QcmwIDAQABo4IDsjCCA64wCQYDVR0TBAIwADALBgNVHQ8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQRbT9qwRblII9x nAN2FlEMUD1LQzAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAiBgNVHREEGzAZgRdo ZW5yeS5zdG9yeUBiYmxmaXNoLm5ldDCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIw ggH/MC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsG AQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEF BQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9u IHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZv ciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5 IG9ibGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBTZWUg c2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5 LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3Js MIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20v c3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29t L2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALj/A19bRLmI7sMf0lVRrdN23NuRC7/UFSLZ DfcxrR1wOtQgAbrFlFLY+Otn6UWYIiWQpv2v5Ploqw9rMam5W8seC3TUt83StohXCmZ0EDmK87If B6kpd7FwJ0RFGCxn22hPU2kuhp2mbjJzCTrd3jWsXw63MXDUzHuucWGX2mY1Ji+zRECh568N7iWA 5jn9kWT+h7o7ywKbHc4qAnksghLYAnTfoCx1IPkT4/8A5hf38imhf9NcNGibrvt/e49sacf6GjRH Ot/lOCrEX2fh2YvTB5sdEKM5tjKCKNpFSqnRCKhsWZ9N9ZP7mRZfCOBjAMsm3CW2ygwlWXc54lgf p1UwggfiMIIFyqADAgECAgENMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQy MTAxNTRaFw0xMjEwMjIyMTAxNTRaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP 6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu 2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyU GHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmt xWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMB AAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUU3Ltkpzg2ssB XHx+ljVO8tS4UYIwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0 YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHmCAQEwCQYDVR0SBAIwADA9BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYB BQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMw JxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmls aXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29t IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRD FkFTdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENl cnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAqprh4FuMzh0b/B3GLDAgoLeTJv3xArbNESi/ Kf/HMM//gf8FzwUUNOCglH6dfYuLQQ/dTtOyMb4JoiL3T7xiVKEAOmQ+t+b/xLOMa0m18zoRqW4k 6Glyoyvc7LMrdpgYk/lEh5nq8tPd9BoNmwiiheXphIVH/QelTgUkNzTC7IVpmYVsKuNOnxE1jJFZ NNfqZZK/5Oto7C6PfOut11KmBQSLZarAz0b/mjghdBsYfHuhdO8vrOvD0g5g7dA4pkOAU2Ed4pSC owBSItyD/5aFwZ75ji6Yq7GCG3BpiyAP9st8h+inc0L+7kmrAMJaLMAmu6GZs5Xgsbzn0wUJvbD9 h5jnnMM9UaZDcxl2uLB04quGUWM6NiKGabbxQc680PYbeQrQu+e6J4uqNAxzoa5RxkBA5a/3qlbg F9uJBekCqJswx5vQ9khJrs8UTMaIFzbEC5VGQziQH3/6KJ4DUP85OJEnCx/quShWA6w318LDnba3 M6a5V+KoNLhsVi/TSxf90UbBqwdRR/cOwuGkNJh16NvvhIqO26osMg64CbZsDVrEDr7uSMV40ieB JTo49Iyt77ECOhz/pyhowa2EUP6aKav+L/wXzAPB3LNqzujGR0K1pbyFWKvyYmdungJtySWUMw+R 5DqpA2bFIOE56pfWPLHZxOL+8+r79PLFX+y2V6ExggNvMIIDawIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRp ZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1l ZGlhdGUgQ2xpZW50IENBAgME0GMwCQYFKw4DAhoFAKCCAa8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMDIyMTAzMzA2WjAjBgkqhkiG9w0BCQQxFgQUcLo1l3go 5p7pH/07RRqAJG2sy50wgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgME0GMwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0ECAwTQYzANBgkqhkiG9w0BAQEFAASCAQB1o+/KVDwuywHVMa9oc1VjOoVO+qsND2g36L8s VooIpOzeQ8rgiRjntxPxTQOhhhiiUkMZQDPq/I9VA7E8BKGrBog4hLuJgirL3r2flKONS6UQv/1g JgSG1tVJZcXGvcAsgFE9OXRf90qjLXgbDaYcmB0jz804tJ2UDc7FKfHqgZzZy74bySP5PkOez+Wm oxhZD7luMm1NPuC+U5lOGzwtb29aMLbTpfE6R1JoUrXzxqnmeERsYKdlPr62Q6ndLvRjkZ+wdfIo 2HNMcxtp8S00wFrbzZ2Heb1vlUoAs1RBfMayROrG/qnxLVheaBs2chPlqu4rWxw9CNrCjXzs9XSV AAAAAAAA --Apple-Mail=_E42F4074-0A40-49D7-B029-5B8C9E3FEBC4-- From henry.story@bblfish.net Mon Oct 22 07:04:29 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E3B21F869C for ; Mon, 22 Oct 2012 07:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.316 X-Spam-Level: X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[AWL=-1.208, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, J_CHICKENPOX_43=0.6, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p76JRqyy9V21 for ; Mon, 22 Oct 2012 07:04:28 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id C32DD21F84F3 for ; Mon, 22 Oct 2012 07:04:23 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so923126bkc.31 for ; Mon, 22 Oct 2012 07:04:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:x-mailer:x-gm-message-state; bh=XprvKztg3gWYvhJBiITQPVnKYbM8l4c+zgKFUw8qkEk=; b=a4Z7IqGttvLoznGB/clw0+FmGRFGZYX0cKq5Rn4ly69UjhTs/jzngipYwC11wrD85s B1EbXydhz/yOj/Iq0Ewfnu/KYu5gnmoH2jeoi7NHH+iJHUHBm+3nMggouGTfXGVfZgC+ rFwhsFmDf9vpNKfL98tGxVzanpqOhmsWDzfoNO9zsHtZxFp2uGGV+wHm+s4RTQxf4loN EhwAFE0Zlo8DiGWZ2wiNZGcyR8p0QwDEQrZAUvZj7dR+BRO8vj5vdEhD2AAkuQLZz0GV 3qConD4cy4K1JDiVPyxEmiS33SgJ9aYgpLtEijFdzQIz1NFXUjfTCLmGnHslW4yls24K E8Dg== Received: by 10.204.149.135 with SMTP id t7mr2637306bkv.103.1350914662268; Mon, 22 Oct 2012 07:04:22 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-132-122.w86-198.abo.wanadoo.fr. [86.198.99.122]) by mx.google.com with ESMTPS id v14sm3728400bkv.10.2012.10.22.07.04.19 (version=SSLv3 cipher=OTHER); Mon, 22 Oct 2012 07:04:20 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_64FCB0C6-821C-408F-B865-0CC321B98461"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Henry Story In-Reply-To: <50853CD8.8020005@w3.org> Date: Mon, 22 Oct 2012 16:04:17 +0200 Message-Id: <5FB468E4-BDD3-4635-ACD0-A23540C08751@bblfish.net> References: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <5083CCCF.2060407@webr3.org> <50842789.3080301@openlinksw.com> <50845268.4010509@webr3.org> <5084AC77.8030600@openlinksw.com> <50851512.9090803@webr3.org> <50852726.9030102@openlinksw.com> <5085360E.3080008@openlinksw.com> <50853CD8.8020005@w3.org> X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkaUH3xnLbX7uqTrn9boEe2dcBXTlVJvI2FRLn0F9jkL0/oYKPlvitlfWSDPP/W9vHpgb2A Cc: public-identity@w3.org, saag@ietf.org, public-webid@w3.org, "public-privacy@w3.org list" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 14:04:29 -0000 --Apple-Mail=_64FCB0C6-821C-408F-B865-0CC321B98461 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 22 Oct 2012, at 14:32, Harry Halpin wrote: > On 10/22/2012 02:03 PM, Kingsley Idehen wrote: >> On 10/22/12 7:26 AM, Ben Laurie wrote: >>> On 22 October 2012 11:59, Kingsley Idehen = wrote: >>>> On 10/22/12 5:54 AM, Ben Laurie wrote: >>>>> Where we came in was me pointing out that if you disconnect your >>>>> identities by using multiple WebIDs, then you have a UI problem, = and >>>>> since then the aim seems to have been to persuade us that multiple >>>>> WebIDs are not needed. >>>> Multiple WebIDs (or any other cryptographically verifiable = identifier) are a >>>> must. >>>>=20 >>>> The issue of UI is inherently subjective. It can't be used to = objectively >>>> validate or invalidate Web-scale verifiable identifier systems such = as >>>> WebID or any other mechanism aimed at achieving the same goals. >>> Ultimately what matters is: do users use it correctly? This can be = tested :-) >>>=20 >>> Note that it is necessary to test the cases where the website is = evil, >>> too - something that's often conveniently missed out of user = testing. >>> For example, its pretty obvious that OpenID fails horribly in this >>> case, so it tends not to get tested. >>=20 >> Okay. >>>=20 >>>> Anyway, Henry, I, and a few others from the WebID IG (hopefully) = are going >>>> to knock up some demonstrations to show how this perceived UI/UX >>>> inconvenience can be addressed. >>> Cool. >>=20 >> Okay, ball is in our court to now present a few implementations that = address the UI/UX concerns. >>=20 >> Quite relieved to have finally reached this point :-) >=20 > No, its not a UI/UX concern, although the UI experience of both = identity on the Web and with WebID in particular is quite terrible, I = agree. It completely depends on the browsers:=20 http://www.w3.org/wiki/Foaf%2Bssl/Clients/CertSelection If you are on Linux just file a bug request to your browser if you are = unhappy, or even better hack up a good UI. It's easy: just make it = simpler. >=20 > My earlier concern was an information flow concern that causes the = issue with linkability, which WebID shares to a large extent with other = server-side information-flow. Including BrowserId. Which has 2 tokens that can be used to identify the = user across sites: - an e-mail address ( useful for spamming ) - a public key, which can be used to authenticate across sites > As stated earlier, as long as you trust the browser, BrowserID does = ameliorate this. No it does not improve linkability at all. Certainly not if you think = the site you are authenticating to is the one you should be worried = about, because just using a public key by itself is enough for Linkability in the strict (paranoid) sense. That = is if you=20 consider the site you are logging into to as the attacker, then by = giving two sites a public key where you have proven you control the private key is enough = for them to know that the same agent visited both sites. That is because the cert:key relation = is inverse functional. So in simple logical terms if you go to site1.org and identify with a = public key pk, and they create a local identifier for you , and = then you go site s2.net and identify with the same public key pk and = they give you an identifier =20 (these need not be public) and then they exchange their information, = then each of the sites would have the following relations ( written in = http://www.w3.org/TR/Turtle ) @prefix cert: cert:key pk . cert:key pk . because cert:key is defined as an InverseFunctionalProperty=20 ( as you can see by going http://www.w3.org/ns/auth/cert#key ) Then it follows from simple owl reasoning that =3D=3D . One cannot get much simpler logical reasoning that this, Harry. > There is also this rather odd conflation of "linkability" of URIs with = hypertext and URI-enabled Semantic Web data" and linkability as a = privacy concern. I am not conflating these. My point from the beginning is that Linkability is both a good thing and = a bad thing.=20 As a defender of BrowserId you cannot consistently attack WebID for = linkability concerns and find BrowserId not to have that same problem. = So I hate to reveal this truth to you: but we have to fight this battle = together. And the battle is simple: the linkability issue is only an issue if you = think the site you are authenticating to is the enemy. If you believe that you are in = relation with a site that is under a legal and moral duty to be respectful of the communication = you are having with it, then you will find that the linkability of information with that site = and across sites is exactly what you want in order to reduce privacy = issues that arise out of centralised systems. >=20 > I do think many people agree stronger cryptographic credentials for = authentication are a good thing, and BrowserID is based on this and = OpenID Connect has (albeit not often used) options in this space. I = would again, please suggest that the WebID community take on board = comments in a polite manner and not cc mailing lists. All my communications have been polite, and I don't know why you select = out the WebID community. As for taking on board comments, why, just the previous e-mail you = responded to was a demonstration that we are: CN=3DWebID,O=3D=E2=88=85 >>=20 >>=20 >>=20 >=20 Social Web Architect http://bblfish.net/ --Apple-Mail=_64FCB0C6-821C-408F-B865-0CC321B98461 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPDTCCByMw ggYLoAMCAQICAwTQYzANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEyMDgyOTAxNDU1NloXDTEzMDgzMDA5MjM0MFowZTEZMBcGA1UEDRMQazQ2eDlvOXJDRE5m VzMwYzEgMB4GA1UEAwwXaGVucnkuc3RvcnlAYmJsZmlzaC5uZXQxJjAkBgkqhkiG9w0BCQEWF2hl bnJ5LnN0b3J5QGJibGZpc2gubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArHXp EmiifOSpudkJn1vAnFdZsuaLuYYLbdWL47o1rKD/kg8/RJUmTIM2ara4e/MOxR16mu2fyAca3H1U oIXNNXDbYQDu2PkfLoNSM5JGAoYbfB0nXBK//ZecidVMZ8eExd02/vFzo5vj9kQNaAPSYirid5xe 1cV9Y1RFjlEozuYAUhU8zi3taf22JM45ii2YrCEgVjDdez8yio0QoJeKEEL3JhL4tqpkbfIOHmdi HYx00S6YcCogDfxXc3zOJ3jcIj/F61eXG1qWX/lq9RAyoBjYHLWE2iHQPwdzum03ubcvOTlohqOR +/cVzvx10l6bJ46KitfbydXMh8HoY7QcmwIDAQABo4IDsjCCA64wCQYDVR0TBAIwADALBgNVHQ8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQRbT9qwRblII9x nAN2FlEMUD1LQzAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAiBgNVHREEGzAZgRdo ZW5yeS5zdG9yeUBiYmxmaXNoLm5ldDCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIw ggH/MC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsG AQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEF BQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9u IHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZv ciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5 IG9ibGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBTZWUg c2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5 LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3Js MIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20v c3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29t L2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALj/A19bRLmI7sMf0lVRrdN23NuRC7/UFSLZ DfcxrR1wOtQgAbrFlFLY+Otn6UWYIiWQpv2v5Ploqw9rMam5W8seC3TUt83StohXCmZ0EDmK87If B6kpd7FwJ0RFGCxn22hPU2kuhp2mbjJzCTrd3jWsXw63MXDUzHuucWGX2mY1Ji+zRECh568N7iWA 5jn9kWT+h7o7ywKbHc4qAnksghLYAnTfoCx1IPkT4/8A5hf38imhf9NcNGibrvt/e49sacf6GjRH Ot/lOCrEX2fh2YvTB5sdEKM5tjKCKNpFSqnRCKhsWZ9N9ZP7mRZfCOBjAMsm3CW2ygwlWXc54lgf p1UwggfiMIIFyqADAgECAgENMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQy MTAxNTRaFw0xMjEwMjIyMTAxNTRaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP 6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu 2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyU GHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmt xWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMB AAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUU3Ltkpzg2ssB XHx+ljVO8tS4UYIwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0 YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHmCAQEwCQYDVR0SBAIwADA9BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYB BQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMw JxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmls aXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29t IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRD FkFTdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENl cnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAqprh4FuMzh0b/B3GLDAgoLeTJv3xArbNESi/ Kf/HMM//gf8FzwUUNOCglH6dfYuLQQ/dTtOyMb4JoiL3T7xiVKEAOmQ+t+b/xLOMa0m18zoRqW4k 6Glyoyvc7LMrdpgYk/lEh5nq8tPd9BoNmwiiheXphIVH/QelTgUkNzTC7IVpmYVsKuNOnxE1jJFZ NNfqZZK/5Oto7C6PfOut11KmBQSLZarAz0b/mjghdBsYfHuhdO8vrOvD0g5g7dA4pkOAU2Ed4pSC owBSItyD/5aFwZ75ji6Yq7GCG3BpiyAP9st8h+inc0L+7kmrAMJaLMAmu6GZs5Xgsbzn0wUJvbD9 h5jnnMM9UaZDcxl2uLB04quGUWM6NiKGabbxQc680PYbeQrQu+e6J4uqNAxzoa5RxkBA5a/3qlbg F9uJBekCqJswx5vQ9khJrs8UTMaIFzbEC5VGQziQH3/6KJ4DUP85OJEnCx/quShWA6w318LDnba3 M6a5V+KoNLhsVi/TSxf90UbBqwdRR/cOwuGkNJh16NvvhIqO26osMg64CbZsDVrEDr7uSMV40ieB JTo49Iyt77ECOhz/pyhowa2EUP6aKav+L/wXzAPB3LNqzujGR0K1pbyFWKvyYmdungJtySWUMw+R 5DqpA2bFIOE56pfWPLHZxOL+8+r79PLFX+y2V6ExggNvMIIDawIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRp ZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1l ZGlhdGUgQ2xpZW50IENBAgME0GMwCQYFKw4DAhoFAKCCAa8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMDIyMTQwNDE4WjAjBgkqhkiG9w0BCQQxFgQU4gahKeOo dr5YnIPUDPFrVUpMo4AwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgME0GMwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0ECAwTQYzANBgkqhkiG9w0BAQEFAASCAQAw7tzAOWv+WqjQufDItjaEGO/zvu2NWu9fRiT0 nTsdhmbQJD6jkrUVwbW8JEFFXSzGYoQNThJNN3vr0d6z0icDHIatMyvK891C92fgW2rd4YAewTL8 zC+k7gYP8wav/U64s5ZrFcY2udP/eSYqjjVTBJbLJ9+KUtQfxddT8Em8NQuPsIBEjeVe5jHCdO24 4BzFblK4IAtu2ndkNJkGuiHLCdlbiZpMsYDbwYilJFphzuvlMyqffu/Ntl9vdO1DQGuN8MszKLcl VmA5SDPg6TEHcwXqoDR6pipyXf8fK7yhnK2VJH99u6JkC8bA5oDzo7JDDX6suyyYl3eGBHVdbgst AAAAAAAA --Apple-Mail=_64FCB0C6-821C-408F-B865-0CC321B98461-- From hhalpin@w3.org Mon Oct 22 08:14:20 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D0E21F8B92 for ; Mon, 22 Oct 2012 08:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_25=0.6, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yayne+N8YSLL for ; Mon, 22 Oct 2012 08:14:19 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 45B8921F87DF for ; Mon, 22 Oct 2012 08:14:19 -0700 (PDT) Received: from net-rtvisitors.oecd.org ([78.41.129.5] helo=[10.116.114.121]) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1TQJho-0005DX-3z; Mon, 22 Oct 2012 11:14:16 -0400 Message-ID: <508562C2.1060905@w3.org> Date: Mon, 22 Oct 2012 17:14:10 +0200 From: Harry Halpin User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Henry Story References: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <5083CCCF.2060407@webr3.org> <50842789.3080301@openlinksw.com> <50845268.4010509@webr3.org> <5084AC77.8030600@openlinksw.com> <50851512.9090803@webr3.org> <50852726.9030102@openlinksw.com> <5085360E.3080008@openlinksw.com> <50853CD8.8020005@w3.org> <5FB468E4-BDD3-4635-ACD0-A23540C08751@bblfish.net> In-Reply-To: <5FB468E4-BDD3-4635-ACD0-A23540C08751@bblfish.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: public-identity@w3.org, saag@ietf.org, public-webid@w3.org, "public-privacy@w3.org list" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 15:14:20 -0000 On 10/22/2012 04:04 PM, Henry Story wrote: > On 22 Oct 2012, at 14:32, Harry Halpin wrote: > >> On 10/22/2012 02:03 PM, Kingsley Idehen wrote: >>> On 10/22/12 7:26 AM, Ben Laurie wrote: >>>> On 22 October 2012 11:59, Kingsley Idehen wrote: >>>>> On 10/22/12 5:54 AM, Ben Laurie wrote: >>>>>> Where we came in was me pointing out that if you disconnect your >>>>>> identities by using multiple WebIDs, then you have a UI problem, and >>>>>> since then the aim seems to have been to persuade us that multiple >>>>>> WebIDs are not needed. >>>>> Multiple WebIDs (or any other cryptographically verifiable identifier) are a >>>>> must. >>>>> >>>>> The issue of UI is inherently subjective. It can't be used to objectively >>>>> validate or invalidate Web-scale verifiable identifier systems such as >>>>> WebID or any other mechanism aimed at achieving the same goals. >>>> Ultimately what matters is: do users use it correctly? This can be tested :-) >>>> >>>> Note that it is necessary to test the cases where the website is evil, >>>> too - something that's often conveniently missed out of user testing. >>>> For example, its pretty obvious that OpenID fails horribly in this >>>> case, so it tends not to get tested. >>> Okay. >>>>> Anyway, Henry, I, and a few others from the WebID IG (hopefully) are going >>>>> to knock up some demonstrations to show how this perceived UI/UX >>>>> inconvenience can be addressed. >>>> Cool. >>> Okay, ball is in our court to now present a few implementations that address the UI/UX concerns. >>> >>> Quite relieved to have finally reached this point :-) >> No, its not a UI/UX concern, although the UI experience of both identity on the Web and with WebID in particular is quite terrible, I agree. > It completely depends on the browsers: > http://www.w3.org/wiki/Foaf%2Bssl/Clients/CertSelection > If you are on Linux just file a bug request to your browser if you are unhappy, or even better hack up a good UI. It's easy: just make it simpler. > >> My earlier concern was an information flow concern that causes the issue with linkability, which WebID shares to a large extent with other server-side information-flow. > Including BrowserId. Which has 2 tokens that can be used to identify the user across sites: > > - an e-mail address ( useful for spamming ) > - a public key, which can be used to authenticate across sites > > >> As stated earlier, as long as you trust the browser, BrowserID does ameliorate this. > No it does not improve linkability at all. Certainly not if you think the site you are authenticating to is the one you should be worried about, because just using a public key > by itself is enough for Linkability in the strict (paranoid) sense. That is if you > consider the site you are logging into to as the attacker, then by giving two sites > a public key where you have proven you control the private key is enough for them to know that > the same agent visited both sites. That is because the cert:key relation is inverse functional. > > So in simple logical terms if you go to site1.org and identify with a public key pk, > and they create a local identifier for you , and then you go site s2.net and identify with the same public key pk and they give you an identifier > (these need not be public) and then they exchange their information, then each of the sites would have the following relations ( written in http://www.w3.org/TR/Turtle ) > > @prefix cert: > > cert:key pk . > cert:key pk . > > because cert:key is defined as an InverseFunctionalProperty > ( as you can see by going http://www.w3.org/ns/auth/cert#key ) > > Then it follows from simple owl reasoning that > > == . > > One cannot get much simpler logical reasoning that this, Harry. > > >> There is also this rather odd conflation of "linkability" of URIs with hypertext and URI-enabled Semantic Web data" and linkability as a privacy concern. > I am not conflating these. To quote the IETF document I seem to have unsuccessfully suggested you read a while back, the linkability of two or more Items Of Interest (e.g., subjects, messages, actions, ...) from an attacker's perspective means that within a particular set of information, the attacker can distinguish whether these IOIs are related or not (with a high enough degree of probability to be useful) [1]. If you "like linkability", that's great, but probably many use-cases aren't built around liking linkability. This has very little with hypertext linking of web-pages via URIs. I think you want to use the term "trust across different sites" rather than linkability, although I see how WebID wants to conflate that with trust, which no other identity solution does. A link does not necessarily mean trust, especially if links aren't bi-directional. As explained earlier, Mozilla Personae/BrowserID uses digital signatures where an IDP signs claims but transfers that claim to the RP via the browser (thus the notion of "different information flow") and thus the RP and IDP do not directly communicate, reducing the linkability of the data easily gathered by the IDP (not the RP). I know WebID folks believe IDP = my homepage, but for most people IDP would likely not be a homepage, but a major identity provider for which data minimization principles should apply, including ownership of the social network data of an individual and a history of their interactions with every RP. I am not defending BrowerID per se: Personae assumes you trust the browser, which some people don't. Also, email verification, while common, is not great from a security perspective, i.e. STARTLS not giving error messages when it degrades. Perhaps a more productive question would be why would someone use WebID rather than OpenID Connect with digital signatures? Although, I have ran out of time for this for the time being. > > My point from the beginning is that Linkability is both a good thing and a bad thing. > > As a defender of BrowserId you cannot consistently attack WebID for linkability concerns and find BrowserId not to have that same problem. So I hate to reveal this truth to you: but we have to fight this battle together. > > And the battle is simple: the linkability issue is only an issue if you think the site you > are authenticating to is the enemy. If you believe that you are in relation with a site that > is under a legal and moral duty to be respectful of the communication you are having with it, > then you will find that the linkability of information with that site and across sites is exactly what you want in order to reduce privacy issues that arise out of centralised systems. > >> I do think many people agree stronger cryptographic credentials for authentication are a good thing, and BrowserID is based on this and OpenID Connect has (albeit not often used) options in this space. I would again, please suggest that the WebID community take on board comments in a polite manner and not cc mailing lists. > All my communications have been polite, and I don't know why you select out the WebID community. > As for taking on board comments, why, just the previous e-mail you responded to was a demonstration that we are: CN=WebID,O=∅ > > > >>> >>> > Social Web Architect > http://bblfish.net/ > From melvincarvalho@gmail.com Thu Oct 18 09:23:43 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F2021F8449 for ; Thu, 18 Oct 2012 09:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlfagpaOCAjv for ; Thu, 18 Oct 2012 09:23:42 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6531321F8448 for ; Thu, 18 Oct 2012 09:23:42 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so16104594iec.31 for ; Thu, 18 Oct 2012 09:23:42 -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=ZQYWe40QSFsIqszKGpI//se5OBmDpLaquBTiFJozwm0=; b=Nfj5S0LezfCF6xDJ/68Pr8E37sT/yxr8xYmQUthG7NiGH+xqk8KouY6ECyYjoKIWmP fxQWa0EIxY9OX7bq3KQ/IVi6+K+XJ1qmpcTz3+9ZwzcCu3e06okn7hmpUtD0bTlKSDUa WYm07EzW8t7jNwMR9QV/fTwkfCA4vOWNIXcaQLi7p7bIm241vhGCeOeBWab2xFIqG31a /eJuR8ei7gTy/i5gjIxoePpTYCcy/9RL9lHubRVcFCsu631I39M6I22AZrNsepAKq3qu P98ssZtak2/HIwv93AsAGquQiTv6qW+AXKAdVxrWKg//F9c/LAK8vdaBH7cVCAYgPs71 h13A== MIME-Version: 1.0 Received: by 10.50.5.239 with SMTP id v15mr5523781igv.41.1350577421916; Thu, 18 Oct 2012 09:23:41 -0700 (PDT) Received: by 10.42.247.129 with HTTP; Thu, 18 Oct 2012 09:23:41 -0700 (PDT) In-Reply-To: References: <88F98DFD-EF7D-4444-A9C2-FB8E15F5DA89@bblfish.net> <3757D928-C3AE-4630-98E7-E30B5CC604B0@cisco.com> <7E1636E02F313F4BA69A428B314B77C708217189@xmb-aln-x12.cisco.com> <7ABCD095-4B09-40DD-A084-1BBE761CA72F@bblfish.net> Date: Thu, 18 Oct 2012 18:23:41 +0200 Message-ID: From: Melvin Carvalho To: Ben Laurie Content-Type: multipart/alternative; boundary=e89a8f502cd6799b9f04cc57cfd9 X-Mailman-Approved-At: Mon, 22 Oct 2012 08:25:26 -0700 Cc: "public-philoweb@w3.org" , "public-identity@w3.org" , "saag@ietf.org" , "public-privacy@w3.org" , "Klaas Wierenga \(kwiereng\)" , "public-webid@w3.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 16:23:43 -0000 --e89a8f502cd6799b9f04cc57cfd9 Content-Type: text/plain; charset=ISO-8859-1 On 18 October 2012 17:34, Ben Laurie wrote: > On 9 October 2012 14:19, Henry Story wrote: > > Still in my conversations I have found that many people in security > spaces > > just don't seem to be able to put the issues in context, and can get > sidetracked > > into not wanting any linkability at all. Not sure how to fix that. > > You persist in missing the point, which is why you can't fix it. The > point is that we want unlinkability to be possible. Protocols that do > not permit it or make it difficult are problematic. I have certainly > never said that you should always be unlinked, that would be stupid > (in fact, I once wrote a paper about how unpleasant it would be). > > As I once wrote, anonymity should be the substrate. Once you have > that, you can the build on it to be linked when you choose to be, and > not linked when you choose not to be. If it is not the substrate, then > you do not have this choice. > > What are the criteria for anonymity to be considered an acceptable substrate? 1. For example if I dont send my certificate, no one can ever link me. Is that good enough? 2. I suggested a shared anonymous identity (either an individual or group) eg at http://webid.info/#anon . What that solve the problem. 3. Are we looking for more crypto style proofs, such as chaumian blinding, anonymous veto, OpenPGP style subkeys or one time shared secrets? I understand what you are suggesting, but on what criteria would a suggested solution be measured? --e89a8f502cd6799b9f04cc57cfd9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 18 October 2012 17:34, Ben Laurie <ben= l@google.com> wrote:
On 9 October 2012 14:19, Henry Story <henry.story@bblfish.net> wrote:
> Still in my conversations I have found that many people in security sp= aces
> just don't seem to be =A0able to put the issues in context, and ca= n get sidetracked
> into not wanting any linkability at all. Not sure how to fix that.

You persist in missing the point, which is why you can't fix it. = The
point is that we want unlinkability to be possible. Protocols that do
not permit it or make it difficult are problematic. I have certainly
never said that you should always be unlinked, that would be stupid
(in fact, I once wrote a paper about how unpleasant it would be).

As I once wrote, anonymity should be the substrate. Once you have
that, you can the build on it to be linked when you choose to be, and
not linked when you choose not to be. If it is not the substrate, then
you do not have this choice.


What are the criteria for anonymity to be considered= an acceptable substrate?

1. For example if I dont send my certifica= te, no one can ever link me.=A0 Is that good enough?

2. I suggested = a shared anonymous identity (either an individual or group) eg at http://webid.info/#anon .=A0 What that sol= ve the problem.

3. Are we looking for more crypto style proofs, such as chaumian blindi= ng, anonymous veto, OpenPGP style subkeys or one time shared secrets?
I understand what you are suggesting, but on what criteria would a sugges= ted solution be measured?
--e89a8f502cd6799b9f04cc57cfd9-- From d.w.chadwick@kent.ac.uk Thu Oct 18 09:56:41 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E3221F8778 for ; Thu, 18 Oct 2012 09:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nwC73Lw2d0n for ; Thu, 18 Oct 2012 09:56:40 -0700 (PDT) Received: from mx1.kent.ac.uk (mx1.kent.ac.uk [129.12.21.39]) by ietfa.amsl.com (Postfix) with ESMTP id 350A721F86B8 for ; Thu, 18 Oct 2012 09:56:40 -0700 (PDT) Received: from mx4.kent.ac.uk ([129.12.21.35]) by mx1.kent.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1TOtOa-00017o-8R; Thu, 18 Oct 2012 17:56:32 +0100 Received: from [63.133.198.91] (helo=[172.16.13.114]) by mx4.kent.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1TOtOZ-000635-Gl; Thu, 18 Oct 2012 17:56:32 +0100 Message-ID: <508034BB.7040102@kent.ac.uk> Date: Thu, 18 Oct 2012 17:56:27 +0100 From: David Chadwick User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Kingsley Idehen References: <88F98DFD-EF7D-4444-A9C2-FB8E15F5DA89@bblfish.net> <3757D928-C3AE-4630-98E7-E30B5CC604B0@cisco.com> <7E1636E02F313F4BA69A428B314B77C708217189@xmb-aln-x12.cisco.com> <7ABCD095-4B09-40DD-A084-1BBE761CA72F@bblfish.net> <50802328.70205@openlinksw.com> <508033C3.1010205@openlinksw.com> In-Reply-To: <508033C3.1010205@openlinksw.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 22 Oct 2012 08:25:26 -0700 Cc: "Klaas Wierenga \(kwiereng\)" , "public-identity@w3.org" , "saag@ietf.org" , "public-privacy@w3.org" , "public-philoweb@w3.org" , "public-webid@w3.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 16:56:41 -0000 and if the user puts his/her email address attribute in the U-Prove token??? David On 18/10/2012 17:52, Kingsley Idehen wrote: > On 10/18/12 12:06 PM, Ben Laurie wrote: >> On 18 October 2012 16:41, Kingsley Idehen wrote: >>> On 10/18/12 11:34 AM, Ben Laurie wrote: >>>> On 9 October 2012 14:19, Henry Story wrote: >>>>> Still in my conversations I have found that many people in security >>>>> spaces >>>>> just don't seem to be able to put the issues in context, and can get >>>>> sidetracked >>>>> into not wanting any linkability at all. Not sure how to fix that. >>>> You persist in missing the point, which is why you can't fix it. The >>>> point is that we want unlinkability to be possible. Protocols that do >>>> not permit it or make it difficult are problematic. I have certainly >>>> never said that you should always be unlinked, that would be stupid >>>> (in fact, I once wrote a paper about how unpleasant it would be). >>>> >>>> As I once wrote, anonymity should be the substrate. Once you have >>>> that, you can the build on it to be linked when you choose to be, and >>>> not linked when you choose not to be. If it is not the substrate, then >>>> you do not have this choice. >>>> >>>> >>>> >>>> >>> Do you have example of what you describe? By that question I mean: >>> implicit >>> anonymity as a functional substrate of some realm that we experience >>> today? >> That's what selective disclosure systems like U-Prove and the PRIME >> project are all about. >> >> >> > Ben, > > How is the following incongruent with the fundamental points we've been > trying to make about the combined effects of URIs, Linked Data, and > Logic en route to controlling privacy at Web-scale? > > Excerpt from Microsoft page [1]: > > A U-Prove token is a new type of credential similar to a PKI certificate > that can encode attributes of any type, but with two important differences: > > 1) The issuance and presentation of a token is unlinkable due to the > special type of public key and signature encoded in the token; the > cryptographic “wrapping” of the attributes contain no correlation > handles. This prevents unwanted tracking of users when they use their > U-Prove tokens, even by colluding insiders. > > 2) Users can minimally disclose information about what attributes are > encoded in a token in response to dynamic verifier policies. As an > example, a user may choose to only disclose a subset of the encoded > attributes, prove that her undisclosed name does not appear on a > blacklist, or prove that she is of age without disclosing her actual > birthdate. > > > Why are you assuming that a hyperlink based pointer (de-referencable > URI) placed in the SAN of minimalist X.509 certificate (i.e., one that > has now personally identifiable information) can't deliver the above and > more? > > Please note, WebID is a piece of the picture. Linked Data, Entity > Relationship Semantics and Logic are other critical parts. That's why > there isn't a golden ontology for resource access policies, the resource > publisher can construct a plethora of resource access policies en route > to leveraging the power of machine discernible entity relationship > semantics and first-order logic. > > In a most basic super paranoid scenario, if I want to constrain access > to a resource to nebulous entity "You" I would share a PKCS#12 document > with that entity. I would also have an access policy in place based on > the data in said document. I would also call "You" by phone to give you > the password of that PKCS#12 document. Once that's all sorted, you can > open the document, get your crytpo data installed in your local keystore > and then visit the resource I've published :-) > > Links: > > 1. http://research.microsoft.com/en-us/projects/u-prove/ > 2. http://en.wikipedia.org/wiki/Zero-knowledge_proof -- I don't see > anything about that being incompatible with what the combined use of > de-referencable URIs based names, Linked Data, Entity Relationship > Semantics, Reasoning, and existing PKI deliver. > From w@1wt.eu Thu Oct 18 10:11:42 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E18E21F86AB for ; Thu, 18 Oct 2012 10:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.898 X-Spam-Level: X-Spam-Status: No, score=-4.898 tagged_above=-999 required=5 tests=[AWL=-2.855, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S93HazXjvHjD for ; Thu, 18 Oct 2012 10:11:40 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 0724621F86A8 for ; Thu, 18 Oct 2012 10:11:39 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q9IHBTEo011923; Thu, 18 Oct 2012 19:11:29 +0200 Date: Thu, 18 Oct 2012 19:11:29 +0200 From: Willy Tarreau To: Barry Leiba Message-ID: <20121018171129.GO9392@1wt.eu> References: <20121018064805.GI7517@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Mon, 22 Oct 2012 08:25:26 -0700 Cc: saag@ietf.org Subject: Re: [saag] Input for conflict review of draft-secure-cookie-session-protocol X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 17:11:42 -0000 Hi Barry, On Thu, Oct 18, 2012 at 01:03:02PM -0400, Barry Leiba wrote: > > I just checked the following document and have one main concern : > ... > > Hence, I'm failing to see what specific use case this protocol covers, > > however I see a risk that it is adopted by users who don't completely > > understand its security implications. > > Willy, did you read my note carefully? In particular: > > > Please read RFC 5742, Section 3, and be aware that we are not looking > > for detailed comments on the document itself (see below). We > > specifically need input on whether this document is in conflict with > > work that's being done in the IETF. Look at the five possible > > responses specified in that section, and help us determine whether any > > of 2 through 5 applies. Please be specific in your response. > > Your response is not related to whether this conflicts with existing > IETF work, but is addressing issues in the document. Well, maybe it's a matter of point of view. Adam took great care to rework the cookie spec and achieve RFC6265 with a number of usage recommendations to use cookies in the safest way. Since this draft suggests a usage which seems totally insecure to me, I found it appropriate to raise it as conflicting with the intended use of cookies. Maybe I was wrong, and if so please accept my apologises. Then it's unclear to me what kind of conflict should be raised :-/ > You need to take > these up with the authors and the Independent Stream Editor. Again > from my note: > > > In addition to this, we're sure that the authors and the ISE would > > appreciate comments about the document. If you have those, you may > > send them directly to the authors at > > > > and to the ISE at . OK I will resend there then. Thanks and sorry for the confusion. Willy From w@1wt.eu Thu Oct 18 10:41:23 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 422D721F8530 for ; Thu, 18 Oct 2012 10:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.774 X-Spam-Level: X-Spam-Status: No, score=-4.774 tagged_above=-999 required=5 tests=[AWL=-2.731, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkBRQxGXAw05 for ; Thu, 18 Oct 2012 10:41:22 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCA321F8507 for ; Thu, 18 Oct 2012 10:41:22 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q9IHfDlZ012063; Thu, 18 Oct 2012 19:41:13 +0200 Date: Thu, 18 Oct 2012 19:41:13 +0200 From: Willy Tarreau To: Barry Leiba Message-ID: <20121018174113.GA11965@1wt.eu> References: <20121018064805.GI7517@1wt.eu> <20121018171129.GO9392@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Mon, 22 Oct 2012 08:25:26 -0700 Cc: saag@ietf.org Subject: Re: [saag] Input for conflict review of draft-secure-cookie-session-protocol X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 17:41:23 -0000 On Thu, Oct 18, 2012 at 01:22:38PM -0400, Barry Leiba wrote: > > Well, maybe it's a matter of point of view. Adam took great care to > > rework the cookie spec and achieve RFC6265 with a number of usage > > recommendations to use cookies in the safest way. Since this draft > > suggests a usage which seems totally insecure to me, I found it > > appropriate to raise it as conflicting with the intended use of > > cookies. Maybe I was wrong, and if so please accept my apologises. > > Then it's unclear to me what kind of conflict should be raised :-/ > > True, and it's sometimes unclear to us as well. OK that makes me feel more comfortable now :-) > I'll see your :-/ and raise you a :-( > > What we're looking for is this sort of thing: > - Is this document in direct conflict with current work in a working > group? Which one(s)? > - Should this be handled by an existing working group? Which one? > - Should a new working group be chartered for this, rather than doing > it as an Independent Submission? > - Does it appear that the authors are trying to get around the system > by submitting this to the ISE? > - Is this spec proposing something sufficiently harmful that it needs > proper IETF review to fix it? > > I suppose your comments could be arguing for that last one. Yes, seems appropriate. > But look at the list in RFC 5742, Section 3, and comment here on which > of the five responses you think applies to this document. I'm balanced between 3 and 5 : 3. The IESG has concluded that publication could potentially disrupt the IETF work done in WG and recommends not publishing the document at this time. 5. The IESG has concluded that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. Basically if used as general purpose cookies, the impossibility to ensure non-replay would be a no-go for me as it goes against the principles of RFC6265, hence #3. However, if designed for use in very specific cases I'm not aware of, then probably the document needs some editorial adjustments to clearly indicate that it is not for general use and possibly be reviewed by specialists to ensure nothing was left unchecked, hence #5. > And then > definitely give your other feedback on the document to the ISE and the > document authors. Done. > Thanks, Willy. You're welcome. Cheers, Willy From d.w.chadwick@kent.ac.uk Thu Oct 18 11:17:58 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAAC821F847B for ; Thu, 18 Oct 2012 11:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+8kD8jfBN3w for ; Thu, 18 Oct 2012 11:17:57 -0700 (PDT) Received: from mx1.kent.ac.uk (mx1.kent.ac.uk [129.12.21.39]) by ietfa.amsl.com (Postfix) with ESMTP id 99C2A21F8470 for ; Thu, 18 Oct 2012 11:17:57 -0700 (PDT) Received: from mx0.kent.ac.uk ([129.12.21.32]) by mx1.kent.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1TOufH-0005Il-SB; Thu, 18 Oct 2012 19:17:51 +0100 Received: from [63.133.198.91] (helo=[172.16.13.114]) by mx0.kent.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1TOufH-00026k-1I; Thu, 18 Oct 2012 19:17:51 +0100 Message-ID: <508047CB.9080008@kent.ac.uk> Date: Thu, 18 Oct 2012 19:17:47 +0100 From: David Chadwick User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Kingsley Idehen References: <88F98DFD-EF7D-4444-A9C2-FB8E15F5DA89@bblfish.net> <3757D928-C3AE-4630-98E7-E30B5CC604B0@cisco.com> <7E1636E02F313F4BA69A428B314B77C708217189@xmb-aln-x12.cisco.com> <7ABCD095-4B09-40DD-A084-1BBE761CA72F@bblfish.net> <50802328.70205@openlinksw.com> <508033C3.1010205@openlinksw.com> <508034BB.7040102@kent.ac.uk> <50803D68.9040206@openlinksw.com> In-Reply-To: <50803D68.9040206@openlinksw.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 22 Oct 2012 08:25:26 -0700 Cc: "Klaas Wierenga \(kwiereng\)" , "public-identity@w3.org" , "saag@ietf.org" , "public-privacy@w3.org" , "public-philoweb@w3.org" , "public-webid@w3.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 18:17:58 -0000 On 18/10/2012 18:33, Kingsley Idehen wrote: > On 10/18/12 12:56 PM, David Chadwick wrote: >> and if the user puts his/her email address attribute in the U-Prove >> token??? > > Then they've broken un-linkability since a mailto: scheme URI is the > ultimate unit of privacy compromise on today's Internet and Web, yes I know. My main point was that using U-Prove or Idemix is employing a very sophisticated privacy protecting encryption scheme that can easily and trivially be undone by everyday users who provide their email address attributes inside the tokens. So I suspect the applicability of these tokens will be quite limited regards David bearing > in mind the state of the underground personal information networks. > Every social network uses your mailto: scheme URI as a key component. > Even if they don't share this data with 3rd parties, other pieces of the > puzzle come together quite easily due to the fundamental semantics > associated with mailto: scheme URIs i.e., you only need to have them in > an inverseFunctionalProperty relationship for entropy to drive the rest > of the profile coalescence. > > The world I envisage starts with the ability to generate (with ease) > X.509 certificates bearing WebIDs in their SAN slots. We will have many > such certificates for a variety of purposes. An email address or any > other overtly identifiable data isn't a mandatory component an X.509 > certificate :-) > > If I want to send something that's only readable by You, I would encrypt > that email via S/MIME. When I make an access policy or resource ACL I > tend not to require email addresses, for instance [1]. > > Links: > > 1. http://bit.ly/Rbnayv -- some posts about the use of social entity > relationship semantics to constrain access to my personal data space on > the Web. > > Kingsley >> >> David >> >> On 18/10/2012 17:52, Kingsley Idehen wrote: >>> On 10/18/12 12:06 PM, Ben Laurie wrote: >>>> On 18 October 2012 16:41, Kingsley Idehen >>>> wrote: >>>>> On 10/18/12 11:34 AM, Ben Laurie wrote: >>>>>> On 9 October 2012 14:19, Henry Story wrote: >>>>>>> Still in my conversations I have found that many people in security >>>>>>> spaces >>>>>>> just don't seem to be able to put the issues in context, and can >>>>>>> get >>>>>>> sidetracked >>>>>>> into not wanting any linkability at all. Not sure how to fix that. >>>>>> You persist in missing the point, which is why you can't fix it. The >>>>>> point is that we want unlinkability to be possible. Protocols that do >>>>>> not permit it or make it difficult are problematic. I have certainly >>>>>> never said that you should always be unlinked, that would be stupid >>>>>> (in fact, I once wrote a paper about how unpleasant it would be). >>>>>> >>>>>> As I once wrote, anonymity should be the substrate. Once you have >>>>>> that, you can the build on it to be linked when you choose to be, and >>>>>> not linked when you choose not to be. If it is not the substrate, >>>>>> then >>>>>> you do not have this choice. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Do you have example of what you describe? By that question I mean: >>>>> implicit >>>>> anonymity as a functional substrate of some realm that we experience >>>>> today? >>>> That's what selective disclosure systems like U-Prove and the PRIME >>>> project are all about. >>>> >>>> >>>> >>> Ben, >>> >>> How is the following incongruent with the fundamental points we've been >>> trying to make about the combined effects of URIs, Linked Data, and >>> Logic en route to controlling privacy at Web-scale? >>> >>> Excerpt from Microsoft page [1]: >>> >>> A U-Prove token is a new type of credential similar to a PKI certificate >>> that can encode attributes of any type, but with two important >>> differences: >>> >>> 1) The issuance and presentation of a token is unlinkable due to the >>> special type of public key and signature encoded in the token; the >>> cryptographic “wrapping” of the attributes contain no correlation >>> handles. This prevents unwanted tracking of users when they use their >>> U-Prove tokens, even by colluding insiders. >>> >>> 2) Users can minimally disclose information about what attributes are >>> encoded in a token in response to dynamic verifier policies. As an >>> example, a user may choose to only disclose a subset of the encoded >>> attributes, prove that her undisclosed name does not appear on a >>> blacklist, or prove that she is of age without disclosing her actual >>> birthdate. >>> >>> >>> Why are you assuming that a hyperlink based pointer (de-referencable >>> URI) placed in the SAN of minimalist X.509 certificate (i.e., one that >>> has now personally identifiable information) can't deliver the above and >>> more? >>> >>> Please note, WebID is a piece of the picture. Linked Data, Entity >>> Relationship Semantics and Logic are other critical parts. That's why >>> there isn't a golden ontology for resource access policies, the resource >>> publisher can construct a plethora of resource access policies en route >>> to leveraging the power of machine discernible entity relationship >>> semantics and first-order logic. >>> >>> In a most basic super paranoid scenario, if I want to constrain access >>> to a resource to nebulous entity "You" I would share a PKCS#12 document >>> with that entity. I would also have an access policy in place based on >>> the data in said document. I would also call "You" by phone to give you >>> the password of that PKCS#12 document. Once that's all sorted, you can >>> open the document, get your crytpo data installed in your local keystore >>> and then visit the resource I've published :-) >>> >>> Links: >>> >>> 1. http://research.microsoft.com/en-us/projects/u-prove/ >>> 2. http://en.wikipedia.org/wiki/Zero-knowledge_proof -- I don't see >>> anything about that being incompatible with what the combined use of >>> de-referencable URIs based names, Linked Data, Entity Relationship >>> Semantics, Reasoning, and existing PKI deliver. >>> >> >> > > From d.w.chadwick@kent.ac.uk Thu Oct 18 12:18:54 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 705CD21F81FF for ; Thu, 18 Oct 2012 12:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ncd6HhHILju7 for ; Thu, 18 Oct 2012 12:18:53 -0700 (PDT) Received: from mx1.kent.ac.uk (mx1.kent.ac.uk [129.12.21.39]) by ietfa.amsl.com (Postfix) with ESMTP id CBC6B21F86F3 for ; Thu, 18 Oct 2012 12:18:53 -0700 (PDT) Received: from mx0.kent.ac.uk ([129.12.21.32]) by mx1.kent.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1TOvcE-00085z-TZ; Thu, 18 Oct 2012 20:18:46 +0100 Received: from [63.133.198.91] (helo=[172.16.13.114]) by mx0.kent.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1TOvcD-00052p-LT; Thu, 18 Oct 2012 20:18:46 +0100 Message-ID: <50805611.2000904@kent.ac.uk> Date: Thu, 18 Oct 2012 20:18:41 +0100 From: David Chadwick User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Ben Laurie References: <88F98DFD-EF7D-4444-A9C2-FB8E15F5DA89@bblfish.net> <3757D928-C3AE-4630-98E7-E30B5CC604B0@cisco.com> <7E1636E02F313F4BA69A428B314B77C708217189@xmb-aln-x12.cisco.com> <7ABCD095-4B09-40DD-A084-1BBE761CA72F@bblfish.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 22 Oct 2012 08:25:26 -0700 Cc: "public-philoweb@w3.org" , "public-identity@w3.org" , "saag@ietf.org" , "public-privacy@w3.org" , "Klaas Wierenga \(kwiereng\)" , "public-webid@w3.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 19:18:54 -0000 Hi Ben I disagree. It depends upon your risk assessment. Your stand is like saying TLS should be the substrate, not http. There are two alternative viewpoints. You can either start with the lowest security/privacy and add to it, or make the highest security/privacy the default and then take from it. So you should not necessarily mandate that U-Prove/Idemix are the default tokens, but rather only require them if your risk assessment says privacy protection is essential regards David On 18/10/2012 16:34, Ben Laurie wrote: > On 9 October 2012 14:19, Henry Story wrote: >> Still in my conversations I have found that many people in security spaces >> just don't seem to be able to put the issues in context, and can get sidetracked >> into not wanting any linkability at all. Not sure how to fix that. > > You persist in missing the point, which is why you can't fix it. The > point is that we want unlinkability to be possible. Protocols that do > not permit it or make it difficult are problematic. I have certainly > never said that you should always be unlinked, that would be stupid > (in fact, I once wrote a paper about how unpleasant it would be). > > As I once wrote, anonymity should be the substrate. Once you have > that, you can the build on it to be linked when you choose to be, and > not linked when you choose not to be. If it is not the substrate, then > you do not have this choice. > From hartmans@mit.edu Fri Oct 19 11:22:04 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22BD821F84A5 for ; Fri, 19 Oct 2012 11:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.574 X-Spam-Level: X-Spam-Status: No, score=-96.574 tagged_above=-999 required=5 tests=[AWL=-0.862, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwqCxfHtN7Jc for ; Fri, 19 Oct 2012 11:22:02 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id D435621F8476 for ; Fri, 19 Oct 2012 11:21:59 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 5A2822010B; Fri, 19 Oct 2012 14:21:42 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 503B04AD5; Fri, 19 Oct 2012 14:21:56 -0400 (EDT) From: Sam Hartman To: Kingsley Idehen References: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <5081910A.1040601@openlinksw.com> Date: Fri, 19 Oct 2012 14:21:56 -0400 In-Reply-To: <5081910A.1040601@openlinksw.com> (Kingsley Idehen's message of "Fri, 19 Oct 2012 13:42:34 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Mon, 22 Oct 2012 08:25:26 -0700 Cc: "public-philoweb@w3.org" , Sam Hartman , "public-identity@w3.org" , "saag@ietf.org" , "public-privacy@w3.org" , "public-webid@w3.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 18:22:04 -0000 >>>>> "Kingsley" == Kingsley Idehen writes: Kingsley> Does "Data Access Policy" work any better so that we stop Kingsley> being distracted by something with different means to the Kingsley> participants in this debate. Kingsley> Can a data access policy deliver unlinkability ? Absolutely not. I think you're talking past each other, but the data access policy on the accessed resource cannot deliver unlinkability in the sense that I and I think Ben are using. The data access policy on a centrally stored credential may be part of delivering unlinkability with regard to certain parties in some security schemes. If you believe that data access policies are part of unlinkability, then I'd suggest starting to see if we're talking about the same definition of unlinkability. From Mo.McRoberts@bbc.co.uk Sun Oct 21 01:24:05 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D5221F8BAC for ; Sun, 21 Oct 2012 01:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.999 X-Spam-Level: X-Spam-Status: No, score=-103.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpr-Yh+E6Y+y for ; Sun, 21 Oct 2012 01:24:04 -0700 (PDT) Received: from mailout1.mh.bbc.co.uk (mailout1.mh.bbc.co.uk [132.185.144.153]) by ietfa.amsl.com (Postfix) with ESMTP id 4573821F8BA9 for ; Sun, 21 Oct 2012 01:24:03 -0700 (PDT) Received: from BGB01XI1003.national.core.bbc.co.uk ([10.184.50.53]) by mailout1.mh.bbc.co.uk (8.14.4/8.14.3) with ESMTP id q9L8O1bQ000254; Sun, 21 Oct 2012 09:24:01 +0100 (BST) Received: from BGB01XUD1009.national.core.bbc.co.uk ([169.254.8.145]) by BGB01XI1003.national.core.bbc.co.uk ([10.184.50.53]) with mapi id 14.01.0355.002; Sun, 21 Oct 2012 09:24:01 +0100 From: Mo McRoberts To: Ben Laurie Thread-Topic: [saag] Liking Linkability Thread-Index: AQHNr2VswW6Jj4A0pkCv1RVTYc/7Nw== Date: Sun, 21 Oct 2012 08:24:08 +0000 Message-ID: References: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.211] x-exclaimer-md-config: 1cd3ac1c-62e5-43f2-8404-6b688271c769 Content-Type: text/plain; charset="Windows-1252" Content-ID: <2673411E12372F46AED0DA6D550BB736@bbc.co.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 22 Oct 2012 08:25:26 -0700 Cc: "public-philoweb@w3.org" , "public-identity@w3.org" , "saag@ietf.org" , "public-privacy@w3.org" , Sam Hartman , "public-webid@w3.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 08:24:36 -0000 On 18 Oct 2012, at 20:29, Ben Laurie wrote: > I really feel like I am beating a dead horse at this point, but > perhaps you'll eventually admit it. Your public key links you. Access > control on the rest of the information is irrelevant. Indeed, access > control on the public key is irrelevant, since you must reveal it when > you use the client cert. Incidentally, to observers as well as the > server you connect to. Right, but that's the nature of a persistent identifier which is (surely) a= prerequisite for auth =97 assuming one doesn't wish to remain anonymous an= d have some auth, you could hypothetically avoid the cross-domain linkabili= ty issue by having a key-per-site, which could be semi-automated on the cli= ent side. What I can't see is how you can maintain persistence on the server side wit= hout something which ultimately boils down to (or otherwise allows the stor= age of) a persistent identifier. M. -- Mo McRoberts - Technical Lead - The Space 0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E, Zone 1.08, BBC Scotland, Pacific Quay, Glasgow, G51 1DA Project Office: Room 7083, BBC Television Centre, London W12 7RJ ----------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specif= ically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ----------------------------- From nathan@webr3.org Sun Oct 21 03:22:32 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C8F21F88D8 for ; Sun, 21 Oct 2012 03:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWPcJ051LvOI for ; Sun, 21 Oct 2012 03:22:30 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4F30E21F8918 for ; Sun, 21 Oct 2012 03:22:29 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so1106848wey.31 for ; Sun, 21 Oct 2012 03:22:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=dKOoxCyhO6/7CX0wiqoyTX9/cfEHgj4+bzfElDZLMh8=; b=CYl8SNQ5VgbOzhqC18zW9EBCIC2Q62lVT7N4/5uxRSaJHy7cVoo6CEzHyNCpvJyM1a /E9M5C0N/wTET/DhKOZoQSZDx6LS6cSvnIbvfi6MGaZWISzXgyKFRZwvHUmd8DQWksyk JJ8kaDDTLhPuu2w+jiJ2/ZMk5ynmq573BBdby5/OiP9B/AVQF/Tz2iq19aJX+vIDW7cH SbX5tVZYkWeRn/CvaJaWkHsihZO3pTU9P/e6nqY6Qeq4YON2wpagGPhZ5BkiXP8j/4ga DwKZGuZOpkR+DItjzaF7uKxPU0iNssyPEF1lDDzIrOpnygw4X9h196CFu1+SAbigHtOh 05LA== Received: by 10.216.141.16 with SMTP id f16mr3975320wej.130.1350814949023; Sun, 21 Oct 2012 03:22:29 -0700 (PDT) Received: from [192.168.1.69] (host86-141-252-78.range86-141.btcentralplus.com. [86.141.252.78]) by mx.google.com with ESMTPS id fp6sm24938807wib.0.2012.10.21.03.22.27 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 21 Oct 2012 03:22:28 -0700 (PDT) Message-ID: <5083CCCF.2060407@webr3.org> Date: Sun, 21 Oct 2012 11:22:07 +0100 From: Nathan Organization: webr3 User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Ben Laurie References: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmiQ4PMCyao07RcR2bUhcvUugpzXjpVbvNJUUUB7E0TU1pZqbAhAcJDZI1hvOZKNhe7p5BB X-Mailman-Approved-At: Mon, 22 Oct 2012 08:25:23 -0700 Cc: "public-philoweb@w3.org" , "public-identity@w3.org" , "saag@ietf.org" , "public-privacy@w3.org" , Sam Hartman , "public-webid@w3.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: nathan@webr3.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 10:22:32 -0000 Ben Laurie wrote: > I'm getting quite tired of this: the point is, you cannot achieve > unlinkability with WebID except by using a different WebIDs. You made > the claim that ACLs on resources achieve unlinkability. This is > incorrect. You're 100% correct here Ben, and I'm unsure why it's so hard to convey!? If you use the same identifier for more than one request, subsequent requests can be associated with the first request. An identifier here is any identifying, stable, information - key parts and URIs. If the issue is only unlinkability across sites, then you just have a keypair+uri per site. Or better, key-pair only, and that's associated with an identifier for the agent behind the interface. You're correct that ACLs won't cut it. From hartmans@mit.edu Sun Oct 21 10:55:35 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E96D21F88BE for ; Sun, 21 Oct 2012 10:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.994 X-Spam-Level: X-Spam-Status: No, score=-99.994 tagged_above=-999 required=5 tests=[AWL=2.605, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zpt-gREYZf46 for ; Sun, 21 Oct 2012 10:55:29 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 5673B21F889B for ; Sun, 21 Oct 2012 10:55:29 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id B3A7A20115; Sun, 21 Oct 2012 13:55:08 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8A5414AD5; Sun, 21 Oct 2012 13:55:25 -0400 (EDT) From: Sam Hartman To: Kingsley Idehen References: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <5084238D.9040106@openlinksw.com> <50842A1D.8090104@openlinksw.com> Date: Sun, 21 Oct 2012 13:55:25 -0400 In-Reply-To: <50842A1D.8090104@openlinksw.com> (Kingsley Idehen's message of "Sun, 21 Oct 2012 13:00:13 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Mon, 22 Oct 2012 08:25:26 -0700 Cc: "public-philoweb@w3.org" , "public-identity@w3.org" , "saag@ietf.org" , "public-privacy@w3.org" , Sam Hartman , "public-webid@w3.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 17:55:35 -0000 I think if I hear the phrase context fluidity or nebulous enttity one more time I'm going to give up in disgust. Those phrases don't have enough meaning to have any place in a security argument. You seem to believe that it is necessary to prove an event is related to a person in order to have a privacy problem. If there are 20 seditious (in the context of some government) messages posted and the government is able to link those events down to 3 machines and conclude that only 10 people had access to those machines at the same time, you have a privacy problem. If the government decides that executing 10 people is an acceptable cost those 10 people are just as dead even if 9 of them had nothing to do with it. Sitting there going "you never proved it was me, only my machine," isn't going to help you as the fluids of your context are leaking out of an ever more nebulous entity. The fact is that by linking events, people can gain information about real-world entities that might have had something to do with an event. To the extent they gain that information, there is a loss of privacy. Not all losses of privacy are bad. Not all linkability is bad. I give up privacy and create linkability every time I log into a site, so that I can store preferences, manage entries I've posted in the past, etc. Of course for the most part I'm not risking my fluid context with what I do online. I'd probably decide preferences weren't worth it if that was the potential price. But seriously, can we either move this discussion off IETF lists or use enough precision and stop hiding behind vague terminology that we can have a computer security discussion? Thanks for your consideration, --Sam From nathan@webr3.org Sun Oct 21 12:52:35 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59FD721F8985 for ; Sun, 21 Oct 2012 12:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YV2BP0uKfSSH for ; Sun, 21 Oct 2012 12:52:34 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 426F421F84BC for ; Sun, 21 Oct 2012 12:52:33 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so1501184wib.13 for ; Sun, 21 Oct 2012 12:52:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=tLKYGdhwtF+21hugduwJkD9zmUImls8zRdsGLqVdA+o=; b=WfSuHIkqMfLjiF4v4eRwdONGvFhEab0NYclzSh+LTSihEuVFIzKDZ7U6qXoPIYiCFK iXoHbjnBxh+a3YyRqmkCnpRTj2YKZhoDJVMp9DoD+kGit9PWpKAmeMcArjFGgSKLNqJr qnAanTlDCRJuw3eRwf//OkuGju+76Z8zA2D+MxMgTr9oEwt1/Y9CaeinkPveLBoAFIXh U41DO1Q1TEaR1hptX0B8VXaWDLoWQB8MxfxlAc4S752hlDLtko3abN6m63cA1zfH3d8r wXTDeiG6cA1CPPXOgBnuhJ9wL93jjXDSEHaggQU8i+DA9cukQr6yTklu4RcYLjGgysXj lDcQ== Received: by 10.180.101.230 with SMTP id fj6mr16305289wib.16.1350849153106; Sun, 21 Oct 2012 12:52:33 -0700 (PDT) Received: from [192.168.1.69] (host86-141-252-78.range86-141.btcentralplus.com. [86.141.252.78]) by mx.google.com with ESMTPS id k20sm47593839wiv.11.2012.10.21.12.52.31 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 21 Oct 2012 12:52:32 -0700 (PDT) Message-ID: <50845268.4010509@webr3.org> Date: Sun, 21 Oct 2012 20:52:08 +0100 From: Nathan Organization: webr3 User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Kingsley Idehen References: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <5083CCCF.2060407@webr3.org> <50842789.3080301@openlinksw.com> In-Reply-To: <50842789.3080301@openlinksw.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQndEph5iwWBp97pIBEUlDXKsAfQbMu+5ta7RrT5n/bKQWQDmc7LSCw7wO5GgURY7Os8nHyn X-Mailman-Approved-At: Mon, 22 Oct 2012 08:25:26 -0700 Cc: "public-philoweb@w3.org" , Sam Hartman , "public-identity@w3.org" , "saag@ietf.org" , Melvin Carvalho , "public-privacy@w3.org" , "public-webid@w3.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: nathan@webr3.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 19:52:35 -0000 Kingsley Idehen wrote: > On 10/21/12 6:22 AM, Nathan wrote: >> Ben Laurie wrote: >>> I'm getting quite tired of this: the point is, you cannot achieve >>> unlinkability with WebID except by using a different WebIDs. You made >>> the claim that ACLs on resources achieve unlinkability. This is >>> incorrect. >> >> You're 100% correct here Ben, and I'm unsure why it's so hard to convey!? >> >> If you use the same identifier for more than one request, subsequent >> requests can be associated with the first request. An identifier here >> is any identifying, stable, information - key parts and URIs. >> >> If the issue is only unlinkability across sites, then you just have a >> keypair+uri per site. Or better, key-pair only, and that's associated >> with an identifier for the agent behind the interface. >> >> You're correct that ACLs won't cut it. >> >> >> >> >> > Nathan, > > What is the subject of unlinkability ? > > I am sure you know that Henry and I are fundamentally referring to > nebulous real-world entities such as "You" and "I". A composite key of: > machine name, user agent name, and a document referrer links != said > neboulus entity. Even further away in today world of multiple form > factor devices that interact with the Internet and Web. > > There is no precise mechanism for electronically nailing down nebulous > entity "You" and "I". We aren't of the Internet or Web, so you can > apprehend us in person. At best you can speculate that we are the > subjects of tokens comprised of composite keys. > > Unlinkability is subject to context fluidity and temporality once you > add neboulus congnitive entites (not of the Web or Internet) to the > equation. I believe you know this anyway :-) We cannot say that a URI refers to "you" or "I" in one breathe, and say it doesn't (or may not) in another. There is a use case which provides a technical requirement here, one which is simply to not use identifiable information between requests to different origin servers, and sometimes more granular, not using the same identifiable information between requests to the same server. WebID, just like any auth protocol can be used, it just means using it on a one time basis, or only for a particular origin. Personally I feel there are still questions here with WebID, as currently people use usernames/emails and passwords almost everywhere, and they can pick different usernames/emails/passwords on every site/origin. Suppose WebID was to gain 100% adoption overnight, we'd suddenly be in a position where everybody usually used the same identifier (rather than usernames and email addresses) and the same key (rather than multiple passwords) - because we've never been in a world like that, we don't know the consequences yet. Thus, when security and identity experts suggest that we need to handle unlinkability, or consider that we may often need per origin WebIDs (or even have that as the default mode), then we may be wise to say "okay", go away and find our options, then report them back for consideration and review. It by no means limits WebID, rather it just makes it applicable to a broader range of use cases. Best as always, Nathan From henry.story@bblfish.net Sun Oct 21 15:14:11 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3439221F887A for ; Sun, 21 Oct 2012 15:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjiFawadEV1o for ; Sun, 21 Oct 2012 15:14:10 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id B771621F855B for ; Sun, 21 Oct 2012 15:14:09 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so1563319wib.13 for ; Sun, 21 Oct 2012 15:14:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=Ee0r5Qo0YxMu4Fa435acsT4IYOuENLb31mSkrdypTD4=; b=Yrh9F8YaAPQBz+5QOnPZ6RX65mzRWAFlLL2rKpFS/fB3sqvW8SFoYDR/wUNdBgd+gB VyJeFEipz29DdBDVkXg+uMC+AMO+TX8u1/eFavN/iwc2Iq/a8IXHKrLJ03QlKX5keZKt 7xnw5/YdrGaMwtbRxPoxMp6KyeTsf1Mw6hC7FAXzuHLdXmfOeO1Vu/wG8qW6KcMQJNBj WAqcNrMB67ys7vTzcOPOBfi44w0+06m6le/mSggA86hDtwd7Ohks18C7ymRZTCRLQxnB n436mhRA8SjNrh+s1+r7uYr8btGKOGmy1NQP1l+BYRuDLgOyWET4jCaPAB/D+VnMTlI9 f2dQ== Received: by 10.180.99.99 with SMTP id ep3mr16736277wib.15.1350857648627; Sun, 21 Oct 2012 15:14:08 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-132-122.w86-198.abo.wanadoo.fr. [86.198.99.122]) by mx.google.com with ESMTPS id w8sm47989860wif.4.2012.10.21.15.13.57 (version=SSLv3 cipher=OTHER); Sun, 21 Oct 2012 15:13:59 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_E03B4CA0-6319-49B8-9979-0A08AE5AF0DD"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Henry Story In-Reply-To: <8F8A1ABB-AB05-4DD0-8846-ECF333C3E782@gmail.com> Date: Mon, 22 Oct 2012 00:13:56 +0200 Message-Id: References: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <5084238D.9040106@openlinksw.com> <8F8A1ABB-AB05-4DD0-8846-ECF333C3E782@gmail.com> To: Dick Hardt X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQml06PQ+UYcKqT8hjcvlND1cOvrXbzIduQqwiKIqwYgAKdkLS5WupOl8oD+5HNGD1NM+N9V X-Mailman-Approved-At: Mon, 22 Oct 2012 08:25:26 -0700 Cc: "public-philoweb@w3.org" , "public-identity@w3.org" , "saag@ietf.org" , "public-privacy@w3.org" , Kingsley Idehen , Sam Hartman , "public-webid@w3.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 22:14:11 -0000 --Apple-Mail=_E03B4CA0-6319-49B8-9979-0A08AE5AF0DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 It would be nice if we could remove the ad-hominem attacks here. These issues can be worked out clearly and calmly by careful reasoning and attending to some existing definitions.=20 Below I show how I agree with Dick Hard and Ben Laurie that public=20 keys are identifiers. But the point of this thread entitled=20 "Liking Linkability" is that this is not the problem to privacy that it is thought to be. Indeed my point is that linkability is very = important=20 to increase privacy....=20 On 21 Oct 2012, at 23:17, Dick Hardt wrote: >=20 > On Oct 21, 2012, at 9:32 AM, Kingsley Idehen = wrote: >=20 >> On 10/18/12 3:29 PM, Ben Laurie wrote: >>>=20 >>> I really feel like I am beating a dead horse at this point, but >>> perhaps you'll eventually admit it. Your public key links you. = Access >>> control on the rest of the information is irrelevant. Indeed, access >>> control on the public key is irrelevant, since you must reveal it = when >>> you use the client cert. Incidentally, to observers as well as the >>> server you connect to. >>>=20 >> A public key links to a private key. >=20 > A public key or private key *is* an identifier. If there is a 1:1 = mapping of public/private key pair to a user, and if the key pair is = used at more than one place, then those places know it is the same user = and the activities at each of those places is linked. Note Dick, that I (Henry Story) agree with you and Ben Laurie here: A = public key is=20 an identifier. If you use the same public key to identify yourself at = various sites then those sites can link you. This may be what you do intend to do = though, and so=20 this is not a priori a bad thing. Which is why the title of this post is = "Liking Linkability". In this thread my argument has consisted in a making two points: 1. that showing someone an identifier - be it public key or other = string with an=20 inverse functional relation to an agent - may not be a linkability = problem ( because you may not consider the agent receiving the information as = the enemy ) 2. Show how linkability is important for privacy 1. linkability -------------- If we look at the definition given of linkability in=20 https://tools.ietf.org/html/draft-hansen-privacy-terminology-03 it says: [[ Definition: Unlinkability of two or more Items Of Interest (e.g., subjects, messages, actions, ...) from an attacker's perspective means that within a particular set of information, the attacker cannot distinguish whether these IOIs are related or not (with a high enough degree of probability to be useful). ]] It is defining unlinkability in terms of "two or more items of interest=20= from an attacker's perspective". So my point is simply: who is the attacker? If you make the site you are=20= authenticating to with OpenID, BrowserId, or WebID be considered=20 the attacker then you should not use any of those technologies. If on = the=20 other hand you consider that those sites are *not* the attacker - = because say,=20 you only give them your identity when you are sure that you want to do = so - then the negative linkability claim cannot be made according to the = above=20 definition. Or at the very least it is a very different problem at that point: if = you=20 exclude the site you are authenticating to as the enemy, then = identifying yourself with your public key is not a linkability problem according to the above = definition. It would be if some other agent listening in on the conversation could = surmise your public key. They would then be able to know that you talked to site = B. (If they also knew the content of the conversation then they would know even = more, and your=20 privacy problem would indeed be greater) 2. linkability's importance to privacy -------------------------------------- I then argued that one cannot make a simple claim that linkability is a = bad thing. In fact there are good reasons to believe that certain types of = linkability are very important to create distributed social networks - which I call = the social web. A Social Web would clearly be a big improvement for privacy over how = things are=20 being done currently. I don't want to repeat this whole thread here = since that was=20 the argument I made in the initial post in this thread which is archived = here: http://lists.w3.org/Archives/Public/public-privacy/2012OctDec/0003.html >=20 >> You are the one being utterly obstinate here. >=20 > Not true =85 and I don't think that was a productive comment. I don't think that comment is fruitful either. This case can be argued well without ad-hominem attacks.=20 >=20 >> I encourage you to make you point with clear examples so that others = can juxtapose your views and ours. >=20 > Perhaps my explanation above makes the point clear to you. >=20 > -- Dick Social Web Architect http://bblfish.net/ --Apple-Mail=_E03B4CA0-6319-49B8-9979-0A08AE5AF0DD Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPDTCCByMw ggYLoAMCAQICAwTQYzANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEyMDgyOTAxNDU1NloXDTEzMDgzMDA5MjM0MFowZTEZMBcGA1UEDRMQazQ2eDlvOXJDRE5m VzMwYzEgMB4GA1UEAwwXaGVucnkuc3RvcnlAYmJsZmlzaC5uZXQxJjAkBgkqhkiG9w0BCQEWF2hl bnJ5LnN0b3J5QGJibGZpc2gubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArHXp EmiifOSpudkJn1vAnFdZsuaLuYYLbdWL47o1rKD/kg8/RJUmTIM2ara4e/MOxR16mu2fyAca3H1U oIXNNXDbYQDu2PkfLoNSM5JGAoYbfB0nXBK//ZecidVMZ8eExd02/vFzo5vj9kQNaAPSYirid5xe 1cV9Y1RFjlEozuYAUhU8zi3taf22JM45ii2YrCEgVjDdez8yio0QoJeKEEL3JhL4tqpkbfIOHmdi HYx00S6YcCogDfxXc3zOJ3jcIj/F61eXG1qWX/lq9RAyoBjYHLWE2iHQPwdzum03ubcvOTlohqOR +/cVzvx10l6bJ46KitfbydXMh8HoY7QcmwIDAQABo4IDsjCCA64wCQYDVR0TBAIwADALBgNVHQ8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQRbT9qwRblII9x nAN2FlEMUD1LQzAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAiBgNVHREEGzAZgRdo ZW5yeS5zdG9yeUBiYmxmaXNoLm5ldDCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIw ggH/MC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsG AQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEF BQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9u IHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZv ciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5 IG9ibGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBTZWUg c2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5 LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3Js MIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20v c3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29t L2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALj/A19bRLmI7sMf0lVRrdN23NuRC7/UFSLZ DfcxrR1wOtQgAbrFlFLY+Otn6UWYIiWQpv2v5Ploqw9rMam5W8seC3TUt83StohXCmZ0EDmK87If B6kpd7FwJ0RFGCxn22hPU2kuhp2mbjJzCTrd3jWsXw63MXDUzHuucWGX2mY1Ji+zRECh568N7iWA 5jn9kWT+h7o7ywKbHc4qAnksghLYAnTfoCx1IPkT4/8A5hf38imhf9NcNGibrvt/e49sacf6GjRH Ot/lOCrEX2fh2YvTB5sdEKM5tjKCKNpFSqnRCKhsWZ9N9ZP7mRZfCOBjAMsm3CW2ygwlWXc54lgf p1UwggfiMIIFyqADAgECAgENMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQy MTAxNTRaFw0xMjEwMjIyMTAxNTRaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP 6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu 2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyU GHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmt xWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMB AAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUU3Ltkpzg2ssB XHx+ljVO8tS4UYIwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0 YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHmCAQEwCQYDVR0SBAIwADA9BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYB BQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMw JxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmls aXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29t IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRD FkFTdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENl cnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAqprh4FuMzh0b/B3GLDAgoLeTJv3xArbNESi/ Kf/HMM//gf8FzwUUNOCglH6dfYuLQQ/dTtOyMb4JoiL3T7xiVKEAOmQ+t+b/xLOMa0m18zoRqW4k 6Glyoyvc7LMrdpgYk/lEh5nq8tPd9BoNmwiiheXphIVH/QelTgUkNzTC7IVpmYVsKuNOnxE1jJFZ NNfqZZK/5Oto7C6PfOut11KmBQSLZarAz0b/mjghdBsYfHuhdO8vrOvD0g5g7dA4pkOAU2Ed4pSC owBSItyD/5aFwZ75ji6Yq7GCG3BpiyAP9st8h+inc0L+7kmrAMJaLMAmu6GZs5Xgsbzn0wUJvbD9 h5jnnMM9UaZDcxl2uLB04quGUWM6NiKGabbxQc680PYbeQrQu+e6J4uqNAxzoa5RxkBA5a/3qlbg F9uJBekCqJswx5vQ9khJrs8UTMaIFzbEC5VGQziQH3/6KJ4DUP85OJEnCx/quShWA6w318LDnba3 M6a5V+KoNLhsVi/TSxf90UbBqwdRR/cOwuGkNJh16NvvhIqO26osMg64CbZsDVrEDr7uSMV40ieB JTo49Iyt77ECOhz/pyhowa2EUP6aKav+L/wXzAPB3LNqzujGR0K1pbyFWKvyYmdungJtySWUMw+R 5DqpA2bFIOE56pfWPLHZxOL+8+r79PLFX+y2V6ExggNvMIIDawIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRp ZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1l ZGlhdGUgQ2xpZW50IENBAgME0GMwCQYFKw4DAhoFAKCCAa8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMDIxMjIxMzU2WjAjBgkqhkiG9w0BCQQxFgQU8+CJZfpP FRf/Zc4CZUk8nbPfLJMwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgME0GMwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0ECAwTQYzANBgkqhkiG9w0BAQEFAASCAQCQPMTkDP+jpQv/d4/tevyhsEVKVXqwi5wqs3Yf yeoXYou7oxhKq6g+bkOKfDMhDvlF5AMwKS791WwxY6zic5jOpLrLt7EdFIaxwfpzI6uAV/WCFBnA Yaluk+Vp2Xcnjvgd3eICyAjGMk88iYdUfeGkqVrXtKvXL9ZBvQwQbVgCag+ko1dt6GwV3uJ3yKKd WYfZ7avm+fw7uX77XEg/wFNS8Yg2XdLTiSkDUk9hu8JAfmICnjIP0rBHUl7j6ALS+XG8zna92xVU uCqVTGOr37ESd4HdZvIie5dJHBcGBi63zw0rYGpY/ZNwjNqXRY6vMgjjs1Z02beled8tpY+cA93R AAAAAAAA --Apple-Mail=_E03B4CA0-6319-49B8-9979-0A08AE5AF0DD-- From nathan@webr3.org Mon Oct 22 02:43:13 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B8921F8546 for ; Mon, 22 Oct 2012 02:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.879 X-Spam-Level: X-Spam-Status: No, score=-3.879 tagged_above=-999 required=5 tests=[AWL=-0.880, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vVE8ydySemU for ; Mon, 22 Oct 2012 02:43:12 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 0124721F8524 for ; Mon, 22 Oct 2012 02:43:11 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so1837862wib.13 for ; Mon, 22 Oct 2012 02:43:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=nq7wiPI+nL1fQX27xBQN5v+iG0zukpCgf9N4NKGTZAs=; b=Nw/UD3zSKuIUYgK/IYInhDkgnbJ9jULszBvqiGQzEWCbh+EwIaDgaR2mFLInVg6oAc XsqwuAxW1MXlTXBplKheVueFc2lA+kWIhOnr7Z+ZBkXYYbXwjPR2Z9a7LpDT4cA0iN6P SyhLY9ZnhOSvuYrX0pRqJot3hRHBcWdTsZq9t+YVwQDqJkWs2B28RBqVxfNJsCbykDTq WrgyPaIwNqCf49M3N/ci34FO/u2ngFFxdbCb9Qhhzhh7lY7iGWQda3V41EgsQucylm2L QoPNc9LxjCNFT3xkeJeG8t91j7aDnPZJfSmjvvm6JWxV0DwVth09PtUK7qpWK747KeeA d1SA== Received: by 10.216.197.205 with SMTP id t55mr5353035wen.156.1350898990507; Mon, 22 Oct 2012 02:43:10 -0700 (PDT) Received: from [192.168.1.69] (host86-141-252-78.range86-141.btcentralplus.com. [86.141.252.78]) by mx.google.com with ESMTPS id p4sm20984069wix.0.2012.10.22.02.43.08 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Oct 2012 02:43:09 -0700 (PDT) Message-ID: <50851512.9090803@webr3.org> Date: Mon, 22 Oct 2012 10:42:42 +0100 From: Nathan Organization: webr3 User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Kingsley Idehen References: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <5083CCCF.2060407@webr3.org> <50842789.3080301@openlinksw.com> <50845268.4010509@webr3.org> <5084AC77.8030600@openlinksw.com> In-Reply-To: <5084AC77.8030600@openlinksw.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmIN4jCUgRX5BDNOzhqMMo2zuYcUZlcoi5nnSfc3w/23prtRHdUyCyo7fJvkzjjxTv1716+ X-Mailman-Approved-At: Mon, 22 Oct 2012 08:25:26 -0700 Cc: "public-philoweb@w3.org" , Sam Hartman , "public-identity@w3.org" , "saag@ietf.org" , Melvin Carvalho , "public-privacy@w3.org" , "public-webid@w3.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: nathan@webr3.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 09:43:13 -0000 Kingsley Idehen wrote: > On 10/21/12 3:52 PM, Nathan wrote: >> Kingsley Idehen wrote: >>> On 10/21/12 6:22 AM, Nathan wrote: >>>> Ben Laurie wrote: >>>>> I'm getting quite tired of this: the point is, you cannot achieve >>>>> unlinkability with WebID except by using a different WebIDs. You made >>>>> the claim that ACLs on resources achieve unlinkability. This is >>>>> incorrect. >>>> >>>> You're 100% correct here Ben, and I'm unsure why it's so hard to >>>> convey!? >>>> >>>> If you use the same identifier for more than one request, subsequent >>>> requests can be associated with the first request. An identifier >>>> here is any identifying, stable, information - key parts and URIs. >>>> >>>> If the issue is only unlinkability across sites, then you just have >>>> a keypair+uri per site. Or better, key-pair only, and that's >>>> associated with an identifier for the agent behind the interface. >>>> >>>> You're correct that ACLs won't cut it. >>>> >>>> >>>> >>>> >>>> >>> Nathan, >>> >>> What is the subject of unlinkability ? >>> >>> I am sure you know that Henry and I are fundamentally referring to >>> nebulous real-world entities such as "You" and "I". A composite key >>> of: machine name, user agent name, and a document referrer links != >>> said neboulus entity. Even further away in today world of multiple >>> form factor devices that interact with the Internet and Web. >>> >>> There is no precise mechanism for electronically nailing down >>> nebulous entity "You" and "I". We aren't of the Internet or Web, so >>> you can apprehend us in person. At best you can speculate that we are >>> the subjects of tokens comprised of composite keys. >>> >>> Unlinkability is subject to context fluidity and temporality once you >>> add neboulus congnitive entites (not of the Web or Internet) to the >>> equation. I believe you know this anyway :-) >> >> We cannot say that a URI refers to "you" or "I" in one breathe, and >> say it doesn't (or may not) in another. > > You raise a good point, Now let me clarify, I don't believe (unless in > utter error) that I've ever claimed that a URI definitively refers to > "You", "Me", or "I". Of course, I cannot claim to have not made the > careless utterances such as "Your Personal URI" , for instance. > > A URI that serves as a WebID has always been a denotation mechanism for > a composite key comprised of: > > 1. private key > 2. public key > 3. URI that resolves to a profile document that describes a subject via > an entity relationship graph. > > The subject of an X.509 certificate is a nebulous entity. This entity is > associated with attribute and value pairs that comprise the profile > graph imprinted in said certificate. The semantics of an X.509 > certificate don't change the nature of the certificates subject. > >> >> There is a use case which provides a technical requirement here, one >> which is simply to not use identifiable information between requests >> to different origin servers, and sometimes more granular, not using >> the same identifiable information between requests to the same server. >> >> WebID, just like any auth protocol can be used, it just means using it >> on a one time basis, or only for a particular origin. > > WebID is a part of the picture, not the picture in its entirety. I've > pretty much tried to encourage others to be careful about conveying the > misconception that WebID (solely) resolves the issues at hand. It is > just a critical piece of the puzzle, that's it. > > You don't need to have a single WebID. Such a thing fails the most > mundane alter ego test re. 'Clarke Kent' and 'Superman' or 'Peter > Parker' and 'Spiderman'. > > Privacy is about the aforementioned personas not being comprised, under > any circumstances. The fact that DC world entities 'Clark Kent' and > 'Superman' used the same Web browser shouldn't comprise the alter ego > relationship between these personas. > > Unlinkability is about the alter ego paradox. > >> >> Personally I feel there are still questions here with WebID, as >> currently people use usernames/emails and passwords almost everywhere, >> and they can pick different usernames/emails/passwords on every >> site/origin. Suppose WebID was to gain 100% adoption overnight, we'd >> suddenly be in a position where everybody usually used the same >> identifier (rather than usernames and email addresses) and the same >> key (rather than multiple passwords) - because we've never been in a >> world like that, we don't know the consequences yet. > > See my comments above. Such a system is dead on arrival re. privacy. > There have to be multiple WebIDs and the exploitation of logic when > dealing with data access policies, and all of this has to occur within > specific interaction contexts. For instance, if I want only you to see a > document, I could knock up the require security tokens and send them to > you via a PKCS#12 file. You open the file then go GET the document in > question. Being super paranoid, I would more than likely speak to you > via phone about the username and password combo for opening up the > PKCS#12 file. >> >> Thus, when security and identity experts suggest that we need to >> handle unlinkability, or consider that we may often need per origin >> WebIDs (or even have that as the default mode), then we may be wise to >> say "okay", go away and find our options, then report them back for >> consideration and review. >> >> It by no means limits WebID, rather it just makes it applicable to a >> broader range of use cases. > > We need others (note: expert is utterly subjective to me) interested in > these matters to be constructive rather than dismissive. I chime in most > of the time because I see Henry going to immense pains to explain > matters only to be summarily dismissed in manners that I find > cognitively dissonant. > > A basic RDBMS product doesn't depend on single attribute/field primary > keys, why would such thinking even apply to the complex matter of > privacy. When I use the term composite, I am pretty much referring the > the same concept well understood in the RDBMS world. You can have a > 'super key' comprised of elements that are of themselves unique > identifiers. > > I don't believe in a single WebID neither does Henry. We just believe > that Web-scale verifiable identity is a critical part of the required > infrastructure. We also believe that a de-referencable URI (e.g., an > HTTP URI) is a very powerful vehicle for this endeavor, even more so > when combined with structured data and first-order logic. > > I only know of one way to deal with context fluidity at the software > level, and that's via logic integrated into data which produces self > describing data objects . I agree on all counts and feel/think the same, so I think I'll need to go and re-read this thread and see where the confusion is. Best, Nathan From benl@google.com Mon Oct 22 02:54:37 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF0421F89E9 for ; Mon, 22 Oct 2012 02:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.677 X-Spam-Level: X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLZFwIP6Kybt for ; Mon, 22 Oct 2012 02:54:37 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 94EB221F843A for ; Mon, 22 Oct 2012 02:54:36 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so1845146wib.13 for ; Mon, 22 Oct 2012 02:54:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=bZwZCovYwvXmyRbzytFvq58uPLSYd0uhY76AAInFs08=; b=DZt2vf3ErEuHuqf1CW3LrOQBlcGRbxwDWoUzV+mQ2qVY8oag68PB8rUXIpyhZtGvSi BVbPXGx1bA54upQTpGI6oe1nQfiX+bqHCzT4y8v3Raj9RR3L9gfsNQ6zNTsF3FMhX32p W7VXk6v9P+mjovlVsSTV9ODpWtowcRVlounQN9796C7sx8ZqsxwlsI+GO2WGS8CfGCXI aZsXVM2hJhnhmfj9cU/F7QDkrc+mvX9VywGJFpT1YhcX8b0QvZ9wW2uvdYisTsje2r2R bKXNu2QbH7LdoxpI40XFKjJYy3NSPsAdIzATZWxQ5fynlrsaX4Px/fVvr4aOC+Z6U0Kp rGwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=bZwZCovYwvXmyRbzytFvq58uPLSYd0uhY76AAInFs08=; b=Rmaqo0xSwaDWMOSLDofhvYgqwJ/PRJpLrlL/VMg/zWq7Bf9iTtP3fNIHqho38pItD3 n98MTKQoD0UlGT4Du9tvBSwn7SIy4tzfoAnkBLvt2g9t9IK0ppdQJzCZ88mDCrogcxhg mlyqdsOSUC++2LZZXUqED8Po2FYKSKyhsyq8DlKPJ35ihyYo1Z2ikQ9axUNE0bSzPG/H r5PY5/Bfvn08IL1mKsMZ2vMbKy25OUEdc7EcR+O16T/nkA3yFxP+mpCTjBN1SKteshDf 7/kWbctso4da5NBjtEVza1FRQP8kwVuNT4Lbeq7il77tFyUQF9arVAmOucXs66fVVDJ/ +ezQ== MIME-Version: 1.0 Received: by 10.216.136.23 with SMTP id v23mr5191616wei.45.1350899675464; Mon, 22 Oct 2012 02:54:35 -0700 (PDT) Received: by 10.194.76.170 with HTTP; Mon, 22 Oct 2012 02:54:35 -0700 (PDT) In-Reply-To: <50851512.9090803@webr3.org> References: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <5083CCCF.2060407@webr3.org> <50842789.3080301@openlinksw.com> <50845268.4010509@webr3.org> <5084AC77.8030600@openlinksw.com> <50851512.9090803@webr3.org> Date: Mon, 22 Oct 2012 10:54:35 +0100 Message-ID: From: Ben Laurie To: nathan@webr3.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlUP3NYZuNh2o/Ag98fHytOhiUgClbsdlX4AoyMAb0rHOyyZ83+A/fU3ZweHL+lqNwtxAZDt2WYecUf6d9S6q9SUu4r+OEn5ZrAVAiMXE7SLZAwDPMupnXcDkbjDhPJVvysSPPieGFbyMAH8B/Zmb8XI/QAZqSL14SGmDyGaoiGtzBSKj+xghlyLaiyqyK0xxqcg4h0 X-Mailman-Approved-At: Mon, 22 Oct 2012 08:25:26 -0700 Cc: "public-philoweb@w3.org" , "public-identity@w3.org" , "saag@ietf.org" , Melvin Carvalho , "public-privacy@w3.org" , Kingsley Idehen , Sam Hartman , "public-webid@w3.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 09:54:37 -0000 On 22 October 2012 10:42, Nathan wrote: > Kingsley Idehen wrote: >> >> On 10/21/12 3:52 PM, Nathan wrote: >>> >>> Kingsley Idehen wrote: >>>> >>>> On 10/21/12 6:22 AM, Nathan wrote: >>>>> >>>>> Ben Laurie wrote: >>>>>> >>>>>> I'm getting quite tired of this: the point is, you cannot achieve >>>>>> unlinkability with WebID except by using a different WebIDs. You made >>>>>> the claim that ACLs on resources achieve unlinkability. This is >>>>>> incorrect. >>>>> >>>>> >>>>> You're 100% correct here Ben, and I'm unsure why it's so hard to >>>>> convey!? >>>>> >>>>> If you use the same identifier for more than one request, subsequent >>>>> requests can be associated with the first request. An identifier here is any >>>>> identifying, stable, information - key parts and URIs. >>>>> >>>>> If the issue is only unlinkability across sites, then you just have a >>>>> keypair+uri per site. Or better, key-pair only, and that's associated with >>>>> an identifier for the agent behind the interface. >>>>> >>>>> You're correct that ACLs won't cut it. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> Nathan, >>>> >>>> What is the subject of unlinkability ? >>>> >>>> I am sure you know that Henry and I are fundamentally referring to >>>> nebulous real-world entities such as "You" and "I". A composite key of: >>>> machine name, user agent name, and a document referrer links != said >>>> neboulus entity. Even further away in today world of multiple form factor >>>> devices that interact with the Internet and Web. >>>> >>>> There is no precise mechanism for electronically nailing down nebulous >>>> entity "You" and "I". We aren't of the Internet or Web, so you can apprehend >>>> us in person. At best you can speculate that we are the subjects of tokens >>>> comprised of composite keys. >>>> >>>> Unlinkability is subject to context fluidity and temporality once you >>>> add neboulus congnitive entites (not of the Web or Internet) to the >>>> equation. I believe you know this anyway :-) >>> >>> >>> We cannot say that a URI refers to "you" or "I" in one breathe, and say >>> it doesn't (or may not) in another. >> >> >> You raise a good point, Now let me clarify, I don't believe (unless in >> utter error) that I've ever claimed that a URI definitively refers to "You", >> "Me", or "I". Of course, I cannot claim to have not made the careless >> utterances such as "Your Personal URI" , for instance. >> >> A URI that serves as a WebID has always been a denotation mechanism for a >> composite key comprised of: >> >> 1. private key >> 2. public key >> 3. URI that resolves to a profile document that describes a subject via an >> entity relationship graph. >> >> The subject of an X.509 certificate is a nebulous entity. This entity is >> associated with attribute and value pairs that comprise the profile graph >> imprinted in said certificate. The semantics of an X.509 certificate don't >> change the nature of the certificates subject. >> >>> >>> There is a use case which provides a technical requirement here, one >>> which is simply to not use identifiable information between requests to >>> different origin servers, and sometimes more granular, not using the same >>> identifiable information between requests to the same server. >>> >>> WebID, just like any auth protocol can be used, it just means using it on >>> a one time basis, or only for a particular origin. >> >> >> WebID is a part of the picture, not the picture in its entirety. I've >> pretty much tried to encourage others to be careful about conveying the >> misconception that WebID (solely) resolves the issues at hand. It is just a >> critical piece of the puzzle, that's it. >> >> You don't need to have a single WebID. Such a thing fails the most mundane >> alter ego test re. 'Clarke Kent' and 'Superman' or 'Peter Parker' and >> 'Spiderman'. >> >> Privacy is about the aforementioned personas not being comprised, under >> any circumstances. The fact that DC world entities 'Clark Kent' and >> 'Superman' used the same Web browser shouldn't comprise the alter ego >> relationship between these personas. >> >> Unlinkability is about the alter ego paradox. >> >>> >>> Personally I feel there are still questions here with WebID, as currently >>> people use usernames/emails and passwords almost everywhere, and they can >>> pick different usernames/emails/passwords on every site/origin. Suppose >>> WebID was to gain 100% adoption overnight, we'd suddenly be in a position >>> where everybody usually used the same identifier (rather than usernames and >>> email addresses) and the same key (rather than multiple passwords) - because >>> we've never been in a world like that, we don't know the consequences yet. >> >> >> See my comments above. Such a system is dead on arrival re. privacy. There >> have to be multiple WebIDs and the exploitation of logic when dealing with >> data access policies, and all of this has to occur within specific >> interaction contexts. For instance, if I want only you to see a document, I >> could knock up the require security tokens and send them to you via a >> PKCS#12 file. You open the file then go GET the document in question. Being >> super paranoid, I would more than likely speak to you via phone about the >> username and password combo for opening up the PKCS#12 file. >>> >>> >>> Thus, when security and identity experts suggest that we need to handle >>> unlinkability, or consider that we may often need per origin WebIDs (or even >>> have that as the default mode), then we may be wise to say "okay", go away >>> and find our options, then report them back for consideration and review. >>> >>> It by no means limits WebID, rather it just makes it applicable to a >>> broader range of use cases. >> >> >> We need others (note: expert is utterly subjective to me) interested in >> these matters to be constructive rather than dismissive. I chime in most of >> the time because I see Henry going to immense pains to explain matters only >> to be summarily dismissed in manners that I find cognitively dissonant. >> >> A basic RDBMS product doesn't depend on single attribute/field primary >> keys, why would such thinking even apply to the complex matter of privacy. >> When I use the term composite, I am pretty much referring the the same >> concept well understood in the RDBMS world. You can have a 'super key' >> comprised of elements that are of themselves unique identifiers. >> >> I don't believe in a single WebID neither does Henry. We just believe that >> Web-scale verifiable identity is a critical part of the required >> infrastructure. We also believe that a de-referencable URI (e.g., an HTTP >> URI) is a very powerful vehicle for this endeavor, even more so when >> combined with structured data and first-order logic. >> >> I only know of one way to deal with context fluidity at the software >> level, and that's via logic integrated into data which produces self >> describing data objects . > > > I agree on all counts and feel/think the same, So do I, more or less (except the last sentence, which I don't think I really understand, and if I do, seems too sweeping), which surprises me. > so I think I'll need to go > and re-read this thread and see where the confusion is. Possibly something to do with the fact that of all of Kingley's posts so far this is the only one I haven't found either incomprehensible or wrong. Where we came in was me pointing out that if you disconnect your identities by using multiple WebIDs, then you have a UI problem, and since then the aim seems to have been to persuade us that multiple WebIDs are not needed. > > Best, Nathan From nathan@webr3.org Mon Oct 22 03:01:51 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8AB21F8B6C for ; Mon, 22 Oct 2012 03:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.032 X-Spam-Level: X-Spam-Status: No, score=-4.032 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgHoMG4DPOcm for ; Mon, 22 Oct 2012 03:01:51 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id F05B721F851F for ; Mon, 22 Oct 2012 03:01:50 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so1850008wib.13 for ; Mon, 22 Oct 2012 03:01:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=fYEuZVHXI+xDxXhkubknbl9i1JGb04rkmg6T+81pZHE=; b=AdgEhhNl8kNtDZw08p8hAjT4wk8jIqHbTadRgj3Iw+oho+at5SV2t9QEeJ1bBbLb9g BRjr/E+KfuwOW+crkzfAyhgnObVw7fv5uTJ9ExRL8mevHBujs45+2Po0LvwPP7UPOt8D 5EvfSNrrMlL3n74K7yuAbyI7KEMTu2XcNXlMUMf0MVHG6XFD4jNPdsJkSJEtQfKUqs1b t/aDu/tPQG/cxoaNLwrO1FBr40HRAKfKaSOelOdC0Wi0Mj9GibtIcO0n7mqK4Ltp7ihQ IOyllWvtiU2yHtqH9Y7Kj4BYlzPFpsVXZdKrZUIl8FQWFyPCkk04A45c3KpUVhQqkBsP L+sw== Received: by 10.180.99.133 with SMTP id eq5mr35686173wib.21.1350900110172; Mon, 22 Oct 2012 03:01:50 -0700 (PDT) Received: from [192.168.1.69] (host86-141-252-78.range86-141.btcentralplus.com. [86.141.252.78]) by mx.google.com with ESMTPS id q7sm21105658wiy.11.2012.10.22.03.01.48 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Oct 2012 03:01:49 -0700 (PDT) Message-ID: <50851972.6030600@webr3.org> Date: Mon, 22 Oct 2012 11:01:22 +0100 From: Nathan Organization: webr3 User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Ben Laurie References: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <5083CCCF.2060407@webr3.org> <50842789.3080301@openlinksw.com> <50845268.4010509@webr3.org> <5084AC77.8030600@openlinksw.com> <50851512.9090803@webr3.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmgK/U0NXdO11FQSDJmFgWKbEgYpI1UzFhWjuQ+YYiR6Rh5iI/oZi8lCbXDCNoz+chR/OHc X-Mailman-Approved-At: Mon, 22 Oct 2012 08:25:26 -0700 Cc: "public-philoweb@w3.org" , "public-identity@w3.org" , "saag@ietf.org" , Melvin Carvalho , "public-privacy@w3.org" , Kingsley Idehen , Sam Hartman , "public-webid@w3.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: nathan@webr3.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 10:01:51 -0000 Ben Laurie wrote: > Where we came in was me pointing out that if you disconnect your > identities by using multiple WebIDs, then you have a UI problem, and > since then the aim seems to have been to persuade us that multiple > WebIDs are not needed. Yup, it appears to boil down to a UI problem, and more specifically, a browser-ui problem. Multiple WeIDs are often needed, and the WebID protocol doesn't preclude that in any way shape or form. On a positive note, it's great to talk through these things and make sure that peoples concerns are voiced and noted :) Best, Nathan From benl@google.com Mon Oct 22 04:26:44 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5045321F8B71 for ; Mon, 22 Oct 2012 04:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.969 X-Spam-Level: X-Spam-Status: No, score=-102.969 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrCipb-AoTsD for ; Mon, 22 Oct 2012 04:26:43 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD5121F8B70 for ; Mon, 22 Oct 2012 04:26:43 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so1932218wib.13 for ; Mon, 22 Oct 2012 04:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=skpeUiZiKnpvkrMSI8FzHTs4x5m2o/i/JX500CSkXbY=; b=m4U7exuZUzyrOD9yWHB25qFvjrX0sMn45QgLjtCXWFG1K2+qc39EiuVlcGB6ci3tuo Ijxg+UwoI3bq8YMA089IylU/S9m6Jf7LUMzY80C3Y9CsXxV+pZoYiRzUF4Tczfa69+kb Dgs2UnFNL7nVuZlcOyoHxIbaCp2yrlJ9Do60ZsSZc55jyhd63jMU/vjh2oPUTKBiDrhg YBF7rUAzhwOT+71dtnEmTtN2i0QmY5nKlj/4TM53tflHTO+oh+v8su7+0YDrjYT8WrHX iWLVcyR4NWgtXI+W3hnYiUtuV6FogxqyotolRpx42XNPOpl6WBMJLhexGdhLVr+Y1dPf c/dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=skpeUiZiKnpvkrMSI8FzHTs4x5m2o/i/JX500CSkXbY=; b=cVB8ly6oF1z8B3UHv7bu9FALRvBiJ5ircxcDbuDlfN7qGbxC1I8Jgevgqn3anwUQ42 /gWMadLkrn4g2sKaEGpRgRJOlm0B5l/ISiBgzebsX8BIa/R96oiJGhGGpdMdwcEMI5N1 netgwoA5zojRPf5vvzGgz2WqCpQ3/OPK3FLm4DJ9y3HMj6svo5NbMrwlalnY8AAGYcsK fYoCNIcKOiOBAOYXnxmoZzziC5IqYITDl0FWj1bYEZGp44LkFG9JPfdgTG+WL2sirlR0 MlBDQrYCGj3WA1fZ+Tw3e889yrcVdzambQrly3P3Ldbf12twLsnWCIgbK9hcpWQazQZ1 M/Rw== MIME-Version: 1.0 Received: by 10.216.193.220 with SMTP id k70mr5694521wen.35.1350905202073; Mon, 22 Oct 2012 04:26:42 -0700 (PDT) Received: by 10.194.76.170 with HTTP; Mon, 22 Oct 2012 04:26:41 -0700 (PDT) In-Reply-To: <50852726.9030102@openlinksw.com> References: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <5083CCCF.2060407@webr3.org> <50842789.3080301@openlinksw.com> <50845268.4010509@webr3.org> <5084AC77.8030600@openlinksw.com> <50851512.9090803@webr3.org> <50852726.9030102@openlinksw.com> Date: Mon, 22 Oct 2012 12:26:41 +0100 Message-ID: From: Ben Laurie To: Kingsley Idehen Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQm8loZqkn6OU5uECTeXLwrMEVLqinC8rcS/Pe60aOCXCAjeyboeY/SaK3sYF2Msa+HTZUfqpUYvPaGrqgi4b8GdMICD1fj3M2UU6qbKafKX6jjGoUfmhAGi1GA8XSSVQE0MUVAHmA3SCuNG6UD3vDxXNuTI0VPR2aRBOo4iqG17w4sIFxA4h9U9vAZy3wupBRfyfMKT X-Mailman-Approved-At: Mon, 22 Oct 2012 08:25:26 -0700 Cc: "public-philoweb@w3.org" , nathan@webr3.org, "public-identity@w3.org" , "saag@ietf.org" , Melvin Carvalho , "public-privacy@w3.org" , Sam Hartman , "public-webid@w3.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 11:26:44 -0000 On 22 October 2012 11:59, Kingsley Idehen wrote: > On 10/22/12 5:54 AM, Ben Laurie wrote: >> >> Where we came in was me pointing out that if you disconnect your >> identities by using multiple WebIDs, then you have a UI problem, and >> since then the aim seems to have been to persuade us that multiple >> WebIDs are not needed. > > Multiple WebIDs (or any other cryptographically verifiable identifier) are a > must. > > The issue of UI is inherently subjective. It can't be used to objectively > validate or invalidate Web-scale verifiable identifier systems such as > WebID or any other mechanism aimed at achieving the same goals. Ultimately what matters is: do users use it correctly? This can be tested :-) Note that it is necessary to test the cases where the website is evil, too - something that's often conveniently missed out of user testing. For example, its pretty obvious that OpenID fails horribly in this case, so it tends not to get tested. > > Anyway, Henry, I, and a few others from the WebID IG (hopefully) are going > to knock up some demonstrations to show how this perceived UI/UX > inconvenience can be addressed. Cool. > > > > -- > > Regards, > > Kingsley Idehen > Founder & CEO > OpenLink Software > Company Web: http://www.openlinksw.com > Personal Weblog: http://www.openlinksw.com/blog/~kidehen > Twitter/Identi.ca handle: @kidehen > Google+ Profile: https://plus.google.com/112399767740508618350/about > LinkedIn Profile: http://www.linkedin.com/in/kidehen > > > > > From hhalpin@w3.org Mon Oct 22 05:32:51 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F9F21F8B71 for ; Mon, 22 Oct 2012 05:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClS9gKlxhVxt for ; Mon, 22 Oct 2012 05:32:50 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1AB21F8B66 for ; Mon, 22 Oct 2012 05:32:50 -0700 (PDT) Received: from [199.254.238.196] (helo=[172.27.0.77]) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1TQHBV-0007gW-G6; Mon, 22 Oct 2012 08:32:46 -0400 Message-ID: <50853CD8.8020005@w3.org> Date: Mon, 22 Oct 2012 14:32:24 +0200 From: Harry Halpin User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Kingsley Idehen References: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <5083CCCF.2060407@webr3.org> <50842789.3080301@openlinksw.com> <50845268.4010509@webr3.org> <5084AC77.8030600@openlinksw.com> <50851512.9090803@webr3.org> <50852726.9030102@openlinksw.com> <5085360E.3080008@openlinksw.com> In-Reply-To: <5085360E.3080008@openlinksw.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 22 Oct 2012 08:25:26 -0700 Cc: "public-philoweb@w3.org" , nathan@webr3.org, "public-identity@w3.org" , Sam Hartman , "saag@ietf.org" , Melvin Carvalho , "public-privacy@w3.org" , "public-webid@w3.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 12:32:51 -0000 On 10/22/2012 02:03 PM, Kingsley Idehen wrote: > On 10/22/12 7:26 AM, Ben Laurie wrote: >> On 22 October 2012 11:59, Kingsley Idehen >> wrote: >>> On 10/22/12 5:54 AM, Ben Laurie wrote: >>>> Where we came in was me pointing out that if you disconnect your >>>> identities by using multiple WebIDs, then you have a UI problem, and >>>> since then the aim seems to have been to persuade us that multiple >>>> WebIDs are not needed. >>> Multiple WebIDs (or any other cryptographically verifiable >>> identifier) are a >>> must. >>> >>> The issue of UI is inherently subjective. It can't be used to >>> objectively >>> validate or invalidate Web-scale verifiable identifier systems such as >>> WebID or any other mechanism aimed at achieving the same goals. >> Ultimately what matters is: do users use it correctly? This can be >> tested :-) >> >> Note that it is necessary to test the cases where the website is evil, >> too - something that's often conveniently missed out of user testing. >> For example, its pretty obvious that OpenID fails horribly in this >> case, so it tends not to get tested. > > Okay. >> >>> Anyway, Henry, I, and a few others from the WebID IG (hopefully) >>> are going >>> to knock up some demonstrations to show how this perceived UI/UX >>> inconvenience can be addressed. >> Cool. > > Okay, ball is in our court to now present a few implementations that > address the UI/UX concerns. > > Quite relieved to have finally reached this point :-) No, its not a UI/UX concern, although the UI experience of both identity on the Web and with WebID in particular is quite terrible, I agree. My earlier concern was an information flow concern that causes the issue with linkability, which WebID shares to a large extent with other server-side information-flow. As stated earlier, as long as you trust the browser, BrowserID does ameliorate this. There is also this rather odd conflation of "linkability" of URIs with hypertext and URI-enabled Semantic Web data" and linkability as a privacy concern. I do think many people agree stronger cryptographic credentials for authentication are a good thing, and BrowserID is based on this and OpenID Connect has (albeit not often used) options in this space. I would again, please suggest that the WebID community take on board comments in a polite manner and not cc mailing lists. > > > From melvincarvalho@gmail.com Mon Oct 22 05:47:00 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8137821F889F for ; Mon, 22 Oct 2012 05:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.286 X-Spam-Level: X-Spam-Status: No, score=-3.286 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cp9qiCnkvl8A for ; Mon, 22 Oct 2012 05:46:59 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 70D2F21F85E2 for ; Mon, 22 Oct 2012 05:46:59 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so4185103iec.31 for ; Mon, 22 Oct 2012 05:46:59 -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=F0PLgs3JbKDUKZTH5kTV6vjQIaCGPOF2Joy7KyfYDwI=; b=KsBhiNU3cc2Ckr9m/yDhfjdQvd+S2ee2JSyGagy0DRSVgKblsoNBmHxWHIyHYU7mRu 1pygLvFst8NTlXjL990ESB8lxMsdEw5hc0zOSqLvy67qU5Bqr4I0kqQ+V+gJV9LBc+pi z5FSUhdPN58UvJ8WCN5NQlZwfShCi0ZzbiQvAvhkm6nHkuPa8TkQpX/G7D1y+I2Cej9N Oq4Sp0r0PvJ+kjZgHKJdKvqbKzQEp3dWR3lKdWV5byZ8h0JAzyUYlrH9k41AdFl59T4D wU1QGPCduFZL6RKA7TG3BJMEdcH854jvZaMRkooITuRwwJ0E0PndxOUCubdOm2kFqOlm dEQQ== MIME-Version: 1.0 Received: by 10.50.190.234 with SMTP id gt10mr8908832igc.20.1350910018953; Mon, 22 Oct 2012 05:46:58 -0700 (PDT) Received: by 10.42.247.129 with HTTP; Mon, 22 Oct 2012 05:46:58 -0700 (PDT) In-Reply-To: <50853CD8.8020005@w3.org> References: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <5083CCCF.2060407@webr3.org> <50842789.3080301@openlinksw.com> <50845268.4010509@webr3.org> <5084AC77.8030600@openlinksw.com> <50851512.9090803@webr3.org> <50852726.9030102@openlinksw.com> <5085360E.3080008@openlinksw.com> <50853CD8.8020005@w3.org> Date: Mon, 22 Oct 2012 14:46:58 +0200 Message-ID: From: Melvin Carvalho To: Harry Halpin Content-Type: multipart/alternative; boundary=14dae93408ddcda15504cca53fe7 X-Mailman-Approved-At: Mon, 22 Oct 2012 08:25:26 -0700 Cc: "public-philoweb@w3.org" , nathan@webr3.org, "public-identity@w3.org" , Sam Hartman , "saag@ietf.org" , "public-privacy@w3.org" , Kingsley Idehen , "public-webid@w3.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 12:47:00 -0000 --14dae93408ddcda15504cca53fe7 Content-Type: text/plain; charset=ISO-8859-1 On 22 October 2012 14:32, Harry Halpin wrote: > On 10/22/2012 02:03 PM, Kingsley Idehen wrote: > >> On 10/22/12 7:26 AM, Ben Laurie wrote: >> >>> On 22 October 2012 11:59, Kingsley Idehen >>> wrote: >>> >>>> On 10/22/12 5:54 AM, Ben Laurie wrote: >>>> >>>>> Where we came in was me pointing out that if you disconnect your >>>>> identities by using multiple WebIDs, then you have a UI problem, and >>>>> since then the aim seems to have been to persuade us that multiple >>>>> WebIDs are not needed. >>>>> >>>> Multiple WebIDs (or any other cryptographically verifiable identifier) >>>> are a >>>> must. >>>> >>>> The issue of UI is inherently subjective. It can't be used to >>>> objectively >>>> validate or invalidate Web-scale verifiable identifier systems such as >>>> WebID or any other mechanism aimed at achieving the same goals. >>>> >>> Ultimately what matters is: do users use it correctly? This can be >>> tested :-) >>> >>> Note that it is necessary to test the cases where the website is evil, >>> too - something that's often conveniently missed out of user testing. >>> For example, its pretty obvious that OpenID fails horribly in this >>> case, so it tends not to get tested. >>> >> >> Okay. >> >>> >>> Anyway, Henry, I, and a few others from the WebID IG (hopefully) are >>>> going >>>> to knock up some demonstrations to show how this perceived UI/UX >>>> inconvenience can be addressed. >>>> >>> Cool. >>> >> >> Okay, ball is in our court to now present a few implementations that >> address the UI/UX concerns. >> >> Quite relieved to have finally reached this point :-) >> > > No, its not a UI/UX concern, although the UI experience of both identity > on the Web and with WebID in particular is quite terrible, I agree. > Harry, what exactly do you mean by "on the web"? The reference point I take for this phrase is from the "Axioms of Web Architecture" : http://www.w3.org/DesignIssues/Axioms.html#uri 'An information object is "on the web" if it has a URI.' If I have understood your previous posts correctly you perhaps have a different definition or referring to something specific. Sorry if im a bit confused things, It's not that clear hat you mean by the phrase. > My earlier concern was an information flow concern that causes the issue > with linkability, which WebID shares to a large extent with other > server-side information-flow. As stated earlier, as long as you trust the > browser, BrowserID does ameliorate this. There is also this rather odd > conflation of "linkability" of URIs with hypertext and URI-enabled Semantic > Web data" and linkability as a privacy concern. > > I do think many people agree stronger cryptographic credentials for > authentication are a good thing, and BrowserID is based on this and OpenID > Connect has (albeit not often used) options in this space. I would again, > please suggest that the WebID community take on board comments in a polite > manner and not cc mailing lists. > Feedback is valuable and appreciated. Certainly the comments made are taken on board. With standards such as identity there's always an overlap between different efforts. I cant speak for others in the community, but I personally agree that care should be taken to post the right topics to the right list. --14dae93408ddcda15504cca53fe7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 22 October 2012 14:32, Harry Halpin <= span dir=3D"ltr"><hh= alpin@w3.org> wrote:
On 10/22/2012 02:03 PM, Kingsley Id= ehen wrote:
On 10/22/12 7:26 AM, Ben Laurie wrote:
On 22 October 2012 11:59, Kingsley Idehen <kidehen@openlinksw.com> wrote:
On 10/22/12 5:54 AM, Ben Laurie wrote:
Where we came in was me pointing out that if you disconnect your
identities by using multiple WebIDs, then you have a UI problem, and
since then the aim seems to have been to persuade us that multiple
WebIDs are not needed.
Multiple WebIDs (or any other cryptographically verifiable identifier) are = a
must.

The issue of UI is inherently subjective. It can't be used to objective= ly
validate or invalidate Web-scale verifiable identifier systems such as
WebID or any other mechanism aimed at achieving the same goals.
Ultimately what matters is: do users use it correctly? This can be tested := -)

Note that it is necessary to test the cases where the website is evil,
too - something that's often conveniently missed out of user testing. For example, its pretty obvious that OpenID fails horribly in this
case, so it tends not to get tested.

Okay.

Anyway, Henry, I, =A0and a few others from the WebID IG (hopefully) are goi= ng
to knock up some demonstrations to show how this perceived UI/UX
inconvenience can be addressed.
Cool.

Okay, ball is in our court to now present a few implementations that addres= s the UI/UX concerns.

Quite relieved to have finally reached this point :-)

No, its not a UI/UX concern, although the UI experience of both identity on= the Web and with WebID in particular is quite terrible, I agree.

Harry, what exactly do you mean by "on the web"?= =A0

The reference point I take for this phrase is from the "Axioms of = Web Architecture" :

http://www.w3.org/DesignIssues/Axioms.html#uri

'An information object is "on the web" if it has a URI.'<= br>=A0
If I have understood your previous posts correctly you perhaps ha= ve a different definition or referring to something specific.=A0 Sorry if i= m a bit confused things, It's not that clear hat you mean by the phrase= .


My earlier concern was an information flow concern that causes the issue wi= th linkability, which WebID shares to a large extent with other server-side= information-flow. As stated earlier, as long as you trust the browser, Bro= wserID does ameliorate this. There is also this rather odd conflation of &q= uot;linkability" of URIs with hypertext and URI-enabled Semantic Web d= ata" and linkability as a privacy concern.

I do think many people agree stronger cryptographic credentials for authent= ication are a good thing, and BrowserID is based on this and OpenID Connect= has (albeit not often used) options in this space. =A0I would again, pleas= e suggest that the WebID community take on board comments in a polite manne= r and not cc mailing lists.

Feedback is valuable and appreciated.=A0 Certainly th= e comments made are taken on board.

With standards such as identity = there's always an overlap between different efforts.=A0 I cant speak fo= r others in the community, but I personally agree that care should be taken= to post the right topics to the right list.
=A0

--14dae93408ddcda15504cca53fe7-- From tho@koanlogic.com Mon Oct 22 09:02:10 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A601C21F8C58 for ; Mon, 22 Oct 2012 09:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlDBCxal8b8P for ; Mon, 22 Oct 2012 09:02:09 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3956121F8C46 for ; Mon, 22 Oct 2012 09:02:09 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id s14so1902921qcg.31 for ; Mon, 22 Oct 2012 09:02:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=IV2qZX4Bs6uRXbRICVR2u+GXzJzd1A9ZQ73baafR13M=; b=HjfTV/BnKcRI593RrHsbtcpXTaLcCPnkTPcOGfDvg9wREfCYA3QbBFmKJ0y077EipC X1z6NqPP7gRycfYn7pz92kv22PcabzBLYQKlnWEbUnzZ53j7nCZAqtrx9Zd1LIdiTQ5e StBSp7jnCgF0Rp2Cpd88Ac22fPJGCcP+WMdnLQckADfaIti1AEZKhOplmebqAg9YLxns yJ1gzrhkEv/KHforg7rXDWTwaBGbXnEfsl/ml6ee7rb6IbqDs0ZLv12DkgFFnUY2ETUj LPSqrxEzSO3wRlsOyJThjw3XiDKoa2Xkhqan1ttHJgZ2frfKAAnu4HPbAgug8oW8FuKr 52YQ== MIME-Version: 1.0 Received: by 10.224.194.193 with SMTP id dz1mr4378443qab.0.1350921724977; Mon, 22 Oct 2012 09:02:04 -0700 (PDT) Received: by 10.49.26.170 with HTTP; Mon, 22 Oct 2012 09:02:04 -0700 (PDT) X-Originating-IP: [81.134.152.4] In-Reply-To: <20121018174113.GA11965@1wt.eu> References: <20121018064805.GI7517@1wt.eu> <20121018171129.GO9392@1wt.eu> <20121018174113.GA11965@1wt.eu> Date: Mon, 22 Oct 2012 17:02:04 +0100 Message-ID: From: Thomas Fossati To: Willy Tarreau Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnCpL6pck1oHq2+bq73/u5YLKn50CFtJjfscXWCdPsxa5tqflH6UPzUrPmM/Tnah9XskXks Cc: Barry Leiba , saag@ietf.org Subject: Re: [saag] Input for conflict review of draft-secure-cookie-session-protocol X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 16:02:11 -0000 Hi Willy, On Thu, Oct 18, 2012 at 6:41 PM, Willy Tarreau wrote: > Basically if used as general purpose cookies, the impossibility to ensure > non-replay would be a no-go for me as it goes against the principles of > RFC6265, hence #3. I beg to disagree. 6265 states: "Servers SHOULD encrypt and sign the contents of cookies (using whatever format the server desires) when transmitting them to the user agent (even when sending the cookies over a secure channel)." which is the very essence of what SCS does (adding a timestamp too). No imposition is made by SCS on storing the whole application state in the cookie, it is just left as a possibility, which comes in handy in some specific scenarios -- e.g. the home router that can reboot without asking the admin to re-authenticate. In fact, if the server wants, it can use the DATA atom to just store a session id which points to state archived server side, and use SCS to just "encrypt and sign the contents of cookies" From benlaurie@gmail.com Mon Oct 22 09:58:40 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFCE821F8B60 for ; Mon, 22 Oct 2012 09:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.852 X-Spam-Level: X-Spam-Status: No, score=-2.852 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfywRT6lGt06 for ; Mon, 22 Oct 2012 09:58:37 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8360F21F8A10 for ; Mon, 22 Oct 2012 09:58:37 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3518400vcb.31 for ; Mon, 22 Oct 2012 09:58:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=3RP+d92azWNYu3fB6b+TpL1yTcR/KZCQleJbXDA8ACc=; b=c71EmcmUT62OVgy4sMZl2sC7gFv92yDu6b7XBzrS3Qf958svfOi4F/u3FqWWFXfzFV pIlzJ2kdx3eSgVGMrCSpUxhczX/SED+ixLRd3O244QjuCE5fp3wZisekcdtDMT0mrz9+ u9bYmtliT0yNgef8ueLC1DV7fRblg1MfD0cJs0Vr9CZQ7jnYpRzhdMP0sREKlJzNjBwJ zVKUHBNkLxHQOpPk6UK4hujTslEP8KymnRh2u8GEeU5nb3aECr6Rzq123qaStT+Rc/LX UpOItqYUSplIShpcIwpeisxsCsMB8t7p34Skcho5nsD0KnBeuUYqVs+J6wKuYTTgtWgh 1iBQ== MIME-Version: 1.0 Received: by 10.58.116.175 with SMTP id jx15mr17122830veb.6.1350925113638; Mon, 22 Oct 2012 09:58:33 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.58.18.235 with HTTP; Mon, 22 Oct 2012 09:58:33 -0700 (PDT) In-Reply-To: <50805611.2000904@kent.ac.uk> References: <88F98DFD-EF7D-4444-A9C2-FB8E15F5DA89@bblfish.net> <3757D928-C3AE-4630-98E7-E30B5CC604B0@cisco.com> <7E1636E02F313F4BA69A428B314B77C708217189@xmb-aln-x12.cisco.com> <7ABCD095-4B09-40DD-A084-1BBE761CA72F@bblfish.net> <50805611.2000904@kent.ac.uk> Date: Mon, 22 Oct 2012 17:58:33 +0100 X-Google-Sender-Auth: wF72rQGNFY_5LwWAPTbg_u52xDo Message-ID: From: Ben Laurie To: David Chadwick Content-Type: text/plain; charset=ISO-8859-1 Cc: "public-philoweb@w3.org" , "public-identity@w3.org" , "saag@ietf.org" , "public-privacy@w3.org" , "Klaas Wierenga \(kwiereng\)" , "public-webid@w3.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 16:58:40 -0000 On Thu, Oct 18, 2012 at 8:18 PM, David Chadwick wrote: > Hi Ben > > I disagree. It depends upon your risk assessment. Your stand is like saying > TLS should be the substrate, not http. Not at all. You can add security to an insecure connection. You cannot add anonymity to an identified session. My stand is, in fact, like saying that TCP should be the substrate, not TLS. > There are two alternative viewpoints. > You can either start with the lowest security/privacy and add to it, or make > the highest security/privacy the default and then take from it. So you > should not necessarily mandate that U-Prove/Idemix are the default tokens, > but rather only require them if your risk assessment says privacy protection > is essential > > regards > > David > > > On 18/10/2012 16:34, Ben Laurie wrote: >> >> On 9 October 2012 14:19, Henry Story wrote: >>> >>> Still in my conversations I have found that many people in security >>> spaces >>> just don't seem to be able to put the issues in context, and can get >>> sidetracked >>> into not wanting any linkability at all. Not sure how to fix that. >> >> >> You persist in missing the point, which is why you can't fix it. The >> point is that we want unlinkability to be possible. Protocols that do >> not permit it or make it difficult are problematic. I have certainly >> never said that you should always be unlinked, that would be stupid >> (in fact, I once wrote a paper about how unpleasant it would be). >> >> As I once wrote, anonymity should be the substrate. Once you have >> that, you can the build on it to be linked when you choose to be, and >> not linked when you choose not to be. If it is not the substrate, then >> you do not have this choice. >> > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From tho@koanlogic.com Mon Oct 22 10:44:57 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B2011E80A2 for ; Mon, 22 Oct 2012 10:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pA0t1UIvlF-9 for ; Mon, 22 Oct 2012 10:44:54 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id AC7FE11E80A5 for ; Mon, 22 Oct 2012 10:44:53 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id 25so1421124qao.10 for ; Mon, 22 Oct 2012 10:44:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=S7/Zx4SIyrMNd06uCaBIJife9uzf0YeIdpi34ecCiMw=; b=XmKcnZ9a/Slts1KZiPLGezPm8n6+2gXwK1E4gRHF0m2ziPNTy2uABfmg21jRJsl7rc Hj9eeoiVyTq8LKiNBnjqXRUs4Cj7H+tHEXtCWiMU9HkvHOilw3dBjj4A7ZyAphOzH+va CeqUqDS4sHUQ4+2mrHVAdvuv2jNIJ+q+xhcrOMUg4YSdQ18cyzG4oPg4a65r/pZkfwih 2aP5lfojLa57AByLvYjEAOMUL2iEcr51444qUolQdEZOEarnt+Mj25w/er3G8lZfcaTQ hMk/YUFcrf8lAD6Nqe1eV0pdPWGbLqzljHD3cKGSTEnWlDvls327IeJa097MTF3hZQpr V50g== MIME-Version: 1.0 Received: by 10.224.194.193 with SMTP id dz1mr4520375qab.0.1350927893051; Mon, 22 Oct 2012 10:44:53 -0700 (PDT) Received: by 10.49.26.170 with HTTP; Mon, 22 Oct 2012 10:44:52 -0700 (PDT) X-Originating-IP: [81.134.152.4] In-Reply-To: <50826EDE.6000509@gondrom.org> References: <50826EDE.6000509@gondrom.org> Date: Mon, 22 Oct 2012 18:44:52 +0100 Message-ID: From: Thomas Fossati To: Tobias Gondrom Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn74bpfxMKhOAznTcFr4niJmkS/M5glJvO48ozwEn4rNk/Zh+jIO8XR5/63HaqryR9Vnq0n Cc: saag@ietf.org Subject: Re: [saag] Input for conflict review of draft-secure-cookie-session-protocol X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 17:44:58 -0000 Hi Tobias, On Sat, Oct 20, 2012 at 10:29 AM, Tobias Gondrom wrote: > Just as an example: already the very first sentence in the introduction some > assumptions are half-true/half-false (like e.g. that cookies would be "... > un-authenticated and sent in clear text." In many applications (though not > all of them) cookies are in fact transmitted over HTTPS and in an > authenticated session and not in clear-text...) right, I will rephrase this to avoid the half wrong side of the statement :-) > A number of questions with this drafts make me suggest that IETF review is a > good thing (including the question whether IETF wants to do this at all): > - is the underlying use case valid for the draft? I am not sure of that. I don't get exactly what you mean here: is it whether the use case for SCS actually exists ? > - the text of the draft would hint towards status as Experimental, not as > Informational? Why Informational? > - Is there the vision of interoperability between different implementations > for this? In case there are multiple servers (e.g. a set of proxies that have to decide if the cached video can be served to the requesting UA), and they are from multiple vendors, yes. > Please note, that I don't deny at all, that there is a security > considerations section - and in the case of this draft, I actually like that > it is quite detailed on security implications compared to some other drafts > I've reviewed in the past years, but I would question whether in fact > suggesting to store server state only in a client is a good idea at all, as > it opens quite a number of security problems. I'm not unaware of that, and I'm not suggesting to use SCS everywhere on every occasion, ignoring the inherent risks. As I've already said to Willy in a private exchange, I think your concerns could be solved by adding the text that you think is currently missing in the Security Consideration. And, much likely, adjusting the Introduction too. That would make it a better (and safer) document. I share the vision that, say, online banking is not the right use case for "pure" SCS (i.e. without a bit of state on server but the crypto keys), but we can't pretend that online banking is the only playground for cookies/ authorisation tokens in the web. Likewise, I don't pretend the HTTP interface to a diskless home router is the most important application on the face of earth :-) Yet, someone in the digital content distribution market would tell you that SCS/SCS-like mechanisms are in massive use today, on STBs and other kind of non-browser UAs... > All this leads me to the recommendation to apply IETF review for this draft > to avoid trouble. > > However, this is only IMHO, for you, saag and the ADs to consider. And I > have the highest regard for Jim and our other reviewers. So consider this > just as my 5cents and I will hand over to others on saag (including Jim) to > comment and decide on whether we should give this more IETF review or not... Thank you very much for taking the time to argument your point. Discussion is vital. Yet, I'm quite surprised that a simple silly thing like SCS has raised such a level of reactions. As Stephen gently suggested, I've probably made a bad marketing choice in picking the name. Avoiding the use of the cookie+secure combo in the title (a gross oxymoron now that you make me think about it) would have probably made my life easier :-) From Jeff.Hodges@KingsMountain.com Mon Oct 22 10:48:03 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04BAD11E80E8 for ; Mon, 22 Oct 2012 10:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.442 X-Spam-Level: X-Spam-Status: No, score=-101.442 tagged_above=-999 required=5 tests=[AWL=1.157, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uam77CSQPseb for ; Mon, 22 Oct 2012 10:48:02 -0700 (PDT) Received: from oproxy11-pub.bluehost.com (oproxy11-pub.bluehost.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 0E4FB11E80A4 for ; Mon, 22 Oct 2012 10:48:01 -0700 (PDT) Received: (qmail 12769 invoked by uid 0); 22 Oct 2012 17:47:38 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy11.bluehost.com with SMTP; 22 Oct 2012 17:47:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=Plg3HgzOBPvVmJojIP3j+1taeSX9Y3djfU0FenjdYqg=; b=W6x3gT+udPUNzVG1MbvXLX2WDjrgVcw7mqgPyK3hzAe0oTjv5tiY/DK5tsHvv8tYurCFEahm/FDEo5IgdlTcxP+BAwS/YuCzst6nb5fHUkeHsMopuuz4hhE7pBvku1XA; Received: from [216.113.168.128] (port=7599 helo=[10.244.137.141]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TQM6D-0003EM-0l; Mon, 22 Oct 2012 11:47:37 -0600 Message-ID: <508586B8.5030302@KingsMountain.com> Date: Mon, 22 Oct 2012 10:47:36 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: IETF Security Area Advisory Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Cc: draft-secure-cookie-session-protocol@tools.ietf.org, Nevil Brownlee Subject: Re: [saag] Input for conflict review of draft-secure-cookie-session-protocol X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 17:48:03 -0000 stephen.farrell@cs.tcd.ie suggested.. > > If it were called "KoanLogic's Secure cookie Sessions > for HTTP" would that then be ok? IMO, it ought. That way, > the independent-stream RFC won't confuse anyone into > thinking that the IETF as a whole has developed this, but > if some IETF WG wants to do similar work, this could be > useful input. (And adding one word seems likely quicker > than organising and coming to IETF rough consensus;-) > > What do folks (incl. authors) think of that? > +1 this has been done with e.g. various of Microsoft's work... 5385 Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs. J. Touch. February 2010. (Format: TXT=38421 bytes) (Obsoletes RFC3285) (Status: INFORMATIONAL) 4757 The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows. K. Jaganathan, L. Zhu, J. Brezak. December 2006. (Format: TXT=36562 bytes) (Updated by RFC6649) (Status: INFORMATIONAL) 4559 SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows. K. Jaganathan, L. Zhu, J. Brezak. June 2006. (Format: TXT=16088 bytes) (Status: INFORMATIONAL) etc. HTH, =JeffH From tobias.gondrom@gondrom.org Mon Oct 22 11:10:39 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E2821F8B46 for ; Mon, 22 Oct 2012 11:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.762 X-Spam-Level: X-Spam-Status: No, score=-94.762 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, J_CHICKENPOX_66=0.6, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4n7S+t-Coxta for ; Mon, 22 Oct 2012 11:10:32 -0700 (PDT) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id EF6C821F8B3D for ; Mon, 22 Oct 2012 11:10:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=nm2kgmlK1NvOyg8Y4wqgkDnFcVkUoGPbSD53yGhJ8rPyd8+PmrDNUPqdOKbPKFzEZSDXWrfzca1GH9x62e7wuJfOIUsDTwN2OftioDTktzMIqlBXCkFgOpLOj5BQuMek; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 3162 invoked from network); 22 Oct 2012 20:10:30 +0200 Received: from unknown (HELO ?10.71.45.180?) (12.201.145.130) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 22 Oct 2012 20:10:30 +0200 Message-ID: <50858C14.1070809@gondrom.org> Date: Mon, 22 Oct 2012 13:10:28 -0500 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: tho@koanlogic.com References: <50826EDE.6000509@gondrom.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: saag@ietf.org Subject: Re: [saag] Input for conflict review of draft-secure-cookie-session-protocol X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 18:10:39 -0000 Hi Thomas, On 22/10/12 12:44, Thomas Fossati wrote: > Hi Tobias, > > On Sat, Oct 20, 2012 at 10:29 AM, Tobias Gondrom > wrote: >> Just as an example: already the very first sentence in the introduction some >> assumptions are half-true/half-false (like e.g. that cookies would be "... >> un-authenticated and sent in clear text." In many applications (though not >> all of them) cookies are in fact transmitted over HTTPS and in an >> authenticated session and not in clear-text...) > right, I will rephrase this to avoid the half wrong side of the statement :-) Yes, changing the intro would help as this frames the way people see what this should be used for. And the intended status is also worth discussion. > >> A number of questions with this drafts make me suggest that IETF review is a >> good thing (including the question whether IETF wants to do this at all): >> - is the underlying use case valid for the draft? I am not sure of that. > I don't get exactly what you mean here: is it whether the use case for > SCS actually exists ? Yes. >> - the text of the draft would hint towards status as Experimental, not as >> Informational? Why Informational? >> - Is there the vision of interoperability between different implementations >> for this? > In case there are multiple servers (e.g. a set of proxies that have to > decide if the cached video can be served to the requesting UA), and > they are from multiple vendors, yes. That might be a use case to explore as justification for the draft. As interoperability of different implementations would be a reason to write this down. (otherwise people could equally do proprietary implementations...) >> Please note, that I don't deny at all, that there is a security >> considerations section - and in the case of this draft, I actually like that >> it is quite detailed on security implications compared to some other drafts >> I've reviewed in the past years, but I would question whether in fact >> suggesting to store server state only in a client is a good idea at all, as >> it opens quite a number of security problems. > I'm not unaware of that, and I'm not suggesting to use SCS everywhere > on every occasion, ignoring the inherent risks. As I've already said > to Willy in a private exchange, I think your concerns could be solved > by adding the text that you think is currently missing in the Security > Consideration. And, much likely, adjusting the Introduction too. > That would make it a better (and safer) document. Yes. > > I share the vision that, say, online banking is not the right use case > for "pure" SCS (i.e. without a bit of state on server but the crypto > keys), but we can't pretend that online banking is the only playground > for cookies/ authorisation tokens in the web. Likewise, I don't > pretend the HTTP interface to a diskless home router is the most > important application on the face of earth :-) Yet, someone in the > digital content distribution market would tell you that SCS/SCS-like > mechanisms are in massive use today, on STBs and other kind of > non-browser UAs... Ok. These use cases might be worth referencing/adding in the appendix, and framing what SCS is intended for. > >> All this leads me to the recommendation to apply IETF review for this draft >> to avoid trouble. >> >> However, this is only IMHO, for you, saag and the ADs to consider. And I >> have the highest regard for Jim and our other reviewers. So consider this >> just as my 5cents and I will hand over to others on saag (including Jim) to >> comment and decide on whether we should give this more IETF review or not... > Thank you very much for taking the time to argument your point. > Discussion is vital. Yet, I'm quite surprised that a simple silly > thing like SCS has raised such a level of reactions. As Stephen > gently suggested, I've probably made a bad marketing choice in picking > the name. Avoiding the use of the cookie+secure combo in the title (a > gross oxymoron now that you make me think about it) would have > probably made my life easier :-) Actually I don't think the draft is "silly" nor a bad "marketing" choice. And I think the title reflects correctly what's in the tin. So the title is accurate. Maybe to explain one further bit, why this rang some bells (alarm bells that is): In any server implementation, I always advise that people must never trust content from the client. And that at the least you must verify all client input for range, type etc. And in a good implementation the server shall store the state and only allow the client to link to that state by reference. Client data is outside of the control of the server and can be lost, corrupted, manipulated on the way or even intentionally malformed by an authorised client/UA to screw things up. This can lead to data leakage, corruption of server data, or in simple cases also to fostering DoS by CPU costs on the server due to de-/encryption algorithm CPU times. So a server must never trust client data or client state (and IMHO use client-side state data as little as possible). And SCS is basically going against this underlying security paradigm, which is giving me some worries. I understand that SCS could mitigate some of the risks above, but I have some concerns that SCS might open up a whole can of worms when we go down the path of client-side state - and that if something breaks with SCS, it may break in a very bad way... Tobias From henry.story@bblfish.net Mon Oct 22 12:36:31 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C27F821F87E0 for ; Mon, 22 Oct 2012 12:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=-1.028, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vcc-4X6b6WT for ; Mon, 22 Oct 2012 12:36:30 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 12FF321F85C1 for ; Mon, 22 Oct 2012 12:36:29 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so1319717eek.31 for ; Mon, 22 Oct 2012 12:36:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=b52waygc/gEWJ9oSQrC40RPZXM2yu9U+fP8eO/Q7u54=; b=J+wbTgGqhZf5TiJ6xP3uOT+PgTAZ35+77Rba6X1E8fqIeBpkscC64xFPSWbcb0mumt iQsjzXxy2wzTeZecLyxgK7WmCxdUMOtOgDXTKYxIbmTI3teuxRpuOa+bHC6/j0A93+X3 yOkudWzRti1wgrf5SDlckfwTKB4J4puBd4ypjHTOQhpkN5yOO5Vy9rHt9wSPhnYU1zSY ecUq4B7oXRy1RBLHCFE3Ra3Q1J7y9FJr+utIBRGFcw7W2h77wquE12veEnY1fnAsE8TF CamL27E8h8baNhfXTtOlGLmwkKVXSCjktLJhJc8EQ0lb1DlLrFtnTxEvy7t/oEeQFDRG Rtgw== Received: by 10.14.221.8 with SMTP id q8mr13626365eep.28.1350934588562; Mon, 22 Oct 2012 12:36:28 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-132-122.w86-198.abo.wanadoo.fr. [86.198.99.122]) by mx.google.com with ESMTPS id k2sm17551592eep.15.2012.10.22.12.36.17 (version=SSLv3 cipher=OTHER); Mon, 22 Oct 2012 12:36:18 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_8E4C4C2E-A1D8-4A9E-A98B-DA3252B6570B"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Henry Story In-Reply-To: <508562C2.1060905@w3.org> Date: Mon, 22 Oct 2012 21:36:14 +0200 Message-Id: References: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <5083CCCF.2060407@webr3.org> <50842789.3080301@openlinksw.com> <50845268.4010509@webr3.org> <5084AC77.8030600@openlinksw.com> <50851512.9090803@webr3.org> <50852726.9030102@openlinksw.com> <5085360E.3080008@openlinksw.com> <50853CD8.8020005@w3.org> <5FB468E4-BDD3-4635-ACD0-A23540C08751@bblfish.net> <508562C2.1060905@w3.org> To: Halpin Harry X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQm836tswgncGXyqLdTGotTbee9IznPZA76tkxUWeEHM/ERKjUZuq0R1T7GGnUsMVOtay55m Cc: public-identity@w3.org, saag@ietf.org, public-webid@w3.org, "public-privacy@w3.org list" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 19:36:31 -0000 --Apple-Mail=_8E4C4C2E-A1D8-4A9E-A98B-DA3252B6570B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 22 Oct 2012, at 17:14, Harry Halpin wrote: > On 10/22/2012 04:04 PM, Henry Story wrote: >> On 22 Oct 2012, at 14:32, Harry Halpin wrote: >>=20 >>> On 10/22/2012 02:03 PM, Kingsley Idehen wrote: >>>> On 10/22/12 7:26 AM, Ben Laurie wrote: >>>>> On 22 October 2012 11:59, Kingsley Idehen = wrote: >>>>>> On 10/22/12 5:54 AM, Ben Laurie wrote: >>>>>>> Where we came in was me pointing out that if you disconnect your >>>>>>> identities by using multiple WebIDs, then you have a UI problem, = and >>>>>>> since then the aim seems to have been to persuade us that = multiple >>>>>>> WebIDs are not needed. >>>>>> Multiple WebIDs (or any other cryptographically verifiable = identifier) are a >>>>>> must. >>>>>>=20 >>>>>> The issue of UI is inherently subjective. It can't be used to = objectively >>>>>> validate or invalidate Web-scale verifiable identifier systems = such as >>>>>> WebID or any other mechanism aimed at achieving the same goals. >>>>> Ultimately what matters is: do users use it correctly? This can be = tested :-) >>>>>=20 >>>>> Note that it is necessary to test the cases where the website is = evil, >>>>> too - something that's often conveniently missed out of user = testing. >>>>> For example, its pretty obvious that OpenID fails horribly in this >>>>> case, so it tends not to get tested. >>>> Okay. >>>>>> Anyway, Henry, I, and a few others from the WebID IG (hopefully) = are going >>>>>> to knock up some demonstrations to show how this perceived UI/UX >>>>>> inconvenience can be addressed. >>>>> Cool. >>>> Okay, ball is in our court to now present a few implementations = that address the UI/UX concerns. >>>>=20 >>>> Quite relieved to have finally reached this point :-) >>> No, its not a UI/UX concern, although the UI experience of both = identity on the Web and with WebID in particular is quite terrible, I = agree. >> It completely depends on the browsers: >> http://www.w3.org/wiki/Foaf%2Bssl/Clients/CertSelection >> If you are on Linux just file a bug request to your browser if you = are unhappy, or even better hack up a good UI. It's easy: just make it = simpler. >>=20 >>> My earlier concern was an information flow concern that causes the = issue with linkability, which WebID shares to a large extent with other = server-side information-flow. >> Including BrowserId. Which has 2 tokens that can be used to identify = the user across sites: >>=20 >> - an e-mail address ( useful for spamming ) >> - a public key, which can be used to authenticate across sites >>=20 >>=20 >>> As stated earlier, as long as you trust the browser, BrowserID does = ameliorate this. >> No it does not improve linkability at all. Certainly not if you think = the site you are authenticating to is the one you should be worried = about, because just using a public key >> by itself is enough for Linkability in the strict (paranoid) sense. = That is if you >> consider the site you are logging into to as the attacker, then by = giving two sites >> a public key where you have proven you control the private key is = enough for them to know that >> the same agent visited both sites. That is because the cert:key = relation is inverse functional. >>=20 >> So in simple logical terms if you go to site1.org and identify with a = public key pk, >> and they create a local identifier for you , = and then you go site s2.net and identify with the same public key pk = and they give you an identifier >> (these need not be public) and then they exchange their information, = then each of the sites would have the following relations ( written in = http://www.w3.org/TR/Turtle ) >>=20 >> @prefix cert: >>=20 >> cert:key pk . >> cert:key pk . >>=20 >> because cert:key is defined as an InverseFunctionalProperty >> ( as you can see by going http://www.w3.org/ns/auth/cert#key ) >>=20 >> Then it follows from simple owl reasoning that >>=20 >> =3D=3D . >>=20 >> One cannot get much simpler logical reasoning that this, Harry. >>=20 >>=20 >>> There is also this rather odd conflation of "linkability" of URIs = with hypertext and URI-enabled Semantic Web data" and linkability as a = privacy concern. >> I am not conflating these. > To quote the IETF document I seem to have unsuccessfully suggested you = read a while back, the linkability of two or more Items Of Interest = (e.g., subjects, messages, actions, ...) from an attacker's perspective = means that within a particular set of information, the attacker can = distinguish whether these IOIs are related or not (with a high enough = degree of probability to be useful) [1]. If you "like linkability", = that's great, but probably many use-cases aren't built around liking = linkability. The use of e-mail addresses as the primary identifier of BrowserId is = defended for exactly the reason that web sites want to be able to = communicate back with the user. It is a core part of the BrowserId = marketing spiel. So linkability is core to BrowserID in that respect, = and it is a core use case.=20 But the problem here is that one cannot speak of linkability full stop. = One has to bring some further elements into consideration. The definition from the draft-hansen-privacy-terminology-03 that you = quote suggests that linkability is relative to an agent, call him 'A'. = It is imagined that A has attackers, and so at least it is logically = possible that A have friends too. Communicating with friends is about building links, indeed this is what = building communities is about. So building a social web is about = building links in a distributed decentralised manner. We want to both = increase linkages between people and increase their autonomy. =46rom this it follows that A when communicating has to consider two = groups of people 1- friends: those people with whom A wishes to increase linkages with 2- enemies: those with whom A wishes to avoid linkages leaking to - the = attacker as per draft-hansen-privacy-terminology-03=20 This is a bit rough of a distinction but I think it makes clear that you = cannot just talk about linkability being good or bad without taking into = considerations what the communication is about - with whom someone is = communicating - and what the social network of the person is about - who = his friends and enemies are. > This has very little with hypertext linking of web-pages via URIs. Well that is why above my argument was based in terms of public keys not = URIs. But I could also have made it in terms of e-mail address for = BrowserID. Here let me do it for you. Imagine you go to two web sites with BrowserID: site1.org and s2.net . = Each captures your e-mail address. They then exchange information ( and = they trust each other too - that is an important point btw. ) Each site = then has the following graph in store @prefix foaf: . foaf:mbox . foaf:mbox . =46rom which they can deduce because since foaf:mbox is an = owl:InverseFunctionalProperty ( just look up http://xmlns.com/foaf/0.1/mbox ) that owl:sameAs . There you go: linkability via e-mail addresses. > I think you want to use the term "trust across different sites" rather = than linkability, although I see how WebID wants to conflate that with = trust, which no other identity solution does. A link does not = necessarily mean trust, especially if links aren't bi-directional. There are many different types of links, some indicate trust, some = don't. One can also have the equivalent of bidirectional links. A has a = document where he points to B as a friend, and B returns the favour by = placing a link from his document to A. >=20 > As explained earlier, Mozilla Personae/BrowserID uses digital = signatures where an IDP signs claims but transfers that claim to the RP = via the browser (thus the notion of "different information flow") and = thus the RP and IDP do not directly communicate, reducing the = linkability of the data easily gathered by the IDP (not the RP). As I prooved above, BrowserID by using Public Keys and by using e-mail = identifiers furthermore, is giving a linkable identity to sites people = use to log into. So you don't get away from the paranoid view of = linkability being a problem, without getting any major interesting gain. > I know WebID folks believe IDP =3D my homepage, but for most people = IDP would likely not be a homepage, but a major identity provider for = which data minimization principles should apply, including ownership of = the social network data of an individual and a history of their = interactions with every RP. The point of this e-mail was to show that the type of linkability WebID = provides is here in order to make it possible for people to choose not to inhabit such a = future.=20 > I am not defending BrowerID per se: Personae assumes you trust the = browser, which some people don't. Also, email verification, while = common, is not great from a security perspective, i.e. STARTLS not = giving error messages when it degrades. BrowserId will be an interesting tool in the future, when cryptography = in the browser is available. Until then it has a strong centralisation = focus. WebID delivers what BrowserId promises to do, but now.=20 Anyway, you need to be more careful about talk of linkability, since to = talk of linkability as good or bad without taking the context of who is = talking to whome, who is in the role of the enemy etc, makes no sense. >=20 > Perhaps a more productive question would be why would someone use = WebID rather than OpenID Connect with digital signatures? that can be a discussion for another day perhaps.=20 >=20 > Although, I have ran out of time for this for the time being. >=20 >>=20 >> My point from the beginning is that Linkability is both a good thing = and a bad thing. >>=20 >> As a defender of BrowserId you cannot consistently attack WebID for = linkability concerns and find BrowserId not to have that same problem. = So I hate to reveal this truth to you: but we have to fight this battle = together. >>=20 >> And the battle is simple: the linkability issue is only an issue if = you think the site you >> are authenticating to is the enemy. If you believe that you are in = relation with a site that >> is under a legal and moral duty to be respectful of the communication = you are having with it, >> then you will find that the linkability of information with that site = and across sites is exactly what you want in order to reduce privacy = issues that arise out of centralised systems. >>=20 >>> I do think many people agree stronger cryptographic credentials for = authentication are a good thing, and BrowserID is based on this and = OpenID Connect has (albeit not often used) options in this space. I = would again, please suggest that the WebID community take on board = comments in a polite manner and not cc mailing lists. >> All my communications have been polite, and I don't know why you = select out the WebID community. >> As for taking on board comments, why, just the previous e-mail you = responded to was a demonstration that we are: CN=3DWebID,O=3D=E2=88=85 >>=20 >>=20 >>=20 >>>>=20 >>>>=20 >> Social Web Architect >> http://bblfish.net/ >>=20 >=20 Social Web Architect http://bblfish.net/ --Apple-Mail=_8E4C4C2E-A1D8-4A9E-A98B-DA3252B6570B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPDTCCByMw ggYLoAMCAQICAwTQYzANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEyMDgyOTAxNDU1NloXDTEzMDgzMDA5MjM0MFowZTEZMBcGA1UEDRMQazQ2eDlvOXJDRE5m VzMwYzEgMB4GA1UEAwwXaGVucnkuc3RvcnlAYmJsZmlzaC5uZXQxJjAkBgkqhkiG9w0BCQEWF2hl bnJ5LnN0b3J5QGJibGZpc2gubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArHXp EmiifOSpudkJn1vAnFdZsuaLuYYLbdWL47o1rKD/kg8/RJUmTIM2ara4e/MOxR16mu2fyAca3H1U oIXNNXDbYQDu2PkfLoNSM5JGAoYbfB0nXBK//ZecidVMZ8eExd02/vFzo5vj9kQNaAPSYirid5xe 1cV9Y1RFjlEozuYAUhU8zi3taf22JM45ii2YrCEgVjDdez8yio0QoJeKEEL3JhL4tqpkbfIOHmdi HYx00S6YcCogDfxXc3zOJ3jcIj/F61eXG1qWX/lq9RAyoBjYHLWE2iHQPwdzum03ubcvOTlohqOR +/cVzvx10l6bJ46KitfbydXMh8HoY7QcmwIDAQABo4IDsjCCA64wCQYDVR0TBAIwADALBgNVHQ8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQRbT9qwRblII9x nAN2FlEMUD1LQzAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAiBgNVHREEGzAZgRdo ZW5yeS5zdG9yeUBiYmxmaXNoLm5ldDCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIw ggH/MC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsG AQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEF BQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9u IHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZv ciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5 IG9ibGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBTZWUg c2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5 LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3Js MIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20v c3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29t L2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALj/A19bRLmI7sMf0lVRrdN23NuRC7/UFSLZ DfcxrR1wOtQgAbrFlFLY+Otn6UWYIiWQpv2v5Ploqw9rMam5W8seC3TUt83StohXCmZ0EDmK87If B6kpd7FwJ0RFGCxn22hPU2kuhp2mbjJzCTrd3jWsXw63MXDUzHuucWGX2mY1Ji+zRECh568N7iWA 5jn9kWT+h7o7ywKbHc4qAnksghLYAnTfoCx1IPkT4/8A5hf38imhf9NcNGibrvt/e49sacf6GjRH Ot/lOCrEX2fh2YvTB5sdEKM5tjKCKNpFSqnRCKhsWZ9N9ZP7mRZfCOBjAMsm3CW2ygwlWXc54lgf p1UwggfiMIIFyqADAgECAgENMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQy MTAxNTRaFw0xMjEwMjIyMTAxNTRaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP 6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu 2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyU GHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmt xWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMB AAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUU3Ltkpzg2ssB XHx+ljVO8tS4UYIwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0 YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHmCAQEwCQYDVR0SBAIwADA9BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYB BQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMw JxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmls aXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29t IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRD FkFTdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENl cnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAqprh4FuMzh0b/B3GLDAgoLeTJv3xArbNESi/ Kf/HMM//gf8FzwUUNOCglH6dfYuLQQ/dTtOyMb4JoiL3T7xiVKEAOmQ+t+b/xLOMa0m18zoRqW4k 6Glyoyvc7LMrdpgYk/lEh5nq8tPd9BoNmwiiheXphIVH/QelTgUkNzTC7IVpmYVsKuNOnxE1jJFZ NNfqZZK/5Oto7C6PfOut11KmBQSLZarAz0b/mjghdBsYfHuhdO8vrOvD0g5g7dA4pkOAU2Ed4pSC owBSItyD/5aFwZ75ji6Yq7GCG3BpiyAP9st8h+inc0L+7kmrAMJaLMAmu6GZs5Xgsbzn0wUJvbD9 h5jnnMM9UaZDcxl2uLB04quGUWM6NiKGabbxQc680PYbeQrQu+e6J4uqNAxzoa5RxkBA5a/3qlbg F9uJBekCqJswx5vQ9khJrs8UTMaIFzbEC5VGQziQH3/6KJ4DUP85OJEnCx/quShWA6w318LDnba3 M6a5V+KoNLhsVi/TSxf90UbBqwdRR/cOwuGkNJh16NvvhIqO26osMg64CbZsDVrEDr7uSMV40ieB JTo49Iyt77ECOhz/pyhowa2EUP6aKav+L/wXzAPB3LNqzujGR0K1pbyFWKvyYmdungJtySWUMw+R 5DqpA2bFIOE56pfWPLHZxOL+8+r79PLFX+y2V6ExggNvMIIDawIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRp ZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1l ZGlhdGUgQ2xpZW50IENBAgME0GMwCQYFKw4DAhoFAKCCAa8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMDIyMTkzNjE2WjAjBgkqhkiG9w0BCQQxFgQUWzcUdajj aGM+nXOQfir0gpno63owgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgME0GMwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0ECAwTQYzANBgkqhkiG9w0BAQEFAASCAQCKG/wXqSm19xFKl26yH1salkSPlnZfJBEdKWy1 /TyKlKaV7BiLAZW0t/AI132806qFgMUNAIVC6I2JS5cbTQ77aD4vp8PIaV7KdUK8MGufXWH386yu DI0pf9Ov8jQXoBVlJw8S6OabLxOdCKPfF8eft4L0zczaOHchYuGs2DmRL+YsuB7C3l5QYEsayBim Pcf1HtG7Tohm6rmeZXiu7pA8ytKMrGu4rcBSKZqV5x1KcCMrCzYnNGojMhzNVbB2iVRCS3sWtwB/ 6KAFJxLxlZMzhi8dkjf7GOYMQu0WJ7oXts9diHraR/A7RCiDezQSaHyOFGEEW+BRr+fS/YA2z+jz AAAAAAAA --Apple-Mail=_8E4C4C2E-A1D8-4A9E-A98B-DA3252B6570B-- From huitema@microsoft.com Mon Oct 22 18:04:26 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FB721F84CA for ; Mon, 22 Oct 2012 18:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GY0-hkw21H5P for ; Mon, 22 Oct 2012 18:04:26 -0700 (PDT) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.25]) by ietfa.amsl.com (Postfix) with ESMTP id DF3F621F84C5 for ; Mon, 22 Oct 2012 18:04:25 -0700 (PDT) Received: from BY2FFO11FD005.protection.gbl (10.1.15.202) by BY2FFO11HUB008.protection.gbl (10.1.14.58) with Microsoft SMTP Server (TLS) id 15.0.545.8; Sun, 21 Oct 2012 23:26:13 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD005.mail.protection.outlook.com (10.1.14.126) with Microsoft SMTP Server (TLS) id 15.0.545.8 via Frontend Transport; Sun, 21 Oct 2012 23:26:13 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.52]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Sun, 21 Oct 2012 23:25:07 +0000 From: Christian Huitema To: Russ Housley , IETF SAAG Thread-Topic: [saag] Fwd: I-D Action: draft-iab-identifier-comparison-05.txt Thread-Index: AQHNr5mmGSEYCi/P50io9tugQ5V36ZfEZTH0 Date: Sun, 21 Oct 2012 23:25:07 +0000 Message-ID: References: <20121020231931.10454.3134.idtracker@ietfa.amsl.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377424002)(377454001)(51704002)(2473001)(16406001)(4196001)(5343655001)(1076001)(20776001)(2666001)(53806001)(8716001)(3846001)(46102001)(49866001)(51856001)(50986001)(50466001)(33656001)(16826001)(47976001)(4396001)(15202345001)(74502001)(47736001)(48376001)(42186003)(44976002)(31966008)(47776002)(47446002)(74662001)(16696001)(550184003)(316001)(3556001)(3746001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0641678E68 Subject: Re: [saag] Fwd: I-D Action: draft-iab-identifier-comparison-05.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 01:04:26 -0000 I read this document, and I am missing the issues around lifetime of identi= fiers. Arguably they do not affect the comparison procedures, but they do h= ave an interesting impact on the choices of identifiers and their usage. Th= e classic example is what happens when Bob Miller leaves the Example compan= y, which then hires Bob Smith. Both, at different time, get control of the = email address bob@example.com. Clearly they will get different certificates= , public keys and the like. However, the new certificates will validate aga= inst old access control list, giving Bob Smith access to whatever was alloc= ated previously to Bob Miller. There are of course similar issues with IPv4 addresses being reallocated vi= a DHCP. ________________________________________ From: saag-bounces@ietf.org [saag-bounces@ietf.org] on behalf of Russ Housl= ey [housley@vigilsec.com] Sent: Sunday, October 21, 2012 7:37 AM To: IETF SAAG Subject: [saag] Fwd: I-D Action: draft-iab-identifier-comparison-05.txt This document is in the final stages. If you have last minute comments, pl= ease send them to iab@iab.org very soon. Russ > From: internet-drafts@ietf.org > Date: October 20, 2012 7:19:31 PM EDT > To: i-d-announce@ietf.org > Cc: iab@iab.org > Subject: [IAB] I-D Action: draft-iab-identifier-comparison-05.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Internet Architecture Board Working Grou= p of the IETF. > > Title : Issues in Identifier Comparison for Security Purp= oses > Author(s) : Dave Thaler > Filename : draft-iab-identifier-comparison-05.txt > Pages : 23 > Date : 2012-10-20 > > Abstract: > Identifiers such as hostnames, URIs, and email addresses are often > used in security contexts to identify security principals and > resources. In such contexts, an identifier supplied via some > protocol is often compared against some policy to make security > decisions such as whether the principal may access the resource, what > level of authentication or encryption is required, etc. If the > parties involved in a security decision use different algorithms to > compare identifiers, then failure scenarios ranging from denial of > service to elevation of privilege can result. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-iab-identifier-comparison > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-iab-identifier-comparison-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-iab-identifier-comparison-05 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag= From tho@koanlogic.com Tue Oct 23 00:52:44 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3D421F8666 for ; Tue, 23 Oct 2012 00:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.902 X-Spam-Level: X-Spam-Status: No, score=-2.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05+Kt68uT3Q1 for ; Tue, 23 Oct 2012 00:52:43 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id B4D2721F866F for ; Tue, 23 Oct 2012 00:52:43 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id s14so2381559qcg.31 for ; Tue, 23 Oct 2012 00:52:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=vIq3CbHh8LKVnhmTk3meybe7F2pbblN2QANTdZbTIYo=; b=lRm17OQ887gxcy7i8EKQ3F62WCJLPChZc8Z5RJ51yVZV/Agn582txZs+PYfmSqZE05 isEG0v0W9dv5MMS0sYaRU8dyz2vW4sZgupnJoCzs6KrlFe0TnqvnUFpCSumqsnYsYfM0 aEa/uYGaUU6izgNANYDhiWskZDZ/QeCHqEi7dLI8mwo/DGIzYayAp3G4chNkNjXGDCvp Pm7NgKJg8FmaKilyVak5nRPlEgxB9qxSn4sJto4tUT5sZVeVX++ciHorqD68V+Mxu3D5 Tl7nl8VNlleU6M3n1O+0WA8s6YXKvp9UnYZ7oIw+wQTKgvijOosQsLojeuuyXkJrcl4s NLgw== MIME-Version: 1.0 Received: by 10.229.176.217 with SMTP id bf25mr1359033qcb.4.1350978762967; Tue, 23 Oct 2012 00:52:42 -0700 (PDT) Received: by 10.49.26.170 with HTTP; Tue, 23 Oct 2012 00:52:42 -0700 (PDT) X-Originating-IP: [81.134.152.4] In-Reply-To: <50858C14.1070809@gondrom.org> References: <50826EDE.6000509@gondrom.org> <50858C14.1070809@gondrom.org> Date: Tue, 23 Oct 2012 08:52:42 +0100 Message-ID: From: Thomas Fossati To: Tobias Gondrom Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQku7du5B/Mmm5Xq2T9z0JDplCisYM7KzMvFca0icuVTZZIBoA63rtEtSPO6Mv8j3oa9w7Du Cc: saag@ietf.org Subject: Re: [saag] Input for conflict review of draft-secure-cookie-session-protocol X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 07:52:45 -0000 Hi Tobias, On Mon, Oct 22, 2012 at 7:10 PM, Tobias Gondrom wrote: > That might be a use case to explore as justification for the draft. As > interoperability of different implementations would be a reason to write > this down. (otherwise people could equally do proprietary > implementations...) Which includes all the use cases except the mere "web interface to the diskless router". >> I share the vision that, say, online banking is not the right use case >> for "pure" SCS (i.e. without a bit of state on server but the crypto >> keys), but we can't pretend that online banking is the only playground >> for cookies/ authorisation tokens in the web. Likewise, I don't >> pretend the HTTP interface to a diskless home router is the most >> important application on the face of earth :-) Yet, someone in the >> digital content distribution market would tell you that SCS/SCS-like >> mechanisms are in massive use today, on STBs and other kind of >> non-browser UAs... > > Ok. These use cases might be worth referencing/adding in the appendix, and > framing what SCS is intended for. The introduction already mention that: "Another noteworthy application scenario is represented by the distribution of authorized web content (e.g. by CDNs), where an SCS token can be used, either in a cookie or embedded in the URI, to provide evidence of the entitlement to access the associated resource by the requesting user agent." > Maybe to explain one further bit, why this rang some bells (alarm bells that > is): > In any server implementation, I always advise that people must never trust > content from the client. And that at the least you must verify all client > input for range, type etc. And in a good implementation the server shall > store the state and only allow the client to link to that state by > reference. Client data is outside of the control of the server and can be > lost, corrupted, manipulated on the way or even intentionally malformed by > an authorised client/UA to screw things up. This can lead to data leakage, > corruption of server data, or in simple cases also to fostering DoS by CPU > costs on the server due to de-/encryption algorithm CPU times. So a server > must never trust client data or client state (and IMHO use client-side state > data as little as possible). And SCS is basically going against this > underlying security paradigm, which is giving me some worries. I think poor SCS has been misunderstood here :-) The "state" (or whatever the server puts into the DATA atom) is encrypted, timestamped, and attached a proof of authorship by the server. No client -- intentionally or unintentionally -- can screw things up without being noticed, unless of course she possesses the private server keys (but this is a completely different story). So, no data leakage, nor corruption is possible with SCS (this was in fact a design goal). The only really different thing (whose impact is described in Sect. 8.2.2.) is the voluntary deletion of an SCS cookie by the client. As to the possible resource DoS, it would be spotted very early by the "inbound transform" (Sect. 3.2.6) after just applying a Base64 decoding and one HMAC on a typically slim input -- a really negligible demand in terms of memory/cpu, even for an embedded devices which, BTW, is already keeping the TCP context, parsing HTTP headers, etc. Cheers, Thomas. From benlaurie@gmail.com Tue Oct 23 01:44:08 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E60D21F85A2 for ; Tue, 23 Oct 2012 01:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_25=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5uWNFIyeRWC for ; Tue, 23 Oct 2012 01:44:07 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF1921F8566 for ; Tue, 23 Oct 2012 01:44:07 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so4308490vcb.31 for ; Tue, 23 Oct 2012 01:44:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pVewrIFHuODjNQ8qeYebKFXfUIVsYpucj2K2A/4oOA8=; b=K+3ZRgx+dOWOOzMxwiqb67BSMu5Wgv+uu++BoYyc4RLursxaAKVXN7WLm9kKCr5sdi ikNodfTClQvJSmXopJl2O/JAF4NN8L/YgD8iwgHAvNwA9gLqvG/kM7MON1DgV+QH3WwF zqi/X0BCrGMeCXsYG2Vw+0YVA/DPPcyXxB/4BDys4NXdkhngWHpYm3mn9c5NHyuvIJKe GaQWD/IQ5rzxenzskXlv2idSM1xPbL1QoMsXsi64Hst54dmWPdyEy0KuxrFe9A95WvnS 4yTnH7miDz8iGYI0G5YooUWti7dvKUVOilV1sMDLZbbA9NMrIgiiQlghgOeRnOMGk0nH wbLg== MIME-Version: 1.0 Received: by 10.58.95.65 with SMTP id di1mr20980360veb.55.1350981846645; Tue, 23 Oct 2012 01:44:06 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.58.18.235 with HTTP; Tue, 23 Oct 2012 01:44:06 -0700 (PDT) In-Reply-To: References: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <5083CCCF.2060407@webr3.org> <50842789.3080301@openlinksw.com> <50845268.4010509@webr3.org> <5084AC77.8030600@openlinksw.com> <50851512.9090803@webr3.org> <50852726.9030102@openlinksw.com> <5085360E.3080008@openlinksw.com> <50853CD8.8020005@w3.org> <5FB468E4-BDD3-4635-ACD0-A23540C08751@bblfish.net> <508562C2.1060905@w3.org> Date: Tue, 23 Oct 2012 09:44:06 +0100 X-Google-Sender-Auth: KrWP1S6yB5VAdLYxPthfKuOrQnk Message-ID: From: Ben Laurie To: Henry Story Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Halpin Harry , public-identity@w3.org, saag@ietf.org, public-webid@w3.org, "public-privacy@w3.org list" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 08:44:08 -0000 On Mon, Oct 22, 2012 at 8:36 PM, Henry Story wrot= e: > > On 22 Oct 2012, at 17:14, Harry Halpin wrote: > >> On 10/22/2012 04:04 PM, Henry Story wrote: >>> On 22 Oct 2012, at 14:32, Harry Halpin wrote: >>> >>>> On 10/22/2012 02:03 PM, Kingsley Idehen wrote: >>>>> On 10/22/12 7:26 AM, Ben Laurie wrote: >>>>>> On 22 October 2012 11:59, Kingsley Idehen w= rote: >>>>>>> On 10/22/12 5:54 AM, Ben Laurie wrote: >>>>>>>> Where we came in was me pointing out that if you disconnect your >>>>>>>> identities by using multiple WebIDs, then you have a UI problem, a= nd >>>>>>>> since then the aim seems to have been to persuade us that multiple >>>>>>>> WebIDs are not needed. >>>>>>> Multiple WebIDs (or any other cryptographically verifiable identifi= er) are a >>>>>>> must. >>>>>>> >>>>>>> The issue of UI is inherently subjective. It can't be used to objec= tively >>>>>>> validate or invalidate Web-scale verifiable identifier systems such= as >>>>>>> WebID or any other mechanism aimed at achieving the same goals. >>>>>> Ultimately what matters is: do users use it correctly? This can be t= ested :-) >>>>>> >>>>>> Note that it is necessary to test the cases where the website is evi= l, >>>>>> too - something that's often conveniently missed out of user testing= . >>>>>> For example, its pretty obvious that OpenID fails horribly in this >>>>>> case, so it tends not to get tested. >>>>> Okay. >>>>>>> Anyway, Henry, I, and a few others from the WebID IG (hopefully) a= re going >>>>>>> to knock up some demonstrations to show how this perceived UI/UX >>>>>>> inconvenience can be addressed. >>>>>> Cool. >>>>> Okay, ball is in our court to now present a few implementations that = address the UI/UX concerns. >>>>> >>>>> Quite relieved to have finally reached this point :-) >>>> No, its not a UI/UX concern, although the UI experience of both identi= ty on the Web and with WebID in particular is quite terrible, I agree. >>> It completely depends on the browsers: >>> http://www.w3.org/wiki/Foaf%2Bssl/Clients/CertSelection >>> If you are on Linux just file a bug request to your browser if you are = unhappy, or even better hack up a good UI. It's easy: just make it simpler. >>> >>>> My earlier concern was an information flow concern that causes the iss= ue with linkability, which WebID shares to a large extent with other server= -side information-flow. >>> Including BrowserId. Which has 2 tokens that can be used to identify th= e user across sites: >>> >>> - an e-mail address ( useful for spamming ) >>> - a public key, which can be used to authenticate across sites >>> >>> >>>> As stated earlier, as long as you trust the browser, BrowserID does am= eliorate this. >>> No it does not improve linkability at all. Certainly not if you think t= he site you are authenticating to is the one you should be worried about, b= ecause just using a public key >>> by itself is enough for Linkability in the strict (paranoid) sense. Tha= t is if you >>> consider the site you are logging into to as the attacker, then by givi= ng two sites >>> a public key where you have proven you control the private key is enoug= h for them to know that >>> the same agent visited both sites. That is because the cert:key relatio= n is inverse functional. >>> >>> So in simple logical terms if you go to site1.org and identify with a p= ublic key pk, >>> and they create a local identifier for you , and= then you go site s2.net and identify with the same public key pk and they= give you an identifier >>> (these need not be public) and then they exchange their information, th= en each of the sites would have the following relations ( written in http:/= /www.w3.org/TR/Turtle ) >>> >>> @prefix cert: >>> >>> cert:key pk . >>> cert:key pk . >>> >>> because cert:key is defined as an InverseFunctionalProperty >>> ( as you can see by going http://www.w3.org/ns/auth/cert#key ) >>> >>> Then it follows from simple owl reasoning that >>> >>> =3D=3D . >>> >>> One cannot get much simpler logical reasoning that this, Harry. >>> >>> >>>> There is also this rather odd conflation of "linkability" of URIs with= hypertext and URI-enabled Semantic Web data" and linkability as a privacy = concern. >>> I am not conflating these. >> To quote the IETF document I seem to have unsuccessfully suggested you r= ead a while back, the linkability of two or more Items Of Interest (e.g., s= ubjects, messages, actions, ...) from an attacker's perspective means that= within a particular set of information, the attacker can distinguish whet= her these IOIs are related or not (with a high enough degree of probability= to be useful) [1]. If you "like linkability", that's great, but probably m= any use-cases aren't built around liking linkability. > > The use of e-mail addresses as the primary identifier of BrowserId is def= ended for exactly the reason that web sites want to be able to communicate = back with the user. It is a core part of the BrowserId marketing spiel. So = linkability is core to BrowserID in that respect, and it is a core use case= . > > But the problem here is that one cannot speak of linkability full stop. O= ne has to bring some further elements into consideration. > > The definition from the draft-hansen-privacy-terminology-03 that you quot= e suggests that linkability is relative to an agent, call him 'A'. It is im= agined that A has attackers, and so at least it is logically possible that = A have friends too. > > Communicating with friends is about building links, indeed this is what b= uilding communities is about. So building a social web is about building li= nks in a distributed decentralised manner. We want to both increase linkage= s between people and increase their autonomy. > > From this it follows that A when communicating has to consider two groups= of people > 1- friends: those people with whom A wishes to increase linkages with > 2- enemies: those with whom A wishes to avoid linkages leaking to - the = attacker as per draft-hansen-privacy-terminology-03 > > This is a bit rough of a distinction but I think it makes clear that you = cannot just talk about linkability being good or bad without taking into co= nsiderations what the communication is about - with whom someone is communi= cating - and what the social network of the person is about - who his frien= ds and enemies are. > >> This has very little with hypertext linking of web-pages via URIs. > > Well that is why above my argument was based in terms of public keys not = URIs. But I could also have made it in terms of e-mail address for BrowserI= D. Here let me do it for you. > > Imagine you go to two web sites with BrowserID: site1.org and s2.net . Ea= ch captures your e-mail address. They then exchange information ( and they = trust each other too - that is an important point btw. ) Each site then has= the following graph in store > > @prefix foaf: . > > foaf:mbox . > foaf:mbox . > > From which they can deduce because since foaf:mbox is an owl:InverseFunct= ionalProperty > ( just look up http://xmlns.com/foaf/0.1/mbox ) that > > owl:sameAs . > > There you go: linkability via e-mail addresses. > >> I think you want to use the term "trust across different sites" rather t= han linkability, although I see how WebID wants to conflate that with trust= , which no other identity solution does. A link does not necessarily mean = trust, especially if links aren't bi-directional. > > There are many different types of links, some indicate trust, some don't.= One can also have the equivalent of bidirectional links. A has a document = where he points to B as a friend, and B returns the favour by placing a lin= k from his document to A. > >> >> As explained earlier, Mozilla Personae/BrowserID uses digital signatures= where an IDP signs claims but transfers that claim to the RP via the brow= ser (thus the notion of "different information flow") and thus the RP and I= DP do not directly communicate, reducing the linkability of the data easily= gathered by the IDP (not the RP). > > As I prooved above, BrowserID by using Public Keys and by using e-mail id= entifiers furthermore, is giving a linkable identity to sites people use to= log into. So you don't get away from the paranoid view of linkability bein= g a problem, without getting any major interesting gain. > >> I know WebID folks believe IDP =3D my homepage, but for most people IDP = would likely not be a homepage, but a major identity provider for which dat= a minimization principles should apply, including ownership of the social n= etwork data of an individual and a history of their interactions with every= RP. > > The point of this e-mail was to show that the type of linkability WebID p= rovides is here in > order to make it possible for people to choose not to inhabit such a futu= re. > >> I am not defending BrowerID per se: Personae assumes you trust the brows= er, which some people don't. Also, email verification, while common, is not= great from a security perspective, i.e. STARTLS not giving error messages = when it degrades. > > BrowserId will be an interesting tool in the future, when cryptography in= the browser is available. Until then it has a strong centralisation focus.= WebID delivers what BrowserId > promises to do, but now. > > Anyway, you need to be more careful about talk of linkability, since to t= alk of linkability as good or bad without taking the context of who is talk= ing to whome, who is in the role of the enemy etc, makes no sense. > >> >> Perhaps a more productive question would be why would someone use WebID = rather than OpenID Connect with digital signatures? > > that can be a discussion for another day perhaps. Not disagreeing with any of the above, but observing that: a) There's no particular reason you could not have an email per site as well as a key per site. b) Linkability it not, as you say, inherently bad. The problem occurs when you have (effectively) no choice about linkability. >> >> Although, I have ran out of time for this for the time being. >> >>> >>> My point from the beginning is that Linkability is both a good thing an= d a bad thing. >>> >>> As a defender of BrowserId you cannot consistently attack WebID for lin= kability concerns and find BrowserId not to have that same problem. So I ha= te to reveal this truth to you: but we have to fight this battle together. >>> >>> And the battle is simple: the linkability issue is only an issue if you= think the site you >>> are authenticating to is the enemy. If you believe that you are in rela= tion with a site that >>> is under a legal and moral duty to be respectful of the communication y= ou are having with it, >>> then you will find that the linkability of information with that site a= nd across sites is exactly what you want in order to reduce privacy issues = that arise out of centralised systems. >>> >>>> I do think many people agree stronger cryptographic credentials for au= thentication are a good thing, and BrowserID is based on this and OpenID Co= nnect has (albeit not often used) options in this space. I would again, pl= ease suggest that the WebID community take on board comments in a polite ma= nner and not cc mailing lists. >>> All my communications have been polite, and I don't know why you select= out the WebID community. >>> As for taking on board comments, why, just the previous e-mail you resp= onded to was a demonstration that we are: CN=3DWebID,O=3D=E2=88=85 >>> >>> >>> >>>>> >>>>> >>> Social Web Architect >>> http://bblfish.net/ >>> >> > > Social Web Architect > http://bblfish.net/ > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From henry.story@bblfish.net Tue Oct 23 02:45:34 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F8221F865D for ; Tue, 23 Oct 2012 02:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=-0.925, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GXDmheOb2Zo for ; Tue, 23 Oct 2012 02:45:32 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA7821F8644 for ; Tue, 23 Oct 2012 02:45:24 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so1534004eek.31 for ; Tue, 23 Oct 2012 02:45:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=PJwczBqueP92wrwCPBpHcNDMkaVgGiUoRwp3wkKvZv4=; b=kDbtuemjEu2jmpxoiiu1Be/GB4/QU09ovDs5AQZsENDr/byQt7uFZFGwrUr+mNCcUN dUW1ZtuNa+qXQ+wYhzh3hTCuRfkEsr9Uxr/GlEgybyNvJgIP3sQ/4HMAO08vE2rnpoBb k05p+w/S9OmROaBmV2NqBFqqhh+5+OhHiQHax/a77gIS7SEkz6XMIuU4Lm/A1Goqlsa/ Hg46zhwBgcJ2qqkhAASXO0IMFIx/kYCB5tTY7qSo5PAioPUKQl2vOcM4wYz1fOIyIyAV xNjRAGDSTCtBaT4djU46wGsBw5/Dwt7lcC8tJEBS+w0D4LO0K0n+7wNC0eLy0RkC6m8k GFAA== Received: by 10.14.178.195 with SMTP id f43mr16005264eem.44.1350985523256; Tue, 23 Oct 2012 02:45:23 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-132-122.w86-198.abo.wanadoo.fr. [86.198.99.122]) by mx.google.com with ESMTPS id o47sm19988637eem.11.2012.10.23.02.45.13 (version=SSLv3 cipher=OTHER); Tue, 23 Oct 2012 02:45:20 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0BA3C0EA-8071-4E2C-9DB6-D2AC3D886780"; protocol="application/pkcs7-signature"; micalg=sha1 From: Henry Story In-Reply-To: Date: Tue, 23 Oct 2012 11:45:11 +0200 Message-Id: <44F83E73-8D1E-450F-94B5-0AFC3D9BFB18@bblfish.net> References: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <5083CCCF.2060407@webr3.org> <50842789.3080301@openlinksw.com> <50845268.4010509@webr3.org> <5084AC77.8030600@openlinksw.com> <50851512.9090803@webr3.org> <50852726.9030102@openlinksw.com> <5085360E.3080008@openlinksw.com> <50853CD8.8020005@w3.org> <5FB468E4-BDD3-4635-ACD0-A23540C08751@bblfish.net> <508562C2.1060905@w3.org> To: Ben Laurie X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmlSmaQsOLoVUHNab2Ae3KsSTGer0e/cp6do+H+024I/SFETjvEj7F0fKnpVTv1yGH8NBFp Cc: public-identity@w3.org, saag@ietf.org, public-webid@w3.org, "public-privacy@w3.org list" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 09:45:34 -0000 --Apple-Mail=_0BA3C0EA-8071-4E2C-9DB6-D2AC3D886780 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 23 Oct 2012, at 10:44, Ben Laurie wrote: > On Mon, Oct 22, 2012 at 8:36 PM, Henry Story = wrote: >>=20 >> On 22 Oct 2012, at 17:14, Harry Halpin wrote: >>=20 >>> On 10/22/2012 04:04 PM, Henry Story wrote: >>>> On 22 Oct 2012, at 14:32, Harry Halpin wrote: >>>>=20 >>>>> On 10/22/2012 02:03 PM, Kingsley Idehen wrote: >>>>>> On 10/22/12 7:26 AM, Ben Laurie wrote: >>>>>>> On 22 October 2012 11:59, Kingsley Idehen = wrote: >>>>>>>> On 10/22/12 5:54 AM, Ben Laurie wrote: >>>>>>>>> Where we came in was me pointing out that if you disconnect = your >>>>>>>>> identities by using multiple WebIDs, then you have a UI = problem, and >>>>>>>>> since then the aim seems to have been to persuade us that = multiple >>>>>>>>> WebIDs are not needed. >>>>>>>> Multiple WebIDs (or any other cryptographically verifiable = identifier) are a >>>>>>>> must. >>>>>>>>=20 >>>>>>>> The issue of UI is inherently subjective. It can't be used to = objectively >>>>>>>> validate or invalidate Web-scale verifiable identifier systems = such as >>>>>>>> WebID or any other mechanism aimed at achieving the same goals. >>>>>>> Ultimately what matters is: do users use it correctly? This can = be tested :-) >>>>>>>=20 >>>>>>> Note that it is necessary to test the cases where the website is = evil, >>>>>>> too - something that's often conveniently missed out of user = testing. >>>>>>> For example, its pretty obvious that OpenID fails horribly in = this >>>>>>> case, so it tends not to get tested. >>>>>> Okay. >>>>>>>> Anyway, Henry, I, and a few others from the WebID IG = (hopefully) are going >>>>>>>> to knock up some demonstrations to show how this perceived = UI/UX >>>>>>>> inconvenience can be addressed. >>>>>>> Cool. >>>>>> Okay, ball is in our court to now present a few implementations = that address the UI/UX concerns. >>>>>>=20 >>>>>> Quite relieved to have finally reached this point :-) >>>>> No, its not a UI/UX concern, although the UI experience of both = identity on the Web and with WebID in particular is quite terrible, I = agree. >>>> It completely depends on the browsers: >>>> http://www.w3.org/wiki/Foaf%2Bssl/Clients/CertSelection >>>> If you are on Linux just file a bug request to your browser if you = are unhappy, or even better hack up a good UI. It's easy: just make it = simpler. >>>>=20 >>>>> My earlier concern was an information flow concern that causes the = issue with linkability, which WebID shares to a large extent with other = server-side information-flow. >>>> Including BrowserId. Which has 2 tokens that can be used to = identify the user across sites: >>>>=20 >>>> - an e-mail address ( useful for spamming ) >>>> - a public key, which can be used to authenticate across sites >>>>=20 >>>>=20 >>>>> As stated earlier, as long as you trust the browser, BrowserID = does ameliorate this. >>>> No it does not improve linkability at all. Certainly not if you = think the site you are authenticating to is the one you should be = worried about, because just using a public key >>>> by itself is enough for Linkability in the strict (paranoid) sense. = That is if you >>>> consider the site you are logging into to as the attacker, then by = giving two sites >>>> a public key where you have proven you control the private key is = enough for them to know that >>>> the same agent visited both sites. That is because the cert:key = relation is inverse functional. >>>>=20 >>>> So in simple logical terms if you go to site1.org and identify with = a public key pk, >>>> and they create a local identifier for you , = and then you go site s2.net and identify with the same public key pk = and they give you an identifier >>>> (these need not be public) and then they exchange their = information, then each of the sites would have the following relations ( = written in http://www.w3.org/TR/Turtle ) >>>>=20 >>>> @prefix cert: >>>>=20 >>>> cert:key pk . >>>> cert:key pk . >>>>=20 >>>> because cert:key is defined as an InverseFunctionalProperty >>>> ( as you can see by going http://www.w3.org/ns/auth/cert#key ) >>>>=20 >>>> Then it follows from simple owl reasoning that >>>>=20 >>>> =3D=3D . >>>>=20 >>>> One cannot get much simpler logical reasoning that this, Harry. >>>>=20 >>>>=20 >>>>> There is also this rather odd conflation of "linkability" of URIs = with hypertext and URI-enabled Semantic Web data" and linkability as a = privacy concern. >>>> I am not conflating these. >>> To quote the IETF document I seem to have unsuccessfully suggested = you read a while back, the linkability of two or more Items Of Interest = (e.g., subjects, messages, actions, ...) from an attacker's perspective = means that within a particular set of information, the attacker can = distinguish whether these IOIs are related or not (with a high enough = degree of probability to be useful) [1]. If you "like linkability", = that's great, but probably many use-cases aren't built around liking = linkability. >>=20 >> The use of e-mail addresses as the primary identifier of BrowserId is = defended for exactly the reason that web sites want to be able to = communicate back with the user. It is a core part of the BrowserId = marketing spiel. So linkability is core to BrowserID in that respect, = and it is a core use case. >>=20 >> But the problem here is that one cannot speak of linkability full = stop. One has to bring some further elements into consideration. >>=20 >> The definition from the draft-hansen-privacy-terminology-03 that you = quote suggests that linkability is relative to an agent, call him 'A'. = It is imagined that A has attackers, and so at least it is logically = possible that A have friends too. >>=20 >> Communicating with friends is about building links, indeed this is = what building communities is about. So building a social web is about = building links in a distributed decentralised manner. We want to both = increase linkages between people and increase their autonomy. >>=20 >> =46rom this it follows that A when communicating has to consider two = groups of people >> 1- friends: those people with whom A wishes to increase linkages with >> 2- enemies: those with whom A wishes to avoid linkages leaking to - = the attacker as per draft-hansen-privacy-terminology-03 >>=20 >> This is a bit rough of a distinction but I think it makes clear that = you cannot just talk about linkability being good or bad without taking = into considerations what the communication is about - with whom someone = is communicating - and what the social network of the person is about - = who his friends and enemies are. >>=20 >>> This has very little with hypertext linking of web-pages via URIs. >>=20 >> Well that is why above my argument was based in terms of public keys = not URIs. But I could also have made it in terms of e-mail address for = BrowserID. Here let me do it for you. >>=20 >> Imagine you go to two web sites with BrowserID: site1.org and s2.net = . Each captures your e-mail address. They then exchange information ( = and they trust each other too - that is an important point btw. ) Each = site then has the following graph in store >>=20 >> @prefix foaf: . >>=20 >> foaf:mbox . >> foaf:mbox . >>=20 >> =46rom which they can deduce because since foaf:mbox is an = owl:InverseFunctionalProperty >> ( just look up http://xmlns.com/foaf/0.1/mbox ) that >>=20 >> owl:sameAs . >>=20 >> There you go: linkability via e-mail addresses. >>=20 >>> I think you want to use the term "trust across different sites" = rather than linkability, although I see how WebID wants to conflate that = with trust, which no other identity solution does. A link does not = necessarily mean trust, especially if links aren't bi-directional. >>=20 >> There are many different types of links, some indicate trust, some = don't. One can also have the equivalent of bidirectional links. A has a = document where he points to B as a friend, and B returns the favour by = placing a link from his document to A. >>=20 >>>=20 >>> As explained earlier, Mozilla Personae/BrowserID uses digital = signatures where an IDP signs claims but transfers that claim to the RP = via the browser (thus the notion of "different information flow") and = thus the RP and IDP do not directly communicate, reducing the = linkability of the data easily gathered by the IDP (not the RP). >>=20 >> As I prooved above, BrowserID by using Public Keys and by using = e-mail identifiers furthermore, is giving a linkable identity to sites = people use to log into. So you don't get away from the paranoid view of = linkability being a problem, without getting any major interesting gain. >>=20 >>> I know WebID folks believe IDP =3D my homepage, but for most people = IDP would likely not be a homepage, but a major identity provider for = which data minimization principles should apply, including ownership of = the social network data of an individual and a history of their = interactions with every RP. >>=20 >> The point of this e-mail was to show that the type of linkability = WebID provides is here in >> order to make it possible for people to choose not to inhabit such a = future. >>=20 >>> I am not defending BrowerID per se: Personae assumes you trust the = browser, which some people don't. Also, email verification, while = common, is not great from a security perspective, i.e. STARTLS not = giving error messages when it degrades. >>=20 >> BrowserId will be an interesting tool in the future, when = cryptography in the browser is available. Until then it has a strong = centralisation focus. WebID delivers what BrowserId >> promises to do, but now. >>=20 >> Anyway, you need to be more careful about talk of linkability, since = to talk of linkability as good or bad without taking the context of who = is talking to whome, who is in the role of the enemy etc, makes no = sense. >>=20 >>>=20 >>> Perhaps a more productive question would be why would someone use = WebID rather than OpenID Connect with digital signatures? >>=20 >> that can be a discussion for another day perhaps. >=20 > Not disagreeing with any of the above, but observing that: >=20 > a) There's no particular reason you could not have an email per site > as well as a key per site. >=20 > b) Linkability it not, as you say, inherently bad. The problem occurs > when you have (effectively) no choice about linkability. Yes. We're agreeing here :-) Just to expand on our agreement: a) You can have an e-mail per site, indeed. That is: nothing disallows = that. But of course that is not what the core use case for BrowserId is. Btw. you can have a profile page per web site too. Any web site that = uses a cookie for a user could create a web page for that connection = where it publishes the information of what it knows about that user. So = for some connection of a user with cookie ck123, web site1.org could = create a access controlled web page where it publishes what it knows about ck123. = This page could be named anything, but let's say that it chooses https://site1.org/cki/ck123=20 It could publish there <#u> foaf:mbox . So that site could be either well intentioned or not. It could be = sharing that information with co-conspirators, hand it over to the FBI = whenever asked (as per US law), or take a stand the way Nichals Merill = did when he fought an FBI order nearly all the way to the supreme court = ( see his Chaos Communication Congress talk "The Importance of = Resisting excessive Government Surveillance" = http://www.youtube.com/watch?v=3DsDkHPNbCC1M ) So above I have have Harry use BrowserId to log into that site. But = most users who log in to a site even using other technologies will = pretty soon give enough information out to be linkable, since it = requires only very few pieces of information for one to be able to get a = statistically high enough correlation to make linkable relations. As a = result one would be making their life extreemly difficult for only very = little actual security gain. The difficulty of making connections cross = sites is then a good reason for 500million people to go use one central = service provider that only requires one login. We have something akin to air in a balloon: you press in one place and = the air just moves elsewhere. So you create a completely unlinkable = security architecture, and all that happens is people move to a = centralised system.=20 b) yes. We don't want people to have no choice about linkability. My = view is we need to decrease sur-veillance we need to help people move to = technologies of sous-veillance, by distributing information back to the = nodes a lot more. That requires us to have better linkability = technologies... oddly enough. :-) >=20 >>>=20 >>> Although, I have ran out of time for this for the time being. >>>=20 >>>>=20 >>>> My point from the beginning is that Linkability is both a good = thing and a bad thing. >>>>=20 >>>> As a defender of BrowserId you cannot consistently attack WebID for = linkability concerns and find BrowserId not to have that same problem. = So I hate to reveal this truth to you: but we have to fight this battle = together. >>>>=20 >>>> And the battle is simple: the linkability issue is only an issue if = you think the site you >>>> are authenticating to is the enemy. If you believe that you are in = relation with a site that >>>> is under a legal and moral duty to be respectful of the = communication you are having with it, >>>> then you will find that the linkability of information with that = site and across sites is exactly what you want in order to reduce = privacy issues that arise out of centralised systems. >>>>=20 >>>>> I do think many people agree stronger cryptographic credentials = for authentication are a good thing, and BrowserID is based on this and = OpenID Connect has (albeit not often used) options in this space. I = would again, please suggest that the WebID community take on board = comments in a polite manner and not cc mailing lists. >>>> All my communications have been polite, and I don't know why you = select out the WebID community. >>>> As for taking on board comments, why, just the previous e-mail you = responded to was a demonstration that we are: CN=3DWebID,O=3D=E2=88=85 >>>>=20 >>>>=20 >>>>=20 >>>>>>=20 >>>>>>=20 >>>> Social Web Architect >>>> http://bblfish.net/ >>>>=20 >>>=20 >>=20 >> Social Web Architect >> http://bblfish.net/ >>=20 >>=20 >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >>=20 Social Web Architect http://bblfish.net/ --Apple-Mail=_0BA3C0EA-8071-4E2C-9DB6-D2AC3D886780 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINXzCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHIzCCBgug AwIBAgIDBNBjMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTIwODI5MDE0NTU2WhcNMTMwODMwMDkyMzQwWjBlMRkwFwYDVQQNExBrNDZ4OW85ckNETmZXMzBj MSAwHgYDVQQDDBdoZW5yeS5zdG9yeUBiYmxmaXNoLm5ldDEmMCQGCSqGSIb3DQEJARYXaGVucnku c3RvcnlAYmJsZmlzaC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsdekSaKJ8 5Km52QmfW8CcV1my5ou5hgtt1YvjujWsoP+SDz9ElSZMgzZqtrh78w7FHXqa7Z/IBxrcfVSghc01 cNthAO7Y+R8ug1IzkkYChht8HSdcEr/9l5yJ1Uxnx4TF3Tb+8XOjm+P2RA1oA9JiKuJ3nF7VxX1j VEWOUSjO5gBSFTzOLe1p/bYkzjmKLZisISBWMN17PzKKjRCgl4oQQvcmEvi2qmRt8g4eZ2IdjHTR LphwKiAN/FdzfM4neNwiP8XrV5cbWpZf+Wr1EDKgGNgctYTaIdA/B3O6bTe5ty85OWiGo5H79xXO /HXSXpsnjoqK19vJ1cyHwehjtBybAgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIE sDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFBFtP2rBFuUgj3GcA3YW UQxQPUtDMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMCIGA1UdEQQbMBmBF2hlbnJ5 LnN0b3J5QGJibGZpc2gubmV0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8w LgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwIC MIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRp ZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVx dWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRo ZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2Js aWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0 aW9uICJMZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAuP8DX1tEuYjuwx/SVVGt03bc25ELv9QVItkN9zGt HXA61CABusWUUtj462fpRZgiJZCm/a/k+WirD2sxqblbyx4LdNS3zdK2iFcKZnQQOYrzsh8HqSl3 sXAnREUYLGfbaE9TaS6GnaZuMnMJOt3eNaxfDrcxcNTMe65xYZfaZjUmL7NEQKHnrw3uJYDmOf2R ZP6HujvLApsdzioCeSyCEtgCdN+gLHUg+RPj/wDmF/fyKaF/01w0aJuu+397j2xpx/oaNEc63+U4 KsRfZ+HZi9MHmx0Qozm2MoIo2kVKqdEIqGxZn031k/uZFl8I4GMAyybcJbbKDCVZdzniWB+nVTGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwTQYzAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjEwMjMwOTQ1 MTJaMCMGCSqGSIb3DQEJBDEWBBSwIse9k50yGQAj5bzk1fgfruRBzTCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwTQYzCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBNBjMA0GCSqGSIb3DQEBAQUABIIBAABk /ywieVUWIsDi+CVd/Te0C9Eiqcx0ZuT+wdJWBrp/L0ahWbs6rD95+C94NkQ+5FDPG2xHtJllx/xH NmLQQkTWrp7tLf5v7DCmP2qAeGB7Ub2c6ZlBVws6wCcgSe4Qs3DuFrmc4YFnuD2i669lkBEDhRzj MVWyBF8U+Nn1q9r6XlTjez/Mp2QapTXIefNxHiHg7viJnBpfxmEAIzOBamixO2hSx6prA3hx2HR6 oJ/4YHqk2L19J7FsGOFv1gPXiIbzkoCqTKQIfEP3uvuZkoZvdP0oHdKOrjonei3sLwRaONpAJ7j8 +HiulBiDj7aA8Ul1DdKTVivJSKS6RS7tcbMAAAAAAAA= --Apple-Mail=_0BA3C0EA-8071-4E2C-9DB6-D2AC3D886780-- From henry.story@bblfish.net Tue Oct 23 03:15:24 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A00821F8654 for ; Tue, 23 Oct 2012 03:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.94 X-Spam-Level: X-Spam-Status: No, score=-2.94 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rhqc9R-RWvnu for ; Tue, 23 Oct 2012 03:15:23 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id C1CD621F8620 for ; Tue, 23 Oct 2012 03:15:22 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so1279431bkc.31 for ; Tue, 23 Oct 2012 03:15:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=9eb0rpx8NVtXXONLy3/Wf0wufmOXO9JoqSPMQSik5TU=; b=HPNiqMoWJiNUEwws0evDCaFJvEjk5bE7qmKiePf+KbQVInqxWxVNNE2z1GC1ManxiZ OEhlzz9uR5UlQr7M7JZEzkhqa5XcooNdOkrAMwzBspjVLaTkjOX3VjXzcn8CvmwEx+cd prMxfYQ/g+YtROtv2+6POrnejI2Rlwh9rH31QpbI0FrZ/xJ27Bw3nUcI0a7kL080bOJx FNmlO6YX5XIiUlDnWd+SJsJrSA07g5Y5SQMGnNwEm9xZNQu9w54EAA6jJXYEUlQeO6jU 1oLmzTiR3/XRqSuTEqmxnoOuxXk1l9jppXka2Ebe8IhNToPde0TgmHy4YyyoHend+s6Y V9GA== Received: by 10.205.135.20 with SMTP id ie20mr3615409bkc.16.1350987321436; Tue, 23 Oct 2012 03:15:21 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-132-122.w86-198.abo.wanadoo.fr. [86.198.99.122]) by mx.google.com with ESMTPS id ht18sm5277984bkc.14.2012.10.23.03.14.51 (version=SSLv3 cipher=OTHER); Tue, 23 Oct 2012 03:15:17 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_4D66E970-5676-43C8-9B12-0983F407E87A"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Henry Story In-Reply-To: <508669C5.90400@webr3.org> Date: Tue, 23 Oct 2012 12:14:49 +0200 Message-Id: <028CAB40-4F6E-41DD-99C5-E474DF3B7A53@bblfish.net> References: <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <5083CCCF.2060407@webr3.org> <50842789.3080301@openlinksw.com> <50845268.4010509@webr3.org> <5084AC77.8030600@openlinksw.com> <50851512.9090803@webr3.org> <50852726.9030102@openlinksw.com> <5085360E.3080008@openlinksw.com> <50853CD8.8020005@w3.org> <5FB468E4-BDD3-4635-ACD0-A23540C08751@bblfish.net> <508562C2.1060905@w3.org> <508669C5.90400@webr3.org> To: nathan@webr3.org X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkU1iFjC1H+bt7j25Hb8PpfrERq3zWZj54IvD7ZIrH5xBpJPTCAziv/2RPAllhjEDxgN4iv Cc: Halpin Harry , public-identity@w3.org, saag@ietf.org, "public-privacy@w3.org list" , public-webid@w3.org Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 10:15:24 -0000 --Apple-Mail=_4D66E970-5676-43C8-9B12-0983F407E87A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 23 Oct 2012, at 11:56, Nathan wrote: > Ben Laurie wrote: >> b) Linkability it not, as you say, inherently bad. The problem occurs >> when you have (effectively) no choice about linkability. >=20 > .. and when people convey or infer that there is no choice about = linkability, when there really is scope to be as unlinkable as one likes = within WebID. >=20 > Quite convinced now that the confusion is just differing objectives = and opinions, and nothing technical. >=20 > You can have one or more WebIDs to cover any combination of one or = more requests to one or more resources. Be as linkable or unlinkable as = you like. >=20 > On the other hand, WebID the idea (rather than the technical protocol) = has been created within a context where linkability is desired, indeed = it's creation was to enable and promote increased linkability - so = applying it to situations where unlinkability is desired goes against = the grain, or clashes with individual's general mental model of it. >=20 > In it's simplest form, WebID is just a way to establish an identifier = for an agent layered on to the usual client cert auth. This allows: > - WebID to be used anywhere HTTP+TLS can be used > - Crucially, identifiers to be used that refer to resources anywhere = on the web which can be interacted with in order to find out more about = the agent identified. Without relying on fixed API features, multiple = protocols and layers, out of band knowledge, or limited functionality by = using non dereferencable identifiers. >=20 > So if wikileaks want to generate a cert with an identifier only they = can view and which is completely unlinkable, for a one time use, they = can. yes, but they had better use some other technology such as = TLS-Origin-Bound Certificates then. http://tools.ietf.org/agenda/81/slides/tls-1.pdf I am not even sure that is a good idea. Strong username passwords may = still be a lot better there, and suggesting strongly the user remember = it by heart. > If a bank wants to issue a series of certs to a client which has some = stable identifier in them for the client, they can. If facebook want to = issue certs which have identifiers which deref to a machine/human = readable version of the users profile, and allow people to use their = facebook id on any site, they can. If a single person wants to handle = their own identity and profile, they can. If services like AWS want to = issue keys to machine agents, they can. And critically, they'd all be = interoperable from a technical view, with limits to which identifiers = and keys and as to which information is visible and what can be used = where added on by ACL and usage restrictions. >=20 > It's quite simple really, client cert auth over TLS is well = established, and HTTP(s) URIs allow dereferencing to anything on the = web, with the possibility of any features you find anywhere on the web. >=20 > Seems far more logical and simpler than creating a plethora of custom = protocols which rely on layer upon layer of techs and protocols in order = to try and make non dereferencable identifiers dereferencable, or to try = and provide more information about an identified agent via a suite of = API extensions that need implemented by all adopters, or to come up with = something new which has most of the same negative sides, and requires = web scale adoption in order to work everywhere WebID already can. >=20 > Best, >=20 > Nathan +1 :-) Social Web Architect http://bblfish.net/ --Apple-Mail=_4D66E970-5676-43C8-9B12-0983F407E87A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINXzCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHIzCCBgug AwIBAgIDBNBjMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTIwODI5MDE0NTU2WhcNMTMwODMwMDkyMzQwWjBlMRkwFwYDVQQNExBrNDZ4OW85ckNETmZXMzBj MSAwHgYDVQQDDBdoZW5yeS5zdG9yeUBiYmxmaXNoLm5ldDEmMCQGCSqGSIb3DQEJARYXaGVucnku c3RvcnlAYmJsZmlzaC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsdekSaKJ8 5Km52QmfW8CcV1my5ou5hgtt1YvjujWsoP+SDz9ElSZMgzZqtrh78w7FHXqa7Z/IBxrcfVSghc01 cNthAO7Y+R8ug1IzkkYChht8HSdcEr/9l5yJ1Uxnx4TF3Tb+8XOjm+P2RA1oA9JiKuJ3nF7VxX1j VEWOUSjO5gBSFTzOLe1p/bYkzjmKLZisISBWMN17PzKKjRCgl4oQQvcmEvi2qmRt8g4eZ2IdjHTR LphwKiAN/FdzfM4neNwiP8XrV5cbWpZf+Wr1EDKgGNgctYTaIdA/B3O6bTe5ty85OWiGo5H79xXO /HXSXpsnjoqK19vJ1cyHwehjtBybAgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIE sDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFBFtP2rBFuUgj3GcA3YW UQxQPUtDMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMCIGA1UdEQQbMBmBF2hlbnJ5 LnN0b3J5QGJibGZpc2gubmV0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8w LgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwIC MIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRp ZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVx dWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRo ZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2Js aWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0 aW9uICJMZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAuP8DX1tEuYjuwx/SVVGt03bc25ELv9QVItkN9zGt HXA61CABusWUUtj462fpRZgiJZCm/a/k+WirD2sxqblbyx4LdNS3zdK2iFcKZnQQOYrzsh8HqSl3 sXAnREUYLGfbaE9TaS6GnaZuMnMJOt3eNaxfDrcxcNTMe65xYZfaZjUmL7NEQKHnrw3uJYDmOf2R ZP6HujvLApsdzioCeSyCEtgCdN+gLHUg+RPj/wDmF/fyKaF/01w0aJuu+397j2xpx/oaNEc63+U4 KsRfZ+HZi9MHmx0Qozm2MoIo2kVKqdEIqGxZn031k/uZFl8I4GMAyybcJbbKDCVZdzniWB+nVTGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwTQYzAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjEwMjMxMDE0 NTBaMCMGCSqGSIb3DQEJBDEWBBRoIjWITrCrAhvLQ3vS6t0rw5yDizCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwTQYzCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBNBjMA0GCSqGSIb3DQEBAQUABIIBAAY1 QeeWA+lYNoWmWGmSLD6akW2HZgoITOic29Muk5VhymIaXq4QtAwtmpY0mKexxVYbR3kPtGa2yfjR ZFN3hFdc6cjHU5G9yaQ9IkcuDrqT66paLHVL6eGpkAYPp/nk6JiZmw4hWss7FbyMd52/qfSVcDDc 0juWDzDH6GHnsJ6y6VFbeun9L7LWF/6YJj4q4F9lYd/tUwa32tNDM6d/s/iPTBMkFD5eNIqjwGBZ M9T7bJfFUrH+q6W2ukbZg1BDo5D5Zdf7FVggW1d0Kcl8ET73yvM/mDo77kGgoO5iRY8bwkAcUx2c xte2Uj4Awng0QSjaQCDS6N7oBUtoy1qecpAAAAAAAAA= --Apple-Mail=_4D66E970-5676-43C8-9B12-0983F407E87A-- From benl@google.com Tue Oct 23 03:50:17 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F8521F86CC for ; Tue, 23 Oct 2012 03:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OqP5ULpX91M for ; Tue, 23 Oct 2012 03:50:16 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5980621F86CB for ; Tue, 23 Oct 2012 03:50:16 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so2250022wey.31 for ; Tue, 23 Oct 2012 03:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=jrBv5t+DMbB9bMEIS6a1A0yfuPkB5UFGIZAtxH/XV50=; b=dF9d2vjBuxm3toxgNw7FrTU8Ic9pzEKkZaGXW0/ednBIZwfRYd76flxiDoW8qM70I+ rhgxFzsFZM/EzHOn7ZN39c5hYW8yuiBqEvDrNj/1gnvy7hF6CVz2wIF+CRzEPPc33UJ+ QZf/pZHX22CDFTeDgSoA3JRCn/zzYVV8mjZHGkFNV4G/feZmV/LjyTaOmwofuieFLphT nvvKcAmKJSMX+6SrZTzAgnXAkhDsG76599Nl3QIoKCApw3NKNopGc83rITjuMYOif/t2 /deifFgtRGE4TVlNPvQii38fhOV8K4zHZBCY6dPASH3sEzexpqwWQoCa8240oAyfVnhk GyNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=jrBv5t+DMbB9bMEIS6a1A0yfuPkB5UFGIZAtxH/XV50=; b=guBa24+mJDTDDmWgRPs12ltG4hIpHnewh5CqwA5V7M1QIMCd4LAdcoEHXJqYY76XA+ KHA3HSnLbEpse0hV4gUyAHaH8sEdb6c5F/DSuytW0MONPJERv/pZ0phd/l3nPmRsuOBX yDL+7C8AvHCDvglkRtFblImdNJ9IVy/akUP7uem69NNdstvf+YZWq0hYXL8rQ2hKSojc nvwDPnuYmRKIizI1A/u39pxtwFpnrrJf9EjKw+ygu8TMU9KLSIoqlkJYgnLn2UsJ6s4g Lb0g/1/xLCDT//2RXjfzMdJyW6va4/aDVmCGA0V/hAyaf9YX5oYvX5ZJaFGEipI+gs1L /iLA== MIME-Version: 1.0 Received: by 10.216.193.220 with SMTP id k70mr7796482wen.35.1350989414830; Tue, 23 Oct 2012 03:50:14 -0700 (PDT) Received: by 10.194.76.170 with HTTP; Tue, 23 Oct 2012 03:50:14 -0700 (PDT) In-Reply-To: <508669C5.90400@webr3.org> References: <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <5083CCCF.2060407@webr3.org> <50842789.3080301@openlinksw.com> <50845268.4010509@webr3.org> <5084AC77.8030600@openlinksw.com> <50851512.9090803@webr3.org> <50852726.9030102@openlinksw.com> <5085360E.3080008@openlinksw.com> <50853CD8.8020005@w3.org> <5FB468E4-BDD3-4635-ACD0-A23540C08751@bblfish.net> <508562C2.1060905@w3.org> <508669C5.90400@webr3.org> Date: Tue, 23 Oct 2012 11:50:14 +0100 Message-ID: From: Ben Laurie To: nathan@webr3.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQn6SgkMdcgBAAyagP6ltSPS5z23/cfoNhrNQKNajLjNVJru9kOgaekv6asIsku3jqbBt6ylYU5xdiRPEAQAhA8sVRG+E+CnZSMU3ss3l04ekImlaJ08GKCdIMLB80bOj5zxLw9ty65gE9v2zspSIubk2Igt5d9+r6gR1Jakecxt9knVAgGuRjURlLUTIRAEZJl8VMTY Cc: Halpin Harry , public-identity@w3.org, saag@ietf.org, "public-privacy@w3.org list" , public-webid@w3.org Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 10:50:17 -0000 On 23 October 2012 10:56, Nathan wrote: > Ben Laurie wrote: >> >> b) Linkability it not, as you say, inherently bad. The problem occurs >> when you have (effectively) no choice about linkability. > > > .. and when people convey or infer that there is no choice about > linkability, when there really is scope to be as unlinkable as one likes > within WebID. I have never disputed that - my point is that if I am as unlinkable as I like I then have a fairly horrific problem managing a large number of certificates and remembering which one I used where. From henry.story@bblfish.net Tue Oct 23 04:53:15 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4FE21F86D9 for ; Tue, 23 Oct 2012 04:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.245 X-Spam-Level: X-Spam-Status: No, score=-3.245 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hS2aqgXcJZUf for ; Tue, 23 Oct 2012 04:53:05 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id B4DB621F86CE for ; Tue, 23 Oct 2012 04:53:04 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so1592526eek.31 for ; Tue, 23 Oct 2012 04:53:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=npSHXF+ReBpkU1rJMKIS6Pc9gDBiLZo7Nltm57t9zJI=; b=ClME2wHmhBYaeJGKEsCjDwQy4+iDj6tX2mW2LoyAHhg1YRblRyfxJu1pjKGE0Rg8De nvJIvbX09iKXEt7PBt7G6anypjbnGaKejg8TlgQUT/FiO3bSOGmrpxeu0nTEp82G61P7 VTMXlfHWM+kc04/6qeWbxewA1a1yCigUUFEpozoSVWREMqu22kdw8im5pG8fh1HBnRqS y9FZm6bkkLaATCpvkpHCbX7q61vKMMSWJhpVv2DhVMvRy46VqyF6wjSRCD9HEIIQgbv4 E7z/d3naWhMYBxj3LapBapqhjoHsswFW/uqiJQPa5PmcV43UVWnq8RyzJW25zVPwZub2 6frw== Received: by 10.14.178.195 with SMTP id f43mr16506330eem.44.1350993183536; Tue, 23 Oct 2012 04:53:03 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-132-122.w86-198.abo.wanadoo.fr. [86.198.99.122]) by mx.google.com with ESMTPS id o47sm20501450eem.11.2012.10.23.04.52.51 (version=SSLv3 cipher=OTHER); Tue, 23 Oct 2012 04:53:01 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_96AE3CA2-5801-47FC-A377-FEC0E361081F"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Henry Story In-Reply-To: Date: Tue, 23 Oct 2012 13:52:49 +0200 Message-Id: <212677E1-8F0E-4005-8015-B4CD1233D67F@bblfish.net> References: <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <5083CCCF.2060407@webr3.org> <50842789.3080301@openlinksw.com> <50845268.4010509@webr3.org> <5084AC77.8030600@openlinksw.com> <50851512.9090803@webr3.org> <50852726.9030102@openlinksw.com> <5085360E.3080008@openlinksw.com> <50853CD8.8020005@w3.org> <5FB468E4-BDD3-4635-ACD0-A23540C08751@bblfish.net> <508562C2.1060905@w3.org> <508669C5.90400@webr3.org> To: Ben Laurie X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkzBWWU3+nJGEdKJhhqx3VHEqEotun1MqWX7CGqoUCCEa/FHBs/cBso7uJrT89V1Ziwq5IN Cc: Halpin Harry , nathan@webr3.org, public-identity@w3.org, saag@ietf.org, "public-privacy@w3.org list" , public-webid@w3.org Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 11:53:15 -0000 --Apple-Mail=_96AE3CA2-5801-47FC-A377-FEC0E361081F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 23 Oct 2012, at 12:50, Ben Laurie wrote: > On 23 October 2012 10:56, Nathan wrote: >> Ben Laurie wrote: >>>=20 >>> b) Linkability it not, as you say, inherently bad. The problem = occurs >>> when you have (effectively) no choice about linkability. >>=20 >>=20 >> .. and when people convey or infer that there is no choice about >> linkability, when there really is scope to be as unlinkable as one = likes >> within WebID. >=20 > I have never disputed that - my point is that if I am as unlinkable as > I like I then have a fairly horrific problem managing a large number > of certificates and remembering which one I used where. Yes, so browsers should in my view remember what selection you make when you go to a web site, and resend the same certificate the next time you = go there. Mind you - they should also show you that they have done this and allow you to change your previous choice - even if needed back to = anonymous. We argued this in a different thread on Transparency of Identity in the=20= browser - and there I pointed to work by Aza Raskin as a good example of what I meant http://www.azarask.in/blog/post/identity-in-the-browser-firefox/ This then leaves the issue of how to do this across browsers, and I = think there are a number of synchronisation "protocols" that could be = developed there. In my view the only protocol needed is HTTP here + an ontology for = bookmarks,=20 cookies, personas, etc... You give your browser your trusted home site = where you can POST, PUT, and GET all of these ids. A good protocol for this = would be the Atom protocol or better the in development linked data protocol http://dvcs.w3.org/hg/ldpwg/raw-file/a3be44430b37/ldp.html You probably don't need here to even save the certificates for each = site, you=20 just need to know if you authenticated there using a global id, a local = certificate,=20 or a password, and you could re-generate the identifiers. Well you have = a more=20 difficult time it is true for certificates bound to one site. And even = saving cookies is difficult because they may encode device type and screen size... So that's a lot of work to get done right. I don't have anything against = it being done. It could even be helpful for WebID... But as my priority is = building a=20 RESTful distributed social web, and as I am not employed by browser = vendors to work=20 on such a protocol, .... (I'll use it when its deployed) In short these issues seem to be orthogonal, and can be developed in = parallel. Henry Social Web Architect http://bblfish.net/ --Apple-Mail=_96AE3CA2-5801-47FC-A377-FEC0E361081F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINXzCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHIzCCBgug AwIBAgIDBNBjMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTIwODI5MDE0NTU2WhcNMTMwODMwMDkyMzQwWjBlMRkwFwYDVQQNExBrNDZ4OW85ckNETmZXMzBj MSAwHgYDVQQDDBdoZW5yeS5zdG9yeUBiYmxmaXNoLm5ldDEmMCQGCSqGSIb3DQEJARYXaGVucnku c3RvcnlAYmJsZmlzaC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsdekSaKJ8 5Km52QmfW8CcV1my5ou5hgtt1YvjujWsoP+SDz9ElSZMgzZqtrh78w7FHXqa7Z/IBxrcfVSghc01 cNthAO7Y+R8ug1IzkkYChht8HSdcEr/9l5yJ1Uxnx4TF3Tb+8XOjm+P2RA1oA9JiKuJ3nF7VxX1j VEWOUSjO5gBSFTzOLe1p/bYkzjmKLZisISBWMN17PzKKjRCgl4oQQvcmEvi2qmRt8g4eZ2IdjHTR LphwKiAN/FdzfM4neNwiP8XrV5cbWpZf+Wr1EDKgGNgctYTaIdA/B3O6bTe5ty85OWiGo5H79xXO /HXSXpsnjoqK19vJ1cyHwehjtBybAgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIE sDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFBFtP2rBFuUgj3GcA3YW UQxQPUtDMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMCIGA1UdEQQbMBmBF2hlbnJ5 LnN0b3J5QGJibGZpc2gubmV0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8w LgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwIC MIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRp ZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVx dWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRo ZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2Js aWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0 aW9uICJMZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAuP8DX1tEuYjuwx/SVVGt03bc25ELv9QVItkN9zGt HXA61CABusWUUtj462fpRZgiJZCm/a/k+WirD2sxqblbyx4LdNS3zdK2iFcKZnQQOYrzsh8HqSl3 sXAnREUYLGfbaE9TaS6GnaZuMnMJOt3eNaxfDrcxcNTMe65xYZfaZjUmL7NEQKHnrw3uJYDmOf2R ZP6HujvLApsdzioCeSyCEtgCdN+gLHUg+RPj/wDmF/fyKaF/01w0aJuu+397j2xpx/oaNEc63+U4 KsRfZ+HZi9MHmx0Qozm2MoIo2kVKqdEIqGxZn031k/uZFl8I4GMAyybcJbbKDCVZdzniWB+nVTGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwTQYzAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjEwMjMxMTUy NTBaMCMGCSqGSIb3DQEJBDEWBBR7amJoH/GAIE9RoS2ibnygWdNZlDCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwTQYzCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBNBjMA0GCSqGSIb3DQEBAQUABIIBAE7W X0d/wM9qFhzXLSeREhN/qXlI5+LF6msZKhaBvFqJallsEe7IDcn5CfAwIYW2D3QnMLOb6LLbyxaZ Edj/FTEnzvWnOAwfkhyQTSTkdE2jsn7OXyeCWJLJdOLnsMlIpEz7pGy/0nd7piRlAoNttgF3PoTs uzjRmLVNqPF6gBV0DrII0Z2WMHHkpkrHqDiQizUcI/2NkyqsLZGMG/4czC7Aqc03+pzhivcbA5ll WmU7mlWY4bAqHud/zWZ3T+BMxcAC1kwd33XyMwk155YehwJxz5Y4lQDLBuzRPrvy+aUTJXdz5Ybq oN98RalVzy0mGNsWdQfCGVuLZj7nQH1+zGsAAAAAAAA= --Apple-Mail=_96AE3CA2-5801-47FC-A377-FEC0E361081F-- From benl@google.com Tue Oct 23 05:04:07 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B31A21F8458 for ; Tue, 23 Oct 2012 05:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z92ZX3d20cog for ; Tue, 23 Oct 2012 05:04:06 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 986DD21F8453 for ; Tue, 23 Oct 2012 05:04:06 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so2108070wgb.13 for ; Tue, 23 Oct 2012 05:03:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=VE4a6WTEkTFQZzWezbx1WVILBVw2GG9SYCuXrv9FGi8=; b=EC7XIFK0chrPMo79f5jhJU/1ZP3nMj5gtrDxyvCB20Qy/WrrBsH7blZ9ooRrSg6v81 GFL7VUyUgyAP90pNesXeRcMcVWo160LL0Yj5BDiWjfkvk3fCdUTHrjVg6w0ZpvxrJCkE rdWQHEDnF7RBTM/NYObpPeBq1NDA/91iRxZqgXXAdHpd00/p6vwcpdSU0qJ0i6HZ1mVO CHXe20aM412/tkcgbtGo/tpTwO7Tojcof+WMu6tCjBxeEY31Sn+6Wte18pjeTnLn/oTA MnSZ4av3SaKMZC1w7DGpKA57c05iBz6i8uu7C8Q8QA3yF1jSbpEksgq4PA0mjMeWZkeV tdKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=VE4a6WTEkTFQZzWezbx1WVILBVw2GG9SYCuXrv9FGi8=; b=IB2P6dACDmbd2gWpmoTLiRIkmTuT6V0uxScqrMhBN0Uf73fjprUL3xMMaDsgyN2l+h V5zCOYErUvF9ZXxxLmxx4O7D5VMG09wCpH+V0ACR4pI9j47GrdU+BztrDuIZCHrH4Q0h IguzgksxhdvPWX935OD3hPb4KhDE7sD9VkgoVXzjRwbYk6tnJ8F2ScoBbfvWSVZZovX/ 6ldS92pj1jfyIO/oFVpLIU3l6z5HZKTzoB2EuIhfXd6wQYfR39MJjQO6gPl1PceykmjA GgR+hn9LrsUt50z0dX22Oqi8SRH7hOZ92gb8bQ7QhOvGDiBTvi6rj9eEjjb8dviOcR0J 7TBg== MIME-Version: 1.0 Received: by 10.216.140.205 with SMTP id e55mr7044855wej.2.1350993838268; Tue, 23 Oct 2012 05:03:58 -0700 (PDT) Received: by 10.194.76.170 with HTTP; Tue, 23 Oct 2012 05:03:58 -0700 (PDT) In-Reply-To: <508683A1.1050809@fcns.eu> References: <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <5083CCCF.2060407@webr3.org> <50842789.3080301@openlinksw.com> <50845268.4010509@webr3.org> <5084AC77.8030600@openlinksw.com> <50851512.9090803@webr3.org> <50852726.9030102@openlinksw.com> <5085360E.3080008@openlinksw.com> <50853CD8.8020005@w3.org> <5FB468E4-BDD3-4635-ACD0-A23540C08751@bblfish.net> <508562C2.1060905@w3.org> <508669C5.90400@webr3.org> <508683A1.1050809@fcns.eu> Date: Tue, 23 Oct 2012 13:03:58 +0100 Message-ID: From: Ben Laurie To: Andrei Sambra Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnc4NDPfIsWRyUY36og8c6T4HC3xhrgc3tRfVNSxluJe6o0B4K77Nt0Cfo9Wjv2vp3SjHBIrUFKdR7cFz9vqV9CwUzPpKhAW5IERwbWWqwWr4uTAbCnEo6XCztkwKaCp8FpUGDVCQJxGzSJSr87WzsIc3XvmO5bTBEgb+rnTaXuELofkCjmH0yL11H+cGv8POIw2bee Cc: Halpin Harry , nathan@webr3.org, public-identity@w3.org, saag@ietf.org, "public-privacy@w3.org list" , public-webid@w3.org Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 12:04:07 -0000 On 23 October 2012 12:46, Andrei Sambra wrote: > On 10/23/2012 12:50 PM, Ben Laurie wrote: >> >> On 23 October 2012 10:56, Nathan wrote: >>> >>> Ben Laurie wrote: >>>> >>>> >>>> b) Linkability it not, as you say, inherently bad. The problem occurs >>>> when you have (effectively) no choice about linkability. >>> >>> >>> >>> .. and when people convey or infer that there is no choice about >>> linkability, when there really is scope to be as unlinkable as one likes >>> within WebID. >> >> >> I have never disputed that - my point is that if I am as unlinkable as >> I like I then have a fairly horrific problem managing a large number >> of certificates and remembering which one I used where. >> > > Wouldn't you say you have the same problem now with most, if not all > authentication protocols? Yes. > I still think it's easier to manage 100s of > certificates compared to managing 100s of user/pass combinations. > > If it is a UI issue, then it can be made more intuitive. From what you say > above, the WebID protocol itself is not the problem. Well. There are certainly protocols that reduce this particular problem, in particular those that use selective disclosure or zero knowledge to solve the linkability issue without requiring a plethora of keys. > > Andrei > > P.S. I've been trying to follow this conversation and so far it's been a > pain in the @$$. W3C should have a way to separate threads based on > relevance to one's interests, otherwise it becomes very hard to be > productive when you have to read though so many emails daily. From bkihara.l@gmail.com Tue Oct 23 07:29:14 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05EC21F8504; Tue, 23 Oct 2012 07:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.164 X-Spam-Level: X-Spam-Status: No, score=-3.164 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXqPB4qtQrSs; Tue, 23 Oct 2012 07:29:14 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 299E121F84F5; Tue, 23 Oct 2012 07:29:13 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so4730212vbb.31 for ; Tue, 23 Oct 2012 07:29:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=PCaES+dDQ1h6RuLoLN35zgu89YJhxH4Fjb9hMFONA70=; b=lZpHxTHOvyZmMFTHdpW4LUlUhXNEVQ3wwG7kTqvc68i1BVCp5gveepu/e0/FLRH3xp zCKwyzsCIYEtdfEJIxi+Jrzo4poJ9Fa7pdfHdIZf0GJhuFllTVvhFMpSs5PCGk0h3IiA GKtROBmw2UYsoI5cH5JW3ZbwV8PAZiRbsVzRs2HpP9pzPF8LQohE5l/GRxytn7ynkXWl ZGJ8KGncOl+pCzcqfsvgIB0xEMh1L/T5zTP1yJaxy+1/17Z59D/6WMsGq/wImEnfOmhf gOV7zgKJhog2Y/0MnUHHAVvihdgzQ7SCKJJCCQx6Ydjn5Yh0chO7/MTCvawoYd5YEOPx z0xA== MIME-Version: 1.0 Received: by 10.52.22.72 with SMTP id b8mr16893649vdf.88.1351002553111; Tue, 23 Oct 2012 07:29:13 -0700 (PDT) Received: by 10.58.221.33 with HTTP; Tue, 23 Oct 2012 07:29:13 -0700 (PDT) Date: Tue, 23 Oct 2012 23:29:13 +0900 Message-ID: From: "KIHARA, Boku" To: apps-discuss@ietf.org, saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [saag] Considerations for Protocols with Compression over TLS X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 14:29:14 -0000 Hello, I'm writing a draft on cosiderations for protocols with compression over TLS, since I was shocked by the CRIME attack. http://tools.ietf.org/html/draft-kihara-compression-considered-harmful-01 What I want to say are: * the CRIME attack may be applied if compression is applied in any form * disabling TLS Compression and SPDY header compression is not a perfect solution; the threat has not gone! * there should be some mitigations to take when using compression in TLS Because I am neither a cryptographer nor a security expert there must many mistakes in the draft in addition to language faults, but I think it is good that we have some guides for comression in TLS. Is IETF the write place to do such things? Regards, Boku Kihara. From melvincarvalho@gmail.com Mon Oct 22 08:25:29 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D803021F8C52 for ; Mon, 22 Oct 2012 08:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hQQxcltTOPX for ; Mon, 22 Oct 2012 08:25:26 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6F31921F8C09 for ; Mon, 22 Oct 2012 08:25:26 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so2573384iad.31 for ; Mon, 22 Oct 2012 08:25:22 -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=9TBiweNlQJgatBKvXqPLl5UzsXDfQEFZ5+YReX1Kj1Q=; b=Q7OY3eemCZDEwPPG1QYnfglZQc8OYj9v+RJ2k8FvDDJdXfe5iMyDg0VzhldNYxmdKt U0+mi6e4glwGpmw02YVEkLU0MCzVVK7ZhzL6tvC7GvU2TrAmGAIzYYVuzxrcKnBH9fxl z19t3DWm71KokM4kAHeCAfE+MO6pLD6d0RZamLPrlADQpUMooiXfL0eC5kBaZ8cKXfpl k88eA3IVSekrHpB5sVMJw5rTd6niI9Ld8/+pnApF8ctyJyR6mlB3cOVYTGGwhp3kFW0D ohZIfAIMBWJ9emRlVCg4NLugKWv1ZqEGHdeBVdNUvvSzFKAdNRonysWj9YzHk7TCb7jZ ejNQ== MIME-Version: 1.0 Received: by 10.50.91.168 with SMTP id cf8mr16601802igb.20.1350919521737; Mon, 22 Oct 2012 08:25:21 -0700 (PDT) Received: by 10.42.247.129 with HTTP; Mon, 22 Oct 2012 08:25:21 -0700 (PDT) In-Reply-To: <508562C2.1060905@w3.org> References: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <5083CCCF.2060407@webr3.org> <50842789.3080301@openlinksw.com> <50845268.4010509@webr3.org> <5084AC77.8030600@openlinksw.com> <50851512.9090803@webr3.org> <50852726.9030102@openlinksw.com> <5085360E.3080008@openlinksw.com> <50853CD8.8020005@w3.org> <5FB468E4-BDD3-4635-ACD0-A23540C08751@bblfish.net> <508562C2.1060905@w3.org> Date: Mon, 22 Oct 2012 17:25:21 +0200 Message-ID: From: Melvin Carvalho To: Harry Halpin Content-Type: multipart/alternative; boundary=e89a8f3b9d3d369d5f04cca7763e X-Mailman-Approved-At: Tue, 23 Oct 2012 14:09:57 -0700 Cc: public-identity@w3.org, saag@ietf.org, "public-privacy@w3.org list" , public-webid@w3.org Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 15:25:29 -0000 --e89a8f3b9d3d369d5f04cca7763e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 22 October 2012 17:14, Harry Halpin wrote: > On 10/22/2012 04:04 PM, Henry Story wrote: > >> On 22 Oct 2012, at 14:32, Harry Halpin wrote: >> >> On 10/22/2012 02:03 PM, Kingsley Idehen wrote: >>> >>>> On 10/22/12 7:26 AM, Ben Laurie wrote: >>>> >>>>> On 22 October 2012 11:59, Kingsley Idehen >>>>> wrote: >>>>> >>>>>> On 10/22/12 5:54 AM, Ben Laurie wrote: >>>>>> >>>>>>> Where we came in was me pointing out that if you disconnect your >>>>>>> identities by using multiple WebIDs, then you have a UI problem, an= d >>>>>>> since then the aim seems to have been to persuade us that multiple >>>>>>> WebIDs are not needed. >>>>>>> >>>>>> Multiple WebIDs (or any other cryptographically verifiable >>>>>> identifier) are a >>>>>> must. >>>>>> >>>>>> The issue of UI is inherently subjective. It can't be used to >>>>>> objectively >>>>>> validate or invalidate Web-scale verifiable identifier systems such = as >>>>>> WebID or any other mechanism aimed at achieving the same goals. >>>>>> >>>>> Ultimately what matters is: do users use it correctly? This can be >>>>> tested :-) >>>>> >>>>> Note that it is necessary to test the cases where the website is evil= , >>>>> too - something that's often conveniently missed out of user testing. >>>>> For example, its pretty obvious that OpenID fails horribly in this >>>>> case, so it tends not to get tested. >>>>> >>>> Okay. >>>> >>>>> Anyway, Henry, I, and a few others from the WebID IG (hopefully) are >>>>>> going >>>>>> to knock up some demonstrations to show how this perceived UI/UX >>>>>> inconvenience can be addressed. >>>>>> >>>>> Cool. >>>>> >>>> Okay, ball is in our court to now present a few implementations that >>>> address the UI/UX concerns. >>>> >>>> Quite relieved to have finally reached this point :-) >>>> >>> No, its not a UI/UX concern, although the UI experience of both identit= y >>> on the Web and with WebID in particular is quite terrible, I agree. >>> >> It completely depends on the browsers: >> http://www.w3.org/wiki/Foaf%**2Bssl/Clients/CertSelection >> If you are on Linux just file a bug request to your browser if you are >> unhappy, or even better hack up a good UI. It's easy: just make it simpl= er. >> >> My earlier concern was an information flow concern that causes the issu= e >>> with linkability, which WebID shares to a large extent with other >>> server-side information-flow. >>> >> Including BrowserId. Which has 2 tokens that can be used to identify the >> user across sites: >> >> - an e-mail address ( useful for spamming ) >> - a public key, which can be used to authenticate across sites >> >> >> As stated earlier, as long as you trust the browser, BrowserID does >>> ameliorate this. >>> >> No it does not improve linkability at all. Certainly not if you think th= e >> site you are authenticating to is the one you should be worried about, >> because just using a public key >> by itself is enough for Linkability in the strict (paranoid) sense. That >> is if you >> consider the site you are logging into to as the attacker, then by givin= g >> two sites >> a public key where you have proven you control the private key is enough >> for them to know that >> the same agent visited both sites. That is because the cert:key relation >> is inverse functional. >> >> So in simple logical terms if you go to site1.org and identify with a >> public key pk, >> and they create a local identifier for you , and >> then you go site s2.net and identify with the same public key pk and >> they give you an identifier >> (these need not be public) and then they exchange their information, the= n >> each of the sites would have the following relations ( written in >> http://www.w3.org/TR/Turtle ) >> >> @prefix cert: >> > >> >> cert:key pk . >> cert:key pk . >> >> because cert:key is defined as an InverseFunctionalProperty >> ( as you can see by going http://www.w3.org/ns/auth/**cert#key) >> >> Then it follows from simple owl reasoning that >> >> =3D=3D . >> >> One cannot get much simpler logical reasoning that this, Harry. >> >> >> There is also this rather odd conflation of "linkability" of URIs with >>> hypertext and URI-enabled Semantic Web data" and linkability as a priva= cy >>> concern. >>> >> I am not conflating these. >> > To quote the IETF document I seem to have unsuccessfully suggested you > read a while back, the linkability of two or more Items Of Interest (e.g.= , > subjects, messages, actions, ...) from an attacker's perspective means > that within a particular set of information, the attacker can distinguis= h > whether these IOIs are related or not (with a high enough degree of > probability to be useful) [1]. If you "like linkability", that's great, b= ut > probably many use-cases aren't built around liking linkability. > Harry, this document has been discussed in detail in the WebID group. Thank you for bringing it to our attention. I cant help but reflect at this point, that the only reason, that this conversation has been made possible, is due to the "linkability" property of the e-mail protocol. :) > This has very little with hypertext linking of web-pages via URIs. I > think you want to use the term "trust across different sites" rather than > linkability, although I see how WebID wants to conflate that with trust, > which no other identity solution does. A link does not necessarily mean > trust, especially if links aren't bi-directional. > > As explained earlier, Mozilla Personae/BrowserID uses digital signatures > where an IDP signs claims but transfers that claim to the RP via the > browser (thus the notion of "different information flow") and thus the RP > and IDP do not directly communicate, reducing the linkability of the data > easily gathered by the IDP (not the RP). > > I know WebID folks believe IDP =3D my homepage, but for most people IDP > would likely not be a homepage, but a major identity provider for which > data minimization principles should apply, including ownership of the > social network data of an individual and a history of their interactions > with every RP. I am not defending BrowerID per se: Personae assumes you > trust the browser, which some people don't. Also, email verification, whi= le > common, is not great from a security perspective, i.e. STARTLS not giving > error messages when it degrades. > > Perhaps a more productive question would be why would someone use WebID > rather than OpenID Connect with digital signatures? > > Although, I have ran out of time for this for the time being. > > > >> My point from the beginning is that Linkability is both a good thing and >> a bad thing. >> >> As a defender of BrowserId you cannot consistently attack WebID for >> linkability concerns and find BrowserId not to have that same problem. S= o I >> hate to reveal this truth to you: but we have to fight this battle toget= her. >> >> And the battle is simple: the linkability issue is only an issue if you >> think the site you >> are authenticating to is the enemy. If you believe that you are in >> relation with a site that >> is under a legal and moral duty to be respectful of the communication yo= u >> are having with it, >> then you will find that the linkability of information with that site an= d >> across sites is exactly what you want in order to reduce privacy issues >> that arise out of centralised systems. >> >> I do think many people agree stronger cryptographic credentials for >>> authentication are a good thing, and BrowserID is based on this and Ope= nID >>> Connect has (albeit not often used) options in this space. I would aga= in, >>> please suggest that the WebID community take on board comments in a pol= ite >>> manner and not cc mailing lists. >>> >> All my communications have been polite, and I don't know why you select >> out the WebID community. >> As for taking on board comments, why, just the previous e-mail you >> responded to was a demonstration that we are: CN=3DWebID,O=3D=E2=88=85 >> >> >> >> >>>> >>>> Social Web Architect >> http://bblfish.net/ >> >> > > --e89a8f3b9d3d369d5f04cca7763e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 22 October 2012 17:14, Harry Halpin <= span dir=3D"ltr"><hh= alpin@w3.org> wrote:
On 10/22/2012 04:04 PM, Henry Story= wrote:
On 22 Oct 2012, at 14:32, Harry Halpin <hhalpin@w3.org> wrote:

On 10/22/2012 02:03 PM, Kingsley Idehen wrote:
On 10/22/12 7:26 AM, Ben Laurie wrote:
On 22 October 2012 11:59, Kingsley Idehen <kidehen@openlinksw.com> wrote:
On 10/22/12 5:54 AM, Ben Laurie wrote:
Where we came in was me pointing out that if you disconnect your
identities by using multiple WebIDs, then you have a UI problem, and
since then the aim seems to have been to persuade us that multiple
WebIDs are not needed.
Multiple WebIDs (or any other cryptographically verifiable identifier) are = a
must.

The issue of UI is inherently subjective. It can't be used to objective= ly
validate or invalidate Web-scale verifiable identifier systems such as
WebID or any other mechanism aimed at achieving the same goals.
Ultimately what matters is: do users use it correctly? This can be tested := -)

Note that it is necessary to test the cases where the website is evil,
too - something that's often conveniently missed out of user testing. For example, its pretty obvious that OpenID fails horribly in this
case, so it tends not to get tested.
Okay.
Anyway, Henry, I, =C2=A0and a few others from the WebID IG (hopefully) are = going
to knock up some demonstrations to show how this perceived UI/UX
inconvenience can be addressed.
Cool.
Okay, ball is in our court to now present a few implementations that addres= s the UI/UX concerns.

Quite relieved to have finally reached this point :-)
No, its not a UI/UX concern, although the UI experience of both identity on= the Web and with WebID in particular is quite terrible, I agree.
It completely depends on the browsers:
http://www.w3.org/wiki/Foaf%2Bssl/Clients/CertSelection<= /a>
If you are on Linux just file a bug request to your browser if you are unha= ppy, or even better hack up a good UI. It's easy: just make it simpler.=

My earlier concern was an information flow concern that causes the issue wi= th linkability, which WebID shares to a large extent with other server-side= information-flow.
Including BrowserId. Which has 2 tokens that can be used to identify the us= er across sites:

=C2=A0 =C2=A0- an e-mail address ( useful for spamming )
=C2=A0 =C2=A0- a public key, which can be used to authenticate across sites=


As stated earlier, as long as you trust the browser, BrowserID does amelior= ate this.
No it does not improve linkability at all. Certainly not if you think the s= ite you are authenticating to is the one you should be worried about, becau= se just using a public key
by itself is enough for Linkability in the strict (paranoid) sense. That is= if you
consider the site you are logging into to as the attacker, then by giving t= wo sites
a public key where you have proven you control the private key is enough fo= r them to know that
the same agent visited both sites. That is because the cert:key relation is= inverse functional.

So in simple logical terms if you go to site1.org and identify with a public key pk,
and they create a local identifier for you <http://site1.org/u123>, and then you go site= s2.net and identify with t= he same public key pk =C2=A0and they give you an identifier <http://s2.net/lsdfs>
(these need not be public) and then they exchange their information, then e= ach of the sites would have the following relations ( written in http://www.w3.org/TR/Turtle= )

=C2=A0 @prefix cert: <http://www.w3.org/ns/auth/cert#>

=C2=A0 <http://site1= .org/u123> cert:key pk .
=C2=A0 <http://s2.net/= lsdfs> =C2=A0 cert:key pk .

because cert:key is defined as an InverseFunctionalProperty
( as you can see by going http://www.w3.org/ns/auth/cert#key )

Then it follows from simple owl reasoning that

=C2=A0 =C2=A0<http:/= /site1.org/u123> =3D=3D <http://s2.net/lsdfs> .

One cannot get much simpler logical reasoning that this, Harry.


There is also this rather odd conflation of "linkability" of URIs= with hypertext and URI-enabled Semantic Web data" and linkability as = a privacy concern.
I am not conflating these.
To quote the IETF document I seem to have unsuccessfully suggested you read= a while back, the linkability of two or more Items Of Interest (e.g., subj= ects, messages, actions, ...) from an attacker's perspective =C2=A0mean= s that within a particular set of information, the attacker =C2=A0can disti= nguish whether these IOIs are related or not (with a high enough degree of = probability to be useful) [1]. If you "like linkability", that= 9;s great, but probably many use-cases aren't built around liking linka= bility.

Harry, this document has been discussed in detail in = the WebID group.=C2=A0 Thank you for bringing it to our attention.

I= cant help but reflect at this point, that the only reason, that this conve= rsation has been made possible, is due to the "linkability" prope= rty of the e-mail protocol. :)


=C2=A0This has very little with hypertext linking of web-pages via URIs. I = think you want to use the term "trust across different sites" rat= her than linkability, although I see how WebID wants to conflate that with = trust, which no other identity solution does. =C2=A0A link does not necessa= rily mean trust, especially if links aren't bi-directional.

As explained earlier, Mozilla Personae/BrowserID uses digital signatures wh= ere an IDP signs claims but transfers that claim =C2=A0to the RP via the br= owser (thus the notion of "different information flow") and thus = the RP and IDP do not directly communicate, reducing the linkability of the= data easily gathered by the IDP (not the RP).

I know WebID folks believe IDP =3D my homepage, but for most people IDP wou= ld likely not be a homepage, but a major identity provider for which data m= inimization principles should apply, including ownership of the social netw= ork data of an individual and a history of their interactions with every RP= . I am not defending BrowerID per se: Personae assumes you trust the browse= r, which some people don't. Also, email verification, while common, is = not great from a security perspective, i.e. STARTLS not giving error messag= es when it degrades.

Perhaps a more productive question would be why would someone use WebID rat= her than OpenID Connect with digital signatures?

Although, I have ran out of time for this for the time being.



My point from the beginning is that Linkability is both a good thing and a = bad thing.

As a defender of BrowserId you cannot consistently attack WebID for linkabi= lity concerns and find BrowserId not to have that same problem. So I hate t= o reveal this truth to you: but we have to fight this battle together.

And the battle is simple: the linkability issue is only an issue if you thi= nk the site you
are authenticating to is the enemy. If you believe that you are in relation= with a site that
is under a legal and moral duty to be respectful of the communication you a= re having with it,
then you will find that the linkability of information with that site and a= cross sites is exactly what you want in order to reduce privacy issues that= arise out of centralised systems.

I do think many people agree stronger cryptographic credentials for authent= ication are a good thing, and BrowserID is based on this and OpenID Connect= has (albeit not often used) options in this space. =C2=A0I would again, pl= ease suggest that the WebID community take on board comments in a polite ma= nner and not cc mailing lists.
All my communications have been polite, and I don't know why you select= out the WebID community.
As for taking on board comments, why, just the previous e-mail you responde= d to was a demonstration that we are: CN=3DWebID,O=3D=E2=88=85





Social Web Architect
http://bblfish.net/



--e89a8f3b9d3d369d5f04cca7763e-- From danbri@danbri.org Mon Oct 22 10:31:31 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757B311E80DE for ; Mon, 22 Oct 2012 10:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhE1BdN4zQI5 for ; Mon, 22 Oct 2012 10:31:29 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9767911E80A5 for ; Mon, 22 Oct 2012 10:31:29 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so2164934pbb.31 for ; Mon, 22 Oct 2012 10:31:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=D+hbFKa6JxgF2qEttg6PSP+L0+nAZ340AidPHWTynY4=; b=ftbwUiMtXlFO+S7H0q5v4SXSJoa9ckLKGhfZpKhgCmPlGQYyoCXBoks9MtZJfPi6UO rf+RBHNFUv2AAdp8aqe0lzSPDpfS56ueuJUG1cjv/Jw93Ks5/sqcxMEyx/gjkgtPzchs 25cUVFWqL+UNCDC1AdhNqnRbIyUvcUtC7rwxid1ctt5ErObqctw1hwxsaV/cDsSeHqKt hL40sC//CCKoxQSd3kkxyZlS8HRP8pA56TldrDkHa5S5sZEXijYEfpPzuMFOX6IqXGyq VGxGZB4d9XzUplDA3owcjpMTioQop3hOcSUYec4TJjAwXAKAKx3LXJSluDoFaIvOatm2 GQQA== MIME-Version: 1.0 Received: by 10.68.213.1 with SMTP id no1mr31774663pbc.123.1350927089229; Mon, 22 Oct 2012 10:31:29 -0700 (PDT) Received: by 10.68.241.226 with HTTP; Mon, 22 Oct 2012 10:31:28 -0700 (PDT) Received: by 10.68.241.226 with HTTP; Mon, 22 Oct 2012 10:31:28 -0700 (PDT) In-Reply-To: <508562C2.1060905@w3.org> References: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <5083CCCF.2060407@webr3.org> <50842789.3080301@openlinksw.com> <50845268.4010509@webr3.org> <5084AC77.8030600@openlinksw.com> <50851512.9090803@webr3.org> <50852726.9030102@openlinksw.com> <5085360E.3080008@openlinksw.com> <50853CD8.8020005@w3.org> <5FB468E4-BDD3-4635-ACD0-A23540C08751@bblfish.net> <508562C2.1060905@w3.org> Date: Mon, 22 Oct 2012 10:31:28 -0700 Message-ID: From: Dan Brickley To: Harry Halpin Content-Type: multipart/alternative; boundary=e89a8ff1c6ba455e1d04cca9399b X-Gm-Message-State: ALoCoQkEkartrz/qhmCEbDT9DPpwX+RRw8CUMhkO5dMIVWoDjR6NZ8j5I8u3NM5QwYSV1u+9jeY3 X-Mailman-Approved-At: Tue, 23 Oct 2012 14:09:57 -0700 Cc: public-identity@w3.org, saag@ietf.org, "public-privacy, \(W3C mailing list\)" , public-webid@w3.org Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 17:31:31 -0000 --e89a8ff1c6ba455e1d04cca9399b Content-Type: text/plain; charset=UTF-8 On 22 Oct 2012 08:14, "Harry Halpin" wrote: > > On 10/22/2012 04:04 PM, Henry > I know WebID folks believe IDP = my homepage, but for most people IDP would likely not be a homepage, but a major identity provider for which data minimization principles should apply, including ownership of the social network data of an individual and a history of their interactions with every RP. Is there some reason it is implausible to assume homepages will never be backed by major identity providers? Specifically, user-controlled DNS names, but resolving to more sophisticated hosting than old-style homepages.... Dan --e89a8ff1c6ba455e1d04cca9399b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 22 Oct 2012 08:14, "Harry Halpin" <hhalpin@w3.org> wrote:
>
> On 10/22/2012 04:04 PM, Henry

> I know WebID folks believe IDP =3D my homepage, but for= most people IDP would likely not be a homepage, but a major identity provi= der for which data minimization principles should apply, including ownershi= p of the social network data of an individual and a history of their intera= ctions with every RP.

Is there some reason it is implausible to assume homepages w= ill never be backed by major identity providers? Specifically, user-control= led DNS names, but resolving to more sophisticated hosting than old-style h= omepages....

Dan

--e89a8ff1c6ba455e1d04cca9399b-- From d.w.chadwick@kent.ac.uk Mon Oct 22 10:41:47 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA95821F889F for ; Mon, 22 Oct 2012 10:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id widex9G9JiGZ for ; Mon, 22 Oct 2012 10:41:46 -0700 (PDT) Received: from mx2.kent.ac.uk (mx2.kent.ac.uk [129.12.21.33]) by ietfa.amsl.com (Postfix) with ESMTP id 89BFB21F84FE for ; Mon, 22 Oct 2012 10:41:46 -0700 (PDT) Received: from edudb9b.kent.ac.uk ([129.12.219.155]) by mx2.kent.ac.uk with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72) (envelope-from ) id 1TQM0S-0004ey-Os; Mon, 22 Oct 2012 18:41:40 +0100 Message-ID: <50858554.1070103@kent.ac.uk> Date: Mon, 22 Oct 2012 18:41:40 +0100 From: David Chadwick User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Ben Laurie References: <88F98DFD-EF7D-4444-A9C2-FB8E15F5DA89@bblfish.net> <3757D928-C3AE-4630-98E7-E30B5CC604B0@cisco.com> <7E1636E02F313F4BA69A428B314B77C708217189@xmb-aln-x12.cisco.com> <7ABCD095-4B09-40DD-A084-1BBE761CA72F@bblfish.net> <50805611.2000904@kent.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 23 Oct 2012 14:09:57 -0700 Cc: "public-philoweb@w3.org" , "public-identity@w3.org" , "saag@ietf.org" , "public-privacy@w3.org" , "Klaas Wierenga \(kwiereng\)" , "public-webid@w3.org" Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 17:41:48 -0000 On 22/10/2012 17:58, Ben Laurie wrote: > On Thu, Oct 18, 2012 at 8:18 PM, David Chadwick wrote: >> Hi Ben >> >> I disagree. It depends upon your risk assessment. Your stand is like saying >> TLS should be the substrate, not http. > > Not at all. You can add security to an insecure connection. You cannot > add anonymity to an identified session. Once you have a session you have linkability. So if you want unlinkability there can be no concept of a session, which by its very nature, links a series of messages together. So when you want anonymity you switch from your existing session to using TOR or some other privacy protecting mechanism. regards David My stand is, in fact, like > saying that TCP should be the substrate, not TLS. > >> There are two alternative viewpoints. >> You can either start with the lowest security/privacy and add to it, or make >> the highest security/privacy the default and then take from it. So you >> should not necessarily mandate that U-Prove/Idemix are the default tokens, >> but rather only require them if your risk assessment says privacy protection >> is essential >> >> regards >> >> David >> >> >> On 18/10/2012 16:34, Ben Laurie wrote: >>> >>> On 9 October 2012 14:19, Henry Story wrote: >>>> >>>> Still in my conversations I have found that many people in security >>>> spaces >>>> just don't seem to be able to put the issues in context, and can get >>>> sidetracked >>>> into not wanting any linkability at all. Not sure how to fix that. >>> >>> >>> You persist in missing the point, which is why you can't fix it. The >>> point is that we want unlinkability to be possible. Protocols that do >>> not permit it or make it difficult are problematic. I have certainly >>> never said that you should always be unlinked, that would be stupid >>> (in fact, I once wrote a paper about how unpleasant it would be). >>> >>> As I once wrote, anonymity should be the substrate. Once you have >>> that, you can the build on it to be linked when you choose to be, and >>> not linked when you choose not to be. If it is not the substrate, then >>> you do not have this choice. >>> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > From mnot@mnot.net Mon Oct 22 15:31:39 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774E211E80E0 for ; Mon, 22 Oct 2012 15:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.044 X-Spam-Level: X-Spam-Status: No, score=-104.044 tagged_above=-999 required=5 tests=[AWL=-1.445, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eD2Bz+no6CIz for ; Mon, 22 Oct 2012 15:31:38 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id A149C11E80E7 for ; Mon, 22 Oct 2012 15:31:38 -0700 (PDT) Received: from [192.168.1.72] (unknown [118.209.87.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4A96122DD6D for ; Mon, 22 Oct 2012 18:31:31 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: Date: Tue, 23 Oct 2012 09:31:30 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <4B8D0A93-3838-4CDB-939B-1183718EFFFE@mnot.net> References: To: saag@ietf.org X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Tue, 23 Oct 2012 14:09:57 -0700 Subject: Re: [saag] Input for conflict review of draft-secure-cookie-session-protocol X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 22:31:39 -0000 As far as I can tell, this document specifies some extensions to the = Cookie / Set-Cookie (RFC6265), and/or "squats" on some pre-defined = cookie names. It's hard to tell, both because of how the draft is = written, and because I read it very quickly. 6265 doesn't define how it's to be extended very well (possibly because = the underlying assumption is that extensions are VERY difficult to = deploy). However, the precedent of an independent stream RFC defining = such extensions, or worse "squatting" on the cookie name space (which is = very widely used and thus very difficult to guarantee an absence of = conflict) is concerning. It seems to me that this *might* therefore conflict with the (previous) = HTTPSTATE WG's work.=20 Cheers, On 18/10/2012, at 1:25 PM, Barry Leiba wrote: > A document titled "Secure Cookie Sessions for HTTP" has been submitted > to the Independent Stream Editor (ISE): > http://datatracker.ietf.org/doc/draft-secure-cookie-session-protocol/ >=20 > The IESG has been asked to review the document, as specified in RFC > 5742, Section 3. The Security and Applications Area Directors are > looking for input for that review. Please post any relevant comments > to the Security Area list, , as soon as possible, and = at > least by 1 November 2012. >=20 > Note: Please do NOT post responses to any of these mailing lists. > Respond only to (using the subject line of this > message). >=20 > Please read RFC 5742, Section 3, and be aware that we are not looking > for detailed comments on the document itself (see below). We > specifically need input on whether this document is in conflict with > work that's being done in the IETF. Look at the five possible > responses specified in that section, and help us determine whether any > of 2 through 5 applies. Please be specific in your response. >=20 > In addition to this, we're sure that the authors and the ISE would > appreciate comments about the document. If you have those, you may > send them directly to the authors at > > and to the ISE at . > General discussion of the document on these lists or the saag list = will > likely not get to the authors or the ISE. >=20 > Barry Leiba, Applications AD >=20 -- Mark Nottingham http://www.mnot.net/ From nathan@webr3.org Tue Oct 23 02:56:58 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44DCD21F8670 for ; Tue, 23 Oct 2012 02:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MT2gSNS1Pn1E for ; Tue, 23 Oct 2012 02:56:57 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 03C3D21F8659 for ; Tue, 23 Oct 2012 02:56:56 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so2049344wgb.13 for ; Tue, 23 Oct 2012 02:56:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=cYXvRS5FCTPUluZohPZseo8EJYPWzs2IF5gjgJ8kPl0=; b=ICbb7vVhaOh2Uxc3UZrbKOrmRG0FvEkXVSnaLwTuJ5lde8qE2o5obF2xa66t3j1BNO giRj3VXbuaSDM1gbI0lP6qMQ+8+SRNu+g4i7Mchh7/aH620eCdE1OXW6aKKihpwCUbls 07kK8JUyHLPdv7hVKH/KSlRSQmeBiY4faZrCMqRNbgx9miht1qewaeVEoSaPb3GoHEpz iUsYMH5jxnfU58wCZr+zb79W98AcanaiGsS7Ox9RVEoQ3q6A1vJTQ+Zi0lo3RNlGqAlY PB0dMTJKSU7iOb3RWTja6o+rhSWLy2fEzsxMlxlgxVdhkGiQ6T8GtwvC+b2P+i+EMSHz fVAQ== Received: by 10.216.203.148 with SMTP id f20mr6966587weo.181.1350986216071; Tue, 23 Oct 2012 02:56:56 -0700 (PDT) Received: from [192.168.1.69] (host217-44-74-203.range217-44.btcentralplus.com. [217.44.74.203]) by mx.google.com with ESMTPS id cu1sm55511475wib.6.2012.10.23.02.56.54 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Oct 2012 02:56:55 -0700 (PDT) Message-ID: <508669C5.90400@webr3.org> Date: Tue, 23 Oct 2012 10:56:21 +0100 From: Nathan Organization: webr3 User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Ben Laurie References: <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <5083CCCF.2060407@webr3.org> <50842789.3080301@openlinksw.com> <50845268.4010509@webr3.org> <5084AC77.8030600@openlinksw.com> <50851512.9090803@webr3.org> <50852726.9030102@openlinksw.com> <5085360E.3080008@openlinksw.com> <50853CD8.8020005@w3.org> <5FB468E4-BDD3-4635-ACD0-A23540C08751@bblfish.net> <508562C2.1060905@w3.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnrjTjvyNaIPIq2Eexqupe1FGq7C+P1SvjunEhKGv/HzxdpWszdMl3mtC4mKwqNOLX37/BN X-Mailman-Approved-At: Tue, 23 Oct 2012 14:09:57 -0700 Cc: Halpin Harry , public-identity@w3.org, saag@ietf.org, "public-privacy@w3.org list" , public-webid@w3.org Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: nathan@webr3.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 09:56:58 -0000 Ben Laurie wrote: > b) Linkability it not, as you say, inherently bad. The problem occurs > when you have (effectively) no choice about linkability. .. and when people convey or infer that there is no choice about linkability, when there really is scope to be as unlinkable as one likes within WebID. Quite convinced now that the confusion is just differing objectives and opinions, and nothing technical. You can have one or more WebIDs to cover any combination of one or more requests to one or more resources. Be as linkable or unlinkable as you like. On the other hand, WebID the idea (rather than the technical protocol) has been created within a context where linkability is desired, indeed it's creation was to enable and promote increased linkability - so applying it to situations where unlinkability is desired goes against the grain, or clashes with individual's general mental model of it. In it's simplest form, WebID is just a way to establish an identifier for an agent layered on to the usual client cert auth. This allows: - WebID to be used anywhere HTTP+TLS can be used - Crucially, identifiers to be used that refer to resources anywhere on the web which can be interacted with in order to find out more about the agent identified. Without relying on fixed API features, multiple protocols and layers, out of band knowledge, or limited functionality by using non dereferencable identifiers. So if wikileaks want to generate a cert with an identifier only they can view and which is completely unlinkable, for a one time use, they can. If a bank wants to issue a series of certs to a client which has some stable identifier in them for the client, they can. If facebook want to issue certs which have identifiers which deref to a machine/human readable version of the users profile, and allow people to use their facebook id on any site, they can. If a single person wants to handle their own identity and profile, they can. If services like AWS want to issue keys to machine agents, they can. And critically, they'd all be interoperable from a technical view, with limits to which identifiers and keys and as to which information is visible and what can be used where added on by ACL and usage restrictions. It's quite simple really, client cert auth over TLS is well established, and HTTP(s) URIs allow dereferencing to anything on the web, with the possibility of any features you find anywhere on the web. Seems far more logical and simpler than creating a plethora of custom protocols which rely on layer upon layer of techs and protocols in order to try and make non dereferencable identifiers dereferencable, or to try and provide more information about an identified agent via a suite of API extensions that need implemented by all adopters, or to come up with something new which has most of the same negative sides, and requires web scale adoption in order to work everywhere WebID already can. Best, Nathan From wilton@isoc.org Tue Oct 23 02:59:30 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E82621F8670 for ; Tue, 23 Oct 2012 02:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.443 X-Spam-Level: X-Spam-Status: No, score=-103.443 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZ5V2NQe-wvt for ; Tue, 23 Oct 2012 02:59:29 -0700 (PDT) Received: from smtp110.iad.emailsrvr.com (smtp110.iad.emailsrvr.com [207.97.245.110]) by ietfa.amsl.com (Postfix) with ESMTP id B34C021F8671 for ; Tue, 23 Oct 2012 02:59:29 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp41.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 0A18E290E68; Tue, 23 Oct 2012 05:59:29 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp41.relay.iad1a.emailsrvr.com (Authenticated sender: wilton-AT-isoc.org) with ESMTPSA id 08B57291630; Tue, 23 Oct 2012 05:59:27 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_50B56029-847C-4E9E-BAD4-B7146DDC9C60"; protocol="application/pkcs7-signature"; micalg=sha1 From: Robin Wilton In-Reply-To: Date: Tue, 23 Oct 2012 10:58:22 +0100 Message-Id: <3EF3A430-A6C5-4ADE-92B5-0744DFFD326B@isoc.org> References: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <5083CCCF.2060407@webr3.org> <50842789.3080301@openlinksw.com> <50845268.4010509@webr3.org> <5084AC77.8030600@openlinksw.com> <50851512.9090803@webr3.org> <50852726.9030102@openlinksw.com> <5085360E.3080008@openlinksw.com> <50853CD8.8020005@w3.org> <5FB468E4-BDD3-4635-ACD0-A23540C08751@bblfish.net> <508562C2.1060905@w3.org> To: Ben Laurie X-Mailer: Apple Mail (2.1278) X-Mailman-Approved-At: Tue, 23 Oct 2012 14:09:57 -0700 Cc: Halpin Harry , public-identity@w3.org, saag@ietf.org, "public-privacy@w3.org list" , public-webid@w3.org Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 09:59:30 -0000 --Apple-Mail=_50B56029-847C-4E9E-BAD4-B7146DDC9C60 Content-Type: multipart/alternative; boundary="Apple-Mail=_3537C014-1C5C-47F5-881E-D35A063BD930" --Apple-Mail=_3537C014-1C5C-47F5-881E-D35A063BD930 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Robin Wilton Technical Outreach Director - Identity and Privacy Internet Society email: wilton@isoc.org Phone: +44 705 005 2931 Twitter: @futureidentity On 23 Oct 2012, at 09:44, Ben Laurie wrote: >=20 > Not disagreeing with any of the above, but observing that: >=20 > a) There's no particular reason you could not have an email per site > as well as a key per site. >=20 > b) Linkability it not, as you say, inherently bad. The problem occurs > when you have (effectively) no choice about linkability. >=20 But it's very hard to use either of those mechanisms (separation through = emails or keys) without giving some third party the ability to achieve = total linkability. (In other words, both options remove effective = choice). Yrs., Robin= --Apple-Mail=_3537C014-1C5C-47F5-881E-D35A063BD930 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Robin = Wilton
Technical Outreach Director - Identity and = Privacy
Internet Society

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




On 23 Oct 2012, at 09:44, Ben Laurie = wrote:

<snip>


Not disagreeing with any of the above, but = observing that:

a) There's no particular reason you could not = have an email per site
as well as a key per site.

b) = Linkability it not, as you say, inherently bad. The problem = occurs
when you have (effectively) no choice about = linkability.



But it's very hard to use either of those mechanisms (separation = through emails or keys) without giving some third party the ability to = achieve total linkability. (In other words, both options remove = effective = choice).

Yrs.,
Robin
= --Apple-Mail=_3537C014-1C5C-47F5-881E-D35A063BD930-- --Apple-Mail=_50B56029-847C-4E9E-BAD4-B7146DDC9C60 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILFTCCBTUw ggQdoAMCAQICDgbgAAEAAq9VCEIjHn/GMA0GCSqGSIb3DQEBBQUAMHwxCzAJBgNVBAYTAkRFMRww GgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxUQyBUcnVzdENlbnRlciBDbGFz cyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBIElYMB4XDTEy MDgxMDE4MzA0M1oXDTEzMDgxMTE4MzA0M1owJDELMAkGA1UEBhMCR0IxFTATBgNVBAMTDFJvYmlu IFdpbHRvbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANKMWhPSgpStu7qHEdssN7ap 235OxnVEiokS/3+Wj7t/8aiFi2Myswpg7+ORRn9GjM1lRib85FU7HvKh+uMVFvo6nwK5E8eVB16W 0oI6gUkdLRny2UfTBmELSORkOVHDuh6a/k1j7qfDu5N2oJMf9vqo4lEhkW/T1dz3EgR6kcJG80SZ ebbefYlf66cJ1r3NZJGKWjLpzxI3zRCTT0amntT7tr/fO+tQHN7Dy9fTDPG7YdjD3eyWWqsHO1Dn 2C7ntg9L3DLPwiSN2aQng/hc/GpyICUHwUVPzBfW6T38Z0R41AOlMM2PwVyBEw9/azFZx+4uEpdG FHk9bJgOmUrPXNMCAwEAAaOCAgswggIHMIGlBggrBgEFBQcBAQSBmDCBlTBRBggrBgEFBQcwAoZF aHR0cDovL3d3dy50cnVzdGNlbnRlci5kZS9jZXJ0c2VydmljZXMvY2FjZXJ0cy90Y19jbGFzczFf TDFfQ0FfSVguY3J0MEAGCCsGAQUFBzABhjRodHRwOi8vb2NzcC5peC50Y2NsYXNzMS50Y3VuaXZl cnNhbC1pLnRydXN0Y2VudGVyLmRlMB8GA1UdIwQYMBaAFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMAwG A1UdEwEB/wQCMAAwSgYDVR0gBEMwQTA/BgkqghQALAEBAQEwMjAwBggrBgEFBQcCARYkaHR0cDov L3d3dy50cnVzdGNlbnRlci5kZS9ndWlkZWxpbmVzMA4GA1UdDwEB/wQEAwIE8DAdBgNVHQ4EFgQU WcbfjY0//wFafU/f7U9EOpfjph4wYgYDVR0fBFswWTBXoFWgU4ZRaHR0cDovL2NybC5peC50Y2Ns YXNzMS50Y3VuaXZlcnNhbC1pLnRydXN0Y2VudGVyLmRlL2NybC92Mi90Y19DbGFzczFfTDFfQ0Ff SVguY3JsMDMGA1UdJQQsMCoGCCsGAQUFBwMCBggrBgEFBQcDBAYIKwYBBQUHAwcGCisGAQQBgjcU AgIwGgYDVR0RBBMwEYEPd2lsdG9uQGlzb2Mub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCjBgf2m5OH bgBcBzwzmF6eOnzoTQIgBwTxxmSuwuo+y89Rqu5F92t+bae5npJx+1exUJCG0RougAjPgUe7Blyl 0o0B8H4qVfWklN8Gxi9IGakH1Eua3k/DyHTfUGwlanKZDEGpL5MgZ89n6QZHnGfnfms5wql0WqGE 8UrgbJOzAr5zfkHfc4H/HzC0VNR+jYxFM4ynew1an4ewfNi2XthE8kp4IF7/TKAlRrcChtQvFzLf EQfmCf+j+/N5nRynhxaDBMRoar3VqB79Z6zrSMegtXwHcAiFo3G2n1ctRGhq4sGeCa5Zxl2HL/gF BJkKL5VAHC0ksP/kGhmRzIcO06+qMIIF2DCCBMCgAwIBAgIOBugAAQACSpYtJAz+xckwDQYJKoZI hvcNAQEFBQAweTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJDAi BgNVBAsTG1RDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQTEmMCQGA1UEAxMdVEMgVHJ1c3RDZW50 ZXIgVW5pdmVyc2FsIENBIEkwHhcNMDkxMTAzMTQwODE5WhcNMjUxMjMxMjE1OTU5WjB8MQswCQYD VQQGEwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBMMSBD QSBJWDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALvmkG7PYunpC6q2ENVH5XxdKydx mmjNVW3kou/k/vJ6YxHCV4rIfc+OZh9lRUvrgGJpvUaOi8VuWpUYKt6n8R91GierbTJT4/tNWGIs /xnlx6ANmi0hiFmEzR3xw8iKPrDl3ggkz/xALLpBI5S7gBKJNUi2hgTgAU+MuqmY/ByJ7R+KoceG mCYecmVr/s9l2QxkSxoJ9UMRYGYm4zNWmsk9PjRqeMblUEvIzYjkOWxQJp5ALLY7fDeyp/Xd3LNR y/TcggK41zre2jBcDfVC3RNpU1TpgCZCMx6l18xuymYJn4bwPb7GimEQ89H/W+Sy2y2yZQypfRes uidNQlzOCU8CAwEAAaOCAlkwggJVMIGaBggrBgEFBQcBAQSBjTCBijBSBggrBgEFBQcwAoZGaHR0 cDovL3d3dy50cnVzdGNlbnRlci5kZS9jZXJ0c2VydmljZXMvY2FjZXJ0cy90Y191bml2ZXJzYWxf cm9vdF9JLmNydDA0BggrBgEFBQcwAYYoaHR0cDovL29jc3AudGN1bml2ZXJzYWwtSS50cnVzdGNl bnRlci5kZTAfBgNVHSMEGDAWgBSSpHUspJ6+gUTrefyKxZWl6xB1czASBgNVHRMBAf8ECDAGAQH/ AgEAMFIGA1UdIARLMEkwBgYEVR0gADA/BgkqghQALAEBAQEwMjAwBggrBgEFBQcCARYkaHR0cDov L3d3dy50cnVzdGNlbnRlci5kZS9ndWlkZWxpbmVzMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU 6bgoHUbP/M34TpvF7ktg69g7P9Ewgf0GA1UdHwSB9TCB8jCB76CB7KCB6YZGaHR0cDovL2NybC50 Y3VuaXZlcnNhbC1JLnRydXN0Y2VudGVyLmRlL2NybC92Mi90Y191bml2ZXJzYWxfcm9vdF9JLmNy bIaBnmxkYXA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvQ049VEMlMjBUcnVzdENlbnRlciUyMFVuaXZl cnNhbCUyMENBJTIwSSxPPVRDJTIwVHJ1c3RDZW50ZXIlMjBHbWJILE9VPXJvb3RjZXJ0cyxEQz10 cnVzdGNlbnRlcixEQz1kZT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/MA0GCSqGSIb3 DQEBBQUAA4IBAQA5yMSb7r6Y7khyb43ncbYOkIzTssEVIahGkGhfSgTxOslohCHYpeYEdV2f0tTy S3dDMtyVy2C/AlXQrBywxRSXm2UKww+lHezYSTmVtam++vQeq1bnpuUBCIg1X2cF3UQkUBIiRGN5 8ZtXac6r1jNRT43wcDuOrVE6F381lmtoaGO2HArJ+N8dXs8rEaVj7czQxtMgb6r8aEh+bR64OkWq Eobzx70Atev+6hKfczN45yg5aNOlbdp20U7hVZWApuAbuM2sVu9FWUeYUts6biayMTlpdbEuJPCk nZeIXjMpxrW8B0A6DD26z3SMS056IfobOM3EQy9vtN947pmS5zocMYIDXTCCA1kCAQEwgY4wfDEL MAkGA1UEBhMCREUxHDAaBgNVBAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRy dXN0Q2VudGVyIENsYXNzIDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEg TDEgQ0EgSVgCDgbgAAEAAq9VCEIjHn/GMAkGBSsOAwIaBQCgggGjMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTAyMzA5NTgyMlowIwYJKoZIhvcNAQkEMRYEFCYR FyVmClJ6k/A4WLI1Eh+x3dKbMIGfBgkrBgEEAYI3EAQxgZEwgY4wfDELMAkGA1UEBhMCREUxHDAa BgNVBAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgCDgbgAAEA Aq9VCEIjHn/GMIGhBgsqhkiG9w0BCRACCzGBkaCBjjB8MQswCQYDVQQGEwJERTEcMBoGA1UEChMT VEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBMMSBD QTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBMMSBDQSBJWAIOBuAAAQACr1UIQiMe f8YwDQYJKoZIhvcNAQEBBQAEggEAdn1PT0h+PYccvhmGaK2K3qHnAbSAeXHVLTDtL8vpDcZKbYR8 bHXm0WKpIXpU4Myffv3GY4IOcQKYvn4IXO0iOw3vZbAHDmkHilDUKKcdIcT0UMaYzvqEtNAbXCFm DJa5keWF/wgJMoXBMYDikF69CX/ii98Q+nFhPDZ38b0n4YCiG3PC+JX3q+o1O3tHVKUg8vuOwprL XGUBDsrOriHf1LkOG124JNXRd5rt2Oq//rzcrRo1A/I6kt6O8CTwvuS7HaMhuEN6u57hqUYXzpF8 3EqPBj3JHahiIAc3nYJ2kpaJXL57FD/NNM9XY+IA9RKJOeNBzKDpGBZgqRqgPCh5BgAAAAAAAA== --Apple-Mail=_50B56029-847C-4E9E-BAD4-B7146DDC9C60-- From tho@koanlogic.com Tue Oct 23 14:53:55 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 610101F0C3A for ; Tue, 23 Oct 2012 14:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arDAgg-oVfe7 for ; Tue, 23 Oct 2012 14:53:54 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id BC6D21F0C92 for ; Tue, 23 Oct 2012 14:53:52 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id s14so2938871qcg.31 for ; Tue, 23 Oct 2012 14:53:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=TWR3Nz6onhA0qC5l/IWtt7BWf1hpGuavbCcobCaXcoQ=; b=pjLUeHBVOCE9BrNBIaZaQGWxUopOx8YHEAs183n4e90VnEra1GMtZOLWBRgx4jwAAY AccrM5fu++qeaOrUVjfWGiH8wsSE4Ui227gitOeQDihx9wkW/Gxi6sUTd0GtVVrA4gKV YGdY0dahkLsdiibNyro+0b/dNc9sLcf9yoPAgjQwHcl6LBmlS4Tve+F7OPi9+a7cyB9u zd6uhLeCqQO3kBY7pfZGAtiNzcFQBb/dJhbbWyDbgvLAr8TEHQBNIENwG6ZAeClQDP8i 2tinEIcSuIh8RIos/OLKxnGcCoEozIiWrECfEHOpzC/GWz9kwrQ0ydqGYLWGnqBFRoEY TkSg== MIME-Version: 1.0 Received: by 10.224.207.8 with SMTP id fw8mr6465296qab.92.1351029229148; Tue, 23 Oct 2012 14:53:49 -0700 (PDT) Received: by 10.49.26.170 with HTTP; Tue, 23 Oct 2012 14:53:49 -0700 (PDT) X-Originating-IP: [213.81.89.208] In-Reply-To: <4B8D0A93-3838-4CDB-939B-1183718EFFFE@mnot.net> References: <4B8D0A93-3838-4CDB-939B-1183718EFFFE@mnot.net> Date: Tue, 23 Oct 2012 22:53:49 +0100 Message-ID: From: Thomas Fossati To: Mark Nottingham Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmQAdc7bVtBZXkglfzqaM3Y0sPfcD/CrmL9KrFktr3Djduo3f8QFDZlxPCTNcQoWfExvSY4 Cc: saag@ietf.org Subject: Re: [saag] Input for conflict review of draft-secure-cookie-session-protocol X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 21:53:55 -0000 Hi Mark, On Mon, Oct 22, 2012 at 11:31 PM, Mark Nottingham wrote: > > As far as I can tell, this document specifies some extensions to the Cookie / Set-Cookie (RFC6265), SCS doesn't define any extension whatsoever. It just specifies a format for what 6265 already identifies as a security need for "plain" cookies. From RFC 6265, Section 8.3.: Servers SHOULD encrypt and sign the contents of cookies (using whatever format the server desires) when transmitting them to the user agent (even when sending the cookies over a secure channel). > and/or "squats" on some pre-defined cookie names. No name squatting: ANY_COOKIE_NAME in Section 3.3. of SCS is just a placeholder which really means what it says: any name the cookie maker decides to uses. > 6265 doesn't define how it's to be extended very well (possibly because the underlying assumption is that extensions are VERY difficult to deploy). Sorry if I sound like a broken record, but I want to be ultra-clear on this point: SCS is not an extension to the cookie exchange; and in fact it works out of the box -- today and since 6 years now -- on any browser with cookies enabled. Cheers, Thomas. From barryleiba.mailing.lists@gmail.com Tue Oct 23 22:47:10 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A9A21F8CC2 for ; Tue, 23 Oct 2012 22:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.107 X-Spam-Level: X-Spam-Status: No, score=-103.107 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3DYxICVXlDB for ; Tue, 23 Oct 2012 22:47:10 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id DF5AC21F8CE3 for ; Tue, 23 Oct 2012 22:47:09 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so928200lbo.31 for ; Tue, 23 Oct 2012 22:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=t13488eeeN7yEAdSGnGH/1jtLdHaTejCZUHhJFIx8PI=; b=zxeDX/yNw3iLdHuYSkrCsceDC4EDqJJMJipLWDjOA3/4W/iIQmBng9bRQY7wYKizXl ASN/tmxc6MhHAbsOWPRA19PVmQLv9ujFogVR/0ibCa28vi20o55Uph9OxhtisIV+PMO8 0XGSrpEhXqxhvJEdOaS5eiAY4TGtYKxHHBdgmx8pQK3xabE/E75XL3T/C5LR+DRsqms5 X/CKG4rB0zPHmhAgIHCydtBS9L2kO75tb3KE4yg6+3msnXn4PX4SCEid+5ZJ7aWnpF0x w7ZPqqmHE8UY1oNlHUpNCFurFyzeyi1mY8jyGxkZzkFe8+8Q0vusOazc9Q7ktknuuSVJ 3O3A== MIME-Version: 1.0 Received: by 10.152.114.100 with SMTP id jf4mr13491756lab.47.1351057628845; Tue, 23 Oct 2012 22:47:08 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.99.131 with HTTP; Tue, 23 Oct 2012 22:47:08 -0700 (PDT) In-Reply-To: <4B8D0A93-3838-4CDB-939B-1183718EFFFE@mnot.net> References: <4B8D0A93-3838-4CDB-939B-1183718EFFFE@mnot.net> Date: Wed, 24 Oct 2012 01:47:08 -0400 X-Google-Sender-Auth: G-KvPl2e8UP_dgRQe1LBs2P7jl0 Message-ID: From: Barry Leiba To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Mark Nottingham Subject: Re: [saag] Input for conflict review of draft-secure-cookie-session-protocol X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 05:47:10 -0000 MNot says... > As far as I can tell, this document specifies some extensions to the > Cookie / Set-Cookie (RFC6265), and/or "squats" on some pre-defined > cookie names. It's hard to tell, both because of how the draft is written, > and because I read it very quickly. I don't see any extension there. I see it using the cookie mechanism defined in 6265, and specifying how to use encrypted cookies instead of plain-text ones. > It seems to me that this *might* therefore conflict with the (previous) HTTPSTATE WG's work. I have sympathy for that idea, but it doesn't bear out: The authors proposed it to the httpstate WG on 22 Feb 2011: http://www.ietf.org/mail-archive/web/http-state/current/msg01227.html They followed up on 25 Feb and 7 March: http://www.ietf.org/mail-archive/web/http-state/current/msg01247.html http://www.ietf.org/mail-archive/web/http-state/current/msg01268.html On 13 March they tried to get on the agenda for the Prague IETF meeting: http://www.ietf.org/mail-archive/web/http-state/current/msg01277.html That didn't happen, and the working group was closed in May 2011, after the publication of RFC 6265: http://www.ietf.org/mail-archive/web/http-state/current/msg01317.html The only responses to any of their messages were two from Adam Barth in the first (22 Feb) thread. There appears to have been no interest in taking on the work in httpstate. What that says to me is that httpstate had the chance to take it, and opted out. It's not valid to now say that they should have, and this document conflicts. All that said, here's what I think, as the AD who's shepherding this through the conflict review: 1. It's probably acceptable to do this through the ISE -- that is, this probably does not *conflict* with IETF work. 2. It's probably better to do this through the IETF Stream -- it will get better review and be a more solid document that way. 3. The authors are happy to do it that way; I've talked with them about it. 4. We could charter a new "son of httpstate" working group for this, we could fit it into an existing working group (httpbis or appsawg, likely), or we could do it as an AD-sponsored document (I would be happy to sponsor it, and I suspect Stephen would also). If we did that, it would go as Proposed Standard ... or we could let it continue through the Independent Stream, as Informational. Thoughts? Barry From benl@google.com Wed Oct 24 02:30:15 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589F321F8BC3 for ; Wed, 24 Oct 2012 02:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNZBarHupJop for ; Wed, 24 Oct 2012 02:30:14 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9603F21F893C for ; Wed, 24 Oct 2012 02:30:14 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so173151wey.31 for ; Wed, 24 Oct 2012 02:30:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=AYwghIcjl3bIv0nshgF4xx7nP2io0aFBNyepVcJFZeI=; b=fL9yFrQwADr2ZCYfWQdMNifp0xsXXiMrqEmqgBoPVRfNwUgbExibvrBexGNQoOYOvc Hi8M5c/O5ZulKjyn3GAs3+9j/e+j8+3F0yiDLOb2JeoJzJzyyF1/EaqTKqnmdqn/TqZj mbxL4FgHp8Hjtk9nwGW9cMKeRIngl8vGsa9RqSmh3JHwnK49dupG1b54IuyEZ6cSw4Rg g1vAM4ZaiVXcNh/d2TMYbz6OJ5xiaHrMSjems9kCK/n36PsG9XmsU3fnf9BOE9inHmcc B7V71ninLqRDyH9GqqhthobKDKqzMYTnjzPn7p+f/5AjxgBucQlfDR8tYFBXcBbLwRKq 5L2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=AYwghIcjl3bIv0nshgF4xx7nP2io0aFBNyepVcJFZeI=; b=UabDOm40AY2fWISWLDq8TB6OADbvqvfrtF7qLHtf8zdmSQLAHvj9NhfwimcFaFhZpq Pu0odoT9uDArZwMhxyZEi+uwadabZ81j6TtxsKwpjmgnfKE5R98Th5uZZwOKT2JA0+zA 3Ot0h6OWlXVnk21lnb87l2PuJ7dAXlPBSimQncr5HzxBYvp0YyWYUvoZFzK7H3T/DPJy PvVn+5Nymn+KZ/jhMlIn+Ld7C5Y6XvinHvl6nsmPbaXSCydGvNwZbbZ0RKa6WRCD1sXA cQdgNms8+eeyxq6+OZrtcSmaAIKQvSOkhveknw7BARlc4TIYPFS1GV1zKENIMwWCAsVe a5nQ== MIME-Version: 1.0 Received: by 10.216.136.23 with SMTP id v23mr9273997wei.45.1351071013209; Wed, 24 Oct 2012 02:30:13 -0700 (PDT) Received: by 10.194.76.170 with HTTP; Wed, 24 Oct 2012 02:30:12 -0700 (PDT) In-Reply-To: <3EF3A430-A6C5-4ADE-92B5-0744DFFD326B@isoc.org> References: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <5083CCCF.2060407@webr3.org> <50842789.3080301@openlinksw.com> <50845268.4010509@webr3.org> <5084AC77.8030600@openlinksw.com> <50851512.9090803@webr3.org> <50852726.9030102@openlinksw.com> <5085360E.3080008@openlinksw.com> <50853CD8.8020005@w3.org> <5FB468E4-BDD3-4635-ACD0-A23540C08751@bblfish.net> <508562C2.1060905@w3.org> <3EF3A430-A6C5-4ADE-92B5-0744DFFD326B@isoc.org> Date: Wed, 24 Oct 2012 10:30:12 +0100 Message-ID: From: Ben Laurie To: Robin Wilton Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQm04PH6DY0SRMqFdPfMUQCiwCSLASRfGYKGSb7kBqZ9RYH/2I1doOdCYBDoyEiLzTIoVUqqRkfmIUYA8iNz15+YRaRAGOheIKGeQ2uO6qr7COIg3dxMV6CFpaAJu0qo/PJVHF5a0Edj8/1nhNOxqXmgUOHZeUEMv+/add2dd1TaKo3YYTzN0/q+0SvZ2oxq7llJYxy0 Cc: Halpin Harry , public-identity@w3.org, saag@ietf.org, "public-privacy@w3.org list" , public-webid@w3.org Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 09:30:15 -0000 On 23 October 2012 10:58, Robin Wilton wrote: > > Robin Wilton > Technical Outreach Director - Identity and Privacy > Internet Society > > email: wilton@isoc.org > Phone: +44 705 005 2931 > Twitter: @futureidentity > > > > > On 23 Oct 2012, at 09:44, Ben Laurie wrote: > > > > > Not disagreeing with any of the above, but observing that: > > a) There's no particular reason you could not have an email per site > as well as a key per site. > > b) Linkability it not, as you say, inherently bad. The problem occurs > when you have (effectively) no choice about linkability. > > > > But it's very hard to use either of those mechanisms (separation through > emails or keys) without giving some third party the ability to achieve total > linkability. (In other words, both options remove effective choice). I agree that emails are a problem, but not at all sure why keys are? In the case of appropriate selective disclosure mechanisms, even if there were a third party involved, they would not be able to link uses of the keys. Also, if you insist on using linkable keys, then per-site keys do not involve third parties. On email, this is a soluble problem, but not without using a completely different delivery mechanism. > > Yrs., > Robin > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From benl@google.com Wed Oct 24 04:32:08 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE16421F8B76 for ; Wed, 24 Oct 2012 04:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYqhE9QmbqmK for ; Wed, 24 Oct 2012 04:32:08 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7AB21F8A07 for ; Wed, 24 Oct 2012 04:32:07 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so220282wgb.13 for ; Wed, 24 Oct 2012 04:32:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=hf6aEg3E6+jKXtlhnnu2FFqbNao3DYxs7Zq4CyVpHrg=; b=FW22yfZOXWwLUKd6yVioW3dB1SiaR9tDJZN5ws45S+VgH09cCM711Wl5py5F4satzM Kksuid4ZWKtcA1VFckmq5ZnU6yq5UzTieExR8kR29qUdIt7u2Tc4WitxQ1Xksf+nBMKo mL6/wcpIBQWzDbGcV1D332VQriX1ytzKcppwPIuwudyF8JM51fxigw9Mm4KwT3o94VIa jtueUdj6iOXvhZqyAB1pY59dLgJg1ujwXTR/J1OOwbJy1dgHBzpvPlsz4z6lx8SBmDOI DO8oJXZJZTE2hjD192m9kPzNPJBE0FCJ0nyJoyC7uCsaZFYZFaDH92ndccTAfepO+ePX OgKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=hf6aEg3E6+jKXtlhnnu2FFqbNao3DYxs7Zq4CyVpHrg=; b=ElPn976hgtnHqpb7QZZtyyw+abKXYRYlHyPWC5UxgZlMPA6ki/p0NNqZTnqmnUV9hs OXtB/9VRR0P1SoFfeSPHCk+L4JuN8X7dxuyOsPP29WjDkd9dzbskcdxUzFzABHduN2Tq S4plHthZxAE8z7b+wX2cn5aqY0D4p3Jd70hUDnltplTQqru3pQUt0HJ8t8mKhE/ekL9i IQ7rGRz2IPG4+0q1GFd3diTyXWWMWLGSwZ6QJDDUW8hP6atrCNT8aULPdz05yk2Lrz4v XahF3JgV0UsKpI7eRd0vi98EfnWfoguDbCmlwdPFb0rzaDXLyyr57frsLJkyfcOGmWWs wFNQ== MIME-Version: 1.0 Received: by 10.180.100.101 with SMTP id ex5mr1797098wib.16.1351078326792; Wed, 24 Oct 2012 04:32:06 -0700 (PDT) Received: by 10.194.76.170 with HTTP; Wed, 24 Oct 2012 04:32:06 -0700 (PDT) In-Reply-To: References: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <5083CCCF.2060407@webr3.org> <50842789.3080301@openlinksw.com> <50845268.4010509@webr3.org> <5084AC77.8030600@openlinksw.com> <50851512.9090803@webr3.org> <50852726.9030102@openlinksw.com> <5085360E.3080008@openlinksw.com> <50853CD8.8020005@w3.org> <5FB468E4-BDD3-4635-ACD0-A23540C08751@bblfish.net> <508562C2.1060905@w3.org> <3EF3A430-A6C5-4ADE-92B5-0744DFFD326B@isoc.org> Date: Wed, 24 Oct 2012 12:32:06 +0100 Message-ID: From: Ben Laurie To: Robin Wilton Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQmIxgkikbbKu3eUg0zBSwwaCl0/U5eut67q8drqtbhwR3JKp1TM09vWjA+NL4KhZVM3B4+oczlCUJDKXNJ0utWPdrqs4kDwwHN5X8aGiaZNsxuGuwClvMBP2twqDsb4TZ4L0p0m1/fLwUNfRKiEM11TnVTFc1ZYc6LrWxr9sxfQuKzBKYvvVJmK1vMW//InjZ+PL/jS Cc: Halpin Harry , public-identity@w3.org, saag@ietf.org, "public-privacy@w3.org list" , public-webid@w3.org Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 11:32:08 -0000 On 24 October 2012 12:26, Robin Wilton wrote: > > > > > > > Robin Wilton > Technical Outreach Director - Identity and Privacy > Internet Society > > email: wilton@isoc.org > Phone: +44 705 005 2931 > Twitter: @futureidentity > > > > > On 24 Oct 2012, at 10:30, Ben Laurie wrote: > > On 23 October 2012 10:58, Robin Wilton wrote: > > > > On 23 Oct 2012, at 09:44, Ben Laurie wrote: > > > > > > > Not disagreeing with any of the above, but observing that: > > > a) There's no particular reason you could not have an email per site > > as well as a key per site. > > > b) Linkability it not, as you say, inherently bad. The problem occurs > > when you have (effectively) no choice about linkability. > > > > > But it's very hard to use either of those mechanisms (separation through > > emails or keys) without giving some third party the ability to achieve to= tal > > linkability. (In other words, both options remove effective choice). > > > I agree that emails are a problem, but not at all sure why keys are? > In the case of appropriate selective disclosure mechanisms, even if > there were a third party involved, they would not be able to link uses > of the keys. Also, if you insist on using linkable keys, then per-site > keys do not involve third parties. > > > It may just be that I'm not getting a clear mental picture of your > architecture. But here was my thinking: > > - If you use symmetric keys, you get a system which can't scale unless yo= u > opt for Schneier's idea of a key server=85 but then the key server become= s a > point of potential panopticality. Symmetric keys obviously don't work. > - If you use PKI, *and* you want your communicating parties to be able to > validate the certs they're relying on, then you have to design a CRL- or > OCSP-like mechanism into the architecture, and again you end up with a > component which is potentially panoptical. (Plus, you have to address the > 20-year-old problem of how to make PKI usable by human beings, when recen= t > history suggests that PKI only takes off where human beings are kept well > away from it). Per-site keys don't really need the I in PKI, just the PK. Revocation need not be centralised - I am not saying it is trivial, but it is akin to the problem of forgotten or compromised passwords. Also, it is possible to blacklist using selective disclosure - i.e. detect whether a key has been revoked without revealing the key. From smb@cs.columbia.edu Wed Oct 24 06:53:16 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19D621F8B46; Wed, 24 Oct 2012 06:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EK0b7hXRGLgI; Wed, 24 Oct 2012 06:53:16 -0700 (PDT) Received: from rambutan.cc.columbia.edu (rambutan.cc.columbia.edu [128.59.29.5]) by ietfa.amsl.com (Postfix) with ESMTP id C126121F8B3D; Wed, 24 Oct 2012 06:53:15 -0700 (PDT) Received: from [10.9.0.146] (fireball.cs.columbia.edu [128.59.13.10]) (user=smb2132 mech=PLAIN bits=0) by rambutan.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id q9ODpxJq004357 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 24 Oct 2012 09:53:14 -0400 (EDT) From: Steven Bellovin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Wed, 24 Oct 2012 09:53:14 -0400 To: IETF Security Area Advisory Group , "cfrg@irtf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.5 Subject: [saag] Don't use short keys... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 13:53:16 -0000 http://www.wired.com/threatlevel/2012/10/dkim-vulnerability-widespread/all/ --Steve Bellovin, https://www.cs.columbia.edu/~smb From stephen.farrell@cs.tcd.ie Wed Oct 24 07:31:59 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F6721F8ACA for ; Wed, 24 Oct 2012 07:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.799 X-Spam-Level: X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbfeG9h5Fbyd for ; Wed, 24 Oct 2012 07:31:58 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 4170A21F8A89 for ; Wed, 24 Oct 2012 07:31:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 69DE6171479; Wed, 24 Oct 2012 15:31:52 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1351089111; bh=wSxtzj8tPB5/+n yZMX4fZPyuwvDXIzu5HSyyjsktUw0=; b=XtZOu9McfOkzkAiLLqY04qcy0Pm3PQ QwilSbYdxdGguWSkAgsq3oJHz+Dx0XQi798t4YFinCae80p7TP76JKFyDHjonCim E8kHKNoJc1LzVXgFebteRxkIH43Jf1QNNdXybRhyhC50+6a4pmQ/Qj2LMJ1LBtCq JihG2oPsB9gweBeKtN2IvSyuhb+9hQkGdfm3CwWnD4sTtsdgmGjfpGHRFaBd0zX8 9PBw3aXyUiRO7S5dDMj42NywQ+ytRd/cfzamiaPeNtt1xQTWUHBDEx/YD9Ps84LS mnrAtYFx/fmzWCTOuXyQAeT8HMXfo61glRV+24iI9rGInVPWPGChTO4A== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id jPaMarzU2D8A; Wed, 24 Oct 2012 15:31:51 +0100 (IST) Received: from [IPv6:2001:770:10:203:93a:7c18:9b35:51a7] (unknown [IPv6:2001:770:10:203:93a:7c18:9b35:51a7]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 30A37171478; Wed, 24 Oct 2012 15:31:47 +0100 (IST) Message-ID: <5087FBD3.3070400@cs.tcd.ie> Date: Wed, 24 Oct 2012 15:31:47 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121017 Thunderbird/16.0.1 MIME-Version: 1.0 To: Barry Leiba References: <4B8D0A93-3838-4CDB-939B-1183718EFFFE@mnot.net> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Mark Nottingham , saag@ietf.org Subject: Re: [saag] Input for conflict review of draft-secure-cookie-session-protocol X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 14:31:59 -0000 Hiya, On 10/24/2012 06:47 AM, Barry Leiba wrote: > All that said, here's what I think, as the AD who's shepherding this > through the conflict review: > > 1. It's probably acceptable to do this through the ISE -- that is, > this probably does not *conflict* with IETF work. Adding the company name to the title would still be good here if we take this route I think. (If for no other reason, to avoid confusion in case we do want a standard flavour of this later.) > 2. It's probably better to do this through the IETF Stream -- it will > get better review and be a more solid document that way. > > 3. The authors are happy to do it that way; I've talked with them about it. > > 4. We could charter a new "son of httpstate" working group for this, > we could fit it into an existing working group (httpbis or appsawg, > likely), or we could do it as an AD-sponsored document (I would be > happy to sponsor it, and I suspect Stephen would also). If we did > that, it would go as Proposed Standard ... or we could let it > continue through the Independent Stream, as Informational. I do think a standard for this could be useful, lots of sites do emit encrypted/integrity-protected cookies and probably lots of 'em roll their own badly. It'd be good to try get a feel for whether a standard would be likely to be adopted though before going down this route I think. Not sure how best to get that done though as I guess it'd more be one for implementers of application frameworks and toolkits, who probably don't read saag. That might take a while though. So, overall, I'd say maybe best might be to stick to the ISE route for this, to get it done (assuming that's what the authors would prefer) but then also try figure out if there's a useful standard to be written here, which might well start out from this document, or maybe we'd find out that there're already slightly different ways to do this that are closer to current implementations that'd be more likely to get deployed. For example load balancing might call for slightly more complex key mgmt, or maybe there'd be a reason to also encrypt or to omit the ATIME field. I've no idea if that's the case, but we'd want to figure it out for a standards track document, and that might take enough time that the authors would really prefer to take the ISE route for now. S. From henry.story@bblfish.net Wed Oct 24 08:00:37 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABED121F8A2F for ; Wed, 24 Oct 2012 08:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.272 X-Spam-Level: X-Spam-Status: No, score=-3.272 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVZb1coVpWmx for ; Wed, 24 Oct 2012 08:00:36 -0700 (PDT) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id CF55221F8A2D for ; Wed, 24 Oct 2012 08:00:27 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id k13so228800eaa.31 for ; Wed, 24 Oct 2012 08:00:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=Dd9+MA7W/m/AaHEVs9kwNVNJTaTcmZL+F2GlszhciBE=; b=N5jLbhLHLqgZZknk8YXKNMSGzrVoQWxAHfT6ccDMPxLHR6UKBXZGhaaD2iv1Nmabr0 B388SalCKKCYNvA6o2UPGEuyQrgKN1xyhgtN6EZsF5JaUFLrf/BVN16JLam3cuFtGQKz jIohbOnvUNzVLbsY1q7pTydrEJJeXwbKPx3LkJB3uok795mdh7mHAOvG8jCnAOrPSxeW grHjLStvGGHqCjESbshyARHAMvM4cBAkZGFEz9eo4czQy3+85bFdF1kNZTZEfZICsUBl 3h51FjU0odqDLkBBSgCgj4iJjqz7M/c5X6yu/VdiTn/ra7YTVhUH54K/wXwb4B5DpzJ/ 8uPw== Received: by 10.14.215.69 with SMTP id d45mr21824949eep.16.1351090826767; Wed, 24 Oct 2012 08:00:26 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-132-122.w86-198.abo.wanadoo.fr. [86.198.99.122]) by mx.google.com with ESMTPS id a44sm12780339eeo.7.2012.10.24.08.00.23 (version=SSLv3 cipher=OTHER); Wed, 24 Oct 2012 08:00:25 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_CE2125B7-DD8E-4565-A599-A00169A79E72"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Henry Story In-Reply-To: Date: Wed, 24 Oct 2012 17:00:21 +0200 Message-Id: <43EEDAE2-6E5F-4D2E-BC1E-516408DCD3CC@bblfish.net> References: <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <5083CCCF.2060407@webr3.org> <50842789.3080301@openlinksw.com> <50845268.4010509@webr3.org> <5084AC77.8030600@openlinksw.com> <50851512.9090803@webr3.org> <50852726.9030102@openlinksw.com> <5085360E.3080008@openlinksw.com> <50853CD8.8020005@w3.org> <5FB468E4-BDD3-4635-ACD0-A23540C08751@bblfish.net> <508562C2.1060905@w3.org> <3EF3A430-A6C5-4ADE-92B5-0744DFFD326B@isoc.org> <5087D92D.8000207@webr3.org> <5087F51D.3040503@openlinksw.com> To: Melvin Carvalho X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQm1JcrVFOjSiWl5rsaPTV/OT6iotnwvpd85QlYTWGRNEkHOF5ET5D84RIcgK6eBh6b7r8+x Cc: Robin Wilton , public-identity@w3.org, "saag@ietf.org" , "public-privacy@w3.org list" , public-webid@w3.org Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 15:00:37 -0000 --Apple-Mail=_CE2125B7-DD8E-4565-A599-A00169A79E72 Content-Type: multipart/alternative; boundary="Apple-Mail=_77546AC2-552D-4C3C-90ED-D12A741A6C2B" --Apple-Mail=_77546AC2-552D-4C3C-90ED-D12A741A6C2B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 24 Oct 2012, at 16:24, Melvin Carvalho = wrote: >=20 >=20 > On 24 October 2012 16:03, Kingsley Idehen = wrote: > On 10/24/12 8:03 AM, Nathan wrote: > Robin Wilton wrote: >=20 >=20 >=20 >=20 > On 24 Oct 2012, at 10:30, Ben Laurie wrote: >=20 > On 23 October 2012 10:58, Robin Wilton wrote: >=20 > On 23 Oct 2012, at 09:44, Ben Laurie wrote: >=20 > >=20 >=20 > Not disagreeing with any of the above, but observing that: >=20 > a) There's no particular reason you could not have an email per site > as well as a key per site. >=20 > b) Linkability it not, as you say, inherently bad. The problem occurs > when you have (effectively) no choice about linkability. >=20 >=20 >=20 > But it's very hard to use either of those mechanisms (separation = through > emails or keys) without giving some third party the ability to achieve = total > linkability. (In other words, both options remove effective choice). > I agree that emails are a problem, but not at all sure why keys are? > In the case of appropriate selective disclosure mechanisms, even if > there were a third party involved, they would not be able to link uses > of the keys. Also, if you insist on using linkable keys, then per-site > keys do not involve third parties. >=20 >=20 > It may just be that I'm not getting a clear mental picture of your = architecture. But here was my thinking: > - If you use symmetric keys, you get a system which can't scale unless = you opt for Schneier's idea of a key server=85 but then the key server = becomes a point of potential panopticality. >=20 > - If you use PKI, *and* you want your communicating parties to be able = to validate the certs they're relying on, then you have to design a CRL- = or OCSP-like mechanism into the architecture, and again you end up with = a component which is potentially panoptical. (Plus, you have to address = the 20-year-old problem of how to make PKI usable by human beings, when = recent history suggests that PKI only takes off where human beings are = kept well away from it). >=20 > CRL is pretty much built in to WebID, if you remove a public key from = the document pointed to by your uri-identifier, then it's no longer = valid for use in WebID - auth can't happen, rendering the cert useless = for WebID. +1 Nathan.=20 ( btw. It is always good to point people to the spec too = http://webid.info/spec is the short url for it. ) >=20 >=20 >=20 >=20 > For sake of clarity, Nathan is speaking about the WebID authentication = protocol. >=20 > A WebID on its own refers to an resolvable (de-referencable) = identifier. The WebID protocol verifies the aforementioned identifier = (entity denotation mechanism) via a combination of cryptography and = entity relationship semantics oriented logic. >=20 > Kingsley, thanks for pointing this out. >=20 > I think some of the confusion arises from the fact that a webid is = sometimes not that clearly defined, and people focus on the protocol. The spec has a definition that seems pretty reasonable, ( though I think = we should remove the reference to "intentions" ) http://www.w3.org/2005/Incubator/webid/spec/#terminology WebID A URI that refers to an Agent - Person, Robot, Group or other thing that = can have Intentions. The WebID should be a URI which when dereferenced = returns a representation whose description uniquely identifies the Agent = who is the controller of a public key. In our example the WebID refers = to Bob. A WebID is usually a URL with a #tag, as the meaning of such a = URL is defined in the document refered to by the WebID URL without the = #tag . >=20 > In particular a WebID is a URI that references an Agent (human or = machine) >=20 > Similarly, email will become WebIDs using the webfinger spec (when = that's complete) >=20 > It can be argued that OAuth/OpenID identifiers are also WebID but with = a different auth protocol. >=20 > Mozilla persona, although certainly useful, would possibly not fit = into the same category, as they use a proprietary identification system.=20= >=20 > The whole idea is that WebID brings things together at an = architectural level. "The WebID Protocol", certs, X.509 are = implementation details really. I would not say just implementation details. =46rom the philosophical = theory of reference=20 ( eg: Gareth Evans's book: The variety of Reference ) they may be, but = in everyday usage=20 how these things are implemented is quite important, and so are the = distinctions. According to the WebID spec definition: - OpenID is close [1] though they have a URL for a web page rather than = an agent (not a big deal), but more importantly they don't make use of = the URL to get the attributes, which is what WebID does. They certainly = don't publish the public key in the OpenId profile. - webfinger does indeed give a method to dereference a mailto: uri, = which could be used for a WebID protocol. - I don't think OAuth is working with URIs at all - Mozilla Persona could use WebIDs [2] and it would improve their = protocol so dramatically, it is evident that they will at some point. Henry [1] https://blogs.oracle.com/bblfish/entry/what_does_foaf_ssl_give [2] = http://security.stackexchange.com/questions/5406/what-are-the-main-advanta= ges-and-disadvantages-of-webid-compared-to-browserid > =20 >=20 >=20 > --=20 >=20 > Regards, >=20 > Kingsley Idehen=20 > Founder & CEO > OpenLink Software > Company Web: http://www.openlinksw.com > Personal Weblog: http://www.openlinksw.com/blog/~kidehen > Twitter/Identi.ca handle: @kidehen > Google+ Profile: https://plus.google.com/112399767740508618350/about > LinkedIn Profile: http://www.linkedin.com/in/kidehen >=20 >=20 >=20 >=20 >=20 >=20 Social Web Architect http://bblfish.net/ --Apple-Mail=_77546AC2-552D-4C3C-90ED-D12A741A6C2B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 melvincarvalho@gmail.com> = wrote:



On 24 October 2012 = 16:03, Kingsley Idehen <kidehen@openlinksw.com> = wrote:
On 10/24/12 8:03 AM, Nathan = wrote:
Robin Wilton wrote:




On 24 Oct 2012, at 10:30, Ben Laurie wrote:

On 23 October 2012 10:58, Robin Wilton <wilton@isoc.org> = wrote:

On 23 Oct 2012, at 09:44, Ben Laurie wrote:

<snip>


Not disagreeing with any of the above, but observing that:

a) There's no particular reason you could not have an email per site
as well as a key per site.

b) Linkability it not, as you say, inherently bad. The problem = occurs
when you have (effectively) no choice about linkability.



But it's very hard to use either of those mechanisms (separation = through
emails or keys) without giving some third party the ability to achieve = total
linkability. (In other words, both options remove effective choice).
I agree that emails are a problem, but not at all sure why keys are?
In the case of appropriate selective disclosure mechanisms, even if
there were a third party involved, they would not be able to link = uses
of the keys. Also, if you insist on using linkable keys, then = per-site
keys do not involve third parties.


It may just be that I'm not getting a clear mental picture of your = architecture. But here was my thinking:
- If you use symmetric keys, you get a system which can't scale unless = you opt for Schneier's idea of a key server=85 but then the key server = becomes a point of potential panopticality.

- If you use PKI, *and* you want your communicating parties to be able = to validate the certs they're relying on, then you have to design a CRL- = or OCSP-like mechanism into the architecture, and again you end up with = a component which is potentially panoptical. (Plus, you have to address = the 20-year-old problem of how to make PKI usable by human beings, when = recent history suggests that PKI only takes off where human beings are = kept well away from it).

CRL is pretty much built in to WebID, if you remove a public key from = the document pointed to by your uri-identifier, then it's no longer = valid for use in WebID - auth can't happen, rendering the cert useless = for = WebID.
+1 Nathan. 

( btw. It is = always good to point people to the spec too http://webid.info/spec is the short = url for it. )





For sake of clarity, Nathan is speaking about the WebID authentication = protocol.

A WebID on its own refers to an resolvable (de-referencable) identifier. = The WebID protocol verifies the aforementioned identifier (entity = denotation mechanism) via a combination of cryptography and entity = relationship semantics oriented logic.

Kingsley, thanks for pointing this out.

I think some of = the confusion arises from the fact that a webid is sometimes not that = clearly defined, and people focus on the = protocol.

The spec has a = definition that seems pretty reasonable, ( though I think we should = remove the reference to "intentions" )


<= div>
WebID
A URI that refers to an Agent - = Person, Robot, Group or other thing that can have Intentions. The WebID = should be a URI which when dereferenced returns a representation whose = description uniquely identifies the Agent who is the controller of a = public key. In our example the WebID refers to Bob. A WebID is = usually a URL with a #tag, as the meaning of such a URL is defined in = the document refered to by the WebID URL without the #tag = .



In particular a WebID is a URI that = references an Agent (human or machine)

Similarly, email will become WebIDs using the webfinger spec (when = that's complete)

It can be argued that OAuth/OpenID identifiers = are also WebID but with a different auth protocol.

Mozilla = persona, although certainly useful, would possibly not fit into the same = category, as they use a proprietary identification system.

The whole idea is that WebID brings things together at an = architectural level.  "The WebID Protocol", certs, X.509 are = implementation details = really.

I would not say = just implementation details. =46rom the philosophical theory of = reference 
( eg: Gareth Evans's book: The variety of = Reference ) they may be, but in everyday usage 
how = these things are implemented is quite important, and so are the = distinctions.

According to the WebID spec = definition:
 - OpenID is close [1] though they have a URL = for a web page rather than an agent (not a big deal), but more = importantly they don't make use of the URL to get the attributes, = which is what WebID does. They certainly don't publish the public key in = the OpenId profile.
 - webfinger does indeed give a = method to dereference a mailto: uri, which could be used for a WebID = protocol.
 - I don't think OAuth is working with URIs at = all
 - Mozilla Persona could use WebIDs [2] and it would = improve their protocol so dramatically, it is evident that they will at = some point.

  = Henry

[2] http://secur= ity.stackexchange.com/questions/5406/what-are-the-main-advantages-and-disa= dvantages-of-webid-compared-to-browserid
 


--

Regards,

Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/abo= ut
LinkedIn Profile: http://www.linkedin.com/in/kidehen







Social Web = Architect
http://bblfish.net/<= /span>

= --Apple-Mail=_77546AC2-552D-4C3C-90ED-D12A741A6C2B-- --Apple-Mail=_CE2125B7-DD8E-4565-A599-A00169A79E72 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINXzCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHIzCCBgug AwIBAgIDBNBjMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTIwODI5MDE0NTU2WhcNMTMwODMwMDkyMzQwWjBlMRkwFwYDVQQNExBrNDZ4OW85ckNETmZXMzBj MSAwHgYDVQQDDBdoZW5yeS5zdG9yeUBiYmxmaXNoLm5ldDEmMCQGCSqGSIb3DQEJARYXaGVucnku c3RvcnlAYmJsZmlzaC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsdekSaKJ8 5Km52QmfW8CcV1my5ou5hgtt1YvjujWsoP+SDz9ElSZMgzZqtrh78w7FHXqa7Z/IBxrcfVSghc01 cNthAO7Y+R8ug1IzkkYChht8HSdcEr/9l5yJ1Uxnx4TF3Tb+8XOjm+P2RA1oA9JiKuJ3nF7VxX1j VEWOUSjO5gBSFTzOLe1p/bYkzjmKLZisISBWMN17PzKKjRCgl4oQQvcmEvi2qmRt8g4eZ2IdjHTR LphwKiAN/FdzfM4neNwiP8XrV5cbWpZf+Wr1EDKgGNgctYTaIdA/B3O6bTe5ty85OWiGo5H79xXO /HXSXpsnjoqK19vJ1cyHwehjtBybAgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIE sDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFBFtP2rBFuUgj3GcA3YW UQxQPUtDMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMCIGA1UdEQQbMBmBF2hlbnJ5 LnN0b3J5QGJibGZpc2gubmV0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8w LgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwIC MIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRp ZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVx dWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRo ZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2Js aWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0 aW9uICJMZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAuP8DX1tEuYjuwx/SVVGt03bc25ELv9QVItkN9zGt HXA61CABusWUUtj462fpRZgiJZCm/a/k+WirD2sxqblbyx4LdNS3zdK2iFcKZnQQOYrzsh8HqSl3 sXAnREUYLGfbaE9TaS6GnaZuMnMJOt3eNaxfDrcxcNTMe65xYZfaZjUmL7NEQKHnrw3uJYDmOf2R ZP6HujvLApsdzioCeSyCEtgCdN+gLHUg+RPj/wDmF/fyKaF/01w0aJuu+397j2xpx/oaNEc63+U4 KsRfZ+HZi9MHmx0Qozm2MoIo2kVKqdEIqGxZn031k/uZFl8I4GMAyybcJbbKDCVZdzniWB+nVTGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwTQYzAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjEwMjQxNTAw MjJaMCMGCSqGSIb3DQEJBDEWBBTwcViMAiaoOm930xj8bZRHP4prDjCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwTQYzCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBNBjMA0GCSqGSIb3DQEBAQUABIIBAAIs uvn1eGp9SbZKXzMPgpo8dHjxRPkP8XM9iYhFeB3G/uknWXzeoUnpC1F3CjVyA/spseub5WnYsfF+ 9XXnSGtWf9uzgwgAbODLKO43//LfBhtMpfmYXb2wRGdKRc+JP0VWn851u+D/ndCMco2r0AJ55F9w PdYoGRwi6j4z7Taz80nQENpl8PRudA7msqQB2tN96OO1VCvPAxAudzIc8GeCgWTKsbWkmUK1zXw2 9AjR2G48SRByUdyM8fFOkpIicOBkSzU/tjBp9w5YtCKT3Hfk1rnSdktWF6q5CI6521ZSjFdHbNSN rGyTZEOKej28yjG6+SD2b4G4z+bE5UGRN/MAAAAAAAA= --Apple-Mail=_CE2125B7-DD8E-4565-A599-A00169A79E72-- From sm@resistor.net Wed Oct 24 17:04:35 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0831F0C4C for ; Wed, 24 Oct 2012 17:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89XDSDsmCalD for ; Wed, 24 Oct 2012 17:04:34 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C02FC1F0419 for ; Wed, 24 Oct 2012 17:04:34 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q9P04Uik027274 for ; Wed, 24 Oct 2012 17:04:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1351123474; bh=BSF5xTzV2jX5BLPTscTWaiaE4Fk8ZVOZ9V3uE4xmTCQ=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=TMCP38/C3roO9B90c6ta/NWiV3J6ImxVuWiVu1JJV692Fl3XRiolisJ7vPyVPDOwl iR6GyM+og4huFmWJsZWmV9NkCm9BUgmgXj7dKqnYKVb2P7I8jHvcDTTPf2BU21TjBk pXDb4xhUfTq0fNibghq/Q95ezRv4kMbOsq2dS5IA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1351123474; i=@resistor.net; bh=BSF5xTzV2jX5BLPTscTWaiaE4Fk8ZVOZ9V3uE4xmTCQ=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=wXjiw6eZU2drs6P/GVOr13zLjeKVsrrko2dx9KcefKhiel6LzzDSNsZHzDBnBp103 t0Uz/8Av6QFqKNhXtVlhAFldZELlmdR26CV1pKBtckAx1Hy0hdD69xth16qUFw9qQv 5Wni8+J1VUI3Z7xb9s0qBmZuUg4vJehdABP9bHkA= Message-Id: <6.2.5.6.2.20121024163519.0b079338@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 24 Oct 2012 17:01:10 -0700 To: saag@ietf.org From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [saag] Don't use short keys... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 00:04:35 -0000 At 06:53 24-10-2012, Steven Bellovin wrote: >http://www.wired.com/threatlevel/2012/10/dkim-vulnerability-widespread/all/ Dan Romascanu filed the following comment about a draft in January: '2. I know too little about the operational model of configuring a report generator, so I was left wondering how are the first two recommendations implemented in practice: 1. Select an arbitrary string that will be used by an Administrative Management Domain (ADMD) that generates reports. This string will not be changed except according to a key rotation policy or similar. Call this the "redaction key".' It is unfortunate that security considerations in specifications are not given adequate consideration. Software is installed in fire and forget mode [1]. Implementing recommendations such as the above, for example, might help remove some of the cruft. Regards, -sm 1. I don't claim to be any better. From aland@deployingradius.com Thu Oct 25 03:37:12 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DA221F896D; Thu, 25 Oct 2012 03:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7N7pvGykPg2z; Thu, 25 Oct 2012 03:37:11 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6E04221F8910; Thu, 25 Oct 2012 03:37:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 2DC5022405AB; Thu, 25 Oct 2012 12:37:09 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyBXXE+mm4f9; Thu, 25 Oct 2012 12:37:07 +0200 (CEST) Received: from Thor.local (pas38-7-83-153-93-21.fbx.proxad.net [83.153.93.21]) by power.freeradius.org (Postfix) with ESMTPSA id E4F5B2240530; Thu, 25 Oct 2012 12:37:06 +0200 (CEST) Message-ID: <50891651.8060902@deployingradius.com> Date: Thu, 25 Oct 2012 12:37:05 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "saag@ietf.org" , draft-ietf-dhc-client-id@tools.ietf.org, IESG IESG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [saag] Review of draft-ietf-dhc-client-id X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 10:37:12 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document is small and simple. The document says: ... When a client receives a DHCP message containing a 'client identifier' option, the client MUST compare that client identifier to the one it is configured to send. If the two client identifiers do not match, the client MUST silently discard the message. ... I find the "configured to send" text a little confusing. In my view, the process is more one of comparing a *received* 'client identifier' with an *expected* 'client identifier'. If they don't match, no response is sent. If they do match, the 'client identifier' is ACKed verbatim. Saying that the server is "configured to send" a 'client identifier' could be interpreted as it *always* sends a 'client identifier'. The intent (I believe) is instead to verify the one that is received. I do have a question about inter-operability. As they note, RFC 2131 says that the DHCP server MUST NOT return the 'client identifier' option. This document changes that MUST NOT to a MUST, if the client sends a 'client identifier'. Some implementations may have "inventive" interpretations of MUST NOT requirements. If this is the case, they may interpret a response with 'client identifier' as violating the protocol. They may then discard the message. So changing the protocol in this way could result in poor implementations being denied access to the network. I would suggest updating the "Security Considerations" section to note that in the absence of the authentication option (90), RFC 3118, anyone can spoof the 'client identifier'. It is a useful field, but not a trusted one. Alan DeKok. From mnot@mnot.net Tue Oct 23 21:56:50 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9DB21F8C27 for ; Tue, 23 Oct 2012 21:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.301 X-Spam-Level: X-Spam-Status: No, score=-104.301 tagged_above=-999 required=5 tests=[AWL=-1.702, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ie3C+EOJ8ODz for ; Tue, 23 Oct 2012 21:56:49 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 36FB821F8C26 for ; Tue, 23 Oct 2012 21:56:49 -0700 (PDT) Received: from [192.168.1.82] (unknown [118.209.87.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1D96B22E1F4; Wed, 24 Oct 2012 00:56:41 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: Date: Wed, 24 Oct 2012 15:56:43 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <4319782A-8D8B-4D38-8046-1F775CEEFBB5@mnot.net> References: <4B8D0A93-3838-4CDB-939B-1183718EFFFE@mnot.net> To: Thomas Fossati X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Thu, 25 Oct 2012 08:21:39 -0700 Cc: saag@ietf.org Subject: Re: [saag] Input for conflict review of draft-secure-cookie-session-protocol X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 04:56:50 -0000 Hi, If you're finding yourself saying it repeatedly, it might be worth = explicitly documenting what the relationship to existing cookies are, = what the expectations are for the various parties involved, and giving a = bit more information about the use case.=20 Cheers, On 24/10/2012, at 8:53 AM, Thomas Fossati wrote: > Hi Mark, >=20 > On Mon, Oct 22, 2012 at 11:31 PM, Mark Nottingham = wrote: >>=20 >> As far as I can tell, this document specifies some extensions to the = Cookie / Set-Cookie (RFC6265), >=20 > SCS doesn't define any extension whatsoever. It just specifies a > format for what 6265 already identifies as a security need for "plain" > cookies. =46rom RFC 6265, Section 8.3.: >=20 > Servers SHOULD encrypt and sign the contents of cookies (using > whatever format the server desires) when transmitting them to the > user agent (even when sending the cookies over a secure channel). >=20 >> and/or "squats" on some pre-defined cookie names. >=20 > No name squatting: ANY_COOKIE_NAME in Section 3.3. of SCS is just a > placeholder which really means what it says: any name the cookie maker > decides to uses. >=20 >> 6265 doesn't define how it's to be extended very well (possibly = because the underlying assumption is that extensions are VERY difficult = to deploy). >=20 > Sorry if I sound like a broken record, but I want to be ultra-clear on > this point: SCS is not an extension to the cookie exchange; and in > fact it works out of the box -- today and since 6 years now -- on any > browser with cookies enabled. >=20 > Cheers, Thomas. -- Mark Nottingham http://www.mnot.net/ From wilton@isoc.org Wed Oct 24 04:28:13 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB7721F8A34 for ; Wed, 24 Oct 2012 04:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.453 X-Spam-Level: X-Spam-Status: No, score=-103.453 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWR+r9+HAeqi for ; Wed, 24 Oct 2012 04:28:12 -0700 (PDT) Received: from smtp130.iad.emailsrvr.com (smtp130.iad.emailsrvr.com [207.97.245.130]) by ietfa.amsl.com (Postfix) with ESMTP id 73BA321F89F4 for ; Wed, 24 Oct 2012 04:28:12 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp53.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id B691C5853F; Wed, 24 Oct 2012 07:28:11 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp53.relay.iad1a.emailsrvr.com (Authenticated sender: wilton-AT-isoc.org) with ESMTPSA id D83D15852D; Wed, 24 Oct 2012 07:28:09 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_3CB19E3D-569C-4A61-8005-2892AE764BB1"; protocol="application/pkcs7-signature"; micalg=sha1 From: Robin Wilton In-Reply-To: Date: Wed, 24 Oct 2012 12:26:58 +0100 Message-Id: References: <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <5083CCCF.2060407@webr3.org> <50842789.3080301@openlinksw.com> <50845268.4010509@webr3.org> <5084AC77.8030600@openlinksw.com> <50851512.9090803@webr3.org> <50852726.9030102@openlinksw.com> <5085360E.3080008@openlinksw.com> <50853CD8.8020005@w3.org> <5FB468E4-BDD3-4635-ACD0-A23540C08751@bblfish.net> <508562C2.1060905@w3.org> <3EF3A430-A6C5-4ADE-92B5-0744DFFD326B@isoc.org> To: Ben Laurie X-Mailer: Apple Mail (2.1278) X-Mailman-Approved-At: Thu, 25 Oct 2012 08:21:39 -0700 Cc: Halpin Harry , public-identity@w3.org, saag@ietf.org, "public-privacy@w3.org list" , public-webid@w3.org Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 11:28:13 -0000 --Apple-Mail=_3CB19E3D-569C-4A61-8005-2892AE764BB1 Content-Type: multipart/alternative; boundary="Apple-Mail=_17ADAE90-849A-45C3-BFDE-BE26F54EB4D2" --Apple-Mail=_17ADAE90-849A-45C3-BFDE-BE26F54EB4D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 =20 Robin Wilton Technical Outreach Director - Identity and Privacy Internet Society email: wilton@isoc.org Phone: +44 705 005 2931 Twitter: @futureidentity On 24 Oct 2012, at 10:30, Ben Laurie wrote: > On 23 October 2012 10:58, Robin Wilton wrote: >>=20 >>=20 >> On 23 Oct 2012, at 09:44, Ben Laurie wrote: >>=20 >> >>=20 >>=20 >> Not disagreeing with any of the above, but observing that: >>=20 >> a) There's no particular reason you could not have an email per site >> as well as a key per site. >>=20 >> b) Linkability it not, as you say, inherently bad. The problem occurs >> when you have (effectively) no choice about linkability. >>=20 >>=20 >>=20 >> But it's very hard to use either of those mechanisms (separation = through >> emails or keys) without giving some third party the ability to = achieve total >> linkability. (In other words, both options remove effective choice). >=20 > I agree that emails are a problem, but not at all sure why keys are? > In the case of appropriate selective disclosure mechanisms, even if > there were a third party involved, they would not be able to link uses > of the keys. Also, if you insist on using linkable keys, then per-site > keys do not involve third parties. >=20 It may just be that I'm not getting a clear mental picture of your = architecture. But here was my thinking:=20 - If you use symmetric keys, you get a system which can't scale unless = you opt for Schneier's idea of a key server=85 but then the key server = becomes a point of potential panopticality. - If you use PKI, *and* you want your communicating parties to be able = to validate the certs they're relying on, then you have to design a CRL- = or OCSP-like mechanism into the architecture, and again you end up with = a component which is potentially panoptical. (Plus, you have to address = the 20-year-old problem of how to make PKI usable by human beings, when = recent history suggests that PKI only takes off where human beings are = kept well away from it). R > On email, this is a soluble problem, but not without using a > completely different delivery mechanism. >=20 >>=20 >> Yrs., >> Robin >>=20 >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >>=20 --Apple-Mail=_17ADAE90-849A-45C3-BFDE-BE26F54EB4D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Robin = Wilton
Technical Outreach Director - Identity and = Privacy
Internet Society

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




On 24 Oct 2012, at 10:30, Ben Laurie wrote:

On 23 = October 2012 10:58, Robin Wilton <wilton@isoc.org> = wrote:


On 23 Oct 2012, at 09:44, Ben Laurie = wrote:

<snip>


Not disagreeing = with any of the above, but observing that:

a) There's no = particular reason you could not have an email per = site
as well as a key per = site.

b) Linkability = it not, as you say, inherently bad. The problem = occurs
when you have = (effectively) no choice about linkability.



But it's very = hard to use either of those mechanisms (separation = through
emails or keys) = without giving some third party the ability to achieve = total
linkability. (In other = words, both options remove effective choice).

I = agree that emails are a problem, but not at all sure why keys are?
In = the case of appropriate selective disclosure mechanisms, even = if
there were a third party involved, they would not be able to link = uses
of the keys. Also, if you insist on using linkable keys, then = per-site
keys do not involve third = parties.


It may just be = that I'm not getting a clear mental picture of your architecture. But = here was my thinking: 

- If you use = symmetric keys, you get a system which can't scale unless you opt for = Schneier's idea of a key server=85 but then the key server becomes a = point of potential panopticality.

- If you use PKI, = *and* you want your communicating parties to be able to validate the = certs they're relying on, then you have to design a CRL- or OCSP-like = mechanism into the architecture, and again you end up with a component = which is potentially panoptical. (Plus, you have to address the = 20-year-old problem of how to make PKI usable by human beings, when = recent history suggests that PKI only takes off where human beings are = kept well away from = it).

R


<= /div>
On email, this is a soluble = problem, but not without using a
completely different delivery = mechanism.





Yrs.,
Robin

_______________________________________________
saag mailing = list
saag@ietf.org
https://www.ietf.org/m= ailman/listinfo/saag


= --Apple-Mail=_17ADAE90-849A-45C3-BFDE-BE26F54EB4D2-- --Apple-Mail=_3CB19E3D-569C-4A61-8005-2892AE764BB1 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILFTCCBTUw ggQdoAMCAQICDgbgAAEAAq9VCEIjHn/GMA0GCSqGSIb3DQEBBQUAMHwxCzAJBgNVBAYTAkRFMRww GgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxUQyBUcnVzdENlbnRlciBDbGFz cyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBIElYMB4XDTEy MDgxMDE4MzA0M1oXDTEzMDgxMTE4MzA0M1owJDELMAkGA1UEBhMCR0IxFTATBgNVBAMTDFJvYmlu IFdpbHRvbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANKMWhPSgpStu7qHEdssN7ap 235OxnVEiokS/3+Wj7t/8aiFi2Myswpg7+ORRn9GjM1lRib85FU7HvKh+uMVFvo6nwK5E8eVB16W 0oI6gUkdLRny2UfTBmELSORkOVHDuh6a/k1j7qfDu5N2oJMf9vqo4lEhkW/T1dz3EgR6kcJG80SZ ebbefYlf66cJ1r3NZJGKWjLpzxI3zRCTT0amntT7tr/fO+tQHN7Dy9fTDPG7YdjD3eyWWqsHO1Dn 2C7ntg9L3DLPwiSN2aQng/hc/GpyICUHwUVPzBfW6T38Z0R41AOlMM2PwVyBEw9/azFZx+4uEpdG FHk9bJgOmUrPXNMCAwEAAaOCAgswggIHMIGlBggrBgEFBQcBAQSBmDCBlTBRBggrBgEFBQcwAoZF aHR0cDovL3d3dy50cnVzdGNlbnRlci5kZS9jZXJ0c2VydmljZXMvY2FjZXJ0cy90Y19jbGFzczFf TDFfQ0FfSVguY3J0MEAGCCsGAQUFBzABhjRodHRwOi8vb2NzcC5peC50Y2NsYXNzMS50Y3VuaXZl cnNhbC1pLnRydXN0Y2VudGVyLmRlMB8GA1UdIwQYMBaAFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMAwG A1UdEwEB/wQCMAAwSgYDVR0gBEMwQTA/BgkqghQALAEBAQEwMjAwBggrBgEFBQcCARYkaHR0cDov L3d3dy50cnVzdGNlbnRlci5kZS9ndWlkZWxpbmVzMA4GA1UdDwEB/wQEAwIE8DAdBgNVHQ4EFgQU WcbfjY0//wFafU/f7U9EOpfjph4wYgYDVR0fBFswWTBXoFWgU4ZRaHR0cDovL2NybC5peC50Y2Ns YXNzMS50Y3VuaXZlcnNhbC1pLnRydXN0Y2VudGVyLmRlL2NybC92Mi90Y19DbGFzczFfTDFfQ0Ff SVguY3JsMDMGA1UdJQQsMCoGCCsGAQUFBwMCBggrBgEFBQcDBAYIKwYBBQUHAwcGCisGAQQBgjcU AgIwGgYDVR0RBBMwEYEPd2lsdG9uQGlzb2Mub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCjBgf2m5OH bgBcBzwzmF6eOnzoTQIgBwTxxmSuwuo+y89Rqu5F92t+bae5npJx+1exUJCG0RougAjPgUe7Blyl 0o0B8H4qVfWklN8Gxi9IGakH1Eua3k/DyHTfUGwlanKZDEGpL5MgZ89n6QZHnGfnfms5wql0WqGE 8UrgbJOzAr5zfkHfc4H/HzC0VNR+jYxFM4ynew1an4ewfNi2XthE8kp4IF7/TKAlRrcChtQvFzLf EQfmCf+j+/N5nRynhxaDBMRoar3VqB79Z6zrSMegtXwHcAiFo3G2n1ctRGhq4sGeCa5Zxl2HL/gF BJkKL5VAHC0ksP/kGhmRzIcO06+qMIIF2DCCBMCgAwIBAgIOBugAAQACSpYtJAz+xckwDQYJKoZI hvcNAQEFBQAweTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJDAi BgNVBAsTG1RDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQTEmMCQGA1UEAxMdVEMgVHJ1c3RDZW50 ZXIgVW5pdmVyc2FsIENBIEkwHhcNMDkxMTAzMTQwODE5WhcNMjUxMjMxMjE1OTU5WjB8MQswCQYD VQQGEwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBMMSBD QSBJWDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALvmkG7PYunpC6q2ENVH5XxdKydx mmjNVW3kou/k/vJ6YxHCV4rIfc+OZh9lRUvrgGJpvUaOi8VuWpUYKt6n8R91GierbTJT4/tNWGIs /xnlx6ANmi0hiFmEzR3xw8iKPrDl3ggkz/xALLpBI5S7gBKJNUi2hgTgAU+MuqmY/ByJ7R+KoceG mCYecmVr/s9l2QxkSxoJ9UMRYGYm4zNWmsk9PjRqeMblUEvIzYjkOWxQJp5ALLY7fDeyp/Xd3LNR y/TcggK41zre2jBcDfVC3RNpU1TpgCZCMx6l18xuymYJn4bwPb7GimEQ89H/W+Sy2y2yZQypfRes uidNQlzOCU8CAwEAAaOCAlkwggJVMIGaBggrBgEFBQcBAQSBjTCBijBSBggrBgEFBQcwAoZGaHR0 cDovL3d3dy50cnVzdGNlbnRlci5kZS9jZXJ0c2VydmljZXMvY2FjZXJ0cy90Y191bml2ZXJzYWxf cm9vdF9JLmNydDA0BggrBgEFBQcwAYYoaHR0cDovL29jc3AudGN1bml2ZXJzYWwtSS50cnVzdGNl bnRlci5kZTAfBgNVHSMEGDAWgBSSpHUspJ6+gUTrefyKxZWl6xB1czASBgNVHRMBAf8ECDAGAQH/ AgEAMFIGA1UdIARLMEkwBgYEVR0gADA/BgkqghQALAEBAQEwMjAwBggrBgEFBQcCARYkaHR0cDov L3d3dy50cnVzdGNlbnRlci5kZS9ndWlkZWxpbmVzMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU 6bgoHUbP/M34TpvF7ktg69g7P9Ewgf0GA1UdHwSB9TCB8jCB76CB7KCB6YZGaHR0cDovL2NybC50 Y3VuaXZlcnNhbC1JLnRydXN0Y2VudGVyLmRlL2NybC92Mi90Y191bml2ZXJzYWxfcm9vdF9JLmNy bIaBnmxkYXA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvQ049VEMlMjBUcnVzdENlbnRlciUyMFVuaXZl cnNhbCUyMENBJTIwSSxPPVRDJTIwVHJ1c3RDZW50ZXIlMjBHbWJILE9VPXJvb3RjZXJ0cyxEQz10 cnVzdGNlbnRlcixEQz1kZT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/MA0GCSqGSIb3 DQEBBQUAA4IBAQA5yMSb7r6Y7khyb43ncbYOkIzTssEVIahGkGhfSgTxOslohCHYpeYEdV2f0tTy S3dDMtyVy2C/AlXQrBywxRSXm2UKww+lHezYSTmVtam++vQeq1bnpuUBCIg1X2cF3UQkUBIiRGN5 8ZtXac6r1jNRT43wcDuOrVE6F381lmtoaGO2HArJ+N8dXs8rEaVj7czQxtMgb6r8aEh+bR64OkWq Eobzx70Atev+6hKfczN45yg5aNOlbdp20U7hVZWApuAbuM2sVu9FWUeYUts6biayMTlpdbEuJPCk nZeIXjMpxrW8B0A6DD26z3SMS056IfobOM3EQy9vtN947pmS5zocMYIDXTCCA1kCAQEwgY4wfDEL MAkGA1UEBhMCREUxHDAaBgNVBAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRy dXN0Q2VudGVyIENsYXNzIDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEg TDEgQ0EgSVgCDgbgAAEAAq9VCEIjHn/GMAkGBSsOAwIaBQCgggGjMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTAyNDExMjY1OFowIwYJKoZIhvcNAQkEMRYEFAn7 k1oxo9CphtK+3BNNADpGoyK9MIGfBgkrBgEEAYI3EAQxgZEwgY4wfDELMAkGA1UEBhMCREUxHDAa BgNVBAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgCDgbgAAEA Aq9VCEIjHn/GMIGhBgsqhkiG9w0BCRACCzGBkaCBjjB8MQswCQYDVQQGEwJERTEcMBoGA1UEChMT VEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBMMSBD QTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBMMSBDQSBJWAIOBuAAAQACr1UIQiMe f8YwDQYJKoZIhvcNAQEBBQAEggEAQQeO6gPzxg4B+He8kDmGquMU8cFo/rjEXMdABp9ef4ziETB0 C5oWARX4TOn8nsfpXQtZa/HT0db9SSUYK7xyBWBRpCPg29IBEWePnsVGAN2Dxqc0ulPF8HCzmaj1 eQcjWJZn4tG4gpOwkMfdFU7gPMF9pqCWjIgiM9P8XjuwzIQg86PDfvIGhyva68938NlABZJchNwF zhWEVnG9kI02APZZV/NhrG0iafeTyitDroTBzuF1kiW0JPmORJ8nSgznXVPt/ekREVe/DvEEoprq h5T6ZyznkoHY2HtBS+/i5/vrWMSE23iE+abwGQp/4EUDsBFPLbEpDmXoxjW+nYOdlAAAAAAAAA== --Apple-Mail=_3CB19E3D-569C-4A61-8005-2892AE764BB1-- From nathan@webr3.org Wed Oct 24 05:04:42 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B42421F8B71 for ; Wed, 24 Oct 2012 05:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phXMFucG9cJF for ; Wed, 24 Oct 2012 05:04:41 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5150021F8B70 for ; Wed, 24 Oct 2012 05:04:41 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so252786wey.31 for ; Wed, 24 Oct 2012 05:04:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=VXdHd5G3wHOT0+eFYc6B1/Tsnn6j4+4gA2qbuWrCLDo=; b=BKYz0z4bOqDj/CVBadOWVnoLapz9t5Uc9B06idH2qbtf2EXDlAntRPHeh1ZA0iAoN8 ksGugVR/6ay15bYjK1a4AhbfefjhB7pSucA1A+aquutye0Zr6iLuEkDUgSBQFfEG8m2z yMNa37GCU5CKLwpUQ5hCeA4WK8+wRG0Aaluk5wl1VHqEsG9J5ipwRP0c8RegV8rkyHwS 5RMMdaaRlzVPrwJcwqU2/r9wZIrgkKErHBXF/xN8UEczU71PFr/NhncQABwHGM+2E7oz 9N4A1DXkz3VUTUe5DcpncW3kQIQV7LznMt7zKi/kZnj8we6oETJhKfOuFMU6g11WS1aK u45Q== Received: by 10.180.101.230 with SMTP id fj6mr5421895wib.16.1351080280447; Wed, 24 Oct 2012 05:04:40 -0700 (PDT) Received: from [192.168.1.69] (host217-44-74-203.range217-44.btcentralplus.com. [217.44.74.203]) by mx.google.com with ESMTPS id p4sm4596239wix.0.2012.10.24.05.04.37 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Oct 2012 05:04:39 -0700 (PDT) Message-ID: <5087D92D.8000207@webr3.org> Date: Wed, 24 Oct 2012 13:03:57 +0100 From: Nathan Organization: webr3 User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Robin Wilton References: <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <5083CCCF.2060407@webr3.org> <50842789.3080301@openlinksw.com> <50845268.4010509@webr3.org> <5084AC77.8030600@openlinksw.com> <50851512.9090803@webr3.org> <50852726.9030102@openlinksw.com> <5085360E.3080008@openlinksw.com> <50853CD8.8020005@w3.org> <5FB468E4-BDD3-4635-ACD0-A23540C08751@bblfish.net> <508562C2.1060905@w3.org> <3EF3A430-A6C5-4ADE-92B5-0744DFFD326B@isoc.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQlkKJWwpwNHQfn4tidRcENptn4gNB4zTbkxp5h4HFmsSWY2YPyg0rms8hmQ71zLOS1QsmRv X-Mailman-Approved-At: Thu, 25 Oct 2012 08:21:39 -0700 Cc: Halpin Harry , public-identity@w3.org, saag@ietf.org, "public-privacy@w3.org list" , public-webid@w3.org Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: nathan@webr3.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 12:04:42 -0000 Robin Wilton wrote: > > > > > > Robin Wilton > Technical Outreach Director - Identity and Privacy > Internet Society > > email: wilton@isoc.org > Phone: +44 705 005 2931 > Twitter: @futureidentity > > > > > On 24 Oct 2012, at 10:30, Ben Laurie wrote: > >> On 23 October 2012 10:58, Robin Wilton wrote: >>> >>> On 23 Oct 2012, at 09:44, Ben Laurie wrote: >>> >>> >>> >>> >>> Not disagreeing with any of the above, but observing that: >>> >>> a) There's no particular reason you could not have an email per site >>> as well as a key per site. >>> >>> b) Linkability it not, as you say, inherently bad. The problem occurs >>> when you have (effectively) no choice about linkability. >>> >>> >>> >>> But it's very hard to use either of those mechanisms (separation through >>> emails or keys) without giving some third party the ability to achieve total >>> linkability. (In other words, both options remove effective choice). >> I agree that emails are a problem, but not at all sure why keys are? >> In the case of appropriate selective disclosure mechanisms, even if >> there were a third party involved, they would not be able to link uses >> of the keys. Also, if you insist on using linkable keys, then per-site >> keys do not involve third parties. >> > > It may just be that I'm not getting a clear mental picture of your architecture. But here was my thinking: > > - If you use symmetric keys, you get a system which can't scale unless you opt for Schneier's idea of a key server… but then the key server becomes a point of potential panopticality. > > - If you use PKI, *and* you want your communicating parties to be able to validate the certs they're relying on, then you have to design a CRL- or OCSP-like mechanism into the architecture, and again you end up with a component which is potentially panoptical. (Plus, you have to address the 20-year-old problem of how to make PKI usable by human beings, when recent history suggests that PKI only takes off where human beings are kept well away from it). CRL is pretty much built in to WebID, if you remove a public key from the document pointed to by your uri-identifier, then it's no longer valid for use in WebID - auth can't happen, rendering the cert useless for WebID. From melvincarvalho@gmail.com Wed Oct 24 07:24:28 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B1C21F86F6 for ; Wed, 24 Oct 2012 07:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suUEXpXSNaEO for ; Wed, 24 Oct 2012 07:24:27 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1655D21F86AA for ; Wed, 24 Oct 2012 07:24:27 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so868858iec.31 for ; Wed, 24 Oct 2012 07:24:26 -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=5GnuLfdNr0thDykrpZ3w6WzaCgCEsLDjihB9e99iOu8=; b=q6EP5ZWTxmalxQ/XOeXR6QWPbquxuhzzOBpeJN6n08MX48zB/KRBYvpWcYe31NLRzA CISS1e8Abta5qTNlClxAwF8B4C5T94TnhXIEFXtXW9BbNJFT4CKoF2BUKzCV5Qh2N2uL 1/UNDAR4LoSnyBAkF9CBksV2+Semu3L2/8P178GquBAJ+h0eh6op70TlLypSiKmguY3u ChhNTPGr5DTrUwBQmkj4TR2s83UAnx244ElV+T/1KbVFvb9v5Oo7hX8FBomz4yhr87kb NcQWe+P2DQtSfRQ9v9NJl8mmEuNATAOKfwT82J1ikYuqgUQRCLmEbhJ0LQ2pfle85C75 XQtg== MIME-Version: 1.0 Received: by 10.50.193.131 with SMTP id ho3mr1082477igc.51.1351088666583; Wed, 24 Oct 2012 07:24:26 -0700 (PDT) Received: by 10.42.247.129 with HTTP; Wed, 24 Oct 2012 07:24:26 -0700 (PDT) In-Reply-To: <5087F51D.3040503@openlinksw.com> References: <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <5083CCCF.2060407@webr3.org> <50842789.3080301@openlinksw.com> <50845268.4010509@webr3.org> <5084AC77.8030600@openlinksw.com> <50851512.9090803@webr3.org> <50852726.9030102@openlinksw.com> <5085360E.3080008@openlinksw.com> <50853CD8.8020005@w3.org> <5FB468E4-BDD3-4635-ACD0-A23540C08751@bblfish.net> <508562C2.1060905@w3.org> <3EF3A430-A6C5-4ADE-92B5-0744DFFD326B@isoc.org> <5087D92D.8000207@webr3.org> <5087F51D.3040503@openlinksw.com> Date: Wed, 24 Oct 2012 16:24:26 +0200 Message-ID: From: Melvin Carvalho To: Kingsley Idehen Content-Type: multipart/alternative; boundary=14dae934106308233a04ccced8e9 X-Mailman-Approved-At: Thu, 25 Oct 2012 08:21:39 -0700 Cc: Halpin Harry , Robin Wilton , nathan@webr3.org, public-identity@w3.org, saag@ietf.org, "public-privacy@w3.org list" , public-webid@w3.org Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 14:24:28 -0000 --14dae934106308233a04ccced8e9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 24 October 2012 16:03, Kingsley Idehen wrote: > On 10/24/12 8:03 AM, Nathan wrote: > >> Robin Wilton wrote: >> >>> >>> >>> >>> >>> >>> Robin Wilton >>> Technical Outreach Director - Identity and Privacy >>> Internet Society >>> >>> email: wilton@isoc.org >>> Phone: +44 705 005 2931 >>> Twitter: @futureidentity >>> >>> >>> >>> >>> On 24 Oct 2012, at 10:30, Ben Laurie wrote: >>> >>> On 23 October 2012 10:58, Robin Wilton wrote: >>>> >>>>> >>>>> On 23 Oct 2012, at 09:44, Ben Laurie wrote: >>>>> >>>>> >>>>> >>>>> >>>>> Not disagreeing with any of the above, but observing that: >>>>> >>>>> a) There's no particular reason you could not have an email per site >>>>> as well as a key per site. >>>>> >>>>> b) Linkability it not, as you say, inherently bad. The problem occurs >>>>> when you have (effectively) no choice about linkability. >>>>> >>>>> >>>>> >>>>> But it's very hard to use either of those mechanisms (separation >>>>> through >>>>> emails or keys) without giving some third party the ability to achiev= e >>>>> total >>>>> linkability. (In other words, both options remove effective choice). >>>>> >>>> I agree that emails are a problem, but not at all sure why keys are? >>>> In the case of appropriate selective disclosure mechanisms, even if >>>> there were a third party involved, they would not be able to link uses >>>> of the keys. Also, if you insist on using linkable keys, then per-site >>>> keys do not involve third parties. >>>> >>>> >>> It may just be that I'm not getting a clear mental picture of your >>> architecture. But here was my thinking: >>> - If you use symmetric keys, you get a system which can't scale unless >>> you opt for Schneier's idea of a key server=85 but then the key server >>> becomes a point of potential panopticality. >>> >>> - If you use PKI, *and* you want your communicating parties to be able >>> to validate the certs they're relying on, then you have to design a CRL= - or >>> OCSP-like mechanism into the architecture, and again you end up with a >>> component which is potentially panoptical. (Plus, you have to address t= he >>> 20-year-old problem of how to make PKI usable by human beings, when rec= ent >>> history suggests that PKI only takes off where human beings are kept we= ll >>> away from it). >>> >> >> CRL is pretty much built in to WebID, if you remove a public key from th= e >> document pointed to by your uri-identifier, then it's no longer valid fo= r >> use in WebID - auth can't happen, rendering the cert useless for WebID. >> >> >> >> > For sake of clarity, Nathan is speaking about the WebID authentication > protocol. > > A WebID on its own refers to an resolvable (de-referencable) identifier. > The WebID protocol verifies the aforementioned identifier (entity > denotation mechanism) via a combination of cryptography and entity > relationship semantics oriented logic. Kingsley, thanks for pointing this out. I think some of the confusion arises from the fact that a webid is sometimes not that clearly defined, and people focus on the protocol. In particular a WebID is a URI that references an Agent (human or machine) Similarly, email will become WebIDs using the webfinger spec (when that's complete) It can be argued that OAuth/OpenID identifiers are also WebID but with a different auth protocol. Mozilla persona, although certainly useful, would possibly not fit into the same category, as they use a proprietary identification system. The whole idea is that WebID brings things together at an architectural level. "The WebID Protocol", certs, X.509 are implementation details really. > > > -- > > Regards, > > Kingsley Idehen > Founder & CEO > OpenLink Software > Company Web: http://www.openlinksw.com > Personal Weblog: http://www.openlinksw.com/**blog/~kidehen > Twitter/Identi.ca handle: @kidehen > Google+ Profile: https://plus.google.com/**112399767740508618350/about > LinkedIn Profile: http://www.linkedin.com/in/**kidehen > > > > > > --14dae934106308233a04ccced8e9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On 24 October 2012 16:03, Kingsley Idehe= n <kidehen@openlinksw.com> wrote:
On 10/24/12 8:03 AM, Nathan wrote:<= br>
Robin Wilton wrote:





Robin Wilton
Technical Outreach Director - Identity and Privacy
Internet Society

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




On 24 Oct 2012, at 10:30, Ben Laurie wrote:

On 23 October 2012 10:58, Robin Wilton <wilton@isoc.org> wrote:

On 23 Oct 2012, at 09:44, Ben Laurie wrote:

<snip>


Not disagreeing with any of the above, but observing that:

a) There's no particular reason you could not have an email per site as well as a key per site.

b) Linkability it not, as you say, inherently bad. The problem occurs
when you have (effectively) no choice about linkability.



But it's very hard to use either of those mechanisms (separation throug= h
emails or keys) without giving some third party the ability to achieve tota= l
linkability. (In other words, both options remove effective choice).
I agree that emails are a problem, but not at all sure why keys are?
In the case of appropriate selective disclosure mechanisms, even if
there were a third party involved, they would not be able to link uses
of the keys. Also, if you insist on using linkable keys, then per-site
keys do not involve third parties.


It may just be that I'm not getting a clear mental picture of your arch= itecture. But here was my thinking:
- If you use symmetric keys, you get a system which can't scale unless = you opt for Schneier's idea of a key server=85 but then the key server = becomes a point of potential panopticality.

- If you use PKI, *and* you want your communicating parties to be able to v= alidate the certs they're relying on, then you have to design a CRL- or= OCSP-like mechanism into the architecture, and again you end up with a com= ponent which is potentially panoptical. (Plus, you have to address the 20-y= ear-old problem of how to make PKI usable by human beings, when recent hist= ory suggests that PKI only takes off where human beings are kept well away = from it).

CRL is pretty much built in to WebID, if you remove a public key from the d= ocument pointed to by your uri-identifier, then it's no longer valid fo= r use in WebID - auth can't happen, rendering the cert useless for WebI= D.




For sake of clarity, Nathan is speaking about the WebID authentication prot= ocol.

A WebID on its own refers to an resolvable (de-referencable) identifier. Th= e WebID protocol verifies the aforementioned identifier (entity denotation = mechanism) via a combination of cryptography and entity relationship semant= ics oriented logic.

Kingsley, thanks for pointing this out.

I think some of the= confusion arises from the fact that a webid is sometimes not that clearly = defined, and people focus on the protocol.

In particular a WebID is = a URI that references an Agent (human or machine)

Similarly, email will become WebIDs using the webfinger spec (when that= 's complete)

It can be argued that OAuth/OpenID identifiers are = also WebID but with a different auth protocol.

Mozilla persona, alth= ough certainly useful, would possibly not fit into the same category, as th= ey use a proprietary identification system.

The whole idea is that WebID brings things together at an architectural= level.=A0 "The WebID Protocol", certs, X.509 are implementation = details really.
=A0


--

Regards,

Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http:/= /www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/11239976774050861835= 0/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen






--14dae934106308233a04ccced8e9-- From melvincarvalho@gmail.com Wed Oct 24 08:09:20 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2866721F86A0 for ; Wed, 24 Oct 2012 08:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.316 X-Spam-Level: X-Spam-Status: No, score=-3.316 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xT+azxTcURR for ; Wed, 24 Oct 2012 08:09:18 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 75B9421F8683 for ; Wed, 24 Oct 2012 08:09:18 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so956933iec.31 for ; Wed, 24 Oct 2012 08:09:18 -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=1BOEWZjalMqhcVDcXvhJrlFwm1E+GIyfBRqTE7fdzx8=; b=ObB627BBEFBjjIMOc2dYho4p0Nx+QwptP+LhiY/9/qnk6CXfCqKKAEo8Fe9n+1PNo7 Eax5IzRU1nemL4HKxri4wJ9PmtKUQiU7kSlHugEPgV+4NcajftsKlWvasL1lxxwAIQTD oJ1HdxnlAuPA8wiEr1kudunrCdP3p+C9XyIWy+jFwG6n4OzQMkjRaquoPxi+Mkb+K1kX +CHejNmgw4EEFAKRWeOsyqaOnNmg7tiFmxDMsrRfMf7E+HemcZif3S5x4BlZonJuHsVY y4nRmkbB/ocMo/sWPz1Ncspi3jbs5AlF5cU3CIBtq2Yf7kr2HrvtmWN2piMdD46qhUur c4QQ== MIME-Version: 1.0 Received: by 10.50.242.74 with SMTP id wo10mr2755191igc.51.1351091357956; Wed, 24 Oct 2012 08:09:17 -0700 (PDT) Received: by 10.42.247.129 with HTTP; Wed, 24 Oct 2012 08:09:17 -0700 (PDT) In-Reply-To: <43EEDAE2-6E5F-4D2E-BC1E-516408DCD3CC@bblfish.net> References: <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <5083CCCF.2060407@webr3.org> <50842789.3080301@openlinksw.com> <50845268.4010509@webr3.org> <5084AC77.8030600@openlinksw.com> <50851512.9090803@webr3.org> <50852726.9030102@openlinksw.com> <5085360E.3080008@openlinksw.com> <50853CD8.8020005@w3.org> <5FB468E4-BDD3-4635-ACD0-A23540C08751@bblfish.net> <508562C2.1060905@w3.org> <3EF3A430-A6C5-4ADE-92B5-0744DFFD326B@isoc.org> <5087D92D.8000207@webr3.org> <5087F51D.3040503@openlinksw.com> <43EEDAE2-6E5F-4D2E-BC1E-516408DCD3CC@bblfish.net> Date: Wed, 24 Oct 2012 17:09:17 +0200 Message-ID: From: Melvin Carvalho To: Henry Story Content-Type: multipart/alternative; boundary=f46d044787d3733cae04cccf783a X-Mailman-Approved-At: Thu, 25 Oct 2012 08:21:39 -0700 Cc: Robin Wilton , public-identity@w3.org, "saag@ietf.org" , "public-privacy@w3.org list" , public-webid@w3.org Subject: Re: [saag] Liking Linkability X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 15:09:20 -0000 --f46d044787d3733cae04cccf783a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 24 October 2012 17:00, Henry Story wrote: > > On 24 Oct 2012, at 16:24, Melvin Carvalho > wrote: > > > > On 24 October 2012 16:03, Kingsley Idehen wrote: > >> On 10/24/12 8:03 AM, Nathan wrote: >> >>> Robin Wilton wrote: >>> >>>> >>>> >>>> >>>> >>>> On 24 Oct 2012, at 10:30, Ben Laurie wrote: >>>> >>>> On 23 October 2012 10:58, Robin Wilton wrote: >>>>> >>>>>> >>>>>> On 23 Oct 2012, at 09:44, Ben Laurie wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Not disagreeing with any of the above, but observing that: >>>>>> >>>>>> a) There's no particular reason you could not have an email per site >>>>>> as well as a key per site. >>>>>> >>>>>> b) Linkability it not, as you say, inherently bad. The problem occur= s >>>>>> when you have (effectively) no choice about linkability. >>>>>> >>>>>> >>>>>> >>>>>> But it's very hard to use either of those mechanisms (separation >>>>>> through >>>>>> emails or keys) without giving some third party the ability to >>>>>> achieve total >>>>>> linkability. (In other words, both options remove effective choice). >>>>>> >>>>> I agree that emails are a problem, but not at all sure why keys are? >>>>> In the case of appropriate selective disclosure mechanisms, even if >>>>> there were a third party involved, they would not be able to link use= s >>>>> of the keys. Also, if you insist on using linkable keys, then per-sit= e >>>>> keys do not involve third parties. >>>>> >>>>> >>>> It may just be that I'm not getting a clear mental picture of your >>>> architecture. But here was my thinking: >>>> - If you use symmetric keys, you get a system which can't scale unless >>>> you opt for Schneier's idea of a key server=85 but then the key server >>>> becomes a point of potential panopticality. >>>> >>>> - If you use PKI, *and* you want your communicating parties to be able >>>> to validate the certs they're relying on, then you have to design a CR= L- or >>>> OCSP-like mechanism into the architecture, and again you end up with a >>>> component which is potentially panoptical. (Plus, you have to address = the >>>> 20-year-old problem of how to make PKI usable by human beings, when re= cent >>>> history suggests that PKI only takes off where human beings are kept w= ell >>>> away from it). >>>> >>> >>> CRL is pretty much built in to WebID, if you remove a public key from >>> the document pointed to by your uri-identifier, then it's no longer val= id >>> for use in WebID - auth can't happen, rendering the cert useless for We= bID. >>> >> > +1 Nathan. > > ( btw. It is always good to point people to the spec too > http://webid.info/spec is the short url for it. ) > > >>> >>> >>> >> For sake of clarity, Nathan is speaking about the WebID authentication >> protocol. >> >> A WebID on its own refers to an resolvable (de-referencable) identifier. >> The WebID protocol verifies the aforementioned identifier (entity >> denotation mechanism) via a combination of cryptography and entity >> relationship semantics oriented logic. > > > Kingsley, thanks for pointing this out. > > I think some of the confusion arises from the fact that a webid is > sometimes not that clearly defined, and people focus on the protocol. > > > The spec has a definition that seems pretty reasonable, ( though I think > we should remove the reference to "intentions" ) > > http://www.w3.org/2005/Incubator/webid/spec/#terminology > > WebIDA URI that refers to an Agent - Person, Robot, Group or other thing > that can have Intentions. The WebID should be a URI which when dereferenc= ed > returns a representation whose description uniquely identifies the Agent > who is the controller of a public key. In our example the WebID refers to > Bob. > A WebID is usually a URL with a #tag, as the meaning of such a URL is > defined in the document refered to by the WebID URL without the #tag . > > > > In particular a WebID is a URI that references an Agent (human or machine= ) > > Similarly, email will become WebIDs using the webfinger spec (when that's > complete) > > It can be argued that OAuth/OpenID identifiers are also WebID but with a > different auth protocol. > > Mozilla persona, although certainly useful, would possibly not fit into > the same category, as they use a proprietary identification system. > > The whole idea is that WebID brings things together at an architectural > level. "The WebID Protocol", certs, X.509 are implementation details > really. > > > I would not say just implementation details. From the philosophical theor= y > of reference > ( eg: Gareth Evans's book: The variety of Reference ) they may be, but in > everyday usage > how these things are implemented is quite important, and so are the > distinctions. > > According to the WebID spec definition: > - OpenID is close [1] though they have a URL for a web page rather than > an agent (not a big deal), but more importantly they don't make use of th= e > URL to get the attributes, which is what WebID does. They certainly don't > publish the public key in the OpenId profile. > - webfinger does indeed give a method to dereference a mailto: uri, > which could be used for a WebID protocol. > the current draft of webfinger allows dereferencing a mailto: URI ... in fact it is anyURI > - I don't think OAuth is working with URIs at all > - Mozilla Persona could use WebIDs [2] and it would improve their > protocol so dramatically, it is evident that they will at some point. > > Henry > > [1] https://blogs.oracle.com/bblfish/entry/what_does_foaf_ssl_give > [2] > http://security.stackexchange.com/questions/5406/what-are-the-main-advant= ages-and-disadvantages-of-webid-compared-to-browserid > > > >> >> >> -- >> >> Regards, >> >> Kingsley Idehen >> Founder & CEO >> OpenLink Software >> Company Web: http://www.openlinksw.com >> Personal Weblog: http://www.openlinksw.com/**blog/~kidehen >> Twitter/Identi.ca handle: @kidehen >> Google+ Profile: https://plus.google.com/**112399767740508618350/about >> LinkedIn Profile: http://www.linkedin.com/in/**kidehen >> >> >> >> >> >> > > Social Web Architect > http://bblfish.net/ > > --f46d044787d3733cae04cccf783a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On 24 October 2012 17:00, Henry Story <henry.story@bblfish.net> wrote:

On 24 O= ct 2012, at 16:24, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

=


On 24 October 2012 16:03, Kingsley Idehen <kidehen@openlinksw.com= > wrote:
On 10/24/12 8:03 AM, Nathan wrote:
Robin Wilton wrote:




On 24 Oct 2012, at 10:30, Ben Laurie wrote:

On 23 October 2012 10:58, Robin Wilton <wilton@isoc.org> wrote:

On 23 Oct 2012, at 09:44, Ben Laurie wrote:

<snip>


Not disagreeing with any of the above, but observing that:

a) There's no particular reason you could not have an email per site as well as a key per site.

b) Linkability it not, as you say, inherently bad. The problem occurs
when you have (effectively) no choice about linkability.



But it's very hard to use either of those mechanisms (separation throug= h
emails or keys) without giving some third party the ability to achieve tota= l
linkability. (In other words, both options remove effective choice).
I agree that emails are a problem, but not at all sure why keys are?
In the case of appropriate selective disclosure mechanisms, even if
there were a third party involved, they would not be able to link uses
of the keys. Also, if you insist on using linkable keys, then per-site
keys do not involve third parties.


It may just be that I'm not getting a clear mental picture of your arch= itecture. But here was my thinking:
- If you use symmetric keys, you get a system which can't scale unless = you opt for Schneier's idea of a key server=85 but then the key server = becomes a point of potential panopticality.

- If you use PKI, *and* you want your communicating parties to be able to v= alidate the certs they're relying on, then you have to design a CRL- or= OCSP-like mechanism into the architecture, and again you end up with a com= ponent which is potentially panoptical. (Plus, you have to address the 20-y= ear-old problem of how to make PKI usable by human beings, when recent hist= ory suggests that PKI only takes off where human beings are kept well away = from it).

CRL is pretty much built in to WebID, if you remove a public key from the d= ocument pointed to by your uri-identifier, then it's no longer valid fo= r use in WebID - auth can't happen, rendering the cert useless for WebI= D.

+1 Nathan.=A0

( btw. It is always good to = point people to the spec too http://webid.info/spec is the short url for it. )

=




For sake of clarity, Nathan is speaking about the WebID authentication prot= ocol.

A WebID on its own refers to an resolvable (de-referencable) identifier. Th= e WebID protocol verifies the aforementioned identifier (entity denotation = mechanism) via a combination of cryptography and entity relationship semant= ics oriented logic.

Kingsley, thanks for pointing this out.

I think some of the= confusion arises from the fact that a webid is sometimes not that clearly = defined, and people focus on the protocol.

The spec has a definition that seems pretty reaso= nable, ( though I think we should remove the reference to "intentions&= quot; )


WebID
A URI that refers to an Agent - Person, Robot, Group or other thing = that can have Intentions. The WebID should be a URI which when dereferenced= returns a representation whose description uniquely identifies the Agent w= ho is the controller of a public key. In our example the WebID refers to=A0= Bob. A WebID is usually a URL= with a #tag, as the meaning of such a URL is defined in the document refer= ed to by the WebID URL without the #tag .


=

In particular a WebID is a URI that ref= erences an Agent (human or machine)

Similarly, email will become WebIDs using the webfinger spec (when that= 's complete)

It can be argued that OAuth/OpenID identifiers are = also WebID but with a different auth protocol.

Mozilla persona, alth= ough certainly useful, would possibly not fit into the same category, as th= ey use a proprietary identification system.

The whole idea is that WebID brings things together at an architectural= level.=A0 "The WebID Protocol", certs, X.509 are implementation = details really.

I wou= ld not say just implementation details. From the philosophical theory of re= ference=A0
( eg: Gareth Evans's book: The variety of Reference )=A0they may b= e, but in everyday usage=A0
how these things are implemented is q= uite important, and so are the distinctions.

Accor= ding to the WebID spec definition:
=A0- OpenID is close [1] though they have a URL for a web page rather = than an agent (not a big deal), but more importantly=A0they don't make = use of the URL to get the attributes, which is what WebID does. They certai= nly don't publish the public key in the OpenId profile.
=A0- webfinger does indeed give a method to dereference a mailto: uri,= which could be used for a WebID protocol.

the current draft of webfinger allows dereferencing a mailto: URI ..= . in fact it is anyURI
=A0
=A0- I don't think OAuth is working with URIs at all
=A0- Mozilla Persona could use WebIDs [2] and it would improve their pro= tocol so dramatically, it is evident that they will at some point.

=A0 Henry


= Social Web Architect
http://bblfish.net/


--f46d044787d3733cae04cccf783a-- From stephen.farrell@cs.tcd.ie Fri Oct 26 04:21:15 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE59A21F8550 for ; Fri, 26 Oct 2012 04:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.628 X-Spam-Level: X-Spam-Status: No, score=-102.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EB+wS3Yax4hO for ; Fri, 26 Oct 2012 04:21:14 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A09E521F854F for ; Fri, 26 Oct 2012 04:21:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0F7C9C794; Fri, 26 Oct 2012 12:20:52 +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 CRtQEdSjlL9I; Fri, 26 Oct 2012 12:20:50 +0100 (IST) Received: from [10.87.48.4] (unknown [86.44.76.190]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EE14BC790; Fri, 26 Oct 2012 12:20:49 +0100 (IST) Message-ID: <508A7211.50108@cs.tcd.ie> Date: Fri, 26 Oct 2012 12:20:49 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121017 Thunderbird/16.0.1 MIME-Version: 1.0 To: "saag@ietf.org" X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [saag] ietf-85 draft agenda X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 11:21:15 -0000 Hiya, A little late (naughty ADs;-) but we just posted a draft agenda for saag@ietf-85 [1] At the moment we're waiting on confirmation that we have a 2nd invited talk, so there's still time to suggest another topic if you want. In that case please send mail to Sean and I, but given how close we are to the meeting, its probably only worth suggesting something where you have a confirmed speaker (which can of course be yourself). Don't be shy about making suggestions, we're good at saying no if its not the right kind of thing:-) Thanks, S. [1] http://www.ietf.org/proceedings/85/agenda/agenda-85-saag From stephen.farrell@cs.tcd.ie Mon Oct 29 13:46:25 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5A921F871D; Mon, 29 Oct 2012 13:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPjbcul9PEef; Mon, 29 Oct 2012 13:46:24 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4E321F870C; Mon, 29 Oct 2012 13:46:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7434FC77B; Mon, 29 Oct 2012 20:46:01 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Pp2h1LZO0hf; Mon, 29 Oct 2012 20:45:59 +0000 (GMT) Received: from [10.87.48.4] (unknown [86.42.183.189]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4325CBE25; Mon, 29 Oct 2012 20:45:59 +0000 (GMT) Message-ID: <508EEB07.8080807@cs.tcd.ie> Date: Mon, 29 Oct 2012 20:45:59 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121017 Thunderbird/16.0.1 MIME-Version: 1.0 To: Michael Richardson References: <015901cdb0d3$d38cf1f0$7aa6d5d0$@a-star.edu.sg> <1116.1351177270@sandelman.ca> <02a101cdb5f5$51109a70$f331cf50$@a-star.edu.sg> <508EBD6B.1070606@cs.tcd.ie> <10703.1351542774@obiwan.sandelman.ca> In-Reply-To: <10703.1351542774@obiwan.sandelman.ca> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , roll@ietf.org, "'Keoh, Sye Loong'" , saag@ietf.org, 6lowpan@ietf.org, Carsten Bormann Subject: Re: [saag] SOLACE things at SAAG X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 20:46:25 -0000 Hiya, So Carsten volunteered to give saag a heads-up on the problem this time. If he and Cullen want to arm-wrestle that's fine:-) I'm sure either would do a fine job. I didn't mean to say anything about the solace draft being good, bad or indifferent. But I figured someone is working on this problem somewhere and would like to make sure that whatever solution looks like it'll be adopted is something that wouldn't cause saag folk to have fits. Cheers, S. On 10/29/2012 08:32 PM, Michael Richardson wrote: > >>>>>> "Stephen" == Stephen Farrell writes: > Stephen> Would it be timely to spend 10 minutes on this during the saag > Stephen> session? > > I think, if you want to talk something SOLACE related which is more > concrete than a possible SOLACE IRTF "charter", then maybe have Cullen > talk about: > > http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/papers/CullenJennings.pdf > http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/slides/Cullen1.pdf > > Stephen> I'd really like that the security area not end up being surprised > Stephen> by whatever is eventually decided so getting a presentation at > Stephen> saag would be useful at the point where you more or less know > Stephen> the direction, but are still flexible enough to deal with someone > Stephen> who e.g. points out significant security issues. > > Except that: > 1) the constrained devices are more constrained than the IP phones > described. > > 2) the constrained devices probably can not be attacked/p0wned until > after they get on the network, and so actually authenticating to the > network is the "application" > > Cullen's slides provide a really good starting explanation. > While the details of the ultimate answer are going to be a bit different > in small ways, the basic architecture he presents has been articulated > repeatedly by many. > > So, if your aim is to get more security geeks thinking about attacks, > and about defenses, in advance of an actual proposed protocol (and > SOLACE is an I*R*TF group, recall. A protocol might not be the result > anyway), then I suggest giving Cullen a few minutes to talk about his > slide 7,8,9. > > Stephen> It might be that waiting another meeting cycle or two would be > Stephen> better if the basic ideas aren't yet firmed up. > > One meeting cycle won't help. Four might. > From lear@cisco.com Tue Oct 30 07:29:45 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E5F21F8589 for ; Tue, 30 Oct 2012 07:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqOmHs+XS3+h for ; Tue, 30 Oct 2012 07:29:42 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9DB21F8484 for ; Tue, 30 Oct 2012 07:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=218; q=dns/txt; s=iport; t=1351607382; x=1352816982; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=Czy/sSq4EmRGJabjXVkoyy/ZXKgP3K3LEIZKb7SAcUU=; b=UTzOwXsjaz9zd5vIe677Q0OWm4AEc/hdWdzrRkMZjh4CSpH81KG++mx8 MQIJcu6gw1zuC3CQ74/O3VoKaO9IX2cCuNaXIJhAt38aPYeIB4dnniZu6 5RwCfs+rYFGN8wssQo8b6Nc/STZlzDuRrfZPTg6tp2wu/tN8LQUtXfRDx o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcLAGnjj1CQ/khL/2dsb2JhbABEgzaCG0eIFLQUAQMBA4EAgQiCNwEQVTYCBRYLAgsDAgECAUsNCAEBHodkC5tMgSyNLII7kDmBIJAhgRMDlXWOV4FrgnA X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="9214548" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 30 Oct 2012 14:29:39 +0000 Received: from dhcp-10-55-90-162.cisco.com (dhcp-10-55-90-162.cisco.com [10.55.90.162]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9UETd64014138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 30 Oct 2012 14:29:40 GMT Message-ID: <508FE453.7060506@cisco.com> Date: Tue, 30 Oct 2012 15:29:39 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "saag@ietf.org" X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [saag] Tribute to Peter Neumann in the New York Times X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 14:29:45 -0000 Many of us grew up on RISKS, and its ACM column. Today, John Markoff fetes Peter Neumann and his work. It's a fun article! http://www.nytimes.com/2012/10/30/science/rethinking-the-computer-at-80.html Eliot