From palmer@google.com Mon Apr 1 15:28:30 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4800511E80F6 for ; Mon, 1 Apr 2013 15:28: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTJdJKqen0aC for ; Mon, 1 Apr 2013 15:28:29 -0700 (PDT) Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2E411E80FB for ; Mon, 1 Apr 2013 15:28:29 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id m1so3120643ves.41 for ; Mon, 01 Apr 2013 15:28:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=CSS/ViO1qVv9ZkLtFlEUHxrM4gJsxa7st2JQtKTrspg=; b=ctT6v9MXUiR1PPhbgIc5m0FjN2hMt0B+zmZyAg6eqdSC3oWWm4HugS9gL8/PhGQ5QQ drxEu0vSWAr/g4OVjLEWAC858TnOHhO5j3QHstiwQi/MlJ0AJ2z7VIm1aU+QshA8IL6/ M5/Bblqw/iXKMB1OLfvjhALFNGuopmVxzsYBZfgBPtY2ESyocGI5g7EIgnUkDyMVhYrG spZVq965mitO/603dhG8wx8w0DTBZB7KslqiEcxs04xhZnutepfrKgtOW6UkwUn/tWpO aJZV+y0VoSYEygAjBQx154OIiupouEI8r6Ytj0Gc8rKbQMarO0U0FqHmNzZx1RM4F37l usZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=CSS/ViO1qVv9ZkLtFlEUHxrM4gJsxa7st2JQtKTrspg=; b=ULq81urjZ1YH4sTkv1ah+eOxojpuSNN9Opl5EPVYUnlj44RRELZZTukfxaGvVltCYw DbOWPIhsrapIpotjRaaEhuKsYrA56zb6/+PAW0QfMCRjnmdF3Pqmq4CbKSiRLumxAKIW j0R6I6A8kW+mEM3pMIZazMBgy01pI49MZ/Xy469QkChEOipUL6aWr4R23FrZ1UbPe+MZ lLhPaK9FEom3uxzTXhoF05LgK3tgi6pVTIryFxS8P4YfTolCDpgkkz6x907rzI5CEsfE ETf4hV5veq/K3m4lNDs1eg1nPnoECw7NDxUQzNwXoHLXcvkrhadX+SVsE2Jj9o9Fn+nz SG8g== MIME-Version: 1.0 X-Received: by 10.52.21.175 with SMTP id w15mr9115505vde.100.1364855297728; Mon, 01 Apr 2013 15:28:17 -0700 (PDT) Received: by 10.58.179.19 with HTTP; Mon, 1 Apr 2013 15:28:17 -0700 (PDT) In-Reply-To: References: <058.106749b7ec8d8775c9a7c03ff71b6de4@trac.tools.ietf.org> <073.ec94ba2e71513562888c29f0af0b3306@trac.tools.ietf.org> Date: Mon, 1 Apr 2013 15:28:17 -0700 Message-ID: From: Chris Palmer To: Tom Ritter Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQn6fb0LihWWDOpd1Af8TJP3nEcQ1AlqwJIcVXGKN4N6SHrE3Bh4rA2lqmBJRpiZwp1tVz3l5XH7n8TgOKwfq0vccBurBey+PNGqS6Mq1mdYr2lQ8e5CjII8WHy6R7ZBxuowoTcYJQuTt2IevmNjf/VxxSDmCEN7AnTu6cv/KQwo+bB7vf03sNYCBK1NaOSTZnPSCKQR Cc: websec issue tracker , IETF WebSec WG , Ryan Sleevi Subject: Re: [websec] #55: Clarify that the newest pinning information takes precedence X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 22:28:30 -0000 On Wed, Mar 27, 2013 at 7:54 PM, Tom Ritter wrote: > " The UA MUST evict all expired Known Pinned Hosts if at any time, an > expired Known Pinned Host exists in the cache" > > I use rrdtool to keep 5 years of statistics for my server. Once, I > accidentally set the date forward, to 2038, wiping out my statistics - > there was no way to recover, because rrdtool dutifully wiped all this > expired data. > > Using the word 'evict' seems particularly dangerous, for both active > ntp attacks, and accidental wiping. Yoav says the text works for him. I wonder if we can satisfy both by saying something like "the UA MUST ignore expired Known Pinned Hosts in the cache." That way, if the client machine gets its clocked fixed and the expired KPHs become un-expired, happiness will ensue once again. Ryan, thoughts? From ryan-ietfhasmat@sleevi.com Wed Apr 3 12:54:47 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F21DF21F8D61 for ; Wed, 3 Apr 2013 12:54:46 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwMSHNrMEl+e for ; Wed, 3 Apr 2013 12:54:46 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8943921F8C09 for ; Wed, 3 Apr 2013 12:54:46 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id D860D42862C; Wed, 3 Apr 2013 12:54:45 -0700 (PDT) Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPA id E37FF1D81BC; Wed, 3 Apr 2013 11:18:49 -0700 (PDT) Received: from 216.239.45.93 (proxying for 216.239.45.93) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Wed, 3 Apr 2013 11:18:50 -0700 Message-ID: <48b1f63e3c764f2ddc591feb00fc1d0a.squirrel@webmail.dreamhost.com> In-Reply-To: References: <058.106749b7ec8d8775c9a7c03ff71b6de4@trac.tools.ietf.org> <073.ec94ba2e71513562888c29f0af0b3306@trac.tools.ietf.org> Date: Wed, 3 Apr 2013 11:18:50 -0700 From: "Ryan Sleevi" To: "Chris Palmer" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG , websec issue tracker , Ryan Sleevi Subject: Re: [websec] #55: Clarify that the newest pinning information takes precedence X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ryan-ietfhasmat@sleevi.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 19:54:47 -0000 On Mon, April 1, 2013 3:28 pm, Chris Palmer wrote: > On Wed, Mar 27, 2013 at 7:54 PM, Tom Ritter wrote: > > > " The UA MUST evict all expired Known Pinned Hosts if at any time, an > > expired Known Pinned Host exists in the cache" > > > > I use rrdtool to keep 5 years of statistics for my server. Once, I > > accidentally set the date forward, to 2038, wiping out my statistics = - > > there was no way to recover, because rrdtool dutifully wiped all this > > expired data. > > > > Using the word 'evict' seems particularly dangerous, for both active > > ntp attacks, and accidental wiping. > > Yoav says the text works for him. I wonder if we can satisfy both by > saying something like "the UA MUST ignore expired Known Pinned Hosts > in the cache." That way, if the client machine gets its clocked fixed > and the expired KPHs become un-expired, happiness will ensue once > again. Ryan, thoughts? > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > Something like that works for me. The spec only needs to ensure that the visible client behaviour remains consistent - and ignoring expired Known Pin Hosts data is the desired effect of the present language, so its fine to specify as this. That said, I expect clients will probably continue with the "evict the cache" approach, which would be fine and spec-compliant. I think there'd only be an issue if there was language being proposed that said clients *should not* evict the cache - as you could make an argument on security considerations using Tom's example. From trevp@trevp.net Fri Apr 5 00:03:12 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8130121F9473 for ; Fri, 5 Apr 2013 00:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.479 X-Spam-Level: X-Spam-Status: No, score=0.479 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5CYb8gtwghk for ; Fri, 5 Apr 2013 00:03:12 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C950F21F942C for ; Fri, 5 Apr 2013 00:03:11 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id c10so264675wiw.2 for ; Fri, 05 Apr 2013 00:03:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=4BRk/pBCPpRLVn/wYDRD4cd3s128roCDiWfpxwQ/DYM=; b=ZMdVHb9tLIePwCzi0845os0Gze42N6qXJWRl8NhmDzSD9rl1Xn2kwd4tILXyMLrvaT bnJngPe69ppNtntLgKvNmi6bzoktWbqoAvBvx5QNPxuQ4ZF3gqLM9r4th7tF/Hn9rnDK wM1Nr6HQS9WiDiTsIFn6h0EO5zGgve6paMKDnDVBX9FBvkd9KJCZ66WWzaTFvt0E+hXM LN6aB1jx30R/HCdV3BXlvFGOE0H3r1CpPiZwoGXM6FIkmnE+FYSnw5DsA8eM49iW9tGm Mhz6khrCx2WQfeCsTb5PpxyX+556k7vKyHrnL73A0aV7hSCWB/06x1+NWjpuBX3nDdkf XqRA== MIME-Version: 1.0 X-Received: by 10.180.87.170 with SMTP id az10mr2001807wib.3.1365145390807; Fri, 05 Apr 2013 00:03:10 -0700 (PDT) Received: by 10.217.119.134 with HTTP; Fri, 5 Apr 2013 00:03:10 -0700 (PDT) X-Originating-IP: [166.137.187.20] In-Reply-To: <77D0BAFD-9345-4F92-A8A3-641DADA771AA@checkpoint.com> References: <058.4066f40ba1a0e0b17085c25af1721605@trac.tools.ietf.org> <073.92e203ac2ffbca6a9b6ecd285f8d0e00@trac.tools.ietf.org> <5B9868F5-6DF8-4D9E-BCE4-248063103A65@checkpoint.com> <77D0BAFD-9345-4F92-A8A3-641DADA771AA@checkpoint.com> Date: Fri, 5 Apr 2013 00:03:10 -0700 Message-ID: From: Trevor Perrin To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmlQouryXzeZBycxmvHDT/SQQSGP46AGDwy4wbZ6gEPMLtW8obAiLotdxCt86F9WHQPKbmi Cc: "" , Ryan Sleevi , websec issue tracker Subject: Re: [websec] #57: Re-add an upper limit to max-age X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 07:03:12 -0000 On Fri, Mar 29, 2013 at 7:05 PM, Yoav Nir wrote: > > Getting back to the subject of the thread, I still don't see the difference for a site operator between being bricked for 60 days and being bricked for a year. For an only retailer it's catastrophe either way. Hi Yoav, There are other things to consider when thinking about pin lifetimes: - Suppose a site foolishly sets a year-long pin to keys that will be expired in 6 months. A client who receives this pin and then visits the site 6 months later will perceive that the site is bricked for the next 6 months. - Suppose a site has a year-long pin to a set of end-entity keys. Suppose these keys are compromised by a hacker. For the next year, the site will be unable to change keys to re-establish security without a risk of "bricking" the site for clients with the old pin. - Suppose you purchase a domain name. The previous owner may have set long-term pins, meaning the name is not fully usable until these expire. So this isn't just a question of "how long might a site outage last". Longer pin lifetimes increase the *possibility* of a site outage, because there will be more old pins out there you have to stay consistent with. I do agree that a 30 or 60 day limit will be cold comfort if you brick your site for that long. Certainly, pinning will need other safeguards. One safeguard could be some sort of "pin activation", where new or changed pins are not accepted immediately, but must be observed for some period of time before they "activate". I know this WG considered a mechanism similar to TACK. TACK's exact mechanism doesn't translate well to HPKP, but perhaps there is something else to be done. It may be worth more thought. Trevor From ynir@checkpoint.com Fri Apr 5 01:48:36 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E139F21F8675 for ; Fri, 5 Apr 2013 01:48:36 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ihn-zIA75VUs for ; Fri, 5 Apr 2013 01:48:36 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id AC2C921F8614 for ; Fri, 5 Apr 2013 01:48:35 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r358mC1A004159; Fri, 5 Apr 2013 11:48:13 +0300 X-CheckPoint: {515E8DB0-4-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Fri, 5 Apr 2013 11:48:12 +0300 From: Yoav Nir To: Trevor Perrin Thread-Topic: [websec] #57: Re-add an upper limit to max-age Thread-Index: AQHOJ0X4m4jM1OHiCUi5AgAOGVjbxZiyNAIAgAAIBoCAACvZgIAHoQKAgAAJPACAAbiWgIAA/uQAgAA6nYCAAFEdAIAJwRkAgAAdWIA= Date: Fri, 5 Apr 2013 08:48:11 +0000 Message-ID: <5758B958-5B08-41D1-B473-E1DD6B78A324@checkpoint.com> References: <058.4066f40ba1a0e0b17085c25af1721605@trac.tools.ietf.org> <073.92e203ac2ffbca6a9b6ecd285f8d0e00@trac.tools.ietf.org> <5B9868F5-6DF8-4D9E-BCE4-248063103A65@checkpoint.com> <77D0BAFD-9345-4F92-A8A3-641DADA771AA@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.5] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3D5A8EAF93BE224F8723D7ED83F62C3C@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Ryan Sleevi , websec issue tracker Subject: Re: [websec] #57: Re-add an upper limit to max-age X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 08:48:37 -0000 On Apr 5, 2013, at 10:03 AM, Trevor Perrin wrote: > On Fri, Mar 29, 2013 at 7:05 PM, Yoav Nir wrote: >>=20 >> Getting back to the subject of the thread, I still don't see the differe= nce for a site operator between being bricked for 60 days and being bricked= for a year. For an only retailer it's catastrophe either way. >=20 >=20 > Hi Yoav, >=20 > There are other things to consider when thinking about pin lifetimes: >=20 > - Suppose a site foolishly sets a year-long pin to keys that will be > expired in 6 months. A client who receives this pin and then visits > the site 6 months later will perceive that the site is bricked for the > next 6 months. True. At least in the case of certificates, there was some discussion of ca= pping the maximum noted age to the expiration time of the certificate for t= hat connection. This is not a complete solution, though, because there is s= ome period of time (perhaps 1-2 weeks) where the site operator has a new, v= alid certificate, but the old one hasn't expired yet. A backup pin should work, as I believe the common practice would be to use = the backup pin in the following certificate request. And backup pins are ma= ndatory according to the draft. > - Suppose a site has a year-long pin to a set of end-entity keys. > Suppose these keys are compromised by a hacker. For the next year, > the site will be unable to change keys to re-establish security > without a risk of "bricking" the site for clients with the old pin. And that is why the draft now requires backup pins. At least, it's one reas= on. > - Suppose you purchase a domain name. The previous owner may have > set long-term pins, meaning the name is not fully usable until these > expire. Yeah, that's bad. Even worse is if an attacker manages to get a CA to issue= them a valid certificate. Users now note pins that match the bad certifica= te, and they can be blocked from going to the real site for some time. HPKP= protects against exactly this attack, but it only does so for sites that p= ublish pins, and for users who have noted pins. If I get a new computer/bro= wser/phone during the attack, I (and some others) will note the attacker's = pin. > So this isn't just a question of "how long might a site outage last". > Longer pin lifetimes increase the *possibility* of a site outage, > because there will be more old pins out there you have to stay > consistent with. >=20 >=20 > I do agree that a 30 or 60 day limit will be cold comfort if you brick > your site for that long. Certainly, pinning will need other > safeguards. >=20 > One safeguard could be some sort of "pin activation", where new or > changed pins are not accepted immediately, but must be observed for > some period of time before they "activate". I know this WG considered > a mechanism similar to TACK. TACK's exact mechanism doesn't translate > well to HPKP, but perhaps there is something else to be done. It may > be worth more thought. >=20 I think it's clear that HPKP (much like HSTS) is a gun with which site oper= ators can easily shoot themselves (or their users) in the foot. There has t= o be a certain level of competence and responsibility to make use of these = mechanisms. They should not be used lightly. OTOH I don't think we should b= ind the hands of administrators who do choose to use it. Yoav From trevp@trevp.net Fri Apr 5 09:53:57 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 260DD21F8BC4 for ; Fri, 5 Apr 2013 09:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.249 X-Spam-Level: X-Spam-Status: No, score=-1.249 tagged_above=-999 required=5 tests=[AWL=1.728, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUEfHTVcigZy for ; Fri, 5 Apr 2013 09:53:48 -0700 (PDT) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id 983C821F8BD5 for ; Fri, 5 Apr 2013 09:53:40 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id f12so4077454wgh.22 for ; Fri, 05 Apr 2013 09:53:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=UHFzH+UXD09oxPcxt1g3xPACwbeMrd2nEAFBs75Bj8c=; b=G5+hAfYoJqGlIK86PwHeMUlD/ZWjRRxGTbnowlEjXzADIqwl0h5cRuLJZp61SQoFtA bWRsEzBBRyUxRl2J/Jt3SyLx99b5PZRpHIFVLZDOAPdC/1bRBGkQoMVjbxs9VfY8uODK kSoyglvzOb6/s2d4laF4fvSjmamflpbEdR03oZKYf/a+pYKRsaGNAu1Kwti6BD/nVR2M KgkY+BPMm3v2o648xvlPIJWJR2g2rl1yJrG2qC7CtvWQxbJZ7x+DddPF0dnbZM2zm15R 0HL1+5lU5nZ4SIWvsQSYenDzZEb1JRaDFjnqLYaVqMnXHRd6E6IOSm74yiKF1vQloeJC 3Lig== MIME-Version: 1.0 X-Received: by 10.180.11.238 with SMTP id t14mr5828651wib.3.1365180818335; Fri, 05 Apr 2013 09:53:38 -0700 (PDT) Received: by 10.217.119.134 with HTTP; Fri, 5 Apr 2013 09:53:38 -0700 (PDT) X-Originating-IP: [166.137.187.20] In-Reply-To: <5758B958-5B08-41D1-B473-E1DD6B78A324@checkpoint.com> References: <058.4066f40ba1a0e0b17085c25af1721605@trac.tools.ietf.org> <073.92e203ac2ffbca6a9b6ecd285f8d0e00@trac.tools.ietf.org> <5B9868F5-6DF8-4D9E-BCE4-248063103A65@checkpoint.com> <77D0BAFD-9345-4F92-A8A3-641DADA771AA@checkpoint.com> <5758B958-5B08-41D1-B473-E1DD6B78A324@checkpoint.com> Date: Fri, 5 Apr 2013 09:53:38 -0700 Message-ID: From: Trevor Perrin To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkhlhyF2m95Y9RYXD+r7nC4BpO4YJYW/O8DTuYNvIso+dL+QL1IhGqwCwFR4pLBB+PcK4GE Cc: "" , Ryan Sleevi , websec issue tracker Subject: Re: [websec] #57: Re-add an upper limit to max-age X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 16:53:59 -0000 On Fri, Apr 5, 2013 at 1:48 AM, Yoav Nir wrote: > > On Apr 5, 2013, at 10:03 AM, Trevor Perrin wrote: > >> On Fri, Mar 29, 2013 at 7:05 PM, Yoav Nir wrote: >>> >>> Getting back to the subject of the thread, I still don't see the differ= ence for a site operator between being bricked for 60 days and being bricke= d for a year. For an only retailer it's catastrophe either way. >> >> >> Hi Yoav, >> >> There are other things to consider when thinking about pin lifetimes: >> >> - Suppose a site foolishly sets a year-long pin to keys that will be >> expired in 6 months. A client who receives this pin and then visits >> the site 6 months later will perceive that the site is bricked for the >> next 6 months. > > True. At least in the case of certificates, there was some discussion of = capping the maximum noted age to the expiration time of the certificate for= that connection. This is not a complete solution, though, because there is= some period of time (perhaps 1-2 weeks) where the site operator has a new,= valid certificate, but the old one hasn't expired yet. That also means that if a site uses short-lived or soon-to-expire certificates the pin lifetime could get badly truncated, so that's not a great idea. Anyways, expiration is just one way the above problem could happen. Imagine that you mistakenly set a year-long pin to CA keys that your CA is going to roll / phase-out in 6 months. Same problem. Capping pin lifetimes means less risk of this occurring. > A backup pin should work, as I believe the common practice would be to us= e the backup pin in the following certificate request. And backup pins are = mandatory according to the draft. Backup pin don't solve this problem. Backup keys can be revoked / expired / rolled / lost like other keys. >> - Suppose a site has a year-long pin to a set of end-entity keys. >> Suppose these keys are compromised by a hacker. For the next year, >> the site will be unable to change keys to re-establish security >> without a risk of "bricking" the site for clients with the old pin. > > And that is why the draft now requires backup pins. At least, it's one re= ason. No, I'm describing the scenario where ALL your pinned keys, including "backup pins", were compromised. Maybe you were keeping all your pinned end-entity keys in an offline laptop which was stolen. Maybe you were pinning yourself exclusively to CAs operated by a single commercial entity (e.g. Symantec), and you lose trust in this entity. In these scenarios, you are "locked-in" and prevented from key changes during the pin lifetime. >> - Suppose you purchase a domain name. The previous owner may have >> set long-term pins, meaning the name is not fully usable until these >> expire. > > Yeah, that's bad. Even worse is if an attacker manages to get a CA to iss= ue them a valid certificate. Users now note pins that match the bad certifi= cate, and they can be blocked from going to the real site for some time. Yes that's what I'm describing. > HPKP protects against exactly this attack No, HPKP or any dynamic-pinning method *CAUSES* this attack, by allowing the previous owner of any domain name to acquire a certificate, then use it to set pins. > I think it's clear that HPKP (much like HSTS) is a gun with which site op= erators can easily shoot themselves (or their users) in the foot. The risks and issues around key-pinning lifetimes are completely different from HSTS. HSTS cannot make it impossible for a site to be reached, or lock you into insecure keys. > There has to be a certain level of competence and responsibility to make = use of these mechanisms. They should not be used lightly. Please note that dynamic pinning creates risks for the entire web by virtue of existing. If 1/1000 websites "opt-in" to a key pinning mechanism, the remaining 999 are still exposed to the risk that their DNS name could be hijacked and a bad pin could be set. And anyone who purchases or acquires a domain name is still exposed to the risk that it could come with an unpleasant "pinning" surprise. >OTOH I don't think we should bind the hands of administrators who do choos= e to use it. Long-lived pins are *more* likely to bind the hands of administrators than short-lived, which is why I think pin lifetimes should be strictly limited. Trevor From trevp@trevp.net Mon Apr 15 17:23:39 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C131421E8037 for ; Mon, 15 Apr 2013 17:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.479 X-Spam-Level: X-Spam-Status: No, score=0.479 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62oy4i0FOzzs for ; Mon, 15 Apr 2013 17:23:35 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 29DCF21E8041 for ; Mon, 15 Apr 2013 17:23:34 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hn17so2103939wib.0 for ; Mon, 15 Apr 2013 17:23:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type:x-gm-message-state; bh=zEzHib+Hy0k4fb68c5eQ67SWxUc1Q1bD+lxuyGwij8w=; b=mvH80w75wzwLVY5eYAKPIGc70+0HpLSeT8xyARLXzONtLa96Mia+BtsjdsKB7PYt5q MQ0K3gbdmoPia3YSvOhkX+1EDXUfMqsKGDLvdAtqzum53KRElAQKsni7niTKeMuRcr3I 8qFD1x/O1Kb0EYP5xcB6YuLRNPcKu2riRa4ZaoiooRpcKiTNJj5M2CH3woamPOt5Ss/+ 723o2+Lc8j0VkWB7m3x8EgVnIfVPI4KOyHrKK8+91zfrhktvkJ+MTEs5Ti9WO/XqG/4V QxkWT2UIr7X67JFyEItvsPLcw1ZdOpnNMMmvOoFOTuVR/y8vP1eQsrcUf/DOD+hQ3Ho1 N8AQ== MIME-Version: 1.0 X-Received: by 10.180.13.233 with SMTP id k9mr15401076wic.6.1366071814225; Mon, 15 Apr 2013 17:23:34 -0700 (PDT) Received: by 10.216.101.138 with HTTP; Mon, 15 Apr 2013 17:23:34 -0700 (PDT) X-Originating-IP: [166.147.111.41] Date: Mon, 15 Apr 2013 17:23:34 -0700 Message-ID: From: Trevor Perrin To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk29ygC+vAbh8rq/5/hNkBxO157vN32u6vQQ+28sJnR3jaUvtE9zVEyURqXGQCTWKAXHXP/ Subject: [websec] Pin activation in HPKP X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 00:23:39 -0000 Hi websec, Long email, sorry! TLDR: HPKP could do TACK-like "pin activation" for safer pinning. ----- At one point, the HPKP draft mentioned "pin activation" a la TACK [1]. In TACK's algorithm, a client has to observe a pin assertion multiple times before "activating" a pin. After the first observation, subsequent observations cause the pin to be activated for a period equal to the span in which the client has observed the assertion, or a max of 30 days. The goal of this is to limit damage from malicious or mistaken "bad pins", with a side benefit of simplifying deployment: * If connections to a domain are being hijacked (due to DNS hijacking, domain name theft, an intercepted Wifi connection, etc.), and the attacker is atttempting to set a malicious pin, the resultant pin will not last longer than the attacker has already controlled the connection for (e.g., if you're at a coffee-shop for 2 hours, it can't set bad pins that last more than 2 hours; if a domain name is hijacked for 2 days, bad pins will expire 2 days afterwards; etc.) * If a site advertises bad pins for itself, perhaps due to a configuration mistake, a hacker, or a disgruntled system administrator, damage will be limited if the mistake is noticed and corrected quickly. * Since pin lifetimes are automatically scaled in a way which allows safe rollout (with quick removal an option if things go wrong), we can potentially do without an explicit max-age, making deployment simpler (one less knob the deployer has to turn). -- I had discussed this with Chris and Ryan, and applying this algorithm to HPKP seemed difficult. The algorithm requires clients make observations which either "confirm" or "contradict" an existing pin. This has three complications in HPKP: First, an HPKP header may assert a list of pinned keys which overlaps but doesn't exactly match a previous header. It's not instantly obvious how to handle this. Second, a TACK pin requires a matching tack to be present in every (non-resumed) TLS handshake, or the pin is contradicted. Thus, a bad pin set by an attacker can be contradicted when the client visits the legitimate site, whether the legitimate site is aware of TACK or not. In HPKP, on the other hand, HPKP headers are *not* required to be present in HTTP responses from pinned sites, so there wouldn't be as much benefit from regular sites "contradicting" bad pins. Third, "include_subdomains" (which TACK does not have) adds a wrinkle (if a pin is set at A.com, can B.A.com activate it?, etc.) -- On further thought, I think the first problem can be solved by adapting TACK's "overlapping pins" notion, where a client can have 2 pins active at once: this allows the new pin to be activated *prior to* removing the old one. The second problem may or may not be solvable, depending on whether HPKP is willing to require HPKP headers be present in responses from a pinned site. However, I think the algorithm has value even without this. The third problem (include_subdomains) needs more analysis. There are ways pin activation could work with include_subdomains, but it adds more complexity. I'm not quite sure the value of "include_subdomains". According to HSTS [2] section 14.4, it protects cookies. But there are other ways to protect cookies (see the TACK draft section 8.1) which are usable by all sites, not just those willing to pin their subdomains. And cookies should be replaced anyways, which I believe this WG is looking into. -- Anyways, here's a sketch of a "pin activation" algorithm for HPKP. This algorithm is basically the same as TACK (section 4.3.4), so it creates opportunites for sharing code / analysis / deployment advice etc. I'm omitting "max-age" and "includeSubdomains", but if the group is interested, we can discuss how to do them. Definition of "HPKP pin": - a set of public-key hashes - "initial time" when pin was created - "end time" when pin ceases to be active (or 0) Definition of "HPKP pin assertion": - A set of public key hashes presented in an HPKP header A client may store 0, 1, or 2 HPKP pins for a single domain name. A server may present 0, 1, or 2 HPKP pin assertions in a single HTTP response header (syntax TBD). Client connections to domains with an active pin or pins MUST match these pins or the connection is considered "contradicted" by the pin (e.g. if a client has 2 active pins for "example.com", the connection must have a certificate path that overlaps at least one key from each pin). If the connection is not contradicted, then the following steps are performed: 1. Any inactive pins are deleted if they don't overlap the certificate chain, or if there is an HPKP header that doesn't reassert the inactive pin. 2. If there are pins that are re-asserted by the HPKP header (i.e. a pin assertion lists the exact same keys as the pin), their active period is set by: end_time = current + MIN(30 days, current - initial_time) 3. Any new pin assertions create new inactive pins with initial_time = current and end_time = 0. -- So on deploying an initial pin assertion, clients will begin creating and activating pins. If problems are detected in the first (minutes / hours / days) of rollout, the assertion can be taken down, and problems will subside fairly quickly, as no client will have yet activated a long-lived pin. To change pins, the server simply deploys the new assertion alongside the old one. After 60 days, the old assertion may be removed. This guarantees that a client who is contacting the server at intervals of 30 days or less will never receive less than a full 30-day active period, to either the new or old pin, during the transition. If the server needs to switch more quickly from the old to new assertion it can do so, but this may create a window where clients have deleted the old pin but the new one is not yet receiving full 30-day active periods. By allowing "overlapping" pins and pin assertions, we avoid this in the case where servers are making carefully-planned transitions from one pin to another. Anyways, yes, this is complicated to analyze but it's fairly simple to implement. I'm sure I explained some of this badly, so please ask questions! I hope we can discuss this more... Trevor From tom@ritter.vg Wed Apr 17 06:43:18 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9966821F8480 for ; Wed, 17 Apr 2013 06:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPqq25QBqrys for ; Wed, 17 Apr 2013 06:43:17 -0700 (PDT) Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF1021F86CE for ; Wed, 17 Apr 2013 06:43:17 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id y10so886972pdj.12 for ; Wed, 17 Apr 2013 06:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=E+VPOf5NqvWu2U/DcHK1nCpKHnO2/6xV0BYvV4nzTbA=; b=DUIbrBS/m9fEKyE3YWByiZ/tIYA7gMlyRRDFvHu4N5xhyuXkD14k6zoANinz3zi4ZL ZrYiVvA0+nNEx2RGaoBDfelpMazZSZd58caDRrX9xkWCDt1mN9I9+W9nL+x2qMeFCjjY u+4+8zkpiKqA37Ce4PRRXcZhzGOCkL3lwC/iI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=E+VPOf5NqvWu2U/DcHK1nCpKHnO2/6xV0BYvV4nzTbA=; b=K9AnzyK5Xru4OAehtaTUhGgnyzfTsy5pcPmmjKjwpVPfYCc2AbOe57c6FPet2BX43A E7uNcILIdRRjhI6EXV26HiKV7MGJNag8XOfZVD2OZD0hYDpA+0Nu/Ek4a5ZSAsojGlRz dknz7BqysR7ieH48Pyx9/9itWCIx0WLkdn76Ohdlmsoa7UvmW+dPF60dTdmNCji43qOS QJgkBrf95wawGf13DchRsio3DXxU/aGvS/wNKQvyA08Zl21XJl98gFI3hTMhK5bVaETl MSR25BiK0XyBosNtoin/hAVLYFK1AE3jhi8Cvo5fOEJA6qj1tAZkTDxilfIwEcH3neGc uOoQ== X-Received: by 10.68.216.165 with SMTP id or5mr9274708pbc.152.1366206196437; Wed, 17 Apr 2013 06:43:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.88.68 with HTTP; Wed, 17 Apr 2013 06:42:56 -0700 (PDT) From: Tom Ritter Date: Wed, 17 Apr 2013 09:42:56 -0400 Message-ID: To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQknyKA6zdR3N4pK/QU75q4o9v7mV+TM3XZcpck5U3Kz4Y5DWQP6JqRlyApl0VzRQdbaFq4K Subject: [websec] HPKP Report Only Mode and Browser Extensions X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 13:43:19 -0000 I hear more and more talk about HPKP being used primarily in Report-Only mode. I think that's fair, as website operators are very *very* nervous about bricking themselves. But it also takes away the ability of users to be proactive about these (possible) violations. How do people feel about the following addition to the "Reporting Pin Validation Failure" section (probably under a new sub-section): If a UA provides extensibility points to be used by third party extensions or plugins, it [MAY?/SHOULD?] provide extensibility points relating to failures in both enforcement and Report Only mode. I envision a browser extension (which is naturally an opt-in mechanism) that flags Report Only violations so users are aware of them, and can investigate. I envision another one, perhaps run by the EFF, Google, or other trustworthy organization that actually sends these reports anonymized to a central database (besides the report-uri) where volunteers or employees could review them for suspicious entries. -tom From ryan-ietfhasmat@sleevi.com Wed Apr 17 08:56:54 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E7C21F8E98 for ; Wed, 17 Apr 2013 08:56:54 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7e3z4axNX4bq for ; Wed, 17 Apr 2013 08:56:53 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id DF6FB21F8E94 for ; Wed, 17 Apr 2013 08:56:53 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id 09A64264058; Wed, 17 Apr 2013 08:56:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=8o0vc+nHbJ4bEcLnFwkZeGDmJvI=; b=RRz7gaHkoH+3e0MCS RjwFWZGXKEKwBuzm2zIWCrBkAHkMbx9MDFjpAS8ZjH1yf3iM7QNUjGkwLPiTuxcT z1IDMubgX7UMGMStonJDvrUyHrfv/z8tXGgA9kL7JGUU2iyBuenF9haqvIjmG0X/ uR96dh2mWUUiL8akKwgJTnAdL4= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPA id 143B726407C; Wed, 17 Apr 2013 08:56:51 -0700 (PDT) Received: from 173.8.157.162 (proxying for 173.8.157.162) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Wed, 17 Apr 2013 08:56:30 -0700 Message-ID: <01722d224edeee1402f1c0d5df9075be.squirrel@webmail.dreamhost.com> In-Reply-To: References: Date: Wed, 17 Apr 2013 08:56:30 -0700 From: "Ryan Sleevi" To: "Tom Ritter" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] HPKP Report Only Mode and Browser Extensions X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ryan-ietfhasmat@sleevi.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 15:56:54 -0000 On Wed, April 17, 2013 6:42 am, Tom Ritter wrote: > I hear more and more talk about HPKP being used primarily in > Report-Only mode. I think that's fair, as website operators are very > *very* nervous about bricking themselves. But it also takes away the > ability of users to be proactive about these (possible) violations. > > How do people feel about the following addition to the "Reporting Pin > Validation Failure" section (probably under a new sub-section): > > If a UA provides extensibility points to be used > by third party extensions or plugins, it [MAY?/SHOULD?] > provide extensibility points relating to failures in > both enforcement and Report Only mode. > > I envision a browser extension (which is naturally an opt-in > mechanism) that flags Report Only violations so users are aware of > them, and can investigate. I envision another one, perhaps run by the > EFF, Google, or other trustworthy organization that actually sends > these reports anonymized to a central database (besides the > report-uri) where volunteers or employees could review them for > suspicious entries. > > -tom > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > While an interesting idea, and certainly one we've discussed on the Chromium side when considering implementation extension points, I think it's wholly inappropriate to include in the spec itself. I feel it opens a slippery slope of introducing behaviours that aren't strictly related to the treatment of the header. What's next? Extension points for how HPKP is managed within the UA (which also makes sense, but shouldn't be included in the spec) Cheers, Ryan From hammondjohnson@hushmail.com Sat Apr 27 16:37:55 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 647D121F9963 for ; Sat, 27 Apr 2013 16:37:55 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1dHwwy+aMax for ; Sat, 27 Apr 2013 16:37:54 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by ietfa.amsl.com (Postfix) with ESMTP id 993FF21F998C for ; Sat, 27 Apr 2013 16:37:54 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by smtp1.hushmail.com (Postfix) with SMTP id A28E431126 for ; Sat, 27 Apr 2013 17:55:21 +0000 (UTC) X-hush-relay-time: 215 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp1.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:55:21 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 631C1E6739; Sat, 27 Apr 2013 17:55:21 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:55:21 -0400 To: websec@ietf.org From: hammondjohnson@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427175521.631C1E6739@smtp.hushmail.com> Subject: [websec] Biggest Fake Conference in Computer Science X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 23:37:55 -0000 We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links.