From joelja@bogus.com Sun Jul 1 09:39: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 B025921F8A58 for ; Sun, 1 Jul 2012 09:39:45 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2sb09SY3ZMi for ; Sun, 1 Jul 2012 09:39:45 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3383521F8A57 for ; Sun, 1 Jul 2012 09:39:45 -0700 (PDT) Received: from joels-MacBook-Air.local (c-71-193-176-225.hsd1.wa.comcast.net [71.193.176.225]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q61Gdf5H077185 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 1 Jul 2012 16:39:42 GMT (envelope-from joelja@bogus.com) Message-ID: <4FF07D48.3080802@bogus.com> Date: Sun, 01 Jul 2012 09:39:36 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120619 Thunderbird/14.0 MIME-Version: 1.0 To: Yaron Sheffer References: <4FEEF96A.5050105@gmail.com> In-Reply-To: <4FEEF96A.5050105@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 01 Jul 2012 16:39:42 +0000 (UTC) Cc: saag@ietf.org Subject: Re: [saag] IPsec, APIs, and x.500 naming (Re: Should security requirements be MUST?) 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, 01 Jul 2012 16:39:45 -0000 On 6/30/12 6:04 AM, Yaron Sheffer wrote: > This is highly speculative, highly subjective of course, but I don't > think an API would have gotten IPsec to dominate the world. On the > contrary, app developers are happy to focus on their own stuff and not > spend too much time on security. > > From an application point of view, TLS has two important advantages > over IPsec (IKE really): > > - The well known advantage is that TLS is usually happy to > authenticate only the server, leaving client auth to the application. > This makes deployment so much easier. > > - The dirty little secret is that many people do not even authenticate > the server. In the cloud computing space (today's Wild West?) I have > seen several cases of popular tools that just don't bother, with no > apparent justification that I can think of. Another example is EAP-TLS > configuration on Windows. offhand I'd say that's the case for most smtp mta implementations as well... > I'm not trying to imply that TLS is insecure. But clearly if > widespread deployment is a goal (and it should be, otherwise why > bother writing RFCs) you should let deployers/developers choose their > appropriate level of security. In some cases, sadly, they will make > the wrong choice. > > Thanks, > Yaron From touch@isi.edu Sun Jul 1 23:00: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 075A811E8166 for ; Sun, 1 Jul 2012 23:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.119 X-Spam-Level: X-Spam-Status: No, score=-102.119 tagged_above=-999 required=5 tests=[AWL=-3.330, BAYES_40=-0.185, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gFwBBjNd-tn for ; Sun, 1 Jul 2012 23:00:24 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 686BC11E8136 for ; Sun, 1 Jul 2012 23:00:24 -0700 (PDT) Received: from [192.168.1.90] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q62603m8029725 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 1 Jul 2012 23:00:06 -0700 (PDT) References: <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> <4FECDEB8.6030600@deployingradius.com> <4FECF995.60009@deployingradius.com> <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> <4FEE41BB.3050705@deployingradius.com> <4FEE4442.70208@isi.! e du> <4FEEEEAA.3090601@deployingradius.com> In-Reply-To: <4FEEEEAA.3090601@deployingradius.com> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (9B206) From: Joe Touch Date: Sun, 1 Jul 2012 23:00:05 -0700 To: Alan DeKok X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Phillip Hallam-Baker , "saag@ietf.org" , Jeffrey Hutzelman Subject: Re: [saag] Should security requirements be MUST? 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, 02 Jul 2012 06:00:25 -0000 On Jun 30, 2012, at 5:18 AM, Alan DeKok wrote: > Joe Touch wrote: >> It would be useful to know if that actually sent packets on the wire >> (not in-memory measurements), >=20 > If your best counter-argument is to assume I'm a complete idiot, that > explains why your tests only get 50Mbps. 1500 byte blocks, measured per core, and that was IP level. > For more reality-based counter-arguments, see the "high performance > SSH" patches. They're also getting better than 900Mbps with crypto on > commodity hardware. 8 cores, different alg (CTR, not CBC, which is weaker), and 8 kb blocks at t= he "app" level, not 1500. That won't protect TCP. To do that, you need to encrypt at the block of a T= CP or IP packet, which is a lot costlier. And burning 8 cores is a lot more= costly than one $10 crypto chip, and prevents use of outboard TCP and IP ha= rdware assist. Joe From touch@isi.edu Sun Jul 1 23:05: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 80C2511E8166 for ; Sun, 1 Jul 2012 23:05:11 -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.664, BAYES_40=-0.185, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HzlkRtxSl1p for ; Sun, 1 Jul 2012 23:05:11 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id EBC5E11E817A for ; Sun, 1 Jul 2012 23:05:10 -0700 (PDT) Received: from [192.168.1.90] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q6264HSh013951 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 1 Jul 2012 23:04:27 -0700 (PDT) References: <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> <4FECDEB8.6030600@deployingradius.com> <4FECF995.60009@deployingradius.com> <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> <4FEE41BB.3050705@deployingradius.com> <4FEE4442.70208@isi.! ! edu> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (9B206) From: Joe Touch Date: Sun, 1 Jul 2012 23:04:19 -0700 To: Eric Rescorla X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Jeffrey Hutzelman , Phillip Hallam-Baker , "saag@ietf.org" Subject: Re: [saag] Should security requirements be MUST? 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, 02 Jul 2012 06:05:11 -0000 On Jun 29, 2012, at 5:43 PM, Eric Rescorla wrote: >=20 >=20 > On Jun 29, 2012, at 17:11, Joe Touch wrote: >=20 >>=20 >>=20 >> On 6/29/2012 5:00 PM, Alan DeKok wrote: >>> Joe Touch wrote: >>>> My last graphed measurements of this were in an NPSEC 2006 paper, and >>>> show that an entire Xeon CPU (within noise of current ones) gets around= >>>> 50Mbps at 100% load. >>>=20 >>> Well... I've measured commodity systems doing 940+ Mbps with AES-256. >>> This is in the last 4 months, using 2 year-old systems, and 1.5K packets= . >>=20 >> It would be useful to know if that actually sent packets on the wire (not= in-memory measurements), and if so, how much of your CPU was gone in the pr= ocess. >>=20 >>> If you need crypto acceleration to fill a 1G pipe, then your system >>> has less CPU power than my iPhone. >>=20 >> Your iPhone certainly can't run anywhere this fast. >=20 > You realize that an iPhone only allows one foreground process so it hardly= matters if it doesn't share the hardware encryption chip (if there even is o= ne) And background processes too, since iOS 4. Joe From y.oiwa@aist.go.jp Mon Jul 2 01:57: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 3A6B121F8BB4 for ; Mon, 2 Jul 2012 01:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.577 X-Spam-Level: X-Spam-Status: No, score=-7.577 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHYYGI6cXxNh for ; Mon, 2 Jul 2012 01:57:10 -0700 (PDT) Received: from na3sys010aog113.obsmtp.com (na3sys010aog113.obsmtp.com [74.125.245.94]) by ietfa.amsl.com (Postfix) with ESMTP id 05D2621F8BB2 for ; Mon, 2 Jul 2012 01:57:09 -0700 (PDT) Received: from mail-gg0-f171.google.com ([209.85.161.171]) (using TLSv1) by na3sys010aob113.postini.com ([74.125.244.12]) with SMTP ID DSNKT/FiafsCoZ4QbzMDlkfPOgdZtA0rXg5U@postini.com; Mon, 02 Jul 2012 01:57:14 PDT Received: by ggmi1 with SMTP id i1so4079761ggm.2 for ; Mon, 02 Jul 2012 01:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=AG5TUK9NIFsrlt11s3XS10aByIg5zuif+g5e0QIBKYs=; b=CEAX1yCLO8uUhB+NhRni87A6lRfSN598xLGrf37/0Qj8y0wZPVzPt63ySUnnoUSB6c UJAi6Adp6jL8XrQaIdEh+zYqlm0oTFyFphiZWNJcjdmcaZkxUSc4kAmeb6APwuPprKSQ TCnTj4Zo1IE+IVRdxcsK9c4knh5VQyfaf2s8Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=AG5TUK9NIFsrlt11s3XS10aByIg5zuif+g5e0QIBKYs=; b=WRDT8ZIbY9SU0YQ1iyYzCkzAKFV8Ki4iyIWG0eyWWNHfaMjHQAgegdvfGhskRmUajG bquHr3zKuz/2NwYmSUPtJw3xzkN5o6LSDj1aFy7vzP+kHjUDjXyOj3N6bqtXVU904jgZ 40wH0ESf5G9OdExRyGI1gkbEzeAAIHtJc1jc9bFyP9IL39JP1pda2LHFNThvK7kcfnln BUdrqskNgJ9iC6+cT4d8qsHx7o9CU6lMpFSr9T48UxONr5fXGmo/TuES6UsjWopJUqSl MGExIkcEoeFaeOC8SpPp0qLTvXGOG8t/hHccC/rC4aNHFj+UnRN+GexyubESpv875vak +bLQ== Received: by 10.50.202.102 with SMTP id kh6mr6671342igc.69.1341219432984; Mon, 02 Jul 2012 01:57:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.140.2 with HTTP; Mon, 2 Jul 2012 01:56:52 -0700 (PDT) In-Reply-To: References: From: Yutaka OIWA Date: Mon, 2 Jul 2012 17:56:52 +0900 Message-ID: To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnXwa2sUm6vBBBraRFwQTVt5udR9Ve3BRDwj9nbKSKEdM3CRvl9DgSjP4/YxOg9jdQBnmMx Cc: Sam Hartman , saag@ietf.org Subject: Re: [saag] On webauth and layering (Re: Reminder: Call for Proposals - HTTP/2.0 and HTTP) 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, 02 Jul 2012 08:57:11 -0000 Dear Nico, First to clarify, you seem to be misunderstanding my claim about "unnaturality". I've never said that your specific proposal is unnatural; I just said that use of HTTP headers are natural for Mutual authentication protocol, and that such "naturality" property depends on specific design and use of each protocols, not a universal one. It seem to me that it also holds for Alexey's SCRAM-SHA1 proposal. 2012/6/26 Nico Williams : > On Fri, Jun 15, 2012 at 7:38 PM, Yutaka OIWA wrote: > If you mean that application-layer authentication is unnatural on the > wire then I disagree vehemently. In fact, I think any HTTP-layer > authentication scheme will be unnatural on the wire: HTTP is a > one-round-trip, stateless protocol, but authentication protocols are > mostly NOT one round-trip (or less). For the first sentence, the answer is "NO" as I wrote above. However, I disagree on the following sentences. Both Mutual and SCRAM authentication schemes are meeting "stateless" requirements of the HTTP which is described in httpbis-p1, quoted below. > HTTP is defined as a stateless protocol, meaning that each request messag= e can be understood in isolation. [...] Hence, servers MUST NOT assume that= two requests on the same connection are from the same user agent unless th= e connection is secured and specific to that agent. HTTP's design criteria is that HTTP transport is completely "stateless", meaning that each response is tied to a single request, and each request can be "understood" without knowledge of the previous requests on the same wire (or, lower-layer transports). There are features on top of HTTP transport which can be called somewhat "stateful", including Cookies, caches and authentications (including Basic and Digest), all of which are carefully designed to meet p1-criteria (i.e. by marking related requests explicitly on the request headers and/or payloads). Previously, there were badly designed multi-hop authentication protocol breaking this criteria. RFC 4559 (SPNEGO) is one of such examples which is explicitly mentioned in the current httpbis-p1 draft= . I am agreeing with the writer of the httpbis-p1 (Julian?) that the design taken by RFC 4559 is conflicting with the HTTP's base philosophy= . Mutual proposal is avoiding such shortcomings and designed under the same principle as current Digest standard did (and as SCRAM-SHA1 seems to d= o). Each request is clearly "isolated", and can be "understood" by servers without any knowledge of previous requests. The contents of each response, and the result (or consequence) of each request may depend on the state of server-side applications and software, but importantly, this property is as same as other authentication protocols including OAuth Bearer, OAuth MAC, and even your GSS-REST, too. It does not violate HTTP's requirement in any way, as same as others. In the Mutual protocol, the property is clearly shown in the Section 10; you can see that server-side response is determined just as a function of an input request, not depending directly on the previous "flow" of proto= cols. It does not require, in any way, that such responses are handled as a set of requests implicitly tied by underlying transports. --=20 Yutaka OIWA, Ph.D. Leader, Software Reliability Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5= ] From fanf2@hermes.cam.ac.uk Mon Jul 2 04:22: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 B305221F853D for ; Mon, 2 Jul 2012 04:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.208 X-Spam-Level: X-Spam-Status: No, score=-6.208 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBWU6Hhf4EBd for ; Mon, 2 Jul 2012 04:22:53 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9035C21F84C8 for ; Mon, 2 Jul 2012 04:22:53 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:45433) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1SleiW-00071m-RT (Exim 4.72) (return-path ); Mon, 02 Jul 2012 12:22:56 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SleiW-00084p-GC (Exim 4.67) (return-path ); Mon, 02 Jul 2012 12:22:56 +0100 Date: Mon, 2 Jul 2012 12:22:56 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: joel jaeggli In-Reply-To: <4FF07D48.3080802@bogus.com> Message-ID: References: <4FEEF96A.5050105@gmail.com> <4FF07D48.3080802@bogus.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: saag@ietf.org Subject: Re: [saag] IPsec, APIs, and x.500 naming (Re: Should security requirements be MUST?) 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, 02 Jul 2012 11:22:54 -0000 joel jaeggli wrote: > On 6/30/12 6:04 AM, Yaron Sheffer wrote: > > > > - The dirty little secret is that many people do not even authenticate the > > server. In the cloud computing space (today's Wild West?) I have seen > > several cases of popular tools that just don't bother, with no apparent > > justification that I can think of. Another example is EAP-TLS configuration > > on Windows. > offhand I'd say that's the case for most smtp mta implementations as well... That's mainly because there's no spec for which identity to check against the cert. Consequently bad certs don't cause operational problems, so most certs that have been installed can't be verified. http://www.imc.org/ietf-smtp/mail-archive/msg05366.html Working on a fix: http://tools.ietf.org/html/draft-fanf-dane-smtp Tony. -- f.anthony.n.finch http://dotat.at/ Tyne, Dogger: South 5 or 6, decreasing 3 or 4. Slight or moderate. Rain, fog patches developing. Good, becoming moderate, occasionally very poor. From ekr@rtfm.com Mon Jul 2 05:57: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 C3F3F21F8673 for ; Mon, 2 Jul 2012 05:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.381, 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 z+XP9IoNSBn3 for ; Mon, 2 Jul 2012 05:57:39 -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 1B0A021F8668 for ; Mon, 2 Jul 2012 05:57:39 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3850476vbb.31 for ; Mon, 02 Jul 2012 05:57: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:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=hXgrVcXPig19LT38BBwA9QKQZKxkbWum+jgodxfAZcc=; b=ccGVgXnOmVmPQ4YnjPy6od+murtA6IO/PVIFa2BJCuE/EzXx5LFSC8ZWJFHui3Nx2e 7ItAkLkoZtvgwfCM8G+EmJU2zzbzYCxxGXicrdSemS/98aUvOJlM/jZi5r9nZXIKIsRl SNoCBT23FxxwWZd8pempr10nvmmt+zI3vKTK7fwT5xPI26HZHZGHFL9JDWXZi9p7sBdx g+rC7haJLLXJnNrq4XxXz6ZeMaoueHfMrYfVC6duaeiCGAodn7bp0ZtfU0//dI6mLczw I7s2Zndu3rtkGVhDgHqnHM0IKXdJv9d49Ror2kI+RPr6WxXm6chN50mo85xulKS9z61d q9fQ== Received: by 10.52.93.133 with SMTP id cu5mr5096761vdb.125.1341233863846; Mon, 02 Jul 2012 05:57:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Mon, 2 Jul 2012 05:57:00 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> <4FECDEB8.6030600@deployingradius.com> <4FECF995.60009@deployingradius.com> <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> <4FEE41BB.3050705@deployingradius.com> From: Eric Rescorla Date: Mon, 2 Jul 2012 05:57:00 -0700 Message-ID: To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmcrg0jhzKM/FQNuHFOYvxa1wSBrlj1QzzXviMrYz4ztGlSs6XpynnF5Rb9i9LyjVnqx7ez Cc: Jeffrey Hutzelman , Phillip Hallam-Baker , "saag@ietf.org" Subject: Re: [saag] Should security requirements be MUST? 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, 02 Jul 2012 12:57:39 -0000 On Sun, Jul 1, 2012 at 11:04 PM, Joe Touch wrote: > > > On Jun 29, 2012, at 5:43 PM, Eric Rescorla wrote: >> You realize that an iPhone only allows one foreground process so it hardly matters if it doesn't share the hardware encryption chip (if there even is one) > > And background processes too, since iOS 4. iOS background processes are very sharply limited in terms of how much resources they can consume. http://developer.apple.com/library/ios/#DOCUMENTATION/iPhone/Conceptual/iPhoneOSProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html About the only one of these cases that would allow you to do high-speed encryption is voice/video, but video in the background doesn't make sense and video in the foreground means nobody else should be doing fast encryption. Really, I'm finding it pretty hard to believe we're still having this userland versus kernel debate in 2012. The market has spoken and userland cryptography won. That was clear back in 1999. -Ekr From kent@bbn.com Mon Jul 2 09:04: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 5085A21F86B0 for ; Mon, 2 Jul 2012 09:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.433 X-Spam-Level: X-Spam-Status: No, score=-106.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzbgg4o27k8N for ; Mon, 2 Jul 2012 09:04:00 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C965E21F8692 for ; Mon, 2 Jul 2012 09:04:00 -0700 (PDT) Received: from dhcp89-089-227.bbn.com ([128.89.89.227]:49215) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Slj6a-0009i8-5V; Mon, 02 Jul 2012 12:04:04 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 2 Jul 2012 12:04:01 -0400 To: Nico Williams From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: saag@ietf.org Subject: Re: [saag] IPsec, APIs, and x.500 naming (Re: Should security requirements be MUST?) 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, 02 Jul 2012 16:04:01 -0000 >... > >x.500 naming is just not useful. Humans can handle name@domain and >only slightly more complex name forms, but x.500 is impossible. And >we're stuck with Name because that's what TBSCertificate uses for >subjectName. We can't switch to GeneralName for subjectName. We're >screwed. I'm tempted to propose the use of UUIDs in subjectName and >then treat the first subjectAltName as the canonical name, banning the >use of Name, but that wouldn't fly either. We're stuck. X.509 has supported DNS names as Subject Alt names since 1998. Steve From nico@cryptonector.com Mon Jul 2 09:05: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 E823C21F8723 for ; Mon, 2 Jul 2012 09:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.166 X-Spam-Level: X-Spam-Status: No, score=-3.166 tagged_above=-999 required=5 tests=[AWL=-1.189, 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 TikKruMwJMvm for ; Mon, 2 Jul 2012 09:05:28 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id F204121F86DF for ; Mon, 2 Jul 2012 09:05:13 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id 441353B805C for ; Mon, 2 Jul 2012 09:05:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=NH7ROuHrUXKpARZ70QpYj OZQD6K9p9gWzLvzhqEwtzDN2gtok4TURryuMCDs6ZgijsNfZE5fkBLszq5r4Gfz2 BiSCrqMN5sT+8NYx4pDEgaAe1SKA5yBU2amJFUM99eaT2u3klA4eTt9F8h+vcFr2 P08gCCRcQMFqJWyIRfH0HM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=2g28VEeY8KlNtuuhPw8t DJTGe6I=; b=mQr0JpLA+Zm7VDA1ewPPzUBktb6hF0eJfedpKTQ6JNalI1FSp9I9 L7u88+b45hTPZ08Kj1k50ZRv8J/D53eHLVd/ULDRNcqA2uHUGpxqVlDKl/S5tRqt bjtmfKiAJiwB1QOBxCPKixI9b0d0o8GaYcO9mlhEuZ62i0JBjpuyP1I= Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id 1967F3B805B for ; Mon, 2 Jul 2012 09:05:18 -0700 (PDT) Received: by vcqp1 with SMTP id p1so3992156vcq.31 for ; Mon, 02 Jul 2012 09:05:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.33.37 with SMTP id o5mr5372650vdi.86.1341245118293; Mon, 02 Jul 2012 09:05:18 -0700 (PDT) Received: by 10.220.76.203 with HTTP; Mon, 2 Jul 2012 09:05:17 -0700 (PDT) In-Reply-To: References: <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> <4FECDEB8.6030600@deployingradius.com> <4FECF995.60009@deployingradius.com> <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> <4FEE41BB.3050705@deployingradius.com> Date: Mon, 2 Jul 2012 11:05:17 -0500 Message-ID: From: Nico Williams To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: Jeffrey Hutzelman , Phillip Hallam-Baker , "saag@ietf.org" Subject: Re: [saag] Should security requirements be MUST? 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, 02 Jul 2012 16:05:29 -0000 On Mon, Jul 2, 2012 at 7:57 AM, Eric Rescorla wrote: > Really, I'm finding it pretty hard to believe we're still having this > userland versus kernel debate in 2012. The market has spoken > and userland cryptography won. That was clear back in 1999. Agreed; user-land cryptographic protocols won long ago, and I'd say they won with SSL 2.0, so, really, long, long ago. There are exceptions though, such as distributed filesystems, which usually are implemented in kernel mode such that session crypto also happens in kernel mode. Also, there do exist kernel-mode HTTPS implementations (e.g., Solaris has one), though I think that exists primarily to take better advantage of crypto co-processors -- a thing of the past really, as crypto instructions like AES-NI proliferate in new CPUs. IPsec would have to have had APIs and all that in 1995 for this to have turned out differently; it didn't. Nico -- From nico@cryptonector.com Mon Jul 2 09:12: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 B5B9221F871D for ; Mon, 2 Jul 2012 09:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[AWL=-1.154, 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 ALm3IY-eJzoM for ; Mon, 2 Jul 2012 09:12:22 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id B8FBF21F86C9 for ; Mon, 2 Jul 2012 09:12:20 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id D9E6567C073 for ; Mon, 2 Jul 2012 09:12:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=JwhA0XbgNnmJFEUC8GeXm J7qHSzxLLoDSdQZHWZgYPFI6AAXh+ihDZtDM0fZS1uLqEOMO+iBZ0eN+JzlthdRY dYawcn8CVSrpyBn9irebPX7PziDJv9fQQn2JyeR2O6Zaip5TTGo797RmL+bwjVg9 yzZfVrW8ryAyw8LGUJsDpY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=yRa7hVXo7i8eXUSHfSJv Jo996UQ=; b=eZ5UGpBZklX3XDrXstdV/4RNHI1y8vfwXCLZVZnBa/aVUbnhmdpT c2CtYHi7zOacd2vjrTsXCDxfWoIgyfhA3NzCYnFWKsyp7DM+kz7enH4p58r+mL+J W9m68JkHLE5/Jv9jarXMoaNE06U5ZHR0fogYuVySmPUfEsL6+ttOBBk= Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id A804C67C06D for ; Mon, 2 Jul 2012 09:12:24 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4002143vbb.31 for ; Mon, 02 Jul 2012 09:12:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.223.201 with SMTP id il9mr1080403vcb.61.1341245543998; Mon, 02 Jul 2012 09:12:23 -0700 (PDT) Received: by 10.220.76.203 with HTTP; Mon, 2 Jul 2012 09:12:23 -0700 (PDT) In-Reply-To: References: Date: Mon, 2 Jul 2012 11:12:23 -0500 Message-ID: From: Nico Williams To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Cc: saag@ietf.org Subject: Re: [saag] IPsec, APIs, and x.500 naming (Re: Should security requirements be MUST?) 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, 02 Jul 2012 16:12:22 -0000 On Mon, Jul 2, 2012 at 11:04 AM, Stephen Kent wrote: >> x.500 naming is just not useful. Humans can handle name@domain and >> only slightly more complex name forms, but x.500 is impossible. And >> we're stuck with Name because that's what TBSCertificate uses for >> subjectName. We can't switch to GeneralName for subjectName. We're >> screwed. I'm tempted to propose the use of UUIDs in subjectName and >> then treat the first subjectAltName as the canonical name, banning the >> use of Name, but that wouldn't fly either. We're stuck. > > X.509 has supported DNS names as Subject Alt names since 1998. Right, but not as subjectName, because subjectName is only a Name, not a GeneralName. And so we're still stuck with Name, and Name is simply awful. Nico -- From stephen.farrell@cs.tcd.ie Mon Jul 2 09:16: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 9FAE021F8741 for ; Mon, 2 Jul 2012 09:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.468 X-Spam-Level: X-Spam-Status: No, score=-102.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IW-6ye6WN42O for ; Mon, 2 Jul 2012 09:16:38 -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 C1F6321F8738 for ; Mon, 2 Jul 2012 09:16:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id C16FD17151B; Mon, 2 Jul 2012 17:16:42 +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=1341245801; bh=n9J4Z5pjXi/wD5 9Tbk6cRDkqCN5Nojg8wPor8o9Xn48=; b=FDoR6ypZ141/pDAahZaHsBPQL2jCH0 nPFEydEjss70JLLfx3bMDetHhoaH/lydEQ4Zn1JaN3vlDeW04qLAu+9kESk9+Gk8 nVdAgg7SCgMNd8gW4Y9om9cf26XLdOvqTJWV1otteE2G0g+vUML6oxeeiYqNNJ1R hwimd1qLaYbRSv1ujDzIwKrDOnuz1a0idGEdBz/AozgC/f1qlQ6eiXxz1P8h9Wlv pk4/VLEMKCI+wM1bJDk+b4lkgMsgKuKQSGhH8cFHUk8lwjCqsyghHEUj8pytF6tV xzjbV+4KWcMmYZK8mjWv2Ug45jSO7S1gW4xWB2LHeNKJNQbV+Yf3ZUpg== 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 GfZfSYrJuBnU; Mon, 2 Jul 2012 17:16:41 +0100 (IST) Received: from [10.3.10.185] (unknown [193.1.186.252]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 9476917147C; Mon, 2 Jul 2012 17:16:41 +0100 (IST) Message-ID: <4FF1C96A.4060507@cs.tcd.ie> Date: Mon, 02 Jul 2012 17:16:42 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: "saag@ietf.org" References: <20120619153312.13442.75785.idtracker@ietfa.amsl.com> <4FE30CAC.6060401@cs.tcd.ie> <4FE8D7B3.3000308@cs.tcd.ie> <4FEB2443.5010909@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [saag] Stephen Farrell's Discuss on draft-ietf-trill-rbridge-channel-06: (with DISCUSS and COMMENT) 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, 02 Jul 2012 16:16:38 -0000 Hi all, I have a discuss [1] on a TRILL draft [2] that defines a way to channel other protocols via RBridges. In discussing that with Don, he nicely summarised the core issue as follows: On 07/01/2012 06:22 PM, Donald Eastlake wrote: > it seems to me > that what all this boils down to is that the Security Area has to > decide that either (1) with improved wording an RBridge Channel level > mandatory to implement, optional to use, security feature is not > necessary for approval of this draft or (2) such a feature is > necessary for approval of the draft and the TRILL WG needs to go come > up with one. TRILL isn't something I know much about, so I'd welcome input (on or off list) as to what's reasonable here. Note that there will be a statement that any other protocol defined to run over this channel MUST define its own security mechanisms. Thanks, Stephen. [1] https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-channel/ballot/ [2] http://tools.ietf.org/html/draft-ietf-trill-rbridge-channel From marsh@extendedsubset.com Mon Jul 2 09:49: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 D612D11E8087 for ; Mon, 2 Jul 2012 09:49:49 -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 JJQh2z6XHXAh for ; Mon, 2 Jul 2012 09:49:49 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id 540BD11E8073 for ; Mon, 2 Jul 2012 09:49:49 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1Sljov-000EwW-9H; Mon, 02 Jul 2012 16:49:53 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id F33C260A1; Mon, 2 Jul 2012 16:49:49 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+0THmZlgvOqCy95Sxj26NjcPxdsS2MhZg= Message-ID: <4FF1D12D.2060209@extendedsubset.com> Date: Mon, 02 Jul 2012 11:49:49 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Joe Touch References: <4FECDEB8.6030600@deployingradius.com> <4FECF995.60009@deployingradius.com> <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> <4FEE41BB.3050705@deployingradius.com> <4FEE4442.70208@isi.! e du> <4FEEEEAA.3090601@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeffrey Hutzelman , Phillip Hallam-Baker , "saag@ietf.org" Subject: Re: [saag] Should security requirements be MUST? 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, 02 Jul 2012 16:49:50 -0000 On 07/02/2012 01:00 AM, Joe Touch wrote: > > That won't protect TCP. To do that, you need to encrypt at the block > of a TCP or IP packet, which is a lot costlier. And burning 8 cores > is a lot more costly than one $10 crypto chip, and prevents use of > outboard TCP and IP hardware assist. I'm not convinced that userland code is incapable of benefiting from crypto hardware. * Userland code benefits greatly from GPU acceleration hardware. Graphics applications (e.g. 3D games) have similar latency requirements to networking and far higher bus bandwidth requirements. * OpenSSL is a userland library that includes hooks for supported crypto hardware. * MS CryptoAPI has installable crypto providers. * OpenBSD has long exposed kernel crypto drivers to userland code. * On Intel and AMD chips that support them, AES-NI instructions are available from userland code. * It's true that most apps build upon TCP support provided by the kernel, but most kernels provide some degree of raw socket capability to allow for userland TCP stacks in cases where it makes a difference. - Marsh From touch@isi.edu Mon Jul 2 09:50:46 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 B930A11E8098 for ; Mon, 2 Jul 2012 09:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.741 X-Spam-Level: X-Spam-Status: No, score=-105.741 tagged_above=-999 required=5 tests=[AWL=0.858, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nLBFdWub97O for ; Mon, 2 Jul 2012 09:50:42 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5E87411E8087 for ; Mon, 2 Jul 2012 09:50:42 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q62Go0LP002694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Jul 2012 09:50:03 -0700 (PDT) Message-ID: <4FF1D139.5050601@isi.edu> Date: Mon, 02 Jul 2012 09:50:01 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Nico Williams References: <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> <4FEE41BB.3050705@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Phillip Hallam-Baker , "saag@ietf.org" , Jeffrey Hutzelman Subject: Re: [saag] Should security requirements be MUST? 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, 02 Jul 2012 16:50:46 -0000 On 7/2/2012 9:05 AM, Nico Williams wrote: > On Mon, Jul 2, 2012 at 7:57 AM, Eric Rescorla wrote: >> Really, I'm finding it pretty hard to believe we're still having this >> userland versus kernel debate in 2012. The market has spoken >> and userland cryptography won. That was clear back in 1999. > > Agreed; user-land cryptographic protocols won long ago, and I'd say > they won with SSL 2.0, so, really, long, long ago. App-layer. Where they won, they won because they allowed half the connection to not authenticate. BTNS was all about trying to get that benefit for protocols like IPsec, that were wound too tightly around a "one size fits all" approach, IMO. And they won for consumer transactions. Secure tunnels can't operate efficiently in user-space without defeating outboard transport, network, and link protocol support. Off-loading for IPsec is still supported both by hardware and OSes, esp. for cloud computing: http://www.intel.com/support/network/adapter/pro100/sb/CS-030515.htm?wapkw=ipsec And it's still supported in line-card hardware for routers too, of course. Joe From kent@bbn.com Mon Jul 2 09:50: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 D5EC111E809F for ; Mon, 2 Jul 2012 09:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.447 X-Spam-Level: X-Spam-Status: No, score=-106.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUzg0g-mDueK for ; Mon, 2 Jul 2012 09:50:57 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3A63111E809C for ; Mon, 2 Jul 2012 09:50:57 -0700 (PDT) Received: from dhcp89-089-227.bbn.com ([128.89.89.227]:49243) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sljq0-0004PE-Pp; Mon, 02 Jul 2012 12:51:00 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 2 Jul 2012 12:46:39 -0400 To: Nico Williams From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: saag@ietf.org Subject: Re: [saag] IPsec, APIs, and x.500 naming (Re: Should security requirements be MUST?) 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, 02 Jul 2012 16:50:58 -0000 At 11:12 AM -0500 7/2/12, Nico Williams wrote: >On Mon, Jul 2, 2012 at 11:04 AM, Stephen Kent wrote: >>> x.500 naming is just not useful. Humans can handle name@domain and >>> only slightly more complex name forms, but x.500 is impossible. And >>> we're stuck with Name because that's what TBSCertificate uses for >>> subjectName. We can't switch to GeneralName for subjectName. We're >>> screwed. I'm tempted to propose the use of UUIDs in subjectName and >>> then treat the first subjectAltName as the canonical name, banning the >>> use of Name, but that wouldn't fly either. We're stuck. >> >> X.509 has supported DNS names as Subject Alt names since 1998. > >Right, but not as subjectName, because subjectName is only a Name, not >a GeneralName. And so we're still stuck with Name, and Name is simply >awful. > >Nico >-- Two observations: - one need not use the subject name for access control decisions - one can represent a DNS name as Subject name, using the DC attribute Steve From touch@isi.edu Mon Jul 2 09:52: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 2AB1811E80A5 for ; Mon, 2 Jul 2012 09:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.773 X-Spam-Level: X-Spam-Status: No, score=-105.773 tagged_above=-999 required=5 tests=[AWL=0.826, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFu8T8mqRwAE for ; Mon, 2 Jul 2012 09:52:38 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 90C9411E809C for ; Mon, 2 Jul 2012 09:52:38 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q62GpGrZ002838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Jul 2012 09:51:16 -0700 (PDT) Message-ID: <4FF1D185.3080306@isi.edu> Date: Mon, 02 Jul 2012 09:51:17 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Eric Rescorla References: <4FECF995.60009@deployingradius.com> <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> <4FEE41BB.3050705@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Jeffrey Hutzelman , Phillip Hallam-Baker , "saag@ietf.org" Subject: Re: [saag] Should security requirements be MUST? 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, 02 Jul 2012 16:52:39 -0000 On 7/2/2012 5:57 AM, Eric Rescorla wrote: > On Sun, Jul 1, 2012 at 11:04 PM, Joe Touch wrote: >> >> >> On Jun 29, 2012, at 5:43 PM, Eric Rescorla wrote: > >>> You realize that an iPhone only allows one foreground process so it hardly matters if it doesn't share the hardware encryption chip (if there even is one) >> >> And background processes too, since iOS 4. > > iOS background processes are very sharply limited in terms of > how much resources they can consume. > > http://developer.apple.com/library/ios/#DOCUMENTATION/iPhone/Conceptual/iPhoneOSProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html > > About the only one of these cases that would allow you to do > high-speed encryption is voice/video, but video in the background > doesn't make sense and video in the foreground means nobody > else should be doing fast encryption. VoIP, or basically *any* networking (Pandora, e.g.) over an IPsec or PPTP tunnel. Part of the restriction in iOS is precisely because of the lack of hardware support for efficient offloading - vs., e.g., audio playback which is supported in that way. Joe From touch@isi.edu Mon Jul 2 09:53: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 ABB0521F86E5 for ; Mon, 2 Jul 2012 09:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.803 X-Spam-Level: X-Spam-Status: No, score=-105.803 tagged_above=-999 required=5 tests=[AWL=0.796, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AZTSnkTGuAg for ; Mon, 2 Jul 2012 09:53:25 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2916D21F86DF for ; Mon, 2 Jul 2012 09:53:25 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q62Gr0jO003066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Jul 2012 09:53:00 -0700 (PDT) Message-ID: <4FF1D1EC.4020206@isi.edu> Date: Mon, 02 Jul 2012 09:53:00 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Marsh Ray References: <4FECF995.60009@deployingradius.com> <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> <4FEE41BB.3050705@deployingradius.com> <4FEE4442.70208@isi.! e du> <4FEEEEAA.3090601@deployingradius.com> <4FF1D12D.2060209@extendedsubset.! com> In-Reply-To: <4FF1D12D.2060209@extendedsubset.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Jeffrey Hutzelman , Phillip Hallam-Baker , "saag@ietf.org" Subject: Re: [saag] Should security requirements be MUST? 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, 02 Jul 2012 16:53:25 -0000 On 7/2/2012 9:49 AM, Marsh Ray wrote: > On 07/02/2012 01:00 AM, Joe Touch wrote: >> >> That won't protect TCP. To do that, you need to encrypt at the block >> of a TCP or IP packet, which is a lot costlier. And burning 8 cores >> is a lot more costly than one $10 crypto chip, and prevents use of >> outboard TCP and IP hardware assist. > > I'm not convinced that userland code is incapable of benefiting from > crypto hardware. > > * Userland code benefits greatly from GPU acceleration hardware. > Graphics applications (e.g. 3D games) have similar latency requirements > to networking and far higher bus bandwidth requirements. > > * OpenSSL is a userland library that includes hooks for supported crypto > hardware. > > * MS CryptoAPI has installable crypto providers. > > * OpenBSD has long exposed kernel crypto drivers to userland code. > > * On Intel and AMD chips that support them, AES-NI instructions are > available from userland code. > > * It's true that most apps build upon TCP support provided by the > kernel, but most kernels provide some degree of raw socket capability to > allow for userland TCP stacks in cases where it makes a difference. The problem is that userland crypto interferes with offloaded TCP and IP. Once an egress packet leaves main memory, you don't want to pull it back in to do crypto. Joe From ekr@rtfm.com Mon Jul 2 10:02: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 8C46F21F8760 for ; Mon, 2 Jul 2012 10:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.625 X-Spam-Level: X-Spam-Status: No, score=-102.625 tagged_above=-999 required=5 tests=[AWL=0.352, 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 H3y93ohdnwsk for ; Mon, 2 Jul 2012 10:02:05 -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 A094D21F861B for ; Mon, 2 Jul 2012 10:02:05 -0700 (PDT) Received: by vcqp1 with SMTP id p1so4031909vcq.31 for ; Mon, 02 Jul 2012 10:02:10 -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:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=8aS6KxorcnwNSeTOQKttOVZSF2QPvR46N5hAFj4Vl+w=; b=R/247kkfGVBGOMWrqU0gbXGcbpJOY4+e3lcfOPONAl1+u3DPux7+DpWEMS2SStGuoB CwjEiG4ZesIweF7aCo5eCI1b8hEUJdj4EF7oBRKiEEHqQorTosX3mWM8K7grsHQxHEuQ qWzlc59WhWJV1sC8zKB34D76eXxvciLPzLwMIld4PGc+p3tIwia5GJ1/Kmf9zUoK0v2A kl8weu4at8XBFqZgOMzqW01Y99HuDOHFjNc+DCIHfSvbV04oFEX+E5xMz+E9tcddUgx3 celHJP7pGraYsXY2zuN51tOlOQA69kGwZBmSD5XHwhgnRTZVuBSyZ8AKcEnfMF1oMy4V PziQ== Received: by 10.220.107.136 with SMTP id b8mr3997127vcp.26.1341248530753; Mon, 02 Jul 2012 10:02:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Mon, 2 Jul 2012 10:01:30 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <4FF1D185.3080306@isi.edu> References: <4FECF995.60009@deployingradius.com> <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> <4FEE41BB.3050705@deployingradius.com> <4FF1D185.3080306@isi.edu> From: Eric Rescorla Date: Mon, 2 Jul 2012 10:01:30 -0700 Message-ID: To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmUN3KIpTUsVMpuTPXXeYUzUkBpMaKTOQvcg3i6R/MPbxqeJfo3Vr3/oh1O5OT4O0BNQ1g/ Cc: Jeffrey Hutzelman , Phillip Hallam-Baker , "saag@ietf.org" Subject: Re: [saag] Should security requirements be MUST? 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, 02 Jul 2012 17:02:06 -0000 On Mon, Jul 2, 2012 at 9:51 AM, Joe Touch wrote: > > > On 7/2/2012 5:57 AM, Eric Rescorla wrote: >> >> On Sun, Jul 1, 2012 at 11:04 PM, Joe Touch wrote: >>> >>> >>> >>> On Jun 29, 2012, at 5:43 PM, Eric Rescorla wrote: >> >> >>>> You realize that an iPhone only allows one foreground process so it >>>> hardly matters if it doesn't share the hardware encryption chip (if there >>>> even is one) >>> >>> >>> And background processes too, since iOS 4. >> >> >> iOS background processes are very sharply limited in terms of >> how much resources they can consume. >> >> >> http://developer.apple.com/library/ios/#DOCUMENTATION/iPhone/Conceptual/iPhoneOSProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html >> >> About the only one of these cases that would allow you to do >> high-speed encryption is voice/video, but video in the background >> doesn't make sense and video in the foreground means nobody >> else should be doing fast encryption. > > > VoIP, or basically *any* networking (Pandora, e.g.) over an IPsec or PPTP > tunnel. > > Part of the restriction in iOS is precisely because of the lack of hardware > support for efficient offloading - vs., e.g., audio playback which is > supported in that way. Huh? Do you have any evidence that difficulty of sharing crypto hardware is a reason for iOS background processing? Like quotes from Apple or somesuch. -Ekr From ekr@rtfm.com Mon Jul 2 10:03: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 EC29A21F85A3 for ; Mon, 2 Jul 2012 10:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.65 X-Spam-Level: X-Spam-Status: No, score=-102.65 tagged_above=-999 required=5 tests=[AWL=0.327, 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 dRChJOxORLnM for ; Mon, 2 Jul 2012 10:03: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 0F5E821F844B for ; Mon, 2 Jul 2012 10:03:36 -0700 (PDT) Received: by vcqp1 with SMTP id p1so4032882vcq.31 for ; Mon, 02 Jul 2012 10:03:42 -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:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=y+cimB/48nKLt42tdmQHBpHy0YHf+4pvyf5pDc8MkME=; b=k8GuHKthahEwZFEqowd+bD1t4kzU1U2kiCyX4zpwnruN9Z1vvG1L1czL4CtueLuwag +HOE+Kh5Z0AqeLSn3WhUW7VnGNIGIlcmoQs1SsYsam7yYQzwTpUWV7Qw2FGUCWVjDgZJ dN8gc5oBWBeybwNaJKTygK7Qj5MBfNqDn/v37x5oP2PZ8kNzLGZx1OoMatxzw344lED3 RG+FbxvtIaxG7qovW5DIwSi2QQTCxwfubqT4paTUlH8x9PBQZJs5BtFoKCHMMvtOX61z Ca8S/78O58B7aTPqLQ6DmskDwJnRSWpveXFPA+HT6ZyJxRMZtTCHpjCRhtWQ+p5GAA/S 6ESg== Received: by 10.52.100.229 with SMTP id fb5mr5420156vdb.102.1341248622208; Mon, 02 Jul 2012 10:03:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Mon, 2 Jul 2012 10:03:01 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <4FF1D139.5050601@isi.edu> References: <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> <4FEE41BB.3050705@deployingradius.com> <4FF1D139.5050601@isi.edu> From: Eric Rescorla Date: Mon, 2 Jul 2012 10:03:01 -0700 Message-ID: To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlX4Ye9ZqzskMlkznI93C3jbxDiOfUsTj/AeWENVCTW24wKsIYbYdaPOtcXcU4HDJDwAIyz Cc: Phillip Hallam-Baker , "saag@ietf.org" , Jeffrey Hutzelman Subject: Re: [saag] Should security requirements be MUST? 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, 02 Jul 2012 17:03:38 -0000 On Mon, Jul 2, 2012 at 9:50 AM, Joe Touch wrote: > > > On 7/2/2012 9:05 AM, Nico Williams wrote: >> >> On Mon, Jul 2, 2012 at 7:57 AM, Eric Rescorla wrote: >>> >>> Really, I'm finding it pretty hard to believe we're still having this >>> userland versus kernel debate in 2012. The market has spoken >>> and userland cryptography won. That was clear back in 1999. >> >> >> Agreed; user-land cryptographic protocols won long ago, and I'd say >> they won with SSL 2.0, so, really, long, long ago. > > > App-layer. > > Where they won, they won because they allowed half the connection to not > authenticate. No, they won because the people deploying the software wanted to be able to have it just install on the user's machine without screwing with the kernel. > BTNS was all about trying to get that benefit for protocols > like IPsec, that were wound too tightly around a "one size fits all" > approach, IMO. > > And they won for consumer transactions. Secure tunnels can't operate > efficiently in user-space without defeating outboard transport, network, and > link protocol support. What, you've never heard of an SSL VPN? -Ekr From touch@isi.edu Mon Jul 2 10:07: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 4CB3421F86D9 for ; Mon, 2 Jul 2012 10:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.83 X-Spam-Level: X-Spam-Status: No, score=-103.83 tagged_above=-999 required=5 tests=[AWL=-1.231, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bV2csD3kK2zv for ; Mon, 2 Jul 2012 10:07:09 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id A54F821F85C5 for ; Mon, 2 Jul 2012 10:07:09 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q62H6mmb026051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Jul 2012 10:06:49 -0700 (PDT) Message-ID: <4FF1D529.5000709@isi.edu> Date: Mon, 02 Jul 2012 10:06:49 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Eric Rescorla References: <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> <4FEE41BB.3050705@deployingradius.com> <4FF1D185.3080306@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Jeffrey Hutzelman , Phillip Hallam-Baker , "saag@ietf.org" Subject: Re: [saag] Should security requirements be MUST? 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, 02 Jul 2012 17:07:10 -0000 On 7/2/2012 10:01 AM, Eric Rescorla wrote: > On Mon, Jul 2, 2012 at 9:51 AM, Joe Touch wrote: ... >> VoIP, or basically *any* networking (Pandora, e.g.) over an IPsec or PPTP >> tunnel. >> >> Part of the restriction in iOS is precisely because of the lack of hardware >> support for efficient offloading - vs., e.g., audio playback which is >> supported in that way. > > Huh? Do you have any evidence that difficulty of sharing crypto hardware > is a reason for iOS background processing? Like quotes from Apple > or somesuch. For things it is designed to do in background, it has outboard processing (phone, music playback). Apple didn't issue a statement about everything it didn't include in its design. The limitations it posts are based on its *current* architecture. Joe From ekr@rtfm.com Mon Jul 2 10:09: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 B58EE11E80B3 for ; Mon, 2 Jul 2012 10:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.672 X-Spam-Level: X-Spam-Status: No, score=-102.672 tagged_above=-999 required=5 tests=[AWL=0.305, 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 I7CDc09fgTyw for ; Mon, 2 Jul 2012 10:09:04 -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 CFB7311E809A for ; Mon, 2 Jul 2012 10:09:03 -0700 (PDT) Received: by vcqp1 with SMTP id p1so4036493vcq.31 for ; Mon, 02 Jul 2012 10:09:09 -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:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=aAdepef2Z5uHPI8lMII6e2i4HZZJ1IvcMSv+eogVGgQ=; b=ZFj7epJc3CyqS/KDHaiiAuvgKReRw7PDbY97lXsfI3K9nML9tARvf6ybtgYGf+Wh86 XC8Bjn5EoToHK7QKZVjrE3GfVUpyPOqpST8MRhgmwIfolRMqPqk31vPlx/NWwZuZQu4B 1Xwo1PvuTupNZotyO5gQJiFpdu1z2jpPLR5JGkq5AkuKhpegGTKNMbutwIwhaS9TK7pU FDeRyeRibKDd1pvVOIAqqfmITAehEh2RziKwhnc5Ib1TdaNnR1V1jjBmGhMn7vkY+E3C sip7uMtGnyYqBhMiT12dETXDHX/QWLLSJIh+CPcO7xhrPWSv17wCjzfNZr+QnEp/8+Mk 5H2A== Received: by 10.220.107.136 with SMTP id b8mr4007480vcp.26.1341248948864; Mon, 02 Jul 2012 10:09:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Mon, 2 Jul 2012 10:08:28 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <4FF1D529.5000709@isi.edu> References: <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> <4FEE41BB.3050705@deployingradius.com> <4FF1D185.3080306@isi.edu> <4FF1D529.5000709@isi.edu> From: Eric Rescorla Date: Mon, 2 Jul 2012 10:08:28 -0700 Message-ID: To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlqoQvGYRjrBguIGhRnWloSqXu4MH+heTwPvFyUIjYpol4uBwuTRCZ29tZuntRknfCtTrgv Cc: Jeffrey Hutzelman , Phillip Hallam-Baker , "saag@ietf.org" Subject: Re: [saag] Should security requirements be MUST? 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, 02 Jul 2012 17:09:05 -0000 On Mon, Jul 2, 2012 at 10:06 AM, Joe Touch wrote: > > > On 7/2/2012 10:01 AM, Eric Rescorla wrote: >> >> On Mon, Jul 2, 2012 at 9:51 AM, Joe Touch wrote: > > ... > >>> VoIP, or basically *any* networking (Pandora, e.g.) over an IPsec or PPTP >>> tunnel. >>> >>> Part of the restriction in iOS is precisely because of the lack of >>> hardware >>> support for efficient offloading - vs., e.g., audio playback which is >>> supported in that way. >> >> >> Huh? Do you have any evidence that difficulty of sharing crypto hardware >> is a reason for iOS background processing? Like quotes from Apple >> or somesuch. > > > For things it is designed to do in background, it has outboard processing > (phone, music playback). There's no hardware acceleration for notifications, for instance, but you can do them in the background. > Apple didn't issue a statement about everything it didn't include in its > design. The limitations it posts are based on its *current* architecture. In other words, this is just something you're asserting without evidence. -Ekr From touch@isi.edu Mon Jul 2 10:10: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 5D7DE11E809A for ; Mon, 2 Jul 2012 10:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.789 X-Spam-Level: X-Spam-Status: No, score=-103.789 tagged_above=-999 required=5 tests=[AWL=-1.190, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNq4LSPV3gge for ; Mon, 2 Jul 2012 10:10:33 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 02F3111E809C for ; Mon, 2 Jul 2012 10:10:32 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q62H9IR3026884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Jul 2012 10:09:18 -0700 (PDT) Message-ID: <4FF1D5BE.7070907@isi.edu> Date: Mon, 02 Jul 2012 10:09:18 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Eric Rescorla References: <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> <4FEE41BB.3050705@deployingradius.com> <4FF1D139.5050601@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Phillip Hallam-Baker , "saag@ietf.org" , Jeffrey Hutzelman Subject: Re: [saag] Should security requirements be MUST? 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, 02 Jul 2012 17:10:34 -0000 On 7/2/2012 10:03 AM, Eric Rescorla wrote: > On Mon, Jul 2, 2012 at 9:50 AM, Joe Touch wrote: >> >> >> On 7/2/2012 9:05 AM, Nico Williams wrote: >>> >>> On Mon, Jul 2, 2012 at 7:57 AM, Eric Rescorla wrote: >>>> >>>> Really, I'm finding it pretty hard to believe we're still having this >>>> userland versus kernel debate in 2012. The market has spoken >>>> and userland cryptography won. That was clear back in 1999. >>> >>> >>> Agreed; user-land cryptographic protocols won long ago, and I'd say >>> they won with SSL 2.0, so, really, long, long ago. >> >> >> App-layer. >> >> Where they won, they won because they allowed half the connection to not >> authenticate. > > No, they won because the people deploying the software wanted to be > able to have it just install on the user's machine without screwing with the > kernel. SSL is popular because users don't need to buy X.509 certs or register with an authority to use it. Compare, e.g., how popular SSL is vs. another userland security system that relies on PKI entries for all users - I don't see the general public using PGP. >> BTNS was all about trying to get that benefit for protocols >> like IPsec, that were wound too tightly around a "one size fits all" >> approach, IMO. >> >> And they won for consumer transactions. Secure tunnels can't operate >> efficiently in user-space without defeating outboard transport, network, and >> link protocol support. > > What, you've never heard of an SSL VPN? I've also heard of token ring, but besides the geek community, it's not used all that much. The dominant VPNs are IPsec and PPTP. Joe From touch@isi.edu Mon Jul 2 10:15: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 C16AD21F86CA for ; Mon, 2 Jul 2012 10:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.751 X-Spam-Level: X-Spam-Status: No, score=-103.751 tagged_above=-999 required=5 tests=[AWL=-1.152, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kjxVyanYg+j for ; Mon, 2 Jul 2012 10:15:10 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 005FA21F861C for ; Mon, 2 Jul 2012 10:15:09 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q62HF3Bu028056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Jul 2012 10:15:03 -0700 (PDT) Message-ID: <4FF1D717.8010409@isi.edu> Date: Mon, 02 Jul 2012 10:15:03 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Eric Rescorla References: <4FEE096B.1090602@isi.edu> <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> <4FEE41BB.3050705@deployingradius.com> <4FF1D185.3080306@isi.edu> <4FF1D529.5000709@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Jeffrey Hutzelman , Phillip Hallam-Baker , "saag@ietf.org" Subject: Re: [saag] Should security requirements be MUST? 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, 02 Jul 2012 17:15:11 -0000 On 7/2/2012 10:08 AM, Eric Rescorla wrote: > On Mon, Jul 2, 2012 at 10:06 AM, Joe Touch wrote: >> >> >> On 7/2/2012 10:01 AM, Eric Rescorla wrote: >>> >>> On Mon, Jul 2, 2012 at 9:51 AM, Joe Touch wrote: >> >> ... >> >>>> VoIP, or basically *any* networking (Pandora, e.g.) over an IPsec or PPTP >>>> tunnel. >>>> >>>> Part of the restriction in iOS is precisely because of the lack of >>>> hardware >>>> support for efficient offloading - vs., e.g., audio playback which is >>>> supported in that way. >>> >>> >>> Huh? Do you have any evidence that difficulty of sharing crypto hardware >>> is a reason for iOS background processing? Like quotes from Apple >>> or somesuch. >> >> >> For things it is designed to do in background, it has outboard processing >> (phone, music playback). > > There's no hardware acceleration for notifications, for instance, but you can > do them in the background. They're presumably not a persistent load. >> Apple didn't issue a statement about everything it didn't include in its >> design. The limitations it posts are based on its *current* architecture. > > In other words, this is just something you're asserting without evidence. I gave you evidence - their current architecture dedicates hardware to persistent shared or background processes. I'm not saying this is a difficulty of sharing crypto hardware, but rather the lack if it in the first place. We're both inferring based on current design and current developer recommendations, neither of which state explicitly why they don't have crypto offloading in hardware. Joe From ekr@rtfm.com Mon Jul 2 10:18:33 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 7838711E808C for ; Mon, 2 Jul 2012 10:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.691 X-Spam-Level: X-Spam-Status: No, score=-102.691 tagged_above=-999 required=5 tests=[AWL=0.286, 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 eKkKI36mVK9G for ; Mon, 2 Jul 2012 10:18:32 -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 B4DC111E8086 for ; Mon, 2 Jul 2012 10:18:30 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4046512vbb.31 for ; Mon, 02 Jul 2012 10:18:36 -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:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=Pb5ihAWs8TsRaQn/wTARY6j9iUlVUed/ad7OqmzJBeQ=; b=AVzy11Ei8WlgAp5/scr0TWe/4gmhsiNQ6GEK6RGUQVf0/B7bIK9njo2lSK8oQgskEC KKWLqL59WOKE9UKbNOK9sPwnyyceTp2sgYmpgMrV32C6YLdaUWBYELqe9bm0JEJTcnZC rBaPBSyXrzz4/EgK20scdEHzg+52f0sold+AbjiCurW1/lHGTG0C8ErKheBwbqhUqFdr HvocW+WDGG+ticPveY9fKOXJY2sk/yXTjwbdzWVHgM0REW13qUR6sv1C4juVMIwdpmYu +zMDssPxHiam/3vZH2wJfEPBTghyHWkfi+dveLBS8yFSBii/j+tbr9BJWHMiIr5kRlIx cZGQ== Received: by 10.220.240.148 with SMTP id la20mr6529749vcb.39.1341249515948; Mon, 02 Jul 2012 10:18:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Mon, 2 Jul 2012 10:17:55 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <4FF1D5BE.7070907@isi.edu> References: <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> <4FEE41BB.3050705@deployingradius.com> <4FF1D139.5050601@isi.edu> <4FF1D5BE.7070907@isi.edu> From: Eric Rescorla Date: Mon, 2 Jul 2012 10:17:55 -0700 Message-ID: To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnbRuuxEhGN6GTnbdnVm0gpwvk7KfmgKS+X1s2tuXij+01SI+lYIgz35yNcdvMWOvIN5gAs Cc: Phillip Hallam-Baker , "saag@ietf.org" , Jeffrey Hutzelman Subject: Re: [saag] Should security requirements be MUST? 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, 02 Jul 2012 17:18:34 -0000 On Mon, Jul 2, 2012 at 10:09 AM, Joe Touch wrote: > > > On 7/2/2012 10:03 AM, Eric Rescorla wrote: >> >> On Mon, Jul 2, 2012 at 9:50 AM, Joe Touch wrote: >>> >>> >>> >>> On 7/2/2012 9:05 AM, Nico Williams wrote: >>>> >>>> >>>> On Mon, Jul 2, 2012 at 7:57 AM, Eric Rescorla wrote: >>>>> >>>>> >>>>> Really, I'm finding it pretty hard to believe we're still having this >>>>> userland versus kernel debate in 2012. The market has spoken >>>>> and userland cryptography won. That was clear back in 1999. >>>> >>>> >>>> >>>> Agreed; user-land cryptographic protocols won long ago, and I'd say >>>> they won with SSL 2.0, so, really, long, long ago. >>> >>> >>> >>> App-layer. >>> >>> Where they won, they won because they allowed half the connection to not >>> authenticate. >> >> >> No, they won because the people deploying the software wanted to be >> able to have it just install on the user's machine without screwing with >> the >> kernel. > > > SSL is popular because users don't need to buy X.509 certs or register with > an authority to use it. IPsec could have been run in the same configuration (i.e., with anonymous clients) if people had wanted to. For instance, one could have used self-signed certs on the client side. Seriously, you think Netscape would have shipped a security system that required you to install a kernel module? >>> BTNS was all about trying to get that benefit for protocols >>> like IPsec, that were wound too tightly around a "one size fits all" >>> approach, IMO. >>> >>> And they won for consumer transactions. Secure tunnels can't operate >>> efficiently in user-space without defeating outboard transport, network, >>> and >>> link protocol support. >> >> >> What, you've never heard of an SSL VPN? > > > I've also heard of token ring, but besides the geek community, it's not used > all that much. The dominant VPNs are IPsec and PPTP. Yeah, that's why both Cisco and Juniper have big SSL VPN product lines and why Cisco AnyConnect now supports DTLS. Look, I'm not making an argument about whether SSL VPN is better or worse than IPsec VPNs. But the notion that you can't run SSL/TLS fast is just silly in a world where all of Gmail runs on SSL/TLS. Here's Adam Langley on the topic: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html "In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that." -Ekr From peter.sylvester@edelweb.fr Mon Jul 2 10:20: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 2DE9A21F8617 for ; Mon, 2 Jul 2012 10:20:04 -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 clyplKyqtVSF for ; Mon, 2 Jul 2012 10:20:03 -0700 (PDT) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.13]) by ietfa.amsl.com (Postfix) with ESMTP id A20B721F85A3 for ; Mon, 2 Jul 2012 10:20:03 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by mx1.on-x.com (Postfix) with ESMTP id 3CCB05E066 for ; Mon, 2 Jul 2012 19:19:53 +0200 (CEST) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 4B35781E421 for ; Mon, 2 Jul 2012 19:00:38 +0200 (CEST) Received: from [192.168.18.180] (unknown [192.168.18.180]) by smtps.on-x.com (Postfix) with ESMTPSA id 363D623632F for ; Mon, 2 Jul 2012 13:04:40 -0400 (EDT) Message-ID: <4FF1D869.8030108@edelweb.fr> Date: Mon, 02 Jul 2012 19:20:41 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: saag@ietf.org References: <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> <4FEE41BB.3050705@deployingradius.com> <4FF1D139.5050601@isi. edu> In-Reply-To: <4FF1D139.5050601@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [saag] Should security requirements be MUST? 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, 02 Jul 2012 17:20:04 -0000 On 07/02/2012 06:50 PM, Joe Touch wrote: > > > > And they won for consumer transactions. Secure tunnels can't operate > efficiently in user-space without defeating outboard transport, > network, and link protocol support. minix3 From rbarnes@bbn.com Mon Jul 2 10:23:19 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 A4B2C11E809C for ; Mon, 2 Jul 2012 10:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.532 X-Spam-Level: X-Spam-Status: No, score=-106.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wp68HbMxn6XJ for ; Mon, 2 Jul 2012 10:23:18 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id BD44311E8086 for ; Mon, 2 Jul 2012 10:23:18 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:62889) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SlkLJ-0005FG-6S; Mon, 02 Jul 2012 13:23:21 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4FF1D5BE.7070907@isi.edu> Date: Mon, 2 Jul 2012 13:23:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> <4FEE41BB.3050705@deployingradius.com> <4FF1D139.5050601@isi.edu> <4FF1D5BE.7070907@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1278) Cc: Phillip Hallam-Baker , "saag@ietf.org" , Jeffrey Hutzelman Subject: Re: [saag] Should security requirements be MUST? 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, 02 Jul 2012 17:23:19 -0000 On Jul 2, 2012, at 1:09 PM, Joe Touch wrote: > On 7/2/2012 10:03 AM, Eric Rescorla wrote: >> On Mon, Jul 2, 2012 at 9:50 AM, Joe Touch wrote: >>> On 7/2/2012 9:05 AM, Nico Williams wrote: >>>> On Mon, Jul 2, 2012 at 7:57 AM, Eric Rescorla wrote: >>>>>=20 >>>>> Really, I'm finding it pretty hard to believe we're still having = this >>>>> userland versus kernel debate in 2012. The market has spoken >>>>> and userland cryptography won. That was clear back in 1999. >>>>=20 >>>>=20 >>>> Agreed; user-land cryptographic protocols won long ago, and I'd say >>>> they won with SSL 2.0, so, really, long, long ago. >>>=20 >>>=20 >>> App-layer. >>>=20 >>> Where they won, they won because they allowed half the connection to = not >>> authenticate. >>=20 >> No, they won because the people deploying the software wanted to be >> able to have it just install on the user's machine without screwing = with the >> kernel. >=20 > SSL is popular because users don't need to buy X.509 certs or register = with an authority to use it. >=20 > Compare, e.g., how popular SSL is vs. another userland security system = that relies on PKI entries for all users - I don't see the general = public using PGP. >=20 >>> BTNS was all about trying to get that benefit for protocols >>> like IPsec, that were wound too tightly around a "one size fits all" >>> approach, IMO. >>>=20 >>> And they won for consumer transactions. Secure tunnels can't operate >>> efficiently in user-space without defeating outboard transport, = network, and >>> link protocol support. >>=20 >> What, you've never heard of an SSL VPN? >=20 > I've also heard of token ring, but besides the geek community, it's = not used all that much. The dominant VPNs are IPsec and PPTP. I'm aware of multiple enterprise VPNs based on DTLS. For example: " The Cisco AnyConnect VPN Client provides remote users with secure VPN = connections to the Cisco ASA 5500 Series Adaptive Security Appliance = using the Secure Socket Layer (SSL) protocol and the Datagram TLS (DTLS) = protocol. AnyConnect provides remote end users with the benefits of a = Cisco SSL VPN client, and supports applications and functions = unavailable to a clientless, browser-based SSL VPN connection. " = = From nico@cryptonector.com Mon Jul 2 10:23: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 2CA7B11E80B3 for ; Mon, 2 Jul 2012 10:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.067 X-Spam-Level: X-Spam-Status: No, score=-3.067 tagged_above=-999 required=5 tests=[AWL=-1.090, 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 vyoRsNefEE6B for ; Mon, 2 Jul 2012 10:23:37 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id A428011E80A5 for ; Mon, 2 Jul 2012 10:23:37 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id 185BD26406A for ; Mon, 2 Jul 2012 10:23:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=ydUV4S6P2rppg8J8i8V6P MbA/GUvNUmVpMZk74Dx7fB9gWxMFBAkXOc/gskNUg0k2lX7gC0yHNJ4N4vMtT67u W6VEFAYVeS/b9niEjJRZu8hwpxdyKaYwGIC64Do37bn76rBm5JFuB2dOz4sU2aCm Y6fyvsIk7yGZzkaqi3uiJA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=YmiSm5poSK0NYD54XmI5 XplkvIY=; b=meyUHVj4FWXPrzx6faglwfwBJkrf5b2uIhwgorBhzWmjwiw7ppaL QrhLAYPu3fd8JPfnymRvX5EW+MAUlb3c6YT4IS0xYwvdGANjtv3mbyj9zAfrdxlT /8Xhy2We6FHcupctO/rVvdj/U9HTU9HONGVFpfkjOi5qvk5OikzRV/M= Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPSA id DB187264060 for ; Mon, 2 Jul 2012 10:23:42 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4049675vbb.31 for ; Mon, 02 Jul 2012 10:23:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.223.201 with SMTP id il9mr1185327vcb.61.1341249822118; Mon, 02 Jul 2012 10:23:42 -0700 (PDT) Received: by 10.220.76.203 with HTTP; Mon, 2 Jul 2012 10:23:41 -0700 (PDT) In-Reply-To: References: Date: Mon, 2 Jul 2012 12:23:42 -0500 Message-ID: From: Nico Williams To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Cc: saag@ietf.org Subject: Re: [saag] IPsec, APIs, and x.500 naming (Re: Should security requirements be MUST?) 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, 02 Jul 2012 17:23:38 -0000 On Mon, Jul 2, 2012 at 11:46 AM, Stephen Kent wrote: > Two observations: > - one need not use the subject name for access control decisions > - one can represent a DNS name as Subject name, using the DC > attribute The former would be nice, but since that's not what's implemented, it's not really possible to issue certificates with meaningless (unique, effectively pseudonymous) subjectNames. The latter works for only one name type, and it's a hack. But that's the point: being forced to use the useless Name type means we're forced to encode better name types as Name using ad-hoc conventions. x.500-style naming is stupid and worse than useless -- it is harmful. Nico -- From touch@isi.edu Mon Jul 2 10:35: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 7F33A21F86F3 for ; Mon, 2 Jul 2012 10:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.715 X-Spam-Level: X-Spam-Status: No, score=-103.715 tagged_above=-999 required=5 tests=[AWL=-1.116, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUbQz2+cLga7 for ; Mon, 2 Jul 2012 10:35:17 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id BD91C21F8611 for ; Mon, 2 Jul 2012 10:35:17 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q62HYgxw001945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Jul 2012 10:34:42 -0700 (PDT) Message-ID: <4FF1DBB2.5090407@isi.edu> Date: Mon, 02 Jul 2012 10:34:42 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Eric Rescorla References: <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> <4FEE41BB.3050705@deployingradius.com> <4FF1D139.5050601@isi.edu> <4FF1D5BE.7070907@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Phillip Hallam-Baker , "saag@ietf.org" , Jeffrey Hutzelman Subject: Re: [saag] Should security requirements be MUST? 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, 02 Jul 2012 17:35:18 -0000 On 7/2/2012 10:17 AM, Eric Rescorla wrote: > On Mon, Jul 2, 2012 at 10:09 AM, Joe Touch wrote: ... >> SSL is popular because users don't need to buy X.509 certs or register with >> an authority to use it. > > IPsec could have been run in the same configuration (i.e., with anonymous > clients) if people had wanted to. For instance, one could have used > self-signed certs on the client side. > > Seriously, you think Netscape would have shipped a security system that > required you to install a kernel module? They could have shipped with a security system that used an existing security kernel module, just like they shipped with a communication system that used an existing transport kernel module. They could also have shipped with modules that used kernel modules optionally where present. >>>> BTNS was all about trying to get that benefit for protocols >>>> like IPsec, that were wound too tightly around a "one size fits all" >>>> approach, IMO. >>>> >>>> And they won for consumer transactions. Secure tunnels can't operate >>>> efficiently in user-space without defeating outboard transport, network, >>>> and >>>> link protocol support. >>> >>> >>> What, you've never heard of an SSL VPN? >> >> >> I've also heard of token ring, but besides the geek community, it's not used >> all that much. The dominant VPNs are IPsec and PPTP. > > Yeah, that's why both Cisco and Juniper have big SSL VPN product lines and > why Cisco AnyConnect now supports DTLS. From their pages, these appear to be focused on support for email and web access to SSL-based services. E.g., from Cisco's page: --- SSL VPN Overview Cisco IOS SSL VPN provides SSL VPN remote-access connectivity from almost any Internet-enabled location using only a web browser that natively supports SSL encryption. This feature allows your company to extend access to its secure enterprise network to any authorized user by providing remote-access connectivity to corporate resources from any Internet-enabled location. --- I.e., that's web browser access to services. > Look, I'm not making an argument about whether SSL VPN is better or worse > than IPsec VPNs. But the notion that you can't run SSL/TLS fast is just > silly in a world where all of Gmail runs on SSL/TLS. Here's Adam Langley > on the topic: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html You can run SSL/TLS fast because a) you encrypt over fairly large blocks most of the time (8K+) b) many users toss their entire multicore CPU at the problem, and don't care When you either care about your battery or preserving that $500 CPU for real work, you want a $10 crypto chip to help. When you handle messages that are high-speed but small (1500 bytes or smaller), you want that chip. And when you want TCP/IP offloading hardware assist, you *need* a crypto chip if you want to protect at the transport or network layer. If you don't want any of that - which web browser users don't - then yes, SSL is fine. > "In January this year (2010), Gmail switched to using HTTPS for > everything by default. Previously it had been introduced as an option, > but now all of our users use HTTPS to secure their email between their > browsers and Google, all the time. In order to do this we had to > deploy no additional machines and no special hardware. On our > production frontend machines, SSL/TLS accounts for less than 1% of the > CPU load, less than 10KB of memory per connection and less than 2% of > network overhead. Many people believe that SSL takes a lot of CPU time > and we hope the above numbers (public for the first time) will help to > dispel that." It'd be interesting to understand where their CPU _is_ spending time, and what the average CPU's network capacity is. Email is notoriously disk-limited as well. Joe From ekr@rtfm.com Mon Jul 2 10:44: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 814A311E80B3 for ; Mon, 2 Jul 2012 10:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.708 X-Spam-Level: X-Spam-Status: No, score=-102.708 tagged_above=-999 required=5 tests=[AWL=0.269, 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 yKv0Yhsg4Wuy for ; Mon, 2 Jul 2012 10:44:57 -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 B2FF021F876D for ; Mon, 2 Jul 2012 10:44:57 -0700 (PDT) Received: by vcqp1 with SMTP id p1so4058399vcq.31 for ; Mon, 02 Jul 2012 10:45:03 -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:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=N6jN6MMJcdC0+/+pm2lltjbvSdlIbNUH3y2VbRGlRgU=; b=OvwsvbjaoupBLvYZ0tzYuC97K4gNGzgmEXFC9O0VTWLTnn5P3pla3kk+61fy8ARnEm AkqZxkWAEXV03vS86z22ujlkv7kzC37dlPXoauECDa1E4n/Ftz6zdvLnJukcY4t2wemZ KcuHCwONQoGnWik0d8Vw0YGnownDZQ/4884N6Ghf6cqBIz2Pgi2Tg1obg3lP8IruYnbx Rz/6lhkYsl8M/NIHBZ0jbYMJcgcODTUt+acGk1cVPR619iem52YLJhPUGpnxotPqIE14 rMceP5ng2k7nNSbruB/e8TQj//Y60JE//rzV+y5ygYiQGx8IopcM4CXdZJpgOfDe1zZo XTBQ== Received: by 10.52.88.170 with SMTP id bh10mr5413248vdb.11.1341251103028; Mon, 02 Jul 2012 10:45:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Mon, 2 Jul 2012 10:44:22 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <4FF1DBB2.5090407@isi.edu> References: <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> <4FEE41BB.3050705@deployingradius.com> <4FF1D139.5050601@isi.edu> <4FF1D5BE.7070907@isi.edu> <4FF1DBB2.5090407@isi.edu> From: Eric Rescorla Date: Mon, 2 Jul 2012 10:44:22 -0700 Message-ID: To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnZv5lBwlvVqKdB1uyCCUn4NIlAsn2ZWfTYdu48Fouj18nnQtTxE5cWpebLA5qYsfylA3mT Cc: Phillip Hallam-Baker , "saag@ietf.org" , Jeffrey Hutzelman Subject: Re: [saag] Should security requirements be MUST? 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, 02 Jul 2012 17:44:58 -0000 On Mon, Jul 2, 2012 at 10:34 AM, Joe Touch wrote: > > > On 7/2/2012 10:17 AM, Eric Rescorla wrote: >> >> On Mon, Jul 2, 2012 at 10:09 AM, Joe Touch wrote: > > ... > >>> SSL is popular because users don't need to buy X.509 certs or register >>> with >>> an authority to use it. >> >> >> IPsec could have been run in the same configuration (i.e., with anonymous >> clients) if people had wanted to. For instance, one could have used >> self-signed certs on the client side. >> >> Seriously, you think Netscape would have shipped a security system that >> required you to install a kernel module? > > > They could have shipped with a security system that used an existing > security kernel module, just like they shipped with a communication system > that used an existing transport kernel module. Please do tell: what existing security kernel module was available in 1995 across the entire range of operating systems that people ran browsers on? > They could also have shipped with modules that used kernel modules > optionally where present. What would be the point of that once you already had to absorb the cost of shipping the crypto? Look, I was actually involved in building cryptographic software intended for use by consumers at the time that SSL/TLS was being designed, and I can assure you that people thought that the need to install a kernel module (not to mention the cost of developing one for an array of operating systems) was a huge issue. You can believe that or not, but really, if you and I have this different views of the history of this technology, then I don't think there's much more to say. -Ekr From ekr@rtfm.com Mon Jul 2 10:51: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 4BB5911E80C8 for ; Mon, 2 Jul 2012 10:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.723 X-Spam-Level: X-Spam-Status: No, score=-102.723 tagged_above=-999 required=5 tests=[AWL=0.254, 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 buEGdH6KVI60 for ; Mon, 2 Jul 2012 10:51:24 -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 E029621F8772 for ; Mon, 2 Jul 2012 10:51:23 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4066643vbb.31 for ; Mon, 02 Jul 2012 10:51:20 -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:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=/VCEDSAHKPDIrHN1h95wlHelwi+EvrKXPWkEPZrSNSc=; b=mvXrLC3OOhdkPA+hOAuy4Kh7Fm6r+ou1aZUB3QHdNdSn0Wp7SDGDmV90YVSGYclapt s7iTQTT8ZVe38+14SEj/0/z/Hj8bO3yYsUsb+LYyVSXEvKFnaDm7wd71JIrqig6EvWSN RSHjkoBI6+oeNq5pdmyU/mwm6R6+OuIPYyDK7JrZY8qck+V3IN30KIe5zAYfpGd7nR3D 0VThOELyfcf67dwT5qthRco+DBmolBUHu48AOgFvhSpw/jtZjvhDgcq1M3rObV5yg8UI UffPyT6awNXTvkedn6tpS1GuSFGNT+hTL5XxIyYg0Zar/u3uO7BbIR3YirgcUr96Uk/D u5bA== Received: by 10.220.224.77 with SMTP id in13mr6641676vcb.9.1341251480550; Mon, 02 Jul 2012 10:51:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Mon, 2 Jul 2012 10:50:40 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <4FF1DBB2.5090407@isi.edu> References: <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> <4FEE41BB.3050705@deployingradius.com> <4FF1D139.5050601@isi.edu> <4FF1D5BE.7070907@isi.edu> <4FF1DBB2.5090407@isi.edu> From: Eric Rescorla Date: Mon, 2 Jul 2012 10:50:40 -0700 Message-ID: To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnVeU5ZRVOXQV7nJ2c22L5ioMfyEzF6QOwGIh1b2Eb8TEqIq1Mgc+Wn1qe3QIaMjdLw4UvY Cc: Phillip Hallam-Baker , "saag@ietf.org" , Jeffrey Hutzelman Subject: Re: [saag] Should security requirements be MUST? 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, 02 Jul 2012 17:51:25 -0000 One more thing. On Mon, Jul 2, 2012 at 10:34 AM, Joe Touch wrote: > When you either care about your battery or preserving that $500 CPU for real > work, you want a $10 crypto chip to help. > > When you handle messages that are high-speed but small (1500 bytes or > smaller), you want that chip. This isn't true. Performance of encryption and decryption is nearly linear in messages encrypted. Yes, HMAC-SHA1 has some per-record overhead but it is amortized very quickly by message size. See, for instance, Rescorla, "SSL and TLS", page 199. Additionally, see Langley again: "But don't make the records too large either! See the 15KB record that https://www.bankofamerica.com sent? None of that data can be parsed by the browser until the whole record has been received. As the congestion window opens up, those large records tend to span several windows and so there's an extra round trip of delay before the browser gets any of that data. Since the browser is pre-parsing the HTML for subresources, it'll delay discovery and cause more knock-on effects. So how large should records be? There's always going to be some uncertainty in that number because the size of the TCP header depends on the OS and the number of SACK blocks that need to be sent. In the ideal case, each packet is full and contains exactly one record. Start with a value of 1415 bytes for a non-padded ciphersuite (like RC4), or 1403 bytes for an AES based ciphersuite and look at the packets which result from that." -Ekr From marsh@extendedsubset.com Mon Jul 2 10:52: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 D469A11E80D5 for ; Mon, 2 Jul 2012 10:52:41 -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 6K+9-d234ybw for ; Mon, 2 Jul 2012 10:52:41 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id D89D611E80C4 for ; Mon, 2 Jul 2012 10:52:40 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1Slknl-000Lbb-MK; Mon, 02 Jul 2012 17:52:45 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id D498863C0; Mon, 2 Jul 2012 17:52:43 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX191L8rv7m+55K/VQ4eGLgvb6mNtv/2kxyc= Message-ID: <4FF1DFEA.1010606@extendedsubset.com> Date: Mon, 02 Jul 2012 12:52:42 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Joe Touch References: <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> <4FEE41BB.3050705@deployingradius.com> <4FF1D139.5050601@isi.edu> <4FF1D5BE.7070907@isi.edu> <4FF1DBB2.5090407@isi.edu> In-Reply-To: <4FF1DBB2.5090407@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Phillip Hallam-Baker , "saag@ietf.org" , Jeffrey Hutzelman Subject: Re: [saag] Should security requirements be MUST? 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, 02 Jul 2012 17:52:42 -0000 On 07/02/2012 12:34 PM, Joe Touch wrote: >> >> Seriously, you think Netscape would have shipped a security system that >> required you to install a kernel module? > > They could have shipped with a security system that used an existing > security kernel module, just like they shipped with a communication > system that used an existing transport kernel module. I'm sorry dude but that's just ridiculous. If fact, Netscape shipped a time when kernel TCP/IP modules didn't exist on many clients. Netscape shipped SSL 6 months before IPsec was even described for the first time in RFC 1825. Of course there were no kernel crypto modules. Today on a popular platform like MS Windows there are OS-provided crypto modules. Some apps use them, some don't. But you can bet if it were a significant perf benefit to doing it in kernel mode this optimization would have gotten to network programmers. In fact, Windows IIS and Linux both have in-kernel http servers but this has everything to do with reducing user-kernel mode context switches and nothing to do with crypto performance. The only crypto performance issues I ever hear of people having on modern hardware is the asymmetric key operations. And with that, I'm pretty sure this thread has overextended its ability to inform. - Marsh From touch@isi.edu Mon Jul 2 11:01: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 3494211E80F9 for ; Mon, 2 Jul 2012 11:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.681 X-Spam-Level: X-Spam-Status: No, score=-103.681 tagged_above=-999 required=5 tests=[AWL=-1.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVLf4WluZ9wL for ; Mon, 2 Jul 2012 11:01:05 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id B13FD11E80F4 for ; Mon, 2 Jul 2012 11:01:05 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q62I0tEV007436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Jul 2012 11:00:55 -0700 (PDT) Message-ID: <4FF1E1D6.9050907@isi.edu> Date: Mon, 02 Jul 2012 11:00:54 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Eric Rescorla References: <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> <4FEE41BB.3050705@deployingradius.com> <4FF1D139.5050601@isi.edu> <4FF1D5BE.7070907@isi.edu> <4FF1DBB2.5090407@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Phillip Hallam-Baker , "saag@ietf.org" , Jeffrey Hutzelman Subject: Re: [saag] Should security requirements be MUST? 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, 02 Jul 2012 18:01:06 -0000 On 7/2/2012 10:44 AM, Eric Rescorla wrote: .... >> They could have shipped with a security system that used an existing >> security kernel module, just like they shipped with a communication system >> that used an existing transport kernel module. > > Please do tell: what existing security kernel module was available in > 1995 across the entire range of operating systems that people > ran browsers on? IPsec didn't exist, nor did PPTP at the time. But that was 1995. There have been more than a few releases since then. I don't know anyone who's still running 1995 browser software. >> They could also have shipped with modules that used kernel modules >> optionally where present. > > What would be the point of that once you already had to absorb the > cost of shipping the crypto? Backup support for services isn't uncommon. Even at the time kernel updates were fairly frequent - as frequent as app updates, in some cases (e.g., comparing release histories of MacOS, for which minor version numbers exist vs patch history, and Netscape). > Look, I was actually involved in building cryptographic software intended > for use by consumers at the time that SSL/TLS was being designed, > and I can assure you that people thought that the need to install a kernel > module (not to mention the cost of developing one for an array of operating > systems) was a huge issue. I recall that too - when you told them it was a kernel module they freaked, but those same people updated their OS, or bought new hardware fairly regularly anyway. What people complain about and what they do anyway aren't always related. I also recall realizing that SSL got it right regarding keys - which is why I brought up BTNS. IPsec is now in everything, including cellphone OSes, but it's rarely used except in enterprises, largely because of the key distribution issue. Joe From david.black@emc.com Mon Jul 2 11:06:48 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 C5F7821F8628 for ; Mon, 2 Jul 2012 11:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiIWtALGJpBC for ; Mon, 2 Jul 2012 11:06:47 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id AEAE121F8627 for ; Mon, 2 Jul 2012 11:06:47 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q62I6jPs013066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jul 2012 14:06:51 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Mon, 2 Jul 2012 14:06:25 -0400 Received: from mxhub21.corp.emc.com (mxhub21.corp.emc.com [128.222.70.133]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q62I6MYb013457; Mon, 2 Jul 2012 14:06:23 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub21.corp.emc.com ([128.222.70.133]) with mapi; Mon, 2 Jul 2012 14:06:22 -0400 From: To: Date: Mon, 2 Jul 2012 14:06:21 -0400 Thread-Topic: SSL VPN Thread-Index: Ac1YeSQNnJ8X59VURHSNJETAOYzEIwAAva8Q Message-ID: <8D3D17ACE214DC429325B2B98F3AE71208D3AB53@MX15A.corp.emc.com> References: <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> <4FEE41BB.3050705@deployingradius.com> <4FF1D139.5050601@isi.edu> <4FF1D5BE.7070907@isi.edu> <4FF1DBB2.5090407@isi.edu> In-Reply-To: <4FF1DBB2.5090407@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: saag@ietf.org Subject: [saag] SSL VPN 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, 02 Jul 2012 18:06:48 -0000 Joe Touch writes: >>>> What, you've never heard of an SSL VPN? >>> >>> I've also heard of token ring, but besides the geek community, it's not= used >>> all that much. The dominant VPNs are IPsec and PPTP. >> >> Yeah, that's why both Cisco and Juniper have big SSL VPN product lines a= nd >> why Cisco AnyConnect now supports DTLS. > > From their pages, these appear to be focused on support for email and > web access to SSL-based services. E.g., from Cisco's page: >=20 > --- > SSL VPN Overview >=20 > Cisco IOS SSL VPN provides SSL VPN remote-access connectivity from > almost any Internet-enabled location using only a web browser that > natively supports SSL encryption. This feature allows your company to > extend access to its secure enterprise network to any authorized user by > providing remote-access connectivity to corporate resources from any > Internet-enabled location. > --- >=20 > I.e., that's web browser access to services. That's wrong, sorry. An SSL VPN provides full IP network extension - it's most definitely not browser-only. The technology is effectively IP encapsulation in TLS, not clever use of TLS to access "SSL-based services." EMC uses AnyConnect for secure remote access, and it effectively replaced usage of remote access IPsec VPNs for the entire company. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From touch@isi.edu Mon Jul 2 11:13:33 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 2218F21F8734 for ; Mon, 2 Jul 2012 11:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.649 X-Spam-Level: X-Spam-Status: No, score=-105.649 tagged_above=-999 required=5 tests=[AWL=0.950, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfEsA7Nub1OG for ; Mon, 2 Jul 2012 11:13:32 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3685621F85C2 for ; Mon, 2 Jul 2012 11:13:32 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q62ID1hA020188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Jul 2012 11:13:01 -0700 (PDT) Message-ID: <4FF1E4AC.40900@isi.edu> Date: Mon, 02 Jul 2012 11:13:00 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Eric Rescorla References: <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> <4FEE41BB.3050705@deployingradius.com> <4FF1D139.5050601@isi.edu> <4FF1D5BE.7070907@isi.edu> <4FF1DBB2.5090407@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Phillip Hallam-Baker , "saag@ietf.org" , Jeffrey Hutzelman Subject: Re: [saag] Should security requirements be MUST? 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, 02 Jul 2012 18:13:33 -0000 On 7/2/2012 10:50 AM, Eric Rescorla wrote: > One more thing. > > On Mon, Jul 2, 2012 at 10:34 AM, Joe Touch wrote: > >> When you either care about your battery or preserving that $500 CPU for real >> work, you want a $10 crypto chip to help. >> >> When you handle messages that are high-speed but small (1500 bytes or >> smaller), you want that chip. > > This isn't true. Performance of encryption and decryption is nearly linear > in messages encrypted. Yes, HMAC-SHA1 has some per-record overhead > but it is amortized very quickly by message size. That must be why the high-speed SSL you cite uses 8K blocks, rather than something that might correspond better to the TCP packets sent. > See, for instance, > Rescorla, "SSL and TLS", page 199. > > Additionally, see Langley again: > "But don't make the records too large either! See the 15KB record that > https://www.bankofamerica.com sent? None of that data can be parsed by > the browser until the whole record has been received. As the > congestion window opens up, those large records tend to span several > windows and so there's an extra round trip of delay before the browser > gets any of that data. Except for the first 3 or so round trips where this matters, ACK clocking will prevent this sort of "full RTT delay". The RTTs of delay that are seen in these cases are typically from misconfigured Nagle. Joe From touch@isi.edu Mon Jul 2 11:17: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 CACE921F8777 for ; Mon, 2 Jul 2012 11:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.676 X-Spam-Level: X-Spam-Status: No, score=-105.676 tagged_above=-999 required=5 tests=[AWL=0.923, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmXnIl7OySkT for ; Mon, 2 Jul 2012 11:17:29 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5D01521F85C2 for ; Mon, 2 Jul 2012 11:17:29 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q62IGLct020850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Jul 2012 11:16:21 -0700 (PDT) Message-ID: <4FF1E575.40608@isi.edu> Date: Mon, 02 Jul 2012 11:16:21 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Marsh Ray References: <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> <4FEE41BB.3050705@deployingradius.com> <4FF1D139.5050601@isi.edu> <4FF1D5BE.7070907@isi.edu> <4FF1DBB2.5090407@isi.edu> <4FF1DFEA.1010606@extendedsubset.! com> In-Reply-To: <4FF1DFEA.1010606@extendedsubset.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Phillip Hallam-Baker , "saag@ietf.org" , Jeffrey Hutzelman Subject: Re: [saag] Should security requirements be MUST? 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, 02 Jul 2012 18:17:29 -0000 On 7/2/2012 10:52 AM, Marsh Ray wrote: > On 07/02/2012 12:34 PM, Joe Touch wrote: >>> >>> Seriously, you think Netscape would have shipped a security system that >>> required you to install a kernel module? >> >> They could have shipped with a security system that used an existing >> security kernel module, just like they shipped with a communication >> system that used an existing transport kernel module. > > I'm sorry dude but that's just ridiculous. > > If fact, Netscape shipped a time when kernel TCP/IP modules didn't exist > on many clients. Clearly everything Netscape first shipped with hasn't changed in 17 years. Oh, and why it's still available. Things change, and there have been many opportunities to use kernel modules over the years. "First out" isn't always the winner (or are you all using SGML and Fetch?) Joe From kent@bbn.com Mon Jul 2 11: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 7486321F8792 for ; Mon, 2 Jul 2012 11:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.459 X-Spam-Level: X-Spam-Status: No, score=-106.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uli2yS+jVDGX for ; Mon, 2 Jul 2012 11:19:30 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7686C21F851A for ; Mon, 2 Jul 2012 11:19:30 -0700 (PDT) Received: from dhcp89-089-227.bbn.com ([128.89.89.227]:49245) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SllDj-0006Kx-DX; Mon, 02 Jul 2012 14:19:35 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 2 Jul 2012 14:14:40 -0400 To: Nico Williams From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: saag@ietf.org Subject: Re: [saag] IPsec, APIs, and x.500 naming (Re: Should security requirements be MUST?) 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, 02 Jul 2012 18:19:31 -0000 At 12:23 PM -0500 7/2/12, Nico Williams wrote: >On Mon, Jul 2, 2012 at 11:46 AM, Stephen Kent wrote: >> Two observations: >> - one need not use the subject name for access control decisions >> - one can represent a DNS name as Subject name, using the DC >> attribute > >The former would be nice, but since that's not what's implemented, >it's not really possible to issue certificates with meaningless >(unique, effectively pseudonymous) subjectNames. are you familiar with the RPKI, where the Subject and Issuer names typically are hashes of public keys? See RFCs 6480-6493. > The latter works for >only one name type, and it's a hack. it is precisely the name type that you cited as a more natural one. IP addresses are are supported via Alt names, too. > But that's the point: being >forced to use the useless Name type means we're forced to encode >better name types as Name using ad-hoc conventions. I should have mentioned that PKIX does NOT require a Subject name in an end-entity cert, which is the type of cert relevant to end-point authentication in these contexts. So, the only directory name in such certs would be for the issuer. > x.500-style >naming is stupid and worse than useless -- it is harmful. that's a personal perspective, not an objective characterization. Steve From kent@bbn.com Mon Jul 2 11: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 970C321F851A for ; Mon, 2 Jul 2012 11:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.469 X-Spam-Level: X-Spam-Status: No, score=-106.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lq26bv2ycEoz for ; Mon, 2 Jul 2012 11:19:31 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 17A0621F8787 for ; Mon, 2 Jul 2012 11:19:31 -0700 (PDT) Received: from dhcp89-089-227.bbn.com ([128.89.89.227]:49245) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SllDk-0006Kx-7Z; Mon, 02 Jul 2012 14:19:36 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 2 Jul 2012 14:18:32 -0400 To: Nico Williams From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: saag@ietf.org Subject: Re: [saag] IPsec, APIs, and x.500 naming (Re: Should security requirements be MUST?) 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, 02 Jul 2012 18:19:31 -0000 At 12:23 PM -0500 7/2/12, Nico Williams wrote: >On Mon, Jul 2, 2012 at 11:46 AM, Stephen Kent wrote: >> Two observations: >> - one need not use the subject name for access control decisions >> - one can represent a DNS name as Subject name, using the DC >> attribute > >The former would be nice, but since that's not what's implemented, implemented by whom? we have lots of examples of bad code for all sorts of IET standards. My favorite, recent example is an apparent lack of support for the name constraints extension in a OS of a major vendor. this failure to support a mandatory feature that has been part of X.509 & PKIX for over a decade is causing problems as browser vendors and TAs try to limit some of the damage that results from the unconstrained browser TA model. >it's not really possible to issue certificates with meaningless >(unique, effectively pseudonymous) subjectNames. not true. see my previous message. Steve From tytso@thunk.org Mon Jul 2 11:24: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 38D3221F873D for ; Mon, 2 Jul 2012 11:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.343 X-Spam-Level: X-Spam-Status: No, score=-1.343 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, IP_NOT_FRIENDLY=0.334] 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 Mo6sJv5kFVlL for ; Mon, 2 Jul 2012 11:24:12 -0700 (PDT) Received: from imap.thunk.org (li9-11.members.linode.com [67.18.176.11]) by ietfa.amsl.com (Postfix) with ESMTP id C587321F845E for ; Mon, 2 Jul 2012 11:24:11 -0700 (PDT) Received: from root (helo=closure.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.72) (envelope-from ) id 1SllID-0004zY-Ph; Mon, 02 Jul 2012 18:24:13 +0000 Received: by closure.thunk.org (Postfix, from userid 15806) id 3C904241486; Mon, 2 Jul 2012 14:24:14 -0400 (EDT) Date: Mon, 2 Jul 2012 14:24:14 -0400 From: Theodore Ts'o To: Joe Touch Message-ID: <20120702182414.GE5795@thunk.org> References: <4FF1D139.5050601@isi.edu> <4FF1D5BE.7070907@isi.edu> <4FF1DBB2.5090407@isi.edu> <4FF1DFEA.1010606@extendedsubset.!com> <4FF1E575.40608@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FF1E575.40608@isi.edu> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Cc: Jeffrey Hutzelman , Phillip Hallam-Baker , "saag@ietf.org" Subject: Re: [saag] Should security requirements be MUST? 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, 02 Jul 2012 18:24:13 -0000 On Mon, Jul 02, 2012 at 11:16:21AM -0700, Joe Touch wrote: > >If fact, Netscape shipped a time when kernel TCP/IP modules didn't exist > >on many clients. > > Clearly everything Netscape first shipped with hasn't changed in 17 years. > > Oh, and why it's still available. > > Things change, and there have been many opportunities to use kernel > modules over the years. "First out" isn't always the winner (or are > you all using SGML and Fetch?) Sure, but what it means is that SSL had the first mover advantage. If IPSEC was going to displace SSL it would have needed to be significantly better in terms features, functionality, ease-of-use, ease-of-deployability, etc. Unfortunately, the lack of standard API, the unevenness which OS providers adopted IPSEC, etc., meant that in the eyes of application developers IPSEC was significantly worse than SSL, not better. Yes, today IPSEC support is in most OS's. And in theory someone could create a simple, easy to use userspace library which applications could use, and this API could expose enough information on a per-TCP connection basis so that a server could make authorization decisions. (The discussion of whether x.509 certificate names is a wash, given SSL is also using certificates, so it doesn't matter for the purposes of this discussion.) But even supposing all of this work got done, what's the killer feature that would cause people to want to migrate to using IPSCEC instead of SSL? If there isn't one, then even if all of the standards work is done, adoption will be slow and uneven. Sort of like the adoption rate of IPv6 until we actually started running out of IPv4 addresses.... - Ted From mouse@Sparkle.Rodents-Montreal.ORG Mon Jul 2 11:37: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 EA44711E80D7 for ; Mon, 2 Jul 2012 11:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.945 X-Spam-Level: X-Spam-Status: No, score=-8.945 tagged_above=-999 required=5 tests=[AWL=1.043, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, 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 XLcftegjeQ8f for ; Mon, 2 Jul 2012 11:37:21 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id EB50011E80D1 for ; Mon, 2 Jul 2012 11:37:20 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id OAA25965; Mon, 2 Jul 2012 14:37:25 -0400 (EDT) Date: Mon, 2 Jul 2012 14:37:25 -0400 (EDT) From: Mouse Message-Id: <201207021837.OAA25965@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: Mon, 2 Jul 2012 14:26:20 -0400 (EDT) To: saag@ietf.org In-Reply-To: <4FF1D12D.2060209@extendedsubset.com> References: <4FECDEB8.6030600@deployingradius.com> <4FECF995.60009@deployingradius.com> <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> <4FEE41BB.3050705@deployingradius.com> <4FEE4442.70208@isi.! e du> <4FEEEEAA.3090601@deployingradius.com> <4FF1D12D.2060209@extendedsubset.com> Subject: Re: [saag] Should security requirements be MUST? 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, 02 Jul 2012 18:37:27 -0000 > I'm not convinced that userland code is incapable of benefiting from > crypto hardware. In general, "userland code cannot benefit from crypto hardware" is false. However, an equally general "userland code can benefit from crypto hardware" is also false. There are a whole lot of factors involved, many of which depend on sufficiently detailed aspects of the task at hand that we can't really say much more than vague handwaves in a thread like this. I was once involved in setting up an OpenVPN tunnel. The machine had a crypto accelerator, but using it proved to actually _impair_ performance. I investigated this and eventually came to the conclusion that, for that application on that hardware with that OS (all three of which are important qualifications), the cost of the kernel/user crossings involved more than outweighed the gain from the crypto hardware. Given the application, it couldn't throw more than some 1500 bytes at the crypto chip at once, and it took more like 8K-10K to actually get a speedup after overhead was taken into account. Of course, if the crypto accelerator had been accessible without needing to do a syscall trap...if the application had been able to throw more than 1½K at the chip at once...if syscall traps had been cheaper...then the tradeoffs would have been different. This is why I remarked that all the qualifiers I mentioned above were relevant. /~\ 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 ekr@rtfm.com Mon Jul 2 11:44: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 82E3811E810B for ; Mon, 2 Jul 2012 11:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.203 X-Spam-Level: X-Spam-Status: No, score=-102.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 pzVqGRBHIkP7 for ; Mon, 2 Jul 2012 11:44:40 -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 DD36911E8105 for ; Mon, 2 Jul 2012 11:44:40 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so8174266pbc.31 for ; Mon, 02 Jul 2012 11:44:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=e81RIgkmRdxRb+7Ec3wEuF6Vf35AYwtpOuV8YXBanok=; b=C6DKPxjVRe653QmWOkPxK1ActclKm7FHqxBESUKB4tlgpdLPNajOiUtDprOHOfr+8+ F7mR0Q2dAjB3huH191w3CqxPhS6mkcl4GVN2MAbmAGbJ7tsbZLijA5yMJu7HUgFTTd5S 9WbnTWLVucdrU8S2j29Af3h/iUFLNGoGz322SEtGorFwkLsOfrn3l4CwrfIr1pt5jSPN Ral1nvCv+nk4jmjwM3qRDKlJS4eRUDl6PGIJNH6nEXXePE4wXwi3DyBuXtgJ7OEZgNaT toFUUfGTG8cQLuv/hTZfrjy7Cirzd+JKLSlEtXITgRuEjdgvijt604KSFHEOmbJC+P9x wbBA== Received: by 10.68.237.74 with SMTP id va10mr499352pbc.46.1341254686373; Mon, 02 Jul 2012 11:44:46 -0700 (PDT) Received: from [10.195.148.76] (mobile-198-228-213-217.mycingular.net. [198.228.213.217]) by mx.google.com with ESMTPS id he9sm13550458pbc.68.2012.07.02.11.44.44 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Jul 2012 11:44:45 -0700 (PDT) References: <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> <4FEE41BB.3050705@deployingradius.com> <4FF1D139.5050601@isi.edu> <4FF1D5BE.7070907@isi.edu> <4FF1DBB2.5090407@isi.edu> <4FF1E4AC.40900@isi.edu> In-Reply-To: <4FF1E4AC.40900@isi.edu> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <38A0BAB5-196F-4C1D-A53D-9BD3969709C4@rtfm.com> X-Mailer: iPhone Mail (9B206) From: Eric Rescorla Date: Mon, 2 Jul 2012 11:44:45 -0700 To: Joe Touch X-Gm-Message-State: ALoCoQmCHvbEYB5sjvXo5Dwn8v3DEuIhJcW9XbTA5YGBrIKUJE0Zx16T6n0kcvmjmXj/Ly2+L0ji Cc: Phillip Hallam-Baker , "saag@ietf.org" , Jeffrey Hutzelman Subject: Re: [saag] Should security requirements be MUST? 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, 02 Jul 2012 18:44:41 -0000 On Jul 2, 2012, at 11:13, Joe Touch wrote: >=20 >=20 > On 7/2/2012 10:50 AM, Eric Rescorla wrote: >> One more thing. >>=20 >> On Mon, Jul 2, 2012 at 10:34 AM, Joe Touch wrote: >>=20 >>> When you either care about your battery or preserving that $500 CPU for r= eal >>> work, you want a $10 crypto chip to help. >>>=20 >>> When you handle messages that are high-speed but small (1500 bytes or >>> smaller), you want that chip. >>=20 >> This isn't true. Performance of encryption and decryption is nearly linea= r >> in messages encrypted. Yes, HMAC-SHA1 has some per-record overhead >> but it is amortized very quickly by message size. >=20 > That must be why the high-speed SSL you cite uses 8K blocks, rather than s= omething that might correspond better to the TCP packets sent. >=20 You must be thinking of someone else. I've provided you measurements that support what I am saying. Unless you hav= e measurements that show differently I don't think there is much to talk abo= ut Ekr > > See, for instance, >> Rescorla, "SSL and TLS", page 199. >>=20 >> Additionally, see Langley again: >> "But don't make the records too large either! See the 15KB record that >> https://www.bankofamerica.com sent? None of that data can be parsed by >> the browser until the whole record has been received. As the >> congestion window opens up, those large records tend to span several >> windows and so there's an extra round trip of delay before the browser >> gets any of that data. >=20 > Except for the first 3 or so round trips where this matters, ACK clocking w= ill prevent this sort of "full RTT delay". The RTTs of delay that are seen i= n these cases are typically from misconfigured Nagle. > Joe From jhutz@cmu.edu Mon Jul 2 12:12: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 AD0EC11E80C8 for ; Mon, 2 Jul 2012 12:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HR6GkyCdo2Mw for ; Mon, 2 Jul 2012 12:12:13 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by ietfa.amsl.com (Postfix) with ESMTP id 08AD611E8098 for ; Mon, 2 Jul 2012 12:12:12 -0700 (PDT) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id q62JCEiJ015034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jul 2012 15:12:15 -0400 (EDT) From: Jeffrey Hutzelman To: Eric Rescorla In-Reply-To: <38A0BAB5-196F-4C1D-A53D-9BD3969709C4@rtfm.com> References: <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> <4FEE41BB.3050705@deployingradius.com> <4FF1D139.5050601@isi.edu> <4FF1D5BE.7070907@isi.edu> <4FF1DBB2.5090407@isi.edu> <4FF1E4AC.40900@isi.edu> <38A0BAB5-196F-4C1D-A53D-9BD3969709C4@rtfm.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 02 Jul 2012 15:03:44 -0400 Message-ID: <1341255824.31047.424.camel@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: Phillip Hallam-Baker , "saag@ietf.org" , jhutz@cmu.edu Subject: Re: [saag] Should security requirements be MUST? 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, 02 Jul 2012 19:12:13 -0000 OK, folks, that's enough. This discussion has gone far, far afield of the original question, and IMHO no longer addresses any question useful in either the design of current and future Internet standards or in the writing of the documents that describe them. And frankly, I'm getting tired of watching Joe and ekr argue. I've seen over 20 messages in this thread in my inbox in the last couple of hours, and it's getting old. Please stop. Please? -- Jeff From mfisk@lanl.gov Mon Jul 2 12:28: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 0D86821F8528 for ; Mon, 2 Jul 2012 12:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZC3NXqD0qwK for ; Mon, 2 Jul 2012 12:28:40 -0700 (PDT) Received: from proofpoint4.lanl.gov (proofpoint4.lanl.gov [204.121.3.52]) by ietfa.amsl.com (Postfix) with ESMTP id 102C521F8525 for ; Mon, 2 Jul 2012 12:28:39 -0700 (PDT) Received: from mailrelay2.lanl.gov (mailrelay2.lanl.gov [128.165.4.103]) by proofpoint4.lanl.gov (8.14.4/8.14.4) with ESMTP id q62JSalH022613; Mon, 2 Jul 2012 13:28:36 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailrelay2.lanl.gov (Postfix) with ESMTP id 0F4E919B93C6; Mon, 2 Jul 2012 13:28:36 -0600 (MDT) X-NIE-2-Virus-Scanner: amavisd-new at mailrelay2.lanl.gov Received: from ECS-EXG-P-CH05.win.lanl.gov (ecs-exg-p-ch05.win.lanl.gov [128.165.106.15]) by mailrelay2.lanl.gov (Postfix) with ESMTP id D850E19B93BC; Mon, 2 Jul 2012 13:28:35 -0600 (MDT) Received: from ECS-EXG-P-MB03.win.lanl.gov ([169.254.3.249]) by ECS-EXG-P-CH05.win.lanl.gov ([128.165.106.15]) with mapi id 14.02.0298.004; Mon, 2 Jul 2012 13:28:31 -0600 From: "Fisk, Mike" To: "'david.black@emc.com'" , "'touch@isi.edu'" Thread-Topic: [saag] SSL VPN Thread-Index: AQHNWH162Xx34iORjEOBoGPIACJI4pcWYLuH Date: Mon, 2 Jul 2012 19:28:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.165.106.221] Content-Type: multipart/alternative; boundary="_000_E894488ED5401F468DE846F92E9ABA1922968104ECSEXGPMB03winl_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-07-02_04:2012-07-02, 2012-07-02, 1970-01-01 signatures=0 Cc: "'saag@ietf.org'" Subject: Re: [saag] SSL VPN 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, 02 Jul 2012 19:28:41 -0000 --_000_E894488ED5401F468DE846F92E9ABA1922968104ECSEXGPMB03winl_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIG1hcmtldGluZyBhcm91bmQgU1NMIFZQTiBpcyBwcmV0dHkgYXRyb2Npb3VzIGluIG15IG9w aW5pb24uLi4gTW9zdCBwcm9kdWN0cyBiYXNpY2FsbHkgcHJvdmlkZSBhbiBTU0wgcHJveHkgdG8g aW50ZXJuYWwgd2ViIHNlcnZlcnMgYW5kLCBvcHRpb25hbGx5LCBhICJicm93c2VyLWJhc2VkIiBw bHVnaW4gdGhhdCBpbnN0YWxscyBhIGZ1bGwga2VybmVsLWxldmVsIG5ldHdvcmsgdHVubmVsIGZv ciB5b3UuIE9uIExpbnV4LCBmb3IgZXhhbXBsZSwgb25lIG1ham9yIHZlbmRvciBwcm92aWRlcyBh IGphdmEgcGFja2FnZSB0aGF0IHJ1bnMgc3VkbywgZ2V0cyB0aGUgdXNlciB0byBhdXRoZW50aWNh dGUsIGFuZCBpbnN0YWxscyBhIHRyYWRpdGlvbmFsIFZQTiBjbGllbnQgKG5vdCBleGFjdGx5IHRo ZSBraW5kIG9mIHRoaW5nIHlvdSB3YW50IHVzZXJzIHRvIGJlIHRyYWluZWQgdG8gYmUgYWNjZXB0 aW5nIG9mKS4gV2hldGhlciBvciBub3QgdGhhdCB0dW5uZWwgdXNlcyBTU0wsIElQc2VjLCBvciBy b3QxMyBpcyBkaWZmaWN1bHQgdG8gdGVsbC4gRW50ZXJwcmlzZXMgYXBwYXJlbnRseSBwcmVmZXIg dG8gZ2V0IHRoZWlyIGVtcGxveWVlcyB0byBpbnN0YWxsIG5ldHdvcmsgdHVubmVscyBmcm9tIHRo ZSBicm93c2VyIHRoYW4gdG8gZGlzdHJpYnV0ZSBzb2Z0d2FyZSBpbiBtb3JlIHRyYWRpdGlvbmFs IHdheXMuDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogZGF2aWQuYmxh Y2tAZW1jLmNvbSBbZGF2aWQuYmxhY2tAZW1jLmNvbTxtYWlsdG86ZGF2aWQuYmxhY2tAZW1jLmNv bT5dDQpTZW50OiBNb25kYXksIEp1bHkgMDIsIDIwMTIgMTI6MDcgUE0gTW91bnRhaW4gU3RhbmRh cmQgVGltZQ0KVG86IHRvdWNoQGlzaS5lZHUNCkNjOiBzYWFnQGlldGYub3JnDQpTdWJqZWN0OiBb c2FhZ10gU1NMIFZQTg0KDQoNCkpvZSBUb3VjaCB3cml0ZXM6DQoNCj4+Pj4gV2hhdCwgeW91J3Zl IG5ldmVyIGhlYXJkIG9mIGFuIFNTTCBWUE4/DQo+Pj4NCj4+PiBJJ3ZlIGFsc28gaGVhcmQgb2Yg dG9rZW4gcmluZywgYnV0IGJlc2lkZXMgdGhlIGdlZWsgY29tbXVuaXR5LCBpdCdzIG5vdCB1c2Vk DQo+Pj4gYWxsIHRoYXQgbXVjaC4gVGhlIGRvbWluYW50IFZQTnMgYXJlIElQc2VjIGFuZCBQUFRQ Lg0KPj4NCj4+IFllYWgsIHRoYXQncyB3aHkgYm90aCBDaXNjbyBhbmQgSnVuaXBlciBoYXZlIGJp ZyBTU0wgVlBOIHByb2R1Y3QgbGluZXMgYW5kDQo+PiB3aHkgQ2lzY28gQW55Q29ubmVjdCBub3cg c3VwcG9ydHMgRFRMUy4NCj4NCj4gIEZyb20gdGhlaXIgcGFnZXMsIHRoZXNlIGFwcGVhciB0byBi ZSBmb2N1c2VkIG9uIHN1cHBvcnQgZm9yIGVtYWlsIGFuZA0KPiB3ZWIgYWNjZXNzIHRvIFNTTC1i YXNlZCBzZXJ2aWNlcy4gRS5nLiwgZnJvbSBDaXNjbydzIHBhZ2U6DQo+DQo+IC0tLQ0KPiBTU0wg VlBOIE92ZXJ2aWV3DQo+DQo+IENpc2NvIElPUyBTU0wgVlBOIHByb3ZpZGVzIFNTTCBWUE4gcmVt b3RlLWFjY2VzcyBjb25uZWN0aXZpdHkgZnJvbQ0KPiBhbG1vc3QgYW55IEludGVybmV0LWVuYWJs ZWQgbG9jYXRpb24gdXNpbmcgb25seSBhIHdlYiBicm93c2VyIHRoYXQNCj4gbmF0aXZlbHkgc3Vw cG9ydHMgU1NMIGVuY3J5cHRpb24uIFRoaXMgZmVhdHVyZSBhbGxvd3MgeW91ciBjb21wYW55IHRv DQo+IGV4dGVuZCBhY2Nlc3MgdG8gaXRzIHNlY3VyZSBlbnRlcnByaXNlIG5ldHdvcmsgdG8gYW55 IGF1dGhvcml6ZWQgdXNlciBieQ0KPiBwcm92aWRpbmcgcmVtb3RlLWFjY2VzcyBjb25uZWN0aXZp dHkgdG8gY29ycG9yYXRlIHJlc291cmNlcyBmcm9tIGFueQ0KPiBJbnRlcm5ldC1lbmFibGVkIGxv Y2F0aW9uLg0KPiAtLS0NCj4NCj4gSS5lLiwgdGhhdCdzIHdlYiBicm93c2VyIGFjY2VzcyB0byBz ZXJ2aWNlcy4NCg0KVGhhdCdzIHdyb25nLCBzb3JyeS4gIEFuIFNTTCBWUE4gcHJvdmlkZXMgZnVs bCBJUCBuZXR3b3JrIGV4dGVuc2lvbiAtDQppdCdzIG1vc3QgZGVmaW5pdGVseSBub3QgYnJvd3Nl ci1vbmx5LiAgVGhlIHRlY2hub2xvZ3kgaXMgZWZmZWN0aXZlbHkgSVANCmVuY2Fwc3VsYXRpb24g aW4gVExTLCBub3QgY2xldmVyIHVzZSBvZiBUTFMgdG8gYWNjZXNzICJTU0wtYmFzZWQgc2Vydmlj ZXMuIg0KDQpFTUMgdXNlcyBBbnlDb25uZWN0IGZvciBzZWN1cmUgcmVtb3RlIGFjY2VzcywgYW5k IGl0IGVmZmVjdGl2ZWx5DQpyZXBsYWNlZCB1c2FnZSBvZiByZW1vdGUgYWNjZXNzIElQc2VjIFZQ TnMgZm9yIHRoZSBlbnRpcmUgY29tcGFueS4NCg0KVGhhbmtzLA0KLS1EYXZpZA0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRGF2aWQgTC4gQmxh Y2ssIERpc3Rpbmd1aXNoZWQgRW5naW5lZXINCkVNQyBDb3Jwb3JhdGlvbiwgMTc2IFNvdXRoIFN0 LiwgSG9wa2ludG9uLCBNQSAgMDE3NDgNCisxICg1MDgpIDI5My03OTUzICAgICAgICAgICAgIEZB WDogKzEgKDUwOCkgMjkzLTc3ODYNCmRhdmlkLmJsYWNrQGVtYy5jb20gICAgICAgIE1vYmlsZTog KzEgKDk3OCkgMzk0LTc3NTQNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCnNhYWcgbWFpbGluZyBsaXN0DQpzYWFnQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhYWcNCg== --_000_E894488ED5401F468DE846F92E9ABA1922968104ECSEXGPMB03winl_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPGh0bWw+ DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gMTQuMDIuMDI4My4wMDAiPg0KPHRpdGxlPltzYWFnXSBT U0wgVlBOPC90aXRsZT4NCjwvaGVhZD4NCjxib2R5Pg0KVGhlIG1hcmtldGluZyBhcm91bmQgU1NM IFZQTiBpcyBwcmV0dHkgYXRyb2Npb3VzIGluIG15IG9waW5pb24uLi4gTW9zdCBwcm9kdWN0cyBi YXNpY2FsbHkgcHJvdmlkZSBhbiBTU0wgcHJveHkgdG8gaW50ZXJuYWwgd2ViIHNlcnZlcnMgYW5k LCBvcHRpb25hbGx5LCBhICZxdW90O2Jyb3dzZXItYmFzZWQmcXVvdDsgcGx1Z2luIHRoYXQgaW5z dGFsbHMgYSBmdWxsIGtlcm5lbC1sZXZlbCBuZXR3b3JrIHR1bm5lbCBmb3IgeW91LiBPbiBMaW51 eCwgZm9yIGV4YW1wbGUsDQogb25lIG1ham9yIHZlbmRvciBwcm92aWRlcyBhIGphdmEgcGFja2Fn ZSB0aGF0IHJ1bnMgc3VkbywgZ2V0cyB0aGUgdXNlciB0byBhdXRoZW50aWNhdGUsIGFuZCBpbnN0 YWxscyBhIHRyYWRpdGlvbmFsIFZQTiBjbGllbnQgKG5vdCBleGFjdGx5IHRoZSBraW5kIG9mIHRo aW5nIHlvdSB3YW50IHVzZXJzIHRvIGJlIHRyYWluZWQgdG8gYmUgYWNjZXB0aW5nIG9mKS4gV2hl dGhlciBvciBub3QgdGhhdCB0dW5uZWwgdXNlcyBTU0wsIElQc2VjLCBvciByb3QxMw0KIGlzIGRp ZmZpY3VsdCB0byB0ZWxsLiBFbnRlcnByaXNlcyBhcHBhcmVudGx5IHByZWZlciB0byBnZXQgdGhl aXIgZW1wbG95ZWVzIHRvIGluc3RhbGwgbmV0d29yayB0dW5uZWxzIGZyb20gdGhlIGJyb3dzZXIg dGhhbiB0byBkaXN0cmlidXRlIHNvZnR3YXJlIGluIG1vcmUgdHJhZGl0aW9uYWwgd2F5cy48YnI+ DQo8YnI+DQo8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCjxiPkZy b206Jm5ic3A7PC9iPmRhdmlkLmJsYWNrQGVtYy5jb20gWzxhIGhyZWY9Im1haWx0bzpkYXZpZC5i bGFja0BlbWMuY29tIj5kYXZpZC5ibGFja0BlbWMuY29tPC9hPl08YnI+DQo8Yj5TZW50OiZuYnNw OzwvYj5Nb25kYXksIEp1bHkgMDIsIDIwMTIgMTI6MDcgUE0gTW91bnRhaW4gU3RhbmRhcmQgVGlt ZTxicj4NCjxiPlRvOiZuYnNwOzwvYj50b3VjaEBpc2kuZWR1PGJyPg0KPGI+Q2M6Jm5ic3A7PC9i PnNhYWdAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OiZuYnNwOzwvYj5bc2FhZ10gU1NMIFZQTjxi cj4NCjxicj4NCjwhLS0gQ29udmVydGVkIGZyb20gdGV4dC9wbGFpbiBmb3JtYXQgLS0+DQo8cD48 Zm9udCBzaXplPSIyIj5Kb2UgVG91Y2ggd3JpdGVzOjxicj4NCjxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsgV2hhdCwgeW91J3ZlIG5ldmVyIGhlYXJkIG9mIGFuIFNTTCBWUE4/PGJyPg0KJmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEkndmUgYWxzbyBoZWFyZCBvZiB0b2tlbiByaW5nLCBidXQg YmVzaWRlcyB0aGUgZ2VlayBjb21tdW5pdHksIGl0J3Mgbm90IHVzZWQ8YnI+DQomZ3Q7Jmd0OyZn dDsgYWxsIHRoYXQgbXVjaC4gVGhlIGRvbWluYW50IFZQTnMgYXJlIElQc2VjIGFuZCBQUFRQLjxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgWWVhaCwgdGhhdCdzIHdoeSBib3RoIENpc2NvIGFu ZCBKdW5pcGVyIGhhdmUgYmlnIFNTTCBWUE4gcHJvZHVjdCBsaW5lcyBhbmQ8YnI+DQomZ3Q7Jmd0 OyB3aHkgQ2lzY28gQW55Q29ubmVjdCBub3cgc3VwcG9ydHMgRFRMUy48YnI+DQomZ3Q7PGJyPg0K Jmd0OyZuYnNwOyBGcm9tIHRoZWlyIHBhZ2VzLCB0aGVzZSBhcHBlYXIgdG8gYmUgZm9jdXNlZCBv biBzdXBwb3J0IGZvciBlbWFpbCBhbmQ8YnI+DQomZ3Q7IHdlYiBhY2Nlc3MgdG8gU1NMLWJhc2Vk IHNlcnZpY2VzLiBFLmcuLCBmcm9tIENpc2NvJ3MgcGFnZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyAt LS08YnI+DQomZ3Q7IFNTTCBWUE4gT3ZlcnZpZXc8YnI+DQomZ3Q7PGJyPg0KJmd0OyBDaXNjbyBJ T1MgU1NMIFZQTiBwcm92aWRlcyBTU0wgVlBOIHJlbW90ZS1hY2Nlc3MgY29ubmVjdGl2aXR5IGZy b208YnI+DQomZ3Q7IGFsbW9zdCBhbnkgSW50ZXJuZXQtZW5hYmxlZCBsb2NhdGlvbiB1c2luZyBv bmx5IGEgd2ViIGJyb3dzZXIgdGhhdDxicj4NCiZndDsgbmF0aXZlbHkgc3VwcG9ydHMgU1NMIGVu Y3J5cHRpb24uIFRoaXMgZmVhdHVyZSBhbGxvd3MgeW91ciBjb21wYW55IHRvPGJyPg0KJmd0OyBl eHRlbmQgYWNjZXNzIHRvIGl0cyBzZWN1cmUgZW50ZXJwcmlzZSBuZXR3b3JrIHRvIGFueSBhdXRo b3JpemVkIHVzZXIgYnk8YnI+DQomZ3Q7IHByb3ZpZGluZyByZW1vdGUtYWNjZXNzIGNvbm5lY3Rp dml0eSB0byBjb3Jwb3JhdGUgcmVzb3VyY2VzIGZyb20gYW55PGJyPg0KJmd0OyBJbnRlcm5ldC1l bmFibGVkIGxvY2F0aW9uLjxicj4NCiZndDsgLS0tPGJyPg0KJmd0Ozxicj4NCiZndDsgSS5lLiwg dGhhdCdzIHdlYiBicm93c2VyIGFjY2VzcyB0byBzZXJ2aWNlcy48YnI+DQo8YnI+DQpUaGF0J3Mg d3JvbmcsIHNvcnJ5LiZuYnNwOyBBbiBTU0wgVlBOIHByb3ZpZGVzIGZ1bGwgSVAgbmV0d29yayBl eHRlbnNpb24gLTxicj4NCml0J3MgbW9zdCBkZWZpbml0ZWx5IG5vdCBicm93c2VyLW9ubHkuJm5i c3A7IFRoZSB0ZWNobm9sb2d5IGlzIGVmZmVjdGl2ZWx5IElQPGJyPg0KZW5jYXBzdWxhdGlvbiBp biBUTFMsIG5vdCBjbGV2ZXIgdXNlIG9mIFRMUyB0byBhY2Nlc3MgJnF1b3Q7U1NMLWJhc2VkIHNl cnZpY2VzLiZxdW90Ozxicj4NCjxicj4NCkVNQyB1c2VzIEFueUNvbm5lY3QgZm9yIHNlY3VyZSBy ZW1vdGUgYWNjZXNzLCBhbmQgaXQgZWZmZWN0aXZlbHk8YnI+DQpyZXBsYWNlZCB1c2FnZSBvZiBy ZW1vdGUgYWNjZXNzIElQc2VjIFZQTnMgZm9yIHRoZSBlbnRpcmUgY29tcGFueS48YnI+DQo8YnI+ DQpUaGFua3MsPGJyPg0KLS1EYXZpZDxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpEYXZpZCBMLiBCbGFjaywgRGlzdGluZ3Vpc2hl ZCBFbmdpbmVlcjxicj4NCkVNQyBDb3Jwb3JhdGlvbiwgMTc2IFNvdXRoIFN0LiwgSG9wa2ludG9u LCBNQSZuYnNwOyAwMTc0ODxicj4NCiYjNDM7MSAoNTA4KSAyOTMtNzk1MyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBGQVg6ICYjNDM7MSAoNTA4KSAyOTMtNzc4Njxicj4NCmRhdmlkLmJsYWNrQGVtYy5jb20mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTW9iaWxlOiAmIzQzOzEgKDk3 OCkgMzk0LTc3NTQ8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpzYWFnIG1haWxpbmcgbGlzdDxicj4NCnNhYWdAaWV0Zi5vcmc8 YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhYWci Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FhZzwvYT48YnI+DQo8L2Zv bnQ+PC9wPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E894488ED5401F468DE846F92E9ABA1922968104ECSEXGPMB03winl_-- From hannes.tschofenig@gmx.net Mon Jul 2 23: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 2E3FB21F86D6 for ; Mon, 2 Jul 2012 23:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2la3NQDqhsOw for ; Mon, 2 Jul 2012 23:01:30 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 227B021F8715 for ; Mon, 2 Jul 2012 23:01:29 -0700 (PDT) Received: (qmail invoked by alias); 03 Jul 2012 06:01:35 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.110]) [88.115.216.191] by mail.gmx.net (mp027) with SMTP; 03 Jul 2012 08:01:35 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+nrlJ06oSniglAXO18s6SsqFE2JDY3uZFAt3vP5K ww9I2orUciRer1 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71208D3AB53@MX15A.corp.emc.com> Date: Tue, 3 Jul 2012 09:01:33 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7CACF142-6779-4321-918A-8A0452F73D6C@gmx.net> References: <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> <4FEE41BB.3050705@deployingradius.com> <4FF1D139.5050601@isi.edu> <4FF1D5BE.7070907@isi.edu> <4FF1DBB2.5090407@isi.edu> <8D3D17 ACE214DC429325B2B98F3AE71208D3AB53@MX15A.corp.emc.com> To: X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: saag@ietf.org Subject: Re: [saag] SSL VPN 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, 03 Jul 2012 06:01:31 -0000 A minor remark: The reason why email and Web access is explicitly = mentioned because that's what people use when they access their company = services (and any other service on the Internet as well).=20 =20 Of course the SSL / TLS based VPNs could carry other protocols on top of = it.=20 I am not sure why you say it isn't a clever use of TLS to access = "SSL-based services. On Jul 2, 2012, at 9:06 PM, wrote: > Joe Touch writes: >=20 >>>>> What, you've never heard of an SSL VPN? >>>>=20 >>>> I've also heard of token ring, but besides the geek community, it's = not used >>>> all that much. The dominant VPNs are IPsec and PPTP. >>>=20 >>> Yeah, that's why both Cisco and Juniper have big SSL VPN product = lines and >>> why Cisco AnyConnect now supports DTLS. >>=20 >> =46rom their pages, these appear to be focused on support for email = and >> web access to SSL-based services. E.g., from Cisco's page: >>=20 >> --- >> SSL VPN Overview >>=20 >> Cisco IOS SSL VPN provides SSL VPN remote-access connectivity from >> almost any Internet-enabled location using only a web browser that >> natively supports SSL encryption. This feature allows your company to >> extend access to its secure enterprise network to any authorized user = by >> providing remote-access connectivity to corporate resources from any >> Internet-enabled location. >> --- >>=20 >> I.e., that's web browser access to services. >=20 > That's wrong, sorry. An SSL VPN provides full IP network extension - > it's most definitely not browser-only. The technology is effectively = IP > encapsulation in TLS, not clever use of TLS to access "SSL-based = services." >=20 > EMC uses AnyConnect for secure remote access, and it effectively > replaced usage of remote access IPsec VPNs for the entire company. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > david.black@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From Hannes.Tschofenig@gmx.net Mon Jul 2 23:26: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 7512411E813E for ; Mon, 2 Jul 2012 23:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSy39uJ2vLAJ for ; Mon, 2 Jul 2012 23:26:22 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 5044D11E8134 for ; Mon, 2 Jul 2012 23:26:21 -0700 (PDT) Received: (qmail invoked by alias); 03 Jul 2012 06:26:28 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.110]) [88.115.216.191] by mail.gmx.net (mp010) with SMTP; 03 Jul 2012 08:26:28 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/168sMgxD157F70Z1MZWyqMe/Q7kueRfbv4S8QT2 Zm2ShvnobVcO/8 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <041792A1-26A0-4607-AF2C-4273D415BCD5@cisco.com> Date: Tue, 3 Jul 2012 09:26:25 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6F024C7F-39FE-4B1B-85CF-AF40E9A2BF65@gmx.net> References: <15FC0C46-8C18-4C77-87BF-470BFC964187@gmx.net> <041792A1-26A0-4607-AF2C-4273D415BCD5@cisco.com> To: David McGrew X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: saag@ietf.org Subject: Re: [saag] Error Handling & Security 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, 03 Jul 2012 06:26:23 -0000 Hi David,=20 On Jun 19, 2012, at 11:08 PM, David McGrew wrote: > Hi Hannes, >=20 > On Jun 19, 2012, at 3:33 PM, Hannes Tschofenig wrote: >=20 >> I guess I need to provide a bit of additional background for my = question.=20 >>=20 >> In the OAuth working group folks are currently arguing that they do = not want to provide more detailed error responses in protocol exchanges = or in some cases no error message at all (even an error happened) -- = essentially being silent.=20 >>=20 >> The argument that this is good for security but while I agree that = one needs to be careful about the information that is being provided = back to the client in case of an error I still see value in providing = more detailed error response.=20 >>=20 >> As such, this is a bit unrelated to the question of what debug level = is currently enabled at the client software or what specifically is = shown to the user.=20 >>=20 >> Without any information from the server (in case of an error) the = client software can obviously only guess what happens.=20 >>=20 >=20 > this is an interesting question. As I am sure that you already know, = crypto should be "atomic", that is, the error messages returned from = cryptographic operations should not give details about what went wrong = in the crypto processing (such as padding errors, decoding errors, and = the like). What is less clear are the other error messages that would = give out information such as which security options are actually in = effect. Are the (potential) error messages listed/documented somewhere? >=20 The document I was specially referring to was an OAuth assertion draft:=20= http://tools.ietf.org/html/draft-ietf-oauth-assertions-04 It re-uses error from the base OAuth specification but does not define = new error codes. I suggested to the authors that they should define = additional error codes that are specific to the assertion processing = (since many things can go wrong with the processing of the content of = the assertion). Here was my review: http://www.ietf.org/mail-archive/web/oauth/current/msg09086.html Ciao Hannes > David >=20 >> Ciao >> Hannes >>=20 >>=20 >> On Jun 18, 2012, at 3:20 PM, Peter Gutmann wrote: >>=20 >>> Hannes Tschofenig writes: >>>=20 >>>> Experience or views from others? >>>=20 >>> I've been recommending that you make it a debug option that has to = be >>> explicitly enabled, that adds extra noise to the protocol (e.g. an = SSH banner) >>> to make it obvious that it's enabled, and that turns itself off = again after a >>> set time or number of protocol runs. >>>=20 >>> Peter. >>=20 >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >=20 From hannes.tschofenig@gmx.net Mon Jul 2 23:28: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 57BE611E8146 for ; Mon, 2 Jul 2012 23:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EsyZd0qagOP for ; Mon, 2 Jul 2012 23:28:36 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 2FA0E11E8141 for ; Mon, 2 Jul 2012 23:28:36 -0700 (PDT) Received: (qmail invoked by alias); 03 Jul 2012 06:28:42 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.110]) [88.115.216.191] by mail.gmx.net (mp027) with SMTP; 03 Jul 2012 08:28:42 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/FXZBpQdfFKXmmY9cFuKfRHtkq6iJ52/FYA1gdQk HfIWS6gZbDpi6o Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4FE15444.2040100@gmail.com> Date: Tue, 3 Jul 2012 09:28:40 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <15FC0C46-8C18-4C77-87BF-470BFC964187@gmx.net> <4FE15444.2040100@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: saag@ietf.org Subject: Re: [saag] Error Handling & Security 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, 03 Jul 2012 06:28:37 -0000 Hi Yaron,=20 the destinction between end user presented error and errors that are = only shown to the developer certain makes a big difference.=20 In OAuth we decided that all errors in the protocol are only processed = by the developer. The developer then has to decide what, when and how to = show an error (and the error resolution mechanism) to the end user. I = don't think that any of the errors in OAuth will easily help end users = to resolve the issue given that multi-party protocols are typically to = understand (even for developers).=20 Ciao Hannes On Jun 20, 2012, at 7:40 AM, Yaron Sheffer wrote: > Hi Hannes, >=20 > One factor in this decision is the distinction between end-user errors = (these errors that would benefit the end user) vs. developer errors. The = trade-off between helpfulness and security should be different for the = two types. >=20 > For many protocols the only useful end-user error is "authentication = failed" (of course with better wording for the intended audience). In = some case "authorization failed" is also useful - you know then that you = need to ask your system administrator for additional permissions. >=20 > In the case of end-user errors my personal preference is for the most = informative response possible. For example: "3 more tries before we lock = you out of your account". >=20 > On the other hand, we can be more stingy with indications that are = only useful to a developer. Presumably the detailed errors are sent to = an internal log (maybe optionally, to prevent timing attacks and DoS). = And developers should have the option to approach the service owner = directly to resolve interoperability issues. >=20 > Thanks, > Yaron >=20 > On 06/19/2012 10:33 PM, Hannes Tschofenig wrote: >> I guess I need to provide a bit of additional background for my = question. >>=20 >> In the OAuth working group folks are currently arguing that they do = not want to provide more detailed error responses in protocol exchanges = or in some cases no error message at all (even an error happened) -- = essentially being silent. >>=20 >> The argument that this is good for security but while I agree that = one needs to be careful about the information that is being provided = back to the client in case of an error I still see value in providing = more detailed error response. >>=20 >> As such, this is a bit unrelated to the question of what debug level = is currently enabled at the client software or what specifically is = shown to the user. >>=20 >> Without any information from the server (in case of an error) the = client software can obviously only guess what happens. >>=20 >> Ciao >> Hannes >>=20 >>=20 >> On Jun 18, 2012, at 3:20 PM, Peter Gutmann wrote: >>=20 >>> Hannes Tschofenig writes: >>>=20 >>>> Experience or views from others? >>>=20 >>> I've been recommending that you make it a debug option that has to = be >>> explicitly enabled, that adds extra noise to the protocol (e.g. an = SSH banner) >>> to make it obvious that it's enabled, and that turns itself off = again after a >>> set time or number of protocol runs. >>>=20 >>> Peter. >>=20 >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag From hannes.tschofenig@gmx.net Mon Jul 2 23:34: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 17E6D11E813D for ; Mon, 2 Jul 2012 23:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tc2ciPxuVK2 for ; Mon, 2 Jul 2012 23:34:52 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id B01F721F862B for ; Mon, 2 Jul 2012 23:34:51 -0700 (PDT) Received: (qmail invoked by alias); 03 Jul 2012 06:34:57 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.110]) [88.115.216.191] by mail.gmx.net (mp012) with SMTP; 03 Jul 2012 08:34:57 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/1HWEBZET1YY6DGlbOvxJcO0+teD5aXxXbKFJu8D WhkcLWKVVLA0Jc Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Tue, 3 Jul 2012 09:34:55 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <13002C3E-6EC1-4898-8EAA-808541E81649@gmx.net> References: To: "Fisk, Mike" X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "'saag@ietf.org'" Subject: Re: [saag] SSL VPN 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, 03 Jul 2012 06:34:53 -0000 The issue is that VPN vendors want to provide software to customers that = actually work. There are networks out there (and I wish I had data to cite; maybe = someone else has) that provide fairly excessing filtering policies and = hence a plain IETF IKEv2/IPsec based VPN wouldn't get through the = firewalls.=20 Then, you have two choices:=20 1) change the transport mechanisms for IKEv2/IPsec (running it over TCP) 2) switch to TLS Since the IKEv2 exchange is pretty similar to the TLS handshake most = people may not have strong preferences between the two. Over the years = we had copied the features between TLS and IKEv2 back and forth. =20 Ciao Hannes On Jul 2, 2012, at 10:28 PM, Fisk, Mike wrote: > The marketing around SSL VPN is pretty atrocious in my opinion... Most = products basically provide an SSL proxy to internal web servers and, = optionally, a "browser-based" plugin that installs a full kernel-level = network tunnel for you. On Linux, for example, one major vendor provides = a java package that runs sudo, gets the user to authenticate, and = installs a traditional VPN client (not exactly the kind of thing you = want users to be trained to be accepting of). Whether or not that tunnel = uses SSL, IPsec, or rot13 is difficult to tell. Enterprises apparently = prefer to get their employees to install network tunnels from the = browser than to distribute software in more traditional ways. >=20 >=20 >=20 > -----Original Message----- > From: david.black@emc.com [david.black@emc.com] > Sent: Monday, July 02, 2012 12:07 PM Mountain Standard Time > To: touch@isi.edu > Cc: saag@ietf.org > Subject: [saag] SSL VPN >=20 > Joe Touch writes: >=20 > >>>> What, you've never heard of an SSL VPN? > >>> > >>> I've also heard of token ring, but besides the geek community, = it's not used > >>> all that much. The dominant VPNs are IPsec and PPTP. > >> > >> Yeah, that's why both Cisco and Juniper have big SSL VPN product = lines and > >> why Cisco AnyConnect now supports DTLS. > > > > =46rom their pages, these appear to be focused on support for email = and > > web access to SSL-based services. E.g., from Cisco's page: > > > > --- > > SSL VPN Overview > > > > Cisco IOS SSL VPN provides SSL VPN remote-access connectivity from > > almost any Internet-enabled location using only a web browser that > > natively supports SSL encryption. This feature allows your company = to > > extend access to its secure enterprise network to any authorized = user by > > providing remote-access connectivity to corporate resources from any > > Internet-enabled location. > > --- > > > > I.e., that's web browser access to services. >=20 > That's wrong, sorry. An SSL VPN provides full IP network extension - > it's most definitely not browser-only. The technology is effectively = IP > encapsulation in TLS, not clever use of TLS to access "SSL-based = services." >=20 > EMC uses AnyConnect for secure remote access, and it effectively > replaced usage of remote access IPsec VPNs for the entire company. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > david.black@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From david.black@emc.com Tue Jul 3 07:03: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 BD6F921F85D2 for ; Tue, 3 Jul 2012 07:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nB41Fuf6e+qZ for ; Tue, 3 Jul 2012 07:03:53 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id B356921F85C2 for ; Tue, 3 Jul 2012 07:03:53 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q63E3wYP014245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jul 2012 10:03:58 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Tue, 3 Jul 2012 10:03:42 -0400 Received: from mxhub22.corp.emc.com (mxhub22.corp.emc.com [128.222.70.134]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q63E3fng031948; Tue, 3 Jul 2012 10:03:41 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub22.corp.emc.com ([128.222.70.134]) with mapi; Tue, 3 Jul 2012 10:03:41 -0400 From: To: Date: Tue, 3 Jul 2012 10:03:40 -0400 Thread-Topic: [saag] SSL VPN Thread-Index: Ac1Y4VsLJ3QXOJF/TpiU51LZveT+CgAQlyvA Message-ID: <8D3D17ACE214DC429325B2B98F3AE71208D3AC46@MX15A.corp.emc.com> References: <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> <4FEE41BB.3050705@deployingradius.com> <4FF1D139.5050601@isi.edu> <4FF1D5BE.7070907@isi.edu> <4FF1DBB2.5090407@isi.edu> <8D3D17ACE214DC429325B2B98F3AE71208D3AB53@MX15A.corp.emc.com> <7CACF142-6779-4321-918A-8A0452F73D6C@gmx.net> In-Reply-To: <7CACF142-6779-4321-918A-8A0452F73D6C@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: saag@ietf.org Subject: Re: [saag] SSL VPN 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, 03 Jul 2012 14:03:55 -0000 Hi Hannes, > A minor remark: The reason why email and Web access is explicitly mention= ed > because that's what people use when they access their company services (a= nd > any other service on the Internet as well). >=20 > Of course the SSL / TLS based VPNs could carry other protocols on top of = it. And they do ... > I am not sure why you say it isn't a clever use of TLS to access "SSL-bas= ed > services." This is because the TLS is in the VPN, not the accessed services. Obviousl= y, HTTPS and the like use a second encapsulated instance of TLS, but the prima= ry TLS is in the SSL VPN, and it doesn't extend to the service. Specifically, the TLS server cert presented by the SSL VPN (at least AnyConnect) is an SS= L VPN cert, not a cert from the accessed service - to get the latter requires= an instance of TLS that goes all the way to the service, not just to the SSL V= PN gateway (ok, that was obvious ...). Hence one can run traffic over an SSL = VPN that is unencrypted on the far side (enterprise network) of the SSL VPN gat= eway. Thanks, --David > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Tuesday, July 03, 2012 2:02 AM > To: Black, David > Cc: Hannes Tschofenig; touch@isi.edu; saag@ietf.org > Subject: Re: [saag] SSL VPN >=20 > A minor remark: The reason why email and Web access is explicitly mention= ed > because that's what people use when they access their company services (a= nd > any other service on the Internet as well). >=20 > Of course the SSL / TLS based VPNs could carry other protocols on top of = it. >=20 > I am not sure why you say it isn't a clever use of TLS to access "SSL-bas= ed > services. >=20 > On Jul 2, 2012, at 9:06 PM, wrote: >=20 > > Joe Touch writes: > > > >>>>> What, you've never heard of an SSL VPN? > >>>> > >>>> I've also heard of token ring, but besides the geek community, it's = not > used > >>>> all that much. The dominant VPNs are IPsec and PPTP. > >>> > >>> Yeah, that's why both Cisco and Juniper have big SSL VPN product line= s and > >>> why Cisco AnyConnect now supports DTLS. > >> > >> From their pages, these appear to be focused on support for email and > >> web access to SSL-based services. E.g., from Cisco's page: > >> > >> --- > >> SSL VPN Overview > >> > >> Cisco IOS SSL VPN provides SSL VPN remote-access connectivity from > >> almost any Internet-enabled location using only a web browser that > >> natively supports SSL encryption. This feature allows your company to > >> extend access to its secure enterprise network to any authorized user = by > >> providing remote-access connectivity to corporate resources from any > >> Internet-enabled location. > >> --- > >> > >> I.e., that's web browser access to services. > > > > That's wrong, sorry. An SSL VPN provides full IP network extension - > > it's most definitely not browser-only. The technology is effectively I= P > > encapsulation in TLS, not clever use of TLS to access "SSL-based servic= es." > > > > EMC uses AnyConnect for secure remote access, and it effectively > > replaced usage of remote access IPsec VPNs for the entire company. > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Distinguished Engineer > > EMC Corporation, 176 South St., Hopkinton, MA 01748 > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > david.black@emc.com Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > > > _______________________________________________ > > saag mailing list > > saag@ietf.org > > https://www.ietf.org/mailman/listinfo/saag >=20 From stephen.farrell@cs.tcd.ie Thu Jul 5 08:06: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 3FC7E21F8716 for ; Thu, 5 Jul 2012 08:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UO7b+kICSkRf for ; Thu, 5 Jul 2012 08:06:15 -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 695B321F865D for ; Thu, 5 Jul 2012 08:06:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id CB5E31715B2 for ; Thu, 5 Jul 2012 16:06:26 +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=1341500785; bh=rtcpcJan1zFy9b sgGc1uwVJ1BKXpYoTgTxNy+nDW4FU=; b=IMnNg+TWva9ZbxFAzG+rcWRt+rTMJR +M6wB1BBSBPJmFSFk67jLj/9hFtm8k6Yxju2dvjac1EF3NllQszADLjDq9x5QwC0 ioHVqZ/5KxmBdbe95E/re+4DiEozyL38B3SJivcSdXD9VOxyEmoCUGCSZiD6SS2k vSDrtf5BnS5a1WZr3vdFBZ5B4AoPXevTcpsqxj4/rZrgnj7oZGwSsHm88a31v4gx fDznosJYOkK+y10csWPTQrfKoCz886snz0SMn7hPqUuXi8OBLtwlAfXYMBwCOh3C Bn/pt/w3B4cUx0D920GvGZIo1evjJkqTPIqUbcfNClleOv56weBK9dwA== 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 paxy+z-fW8SD; Thu, 5 Jul 2012 16:06:25 +0100 (IST) Received: from [10.87.48.11] (unknown [86.41.13.125]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 397BB17151C; Thu, 5 Jul 2012 16:06:25 +0100 (IST) Message-ID: <4FF5AD71.30900@cs.tcd.ie> Date: Thu, 05 Jul 2012 16:06:25 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Stephen Farrell References: <20120619153312.13442.75785.idtracker@ietfa.amsl.com> <4FE30CAC.6060401@cs.tcd.ie> <4FE8D7B3.3000308@cs.tcd.ie> <4FEB2443.5010909@cs.tcd.ie> <4FF1C96A.4060507@cs.tcd.ie> In-Reply-To: <4FF1C96A.4060507@cs.tcd.ie> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "saag@ietf.org" Subject: Re: [saag] Stephen Farrell's Discuss on draft-ietf-trill-rbridge-channel-06: (with DISCUSS and COMMENT) 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, 05 Jul 2012 15:06:16 -0000 So if this doesn't push anyone's buttons by the end of the week then I'll just clear the discuss, Ta, S. On 07/02/2012 05:16 PM, Stephen Farrell wrote: > > Hi all, > > I have a discuss [1] on a TRILL draft [2] that defines a way > to channel other protocols via RBridges. > > In discussing that with Don, he nicely summarised the core issue > as follows: > > On 07/01/2012 06:22 PM, Donald Eastlake wrote: >> it seems to me >> that what all this boils down to is that the Security Area has to >> decide that either (1) with improved wording an RBridge Channel level >> mandatory to implement, optional to use, security feature is not >> necessary for approval of this draft or (2) such a feature is >> necessary for approval of the draft and the TRILL WG needs to go come >> up with one. > > TRILL isn't something I know much about, so I'd welcome input > (on or off list) as to what's reasonable here. > > Note that there will be a statement that any other protocol > defined to run over this channel MUST define its own security > mechanisms. > > Thanks, > Stephen. > > [1] > https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-channel/ballot/ > [2] http://tools.ietf.org/html/draft-ietf-trill-rbridge-channel > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > From paul.hoffman@vpnc.org Sun Jul 8 16:52: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 62FD721F87B2 for ; Sun, 8 Jul 2012 16:52:23 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsRbC8cqC9dc for ; Sun, 8 Jul 2012 16:52:22 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE2321F87B3 for ; Sun, 8 Jul 2012 16:52:22 -0700 (PDT) Received: from [10.20.30.102] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q68NqgmP029203 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 8 Jul 2012 16:52:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 8 Jul 2012 16:52:41 -0700 Message-Id: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> To: IETF Security Area Advisory Group Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [saag] The quest to replace passwords 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, 08 Jul 2012 23:52:23 -0000 Greetings again. A few times on this list, people have spoken of the = need to replace passwords with an unstated assumption that if we just = work hard enough, we'll have a good solution. Another unstated = assumption is that we know how to measure what a good replacement is. A = recent excellent academic paper, referenced at = , may make us (well, the less single-minded among us) a tad less = confident in both of those assumptions. This work is certainly relevant = in a few IETF WGs as well as SAAG in general. --Paul Hoffman From stephen.farrell@cs.tcd.ie Sun Jul 8 17:21:46 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 E7B5F21F877A for ; Sun, 8 Jul 2012 17:21:46 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCQlxIkvSZ6P for ; Sun, 8 Jul 2012 17:21:45 -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 B66C821F876A for ; Sun, 8 Jul 2012 17:21:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id C806C171838; Mon, 9 Jul 2012 01:22:05 +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=1341793325; bh=roGfK60WURC+EK qao6rYb/FtIvBpA90HQoRMkieiSJA=; b=vYZjPsnCPvRckLJBaTd9mCs+XG1Nkf z6oH7fP1+PkAm2VyeU47OhhjPJWKLXvrVZzuxmxCapyvM4pAxdM4VAGF5GzAyP+t GgeQNL27ceYybedvt1MlzCOcxGlKy2Au2ZF+bOKekvarn+5+idNrK8BJJavlHigK llpfuvjJ2Uh5FgFY+CpEJ9Bx2yFYLdiV8RSTnQe34eWeqlmzb0V4nClZ6V9eLGPh 7IrTXqa2qd/ykZ4dXz2hQ8SNCpHQS7NE6pUWMyj3bbcEkOmi+gdwAlAck8RiaqWB GZm8aC++1CKCWkmP+tk52/oF4Ab6J9ot0+6BoYS1IzrK9R9bMpCP+4gw== 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 vbP9w-Jp+9VE; Mon, 9 Jul 2012 01:22:05 +0100 (IST) Received: from [10.87.48.11] (unknown [86.44.73.65]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id EAA941714ED; Mon, 9 Jul 2012 01:22:04 +0100 (IST) Message-ID: <4FFA242C.8000402@cs.tcd.ie> Date: Mon, 09 Jul 2012 01:22:04 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Paul Hoffman References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> In-Reply-To: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 09 Jul 2012 00:21:47 -0000 I agree with their opening (*) and with thinking more, and seriously, about this topic. (*) "The continued domination of passwords over all other methods of end-user authentication is a major embarrassment..." I entirely disagree that we ought give up, if that's the conclusion someone might draw. If we wanted to solve this, we could, IMO. SSH and PGP are perfectly good protocol models, and usability has to be easier than installing linux, which seems to have been doable for a few million folks. S. PS: Full disclosure - I got frustrated that nobody else did it, so I wrote up a scheme for http/2.0 aiming specifically at tackling this issue. [1] IMO, it could work, if the browser folks actually felt the embarrassment mentioned above. I hope they do. (And don't care if this or some other scheme is the non-password one that gets adopted.) [1] http://tools.ietf.org/html/draft-farrell-httpbis-hoba On 07/09/2012 12:52 AM, Paul Hoffman wrote: > Greetings again. A few times on this list, people have spoken of the need to replace passwords with an unstated assumption that if we just work hard enough, we'll have a good solution. Another unstated assumption is that we know how to measure what a good replacement is. A recent excellent academic paper, referenced at , may make us (well, the less single-minded among us) a tad less confident in both of those assumptions. This work is certainly relevant in a few IETF WGs as well as SAAG in general. > > --Paul Hoffman > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From yaronf.ietf@gmail.com Sun Jul 8 23:29: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 BCC5C21F8666 for ; Sun, 8 Jul 2012 23:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMbUJ8INVVIG for ; Sun, 8 Jul 2012 23:29:40 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 06EE621F8649 for ; Sun, 8 Jul 2012 23:29:35 -0700 (PDT) Received: by eaaq13 with SMTP id q13so4361225eaa.31 for ; Sun, 08 Jul 2012 23:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=mhJQukHhwj14bsXL2tzvVlZDHWM9jNCeFAbwNA7fKdE=; b=mpYwxCrondub+VVOIxMkg2+RlrWLP8FSngZ+NDeNjd06XteH7ib78QWTHDFUVVNA70 u0KAYSHinJZjNWgy5Eg7RWGFdTY1y+7CvbMucpISeR5Uq1SKgLV54sg0Yqi4/K914d3N 8cOp4iYxXPXJUs166+iJVKbQW1QDTspMvcwzPz2IVA+3wWiq8FHupONJ0/Kamg46jhqt yLwn23z8ieLI56LlD+RGsI9E6TxcoWURMY6zlZKgCV2O7NLsLNUrIed0HXiX343wbMa3 X/H9YWs6HXZanEKQBWoWY1W/5Q+wuz3Dor3wLptHaa7TbFJZnwpPsaronrzFQ+5Y8+6k rpxA== Received: by 10.14.22.15 with SMTP id s15mr8744522ees.88.1341815399301; Sun, 08 Jul 2012 23:29:59 -0700 (PDT) Received: from [192.168.1.107] (192.117.25.34.static.012.net.il. [192.117.25.34]) by mx.google.com with ESMTPS id h53sm90918991eea.1.2012.07.08.23.29.57 (version=SSLv3 cipher=OTHER); Sun, 08 Jul 2012 23:29:58 -0700 (PDT) Message-ID: <4FFA7A5A.70008@gmail.com> Date: Mon, 09 Jul 2012 09:29:46 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Stephen Farrell References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> <4FFA242C.8000402@cs.tcd.ie> In-Reply-To: <4FFA242C.8000402@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 09 Jul 2012 06:29:41 -0000 Passwords are not "the enemy". More like a wild animal that we, as a community, need to tame. This paper presents a very important classification. Unlike Stephen, I think that moving forward we should not aim to drop passwords altogether. Rather, we should combine the usability benefits of passwords (primarily the fact that a password can be used from anywhere, with no need for credentials to live on a device) with one or more of the password "replacement" technologies. For example, a master password can be used to unlock a public-key store. We can reduce the usage of passwords significantly, thereby reducing the associated risk. We can also use under-utilized technologies to improve the remaining uses of passwords. These include password-based authentication protocols (EKE and the like), and amplification of passwords into long-term cryptographic secrets, when appropriate (http://tools.ietf.org/html/rfc6631#section-3.5). Thanks, Yaron On 07/09/2012 03:22 AM, Stephen Farrell wrote: > > I agree with their opening (*) and with thinking more, > and seriously, about this topic. > > (*) "The continued domination of passwords over all > other methods of end-user authentication is a > major embarrassment..." > > I entirely disagree that we ought give up, if that's the > conclusion someone might draw. > > If we wanted to solve this, we could, IMO. SSH and PGP are > perfectly good protocol models, and usability has to be > easier than installing linux, which seems to have been > doable for a few million folks. > > S. > > PS: Full disclosure - I got frustrated that nobody else did > it, so I wrote up a scheme for http/2.0 aiming specifically > at tackling this issue. [1] IMO, it could work, if the > browser folks actually felt the embarrassment mentioned > above. I hope they do. (And don't care if this or some other > scheme is the non-password one that gets adopted.) > > [1] http://tools.ietf.org/html/draft-farrell-httpbis-hoba > > On 07/09/2012 12:52 AM, Paul Hoffman wrote: >> Greetings again. A few times on this list, people have spoken of the need to replace passwords with an unstated assumption that if we just work hard enough, we'll have a good solution. Another unstated assumption is that we know how to measure what a good replacement is. A recent excellent academic paper, referenced at , may make us (well, the less single-minded among us) a tad less confident in both of those assumptions. This work is certainly relevant in a few IETF WGs as well as SAAG in general. >> >> --Paul Hoffman >> >> _______________________________________________ >> 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 nico@cryptonector.com Mon Jul 9 00:01: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 23DE111E8085 for ; Mon, 9 Jul 2012 00:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=-1.883, BAYES_05=-1.11, 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 UICFKZSO5cyo for ; Mon, 9 Jul 2012 00:01:14 -0700 (PDT) Received: from homiemail-a98.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id B82B611E8083 for ; Mon, 9 Jul 2012 00:01:14 -0700 (PDT) Received: from homiemail-a98.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTP id BB5132C207C for ; Mon, 9 Jul 2012 00:01:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=mY+x/teurMfhtcjo1NYal 5CAuM6x12gxPnMXlFQDHx1UMuNfDtmfHgBK/pqaSocLzUXTUZAS8tkrt4rkevIR7 OFRDK20o29YIyExS/6aJ3lBXl8wpXSyiF1jcL2V8RpxeFsdTkE2Z/fvFdjPDfi/R 6/oUvoMvR9B4e6zYPaPdW8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=q9soRicXZihpkDBczGH1 fmOTQ3M=; b=A3KWnXM99mGDGWAFeSYlIioKHcCiWe/7IFNUU0yKTPsJlelEaLUI jW5bC06gB5qTzfZHbgXb1U53dWz0ewNTNFP6isqp/0B2C2odnOW+SFPEknN5nT8E JgFyBCC4aWpDgaDL4/xdaeIDVN5Jntr6EccDuja2e74V57P0Kg9wwQY= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTPSA id 9E2C82C2060 for ; Mon, 9 Jul 2012 00:01:38 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so19302283pbc.31 for ; Mon, 09 Jul 2012 00:01:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.220.39 with SMTP id pt7mr58656550pbc.40.1341817298238; Mon, 09 Jul 2012 00:01:38 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Mon, 9 Jul 2012 00:01:38 -0700 (PDT) In-Reply-To: <4FFA7A5A.70008@gmail.com> References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> <4FFA242C.8000402@cs.tcd.ie> <4FFA7A5A.70008@gmail.com> Date: Mon, 9 Jul 2012 02:01:38 -0500 Message-ID: From: Nico Williams To: Yaron Sheffer Content-Type: text/plain; charset=UTF-8 Cc: IETF Security Area Advisory Group , Paul Hoffman Subject: Re: [saag] The quest to replace passwords 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, 09 Jul 2012 07:01:15 -0000 On Mon, Jul 9, 2012 at 1:29 AM, Yaron Sheffer wrote: > Passwords are not "the enemy". More like a wild animal that we, as a > community, need to tame. I think we'll end up with more than one standard replacement for the current web authentication mess. Passwords will continue to have a place. I like HOBA, and to the extent that soon enough everyone everywhere will have a smartphone (or more, + tablets) it certainly has a place. I just don't think it will be the only solution we end up with. E.g., for as long as the desktop remains king of the corporate world we'll need something else, and probably even after BYOD triumphs -- if it does. Even if everyone carries smartphones we'll still need failsafe account recovery systems, and those are likely to continue to be... password based (only it will be worse when users rarely type in passwords, since they'll then rarely practice their recall). > This paper presents a very important classification. [...] I think classification is really the first step towards choosing from among proposals, and perhaps even for choosing techniques on which to base proposals. Nico -- From lear@cisco.com Mon Jul 9 01:40: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 5C20E21F8570 for ; Mon, 9 Jul 2012 01:40:54 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voXgsniKsCXz for ; Mon, 9 Jul 2012 01:40:53 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB0821F857A for ; Mon, 9 Jul 2012 01:40:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=377; q=dns/txt; s=iport; t=1341823278; x=1343032878; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=L3SCJjVrb4VVuu7PrKh3QnGxf41h7N5Aaxr5zUYLuUk=; b=D6J/Pf/PmY8AtSvZX16XrMxwY3Pviwd8Bns3j6LyySv5Y27r1d+oVo6Y iceet3uEITwLTJMaYOck4PPDGomh2bZLYcs3oIlxPkSyHax+M5Wb3MK3r d5Md/UwapoTv67chRVDcrcn3ScJplOfai/QlxfI9KF9cFldOxHX5S1GIG A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAHqY+k9Io8UY/2dsb2JhbABFhWazCIIhAQEEEgEQVQEQCxoCBRYLAgIJAwIBAgFFBg0BBwEBEA6Ha5sIjRmRfoEgjxqBEgOVNo4fgWaCYQ X-IronPort-AV: E=Sophos;i="4.77,551,1336348800"; d="scan'208";a="14854576" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 09 Jul 2012 08:41:12 +0000 Received: from ams3-vpn-dhcp1218.cisco.com (ams3-vpn-dhcp1218.cisco.com [10.61.68.194]) by bgl-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q698f9C3027950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jul 2012 14:11:11 +0530 Message-ID: <4FFA9925.9000407@cisco.com> Date: Mon, 09 Jul 2012 10:41:09 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Paul Hoffman References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> In-Reply-To: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 09 Jul 2012 08:40:54 -0000 Paul, I take away something quite different, that in fact the Internet technical community is doing the exactly right thing, by creating a toolbox to allow for a more nuanced evolution away from passwords. That table they provide shows also that there is likely to be a consolidation as things progress, but perhaps not before a few more methods are created! Eliot From stephen.farrell@cs.tcd.ie Mon Jul 9 02:27: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 4D02F21F8838 for ; Mon, 9 Jul 2012 02:27:44 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+ckpOiIFf+W for ; Mon, 9 Jul 2012 02:27:43 -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 07FF121F882B for ; Mon, 9 Jul 2012 02:27:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id C46D31714C4; Mon, 9 Jul 2012 10:28:03 +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=1341826082; bh=vK3oS3I0Vd/L2e VxAkCSQfRELLPHca3F4DilSRVMWVo=; b=N7OUqF+IyDPtU3wqiI8cZkv9A1Er5d /O9I5WacxUwwVCl0Ii/3j1MBqaGmGM0AWktp0mXS+35askWHUkQk6ZYC7afdkEI2 KYoFD1PdJrlkceoZNnJ81qwwpnhUHjeeeKspo2ZHbUeHpGKpx17xn5DScnnoCcGj Y6WN1htRMZWjbUglkPZmxrMG2zIzgAUR37goWIoVeTGQah2rL91Tj3nc6Tq9RmnO m6bc5wJp2kFEDf5TccOi9Fta7hp6AdzqDIZkH9AG4ia+RQYQUDI1mLYJGqT9oye7 9Nhm/LRnr4y5p/3HExGmou7bXe7ckpMShdpYbBF8eeTs6+Q0TA+td1/Q== 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 TFySePUJ3Ot9; Mon, 9 Jul 2012 10:28:02 +0100 (IST) Received: from [10.87.48.11] (unknown [86.44.73.65]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 1C37F1714F6; Mon, 9 Jul 2012 10:28:00 +0100 (IST) Message-ID: <4FFAA41E.7080907@cs.tcd.ie> Date: Mon, 09 Jul 2012 10:27:58 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Yaron Sheffer References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> <4FFA242C.8000402@cs.tcd.ie> <4FFA7A5A.70008@gmail.com> In-Reply-To: <4FFA7A5A.70008@gmail.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 09 Jul 2012 09:27:44 -0000 On 07/09/2012 07:29 AM, Yaron Sheffer wrote: > Passwords are not "the enemy". More like a wild animal that we, as a > community, need to tame. Fair enough that "enemy" is exaggeration. I'm guilty of that:-0 FWIW, I don't think we ought try get rid of passwords. I think a practical goal though is to try reduce the rate of growth of password database entries. And I think we ought try do that via non-password based auth schemes, in http and elsewhere. So I don't think we're really disagreeing. S. > > This paper presents a very important classification. Unlike Stephen, I > think that moving forward we should not aim to drop passwords > altogether. Rather, we should combine the usability benefits of > passwords (primarily the fact that a password can be used from anywhere, > with no need for credentials to live on a device) with one or more of > the password "replacement" technologies. For example, a master password > can be used to unlock a public-key store. > > We can reduce the usage of passwords significantly, thereby reducing the > associated risk. We can also use under-utilized technologies to improve > the remaining uses of passwords. These include password-based > authentication protocols (EKE and the like), and amplification of > passwords into long-term cryptographic secrets, when appropriate > (http://tools.ietf.org/html/rfc6631#section-3.5). > > Thanks, > Yaron > > On 07/09/2012 03:22 AM, Stephen Farrell wrote: >> >> I agree with their opening (*) and with thinking more, >> and seriously, about this topic. >> >> (*) "The continued domination of passwords over all >> other methods of end-user authentication is a >> major embarrassment..." >> >> I entirely disagree that we ought give up, if that's the >> conclusion someone might draw. >> >> If we wanted to solve this, we could, IMO. SSH and PGP are >> perfectly good protocol models, and usability has to be >> easier than installing linux, which seems to have been >> doable for a few million folks. >> >> S. >> >> PS: Full disclosure - I got frustrated that nobody else did >> it, so I wrote up a scheme for http/2.0 aiming specifically >> at tackling this issue. [1] IMO, it could work, if the >> browser folks actually felt the embarrassment mentioned >> above. I hope they do. (And don't care if this or some other >> scheme is the non-password one that gets adopted.) >> >> [1] http://tools.ietf.org/html/draft-farrell-httpbis-hoba >> >> On 07/09/2012 12:52 AM, Paul Hoffman wrote: >>> Greetings again. A few times on this list, people have spoken of the >>> need to replace passwords with an unstated assumption that if we just >>> work hard enough, we'll have a good solution. Another unstated >>> assumption is that we know how to measure what a good replacement is. >>> A recent excellent academic paper, referenced at >>> , >>> may make us (well, the less single-minded among us) a tad less >>> confident in both of those assumptions. This work is certainly >>> relevant in a few IETF WGs as well as SAAG in general. >>> >>> --Paul Hoffman >>> >>> _______________________________________________ >>> 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 Mon Jul 9 02:53: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 8DADC21F8602 for ; Mon, 9 Jul 2012 02:53:57 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xq9Q+6R7sJ62 for ; Mon, 9 Jul 2012 02:53:57 -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 E807921F85A7 for ; Mon, 9 Jul 2012 02:53:56 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so7797171vbb.31 for ; Mon, 09 Jul 2012 02:54:21 -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=4rNZjHtAPMTrK/K7sbvAfV8M/GnH+1Q0PhGqfPfOAXY=; b=fHpEb4cIAzwm/ADKidOmP1nVWP769+fUBhTCM4poLi7i4ZU6QbpkYlMNhg48sc1Ubk c7RtiBrmpwpoB4zN795ytcGDXWCN3kpzUsMzvvPFoujjJNdaJFpQHpxTrR3Bm+q0hfdE gWSVscG+R6KrlZVd4qTPpEUIDJDxPALKmDfi87HV0IFhWSLER//cJjHLrCi1vBEPVqTz kSzhdRspSHp/pu5PkeOouBCrgRh/FFmykdUwFh8hJyryuDTssVof1oo4nXvQhVDdV/Nq xSHUXh6Y6d0PWYIvHfdw9Kiojx8mAOiVIFZjwhFKa4L+66MKz65cs1rlFU+gddC80mpZ 2wKA== MIME-Version: 1.0 Received: by 10.52.73.225 with SMTP id o1mr16019391vdv.77.1341827661064; Mon, 09 Jul 2012 02:54:21 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.52.109.71 with HTTP; Mon, 9 Jul 2012 02:54:21 -0700 (PDT) In-Reply-To: <4FFA242C.8000402@cs.tcd.ie> References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> <4FFA242C.8000402@cs.tcd.ie> Date: Mon, 9 Jul 2012 10:54:21 +0100 X-Google-Sender-Auth: SJ-fGwfZg1jbfBtHfT65MOn6hCA Message-ID: From: Ben Laurie To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Cc: Paul Hoffman , IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 09 Jul 2012 09:53:57 -0000 On Mon, Jul 9, 2012 at 1:22 AM, Stephen Farrell wrote: > > I agree with their opening (*) and with thinking more, > and seriously, about this topic. > > (*) "The continued domination of passwords over all > other methods of end-user authentication is a > major embarrassment..." > > I entirely disagree that we ought give up, if that's the > conclusion someone might draw. > > If we wanted to solve this, we could, IMO. SSH and PGP are > perfectly good protocol models, and usability has to be > easier than installing linux, which seems to have been > doable for a few million folks. One has to wonder why they are not included in that paper? From yaronf.ietf@gmail.com Mon Jul 9 02:57: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 ABDA321F879E for ; Mon, 9 Jul 2012 02:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.013 X-Spam-Level: X-Spam-Status: No, score=-103.013 tagged_above=-999 required=5 tests=[AWL=0.586, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rEHOu4jMu6X for ; Mon, 9 Jul 2012 02:57:57 -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 646ED21F8699 for ; Mon, 9 Jul 2012 02:57:57 -0700 (PDT) Received: by bkty7 with SMTP id y7so2539300bkt.31 for ; Mon, 09 Jul 2012 02:58:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=u7p8WPBlp3u140ob+jzRGSC94mCI92+J6QJIkSa+81c=; b=DUFKqktt6rQU0GJ8pp1ZJZMwmd6XpdfPVrXsBo+oRyHuarrISxxveU2Yjer/jHjh2c 0ZbJkdIXOjNwQWG2J9mKydks2Nak4skNKWk2eWy4MjLu4U3ND2icV/jGrSv7OmwxxZ/r ESfM/3RWTGQuZ57gHKu4Ek161OtrwVN+Jg/Ira4MY1OP2KzFZi5eEzcQCcVdS+gYNmV/ yOZ1wrJAobolQDQwY4oXhQmxYCYEofvp5G21KAtKxtZgH06UqtZE3dOiwY4MPGy+Uqip KwENP5ohRcut43o56zL3zwvXIcZYwcGp2fGTMqa45T18oRICzH9R0o9tJWEBcE8pATaJ QKcQ== Received: by 10.204.156.220 with SMTP id y28mr19107949bkw.37.1341827901008; Mon, 09 Jul 2012 02:58:21 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-181-164-236.red.bezeqint.net. [79.181.164.236]) by mx.google.com with ESMTPS id u8sm25860049bks.0.2012.07.09.02.58.19 (version=SSLv3 cipher=OTHER); Mon, 09 Jul 2012 02:58:20 -0700 (PDT) Message-ID: <4FFAAB3A.3030403@gmail.com> Date: Mon, 09 Jul 2012 12:58:18 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Stephen Farrell References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> <4FFA242C.8000402@cs.tcd.ie> <4FFA7A5A.70008@gmail.com> <4FFAA41E.7080907@cs.tcd.ie> In-Reply-To: <4FFAA41E.7080907@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 09 Jul 2012 09:57:58 -0000 So it's mostly a question of where to focus. I would say that, *in addition* to non-password based auth methods, we also need to work on more modern password based auth methods, in HTTP and elsewhere. We will probably need both for a long time. Thanks, Yaron On 07/09/2012 12:27 PM, Stephen Farrell wrote: > > > On 07/09/2012 07:29 AM, Yaron Sheffer wrote: >> Passwords are not "the enemy". More like a wild animal that we, as a >> community, need to tame. > > Fair enough that "enemy" is exaggeration. I'm guilty of > that:-0 > > FWIW, I don't think we ought try get rid of passwords. I think > a practical goal though is to try reduce the rate of growth of > password database entries. > > And I think we ought try do that via non-password based auth > schemes, in http and elsewhere. > > So I don't think we're really disagreeing. > > S. > >> >> This paper presents a very important classification. Unlike Stephen, I >> think that moving forward we should not aim to drop passwords >> altogether. Rather, we should combine the usability benefits of >> passwords (primarily the fact that a password can be used from anywhere, >> with no need for credentials to live on a device) with one or more of >> the password "replacement" technologies. For example, a master password >> can be used to unlock a public-key store. >> >> We can reduce the usage of passwords significantly, thereby reducing the >> associated risk. We can also use under-utilized technologies to improve >> the remaining uses of passwords. These include password-based >> authentication protocols (EKE and the like), and amplification of >> passwords into long-term cryptographic secrets, when appropriate >> (http://tools.ietf.org/html/rfc6631#section-3.5). >> >> Thanks, >> Yaron >> >> On 07/09/2012 03:22 AM, Stephen Farrell wrote: >>> >>> I agree with their opening (*) and with thinking more, >>> and seriously, about this topic. >>> >>> (*) "The continued domination of passwords over all >>> other methods of end-user authentication is a >>> major embarrassment..." >>> >>> I entirely disagree that we ought give up, if that's the >>> conclusion someone might draw. >>> >>> If we wanted to solve this, we could, IMO. SSH and PGP are >>> perfectly good protocol models, and usability has to be >>> easier than installing linux, which seems to have been >>> doable for a few million folks. >>> >>> S. >>> >>> PS: Full disclosure - I got frustrated that nobody else did >>> it, so I wrote up a scheme for http/2.0 aiming specifically >>> at tackling this issue. [1] IMO, it could work, if the >>> browser folks actually felt the embarrassment mentioned >>> above. I hope they do. (And don't care if this or some other >>> scheme is the non-password one that gets adopted.) >>> >>> [1] http://tools.ietf.org/html/draft-farrell-httpbis-hoba >>> >>> On 07/09/2012 12:52 AM, Paul Hoffman wrote: >>>> Greetings again. A few times on this list, people have spoken of the >>>> need to replace passwords with an unstated assumption that if we just >>>> work hard enough, we'll have a good solution. Another unstated >>>> assumption is that we know how to measure what a good replacement is. >>>> A recent excellent academic paper, referenced at >>>> , >>>> may make us (well, the less single-minded among us) a tad less >>>> confident in both of those assumptions. This work is certainly >>>> relevant in a few IETF WGs as well as SAAG in general. >>>> >>>> --Paul Hoffman >>>> >>>> _______________________________________________ >>>> 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 stephen.farrell@cs.tcd.ie Mon Jul 9 04:22: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 23FB421F8540 for ; Mon, 9 Jul 2012 04:22:22 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iu9ro+KpoM+F for ; Mon, 9 Jul 2012 04:22: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 F010B21F852A for ; Mon, 9 Jul 2012 04:22:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id C5E1B1714F6; Mon, 9 Jul 2012 12:22:43 +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=1341832962; bh=FMHLd27z3abyWu cNE7TdI/N2uQTGMlC2Q3/nQB8VLQA=; b=7mR7ATKFKVbonbTocxGfU3Q8oKdDIV 6oq6z2UMsRskGkTLB4Sw06m3BY2iX3Wu28DEBG0bfjYhoEY+WEOgJrRWkTe8F1pG MP4THKqSdhdb9ZEl6BSReKiWvBIK9fknv/oukavP0Gv40xZQ2n7h1BLtPm2EN4Lp EpsnqeOx1G0M6yWqF900LA0mVTF80ukT8Ze8gobK6BCJJmhTXkqHI1Y3bs8mMdyP h1nNs4TejxTzH3rtl3mYN2YvwNO7EG7wbFgWSJvXvkAqONQMbx6pRX/AJZIZWh/v gP9eGf1EQY0UeOdOQI1YPBW+DJSTtZVE4+GgPQlNKOBkQVJrOWUGYc+Q== 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 jL9uNckgK3qo; Mon, 9 Jul 2012 12:22:42 +0100 (IST) Received: from [IPv6:2001:770:10:203:49c4:9e95:3fcb:975a] (unknown [IPv6:2001:770:10:203:49c4:9e95:3fcb:975a]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 7C4E61714EB; Mon, 9 Jul 2012 12:22:40 +0100 (IST) Message-ID: <4FFABF00.7030001@cs.tcd.ie> Date: Mon, 09 Jul 2012 12:22:40 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Yaron Sheffer References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> <4FFA242C.8000402@cs.tcd.ie> <4FFA7A5A.70008@gmail.com> <4FFAA41E.7080907@cs.tcd.ie> <4FFAAB3A.3030403@gmail.com> In-Reply-To: <4FFAAB3A.3030403@gmail.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 09 Jul 2012 11:22:22 -0000 On 07/09/2012 10:58 AM, Yaron Sheffer wrote: > So it's mostly a question of where to focus. I would say that, *in > addition* to non-password based auth methods, we also need to work on > more modern password based auth methods, in HTTP and elsewhere. We will > probably need both for a long time. I sort of agree, though I personally think the most pressing need (in the IETF, for http) is to provide a usable non-password based auth scheme that has a good chance to get used. That last is outside our control of course, but the current work on http/2.0 does provide a window of opportunity maybe. For "more modern" (whatever that means) schemes based on passwords, if they still require a database that can leak and be dictionary attacked, then I'm not so interested, since the overall benefit provided doesn't seem that great given the kinds of attack seen in the wild. But I do agree that better support for kerberos-like auth-schemes in http is probably worth effort and maybe EKE-like things are also, but less so IMO. I'd encourage folks to go look at the set of http/2.0 auth scheme proposals [1] and send the kind of comments requested [2] to the httpbis wg. [3] There's a deadline for that of July 15th btw. S. [1] http://trac.tools.ietf.org/wg/httpbis/trac/wiki/HttpAuthProposals [2] http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0008.html [3] http://tools.ietf.org/wg/httpbis/ > > Thanks, > Yaron > > On 07/09/2012 12:27 PM, Stephen Farrell wrote: >> >> >> On 07/09/2012 07:29 AM, Yaron Sheffer wrote: >>> Passwords are not "the enemy". More like a wild animal that we, as a >>> community, need to tame. >> >> Fair enough that "enemy" is exaggeration. I'm guilty of >> that:-0 >> >> FWIW, I don't think we ought try get rid of passwords. I think >> a practical goal though is to try reduce the rate of growth of >> password database entries. >> >> And I think we ought try do that via non-password based auth >> schemes, in http and elsewhere. >> >> So I don't think we're really disagreeing. >> >> S. >> >>> >>> This paper presents a very important classification. Unlike Stephen, I >>> think that moving forward we should not aim to drop passwords >>> altogether. Rather, we should combine the usability benefits of >>> passwords (primarily the fact that a password can be used from anywhere, >>> with no need for credentials to live on a device) with one or more of >>> the password "replacement" technologies. For example, a master password >>> can be used to unlock a public-key store. >>> >>> We can reduce the usage of passwords significantly, thereby reducing the >>> associated risk. We can also use under-utilized technologies to improve >>> the remaining uses of passwords. These include password-based >>> authentication protocols (EKE and the like), and amplification of >>> passwords into long-term cryptographic secrets, when appropriate >>> (http://tools.ietf.org/html/rfc6631#section-3.5). >>> >>> Thanks, >>> Yaron >>> >>> On 07/09/2012 03:22 AM, Stephen Farrell wrote: >>>> >>>> I agree with their opening (*) and with thinking more, >>>> and seriously, about this topic. >>>> >>>> (*) "The continued domination of passwords over all >>>> other methods of end-user authentication is a >>>> major embarrassment..." >>>> >>>> I entirely disagree that we ought give up, if that's the >>>> conclusion someone might draw. >>>> >>>> If we wanted to solve this, we could, IMO. SSH and PGP are >>>> perfectly good protocol models, and usability has to be >>>> easier than installing linux, which seems to have been >>>> doable for a few million folks. >>>> >>>> S. >>>> >>>> PS: Full disclosure - I got frustrated that nobody else did >>>> it, so I wrote up a scheme for http/2.0 aiming specifically >>>> at tackling this issue. [1] IMO, it could work, if the >>>> browser folks actually felt the embarrassment mentioned >>>> above. I hope they do. (And don't care if this or some other >>>> scheme is the non-password one that gets adopted.) >>>> >>>> [1] http://tools.ietf.org/html/draft-farrell-httpbis-hoba >>>> >>>> On 07/09/2012 12:52 AM, Paul Hoffman wrote: >>>>> Greetings again. A few times on this list, people have spoken of the >>>>> need to replace passwords with an unstated assumption that if we just >>>>> work hard enough, we'll have a good solution. Another unstated >>>>> assumption is that we know how to measure what a good replacement is. >>>>> A recent excellent academic paper, referenced at >>>>> , >>>>> >>>>> may make us (well, the less single-minded among us) a tad less >>>>> confident in both of those assumptions. This work is certainly >>>>> relevant in a few IETF WGs as well as SAAG in general. >>>>> >>>>> --Paul Hoffman >>>>> >>>>> _______________________________________________ >>>>> 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 hartmans@mit.edu Mon Jul 9 07:45: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 78DB311E80A0 for ; Mon, 9 Jul 2012 07:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.742 X-Spam-Level: X-Spam-Status: No, score=-102.742 tagged_above=-999 required=5 tests=[AWL=-2.336, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBS-mxQRyCLr for ; Mon, 9 Jul 2012 07:45:09 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 62B1A11E8097 for ; Mon, 9 Jul 2012 07:45:09 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id F19EC20576; Mon, 9 Jul 2012 10:46:01 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9BEE441F0; Mon, 9 Jul 2012 10:45:27 -0400 (EDT) From: Sam Hartman To: Ben Laurie References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> <4FFA242C.8000402@cs.tcd.ie> Date: Mon, 09 Jul 2012 10:45:27 -0400 In-Reply-To: (Ben Laurie's message of "Mon, 9 Jul 2012 10:54:21 +0100") 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: IETF Security Area Advisory Group , Paul Hoffman Subject: Re: [saag] The quest to replace passwords 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, 09 Jul 2012 14:45:10 -0000 I'll note that the usable deployments of ssh public keys I've seen--things widely deployed enough that a commercial organization is willing to support it for a public of developer communities--all fall back to passwords to reset/change your ssh keys. I'm thinking of things like github/launchpad/sourceforge/etc. Ssh alone does not solve the key management problem ; how do I get a particular ssh key authorized. In practice, beyond fairly small deployments that ends up boiling down to passwords and TLS. From stephen.farrell@cs.tcd.ie Mon Jul 9 07:56: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 DEB2521F8649 for ; Mon, 9 Jul 2012 07:56:25 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6PzV+XXUPbu for ; Mon, 9 Jul 2012 07:56:22 -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 A561421F8648 for ; Mon, 9 Jul 2012 07:56:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 4692B1714F6; Mon, 9 Jul 2012 15:56:44 +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=1341845804; bh=4hZM/7KIG6fOUP PSnOEB7mtZ2k1Wzu/me8sv01Oq24A=; b=c7UzE/p5AjSkQFnQXqya9fdtMTgunZ NTvDMwFbneYcGyStGl0zKiaTjhWYFrF1ugUdvMulGaAmr0TmaKULD3CBCo9Kuqcc O/jaNu9MNo2fF9eaaAJ4MtTdTN2kuYrp/Tswjpj0h1gJKMt05+ai3C1Ifv7JgkIL jKECaiJY+2z+8R+N7z9YX7ii7q5ZgScCDYuHWf5GQYact01Xo4nwWcD6+Q5LTxe1 P/1NRCr6dpBntB0nsN/N6lliGnWEKgWF/tNtMNMTkV1XZQmwEJFwO+z45UnqgwwL B9j/2IsL6UD5siGWGwVzDmQC8Dh2WHLjJcML5YJlh/8eW2h+nbTuNImw== 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 6MV5GNjJBfu8; Mon, 9 Jul 2012 15:56:44 +0100 (IST) Received: from [IPv6:2001:770:10:203:49c4:9e95:3fcb:975a] (unknown [IPv6:2001:770:10:203:49c4:9e95:3fcb:975a]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id EF8041714F1; Mon, 9 Jul 2012 15:56:40 +0100 (IST) Message-ID: <4FFAF128.3010106@cs.tcd.ie> Date: Mon, 09 Jul 2012 15:56:40 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Sam Hartman References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> <4FFA242C.8000402@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF Security Area Advisory Group , Paul Hoffman Subject: Re: [saag] The quest to replace passwords 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, 09 Jul 2012 14:56:26 -0000 Hi Sam, On 07/09/2012 03:45 PM, Sam Hartman wrote: > I'll note that the usable deployments of ssh public keys I've > seen--things widely deployed enough that a commercial organization is > willing to support it for a public of developer communities--all fall > back to passwords to reset/change your ssh keys. I'm thinking of things > like github/launchpad/sourceforge/etc. > > Ssh alone does not solve the key management problem ; how do I get a > particular ssh key authorized. In practice, beyond fairly small > deployments that ends up boiling down to passwords and TLS. I agree that those are issues that need to be tackled but I don't think they are insurmountable. My thesis is that there are now enough people with multiple capable devices that we can solve these problems in a useful number of situations by taking advantage of that fact. I fully accept that that's somewhat speculative but the potential payoff is IMO worth the effort of trying (again;-). Cheers, S. From tbray@textuality.com Mon Jul 9 08:02: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 F223621F8686 for ; Mon, 9 Jul 2012 08:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.071 X-Spam-Level: X-Spam-Status: No, score=-6.071 tagged_above=-999 required=5 tests=[AWL=-3.094, 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 nNel4YIRXwu1 for ; Mon, 9 Jul 2012 08:02:49 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0C91D21F8659 for ; Mon, 9 Jul 2012 08:02:48 -0700 (PDT) Received: by ggnc4 with SMTP id c4so11162745ggn.31 for ; Mon, 09 Jul 2012 08:03:13 -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 :content-transfer-encoding:x-gm-message-state; bh=vGkq0ipNJ53Fu1UGo7loplj2ni4NJyokj42cgFG8lJQ=; b=KiuttIFedaQYEIy+QHDP9iPigfHR7IJNQyYajLrZXdRgMwPmG499VcbeGp2EzVHWKt PKHhj1fsVP6fIREnaTL2DnqmH7Iphcdyw1tCm85sGBcMzZkgH7F/1CAyvlZ76APIVjsq JiOU3akIUksQPnaahFJFuACqf2PtsZhIcMGdzdNCK13fKe9r14QOFEFOl68YnC1c1uyj 9IR1gIWNdgPKA3Yy9W0YzUJNhh+Rr0aesaUHR9HYK+ioAt6Wvto22FrGpHIaE5cAjDWD 6tGtcklcWt7IOZR10LtesL0hYJBGoeQil8XTQlJwNHeAo5FYV2rKqHekLpSybrCH5Riz TL5w== MIME-Version: 1.0 Received: by 10.60.2.193 with SMTP id 1mr42686886oew.29.1341846193611; Mon, 09 Jul 2012 08:03:13 -0700 (PDT) Received: by 10.182.75.38 with HTTP; Mon, 9 Jul 2012 08:03:13 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> Date: Mon, 9 Jul 2012 08:03:13 -0700 Message-ID: From: Tim Bray To: Paul Hoffman Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnmqOrV4DhEKyJSfIXGEr7ChOhLaygknsbAqfBMrLWQalYYoMaqt5tpbQiCzt+V8AIUUsVR Cc: IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 09 Jul 2012 15:02:50 -0000 Hmm... most organizations I=92ve worked with/for that really care about security seem to think the old something-you-have+something-you-know, implemented well, hits a good 80/20 point. I=92m inclined to agree. I=92d also be unsurprised if someone came up with something better, and that table is a handy tool to help think about replacements. The problem with passwords is trying to scale them across the Internet. I don=92t mind at all logging on once, and even doing some extra-security song-and-dance about it. I just want to use the identity thus established everywhere I go, to the extent possible. -T On Sun, Jul 8, 2012 at 4:52 PM, Paul Hoffman wrote: > Greetings again. A few times on this list, people have spoken of the need= to replace passwords with an unstated assumption that if we just work hard= enough, we'll have a good solution. Another unstated assumption is that we= know how to measure what a good replacement is. A recent excellent academi= c paper, referenced at , may make us (well, the less single-minded amon= g us) a tad less confident in both of those assumptions. This work is certa= inly relevant in a few IETF WGs as well as SAAG in general. > > --Paul Hoffman > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From hartmans@mit.edu Mon Jul 9 08:06: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 004DE11E80BF for ; Mon, 9 Jul 2012 08:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.555 X-Spam-Level: X-Spam-Status: No, score=-103.555 tagged_above=-999 required=5 tests=[AWL=-1.290, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FmjFkqotoTs for ; Mon, 9 Jul 2012 08:06:17 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0A56C11E80B7 for ; Mon, 9 Jul 2012 08:06:03 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 03827202D8; Mon, 9 Jul 2012 11:06:58 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8526841F0; Mon, 9 Jul 2012 11:06:23 -0400 (EDT) From: Sam Hartman To: Stephen Farrell References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> <4FFA242C.8000402@cs.tcd.ie> <4FFAF128.3010106@cs.tcd.ie> Date: Mon, 09 Jul 2012 11:06:23 -0400 In-Reply-To: <4FFAF128.3010106@cs.tcd.ie> (Stephen Farrell's message of "Mon, 09 Jul 2012 15:56:40 +0100") 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: IETF Security Area Advisory Group , Sam Hartman , Paul Hoffman Subject: Re: [saag] The quest to replace passwords 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, 09 Jul 2012 15:06:18 -0000 >>>>> "Stephen" == Stephen Farrell writes: Stephen> Hi Sam, Stephen> On 07/09/2012 03:45 PM, Sam Hartman wrote: >> I'll note that the usable deployments of ssh public keys I've >> seen--things widely deployed enough that a commercial organization is >> willing to support it for a public of developer communities--all fall >> back to passwords to reset/change your ssh keys. I'm thinking of things >> like github/launchpad/sourceforge/etc. >> >> Ssh alone does not solve the key management problem ; how do I get a >> particular ssh key authorized. In practice, beyond fairly small >> deployments that ends up boiling down to passwords and TLS. Stephen> I agree that those are issues that need to be tackled Stephen> but I don't think they are insurmountable. Perhaps. However, if I were going to look at successful models of non-password auth I'd look at Blizard (World of Warcraft), Google and various business banking tokens rather than SSH for success stories and motivation. Those deployments seem to focus on OTP of some kind or another or a presumed secure back channel in the case of some SMS schemes. Obviously I believe this is an important problem. I've been working on various ways to decouple authentication mechanism from the rest of the exchange and various ways to abstract out authentication for the past 15 years or so. The reason I've been working on that is in part to support move away from passwords where it makes sense. From nico@cryptonector.com Mon Jul 9 08:39: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 1FEB911E80E1 for ; Mon, 9 Jul 2012 08:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.067 X-Spam-Level: X-Spam-Status: No, score=-3.067 tagged_above=-999 required=5 tests=[AWL=-1.090, 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 NCk+XNd1ucH7 for ; Mon, 9 Jul 2012 08:39:23 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 826E711E80D2 for ; Mon, 9 Jul 2012 08:39:23 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 2BE5F6B007B for ; Mon, 9 Jul 2012 08:39:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=XkYSa38w+exRwiVv6k3x5 vCQ46XsN0tOqRWN0rxJZc0sJjowckkzesvjbt9sRGcy2BjZB9ms0z1JgSGphIyqq l3PvQPqXtwoKJtILcJ6p2n8lyNrs1PJVJ6zQJ+u8fi8KDXxGIGH0dhxa3bnLovbx s5izGAMbP409CsTJ5hbN/c= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=I20lQ55qr/Ou4Ab9uA+4 43AOjd4=; b=X/jk7WlqexgEW1YeGb1QbMEHChlhY1TqUHOZ1T8JZMJILvgBqsui k+clGzZL5RidSqneS+HCcl1AXlKhLYVHOzGixSHTk49jwj1NiiRmhH9Sg3pAvmzz 1D8yJNP1IzYcPrL0UnmjcWHU/XSZP+NNucAU1p1EBoOdVOFAMmxFT7A= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 10FD56B0070 for ; Mon, 9 Jul 2012 08:39:48 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so19993520pbc.31 for ; Mon, 09 Jul 2012 08:39:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.223.138 with SMTP id qu10mr61569226pbc.50.1341848387568; Mon, 09 Jul 2012 08:39:47 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Mon, 9 Jul 2012 08:39:47 -0700 (PDT) In-Reply-To: <4FFABF00.7030001@cs.tcd.ie> References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> <4FFA242C.8000402@cs.tcd.ie> <4FFA7A5A.70008@gmail.com> <4FFAA41E.7080907@cs.tcd.ie> <4FFAAB3A.3030403@gmail.com> <4FFABF00.7030001@cs.tcd.ie> Date: Mon, 9 Jul 2012 10:39:47 -0500 Message-ID: From: Nico Williams To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Cc: Paul Hoffman , IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 09 Jul 2012 15:39:24 -0000 On Mon, Jul 9, 2012 at 6:22 AM, Stephen Farrell wrote: > For "more modern" (whatever that means) schemes based on > passwords, if they still require a database that can leak > and be dictionary attacked, then I'm not so interested, > since the overall benefit provided doesn't seem that > great given the kinds of attack seen in the wild. All password-based schemes must have either password equivalent or password verifier databases. Necessarily. ZKPPs included. These usually are amenable to HSM implementation, so that helps. Also, some such schemes have trusted infrastructure, and that too helps (put the HSMs in the infrastructure, and you've minimized and reasonably secured the number of places where material can get stolen for off-line dictionary attacks). > But I do agree that better support for kerberos-like > auth-schemes in http is probably worth effort and maybe > EKE-like things are also, but less so IMO. We have roughly these choices for cryptographic, password-based security: - no trusted third parties (e.g., SCRAM and all plain ZKPPs) - trusted infrastructure, with client doing the talking (Kerberos) - trusted infrastructure, with server doing the talking (ABFAB) Any variation on the first that adds trusted third parties ends up looking like Kerberos or ABFAB or a hybrid. > I'd encourage folks to go look at the set of http/2.0 > auth scheme proposals [1] and send the kind of comments > requested [2] to the httpbis wg. [3] There's a deadline > for that of July 15th btw. For comments? I've seen very few, if any comments so far on all of the proposals. Makes me question actual WG inteterst. Nico -- From stephen.farrell@cs.tcd.ie Mon Jul 9 08:51: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 4BB4711E80FF for ; Mon, 9 Jul 2012 08:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZ0G4nyaGYbR for ; Mon, 9 Jul 2012 08:51:34 -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 587FB11E80FE for ; Mon, 9 Jul 2012 08:51:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id EF0471714F6; Mon, 9 Jul 2012 16:51: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=1341849118; bh=14n58o4Lc3QGmY LPiLPICn8/OJ9UxVUXIob+ds2lHWc=; b=vAGtl4PaCScrRFze6Z5FMkxatFRgNh Wddiyf1VKm2ECp43fd8nKqyhyb3T7hmYI93HQm/i4bc14xsi1h46AW4nit5vlyxi TJULPqEcLgD/21kB4gk4RDWIkXKMKFU4NcP+y/PbCBUEzbG644eqTUZKupP7/NlI TBcDPjUZMS0qwDEAl7mdmnq9jtuEhFsia7eOcAQxRXUR7wLslE0R3/Zz8XLXPgrr 7EsFJAWLAJ0qIQJ9NXu4raZdWyq3LOfq0WBc4mK28gVfVJnAsv2y2EmU1LttWppH 4NlH6JnKTm6uMXQxM3uMcegKBhiqq42MdVklRPRcSWOWLF+hZxwdKjFQ== 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 V8K848yF15LQ; Mon, 9 Jul 2012 16:51:58 +0100 (IST) Received: from [IPv6:2001:770:10:203:49c4:9e95:3fcb:975a] (unknown [IPv6:2001:770:10:203:49c4:9e95:3fcb:975a]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 8ECBE1714F1; Mon, 9 Jul 2012 16:51:58 +0100 (IST) Message-ID: <4FFAFE1E.9010300@cs.tcd.ie> Date: Mon, 09 Jul 2012 16:51:58 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Nico Williams References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> <4FFA242C.8000402@cs.tcd.ie> <4FFA7A5A.70008@gmail.com> <4FFAA41E.7080907@cs.tcd.ie> <4FFAAB3A.3030403@gmail.com> <4FFABF00.7030001@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 09 Jul 2012 15:51:35 -0000 On 07/09/2012 04:39 PM, Nico Williams wrote: >> > I'd encourage folks to go look at the set of http/2.0 >> > auth scheme proposals [1] and send the kind of comments >> > requested [2] to the httpbis wg. [3] There's a deadline >> > for that of July 15th btw. > > For comments? Yep. > I've seen very few, if any comments so far on all of > the proposals. Makes me question actual WG inteterst. Agreed. However to be fair, I guess "SPDY vs.the rest" is probably more of a deal for most wg participants. I'm not sure what the chair plans if there're few or no comments on the auth schemes, but I'd bet it'll be seen as a lack of interest and will make it less likely that we'll get security improvements as part of http/2.0, so if folks here do have thoughts, sharing those on the httpbis list would be welcome, esp. if they relate to things you'd implement/deploy. (I doubt that a bunch of "+1 for more security" mails will help very much;-) S. From nico@cryptonector.com Mon Jul 9 09:45: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 5B19111E813E for ; Mon, 9 Jul 2012 09:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.039 X-Spam-Level: X-Spam-Status: No, score=-3.039 tagged_above=-999 required=5 tests=[AWL=-1.063, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygRc6SIlPkMi for ; Mon, 9 Jul 2012 09:45:55 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 8617411E8137 for ; Mon, 9 Jul 2012 09:45:55 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 8A6AF318064 for ; Mon, 9 Jul 2012 09:46:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=CCIdMEl1M0wR1gybzFKZA 69JBR53DrNHn3gnm/veFGWUgFUId4JMxjETMSYBpIu+RxHanr3KLFbgktH35/6In wdu5YOsa35PnJfwCffzaXxiwm2DzxEr+O/yLj2/qTjqBV6L2Kplk4gMA4Fj3web4 VkzQt+w/w1jSUeM1Ivl5kI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=meCbldJs08eKv9dk9Icj VIbwFSs=; b=m4YCTwlPQrQiIm/KloN6DT7yJMM4kDiIswoOsNFrkbdSpwQZSIkd SMWfhBeXcQQKWiaqXUci+6xxcYZl2VO0Viz/nZSBX2Ff9RledxyLSoqZjjq7zv/n TjcHJGqj+2PjAynVuJLFSfI6g9VgUGy3OY0SuQA9QjItVGjV9lBedQk= Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 69E2B318071 for ; Mon, 9 Jul 2012 09:46:20 -0700 (PDT) Received: by yhq56 with SMTP id 56so12871310yhq.31 for ; Mon, 09 Jul 2012 09:46:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.222.40 with SMTP id qj8mr61295005pbc.139.1341852379163; Mon, 09 Jul 2012 09:46:19 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Mon, 9 Jul 2012 09:46:19 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Mon, 9 Jul 2012 09:46:19 -0700 (PDT) In-Reply-To: References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> Date: Mon, 9 Jul 2012 11:46:19 -0500 Message-ID: From: Nico Williams To: Tim Bray Content-Type: multipart/alternative; boundary=047d7b2ee2e966aa4704c4685ad2 Cc: saag@ietf.org, Paul Hoffman Subject: Re: [saag] The quest to replace passwords 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, 09 Jul 2012 16:45:56 -0000 --047d7b2ee2e966aa4704c4685ad2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Jul 9, 2012 10:03 AM, "Tim Bray" wrote: > > Hmm... most organizations I=E2=80=99ve worked with/for that really care a= bout > security seem to think the old something-you-have+something-you-know, > implemented well, hits a good 80/20 point. I=E2=80=99m inclined to agree= . > > I=E2=80=99d also be unsurprised if someone came up with something better,= and > that table is a handy tool to help think about replacements. > > The problem with passwords is trying to scale them across the > Internet. I don=E2=80=99t mind at all logging on once, and even doing so= me > extra-security song-and-dance about it. I just want to use the > identity thus established everywhere I go, to the extent possible. -T +1. This basically means trusted third parties. I'm ok with that. I don't think we'll do much better than this. We can make the crypto not suck, we can use HSMs, and we can make authentication federations scale to whatever size is appropriate (the smaller the better for authenticating services to users). Nico -- --047d7b2ee2e966aa4704c4685ad2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jul 9, 2012 10:03 AM, "Tim Bray" <tbray@textuality.com> wrote:
>
> Hmm... most organizations I=E2=80=99ve worked with/for that really car= e about
> security seem to think the old something-you-have+something-you-know,<= br> > implemented well, hits a good 80/20 point. =C2=A0I=E2=80=99m inclined = to agree.
>
> I=E2=80=99d also be unsurprised if someone came up with something bett= er, and
> that table is a handy tool to help think about replacements.
>
> The problem with passwords is trying to scale them across the
> Internet. =C2=A0I don=E2=80=99t mind at all logging on once, and even = doing some
> extra-security song-and-dance about it. =C2=A0I just want to use the > identity thus established everywhere I go, to the extent possible. =C2= =A0-T

+1.=C2=A0 This basically means trusted third parties.=C2=A0 I'm ok w= ith that.=C2=A0 I don't think we'll do much better than this.=C2=A0= We can make the crypto not suck, we can use HSMs, and we can make authenti= cation federations scale to whatever size is appropriate (the smaller the b= etter for authenticating services to users).

Nico
--

--047d7b2ee2e966aa4704c4685ad2-- From mouse@Sparkle.Rodents-Montreal.ORG Mon Jul 9 09:52: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 C13E421F87BD for ; Mon, 9 Jul 2012 09:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.061 X-Spam-Level: X-Spam-Status: No, score=-9.061 tagged_above=-999 required=5 tests=[AWL=0.927, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, 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 zgeNFvZg2INe for ; Mon, 9 Jul 2012 09:52:09 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id CFA1621F86DE for ; Mon, 9 Jul 2012 09:52:08 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id MAA22795; Mon, 9 Jul 2012 12:52:30 -0400 (EDT) Date: Mon, 9 Jul 2012 12:52:30 -0400 (EDT) From: Mouse Message-Id: <201207091652.MAA22795@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: Mon, 9 Jul 2012 12:42:21 -0400 (EDT) To: Sam Hartman , saag@ietf.org, Paul Hoffman In-Reply-To: References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> <4FFA242C.8000402@cs.tcd.ie> Subject: Re: [saag] The quest to replace passwords 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, 09 Jul 2012 16:52:11 -0000 > Ssh alone does not solve the key management problem ; No, but neither do passwords. ssh is better in that the data the client (the one who is authenticated) has to give to the server (the one who checks authentication) is not enough information for someone who obtains it to falsely authenticate as the client; it's worse in that that the data the client has to have on hand to authenticate is larger and, in general, cannot be memorized by humans. Actually, that's not ssh per se, but ssh's publickey authentication method. The ssh protocol does support other authentication methods, including traditional passwords (though they at least don't generally appear on the wire in the clear). /~\ 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 stephen.farrell@cs.tcd.ie Mon Jul 9 11:43: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 B005C11E80C1 for ; Mon, 9 Jul 2012 11:43:23 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejpwVrI4+Hgm for ; Mon, 9 Jul 2012 11:43:23 -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 2222311E80BC for ; Mon, 9 Jul 2012 11:43:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 342FF1714F7; Mon, 9 Jul 2012 19:43:47 +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=1341859425; bh=zIwwrFSKvJ74A2 eqE0DiJeRq5S7xqjd16m45tQdwBXM=; b=rra4z+SLAIaAccIaD2tm6GDtcpAmTf aKrkaT+Oh+OKvZCLePItfThIY5j+fBVPcRgUhsFXLUTCvj8LuIyASAtRBFPkleme nS1RNbrQyajMzrbGxM3wyL/QE+KnlOPNQFKmgjXqJBxBMSY9UsyxTnrUf82x0tbg nzvaavKRwTMG7CeSiv2QBz2PGl23259SHcU7uLQYv6hQQmrWGnzT9l0pSM7PmKHP 8qPh5Uzq+twdtISeaSB2KNgyW77AvZT80MsNHfQ2w1TahjocDakB/hpWMw/GnWCZ 8CoTTdBXKLLGBtQN0u6CxpR3pqEwulp3ochccmT8ZCKZpv9CKR2OOEbQ== 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 Ez4gGaM75kvw; Mon, 9 Jul 2012 19:43:45 +0100 (IST) Received: from [10.87.48.11] (unknown [86.42.16.71]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id BCDB61714F6; Mon, 9 Jul 2012 19:43:45 +0100 (IST) Message-ID: <4FFB2661.6070607@cs.tcd.ie> Date: Mon, 09 Jul 2012 19:43:45 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Tim Bray References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 09 Jul 2012 18:43:23 -0000 On 07/09/2012 04:03 PM, Tim Bray wrote: > Hmm... most organizations I’ve worked with/for that really care about > security seem to think the old something-you-have+something-you-know, > implemented well, hits a good 80/20 point. I’m inclined to agree. Sure, token based or two-factor auth is useful where you can afford the tokens and associated costs. > > I’d also be unsurprised if someone came up with something better, and > that table is a handy tool to help think about replacements. > > The problem with passwords is trying to scale them across the > Internet. There is definitely more than one problem with passwords;-) For example, if you just use passwords for your service and do a great job of that in every possible way, you're still vulnerable to every other less careful service that leaks its password database, to the extent that you share some users with the careless folks. > I don’t mind at all logging on once, and even doing some > extra-security song-and-dance about it. I just want to use the > identity thus established everywhere I go, to the extent possible. -T That's fine but not everyone has that requirement. Many folks would rather not have SSO everywhere all the time, and would prefer to not use the same user identifier across all services, e.g. for privacy reasons. S. > > On Sun, Jul 8, 2012 at 4:52 PM, Paul Hoffman wrote: >> Greetings again. A few times on this list, people have spoken of the need to replace passwords with an unstated assumption that if we just work hard enough, we'll have a good solution. Another unstated assumption is that we know how to measure what a good replacement is. A recent excellent academic paper, referenced at , may make us (well, the less single-minded among us) a tad less confident in both of those assumptions. This work is certainly relevant in a few IETF WGs as well as SAAG in general. >> >> --Paul Hoffman >> >> _______________________________________________ >> 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 nico@cryptonector.com Mon Jul 9 12: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 A3D7711E8139 for ; Mon, 9 Jul 2012 12:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.014 X-Spam-Level: X-Spam-Status: No, score=-3.014 tagged_above=-999 required=5 tests=[AWL=-1.037, 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 qlP6PDRNQhcu for ; Mon, 9 Jul 2012 12:00:02 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 5234811E80D0 for ; Mon, 9 Jul 2012 12:00:01 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 2F34A2C806E for ; Mon, 9 Jul 2012 12:00:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=T6HLis0xU7ezb9QxsjRMk1BQ6TIDDedIIqhrRLwqEos2 ILR96GXjvCtp4eaDuVlSVfhGQKd4T0/0SJT74dGwU3ycrXCX8EBbm3qHnUGwYWrz Pxn9onY+7aB6MzaqWI/a6WiRZLL8Q3Jw53jCzukie42Q7oBWzHTDiiBbZ7MPtlk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=5lx+biRZG6BVd+0qxh1hNvs4VLk=; b=CGSfXJVmEwB xDXQ5dWy/SdbRZ4XsHbFJXKN4LtpvapZEbA14jdZfWu6uBc78G1vRrV3TtS65w8g u6knpDfFndyAuok44S4ttPzpaAeS6od8fKASIZT8eXhhxI5P/fzZybz7zepUlrUs KBhKeFmWRa6qUkZAdRnU43LYmft2bgP8= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id 1E5392C806B for ; Mon, 9 Jul 2012 12:00:27 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so20243448pbc.31 for ; Mon, 09 Jul 2012 12:00:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.221.227 with SMTP id qh3mr62178338pbc.115.1341860426703; Mon, 09 Jul 2012 12:00:26 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Mon, 9 Jul 2012 12:00:26 -0700 (PDT) In-Reply-To: <4FFB2661.6070607@cs.tcd.ie> References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> <4FFB2661.6070607@cs.tcd.ie> Date: Mon, 9 Jul 2012 14:00:26 -0500 Message-ID: From: Nico Williams To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 09 Jul 2012 19:00:07 -0000 On Mon, Jul 9, 2012 at 1:43 PM, Stephen Farrell wrote: > On 07/09/2012 04:03 PM, Tim Bray wrote: >> Hmm... most organizations I=E2=80=99ve worked with/for that really care = about >> security seem to think the old something-you-have+something-you-know, >> implemented well, hits a good 80/20 point. I=E2=80=99m inclined to agre= e. > > Sure, token based or two-factor auth is useful where you can > afford the tokens and associated costs. They can be soft tokens (on smartphones, tablets), and they can be SMSed. >> The problem with passwords is trying to scale them across the >> Internet. > > There is definitely more than one problem with passwords;-) > > For example, if you just use passwords for your service and > do a great job of that in every possible way, you're still > vulnerable to every other less careful service that leaks > its password database, to the extent that you share some > users with the careless folks. My vision is of several/many ID providers participating in several authentication federations. Users should pick reputable ID providers, preferably ones using HSMs for protecting the password verifiers. To expand on my vision, I see: - Large shopping sites (think Amazon, Yahoo!, eBay, ...) forming their own federations, possibly allowing third party ID providers to participate. The benefit here is that the entity running the bazaar can be very selective about which *services* the user can authenticate to. This scales user populations to Internet scale, but by limiting the scale of reachable services these federations can provide much-better-than-TLS-server-PKI service authentication. - A plethora of ID providers, from user-run, to ISPs, to commercial third party ID providers, to the authentication federations themselves. Scaling user populations to Internet scale means effective SSO. Special-purpose federations with small service populations means effective mutual authentication. >> I don=E2=80=99t mind at all logging on once, and even doing some >> extra-security song-and-dance about it. I just want to use the >> identity thus established everywhere I go, to the extent possible. -T > > That's fine but not everyone has that requirement. Many folks > would rather not have SSO everywhere all the time, and would > prefer to not use the same user identifier across all services, > e.g. for privacy reasons. I didn't think that's what Tim meant. I share my tablet with my household. I find one-device-one-ID to be rather obnoxious. But that's NOT a function of the authentication method/credentials used. It's a function of the tablet OS and application developers... i dunno, not having gotten to multi-ID support. Identity selection is a complicated topic, but fortunately it's orthogonal to the web authentication topic and we can leave it for a different thread, on a different day. Nico -- From Josh.Howlett@ja.net Mon Jul 9 12:59: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 62EA611E809F for ; Mon, 9 Jul 2012 12:59:05 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mb4iEdLCpJVw for ; Mon, 9 Jul 2012 12:59:04 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id BA7AF21F8627 for ; Mon, 9 Jul 2012 12:59:04 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 2A3444A6B8B_FFB3821B; Mon, 9 Jul 2012 19:59:29 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id E7C604A6B4A_FFB3820F; Mon, 9 Jul 2012 19:59:28 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0355.002; Mon, 9 Jul 2012 20:59:28 +0100 From: Josh Howlett To: Stephen Farrell , Tim Bray Thread-Topic: [saag] The quest to replace passwords Thread-Index: AQHNXWTaTmeYN10ChkqR7Ymm7rpsjZcg/F6AgAA9noCAAN43gA== Date: Mon, 9 Jul 2012 19:59:28 +0000 Message-ID: In-Reply-To: <4FFB2661.6070607@cs.tcd.ie> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <15D73B3F7402A64287AFC00AA0586EB0@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 09 Jul 2012 19:59:05 -0000 >> I don=B9t mind at all logging on once, and even doing some >> extra-security song-and-dance about it. I just want to use the >> identity thus established everywhere I go, to the extent possible. -T > >That's fine but not everyone has that requirement. Many folks >would rather not have SSO everywhere all the time, and would >prefer to not use the same user identifier across all services, >e.g. for privacy reasons. That scenario does not preclude the use of a federated authentication mechanism; you can, after all, have a federation of one. The interesting part is generalising this so that it is merely a question for deployers to decide the scope of their federation, rather than it being an inherent property of an authentication mechanism. 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 stephen.farrell@cs.tcd.ie Wed Jul 11 10:36: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 C605111E8122 for ; Wed, 11 Jul 2012 10:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.435 X-Spam-Level: X-Spam-Status: No, score=-102.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Xju1IEgVpTU for ; Wed, 11 Jul 2012 10:36:23 -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 9F34A11E8110 for ; Wed, 11 Jul 2012 10:36:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id EEE99154130; Wed, 11 Jul 2012 18:36:53 +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=1342028212; bh=b6+GGQmN5wxfX+ 9hoMqXBDq2Y4wOUokTWgl9eJcwQ0M=; b=nu/pSMnaHxAGZLs9yAJorFQ4U/+Xl7 eg8cDsjIekaVjOui4lCFhMd2RQUsETYNnLWATF1AthM80KNbG/RKKA2CIZRp0xuW x4+FFKkHqA6oroNgmxKt/hlCHJHC7FIz9cQVhK2UdxYna08DLTdpbsyoq4ODiJ+H Cn0iZrA6YGUgIJ8B7L4q1khILPe0amWE6by1z1ddrVkQXtV8SDPLNF/81NcBAlCi 2aQQvQkByIxb8M4eVjk3aqUlC7aZcVauAqVU+yEqy/lGyZmll/h2Pf1JksuF3EbE JvmLjuZrxnf40ZxjpC/8dmPOXGgYhcXyjBHvzuoJOWQjyn7RUYG8secA== 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 q-TdmU8BpE6V; Wed, 11 Jul 2012 18:36:52 +0100 (IST) Received: from [IPv6:2001:770:10:203:ccef:cfde:983f:a313] (unknown [IPv6:2001:770:10:203:ccef:cfde:983f:a313]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 7CD7315412D; Wed, 11 Jul 2012 18:36:51 +0100 (IST) Message-ID: <4FFDB9B3.6050008@cs.tcd.ie> Date: Wed, 11 Jul 2012 18:36:51 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Paul Hoffman References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> In-Reply-To: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 11 Jul 2012 17:36:24 -0000 So yet another example of why this problem deserves effort. [1] Again, I'm not saying we can get rid of passwords, but we shouldn't give up on offering better options IMO. S. [1] http://news.slashdot.org/story/12/07/11/1344231/formspring-hacked---420000-password-hashes-leaked On 07/09/2012 12:52 AM, Paul Hoffman wrote: > Greetings again. A few times on this list, people have spoken of the need to replace passwords with an unstated assumption that if we just work hard enough, we'll have a good solution. Another unstated assumption is that we know how to measure what a good replacement is. A recent excellent academic paper, referenced at , may make us (well, the less single-minded among us) a tad less confident in both of those assumptions. This work is certainly relevant in a few IETF WGs as well as SAAG in general. > > --Paul Hoffman > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > From nico@cryptonector.com Wed Jul 11 10:56: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 16B9711E8104 for ; Wed, 11 Jul 2012 10:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.125 X-Spam-Level: X-Spam-Status: No, score=-3.125 tagged_above=-999 required=5 tests=[AWL=-1.148, 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 hX9b-p98ztpN for ; Wed, 11 Jul 2012 10:56:46 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8FD11E80DB for ; Wed, 11 Jul 2012 10:56:46 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 2FB26598065 for ; Wed, 11 Jul 2012 10:57:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=yfsciuKagG9LSZ7IlaerH u6XIchmHb6ynDKuzHVx3IoNOaqGwuFmSPq/d2zLOzPVEtXJyhQgai8nABgHvUoFX Rh1SGv9K5jtSGswc4vvbt53pdjtWz6UQgEJaqjYT5b4JtysoCyimUtoNa7uDIbiP Mt97F7/sVeIWBShqUOXJfM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=fegtyt9CRSECnJPf56+e 7bihkBA=; b=JXCKMXnMSyqccU1kPkLZi2dWhp7uBb9VXyQCTwVIWgSxw0uC51xk yutr0wH1zqaywg1n0FKbHF91FAscbOEViyBTEMkpF11bwtbow5mw7hrdaRBkl+tY CfIAtV+HAxpf5vtIIUrlPemZKenrtqNWTASLoFy6xXOg/INdebggOqs= Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id 07FCB598060 for ; Wed, 11 Jul 2012 10:57:16 -0700 (PDT) Received: by yhfs35 with SMTP id s35so2286596yhf.27 for ; Wed, 11 Jul 2012 10:57:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.80.199 with SMTP id t7mr83540337pax.82.1342029436181; Wed, 11 Jul 2012 10:57:16 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Wed, 11 Jul 2012 10:57:16 -0700 (PDT) In-Reply-To: <4FFDB9B3.6050008@cs.tcd.ie> References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> <4FFDB9B3.6050008@cs.tcd.ie> Date: Wed, 11 Jul 2012 12:57:16 -0500 Message-ID: From: Nico Williams To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Cc: Paul Hoffman , IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 11 Jul 2012 17:56:47 -0000 On Wed, Jul 11, 2012 at 12:36 PM, Stephen Farrell wrote: > Again, I'm not saying we can get rid of passwords, > but we shouldn't give up on offering better options > IMO. Anything we can do to reduce the *number* of passwords users must carry will help them pick stronger passwords, not least because carrying two or three strong passwords on a piece of paper in their wallets/purses is reasonable, while carrying hundreds, or even tens, is not. This means SSO/federation/PBKDF type solutions. The PBKDF approach (deriving site passwords from a master password) has been tried, but failed, probably because of lack of deep integration between new login pages and browser password managers. The other password count reduction schemes wouldn't need the same changes, but browsers would still have to get decent integration. Nico -- From stephen.farrell@cs.tcd.ie Wed Jul 11 11:23: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 90FFC21F8525 for ; Wed, 11 Jul 2012 11:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vP0D-P-RAwft for ; Wed, 11 Jul 2012 11:23:27 -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 D094221F84DF for ; Wed, 11 Jul 2012 11:23:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 8F59B154130; Wed, 11 Jul 2012 19:23:57 +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=1342031037; bh=UWSXH4wzcTIvJQ yrJLEdqrCS7Mw7tZYT1IWJdfj9DlY=; b=FKtHxd7qRVWAljognka4cDsIOIiXn7 GkxnsC1hJKYgwYcpG8/p1y+3QpZAMh/1DZgzSjD1TAhOkbBH3YMSSHZ7p1rSWZ0J 7mWTR3bRNainXp+qSg0NMqnm6NRiFmoiAhyWsbnhk09defkFblAtTrF4FwvnkmCn EQw6ARb5fWlv6nJT2d5q1DRsSfR4HY8pyKNQL0vZa4hIbIvk2f5hq6vsAkWjFGVi mQbDjSvfn/46X2lWSNV59gegEqkQ1fCzpiGRX5cMIxgYjrlkLV2MjgAj6/MDRLKl I6hnUpJ+BdR7KVvbVZ9c1cTDQRGXs+XBckbPQgoMoDgCoGs30TAh5A8g== 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 AkHHbW9E1lit; Wed, 11 Jul 2012 19:23:57 +0100 (IST) Received: from [10.87.48.11] (unknown [86.44.69.125]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 263EA15412F; Wed, 11 Jul 2012 19:23:57 +0100 (IST) Message-ID: <4FFDC4BC.9000406@cs.tcd.ie> Date: Wed, 11 Jul 2012 19:23:56 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Nico Williams References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> <4FFDB9B3.6050008@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 11 Jul 2012 18:23:31 -0000 Hi Nico, On 07/11/2012 06:57 PM, Nico Williams wrote: > On Wed, Jul 11, 2012 at 12:36 PM, Stephen Farrell > wrote: >> Again, I'm not saying we can get rid of passwords, >> but we shouldn't give up on offering better options >> IMO. > > Anything we can do to reduce the *number* of passwords users must > carry will help them pick stronger passwords, So I'd be interested in any evidence that that is correct. It appears to make sense, but of course that doesn't mean its what'd actually happen. I'd be surprised to be honest if it were found to be the case. S > not least because > carrying two or three strong passwords on a piece of paper in their > wallets/purses is reasonable, while carrying hundreds, or even tens, > is not. This means SSO/federation/PBKDF type solutions. > > The PBKDF approach (deriving site passwords from a master password) > has been tried, but failed, probably because of lack of deep > integration between new login pages and browser password managers. > The other password count reduction schemes wouldn't need the same > changes, but browsers would still have to get decent integration. > > Nico > -- > From nico@cryptonector.com Wed Jul 11 11:47: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 9CADC21F8554 for ; Wed, 11 Jul 2012 11:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.162 X-Spam-Level: X-Spam-Status: No, score=-3.162 tagged_above=-999 required=5 tests=[AWL=-1.185, 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 b4WiK2xNqZMG for ; Wed, 11 Jul 2012 11:47:15 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 3A63321F8552 for ; Wed, 11 Jul 2012 11:47:15 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 15622202043 for ; Wed, 11 Jul 2012 11:47:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=kJiVsveo9/kYoK4gIFrDO 9C2a4kS8dMSydSBNdjBkwISWjUYwZ0Ho4X3/di63UgVOqULRDJ4hKy5VJFf6dICX veYAQtzXmclPir0KAwb5165oB2Lon2eEpZePta9mkLmzf/8TfvbQkbFHqrCwyWwL WtzkUVIVT7gaRzAVqtjnkY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=H8tvQkRFHGqSpm9ivkc1 SGFGOGI=; b=peiwFrokN8aW1/DeJNocdSOrxIXv/2LkkGSObJ4U7TUrdMlJVepV D8t9Ui+2onSJ39zDRjfRSfrqxBD05wB80xWpYTHjGx3sgwkL/xZNboOhYlTPnK3Z Twbbf7QulOa2L9xGj2tRqAxB6Anrcsf9eFdw/Ap4DXzHhaVb2VFjD3Q= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id D99E020203C for ; Wed, 11 Jul 2012 11:47:43 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so2561203pbc.31 for ; Wed, 11 Jul 2012 11:47:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.135.201 with SMTP id pu9mr80575846pbb.146.1342032463544; Wed, 11 Jul 2012 11:47:43 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Wed, 11 Jul 2012 11:47:43 -0700 (PDT) In-Reply-To: <4FFDC4BC.9000406@cs.tcd.ie> References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> <4FFDB9B3.6050008@cs.tcd.ie> <4FFDC4BC.9000406@cs.tcd.ie> Date: Wed, 11 Jul 2012 13:47:43 -0500 Message-ID: From: Nico Williams To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Cc: IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 11 Jul 2012 18:47:15 -0000 On Wed, Jul 11, 2012 at 1:23 PM, Stephen Farrell wrote: > On 07/11/2012 06:57 PM, Nico Williams wrote: >> On Wed, Jul 11, 2012 at 12:36 PM, Stephen Farrell >> wrote: >>> Again, I'm not saying we can get rid of passwords, >>> but we shouldn't give up on offering better options >>> IMO. >> >> Anything we can do to reduce the *number* of passwords users must >> carry will help them pick stronger passwords, > > So I'd be interested in any evidence that that is > correct. It appears to make sense, but of course that > doesn't mean its what'd actually happen. I'd be > surprised to be honest if it were found to be the > case. No need for evidence, just don't let the user pick the password: generate the passwords for them and tell them to write them down. Also, even if you let them pick their passwords, fewer passwords will not likely lead to the user picking worse ones than before (it's always possible, I suppose, but it makes no sense that they would). And if you instruct the user to write down the passwords, and offer suggestions for stronger passwords, I think users can pick stronger passwords. But I can assure you that users will NOT pick or use stronger passwords if they have to have dozens of them (again, no evidence, just an assertion of common sense). Nico -- From stephen.farrell@cs.tcd.ie Wed Jul 11 12:03: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 9E47321F8478 for ; Wed, 11 Jul 2012 12:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.471 X-Spam-Level: X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kS-69L8q-mG5 for ; Wed, 11 Jul 2012 12:03:02 -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 90D1311E8118 for ; Wed, 11 Jul 2012 12:03:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id A88E315412F; Wed, 11 Jul 2012 20:03:32 +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=1342033412; bh=NNmQNwrNROkkHE G5B3uTqJYVVm0gUBMy8zjjwQkDyQg=; b=SA/2JRciTjaW+M9mWcKFWXI70iJytK J83qQSmP5cgpewfOOeqAH4zzO5l3vsvELrsJ6rFzL5xOLXbLH5h/+xpDqmKPuZon CJM3fZ0lP82chkk488tBCOD1+4r5QB0DPvBGNoGUi+feOM+gwqfw2baiA7p+XWRr zcuk+N2i/VTJxIJs+gV9j2gn7PtAR+e7h54nvizP80QvpqS266mGfXu1EIO+2d27 SPmjzWPs3Cc5Z5VjK+2FIOfcHd8pyOoH+T4zfZ6YOjfo5giqPMPx0tSUEZws0NbA rq+CFLctB3iV508jbESWpBBv7hWoSF44q6NVhnE4/TnHam+CodwI/4kA== 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 fSKeTTatYy50; Wed, 11 Jul 2012 20:03:32 +0100 (IST) Received: from [10.87.48.11] (unknown [86.44.69.125]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 1B01D15412D; Wed, 11 Jul 2012 20:03:32 +0100 (IST) Message-ID: <4FFDCE03.6010009@cs.tcd.ie> Date: Wed, 11 Jul 2012 20:03:31 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Nico Williams References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> <4FFDB9B3.6050008@cs.tcd.ie> <4FFDC4BC.9000406@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 11 Jul 2012 19:03:03 -0000 Hiya, On 07/11/2012 07:47 PM, Nico Williams wrote: > On Wed, Jul 11, 2012 at 1:23 PM, Stephen Farrell > wrote: >> On 07/11/2012 06:57 PM, Nico Williams wrote: >>> On Wed, Jul 11, 2012 at 12:36 PM, Stephen Farrell >>> wrote: >>>> Again, I'm not saying we can get rid of passwords, >>>> but we shouldn't give up on offering better options >>>> IMO. >>> >>> Anything we can do to reduce the *number* of passwords users must >>> carry will help them pick stronger passwords, >> >> So I'd be interested in any evidence that that is >> correct. It appears to make sense, but of course that >> doesn't mean its what'd actually happen. I'd be >> surprised to be honest if it were found to be the >> case. > > No need for evidence, I disagree. We ought be able to quote numbers here since we've been doing web authentication at scale for over a decade now, so many variants of password scheme have already been tried. > just don't let the user pick the password: > generate the passwords for them and tell them to write them down. I think that fails on usability grounds to be honest. I guess there may be figures for how many people let Ubuntu generate good passwords, but I suspect its a small percentage. > Also, even if you let them pick their passwords, fewer passwords will > not likely lead to the user picking worse ones than before (it's > always possible, I suppose, but it makes no sense that they would). I didn't say the passwords chosen would be worse. I said I doubted they'd be any better. > And if you instruct the user to write down the passwords, and offer > suggestions for stronger passwords, I think users can pick stronger > passwords. I think you're being *very* optimistic there. > But I can assure you that users will NOT pick or use > stronger passwords if they have to have dozens of them (again, no > evidence, just an assertion of common sense). My guess is that dozens would remain the case. There have been mega-sized password databases/login services around for years but the number of passwords people have has only kept increasing as far as I know. S > > Nico > -- > > From nico@cryptonector.com Wed Jul 11 12:08: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 A7ACD11E80DB for ; Wed, 11 Jul 2012 12:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.137 X-Spam-Level: X-Spam-Status: No, score=-3.137 tagged_above=-999 required=5 tests=[AWL=-1.160, 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 ePkNttaPYqqh for ; Wed, 11 Jul 2012 12:08:42 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id EFFA711E8101 for ; Wed, 11 Jul 2012 12:08:41 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 2012050807B for ; Wed, 11 Jul 2012 12:09:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=meKMlmF9/Bjzk8iNfphJu ZaGQnAK1E0ROSPR4Y8H64npEg3kLvzV0O388c0u0KuIkD9xgs65tYn+lTcyCV9Cf DbR7XL8ZTkgBXHhscVW1yIg6LNtlXh7yLIs/NezTQq2ASNj4prLi6SHWQUfkOrfx HnMj3/WBsLhdnqw0RriqDQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=H1ytha/SV52egOMQT6zd /YYiwdk=; b=US1IKFTQOGOoMhQzMT8FgeGE/W78wG+JRWJgz+EHy0Tg4wDMhrEO 3svtAZxcIECVKMbFCCx+NGScSVZi0dX/S4tp4u6ZRqcu2uJ43T6zhGupVpy7YhlB T6KRMnlm8qejSbzJntdPxOLQHFWIaPSace/n4pwhpDydv3dPQ3yrqkk= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 0D738508069 for ; Wed, 11 Jul 2012 12:09:13 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so2586702pbc.31 for ; Wed, 11 Jul 2012 12:09:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.130.67 with SMTP id oc3mr12480370pbb.18.1342033752727; Wed, 11 Jul 2012 12:09:12 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Wed, 11 Jul 2012 12:09:12 -0700 (PDT) In-Reply-To: <4FFDCE03.6010009@cs.tcd.ie> References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> <4FFDB9B3.6050008@cs.tcd.ie> <4FFDC4BC.9000406@cs.tcd.ie> <4FFDCE03.6010009@cs.tcd.ie> Date: Wed, 11 Jul 2012 14:09:12 -0500 Message-ID: From: Nico Williams To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Cc: IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 11 Jul 2012 19:08:42 -0000 On Wed, Jul 11, 2012 at 2:03 PM, Stephen Farrell wrote: > On 07/11/2012 07:47 PM, Nico Williams wrote: >> No need for evidence, > > I disagree. We ought be able to quote numbers here > since we've been doing web authentication at scale > for over a decade now, so many variants of password > scheme have already been tried. I call foul. Breaking up the quote like you did makes it look like I said something entirely different from what I actually wrote. >> just don't let the user pick the password: >> generate the passwords for them and tell them to write them down. > > I think that fails on usability grounds to be honest. > I guess there may be figures for how many people let > Ubuntu generate good passwords, but I suspect its > a small percentage. The key word is "let". Also, local passwords are a different beast, so I don't think Ubuntu stats here would help the analysis. >> Also, even if you let them pick their passwords, fewer passwords will >> not likely lead to the user picking worse ones than before (it's >> always possible, I suppose, but it makes no sense that they would). > > I didn't say the passwords chosen would be worse. I > said I doubted they'd be any better. Indeed, but I think we should first see if they could be worse on the way to arguing likelihood of improvement. >> And if you instruct the user to write down the passwords, and offer >> suggestions for stronger passwords, I think users can pick stronger >> passwords. > > I think you're being *very* optimistic there. Which is why I'd rather passwords be generated. Give the user no choice. >> But I can assure you that users will NOT pick or use >> stronger passwords if they have to have dozens of them (again, no >> evidence, just an assertion of common sense). > > My guess is that dozens would remain the case. There > have been mega-sized password databases/login services > around for years but the number of passwords people > have has only kept increasing as far as I know. I addressed this. Any such solution will require proper integration with the browsers. If the browsers don't play along then we might as well go home. Nico -- From stephen.farrell@cs.tcd.ie Wed Jul 11 12:17: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 07CB411E8101 for ; Wed, 11 Jul 2012 12:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvrvoWV4CB1Z for ; Wed, 11 Jul 2012 12:17:14 -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 EF8AC11E80DB for ; Wed, 11 Jul 2012 12:17:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 92EAE15412F; Wed, 11 Jul 2012 20:17:44 +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=1342034264; bh=5XKhQnS8efhmlz S6sPFPctLut/fFwPjIHTEG/en0bNw=; b=mr8w9DhzBgdK/piWRfvEIHHBW4hDV9 8nx2xd20AvAk+pQsLsXkx6MlhBDvHPoRR/e7wsA0eMdLcUiLBIcGmAgm04Ge/maJ HIGi+8oDXID8nj7MCeQ5t4K3Y+rZQNltIBu39sxw5RFkQp0BnEH57soCDQ7roj9Z +3sVf677u719kqFddVDG3ljCxRCYh4Js/c4osS9MqMVddbZPW8/Cd8dxYD+8EzAd zlq0qmywBUYRdNHS0RMkdXcZACDM64IkN/w/mdFdUTEbJwLOgwzNQkIUgpVBXFo/ nt0/DUL4WSH3tpaRppLOgK0rx7TOKmdEDHUT7MxwtAA8YCJRLg6dZIsQ== 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 YN9SbQGea3xR; Wed, 11 Jul 2012 20:17:44 +0100 (IST) Received: from [10.87.48.11] (unknown [86.44.69.125]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 1B24515412D; Wed, 11 Jul 2012 20:17:44 +0100 (IST) Message-ID: <4FFDD157.1060208@cs.tcd.ie> Date: Wed, 11 Jul 2012 20:17:43 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Nico Williams References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> <4FFDB9B3.6050008@cs.tcd.ie> <4FFDC4BC.9000406@cs.tcd.ie> <4FFDCE03.6010009@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 11 Jul 2012 19:17:15 -0000 On 07/11/2012 08:09 PM, Nico Williams wrote: > On Wed, Jul 11, 2012 at 2:03 PM, Stephen Farrell > wrote: >> On 07/11/2012 07:47 PM, Nico Williams wrote: >>> No need for evidence, >> >> I disagree. We ought be able to quote numbers here >> since we've been doing web authentication at scale >> for over a decade now, so many variants of password >> scheme have already been tried. > > I call foul. Breaking up the quote like you did makes it look like I > said something entirely different from what I actually wrote. Sorry. But honestly we really oughtn't have to depend solely on intuition here and I wanted to emphasise that. >>> just don't let the user pick the password: >>> generate the passwords for them and tell them to write them down. >> >> I think that fails on usability grounds to be honest. >> I guess there may be figures for how many people let >> Ubuntu generate good passwords, but I suspect its >> a small percentage. > > The key word is "let". Also, local passwords are a different beast, > so I don't think Ubuntu stats here would help the analysis. Well, if the argument is about password strength then I would think it'd be just as good a metric of adoption. I can't see that users behaviour will depend on the whether or not the password is sent in a protocol. (It probably does depend on how important they perceive the service for a good chunk of users.) But any source for credible evidence would be fine, and I'm sure there are more. >>> Also, even if you let them pick their passwords, fewer passwords will >>> not likely lead to the user picking worse ones than before (it's >>> always possible, I suppose, but it makes no sense that they would). >> >> I didn't say the passwords chosen would be worse. I >> said I doubted they'd be any better. > > Indeed, but I think we should first see if they could be worse on the > way to arguing likelihood of improvement. If you look at lists of common passwords, its hard to imagine it could be any worse:-) S. > >>> And if you instruct the user to write down the passwords, and offer >>> suggestions for stronger passwords, I think users can pick stronger >>> passwords. >> >> I think you're being *very* optimistic there. > > Which is why I'd rather passwords be generated. Give the user no choice. > >>> But I can assure you that users will NOT pick or use >>> stronger passwords if they have to have dozens of them (again, no >>> evidence, just an assertion of common sense). >> >> My guess is that dozens would remain the case. There >> have been mega-sized password databases/login services >> around for years but the number of passwords people >> have has only kept increasing as far as I know. > > I addressed this. Any such solution will require proper integration > with the browsers. If the browsers don't play along then we might as > well go home. > > Nico > -- > > From nico@cryptonector.com Wed Jul 11 13:03: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 6157311E80F5 for ; Wed, 11 Jul 2012 13:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.113 X-Spam-Level: X-Spam-Status: No, score=-3.113 tagged_above=-999 required=5 tests=[AWL=-1.136, 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 VFF14a5+5ajb for ; Wed, 11 Jul 2012 13:03:50 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 8C76A21F8499 for ; Wed, 11 Jul 2012 13:03:50 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id D62D7678058 for ; Wed, 11 Jul 2012 13:04:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=ZeQDGl5jhZ0YBsi9jwV7x 5obnPCvOQCfIRoCKmZRlJ5RKhhFyxXcFQ0CSHRGztJigim0gI4Wqn91VN6H5NW59 +I4TRBk+PqagS3L8OFJssCRQHsuJUPUN267VWQ7WpdDlETbY5rhwJdh3IpyEr5N0 ZQIr7JQz2af8cJpMh+/ruU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=/I8EGyD6u5PeO76wKHkR YjN/oho=; b=LgRqfiCsrRg5j71LUTX2ubN3AIA4Vr14zYX4bLZELgeoztTqk/qT 1utcadN4pKsNab6T6a0SvmYVFA9VmbikYvNwY7y9kfw6HmDidTfBDqw6Md9oJSl/ MpWkFbL84/CEayyaXQZpAcTQNT3uUWqlI2dxShCG4L4EAPwsKIXd5s8= Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id B4A6E678057 for ; Wed, 11 Jul 2012 13:04:21 -0700 (PDT) Received: by yenq13 with SMTP id q13so1779149yen.31 for ; Wed, 11 Jul 2012 13:04:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.222.40 with SMTP id qj8mr81042718pbc.139.1342037060765; Wed, 11 Jul 2012 13:04:20 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Wed, 11 Jul 2012 13:04:20 -0700 (PDT) In-Reply-To: <4FFDD157.1060208@cs.tcd.ie> References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> <4FFDB9B3.6050008@cs.tcd.ie> <4FFDC4BC.9000406@cs.tcd.ie> <4FFDCE03.6010009@cs.tcd.ie> <4FFDD157.1060208@cs.tcd.ie> Date: Wed, 11 Jul 2012 15:04:20 -0500 Message-ID: From: Nico Williams To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Cc: IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 11 Jul 2012 20:03:51 -0000 On Wed, Jul 11, 2012 at 2:17 PM, Stephen Farrell wrote: > On 07/11/2012 08:09 PM, Nico Williams wrote: >> I call foul. Breaking up the quote like you did makes it look like I >> said something entirely different from what I actually wrote. > > Sorry. But honestly we really oughtn't have to > depend solely on intuition here and I wanted to > emphasise that. You can make that point without misquoting me. My point was that we don't need evidence for one particular assertion if we don't need that assertion -- a perfectly valid, logical point, even if it starts with "we don't need evidence". Where as "we don't need evidence" as a complete, stand-alone assertion, damns anyone making it. >>>> just don't let the user pick the password: >>>> generate the passwords for them and tell them to write them down. >>> >>> I think that fails on usability grounds to be honest. >>> I guess there may be figures for how many people let >>> Ubuntu generate good passwords, but I suspect its >>> a small percentage. >> >> The key word is "let". Also, local passwords are a different beast, >> so I don't think Ubuntu stats here would help the analysis. > > Well, if the argument is about password strength then > I would think it'd be just as good a metric of adoption. I don't. The user got a choice. That some/many/all users chose to pick their own may well only tell us something about user preferences for the very first password they must use and nothing at all about web authentication. Only if most/all users had picked the generated password option would that help us extrapolate to web auth. > I can't see that users behaviour will depend on the whether > or not the password is sent in a protocol. (It probably > does depend on how important they perceive the service > for a good chunk of users.) No, but it will depend on whether it's the very first one they must type, thus not subject to, e.g., password managers. >>> I didn't say the passwords chosen would be worse. I >>> said I doubted they'd be any better. >> >> Indeed, but I think we should first see if they could be worse on the >> way to arguing likelihood of improvement. > > If you look at lists of common passwords, its hard to > imagine it could be any worse:-) Right. We can't do worse. I don't think we need evidence for that particular assertion... :^) Nico -- From stephen.farrell@cs.tcd.ie Wed Jul 11 13:19: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 AC79811E80A2 for ; Wed, 11 Jul 2012 13:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0L2zVjnxTfd9 for ; Wed, 11 Jul 2012 13:19:06 -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 326B221F8555 for ; Wed, 11 Jul 2012 13:19:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id EF5B115412F; Wed, 11 Jul 2012 21:19:36 +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=1342037976; bh=ODGxgz87WyhTEU KTqt3gtbMcWdyCPrMY/GbP9y1rSNU=; b=2MmDj5AsB0P0JteFDhTts0yvriOWmK kuIIHynVPynFy8wsJdvWwBSQgpDOyTys4TuRzMh3bNbIEbkZzm3oPtwrFKe4YO9d RYzA37zdubLJgqgxUJssk+LCKDm/5M4h0KYD4XeibHyXovLSET+o05Jtns4ut8ok a/k9gEspP4rf0WnuDKSoNP3i3umZ/4SKup+YTdXDMisg2B8ZombSlz9d7PWTqKWH UjIBCib8HLupIpA4Gte8mQwHxZpX2CEngyq5o77jD0p2+H3DyPOdn5Oc7Jaz4eum mQmT5rUwKXrwXEs3RE84NKyICLAcc6Ags2BepQSmlREbK/crRaLPM3kA== 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 JZvyv+s0ciuW; Wed, 11 Jul 2012 21:19:36 +0100 (IST) Received: from [10.87.48.11] (unknown [86.44.69.125]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 72E1715412D; Wed, 11 Jul 2012 21:19:36 +0100 (IST) Message-ID: <4FFDDFD8.9020300@cs.tcd.ie> Date: Wed, 11 Jul 2012 21:19:36 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Nico Williams References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> <4FFDB9B3.6050008@cs.tcd.ie> <4FFDC4BC.9000406@cs.tcd.ie> <4FFDCE03.6010009@cs.tcd.ie> <4FFDD157.1060208@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 11 Jul 2012 20:19:10 -0000 On 07/11/2012 09:04 PM, Nico Williams wrote: > On Wed, Jul 11, 2012 at 2:17 PM, Stephen Farrell > wrote: >> On 07/11/2012 08:09 PM, Nico Williams wrote: >>> I call foul. Breaking up the quote like you did makes it look like I >>> said something entirely different from what I actually wrote. >> >> Sorry. But honestly we really oughtn't have to >> depend solely on intuition here and I wanted to >> emphasise that. > > You can make that point without misquoting me. Again, sorry. I really wasn't trying to misquote you but I continue to think that we can and ought have more backing than just intuition for the kind of assertion you made earlier. > My point was that we don't need evidence for one particular assertion > if we don't need that assertion -- a perfectly valid, logical point, > even if it starts with "we don't need evidence". Where as "we don't > need evidence" as a complete, stand-alone assertion, damns anyone > making it. Fair enough. I can agree that if never let uses choose passwords then stronger passwords can be given to users. That's clearly true. I don't agree that that's a good basis on which to figure out what to do though. S > >>>>> just don't let the user pick the password: >>>>> generate the passwords for them and tell them to write them down. >>>> >>>> I think that fails on usability grounds to be honest. >>>> I guess there may be figures for how many people let >>>> Ubuntu generate good passwords, but I suspect its >>>> a small percentage. >>> >>> The key word is "let". Also, local passwords are a different beast, >>> so I don't think Ubuntu stats here would help the analysis. >> >> Well, if the argument is about password strength then >> I would think it'd be just as good a metric of adoption. > > I don't. The user got a choice. That some/many/all users chose to > pick their own may well only tell us something about user preferences > for the very first password they must use and nothing at all about web > authentication. Only if most/all users had picked the generated > password option would that help us extrapolate to web auth. > >> I can't see that users behaviour will depend on the whether >> or not the password is sent in a protocol. (It probably >> does depend on how important they perceive the service >> for a good chunk of users.) > > No, but it will depend on whether it's the very first one they must > type, thus not subject to, e.g., password managers. > >>>> I didn't say the passwords chosen would be worse. I >>>> said I doubted they'd be any better. >>> >>> Indeed, but I think we should first see if they could be worse on the >>> way to arguing likelihood of improvement. >> >> If you look at lists of common passwords, its hard to >> imagine it could be any worse:-) > > Right. We can't do worse. I don't think we need evidence for that > particular assertion... :^) > > Nico > -- > > From nico@cryptonector.com Wed Jul 11 13:47: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 10A2D11E80E3 for ; Wed, 11 Jul 2012 13:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.089 X-Spam-Level: X-Spam-Status: No, score=-3.089 tagged_above=-999 required=5 tests=[AWL=-1.112, 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 scGV3nmo7aIg for ; Wed, 11 Jul 2012 13:47:30 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 839D411E80BD for ; Wed, 11 Jul 2012 13:47:30 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id BAE96318065 for ; Wed, 11 Jul 2012 13:48:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=STP8L9aTWNTBsbefu5ObG fJ9ilgc/awPhLp4/l4lk1C11tRSndAi+rTp7HHBDpaawHzEagjEGBks3mh/oUe8b KaqcxSPsKvrmFQTBgx4CnOQEAA2677V2LEWNPkr/NoZ2LxfB/k3agDwgOz51Z8Qy 9hl9tWi3YzU0bHUNt4Q7Ds= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=SmKasUrMtaAPscmuG+/T Z2yiwLs=; b=Y2uOOkrtZ1rpx1uWcFVTSfSabMF922y+NFgB2ORIXQU4K+xxbqxb 3pF1vSwCaEpFK0XKeNFVFtLPOEvWwIkFDxdFUnBDYRmr/Wwz64qP8HzM5oqP1jSp p+wGPEN95dzoW05hpTArjKnSs7be0IcrQ703ygn2jorLatIu/CUjad8= Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 8538131805D for ; Wed, 11 Jul 2012 13:48:01 -0700 (PDT) Received: by yhfs35 with SMTP id s35so2565602yhf.27 for ; Wed, 11 Jul 2012 13:48:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.75.225 with SMTP id f1mr83038500paw.35.1342039680557; Wed, 11 Jul 2012 13:48:00 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Wed, 11 Jul 2012 13:48:00 -0700 (PDT) In-Reply-To: <4FFDDFD8.9020300@cs.tcd.ie> References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> <4FFDB9B3.6050008@cs.tcd.ie> <4FFDC4BC.9000406@cs.tcd.ie> <4FFDCE03.6010009@cs.tcd.ie> <4FFDD157.1060208@cs.tcd.ie> <4FFDDFD8.9020300@cs.tcd.ie> Date: Wed, 11 Jul 2012 15:48:00 -0500 Message-ID: From: Nico Williams To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Cc: IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 11 Jul 2012 20:47:31 -0000 On Wed, Jul 11, 2012 at 3:19 PM, Stephen Farrell wrote: >> You can make that point without misquoting me. > > Again, sorry. NP. > I can agree that if never let uses choose passwords > then stronger passwords can be given to users. That's > clearly true. I don't agree that that's a good basis > on which to figure out what to do though. Well, I want to distinguish device passwords from all others. Given that distinction the next question is: can generated passwords be made usable? I think the answer is: a) only if there are few such passwords for any given user, b) only if they rarely have to enter them. If not, forget it. Keep in mind that (b) is probably the most important factor because I suspect that having to enter passwords frequently leads users to picking short, easy to type passwords. I have no data to back up that suspicion, just my intuition. I suppose I should go find some professor at the local university whom I might con into conning some graduate students into doing a study about this. Or maybe we can find existing studies. But note that this is a difficult study proposition as it requires monitoring and testing the habits of study participants, as opposed to merely studying a leaked password hash DB. Nico -- From stephen.farrell@cs.tcd.ie Wed Jul 11 14: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 D940B11E80EC for ; Wed, 11 Jul 2012 14:25:29 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbnn3dzTlxUv for ; Wed, 11 Jul 2012 14:25:29 -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 BD38111E80EA for ; Wed, 11 Jul 2012 14:25:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id DAA1815412F; Wed, 11 Jul 2012 22:25:57 +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=1342041957; bh=0a5TbIPXzwwm4r i8zrMTRGeqbW5fsAYYwAC3+gURS9A=; b=jGdVWoESMNMc27Pt9BIWEWfvwOrPMH Zc0NMr1KKFeGw5wCnuHQIiABZhz/NJwPGojqsdEWvgtaEJZzx7QjA33J8vNxR8lC uX2ruz+HFIG8gv2YmZg5HED0lFv/ml/9Abf0Mq8BXK9w2vS+qynYWLdKT+ZXpEP4 ZX9AWGK1GCbS39LI8jFwaua9Z/OsexR0rwsK4GBk/b7YY3SCqotUn33Yd2CxkDMF l8wKnGSp2/fb7dOBtpM3+6RUlMLtP3lbrKCh2wycV9mEXP/IKD3g4NVmH3M4m2v6 /SFfuHqqAETFZ6Mu58z2rYrqJo5oiWg7goipnk6BH0XI+FQUOd6787kw== 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 gwCyHt0vecss; Wed, 11 Jul 2012 22:25:57 +0100 (IST) Received: from [10.87.48.11] (unknown [86.42.30.229]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 4270415412D; Wed, 11 Jul 2012 22:25:56 +0100 (IST) Message-ID: <4FFDEF64.9040508@cs.tcd.ie> Date: Wed, 11 Jul 2012 22:25:56 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Nico Williams References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> <4FFDB9B3.6050008@cs.tcd.ie> <4FFDC4BC.9000406@cs.tcd.ie> <4FFDCE03.6010009@cs.tcd.ie> <4FFDD157.1060208@cs.tcd.ie> <4FFDDFD8.9020300@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 11 Jul 2012 21:25:30 -0000 To be honest, I think that spending a lot of effort on this is not very worthwhile until someone's done the work you describe below and come back with a design and some evidence that its worthwhile. My (admittedly biased) intuition is that it'll amount to no more than tinkering at the edges in terms of overall system and Internet security. If current proportions of bad passwords continue to be shared over O(10) [1] sites and if databases continue to leak then I don't see that adding a few large scale SSO services helps very much. But I'd love to see the evidence that it might. And of course, such large services would be very attractive targets for all the usual suspects. And DB leak events have a lot of associated costs, both for the site that's leaked its DB, for its users and for other sites where those users have accounts and for the general perception of the security of the network. Overall, I think its just compelling to try to get rid of that leaked-password-database threat via signatures. (As in hoba or whatever.) Its not a panacea, but is entirely worth trying. S. PS: The above are (I hope obviously) personal views. If there's consensus in some wg to do work such as you envisage, my personal views won't get in the way of that. Put another way: requiring the evidence is not part of IETF process, and I'm not trying to make it so. But it is part of arguing:-) [1] http://wwwconference.org/www2007/papers/paper620.pdf On 07/11/2012 09:48 PM, Nico Williams wrote: > On Wed, Jul 11, 2012 at 3:19 PM, Stephen Farrell > wrote: >>> You can make that point without misquoting me. >> >> Again, sorry. > > NP. > >> I can agree that if never let uses choose passwords >> then stronger passwords can be given to users. That's >> clearly true. I don't agree that that's a good basis >> on which to figure out what to do though. > > Well, I want to distinguish device passwords from all others. Given > that distinction the next question is: can generated passwords be made > usable? I think the answer is: a) only if there are few such > passwords for any given user, b) only if they rarely have to enter > them. If not, forget it. Keep in mind that (b) is probably the most > important factor because I suspect that having to enter passwords > frequently leads users to picking short, easy to type passwords. I > have no data to back up that suspicion, just my intuition. I suppose > I should go find some professor at the local university whom I might > con into conning some graduate students into doing a study about this. > Or maybe we can find existing studies. But note that this is a > difficult study proposition as it requires monitoring and testing the > habits of study participants, as opposed to merely studying a leaked > password hash DB. > > Nico > -- > From nico@cryptonector.com Wed Jul 11 14:48: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 8A18D21F8508 for ; Wed, 11 Jul 2012 14:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.067 X-Spam-Level: X-Spam-Status: No, score=-3.067 tagged_above=-999 required=5 tests=[AWL=-1.090, 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 C9jcD5N0e4Yq for ; Wed, 11 Jul 2012 14:48:54 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 104B821F84FF for ; Wed, 11 Jul 2012 14:48:54 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id 8E30126C06F for ; Wed, 11 Jul 2012 14:49:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=S5aD33gBmDEQr1dSd6AsY RB4sCTYcX18EP8wuZZig+wjf8bQ2CGhY/dfswlsZYhz86xKh1ZQMahxmZx5jAWgV MrThaPt/vR0NM6aGiQcZsDIJKlk5PULuN1TQnY4iNB1NiixTLx5zqeBFqzdl50dN XzqH5TsHV+yaZBBOtUCMJI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=5RcnsNl0OH1Fl38+iQQ6 f/dtGoE=; b=RpvHv4WR2lVgU1rBXEsswbdOtqo6SRHj9EtnNPG4+kEsY/ez8s87 /PatsQ6izVKBZckzI7tnTbaUI2NIrqSlocZMa0V2dUugw9sO+qL4a9GXR+PjgYh5 xo6ysf1nxvFmGVUsYuG6ifJsQY+mUIHvPJWowMPX/O6CpwiHZXYSqmw= Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPSA id 64EEA26C069 for ; Wed, 11 Jul 2012 14:49:25 -0700 (PDT) Received: by yhfs35 with SMTP id s35so2648104yhf.27 for ; Wed, 11 Jul 2012 14:49:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.74.69 with SMTP id r5mr84855754pav.56.1342043364612; Wed, 11 Jul 2012 14:49:24 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Wed, 11 Jul 2012 14:49:24 -0700 (PDT) In-Reply-To: <4FFDEF64.9040508@cs.tcd.ie> References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> <4FFDB9B3.6050008@cs.tcd.ie> <4FFDC4BC.9000406@cs.tcd.ie> <4FFDCE03.6010009@cs.tcd.ie> <4FFDD157.1060208@cs.tcd.ie> <4FFDDFD8.9020300@cs.tcd.ie> <4FFDEF64.9040508@cs.tcd.ie> Date: Wed, 11 Jul 2012 16:49:24 -0500 Message-ID: From: Nico Williams To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Cc: IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 11 Jul 2012 21:48:54 -0000 But I don't see passwords going away, at least for account recovery purposes. HOBA is nice, but it can't be the sole solution. From stephen.farrell@cs.tcd.ie Wed Jul 11 14:51: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 16C2A21F866A for ; Wed, 11 Jul 2012 14:51:34 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nw+v2RTKcMgd for ; Wed, 11 Jul 2012 14:51:33 -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 C04D121F84FF for ; Wed, 11 Jul 2012 14:51:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id E0D7B15412F; Wed, 11 Jul 2012 22:52:03 +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=1342043523; bh=+eCO5/SDTwHF7Y d7W6uXs3u97cO4/gca+upFMcD1/p4=; b=aK+omwTuk4KfffbPJwYPtFgepJbnRO hPgrpwXK/Rlk1uv/CEFx6c3Cp1i3xutWDOlF0QabrSfAhN+Imhd+qEV3cWsmIKSo tKHnAsYSTerBZ5TPu1EBEHq+LpGvsKwdjVS7O3bRE2TVep8SY9WYb0lqvj6SjIee u3N2RAhVeYGcei7rgdyIzQ+tGxEJmBcZysudzKQGzVRNFfrGKfwAswUlm7FqRUDU AgxeCdu+K2GvPhGX/oLevIbgIiYivUE8zTqrFsEAU3tWfGR3nP8b+R0Iqmw26PMG VzQUogESNU3y5W4W16MEeCVNQvg3F2bSTyviZn+XynmFZJ1R8PybG1sA== 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 c7QLsvxzEVh2; Wed, 11 Jul 2012 22:52:03 +0100 (IST) Received: from [10.87.48.11] (unknown [86.42.30.229]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 0CCF815412D; Wed, 11 Jul 2012 22:52:03 +0100 (IST) Message-ID: <4FFDF582.8040305@cs.tcd.ie> Date: Wed, 11 Jul 2012 22:52:02 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Nico Williams References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> <4FFDB9B3.6050008@cs.tcd.ie> <4FFDC4BC.9000406@cs.tcd.ie> <4FFDCE03.6010009@cs.tcd.ie> <4FFDD157.1060208@cs.tcd.ie> <4FFDDFD8.9020300@cs.tcd.ie> <4FFDEF64.9040508@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 11 Jul 2012 21:51:34 -0000 On 07/11/2012 10:49 PM, Nico Williams wrote: > But I don't see passwords going away, at least for account recovery > purposes. HOBA is nice, but it can't be the sole solution. When did *anyone* propose that? S. From nico@cryptonector.com Wed Jul 11 14:52:33 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 46DF121F867B for ; Wed, 11 Jul 2012 14:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[AWL=-1.069, 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 HwIVlDERd1wJ for ; Wed, 11 Jul 2012 14:52:31 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBAA21F8671 for ; Wed, 11 Jul 2012 14:52:31 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTP id 051647E4062 for ; Wed, 11 Jul 2012 14:53:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=cyxX6NxYOM3wycXFA9A8r 5Lsm0MMKywgdbolzVuVFN7N1e3OtfynaNBb1/k/SxwpGKXeqbgbTHM+LxB5V7u2C 3w0TRCBi7yJJggFHZcl+zxGx/hfMAq77PVHvb5NQ7bgNTEobT2CAG6xMQk3CqaOP cJWR66kL73khtFe9/HQCv4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=iYE40a05xp2MdUbO2q36 sfXd/Fk=; b=UDqArTES/uymK1R6T1hqKs+dlKwAvtrZMXLagcbg6N7e7uKi4pqB U1oRPjkyhub+uGoHA16Zm3uYQSybMFf5WXSfMdcwIJA6HXK0hH651pdOH2l4ubeG 13FNI59Y5liqY1C0HU2ErmbnyYnZgZBvC4XquQpopK/NZsKvGpxo5+Y= Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTPSA id CFE9E7E4058 for ; Wed, 11 Jul 2012 14:53:02 -0700 (PDT) Received: by ggnc4 with SMTP id c4so1899962ggn.31 for ; Wed, 11 Jul 2012 14:53:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.75.168 with SMTP id d8mr84776748paw.63.1342043581655; Wed, 11 Jul 2012 14:53:01 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Wed, 11 Jul 2012 14:53:01 -0700 (PDT) In-Reply-To: <4FFDF582.8040305@cs.tcd.ie> References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> <4FFDB9B3.6050008@cs.tcd.ie> <4FFDC4BC.9000406@cs.tcd.ie> <4FFDCE03.6010009@cs.tcd.ie> <4FFDD157.1060208@cs.tcd.ie> <4FFDDFD8.9020300@cs.tcd.ie> <4FFDEF64.9040508@cs.tcd.ie> <4FFDF582.8040305@cs.tcd.ie> Date: Wed, 11 Jul 2012 16:53:01 -0500 Message-ID: From: Nico Williams To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Cc: IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 11 Jul 2012 21:52:33 -0000 On Wed, Jul 11, 2012 at 4:52 PM, Stephen Farrell wrote: > On 07/11/2012 10:49 PM, Nico Williams wrote: >> But I don't see passwords going away, at least for account recovery >> purposes. HOBA is nice, but it can't be the sole solution. > > When did *anyone* propose that? Dunno that anyone did. Just that we still need to do something about passwords that isn't avoiding passwords. Nico -- From stephen.farrell@cs.tcd.ie Wed Jul 11 15:05: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 307F911E811E for ; Wed, 11 Jul 2012 15:05:18 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3h+SWSRSzTIT for ; Wed, 11 Jul 2012 15:05:16 -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 6D23A11E810F for ; Wed, 11 Jul 2012 15:05:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 9410415412F; Wed, 11 Jul 2012 23:05:47 +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=1342044347; bh=P8hCZjYkf8Ag3r 1W2WJeK3WpQrr+/b1augwvlVGmxCs=; b=cS9sYDauV3vWPgk0L91iYqQ4yI6D+u 4zJrWCl86+6IRPHB+jPGNyZA7aHeJH/ATMMk9sZb5t2ZNfheJc1uNPfJ+COF2/SY i9ZmnbxaaUGu9r2n5K1Oo2a7TlrALdzJHl+3rZrWkKy/U239GxOljBa96N4kYIaG X+WnvMgKicN81SXXOaIydTHN7JUSUqfDNGp6mYwh59YzIrxSspjIcXCdBwuNjhLj YuOySu412rnZePmMd8UucgYOuij+u5KPxp2OgYY2YaKKp2AVds2DZPYeYxX2s6YD +3JGNpuQI5A1St00KVJMai4Otp3HLn/OI/RPt9jnjFeiqFsHo/mcMCtA== 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 k6UjEs69-2Da; Wed, 11 Jul 2012 23:05:47 +0100 (IST) Received: from [10.87.48.11] (unknown [86.42.30.229]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 3F52015412D; Wed, 11 Jul 2012 23:05:47 +0100 (IST) Message-ID: <4FFDF8BA.8080505@cs.tcd.ie> Date: Wed, 11 Jul 2012 23:05:46 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Nico Williams References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> <4FFDB9B3.6050008@cs.tcd.ie> <4FFDC4BC.9000406@cs.tcd.ie> <4FFDCE03.6010009@cs.tcd.ie> <4FFDD157.1060208@cs.tcd.ie> <4FFDDFD8.9020300@cs.tcd.ie> <4FFDEF64.9040508@cs.tcd.ie> <4FFDF582.8040305@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 11 Jul 2012 22:05:18 -0000 On 07/11/2012 10:53 PM, Nico Williams wrote: > On Wed, Jul 11, 2012 at 4:52 PM, Stephen Farrell > wrote: >> On 07/11/2012 10:49 PM, Nico Williams wrote: >>> But I don't see passwords going away, at least for account recovery >>> purposes. HOBA is nice, but it can't be the sole solution. >> >> When did *anyone* propose that? > > Dunno that anyone did. Then I'm puzzled. But whatever. > Just that we still need to do something about > passwords that isn't avoiding passwords. FWIW, I'm not at all convinced of that, if by "do something" you mean "improve security" or some equivalent. I don't buy that there's a great security justification for such work since I suspect that it won't change the overall situation much, even if deployed on a medium-large scale. Again, I'd be happy to be convinced otherwise (by evidence:-). There may well however probably good protocol or engineering reasons for work related to password auth in e.g. http/2.0 that independently justify that effort, but that's another discussion, that isn't and doesn't need to be, driven by improving the security situation. S > > Nico > -- > > From nico@cryptonector.com Wed Jul 11 15:11: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 CF1C011E80FB for ; Wed, 11 Jul 2012 15:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.081 X-Spam-Level: X-Spam-Status: No, score=-3.081 tagged_above=-999 required=5 tests=[AWL=-1.104, 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 L8SiAOC5Kaae for ; Wed, 11 Jul 2012 15:11:28 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 5F22811E810F for ; Wed, 11 Jul 2012 15:11:28 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id E33AB9406B for ; Wed, 11 Jul 2012 15:11:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=fh6GJ7W8oAIbeBEoKCDba BLNfJPTx8CYoV4vRTDAiKvVi6+upqWGqN2TMdEGyZ4ieMWcvP2M2e3D1XLF/12v0 aI6rx5dISQ1ZpPT+eOooxCD2ThBd+7ND9qnBOUcH4esBKtz6dw90T+rnMg+2xKEj vSP8W1H3k3o2q/y21vrXaQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=QlaDps9yFbGRYcpFyZOZ Tc+A0Xk=; b=fxKBtH8dhfXJlJ+85zKkg5xEc/e7Jh3X5z3CRc6gUO2+TMp/nIeQ KFiny/hjNh1DZNCfFqkI4G1epa19S/W5MUAKH+SkbNvwlaDxTDjSFfqBuV2vTd4E bE7po+6J40/NXGo0kC2EF4p1q+V4X8DmMXvUwfoNU17jHF8G4vEgbAw= Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id BBDBD9405E for ; Wed, 11 Jul 2012 15:11:59 -0700 (PDT) Received: by ggnc4 with SMTP id c4so1916859ggn.31 for ; Wed, 11 Jul 2012 15:11:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.75.71 with SMTP id a7mr84981944paw.48.1342044718835; Wed, 11 Jul 2012 15:11:58 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Wed, 11 Jul 2012 15:11:58 -0700 (PDT) In-Reply-To: <4FFDF8BA.8080505@cs.tcd.ie> References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> <4FFDB9B3.6050008@cs.tcd.ie> <4FFDC4BC.9000406@cs.tcd.ie> <4FFDCE03.6010009@cs.tcd.ie> <4FFDD157.1060208@cs.tcd.ie> <4FFDDFD8.9020300@cs.tcd.ie> <4FFDEF64.9040508@cs.tcd.ie> <4FFDF582.8040305@cs.tcd.ie> <4FFDF8BA.8080505@cs.tcd.ie> Date: Wed, 11 Jul 2012 17:11:58 -0500 Message-ID: From: Nico Williams To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Cc: IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 11 Jul 2012 22:11:34 -0000 On Wed, Jul 11, 2012 at 5:05 PM, Stephen Farrell wrote: > There may well however probably good protocol or > engineering reasons for work related to password > auth in e.g. http/2.0 that independently justify > that effort, but that's another discussion, that > isn't and doesn't need to be, driven by improving > the security situation. Well, certainly for corporate environments we need GSS/Kerberos (and other) support. But I still think we'll need something like GSS/Kerberos or GSS/ABFAB on the web at large. Nico -- From hallam@gmail.com Wed Jul 11 18:06: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 816B211E80D6 for ; Wed, 11 Jul 2012 18:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.569 X-Spam-Level: X-Spam-Status: No, score=-4.569 tagged_above=-999 required=5 tests=[AWL=-0.970, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00hH6VqB2rJ6 for ; Wed, 11 Jul 2012 18:06:44 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B3C8611E80CA for ; Wed, 11 Jul 2012 18:06:44 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2542310obb.31 for ; Wed, 11 Jul 2012 18:07:16 -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=wcDdTh/1yHRLMHUCjWjfJ/43DdZm3fzrEa9LXYrRk0Y=; b=U9AK0Xj4JKuIZLpMDrJq4+bmBT/5vKlI8yQwt0BkAp/g+ZoBKlFPTuhz8q7oCbic18 XvZbr4GaOgoncfYh4rAs0bMfZoUInyzhjTSj4VcTL35/cbcGl1BcgK1VXWnSwtSfCIRN N+cva76SkX3BP2HZoacl7VprjzI+KLTqI62DMvHmqd7DOjTb4JK/H8RP5BN/9Y1TBsrE hLNmkPQayL5tF9fOvEOGZKSQgDUsnyITnz1eL5iYHmeAuYCKQeKj/d/UF2tKTqvLLCj+ Bxl6yUWo3tctv6f8QRvZwL4DGmWR7jw1/XpC+IaW+YU5yYK9elgvgufwQMozce5lSiw/ Xm+Q== MIME-Version: 1.0 Received: by 10.60.1.40 with SMTP id 8mr52403597oej.70.1342055236313; Wed, 11 Jul 2012 18:07:16 -0700 (PDT) Received: by 10.76.120.110 with HTTP; Wed, 11 Jul 2012 18:07:16 -0700 (PDT) Date: Wed, 11 Jul 2012 21:07:16 -0400 Message-ID: From: Phillip Hallam-Baker To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [saag] How long should a MAC be? 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, 12 Jul 2012 01:06:45 -0000 Yeah, yeah, digests, birthday attack, yadda yadda. But! A MAC is not a digest, it is an authentication mechanism. If I use HMAC-SHA256 with a 128 bit key, I am going to have no more than 128 bits of ergodicity in my output. So what is the justification for presenting more than 128 bits? Now I guess someone can argue (OK they will) that HMAC-SHA256 with a 256 bit key produces a full 256 bits of ergodicity in the output. But given that we have agreed on 128 bits as 'sufficient' for encryption keys (well for the lifetime of this universe at least) why then demand up to 512 for authentication? I know that there are perfectly good reasons for using AES-256, it is not really the possibility of brute forcing the key that is the issue so much as the fact that AES-512 has many more rounds than AES-128 and is stronger. And when someone like Adi Shamir suggests AES might be a little over-optimized, well I listen. What this comes down to is that I think we need a HMAC-SHA128 and maybe people who are really looking for 256 bits of authentication should be cutting HMAC-SHA512 in two... Just a thought. -- Website: http://hallambaker.com/ From ekr@rtfm.com Wed Jul 11 18:37: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 464CF11E80D6 for ; Wed, 11 Jul 2012 18:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.806 X-Spam-Level: X-Spam-Status: No, score=-102.806 tagged_above=-999 required=5 tests=[AWL=0.171, 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 oNC8XDgS0Kaa for ; Wed, 11 Jul 2012 18:37:23 -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 5823E11E80C9 for ; Wed, 11 Jul 2012 18:37:23 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1254622vbb.31 for ; Wed, 11 Jul 2012 18:37:55 -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:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=tuLOlDLYLSkBVLPKUh/kIXhplBPDvzIR+UX5xxV4+Bc=; b=JuEsc50VpMwn1W22P58Cz+t423amGYQ67Prk5TAF5sWiHcqnwckFo73lqWXGBfV6g0 YkhWM6ZNni/43jL0lfrOuzWL3FmLrxD/yLyogj+mmCiYoskQG5lCu1G0tppoVVtRivd/ oV5vz+vLkQNIzLRm5SaCsTyGbrKiJzv1ge0/tubuoO8s8tg4hVUlISD1rSCPUENGFJvY jJDHyAL7xWGGV29lxNj1JjSdKapLSL5+ke88+DMmaJaKeiEsH0PmfrBurtI6h+McSvwr DAHcwWwZzPdOXKqeffoT4WXCd5NVYiiC2nyxPe/1gcfzvcI381aZx4HEJ3zZvxGIkX3U UogA== Received: by 10.52.156.47 with SMTP id wb15mr21045813vdb.53.1342057074882; Wed, 11 Jul 2012 18:37:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Wed, 11 Jul 2012 18:37:14 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: From: Eric Rescorla Date: Wed, 11 Jul 2012 18:37:14 -0700 Message-ID: To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkxqcULwCTrCWTJKnMJB9oRaSJmlWcY325WPOwu+qbbs/z85aVTQjoFZBuo3Yx7wHIMYB9i Cc: saag@ietf.org Subject: Re: [saag] How long should a MAC be? 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, 12 Jul 2012 01:37:25 -0000 On Wed, Jul 11, 2012 at 6:07 PM, Phillip Hallam-Baker wrote: > Yeah, yeah, digests, birthday attack, yadda yadda. > > But! A MAC is not a digest, it is an authentication mechanism. If I > use HMAC-SHA256 with a 128 bit key, I am going to have no more than > 128 bits of ergodicity in my output. So what is the justification for > presenting more than 128 bits? I am unaware of one, provided, of course, that the MAC is in fact as strong as its output length. Obviously, if there are weaknesses in the MAC, all bets are off. Certainly one could design MACs that were secure at 256 bits but not 128 [0] but I don't know of any evidence that HMAC-SHA256 is such a MAC. -Ekr [0] Consider the MAC HMAC-SHA-256X which is produced by taking the HMAC-SHA256 output and zeroing the first 128 bits. From nico@cryptonector.com Wed Jul 11 18:49: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 BDC6911E80E5 for ; Wed, 11 Jul 2012 18:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.165 X-Spam-Level: X-Spam-Status: No, score=-3.165 tagged_above=-999 required=5 tests=[AWL=-1.188, 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 SSq8wTc3nzMQ for ; Wed, 11 Jul 2012 18:49:10 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 904FD11E80A3 for ; Wed, 11 Jul 2012 18:49:10 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 67CA336006B for ; Wed, 11 Jul 2012 18:49:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=EYnsNXA7ShSK9ZkhfF1mf 1XdfHwNRyvmAetyb8394UFkKyMu4wCfGZ9iBbFaWIUQCfcDILugz0SuMSISOZZgr 0MoxELwkd2dI3cJekBPOoO0ji9wo62h++JzDPjRtbM8s1EwXfNTVviM3mCZBiUPM 6KesKt67WFIT2mB+YGsznM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=62AgTu+VAIaO1ft/bWwL ozkqw7M=; b=ffr8yvsCi1LUsEidRULSThHYfI1xh5QgT8e0X4dNemXUcXLj7kW8 b9bM5XOTSKmqv1hGfHiUsWhMkqrlKaD0LJb/i2a1Qi97vqeNdtxA2SpRwkycQVks fqUbwVS0Tu6uylMG0eFNxahyw7Cj+ib6z30c7XgodOCb2MVn5nH8atY= Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id 4A1B836006A for ; Wed, 11 Jul 2012 18:49:42 -0700 (PDT) Received: by ggnc4 with SMTP id c4so2054264ggn.31 for ; Wed, 11 Jul 2012 18:49:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.83.39 with SMTP id n7mr1429408pay.82.1342057781180; Wed, 11 Jul 2012 18:49:41 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Wed, 11 Jul 2012 18:49:41 -0700 (PDT) In-Reply-To: References: Date: Wed, 11 Jul 2012 20:49:41 -0500 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Cc: saag@ietf.org Subject: Re: [saag] How long should a MAC be? 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, 12 Jul 2012 01:49:11 -0000 Phillip, Kerberos uses 96-bit HMAC-SHA1 for the AES 'enctypes' (ciphersuites). See RFC3962, where nothing much is said about the MAC length (but RFC2104 does have text on truncation of HMAC); you might want to ask the authors of RFC3962 and/or other RFCs that also use truncated MACs. In order to foil a MAC (forge a message) an attacker would have to compute not only a modification of the MACed text that collides with the original, but collides with the original under the same secret key presumed not known to the attacker. Moreover, an attack on the MAC is requires interaction with the receiver, while hash collision attacks are off-line. This is much harder than looking for a mere hash collision. Also there's no question of recovering plaintext from the MAC (particularly if you encrypt-then-MAC) without pre-image attacks, and as long as the MAC and encrypt keys are not the same (such that key recovery attacks on the MAC can't be used to attack the ciphertext). I think this means that effective MAC sizes can be somewhat shorter than the MAC keys, at least if what you're concerned about is forgeries. As for key recovery attacks, any such attack with less complexity than forgery will be... a better forgery attack in the first place; on the flip side forgery attacks facility better-than-brute-force key recovery attacks, so the key had better not be the same as, say, encryption keys. The active forgery attacks on HMAC require 2^(L/2) messages assuming a strong hash function and where L is the hash output length in bits, which I think means you want L to be longer than 64 bits. In some protocols (if you re-key often, say) I think you can get away with significantly shorter MACs, and UMAC-32 has been used. In short, yes, I think you can get away with shorter-than-key-length MACs, and still retain meaningful security, with the caveats that MAC keys should be different from encryption keys, and if the MAC is really short, then you should probably have additional defenses in the protocol and/or implementation to protect against active forgery attacks. Nico -- From Josh.Howlett@ja.net Wed Jul 11 19:30: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 6745A11E810F for ; Wed, 11 Jul 2012 19:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.855 X-Spam-Level: X-Spam-Status: No, score=-101.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, 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 BBQkYEkauCi2 for ; Wed, 11 Jul 2012 19:30:31 -0700 (PDT) Received: from egw002.ukerna.ac.uk (egw002.ukerna.ac.uk [194.81.3.65]) by ietfa.amsl.com (Postfix) with ESMTP id 65A5011E80FA for ; Wed, 11 Jul 2012 19:30:31 -0700 (PDT) Received: from egw002.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 5A51320C7169_FFE36E5B; Thu, 12 Jul 2012 02:31:01 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw002.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id AACBF20C711C_FFE36E4F; Thu, 12 Jul 2012 02:31:00 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0355.002; Thu, 12 Jul 2012 03:31:00 +0100 From: Josh Howlett To: Stephen Farrell , Nico Williams Thread-Topic: [saag] The quest to replace passwords Thread-Index: AQHNXWTaTmeYN10ChkqR7Ymm7rpsjZckS/WAgAAFtACAAAdzAIAABqWAgAAEa4CAAAGWAIAAAmGAgAANBgCAAAREAIAAB/AAgAAKmQCAAPzEgA== Date: Thu, 12 Jul 2012 02:30:59 +0000 Message-ID: In-Reply-To: <4FFDEF64.9040508@cs.tcd.ie> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 12 Jul 2012 02:30:32 -0000 >If current proportions of bad passwords continue >to be shared over O(10) [1] sites and if databases >continue to leak then I don't see that adding a >few large scale SSO services helps very much. >But I'd love to see the evidence that it might. I'm not personally aware of any such evidence; but I wonder if that evidence is really necessary to move forwards. IMO we should seek to provide technologies and infrastructure that will enable the market to select between alternate authentication mechanisms (and authentication providers), and I believe that the framework-orientated approach that Nico advocates satisfies that criterion. Prescribing one or a particular set of prescribed or approved mechanisms from the ivory tower does not; consider the level of market acceptance of HTTP Basic and Digest. 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 rbarnes@bbn.com Wed Jul 11 19:58: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 047D611E80DC for ; Wed, 11 Jul 2012 19:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.559 X-Spam-Level: X-Spam-Status: No, score=-106.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GjDaB1mwivQ for ; Wed, 11 Jul 2012 19:58:36 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4AA11E80A1 for ; Wed, 11 Jul 2012 19:58:36 -0700 (PDT) Received: from [128.89.253.251] (port=62875) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sp9cJ-0000BS-Pq; Wed, 11 Jul 2012 22:58:59 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Wed, 11 Jul 2012 22:58:59 -0400 Content-Transfer-Encoding: 7bit Message-Id: <37ADA69D-F318-461A-A360-5F2049138D1B@bbn.com> References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> <4FFDB9B3.6050008@cs.tcd.ie> <4FFDC4BC.9000406@cs.tcd.ie> <4FFDCE03.6010009@cs.tcd.ie> <4FFDD157.1060208@cs.tcd.ie> <4FFDDFD8.9020300@cs.tcd.ie> <4FFDEF64.9040508@cs.tcd.ie> <4FFDF582.8040305@cs.tcd.ie> <4FFDF8BA.8080505@cs.tcd.ie> To: Nico Williams X-Mailer: Apple Mail (2.1278) Cc: IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 12 Jul 2012 02:58:37 -0000 On Jul 11, 2012, at 6:11 PM, Nico Williams wrote: > On Wed, Jul 11, 2012 at 5:05 PM, Stephen Farrell > wrote: >> There may well however probably good protocol or >> engineering reasons for work related to password >> auth in e.g. http/2.0 that independently justify >> that effort, but that's another discussion, that >> isn't and doesn't need to be, driven by improving >> the security situation. > > Well, certainly for corporate environments we need GSS/Kerberos (and > other) support. But I still think we'll need something like > GSS/Kerberos or GSS/ABFAB on the web at large. We already have a WG for that From stephen.farrell@cs.tcd.ie Thu Jul 12 03:23: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 276F621F8731 for ; Thu, 12 Jul 2012 03:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.439 X-Spam-Level: X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYvtvFksgFs7 for ; Thu, 12 Jul 2012 03:23:44 -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 69B4B21F85FC for ; Thu, 12 Jul 2012 03:23:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 046AD153C75; Thu, 12 Jul 2012 11:24:17 +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=1342088656; bh=mEPT4m9IGh7DuA xu4YjfsU7l8iCuOnEFTDcPHDeG/iY=; b=rSfyaBTalVDSfGd4VMzv6TvJ52NMM7 MipC4qahhQPjPdnEpGJpGHdJXa9HF0FQTiBFrZzLO7E3zS8hsF/7uM0tK1Zq9+iA gBXSYpL01wQLWYiN+r39FB8vmj/1N79Mh/y2uYmslLP5BuCuuYMABbGLqZwMxSTJ tqiYin/MjOi7IT6Po3r8Z/Im/wSlSKoAFYWgUEvoq94D4q8hj1M5gE0X3CwotJtN 4sxbHmZzCDaKF8zIw72u1u+Kzp9H76GnGeyBvbWugJcCo7SX8J4DvtShFlCn0+kd WZZp3wgdb/x0biL7dNwDmyzIlTPGazizr5yijAuY8yYecdkPDft1fNaA== 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 cUAxGtj-VHZv; Thu, 12 Jul 2012 11:24:16 +0100 (IST) Received: from [10.87.48.11] (unknown [86.42.30.229]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6100F153C73; Thu, 12 Jul 2012 11:24:15 +0100 (IST) Message-ID: <4FFEA5CF.2050104@cs.tcd.ie> Date: Thu, 12 Jul 2012 11:24:15 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Josh Howlett References: In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 12 Jul 2012 10:23:45 -0000 On 07/12/2012 03:30 AM, Josh Howlett wrote: > > > >> If current proportions of bad passwords continue >> to be shared over O(10) [1] sites and if databases >> continue to leak then I don't see that adding a >> few large scale SSO services helps very much. >> But I'd love to see the evidence that it might. > > I'm not personally aware of any such evidence; but I wonder if that > evidence is really necessary to move forwards. IMO we should seek to > provide technologies and infrastructure that will enable the market to > select between alternate authentication mechanisms (and authentication > providers), and I believe that the framework-orientated approach that Nico > advocates satisfies that criterion. Prescribing one or a particular set of > prescribed or approved mechanisms from the ivory tower does not; consider > the level of market acceptance of HTTP Basic and Digest. So if asking for evidence generates immediate "ivory tower" responses like this that's probably a signal of a sort;-) Like I said, there are reasons to work on frameworks like that, but that work is just not addressing the leaky password database threat, which is a real and current problem. S. > > Josh. > > > > Janet is a trading name of The JNT Association, a company limited > by guarantee which is registered in England under No. 2881024 > and whose Registered Office is at Lumen House, Library Avenue, > Harwell Oxford, Didcot, Oxfordshire. OX11 0SG > > From hallam@gmail.com Thu Jul 12 06:54: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 2C4B321F87D3 for ; Thu, 12 Jul 2012 06:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.585 X-Spam-Level: X-Spam-Status: No, score=-4.585 tagged_above=-999 required=5 tests=[AWL=-0.986, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJAxBhcFKa3k for ; Thu, 12 Jul 2012 06:54:15 -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 EE02221F86B0 for ; Thu, 12 Jul 2012 06:53:54 -0700 (PDT) Received: by vcqp1 with SMTP id p1so1642930vcq.31 for ; Thu, 12 Jul 2012 06:54:28 -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=AIExux/U+n4fS93nQcwYo9je0h4dgfyh8c39qaKfizI=; b=nN7HuojigsXpXr7rQIZxJbcyjyDUR8LBRRa1zyQmetjLERdG9ZiFNKlJZdShK11KAO F9jMHRwglgwQh5Gj4iGw/KdxmOz8TuXLY3jfBn67kPMw70w4/G4JDjQHNxmW2xzMDzsz ZlOAG/iUcnzqAKLRouAVrzfI6WhSCDaxV2Poev1VlY0WTwYAC4S9abWeTFZspDczPQZN JmoI98bEG79qUFaJriXlM7ZcI0wU+Ay0kZo9Cmc/Le1DwzOR50kjL8DRwGUmGK2HsTNi TCVk0oeUSzmwHD4qp2VifPbZWyEy5oiAy59BKJeBXbLNc9cE/JM9Fg2IbsQzpuKdWdvn bUOw== MIME-Version: 1.0 Received: by 10.220.40.11 with SMTP id i11mr5315641vce.50.1342101267791; Thu, 12 Jul 2012 06:54:27 -0700 (PDT) Received: by 10.58.161.139 with HTTP; Thu, 12 Jul 2012 06:54:27 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Jul 2012 09:54:27 -0400 Message-ID: From: Phillip Hallam-Baker To: Peter Gutmann Content-Type: text/plain; charset=ISO-8859-1 Cc: saag@ietf.org Subject: Re: [saag] How long should a MAC be? 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, 12 Jul 2012 13:54:16 -0000 Quite, I suspect that if people really had the motivation that they could brute force 64 bit keys right now, 80 bits of a strong cipher is almost certainly safe even against heroic measures. But most of us want to have something of a safety margin. It is easy to show how 96 bits is likely to be more than adequate for IPSEC. It is only being used for transport layer integrity checking. Even if an attacker could break 96 bits, it is hard to imagine a case where it would be worth doing so for a single packet and even if it was worth doing, the break would have to be accomplished in the time before the IP connection timed out. That logic does not apply to Kerberos type schemes unless the tickets are relatively short lived, that is days rather than years. I know that the fashion has been to use public key for long lived keys, but there are advantages to limiting the number of public key operations to the bare minimum necessary to establish a trust context. Public key operations are very hard to implement in ways that avoid potential leakage of the key. Symmetric operations are much less leaky. It is much harder to spot a single gate flipping on a 64 bit CPU than a modular multiplication being performed during a modular exponentiation. On Thu, Jul 12, 2012 at 7:54 AM, Peter Gutmann wrote: > Nico Williams writes: > >>Kerberos uses 96-bit HMAC-SHA1 for the AES 'enctypes' (ciphersuites). See >>RFC3962, where nothing much is said about the MAC length (but RFC2104 does >>have text on truncation of HMAC); you might want to ask the authors of >>RFC3962 and/or other RFCs that also use truncated MACs. > > There really ought to be some FAQ on this because it keeps on coming up: 96- > bit MACs are used for IPsec cargo-cult purposes, because 96 bits was all that > would fit in an IPsec header. Other protocols blindly copied it on the > assumption that the number 96 had some sort of magical properties. > > Please keep this response on file for when the question comes up again in > 12-18 months. > > Peter. > -- Website: http://hallambaker.com/ From hartmans@mit.edu Thu Jul 12 07:34: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 7A0B221F87D5 for ; Thu, 12 Jul 2012 07:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.221 X-Spam-Level: X-Spam-Status: No, score=-103.221 tagged_above=-999 required=5 tests=[AWL=-0.956, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DeiPV3THv9f for ; Thu, 12 Jul 2012 07:34:39 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id F1DBE21F87CC for ; Thu, 12 Jul 2012 07:34:38 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 464F9203BA; Thu, 12 Jul 2012 10:35:38 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 08D6E41F0; Thu, 12 Jul 2012 10:35:00 -0400 (EDT) From: Sam Hartman To: "Richard L. Barnes" References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> <4FFDB9B3.6050008@cs.tcd.ie> <4FFDC4BC.9000406@cs.tcd.ie> <4FFDCE03.6010009@cs.tcd.ie> <4FFDD157.1060208@cs.tcd.ie> <4FFDDFD8.9020300@cs.tcd.ie> <4FFDEF64.9040508@cs.tcd.ie> <4FFDF582.8040305@cs.tcd.ie> <4FFDF8BA.8080505@cs.tcd.ie> <37ADA69D-F318-461A-A360-5F2049138D1B@bbn.com> Date: Thu, 12 Jul 2012 10:34:59 -0400 In-Reply-To: <37ADA69D-F318-461A-A360-5F2049138D1B@bbn.com> (Richard L. Barnes's message of "Wed, 11 Jul 2012 22:58:59 -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 Cc: IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 12 Jul 2012 14:34:39 -0000 >>>>> "Richard" == Richard L Barnes writes: Richard> On Jul 11, 2012, at 6:11 PM, Nico Williams wrote: >> On Wed, Jul 11, 2012 at 5:05 PM, Stephen Farrell >> wrote: >>> There may well however probably good protocol or >>> engineering reasons for work related to password >>> auth in e.g. http/2.0 that independently justify >>> that effort, but that's another discussion, that >>> isn't and doesn't need to be, driven by improving >>> the security situation. >> >> Well, certainly for corporate environments we need GSS/Kerberos (and >> other) support. But I still think we'll need something like >> GSS/Kerberos or GSS/ABFAB on the web at large. Richard> We already have a WG for that Which one are you thinking of? Using GSS or ABFAB with HTTP is outside of the charters of kitten, abfab and krb-wg at least as far as I know. From nico@cryptonector.com Thu Jul 12 07:45: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 AC34821F8759 for ; Thu, 12 Jul 2012 07:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.144 X-Spam-Level: X-Spam-Status: No, score=-3.144 tagged_above=-999 required=5 tests=[AWL=-1.167, 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 cgCzj-gYqutu for ; Thu, 12 Jul 2012 07:45:24 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id CE46421F8700 for ; Thu, 12 Jul 2012 07:45:24 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id 5041326C08B for ; Thu, 12 Jul 2012 07:45:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=I9jQ11V//iJ10PsHJFyBJ XWThxCwQO2qALND2mSx5SOFXMh4gzFse9tCixfEcQtwZtCqsDbbUQcAOqpNPwrrN +2awOdByV3lWyeDUdX+GBlYTctGXv/kqhVNdBRhlBKhKcyTrN21VddTDgblYtFVP j1wDzOsJGqAFhefjwTVauM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=e/AhMWn0gtAIgB/0jZZF krS9QO4=; b=RNlG1+5vgRQi/Pt5LghPBW3f+627/e5JSKX8dsBE/nQD225XGjMT ZiDrILhlkKa/ttUQO/ECk649S5DkeWpqZz2dI2WTm7pnIPE+meZA59ubKdBKyCaq IV98ZxxDcZOTCOfRJ6Iqg2XGx4A4oNMNnE0Fadv2TencWhyQGnOZPlM= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPSA id 3448B26C085 for ; Thu, 12 Jul 2012 07:45:58 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so4093646pbc.31 for ; Thu, 12 Jul 2012 07:45:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.130.67 with SMTP id oc3mr5898935pbb.18.1342104357816; Thu, 12 Jul 2012 07:45:57 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Thu, 12 Jul 2012 07:45:57 -0700 (PDT) In-Reply-To: <4FFEA5CF.2050104@cs.tcd.ie> References: <4FFEA5CF.2050104@cs.tcd.ie> Date: Thu, 12 Jul 2012 09:45:57 -0500 Message-ID: From: Nico Williams To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Cc: IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 12 Jul 2012 14:45:25 -0000 On Thu, Jul 12, 2012 at 5:24 AM, Stephen Farrell wrote: > So if asking for evidence generates immediate "ivory tower" > responses like this that's probably a signal of a sort;-) The IETF is about running code and rough consensus. The IETF is not a scientific organization. Of course, running code is itself evidence of something, typically that e good enough solution exists right then to whatever problem -- good enough from an economic point of view. Running code can also include can kicking exercises that put off economic costs. For example, we have running code right now that takes care of web auth -- it's not *great*, and its occasional failures are starting to grate, but it's certainly good enough from an IETF point of view. Can we do better? Sure, but whether we do will depend on economics, and we don't have to prove anything about the economics: that will work out on its own. Of course, it sure helps to have an accurate understanding of the issues, so please do not get confused about what I'm saying (I'm NOT saying that "we don't need no stinkin' evidence"). > Like I said, there are reasons to work on frameworks like > that, but that work is just not addressing the leaky > password database threat, which is a real and current > problem. It's one problem. There's also phishing and other problems. We can't get a 100% solution. That said, for those passwords that users can get help managing, it's OK to generate them for the user, in which case the leaky password database problem disappears completely. Also, the framework approach fits other solutions *including* HOBA (e.g., because TLS is the wrong layer for user auth), smartcards, OTPs, and so on. Nico -- From stephen.farrell@cs.tcd.ie Thu Jul 12 07:47: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 EA75721F8759 for ; Thu, 12 Jul 2012 07:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8KPNtStFw5L for ; Thu, 12 Jul 2012 07:47:41 -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 53FB621F84F1 for ; Thu, 12 Jul 2012 07:47:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 903D31717CD; Thu, 12 Jul 2012 15:48:13 +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=1342104493; bh=TvTTXWVq6KFoUm FcYNRTlEL2KI4qnNbpy54DmUtkmLw=; b=fvzt6RN9YdDn2JQY0OLn/UL5pYKwD6 KCZWMSedskOUhtSD5LhSHM0sMTa20LxvbrEzFSiPqdwggETx5zSSiarlhCPS0NmH 6SEXnPkGW/x3sMxzqdDcy5OLyBm0rAzkcjGqEJjORX91Y1WnTWKijkwB/hMZVeoh 2YeUkz6vQTDJmOPu17fwttlkDYbtzptxw1UYaw+/HSf1xyFLrCDqJk5MN9rR+Xeb 1n5UxZrei5dJTPnvIpjA2zMVbwVLlQ7a93ITDEH1GFkHSJ/HN75BYKpCdmsFtdOI 0rSFps+ctq3onyzFMDq/gaYyNKIY85NVtkoi0Z+KNRM0CG+1ST05iOpA== 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 OUOwGXqrUDhO; Thu, 12 Jul 2012 15:48:13 +0100 (IST) Received: from [10.87.48.11] (unknown [86.42.30.229]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id DB9EF1714F4; Thu, 12 Jul 2012 15:48:12 +0100 (IST) Message-ID: <4FFEE3AC.1090205@cs.tcd.ie> Date: Thu, 12 Jul 2012 15:48:12 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Nico Williams References: <4FFEA5CF.2050104@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 12 Jul 2012 14:47:43 -0000 On 07/12/2012 03:45 PM, Nico Williams wrote: > On Thu, Jul 12, 2012 at 5:24 AM, Stephen Farrell > wrote: >> So if asking for evidence generates immediate "ivory tower" >> responses like this that's probably a signal of a sort;-) > > The IETF is about running code and rough consensus. The IETF is not a > scientific organization. Thanks. The smiley above was there for a reason. You can relax.:-) And I already said all that myself in an earlier mail. S From nico@cryptonector.com Thu Jul 12 07:49:52 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 5923021F879A for ; Thu, 12 Jul 2012 07:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.124 X-Spam-Level: X-Spam-Status: No, score=-3.124 tagged_above=-999 required=5 tests=[AWL=-1.147, 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 9wB7808nU0GJ for ; Thu, 12 Jul 2012 07:49:51 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id D3F0C21F876C for ; Thu, 12 Jul 2012 07:49:51 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id 5E685286057 for ; Thu, 12 Jul 2012 07:50:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=PYWecmw3NhLRqujTSLQ8D 1egMe2Z9efZzjp9v/uAuS++jVPanm+nL0UTwVi8F6UX1ZN3+M3ZJani/lW6ZvFBd iP0yQ1KQubDViCG0SczjkfLSQBmegh7zQiLLIk2fv08d3v2zBNojU+uDDoHgRmFx PFfMsGe9PlIsUVp2d9S3pE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=ArfUFxMF36yWiWBa+MNf NLxhnss=; b=MXWgmA9Xe7bEaTYi1ihhPrlV06uLieJ48MLa8gTnGZ5a7fORM7gF R5LDZHKe+44yshll5dLVU58Xy9yfyalrbcq6YgTNDAx37Z+LOwcv+I9hcGotSiil GG8u06/aYJyo12YBTIsT0BFnJR5MaLAy8zvzPKXNCyJQIEnV6RQ/zM8= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPSA id 317D2286059 for ; Thu, 12 Jul 2012 07:50:25 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so4099939pbc.31 for ; Thu, 12 Jul 2012 07:50:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.200.232 with SMTP id jv8mr5970668pbc.161.1342104624698; Thu, 12 Jul 2012 07:50:24 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Thu, 12 Jul 2012 07:50:24 -0700 (PDT) In-Reply-To: <4FFEE3AC.1090205@cs.tcd.ie> References: <4FFEA5CF.2050104@cs.tcd.ie> <4FFEE3AC.1090205@cs.tcd.ie> Date: Thu, 12 Jul 2012 09:50:24 -0500 Message-ID: From: Nico Williams To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Cc: IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 12 Jul 2012 14:49:52 -0000 On Thu, Jul 12, 2012 at 9:48 AM, Stephen Farrell wrote: > On 07/12/2012 03:45 PM, Nico Williams wrote: >> On Thu, Jul 12, 2012 at 5:24 AM, Stephen Farrell >> wrote: >>> So if asking for evidence generates immediate "ivory tower" >>> responses like this that's probably a signal of a sort;-) >> >> The IETF is about running code and rough consensus. The IETF is not a >> scientific organization. > > Thanks. The smiley above was there for a reason. You can relax.:-) > > And I already said all that myself in an earlier mail. Heh. My turn. Sorry! From stephen.farrell@cs.tcd.ie Thu Jul 12 07:50: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 CEBAE21F87E6 for ; Thu, 12 Jul 2012 07:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuYK8kYFwFW9 for ; Thu, 12 Jul 2012 07:50:57 -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 277C321F87B3 for ; Thu, 12 Jul 2012 07:50:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 49EE01714F4; Thu, 12 Jul 2012 15:51:30 +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=1342104690; bh=7Q0iJCfDSjZhE/ zIXFydYDtpxsKABMy8EZbLSeodvSA=; b=J3v90NTWjo0VewTaNCgWubHfrVBD2e Px7hfkhFYdwZ3IpEJZOC1q1qXZrwvqj/ZOozEIRErPtub9bbWTZt7tLZ1034W9kv mtz4bpJaoN00MfOkSEEcSkSiZSdhTN5oWVvckG6HiXdbGoUioxxA5NeHrgJ+Em8v raX0VhOXejsbAU78w2ZSNUQ+QLCTSatgk2Lte79ldJ8pZwYhAcI6tePw6PpnbkzO nNpdhkVLRHivRcbQyJcysVvSpyUpgGcO/vTjnKGrjV8lRgHaopvNHJgHp54k5A0Y RtCU8pf9OqIfqZzP9lppK//JXCbgBDWr0HdqZMNU6IWRccxVByHJKpUg== 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 xdKihn848C73; Thu, 12 Jul 2012 15:51:30 +0100 (IST) Received: from [10.87.48.11] (unknown [86.42.30.229]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 0BD8A17147E; Thu, 12 Jul 2012 15:51:29 +0100 (IST) Message-ID: <4FFEE471.40308@cs.tcd.ie> Date: Thu, 12 Jul 2012 15:51:29 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Sam Hartman , "saag@ietf.org" References: <4FFEA5CF.2050104@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [saag] The quest to replace passwords 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, 12 Jul 2012 14:50:57 -0000 Hi Sam, On 07/12/2012 03:30 PM, Sam Hartman wrote: >>>>>> "Stephen" == Stephen Farrell writes: > > > Stephen> Like I said, there are reasons to work on frameworks like > Stephen> that, but that work is just not addressing the leaky > Stephen> password database threat, which is a real and current > Stephen> problem. > > I think you're wrong when you say the framework work is not part of the > leaky password database problem. Not quite what I meant. I think the justification for frameworks is far more related to engineering than security. (But that's ok.) I reckon we could have much more impact on security via usable non password schemes (if we can agree on 'em;-) than via frameworks which mostly get put in front of password DBs. > 1) Decoupling applications from their authentication mechanisms seems > like it makes it easier to deploy non-password mechanisms. Well, only if all services have shifted to the federated thing. If a lot haven't then all clients and serves need to change for any new scheme anyway. > 2) It seems fairly likely that deploying non-password mechanisms will be > easier in the framework cases. That is, someone like Google and facebook > are in a much better position to actually deploy tokens of some kind > than some random website. Maybe. I dunno about "fairly likely" since a lot of that is about business issues, but I would hope sites like those must be fairly nervous about how broad an impact leaking their password databases might have. > 3) Reuse of identity makes dealing with a compromise easier; I need to > change a password in one place. Mitigating consequences of an attack is > a valuable thing to do. Note of course that this concentration may > create higher-value targets. In practice, people do enough credential > re-use that it's not clear how real this is. Right. S. PS: Another one today. [1] Sigh. [1] http://it.slashdot.org/story/12/07/12/1243217/nearly-half-a-million-yahoo-passwords-leaked From derek@ihtfp.com Thu Jul 12 08:47: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 647B611E80AA for ; Thu, 12 Jul 2012 08:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdG3qC7JDTmn for ; Thu, 12 Jul 2012 08:47:07 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) by ietfa.amsl.com (Postfix) with ESMTP id CC5E911E8095 for ; Thu, 12 Jul 2012 08:47:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id AF93A2602A9; Thu, 12 Jul 2012 11:47:39 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 15161-03; Thu, 12 Jul 2012 11:47:38 -0400 (EDT) Received: from mocana.ihtfp.org (unknown [IPv6:fe80::224:d7ff:fee7:8924]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 0270E2602A6; Thu, 12 Jul 2012 11:47:38 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id q6CFlZmQ029906; Thu, 12 Jul 2012 11:47:35 -0400 From: Derek Atkins To: Sam Hartman References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> <4FFDB9B3.6050008@cs.tcd.ie> <4FFDC4BC.9000406@cs.tcd.ie> <4FFDCE03.6010009@cs.tcd.ie> <4FFDD157.1060208@cs.tcd.ie> <4FFDDFD8.9020300@cs.tcd.ie> <4FFDEF64.9040508@cs.tcd.ie> <4FFDF582.8040305@cs.tcd.ie> <4FFDF8BA.8080505@cs.tcd.ie> <37ADA69D-F318-461A-A360-5F2049138D1B@bbn.com> Date: Thu, 12 Jul 2012 11:47:34 -0400 In-Reply-To: (Sam Hartman's message of "Thu, 12 Jul 2012 10:34:59 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 12 Jul 2012 15:47:07 -0000 Sam Hartman writes: >>>>>> "Richard" == Richard L Barnes writes: > > Richard> On Jul 11, 2012, at 6:11 PM, Nico Williams wrote: > > >> On Wed, Jul 11, 2012 at 5:05 PM, Stephen Farrell > >> wrote: > >>> There may well however probably good protocol or > >>> engineering reasons for work related to password > >>> auth in e.g. http/2.0 that independently justify > >>> that effort, but that's another discussion, that > >>> isn't and doesn't need to be, driven by improving > >>> the security situation. > >> > >> Well, certainly for corporate environments we need GSS/Kerberos (and > >> other) support. But I still think we'll need something like > >> GSS/Kerberos or GSS/ABFAB on the web at large. > > > Richard> We already have a WG for that > > Which one are you thinking of? > Using GSS or ABFAB with HTTP is outside of the charters of kitten, abfab > and krb-wg at least as far as I know. Sam, You missed the rest of Richard's sentence, and didn't even deign to quote it. He said, in full, "We already have a WG for that: oauth". And you can certainly use GSS or ABFAB for the "user<->AS" authN path (because that flow is not defined by OAuth). > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From adam@stoicsecurity.com Thu Jul 12 09:13: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 39B6221F85B1 for ; Thu, 12 Jul 2012 09:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.359 X-Spam-Level: X-Spam-Status: No, score=-1.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_LWSHORTT=1.24] 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 XtrrmwEKN7xZ for ; Thu, 12 Jul 2012 09:13:09 -0700 (PDT) Received: from smtpauth23.prod.mesa1.secureserver.net (smtpauth23.prod.mesa1.secureserver.net [64.202.165.47]) by ietfa.amsl.com (Postfix) with SMTP id B993D21F85AE for ; Thu, 12 Jul 2012 09:13:09 -0700 (PDT) Received: (qmail 4000 invoked from network); 12 Jul 2012 16:13:42 -0000 Received: from unknown (50.137.24.91) by smtpauth23.prod.mesa1.secureserver.net (64.202.165.47) with ESMTP; 12 Jul 2012 16:13:42 -0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Adam W. Montville" In-Reply-To: <4FFEE471.40308@cs.tcd.ie> Date: Thu, 12 Jul 2012 09:13:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <17445680-7176-440B-ACB3-6960BEA3E255@stoicsecurity.com> References: <4FFEA5CF.2050104@cs.tcd.ie> <4FFEE471.40308@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1278) Cc: Sam Hartman , "saag@ietf.org" Subject: Re: [saag] The quest to replace passwords 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, 12 Jul 2012 16:13:10 -0000 On Jul 12, 2012, at 7:51 AM, Stephen Farrell wrote: > I reckon we could have much more impact on security via usable > non password schemes (if we can agree on 'em;-) than via frameworks > which mostly get put in front of password DBs. I'm stepping out of comfort here, but it seems that we could realize = some benefit with a framework generating sufficiently long pass phrases = rather than pass "words." Four randomly chosen words (of sufficient = length) separated by spaces, for example, would increase the effort = required for offline brute force attacks under many circumstances. =20 A 100% solution this is not, but it would be something that might get = some traction in the short term. I like the notion of avoiding passwords entirely, however, if it can be = done or at least moved toward. Adam= From hartmans@mit.edu Thu Jul 12 09:26: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 0304221F8724 for ; Thu, 12 Jul 2012 09:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.186 X-Spam-Level: X-Spam-Status: No, score=-103.186 tagged_above=-999 required=5 tests=[AWL=-0.921, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFXu6N2wOI2t for ; Thu, 12 Jul 2012 09:26:08 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 8447721F871A for ; Thu, 12 Jul 2012 09:26:08 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 674832043E; Thu, 12 Jul 2012 12:27:08 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CC03541F0; Thu, 12 Jul 2012 12:26:29 -0400 (EDT) From: Sam Hartman To: Derek Atkins References: <7EE01297-2BA0-4882-8CF0-AEFC154BEEFB@vpnc.org> <4FFDB9B3.6050008@cs.tcd.ie> <4FFDC4BC.9000406@cs.tcd.ie> <4FFDCE03.6010009@cs.tcd.ie> <4FFDD157.1060208@cs.tcd.ie> <4FFDDFD8.9020300@cs.tcd.ie> <4FFDEF64.9040508@cs.tcd.ie> <4FFDF582.8040305@cs.tcd.ie> <4FFDF8BA.8080505@cs.tcd.ie> <37ADA69D-F318-461A-A360-5F2049138D1B@bbn.com> Date: Thu, 12 Jul 2012 12:26:29 -0400 In-Reply-To: (Derek Atkins's message of "Thu, 12 Jul 2012 11:47: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 Cc: Sam Hartman , IETF Security Area Advisory Group Subject: Re: [saag] The quest to replace passwords 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, 12 Jul 2012 16:26:09 -0000 >>>>> "Derek" == Derek Atkins writes: Derek> Sam Hartman writes: >>>>>>> "Richard" == Richard L Barnes writes: >> Richard> On Jul 11, 2012, at 6:11 PM, Nico Williams wrote: >> >> >> On Wed, Jul 11, 2012 at 5:05 PM, Stephen Farrell >> >> wrote: >> >>> There may well however probably good protocol or >> >>> engineering reasons for work related to password >> >>> auth in e.g. http/2.0 that independently justify >> >>> that effort, but that's another discussion, that >> >>> isn't and doesn't need to be, driven by improving >> >>> the security situation. >> >> >> >> Well, certainly for corporate environments we need GSS/Kerberos (and >> >> other) support. But I still think we'll need something like >> >> GSS/Kerberos or GSS/ABFAB on the web at large. >> >> Richard> We already have a WG for that >> >> Which one are you thinking of? >> Using GSS or ABFAB with HTTP is outside of the charters of kitten, abfab >> and krb-wg at least as far as I know. Derek> Sam, You missed the rest of Richard's sentence, and didn't even deign to Derek> quote it. He said, in full, "We already have a WG for that: oauth". Derek> my apologies. I certainly would not have sent the message at all had I seen the rest of the sentence. I can't explain how I missed that but it was an honest mistake. From stephen.farrell@cs.tcd.ie Thu Jul 12 09:34: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 DD1AE21F872D for ; Thu, 12 Jul 2012 09:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.879 X-Spam-Level: X-Spam-Status: No, score=-101.879 tagged_above=-999 required=5 tests=[AWL=-0.520, BAYES_00=-2.599, SARE_LWSHORTT=1.24, 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 ucQGiyRH120f for ; Thu, 12 Jul 2012 09:34:38 -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 C6E8E21F872A for ; Thu, 12 Jul 2012 09:34:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 1CF5F1714F4; Thu, 12 Jul 2012 17:35:09 +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=1342110908; bh=v4MEwymqKWAq9j PsIC0XRHeLLWiYaykf3Mfr7eahU2U=; b=kdraOD5TSwebc+ZQcepmE08pEAiCUb cmukbBVvWvDzjhOvWn4TH1HitE2F/wctjCAshcJElDplZMx7kFa6ntFppmhPp+WJ gQQlp10F/PZb6bEyYMBuUG8R3BoLzrvKJJ0nQWCpXLOZgCUoJhNH/3J3DtunT1Iz E4yLl2FtEWu0vKraYxRi2feZc6FiADRYmKjPpypB81ovGXxY4BitlLMMiWcheiZU 39gVDitXD0NJmmX8NqED3H50UrWCJn4IcmbT0Wc8KsG020OBtpnye40i/2GFNddp bpPqisKrHPg3VhJ7QFU5Z53oCwa3xpmYtQ08csL7VHdoUE3daOZ8YpXQ== 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 djPum0dztUNq; Thu, 12 Jul 2012 17:35:08 +0100 (IST) Received: from [10.87.48.11] (unknown [86.42.30.229]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 2708317147E; Thu, 12 Jul 2012 17:35:07 +0100 (IST) Message-ID: <4FFEFCBB.9070609@cs.tcd.ie> Date: Thu, 12 Jul 2012 17:35:07 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Adam W. Montville" References: <4FFEA5CF.2050104@cs.tcd.ie> <4FFEE471.40308@cs.tcd.ie> <17445680-7176-440B-ACB3-6960BEA3E255@stoicsecurity.com> In-Reply-To: <17445680-7176-440B-ACB3-6960BEA3E255@stoicsecurity.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sam Hartman , "saag@ietf.org" Subject: Re: [saag] The quest to replace passwords 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, 12 Jul 2012 16:34:39 -0000 On 07/12/2012 05:13 PM, Adam W. Montville wrote: > > On Jul 12, 2012, at 7:51 AM, Stephen Farrell wrote: > >> I reckon we could have much more impact on security via usable >> non password schemes (if we can agree on 'em;-) than via frameworks >> which mostly get put in front of password DBs. > > I'm stepping out of comfort here, but it seems that we could realize some benefit with a framework generating sufficiently long pass phrases rather than pass "words." Four randomly chosen words (of sufficient length) separated by spaces, for example, would increase the effort required for offline brute force attacks under many circumstances. > > A 100% solution this is not, but it would be something that might get some traction in the short term. > > I like the notion of avoiding passwords entirely, however, if it can be done or at least moved toward. I'd recommend a look at the phd thesis mentioned earlier. [1] It has a very good state of the art chapter. To be clear though: I don't think the way to replace passwords is with....passwords:-) S. [1] http://www.cl.cam.ac.uk/~jcb82/doc/2012-jbonneau-phd_thesis.pdf > Adam > From rbarnes@bbn.com Thu Jul 12 12:14: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 ACBE821F8668 for ; Thu, 12 Jul 2012 12:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.588 X-Spam-Level: X-Spam-Status: No, score=-106.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLiHotGAv7ap for ; Thu, 12 Jul 2012 12:14:30 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 06B3721F865A for ; Thu, 12 Jul 2012 12:14:30 -0700 (PDT) Received: from ros-dhcp192-1-51-20.bbn.com ([192.1.51.20]:49963) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SpOqt-000DLC-TX; Thu, 12 Jul 2012 15:15:03 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Richard L. Barnes In-Reply-To: Date: Thu, 12 Jul 2012 15:15:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1278) Cc: saag@ietf.org Subject: Re: [saag] How long should a MAC be? 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, 12 Jul 2012 19:14:31 -0000 > But! A MAC is not a digest, it is an authentication mechanism. If I > use HMAC-SHA256 with a 128 bit key, I am going to have no more than > 128 bits of ergodicity in my output. So what is the justification for > presenting more than 128 bits? The 128 bits of entropy (FTFY) might not be evenly distributed though = the output bits of the MAC function. You would need to evaluate the = algorithm to determine the entropy each section of the output in order = to determine which portion of the output is sufficient. --Richard= From mouse@Sparkle.Rodents-Montreal.ORG Thu Jul 12 12: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 D3F1221F8687 for ; Thu, 12 Jul 2012 12:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.224 X-Spam-Level: X-Spam-Status: No, score=-8.224 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_20=-0.74, HELO_MISMATCH_ORG=0.611, 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 UvDcpC2keJUt for ; Thu, 12 Jul 2012 12:45:34 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id 62C0F21F861A for ; Thu, 12 Jul 2012 12:45:27 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id PAA26881; Thu, 12 Jul 2012 15:46:00 -0400 (EDT) Date: Thu, 12 Jul 2012 15:46:00 -0400 (EDT) From: Mouse Message-Id: <201207121946.PAA26881@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, 12 Jul 2012 15:44:34 -0400 (EDT) To: saag@ietf.org In-Reply-To: <17445680-7176-440B-ACB3-6960BEA3E255@stoicsecurity.com> References: <4FFEA5CF.2050104@cs.tcd.ie> <4FFEE471.40308@cs.tcd.ie> <17445680-7176-440B-ACB3-6960BEA3E255@stoicsecurity.com> Subject: Re: [saag] The quest to replace passwords 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, 12 Jul 2012 19:45:35 -0000 > I'm stepping out of comfort here, but it seems that we could realize some be$ I agree. Randall totally nailed this in xkcd #936. /~\ 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 ynir@checkpoint.com Thu Jul 12 13:05: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 C689221F8705 for ; Thu, 12 Jul 2012 13:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.804 X-Spam-Level: X-Spam-Status: No, score=-9.804 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_OBFU_PART_ORD=0.952] 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 8zW7beKi1iFe for ; Thu, 12 Jul 2012 13:05:20 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id C5E4A21F8548 for ; Thu, 12 Jul 2012 13:05:19 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q6CK5hNZ021473; Thu, 12 Jul 2012 23:05:51 +0300 X-CheckPoint: {4FFF2C92-0-1B221DC2-4FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 12 Jul 2012 23:05:43 +0300 From: Yoav Nir To: Mouse Date: Thu, 12 Jul 2012 23:05:42 +0300 Thread-Topic: [saag] The quest to replace passwords Thread-Index: Ac1gabcy62ZgNg7gT4aoY3ONzBmZFg== Message-ID: References: <4FFEA5CF.2050104@cs.tcd.ie> <4FFEE471.40308@cs.tcd.ie> <17445680-7176-440B-ACB3-6960BEA3E255@stoicsecurity.com> <201207121946.PAA26881@Sparkle.Rodents-Montreal.ORG> In-Reply-To: <201207121946.PAA26881@Sparkle.Rodents-Montreal.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "saag@ietf.org" Subject: Re: [saag] The quest to replace passwords 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, 12 Jul 2012 20:05:21 -0000 On Jul 12, 2012, at 10:46 PM, Mouse wrote: >> I'm stepping out of comfort here, but it seems that we could realize som= e be$ >=20 > I agree. Randall totally nailed this in xkcd #936. I don't think he did. While there are only a few thousand common words that= might be chosen for the base word, 2^28 is a very large number for guessin= g over the 'net. Any system worth its salt won't let an attacker guess 1000= times a second, and he overestimates the difficulty of remembering it. On the other hand, 4 random common words are very hard to remember - you fo= rget the order, you replace words, and the story you invent doesn't make se= nse, and gets mixed up with the stories for last month's passphrase. People= would naturally not choose 4 independently random words. If the first word= is "correct", the next is likely to be either something that is correct, o= r another adjective. Not a horse. Make this the rule for wiki passwords for IETF meetings, and you'll have mo= re than one instance of "explore strange new worlds", "rough consensus runn= ing code", and maybe even "d**n you perry platypus". These are the equivale= nts of "password", "pass1234", and "passw0rd", except this time, nobody's m= aking us use numerals or symbols and mixed case to add unpredictability. Yoav From ekr@rtfm.com Thu Jul 12 16:00: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 2DB8F11E80D9 for ; Thu, 12 Jul 2012 16:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.812 X-Spam-Level: X-Spam-Status: No, score=-102.812 tagged_above=-999 required=5 tests=[AWL=0.165, 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 ZR7PYn1KCLGV for ; Thu, 12 Jul 2012 16:00:28 -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 8F48E11E80B6 for ; Thu, 12 Jul 2012 16:00:28 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2027114vbb.31 for ; Thu, 12 Jul 2012 16:01:02 -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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=Oazdx+68cmq02ifo4euDpg5hOtIa+XwxsWYzuJzkrNQ=; b=eT08duc5QCyMdk+Hp/gXwvkvQ6cGpnFTB5Qzfknfc39JhXKENAMTv4s7oeDjwIsrlX KRwAg+XuDuWQRs+68JUelbvlFp0Z5BuWWaqI7R41Q8RNa7eKJ6jLzyQlwAqLPO8xjdU8 fjb0BKKhbJ69u6KFxYTLo8nO6oONuktseA4UnazqO795YVBepI9UCbc7zaz22EflavJM TA7nsOzDPvp7pd+RFZHSWQO61VM5pjCC011FwPAw+nf87+GokbH8Yq16sAK8ZoM+uhYd Auq7w7LZimmJMy6AZyu1XglwV7l2a4abxk9p0VgtBdrKnTSywWEjnZKnDdJ3Bal5w9av Ah3g== Received: by 10.220.153.198 with SMTP id l6mr77432vcw.2.1342134062633; Thu, 12 Jul 2012 16:01:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Thu, 12 Jul 2012 16:00:22 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: From: Eric Rescorla Date: Thu, 12 Jul 2012 16:00:22 -0700 Message-ID: To: "Richard L. Barnes" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkT8zZeMsF23bMpus5klO/vXZcizSUOIMZ8J9KDmZkfGK2sMyv6OTCkZTUA8YD12k4h5ec2 Cc: Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] How long should a MAC be? 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, 12 Jul 2012 23:00:29 -0000 On Thu, Jul 12, 2012 at 12:15 PM, Richard L. Barnes wrote= : >> But! A MAC is not a digest, it is an authentication mechanism. If I >> use HMAC-SHA256 with a 128 bit key, I am going to have no more than >> 128 bits of ergodicity in my output. So what is the justification for >> presenting more than 128 bits? > > The 128 bits of entropy (FTFY) might not be evenly distributed though the= output bits of the MAC function. You would need to evaluate the algorithm= to determine the entropy each section of the output in order to determine = which portion of the output is sufficient. This is of course true, but if that were true for a given MAC. it would likely imply that the MAC was weaker than the design strength. -Ekr From prvs=65403c2e64=dbrown@certicom.com Thu Jul 12 16:32: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 2D86F11E80EA for ; Thu, 12 Jul 2012 16:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zv+U3qOmTnso for ; Thu, 12 Jul 2012 16:32:00 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id E9F3F11E80BD for ; Thu, 12 Jul 2012 16:31:59 -0700 (PDT) X-AuditID: 0a412830-b7f2c6d00000418a-87-4fff5e8ec24f Received: from XCT105CNC.rim.net (xct105cnc.rim.net [10.65.161.205]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id BF.75.16778.E8E5FFF4; Thu, 12 Jul 2012 23:32:31 +0000 (GMT) Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT105CNC.rim.net ([fe80::d13d:b7a2:ae5e:db06%16]) with mapi id 14.02.0298.004; Thu, 12 Jul 2012 19:32:30 -0400 From: Dan Brown To: "hallam@gmail.com" , "saag@ietf.org" Thread-Topic: [saag] How long should a MAC be? Thread-Index: AQHNX8qwy5MebXb55USchhFnivaxXZcmTZ/Z Date: Thu, 12 Jul 2012 23:32:29 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF509A6AF@XMB111CNC.rim.net> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.246] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNKsWRmVeSWpSXmKPExsXC5bjwrG5/3H9/g65VnBZXlx9nspjS38nk wOSxc9Zddo8lS34yBTBFNTDaJCWWlAVnpufp29kk5uXllySWpCqkpBYn2yr5pKYn5igEFGWW JSZXKrhkFifnJGbmphYpKWSm2CqZKCkU5CQmp+am5pXYKiUWFKTmpSjZcSlgABugssw8hdS8 5PyUzLx0WyXPYH9dCwtTS11DJTvdhE6ejNN37jEVXOOpaOyawtTAuJiri5GTQ0LARGLOlNWM ELaYxIV769m6GLk4hAT6mCS27FoG5WxllFg7YTo7SBWbgKrE/aPnmEFsEQEviUUtK8BsYQFd ifWvb7BAxPUkthw9z9rFyAFkG0nc+lkMEmYBar26by0TiM0r4CYxdeEXZpASToFAiaOfJUHC jAKyErvPXgcrYRYQl7j1ZD4TxG0CEkv2nGeGsEUlXj7+xwphK0o8OXmNBaJeT+LG1ClsELa2 xLKFr5khVglKnJz5hGUCo8gsJGNnIWmZhaRlFpKWBYwsqxgFczOKDcwMk/OS9Yoyc/XyUks2 MYKjXsNgB+OEvVqHGAU4GJV4eH1C//sLsSaWFVfmHmKU4GBWEuFdZw8U4k1JrKxKLcqPLyrN SS0+xGgBDIiJzFLcyfnAhJRXEm9sYIDCURLnPcL+2V9IIB2YSLJTUwtSi2BamTg4QUZzSYkU A9NBalFiaUlGPChpxRcD05ZUAyPb1ROHX7tZHvCv/8MbzXfLP372uQYvI4v92kqnv/eL2e13 aEi0OcXi7aDdKvR2mfiv250qNTwf6htlNszImVHZv8JxTWqpHd9sy5Pvnpo8vt7U+cHDyeFg eLOp7P/rRlZ9nQ/cZ4hNP/pqT0//aqebZq0OKqqS117ZRVY6/tonduCDbylflBJLcUaioRZz UXEiAALbqhsuAwAA Subject: Re: [saag] How long should a MAC be? 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, 12 Jul 2012 23:32:01 -0000 Maybe some of the HMAC security proofs don't work if HMAC is truncated. We= could ask CFRG or Bellare. ----- Original Message ----- From: Phillip Hallam-Baker [mailto:hallam@gmail.com] Sent: Wednesday, July 11, 2012 09:07 PM=0A= To: saag@ietf.org Subject: [saag] How long should a MAC be? Yeah, yeah, digests, birthday attack, yadda yadda. But! A MAC is not a digest, it is an authentication mechanism. If I use HMAC-SHA256 with a 128 bit key, I am going to have no more than 128 bits of ergodicity in my output. So what is the justification for presenting more than 128 bits? Now I guess someone can argue (OK they will) that HMAC-SHA256 with a 256 bit key produces a full 256 bits of ergodicity in the output. But given that we have agreed on 128 bits as 'sufficient' for encryption keys (well for the lifetime of this universe at least) why then demand up to 512 for authentication? I know that there are perfectly good reasons for using AES-256, it is not really the possibility of brute forcing the key that is the issue so much as the fact that AES-512 has many more rounds than AES-128 and is stronger. And when someone like Adi Shamir suggests AES might be a little over-optimized, well I listen. What this comes down to is that I think we need a HMAC-SHA128 and maybe people who are really looking for 256 bits of authentication should be cutting HMAC-SHA512 in two... Just a thought. -- Website: http://hallambaker.com/ _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From ekr@rtfm.com Thu Jul 12 16:38:48 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 D59D021F8526 for ; Thu, 12 Jul 2012 16:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.817 X-Spam-Level: X-Spam-Status: No, score=-102.817 tagged_above=-999 required=5 tests=[AWL=0.160, 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 qd0uvzmuqvs2 for ; Thu, 12 Jul 2012 16:38:47 -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 AA7D121F8505 for ; Thu, 12 Jul 2012 16:38:47 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so261284vcb.31 for ; Thu, 12 Jul 2012 16:39:21 -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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=Ips0Ey/wUY1IPd+p4Mvew9b0iId+qQA1ZJfjRGmL58o=; b=asF6t7jnyiDtSkpgWpuT2sm1sTo2uiy3xBEC13fN0uyZygHIc+CwrA3dN0eaw4nvdS pSetE2TEfMui5hcWWhLxX6Y1S4t6cWtyl1GM++LWI4Mb7+25CKSvbflsbIVQFjBSxw5T nEcwTXF4wX39O5qYG9glG4srrCw3dg79v8LA/UipB0XTnclGM1qJ+8FdYIS2nXJJos/e wdZXaOqr71e4n2FgW3zTa7dJDRDuEE8zvA668ja4YRBxICm835aFxxjsNXBi9ltVweA6 U2PmeGmPIUDvmCSfJYidPStlFmvbAfjlK2S3lv8tLEaop2JZoCN9NPAFqjV94hhUmxsM VYow== Received: by 10.52.99.227 with SMTP id et3mr48271vdb.110.1342136361836; Thu, 12 Jul 2012 16:39:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Thu, 12 Jul 2012 16:38:41 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <810C31990B57ED40B2062BA10D43FBF509A6AF@XMB111CNC.rim.net> References: <810C31990B57ED40B2062BA10D43FBF509A6AF@XMB111CNC.rim.net> From: Eric Rescorla Date: Thu, 12 Jul 2012 16:38:41 -0700 Message-ID: To: Dan Brown Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmpl6LKiy/cf1FonbrhrcQ4RJro/Pvhc+30gCyGC0h44js17ZqS/Un5rEZeO/pDa6/De7bb Cc: "hallam@gmail.com" , "saag@ietf.org" Subject: Re: [saag] How long should a MAC be? 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, 12 Jul 2012 23:38:49 -0000 Given that Bellare is a co-author on RFC 2104 and 2104 describes truncation= , I would certainly be sad to learn truncation wasn't OK. -Ekr On Thu, Jul 12, 2012 at 4:32 PM, Dan Brown wrote: > Maybe some of the HMAC security proofs don't work if HMAC is truncated. = We could ask CFRG or Bellare. > > ----- Original Message ----- > From: Phillip Hallam-Baker [mailto:hallam@gmail.com] > Sent: Wednesday, July 11, 2012 09:07 PM > To: saag@ietf.org > Subject: [saag] How long should a MAC be? > > Yeah, yeah, digests, birthday attack, yadda yadda. > > But! A MAC is not a digest, it is an authentication mechanism. If I > use HMAC-SHA256 with a 128 bit key, I am going to have no more than > 128 bits of ergodicity in my output. So what is the justification for > presenting more than 128 bits? > > Now I guess someone can argue (OK they will) that HMAC-SHA256 with a > 256 bit key produces a full 256 bits of ergodicity in the output. But > given that we have agreed on 128 bits as 'sufficient' for encryption > keys (well for the lifetime of this universe at least) why then demand > up to 512 for authentication? > > I know that there are perfectly good reasons for using AES-256, it is > not really the possibility of brute forcing the key that is the issue > so much as the fact that AES-512 has many more rounds than AES-128 and > is stronger. And when someone like Adi Shamir suggests AES might be a > little over-optimized, well I listen. > > What this comes down to is that I think we need a HMAC-SHA128 and > maybe people who are really looking for 256 bits of authentication > should be cutting HMAC-SHA512 in two... > > Just a thought. > > -- > Website: http://hallambaker.com/ > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From prvs=3540129fc1=dbrown@certicom.com Thu Jul 12 16:50:33 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 8B20811E80F0 for ; Thu, 12 Jul 2012 16:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5iNV9-Z9Fvf for ; Thu, 12 Jul 2012 16:50:32 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7845511E80BC for ; Thu, 12 Jul 2012 16:50:32 -0700 (PDT) X-AuditID: 0a412830-b7f2c6d00000418a-6d-4fff62ea7414 Received: from XCT106CNC.rim.net (xct106cnc.rim.net [10.65.161.206]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 57.F5.16778.AE26FFF4; Thu, 12 Jul 2012 23:51:06 +0000 (GMT) Received: from XCT112CNC.rim.net (10.65.161.212) by XCT106CNC.rim.net (10.65.161.206) with Microsoft SMTP Server (TLS) id 14.2.298.4; Thu, 12 Jul 2012 19:51:06 -0400 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT112CNC.rim.net ([::1]) with mapi id 14.02.0298.004; Thu, 12 Jul 2012 19:51:05 -0400 From: Dan Brown To: "ekr@rtfm.com" Thread-Topic: [saag] How long should a MAC be? Thread-Index: AQHNX8qwy5MebXb55USchhFnivaxXZcmTZ/ZgABEyYD//8Bppg== Date: Thu, 12 Jul 2012 23:51:05 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF509A6DD@XMB111CNC.rim.net> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.246] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNKsWRmVeSWpSXmKPExsXC5bjwnO6rpP/+Bo3TTCxWvD7HbnF1+XEm iyn9nUwOzB47Z91l91iy5CeTx+THbcwBzFENjDZJiSVlwZnpefp2Nol5efkliSWpCimpxcm2 Sj6p6Yk5CgFFmWWJyZUKLpnFyTmJmbmpRUoKmSm2SiZKCgU5icmpual5JbZKiQUFqXkpSnZc ChjABqgsM08hNS85PyUzL91WyTPYX9fCwtRS11DJTjehkyej6d0UloLvEhWvmqcxNjBuEuli 5OSQEDCReHR7GjuELSZx4d56ti5GLg4hgT4miX8ffjBBOCsZJXbf3wOVmcMosfLBJlaQFjYB VYn7R88xg9giAooSR+4dZQOxmQW8JF5vuwU2VlhAV2L96xssEDV6EluOnmeFsJ0k1s5cwwhi swDN+XxvEdA2Dg5eATeJ+0/EQcKcAoESC38sBRvPKCArsfvsdSaI8eISt57MZ4K4WkBiyZ7z zBC2qMTLx/9YIWxFiScnr7FA1OtJ3Jg6Beo0bYllC1+D1fMKCEqcnPkErEZIQEHiyvV9LBMY xWchWTELSfssJO2zkLQvYGRZxSiYm1FsYGaYnJesV5SZq5eXWrKJEZxUNAx2ME7Yq3WIUYCD UYmH1yf0v78Qa2JZcWXuIUYJDmYlEd519kAh3pTEyqrUovz4otKc1OJDjBbAQJnILMWdnA9M eHkl8cYGBigcJXHeI+yf/YUE0oFJKTs1tSC1CKaViYMTZDSXlEgxMLWkFiWWlmTEgxJgfDEw BUo1MNpF97mzqann+si+abzr9OdVtU/qf9+Wr8tddPpSv3NvqNofH/ezZJvHrfbFUe+L1vPd bjq39P6RlmiGl+Va1lFVThbnn7z11+XtSTogKVAR5TbPqeZqTeR6x7dRa03ylVM8lwUmc6pP qtk/U2FXYbVK67s9br+/+p7V1Ivbtk14g7IQ5xl/JZbijERDLeai4kQAoDO0l14DAAA= Cc: "hallam@gmail.com" , "saag@ietf.org" Subject: Re: [saag] How long should a MAC be? 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, 12 Jul 2012 23:50:33 -0000 I expect truncation is OK. My point was that a truncated MAC is perhaps not= (as) provably secure (because extra assumptioms may be needed). Maybe 2104 does not mandate truncation for this very reason. ----- Original Message ----- From: Eric Rescorla [mailto:ekr@rtfm.com] Sent: Thursday, July 12, 2012 07:38 PM=0A= To: Dan Brown Cc: hallam@gmail.com ; saag@ietf.org Subject: Re: [saag] How long should a MAC be? Given that Bellare is a co-author on RFC 2104 and 2104 describes truncation, I would certainly be sad to learn truncation wasn't OK. -Ekr On Thu, Jul 12, 2012 at 4:32 PM, Dan Brown wrote: > Maybe some of the HMAC security proofs don't work if HMAC is truncated. W= e could ask CFRG or Bellare. > > ----- Original Message ----- > From: Phillip Hallam-Baker [mailto:hallam@gmail.com] > Sent: Wednesday, July 11, 2012 09:07 PM > To: saag@ietf.org > Subject: [saag] How long should a MAC be? > > Yeah, yeah, digests, birthday attack, yadda yadda. > > But! A MAC is not a digest, it is an authentication mechanism. If I > use HMAC-SHA256 with a 128 bit key, I am going to have no more than > 128 bits of ergodicity in my output. So what is the justification for > presenting more than 128 bits? > > Now I guess someone can argue (OK they will) that HMAC-SHA256 with a > 256 bit key produces a full 256 bits of ergodicity in the output. But > given that we have agreed on 128 bits as 'sufficient' for encryption > keys (well for the lifetime of this universe at least) why then demand > up to 512 for authentication? > > I know that there are perfectly good reasons for using AES-256, it is > not really the possibility of brute forcing the key that is the issue > so much as the fact that AES-512 has many more rounds than AES-128 and > is stronger. And when someone like Adi Shamir suggests AES might be a > little over-optimized, well I listen. > > What this comes down to is that I think we need a HMAC-SHA128 and > maybe people who are really looking for 256 bits of authentication > should be cutting HMAC-SHA512 in two... > > Just a thought. > > -- > Website: http://hallambaker.com/ > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential inf= ormation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informatio= n. Any use of this information by anyone other than the intended recipient i= s prohibited. If you have received this transmission in error, please immedi= ately reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From hugokraw@gmail.com Thu Jul 12 18:05:36 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 1829B11E8098 for ; Thu, 12 Jul 2012 18:05:36 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjZyFUjA4T1M for ; Thu, 12 Jul 2012 18:05:34 -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 5A3FB11E8096 for ; Thu, 12 Jul 2012 18:05:34 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so4253927lbb.31 for ; Thu, 12 Jul 2012 18:06: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:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=U86K+HKnhuK9OMeVS80u1DJBIh/S0rHUOXGMhViskdo=; b=cw1QbPGvkSzIYotwxKbRRxFvej8JiiVCaewu+DIklbwBgwwwljlnvT8XDQkm4a3DV1 mwSFIPZsJv9RA4kv9Mbq4KzCwdOHBzGtTBAA1+QQsZvkrztrulc25C4klXQOoYb3aEUZ iqdRJPJLJqBJtYtkxGmiXIOjxgGLfaemAbKr8Zgp0+tCDpl33tTGkzv/C7kHboT2RnBg iO4vH5wa+3mx37EtpXnz+CwFjgFaJwV8fPxzcbU55sFS5CCh53sLqLPp1rP3O35dArbt 3HDMOQu4s+oB88+bCphAFEeJd8zoe7MoslXwl/9QO3rmcuqGG3afDczO4jUp0gr/1Lvs f7dQ== Received: by 10.152.125.116 with SMTP id mp20mr387581lab.19.1342141568188; Thu, 12 Jul 2012 18:06:08 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.112.42.138 with HTTP; Thu, 12 Jul 2012 18:05:47 -0700 (PDT) In-Reply-To: References: <810C31990B57ED40B2062BA10D43FBF509A6AF@XMB111CNC.rim.net> From: Hugo Krawczyk Date: Thu, 12 Jul 2012 21:05:47 -0400 X-Google-Sender-Auth: 2hCHkOUNCGkus-qM3hZNafsSr9g Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=f46d0435be6e69035d04c4abaf8a Cc: "hallam@gmail.com" , "saag@ietf.org" Subject: Re: [saag] How long should a MAC be? 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, 13 Jul 2012 01:05:36 -0000 --f46d0435be6e69035d04c4abaf8a Content-Type: text/plain; charset=UTF-8 On Thu, Jul 12, 2012 at 7:38 PM, Eric Rescorla wrote: > Given that Bellare is a co-author on RFC 2104 and 2104 describes truncation, > I would certainly be sad to learn truncation wasn't OK. > > -Ekr No reason to be sad, Eric. The text for HMAC truncation in RFC 2104 (see below) still holds. Confidence in this mechanism is even stronger today given the proofs (and practical acceptance) of HMAC as a pseudo-random function [1,2,3]. This means that any subset of t bits from HMAC's output should be computationally indistinguishable from t random bits, therefore suitable for MAC (the security should be considered the minimum between the length of the MAC and the security of HMAC, typically given by half the size of the hash length). [1] M. Bellare, R. Canetti, and H. Krawczyk, "Keying Hash Functions for Message Authentication", Crypto 1996. [2] M. Bellare, R. Canetti, and H. Krawczyk, "Pseudorandom Functions Revisited: The Cascade Construction", Proceedings of FOCS'96. [3] M. Bellare "New Proofs for NMAC and HMAC: Security without Collision-Resistance", Crypto 2006. Here is the original text from the RFC 5. Truncated output A well-known practice with message authentication codes is to truncate the output of the MAC and output only part of the bits (e.g., [MM, ANSI]). Preneel and van Oorschot [PV] show some analytical advantages of truncating the output of hash-based MAC functions. The results in this area are not absolute as for the overall security advantages of truncation. It has advantages (less information on the hash result available to an attacker) and disadvantages (less bits to predict for the attacker). Applications of HMAC can choose to truncate the output of HMAC by outputting the t leftmost bits of the HMAC computation for some parameter t (namely, the computation is carried in the normal way as defined in section 2 above but the end result is truncated to t bits). We recommend that the output length t be not less than half the length of the hash output (to match the birthday attack bound) and not less than 80 bits (a suitable lower bound on the number of bits that need to be predicted by an attacker). Hugo > On Thu, Jul 12, 2012 at 4:32 PM, Dan Brown wrote: > > Maybe some of the HMAC security proofs don't work if HMAC is truncated. > We could ask CFRG or Bellare. > > > > ----- Original Message ----- > > From: Phillip Hallam-Baker [mailto:hallam@gmail.com] > > Sent: Wednesday, July 11, 2012 09:07 PM > > To: saag@ietf.org > > Subject: [saag] How long should a MAC be? > > > > Yeah, yeah, digests, birthday attack, yadda yadda. > > > > But! A MAC is not a digest, it is an authentication mechanism. If I > > use HMAC-SHA256 with a 128 bit key, I am going to have no more than > > 128 bits of ergodicity in my output. So what is the justification for > > presenting more than 128 bits? > > > > Now I guess someone can argue (OK they will) that HMAC-SHA256 with a > > 256 bit key produces a full 256 bits of ergodicity in the output. But > > given that we have agreed on 128 bits as 'sufficient' for encryption > > keys (well for the lifetime of this universe at least) why then demand > > up to 512 for authentication? > > > > I know that there are perfectly good reasons for using AES-256, it is > > not really the possibility of brute forcing the key that is the issue > > so much as the fact that AES-512 has many more rounds than AES-128 and > > is stronger. And when someone like Adi Shamir suggests AES might be a > > little over-optimized, well I listen. > > > > What this comes down to is that I think we need a HMAC-SHA128 and > > maybe people who are really looking for 256 bits of authentication > > should be cutting HMAC-SHA512 in two... > > > > Just a thought. > > > > -- > > Website: http://hallambaker.com/ > > _______________________________________________ > > saag mailing list > > saag@ietf.org > > https://www.ietf.org/mailman/listinfo/saag > > > > --------------------------------------------------------------------- > > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be unlawful. > > _______________________________________________ > > 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 > --f46d0435be6e69035d04c4abaf8a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jul 12, 2012 at 7:38 PM, Eric Rescorla <ekr@rtfm.com> wro= te:
> Given that Bellare is a co-author on RFC 2104 and 2104 describe= s truncation,
> I would certainly be sad to learn truncation wasn't OK.
>
> -Ekr

No reason to be sad, Eri= c.

The text for HMAC = truncation in RFC 2104 (see below) still holds. Confidence in this mechanis= m is even stronger today given the proofs (and practical acceptance) of HMA= C as a pseudo-random function [1,2,3]. This means that any subset of t bits= from HMAC's output should be computationally indistinguishable from t = random bits, therefore suitable for MAC (the security should be considered = the minimum between the length of the MAC and the security of HMAC, typical= ly given by half the size of the hash length).

[1] M. Bellare, R. Canetti, and H. Krawczyk, "Keying Hash Function= s for Message Authentication", Crypto 1996.

[2] M. Bellare, R. = Canetti, and H. Krawczyk, "Pseudorandom Functions Revisited: The Casca= de Construction", Proceedings of FOCS'96.

[3] M. Bellare "New Proofs for NMAC and HMAC: Security without Col= lision-Resistance", Crypto 2006.

Here is the original text from= the RFC

 5. Truncated output

   A well-known practice with message authentication codes is to
   truncate the output of the MAC and output only part of the bits
   (e.g., [MM, ANSI]).  Preneel and van Oorschot [PV] show some
   analytical advantages of truncating the output of hash-based MAC
   functions. The results in this area are not absolute as for the
   overall security advantages of truncation. It has advantages (less
   information on the hash result available to an attacker) and
   disadvantages (less bits to predict for the attacker).  Applications
   of HMAC can choose to truncate the output of HMAC by outputting the t
   leftmost bits of the HMAC computation for some parameter t (namely,
   the computation is carried in the normal way as defined in section 2
   above but the end result is truncated to t bits). We recommend that
   the output length t be not less than half the length of the hash
   output (to match the birthday attack bound) and not less than 80 bits
   (a suitable lower bound on the number of bits that need to be
   predicted by an attacker).

Hugo



On Thu, Jul 12, 2012 at 4:32 PM, Dan Brown <dbrown@certicom.com> wrote:
> Maybe some of the HMAC security proofs don't work if HMAC is trunc= ated. =C2=A0We could ask CFRG or Bellare.
>
> ----- Original Message -----
> From: Phillip Hallam-Baker [mailto:hallam@gmail.com]
> Sent: Wednesday, July 11, 2012 09:07 PM
> To: saag@ietf.org <saag@ietf.org>
> Subject: [saag] How long should a MAC be?
>
> Yeah, yeah, digests, birthday attack, yadda yadda.
>
> But! A MAC is not a digest, it is an authentication mechanism. If I > use HMAC-SHA256 with a 128 bit key, I am going to have no more than > 128 bits of ergodicity in my output. So what is the justification for<= br> > presenting more than 128 bits?
>
> Now I guess someone can argue (OK they will) that HMAC-SHA256 with a > 256 bit key produces a full 256 bits of ergodicity in the output. But<= br> > given that we have agreed on 128 bits as 'sufficient' for encr= yption
> keys (well for the lifetime of this universe at least) why then demand=
> up to 512 for authentication?
>
> I know that there are perfectly good reasons for using AES-256, it is<= br> > not really the possibility of brute forcing the key that is the issue<= br> > so much as the fact that AES-512 has many more rounds than AES-128 and=
> is stronger. And when someone like Adi Shamir suggests AES might be a<= br> > little over-optimized, well I listen.
>
> What this comes down to is that I think we need a HMAC-SHA128 and
> maybe people who are really looking for 256 bits of authentication
> should be cutting HMAC-SHA512 in two...
>
> Just a thought.
>
> --
> Website: http://= hallambaker.com/
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>
> ---------------------------------------------------------------------<= br> > This transmission (including any attachments) may contain confidential= information, privileged material (including material protected by the soli= citor-client or other applicable privileges), or constitute non-public info= rmation. Any use of this information by anyone other than the intended reci= pient is prohibited. If you have received this transmission in error, pleas= e immediately reply to the sender and delete this information from your sys= tem. Use, dissemination, distribution, or reproduction of this transmission= by unintended recipients is not authorized and may be unlawful.
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
_______________________________________________
saag mailing list
saag@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/saag


--f46d0435be6e69035d04c4abaf8a-- From prvs=6541509e3d=dbrown@certicom.com Thu Jul 12 18:20: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 4213911E8105 for ; Thu, 12 Jul 2012 18:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=0.697, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9esJZ5IKVtE for ; Thu, 12 Jul 2012 18:20:39 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 412A511E810B for ; Thu, 12 Jul 2012 18:20:38 -0700 (PDT) X-AuditID: 0a41282f-b7fe56d000007bb5-65-4fff7808afbe Received: from XCT108CNC.rim.net (xct108cnc.rim.net [10.65.161.208]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs060cnc.rim.net (SBG) with SMTP id BF.88.31669.8087FFF4; Fri, 13 Jul 2012 01:21:12 +0000 (GMT) Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT108CNC.rim.net ([fe80::8dc1:9551:6ed8:c618%17]) with mapi id 14.02.0298.004; Thu, 12 Jul 2012 21:21:11 -0400 From: Dan Brown To: "hugo@ee.technion.ac.il" , "ekr@rtfm.com" Thread-Topic: [saag] How long should a MAC be? Thread-Index: AQHNX8qwy5MebXb55USchhFnivaxXZcmTZ/ZgABEyYCAABhWgP//wT+a Date: Fri, 13 Jul 2012 01:21:10 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF509A718@XMB111CNC.rim.net> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.246] Content-Type: multipart/alternative; boundary="_000_810C31990B57ED40B2062BA10D43FBF509A718XMB111CNCrimnet_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMKsWRmVeSWpSXmKPExsXC5bjwgi5HxX9/g/OTxC1WvD7HbnF1+XEm i6evpjNbTOnvZHJg8dg+7SG7x85Zd9k9liz5yeQx+XEbcwBLVAOjTVJiSVlwZnqevp1NYl5e fkliSapCSmpxsq2ST2p6Yo5CQFFmWWJypYJLZnFyTmJmbmqRkkJmiq2SiZJCQU5icmpual6J rVJiQUFqXoqSHZcCBrABKsvMU0jNS85PycxLt1XyDPbXtbAwtdQ1VLLTTejkybjw4i5rwZR+ xorWt0cYGxhXdTN2MXJySAiYSMzft5oJwhaTuHBvPVsXIxeHkEAfk8S1uXdYIZytjBKdzcfA qtgEVCXuHz3HDGKLCIRJNF2Zzw5iMwt4SbzedgvMFhbQlVj/+gYLRI2exJaj51khbDegOe/B NrMAzTm3vAUszgsUv/r5IRuIzSkQKLHk3x2wXYwCshK7z15ngpgvLnHryXyoSwUkluw5zwxh i0q8fPyPFcJWlHhy8hoLRH2uxNqmGcwQ8wUlTs58wjKBUWQWklGzkJTNQlI2i5EDKK4psX6X PkSJosSU7ofsELaGROucuezI4gsY2VcxCuZmFBuYGSTnJesVZebq5aWWbGIEpxoN/R2MfXu1 DjEKcDAq8fA2lP33F2JNLCuuzD3EKMHBrCTCa1cKFOJNSaysSi3Kjy8qzUktPsToCgygicxS 3Mn5wDSYVxJvbGCAm6MkznuI/bO/kEA6MGFlp6YWpBbBzGHi4ATZwyUlUgxMO6lFiaUlGfGg 5BhfDEyPUg2MCzdmtXukLwsonrf3k4efeAsrx6sPL5mXHC1dxTTLbtmyNdaz3u4yF7Xc5Kp+ 6v0BAa8A13dHmU75MMwy1Lv6e/Fhn+DbB1J15Y8ddXvrtirTXbtT9bpPDWful3WtgTqJNrPz 35nMVZhQ1RZ0R6e/w3GW5/cb7zsb7brSnq6InpR+dsNJVjZNJZbijERDLeai4kQAj7yQFnYD AAA= Cc: "hallam@gmail.com" , "saag@ietf.org" Subject: Re: [saag] How long should a MAC be? 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, 13 Jul 2012 01:20:41 -0000 --_000_810C31990B57ED40B2062BA10D43FBF509A718XMB111CNCrimnet_ Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 U28sIGluIHRlcm1zIG9mIHNlY3VyaXR5IGxldmVscywgZG9lcyB3aGF0IFJGQyAyMTA0IHNh eXMgbWVhbiB0aGF0IEhNQUMtU0hBMjU2IHByb3ZpZGVzIDI1Ni1iaXQgc2VjdXJpdHksIHdo aWxlIHRydW5jYXRpbmcgdG8gMTI4IGJpdHMgcHJvdmlkZXMgMTI4LWJpdCBzZWN1cml0eT8g T3IgZG9lcyBITUFDLVNIQTI1NiBvbmx5IHByb3ZpZGUgMTI4IHNlY3VyaXR5Pw0KDQoNCg0K RnJvbTogSHVnbyBLcmF3Y3p5ayBbbWFpbHRvOmh1Z29AZWUudGVjaG5pb24uYWMuaWxdDQpT ZW50OiBUaHVyc2RheSwgSnVseSAxMiwgMjAxMiAwOTowNSBQTQ0KVG86IEVyaWMgUmVzY29y bGEgPGVrckBydGZtLmNvbT4NCkNjOiBEYW4gQnJvd247IGhhbGxhbUBnbWFpbC5jb20gPGhh bGxhbUBnbWFpbC5jb20+OyBzYWFnQGlldGYub3JnIDxzYWFnQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFtzYWFnXSBIb3cgbG9uZyBzaG91bGQgYSBNQUMgYmU/DQoNCk9uIFRodSwgSnVs IDEyLCAyMDEyIGF0IDc6MzggUE0sIEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbTxtYWls dG86ZWtyQHJ0Zm0uY29tPj4gd3JvdGU6DQo+IEdpdmVuIHRoYXQgQmVsbGFyZSBpcyBhIGNv LWF1dGhvciBvbiBSRkMgMjEwNCBhbmQgMjEwNCBkZXNjcmliZXMgdHJ1bmNhdGlvbiwNCj4g SSB3b3VsZCBjZXJ0YWlubHkgYmUgc2FkIHRvIGxlYXJuIHRydW5jYXRpb24gd2Fzbid0IE9L Lg0KPg0KPiAtRWtyDQoNCk5vIHJlYXNvbiB0byBiZSBzYWQsIEVyaWMuDQoNClRoZSB0ZXh0 IGZvciBITUFDIHRydW5jYXRpb24gaW4gUkZDIDIxMDQgKHNlZSBiZWxvdykgc3RpbGwgaG9s ZHMuIENvbmZpZGVuY2UgaW4gdGhpcyBtZWNoYW5pc20gaXMgZXZlbiBzdHJvbmdlciB0b2Rh eSBnaXZlbiB0aGUgcHJvb2ZzIChhbmQgcHJhY3RpY2FsIGFjY2VwdGFuY2UpIG9mIEhNQUMg YXMgYSBwc2V1ZG8tcmFuZG9tIGZ1bmN0aW9uIFsxLDIsM10uIFRoaXMgbWVhbnMgdGhhdCBh bnkgc3Vic2V0IG9mIHQgYml0cyBmcm9tIEhNQUMncyBvdXRwdXQgc2hvdWxkIGJlIGNvbXB1 dGF0aW9uYWxseSBpbmRpc3Rpbmd1aXNoYWJsZSBmcm9tIHQgcmFuZG9tIGJpdHMsIHRoZXJl Zm9yZSBzdWl0YWJsZSBmb3IgTUFDICh0aGUgc2VjdXJpdHkgc2hvdWxkIGJlIGNvbnNpZGVy ZWQgdGhlIG1pbmltdW0gYmV0d2VlbiB0aGUgbGVuZ3RoIG9mIHRoZSBNQUMgYW5kIHRoZSBz ZWN1cml0eSBvZiBITUFDLCB0eXBpY2FsbHkgZ2l2ZW4gYnkgaGFsZiB0aGUgc2l6ZSBvZiB0 aGUgaGFzaCBsZW5ndGgpLg0KDQpbMV0gTS4gQmVsbGFyZSwgUi4gQ2FuZXR0aSwgYW5kIEgu IEtyYXdjenlrLCAiS2V5aW5nIEhhc2ggRnVuY3Rpb25zIGZvciBNZXNzYWdlIEF1dGhlbnRp Y2F0aW9uIiwgQ3J5cHRvIDE5OTYuDQoNClsyXSBNLiBCZWxsYXJlLCBSLiBDYW5ldHRpLCBh bmQgSC4gS3Jhd2N6eWssICJQc2V1ZG9yYW5kb20gRnVuY3Rpb25zIFJldmlzaXRlZDogVGhl IENhc2NhZGUgQ29uc3RydWN0aW9uIiwgUHJvY2VlZGluZ3Mgb2YgRk9DUyc5Ni4NCg0KWzNd IE0uIEJlbGxhcmUgIk5ldyBQcm9vZnMgZm9yIE5NQUMgYW5kIEhNQUM6IFNlY3VyaXR5IHdp dGhvdXQgQ29sbGlzaW9uLVJlc2lzdGFuY2UiLCBDcnlwdG8gMjAwNi4NCg0KSGVyZSBpcyB0 aGUgb3JpZ2luYWwgdGV4dCBmcm9tIHRoZSBSRkMNCg0KDQogNS4gVHJ1bmNhdGVkIG91dHB1 dA0KDQogICBBIHdlbGwta25vd24gcHJhY3RpY2Ugd2l0aCBtZXNzYWdlIGF1dGhlbnRpY2F0 aW9uIGNvZGVzIGlzIHRvDQogICB0cnVuY2F0ZSB0aGUgb3V0cHV0IG9mIHRoZSBNQUMgYW5k IG91dHB1dCBvbmx5IHBhcnQgb2YgdGhlIGJpdHMNCiAgIChlLmcuLCBbTU0sIEFOU0ldKS4g IFByZW5lZWwgYW5kIHZhbiBPb3JzY2hvdCBbUFZdIHNob3cgc29tZQ0KICAgYW5hbHl0aWNh bCBhZHZhbnRhZ2VzIG9mIHRydW5jYXRpbmcgdGhlIG91dHB1dCBvZiBoYXNoLWJhc2VkIE1B Qw0KICAgZnVuY3Rpb25zLiBUaGUgcmVzdWx0cyBpbiB0aGlzIGFyZWEgYXJlIG5vdCBhYnNv bHV0ZSBhcyBmb3IgdGhlDQogICBvdmVyYWxsIHNlY3VyaXR5IGFkdmFudGFnZXMgb2YgdHJ1 bmNhdGlvbi4gSXQgaGFzIGFkdmFudGFnZXMgKGxlc3MNCiAgIGluZm9ybWF0aW9uIG9uIHRo ZSBoYXNoIHJlc3VsdCBhdmFpbGFibGUgdG8gYW4gYXR0YWNrZXIpIGFuZA0KICAgZGlzYWR2 YW50YWdlcyAobGVzcyBiaXRzIHRvIHByZWRpY3QgZm9yIHRoZSBhdHRhY2tlcikuICBBcHBs aWNhdGlvbnMNCiAgIG9mIEhNQUMgY2FuIGNob29zZSB0byB0cnVuY2F0ZSB0aGUgb3V0cHV0 IG9mIEhNQUMgYnkgb3V0cHV0dGluZyB0aGUgdA0KICAgbGVmdG1vc3QgYml0cyBvZiB0aGUg SE1BQyBjb21wdXRhdGlvbiBmb3Igc29tZSBwYXJhbWV0ZXIgdCAobmFtZWx5LA0KICAgdGhl IGNvbXB1dGF0aW9uIGlzIGNhcnJpZWQgaW4gdGhlIG5vcm1hbCB3YXkgYXMgZGVmaW5lZCBp biBzZWN0aW9uIDINCiAgIGFib3ZlIGJ1dCB0aGUgZW5kIHJlc3VsdCBpcyB0cnVuY2F0ZWQg dG8gdCBiaXRzKS4gV2UgcmVjb21tZW5kIHRoYXQNCiAgIHRoZSBvdXRwdXQgbGVuZ3RoIHQg YmUgbm90IGxlc3MgdGhhbiBoYWxmIHRoZSBsZW5ndGggb2YgdGhlIGhhc2gNCiAgIG91dHB1 dCAodG8gbWF0Y2ggdGhlIGJpcnRoZGF5IGF0dGFjayBib3VuZCkgYW5kIG5vdCBsZXNzIHRo YW4gODAgYml0cw0KICAgKGEgc3VpdGFibGUgbG93ZXIgYm91bmQgb24gdGhlIG51bWJlciBv ZiBiaXRzIHRoYXQgbmVlZCB0byBiZQ0KICAgcHJlZGljdGVkIGJ5IGFuIGF0dGFja2VyKS4N Cg0KDQpIdWdvDQoNCg0KDQpPbiBUaHUsIEp1bCAxMiwgMjAxMiBhdCA0OjMyIFBNLCBEYW4g QnJvd24gPGRicm93bkBjZXJ0aWNvbS5jb208bWFpbHRvOmRicm93bkBjZXJ0aWNvbS5jb20+ PiB3cm90ZToNCj4gTWF5YmUgc29tZSBvZiB0aGUgSE1BQyBzZWN1cml0eSBwcm9vZnMgZG9u J3Qgd29yayBpZiBITUFDIGlzIHRydW5jYXRlZC4gIFdlIGNvdWxkIGFzayBDRlJHIG9yIEJl bGxhcmUuDQo+DQo+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gRnJvbTogUGhp bGxpcCBIYWxsYW0tQmFrZXIgW21haWx0bzpoYWxsYW1AZ21haWwuY29tPG1haWx0bzpoYWxs YW1AZ21haWwuY29tPl0NCj4gU2VudDogV2VkbmVzZGF5LCBKdWx5IDExLCAyMDEyIDA5OjA3 IFBNDQo+IFRvOiBzYWFnQGlldGYub3JnPG1haWx0bzpzYWFnQGlldGYub3JnPiA8c2FhZ0Bp ZXRmLm9yZzxtYWlsdG86c2FhZ0BpZXRmLm9yZz4+DQo+IFN1YmplY3Q6IFtzYWFnXSBIb3cg bG9uZyBzaG91bGQgYSBNQUMgYmU/DQo+DQo+IFllYWgsIHllYWgsIGRpZ2VzdHMsIGJpcnRo ZGF5IGF0dGFjaywgeWFkZGEgeWFkZGEuDQo+DQo+IEJ1dCEgQSBNQUMgaXMgbm90IGEgZGln ZXN0LCBpdCBpcyBhbiBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20uIElmIEkNCj4gdXNlIEhN QUMtU0hBMjU2IHdpdGggYSAxMjggYml0IGtleSwgSSBhbSBnb2luZyB0byBoYXZlIG5vIG1v cmUgdGhhbg0KPiAxMjggYml0cyBvZiBlcmdvZGljaXR5IGluIG15IG91dHB1dC4gU28gd2hh dCBpcyB0aGUganVzdGlmaWNhdGlvbiBmb3INCj4gcHJlc2VudGluZyBtb3JlIHRoYW4gMTI4 IGJpdHM/DQo+DQo+IE5vdyBJIGd1ZXNzIHNvbWVvbmUgY2FuIGFyZ3VlIChPSyB0aGV5IHdp bGwpIHRoYXQgSE1BQy1TSEEyNTYgd2l0aCBhDQo+IDI1NiBiaXQga2V5IHByb2R1Y2VzIGEg ZnVsbCAyNTYgYml0cyBvZiBlcmdvZGljaXR5IGluIHRoZSBvdXRwdXQuIEJ1dA0KPiBnaXZl biB0aGF0IHdlIGhhdmUgYWdyZWVkIG9uIDEyOCBiaXRzIGFzICdzdWZmaWNpZW50JyBmb3Ig ZW5jcnlwdGlvbg0KPiBrZXlzICh3ZWxsIGZvciB0aGUgbGlmZXRpbWUgb2YgdGhpcyB1bml2 ZXJzZSBhdCBsZWFzdCkgd2h5IHRoZW4gZGVtYW5kDQo+IHVwIHRvIDUxMiBmb3IgYXV0aGVu dGljYXRpb24/DQo+DQo+IEkga25vdyB0aGF0IHRoZXJlIGFyZSBwZXJmZWN0bHkgZ29vZCBy ZWFzb25zIGZvciB1c2luZyBBRVMtMjU2LCBpdCBpcw0KPiBub3QgcmVhbGx5IHRoZSBwb3Nz aWJpbGl0eSBvZiBicnV0ZSBmb3JjaW5nIHRoZSBrZXkgdGhhdCBpcyB0aGUgaXNzdWUNCj4g c28gbXVjaCBhcyB0aGUgZmFjdCB0aGF0IEFFUy01MTIgaGFzIG1hbnkgbW9yZSByb3VuZHMg dGhhbiBBRVMtMTI4IGFuZA0KPiBpcyBzdHJvbmdlci4gQW5kIHdoZW4gc29tZW9uZSBsaWtl IEFkaSBTaGFtaXIgc3VnZ2VzdHMgQUVTIG1pZ2h0IGJlIGENCj4gbGl0dGxlIG92ZXItb3B0 aW1pemVkLCB3ZWxsIEkgbGlzdGVuLg0KPg0KPiBXaGF0IHRoaXMgY29tZXMgZG93biB0byBp cyB0aGF0IEkgdGhpbmsgd2UgbmVlZCBhIEhNQUMtU0hBMTI4IGFuZA0KPiBtYXliZSBwZW9w bGUgd2hvIGFyZSByZWFsbHkgbG9va2luZyBmb3IgMjU2IGJpdHMgb2YgYXV0aGVudGljYXRp b24NCj4gc2hvdWxkIGJlIGN1dHRpbmcgSE1BQy1TSEE1MTIgaW4gdHdvLi4uDQo+DQo+IEp1 c3QgYSB0aG91Z2h0Lg0KPg0KPiAtLQ0KPiBXZWJzaXRlOiBodHRwOi8vaGFsbGFtYmFrZXIu Y29tLw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBzYWFnIG1haWxpbmcgbGlzdA0KPiBzYWFnQGlldGYub3JnPG1haWx0bzpzYWFnQGll dGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhYWcN Cj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFRoaXMgdHJhbnNtaXNzaW9uIChpbmNsdWRpbmcg YW55IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24s IHByaXZpbGVnZWQgbWF0ZXJpYWwgKGluY2x1ZGluZyBtYXRlcmlhbCBwcm90ZWN0ZWQgYnkg dGhlIHNvbGljaXRvci1jbGllbnQgb3Igb3RoZXIgYXBwbGljYWJsZSBwcml2aWxlZ2VzKSwg b3IgY29uc3RpdHV0ZSBub24tcHVibGljIGluZm9ybWF0aW9uLiBBbnkgdXNlIG9mIHRoaXMg aW5mb3JtYXRpb24gYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVu dCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lv biBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5k IGRlbGV0ZSB0aGlzIGluZm9ybWF0aW9uIGZyb20geW91ciBzeXN0ZW0uIFVzZSwgZGlzc2Vt aW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21p c3Npb24gYnkgdW5pbnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdCBhdXRob3JpemVkIGFuZCBt YXkgYmUgdW5sYXdmdWwuDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IHNhYWcgbWFpbGluZyBsaXN0DQo+IHNhYWdAaWV0Zi5vcmc8bWFp bHRvOnNhYWdAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2FhZw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCnNhYWcgbWFpbGluZyBsaXN0DQpzYWFnQGlldGYub3JnPG1haWx0bzpzYWFnQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWFnDQoN Cg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgdHJhbnNtaXNzaW9uIChpbmNsdWRpbmcgYW55 IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24sIHBy aXZpbGVnZWQgbWF0ZXJpYWwgKGluY2x1ZGluZyBtYXRlcmlhbCBwcm90ZWN0ZWQgYnkgdGhl IHNvbGljaXRvci1jbGllbnQgb3Igb3RoZXIgYXBwbGljYWJsZSBwcml2aWxlZ2VzKSwgb3Ig Y29uc3RpdHV0ZSBub24tcHVibGljIGluZm9ybWF0aW9uLiBBbnkgdXNlIG9mIHRoaXMgaW5m b3JtYXRpb24gYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudCBp cyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBp biBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5kIGRl bGV0ZSB0aGlzIGluZm9ybWF0aW9uIGZyb20geW91ciBzeXN0ZW0uIFVzZSwgZGlzc2VtaW5h dGlvbiwgZGlzdHJpYnV0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21pc3Np b24gYnkgdW5pbnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdCBhdXRob3JpemVkIGFuZCBtYXkg YmUgdW5sYXdmdWwuDQo= --_000_810C31990B57ED40B2062BA10D43FBF509A718XMB111CNCrimnet_ Content-Type: text/html; charset="utf-8" content-transfer-encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGZvbnQg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvLCBpbiB0ZXJtcyBv ZiBzZWN1cml0eSBsZXZlbHMsIGRvZXMgd2hhdCBSRkMgMjEwNCBzYXlzIG1lYW4gdGhhdCBI TUFDLVNIQTI1NiBwcm92aWRlcyAyNTYtYml0IHNlY3VyaXR5LCB3aGlsZSB0cnVuY2F0aW5n IHRvIDEyOCBiaXRzIHByb3ZpZGVzIDEyOC1iaXQgc2VjdXJpdHk/IE9yIGRvZXMgSE1BQy1T SEEyNTYNCiBvbmx5IHByb3ZpZGUgMTI4IHNlY3VyaXR5Pzxicj4NCjxicj4NCjwvZm9udD48 YnI+DQombmJzcDs8YnI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8Zm9udCBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGI+RnJvbTwvYj46IEh1Z28gS3Jhd2N6eWsgW21h aWx0bzpodWdvQGVlLnRlY2huaW9uLmFjLmlsXQ0KPGJyPg0KPGI+U2VudDwvYj46IFRodXJz ZGF5LCBKdWx5IDEyLCAyMDEyIDA5OjA1IFBNPGJyPg0KPGI+VG88L2I+OiBFcmljIFJlc2Nv cmxhICZsdDtla3JAcnRmbS5jb20mZ3Q7IDxicj4NCjxiPkNjPC9iPjogRGFuIEJyb3duOyBo YWxsYW1AZ21haWwuY29tICZsdDtoYWxsYW1AZ21haWwuY29tJmd0Ozsgc2FhZ0BpZXRmLm9y ZyAmbHQ7c2FhZ0BpZXRmLm9yZyZndDsNCjxicj4NCjxiPlN1YmplY3Q8L2I+OiBSZTogW3Nh YWddIEhvdyBsb25nIHNob3VsZCBhIE1BQyBiZT8gPGJyPg0KPC9mb250PiZuYnNwOzxicj4N CjwvZGl2Pg0KT24gVGh1LCBKdWwgMTIsIDIwMTIgYXQgNzozOCBQTSwgRXJpYyBSZXNjb3Js YSA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iIHRh cmdldD0iX2JsYW5rIj5la3JAcnRmbS5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPg0K Jmd0OyBHaXZlbiB0aGF0IEJlbGxhcmUgaXMgYSBjby1hdXRob3Igb24gUkZDIDIxMDQgYW5k IDIxMDQgZGVzY3JpYmVzIHRydW5jYXRpb24sPGJyPg0KJmd0OyBJIHdvdWxkIGNlcnRhaW5s eSBiZSBzYWQgdG8gbGVhcm4gdHJ1bmNhdGlvbiB3YXNuJ3QgT0suPGJyPg0KJmd0Ozxicj4N CiZndDsgLUVrcjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTp2ZXJkYW5h LHNhbnMtc2VyaWYiPk5vIHJlYXNvbiB0byBiZSBzYWQsIEVyaWMuPC9zcGFuPjxicj4NCjxi cj4NCjxmb250Pjxmb250IGZhY2U9InZlcmRhbmEsc2Fucy1zZXJpZiI+VGhlIHRleHQgZm9y IEhNQUMgdHJ1bmNhdGlvbiBpbiBSRkMgMjEwNCAoc2VlIGJlbG93KSBzdGlsbCBob2xkcy4g Q29uZmlkZW5jZSBpbiB0aGlzIG1lY2hhbmlzbSBpcyBldmVuIHN0cm9uZ2VyIHRvZGF5IGdp dmVuIHRoZSBwcm9vZnMgKGFuZCBwcmFjdGljYWwgYWNjZXB0YW5jZSkgb2YgSE1BQyBhcyBh IHBzZXVkby1yYW5kb20gZnVuY3Rpb24gWzEsMiwzXS4gVGhpcyBtZWFucyB0aGF0DQogYW55 IHN1YnNldCBvZiB0IGJpdHMgZnJvbSBITUFDJ3Mgb3V0cHV0IHNob3VsZCBiZSBjb21wdXRh dGlvbmFsbHkgaW5kaXN0aW5ndWlzaGFibGUgZnJvbSB0IHJhbmRvbSBiaXRzLCB0aGVyZWZv cmUgc3VpdGFibGUgZm9yIE1BQyAodGhlIHNlY3VyaXR5IHNob3VsZCBiZSBjb25zaWRlcmVk IHRoZSBtaW5pbXVtIGJldHdlZW4gdGhlIGxlbmd0aCBvZiB0aGUgTUFDIGFuZCB0aGUgc2Vj dXJpdHkgb2YgSE1BQywgdHlwaWNhbGx5IGdpdmVuIGJ5IGhhbGYNCiB0aGUgc2l6ZSBvZiB0 aGUgaGFzaCBsZW5ndGgpLjxicj4NCjxicj4NClsxXSBNLiBCZWxsYXJlLCBSLiBDYW5ldHRp LCBhbmQgSC4gS3Jhd2N6eWssICZxdW90O0tleWluZyBIYXNoIEZ1bmN0aW9ucyBmb3IgTWVz c2FnZSBBdXRoZW50aWNhdGlvbiZxdW90OywgQ3J5cHRvIDE5OTYuPGJyPg0KPGJyPg0KWzJd IE0uIEJlbGxhcmUsIFIuIENhbmV0dGksIGFuZCBILiBLcmF3Y3p5aywgJnF1b3Q7UHNldWRv cmFuZG9tIEZ1bmN0aW9ucyBSZXZpc2l0ZWQ6IFRoZSBDYXNjYWRlIENvbnN0cnVjdGlvbiZx dW90OywgUHJvY2VlZGluZ3Mgb2YgRk9DUyc5Ni48YnI+DQo8YnI+DQpbM10gTS4gQmVsbGFy ZSAmcXVvdDtOZXcgUHJvb2ZzIGZvciBOTUFDIGFuZCBITUFDOiBTZWN1cml0eSB3aXRob3V0 IENvbGxpc2lvbi1SZXNpc3RhbmNlJnF1b3Q7LCBDcnlwdG8gMjAwNi48YnI+DQo8YnI+DQpI ZXJlIGlzIHRoZSBvcmlnaW5hbCB0ZXh0IGZyb20gdGhlIFJGQzxicj4NCjxicj4NCjwvZm9u dD48L2ZvbnQ+DQo8cHJlPiA8Zm9udCBzdHlsZT0iZm9udC1mYW1pbHk6Y291cmllciBuZXcs bW9ub3NwYWNlIiBzaXplPSIyIj41LiBUcnVuY2F0ZWQgb3V0cHV0DQoNCiAgIEEgd2VsbC1r bm93biBwcmFjdGljZSB3aXRoIG1lc3NhZ2UgYXV0aGVudGljYXRpb24gY29kZXMgaXMgdG8N CiAgIHRydW5jYXRlIHRoZSBvdXRwdXQgb2YgdGhlIE1BQyBhbmQgb3V0cHV0IG9ubHkgcGFy dCBvZiB0aGUgYml0cw0KICAgKGUuZy4sIFtNTSwgQU5TSV0pLiAgUHJlbmVlbCBhbmQgdmFu IE9vcnNjaG90IFtQVl0gc2hvdyBzb21lDQogICBhbmFseXRpY2FsIGFkdmFudGFnZXMgb2Yg dHJ1bmNhdGluZyB0aGUgb3V0cHV0IG9mIGhhc2gtYmFzZWQgTUFDDQogICBmdW5jdGlvbnMu IFRoZSByZXN1bHRzIGluIHRoaXMgYXJlYSBhcmUgbm90IGFic29sdXRlIGFzIGZvciB0aGUN CiAgIG92ZXJhbGwgc2VjdXJpdHkgYWR2YW50YWdlcyBvZiB0cnVuY2F0aW9uLiBJdCBoYXMg YWR2YW50YWdlcyAobGVzcw0KICAgaW5mb3JtYXRpb24gb24gdGhlIGhhc2ggcmVzdWx0IGF2 YWlsYWJsZSB0byBhbiBhdHRhY2tlcikgYW5kDQogICBkaXNhZHZhbnRhZ2VzIChsZXNzIGJp dHMgdG8gcHJlZGljdCBmb3IgdGhlIGF0dGFja2VyKS4gIEFwcGxpY2F0aW9ucw0KICAgb2Yg SE1BQyBjYW4gY2hvb3NlIHRvIHRydW5jYXRlIHRoZSBvdXRwdXQgb2YgSE1BQyBieSBvdXRw dXR0aW5nIHRoZSB0DQogICBsZWZ0bW9zdCBiaXRzIG9mIHRoZSBITUFDIGNvbXB1dGF0aW9u IGZvciBzb21lIHBhcmFtZXRlciB0IChuYW1lbHksDQogICB0aGUgY29tcHV0YXRpb24gaXMg Y2FycmllZCBpbiB0aGUgbm9ybWFsIHdheSBhcyBkZWZpbmVkIGluIHNlY3Rpb24gMg0KICAg YWJvdmUgYnV0IHRoZSBlbmQgcmVzdWx0IGlzIHRydW5jYXRlZCB0byB0IGJpdHMpLiBXZSBy ZWNvbW1lbmQgdGhhdA0KICAgdGhlIG91dHB1dCBsZW5ndGggdCBiZSBub3QgbGVzcyB0aGFu IGhhbGYgdGhlIGxlbmd0aCBvZiB0aGUgaGFzaA0KICAgb3V0cHV0ICh0byBtYXRjaCB0aGUg YmlydGhkYXkgYXR0YWNrIGJvdW5kKSBhbmQgbm90IGxlc3MgdGhhbiA4MCBiaXRzDQogICAo YSBzdWl0YWJsZSBsb3dlciBib3VuZCBvbiB0aGUgbnVtYmVyIG9mIGJpdHMgdGhhdCBuZWVk IHRvIGJlDQogICBwcmVkaWN0ZWQgYnkgYW4gYXR0YWNrZXIpLiA8L2ZvbnQ+PGJyPjxicj48 Zm9udD48Zm9udCBmYWNlPSJ2ZXJkYW5hLHNhbnMtc2VyaWYiPjwvZm9udD48L2ZvbnQ+PC9w cmU+DQpIdWdvPGJyPg0KPGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjxicj4NCjxi bG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4 O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBj bGFzcz0iSE9FblpiIj4NCjxkaXYgY2xhc3M9Img1Ij48YnI+DQpPbiBUaHUsIEp1bCAxMiwg MjAxMiBhdCA0OjMyIFBNLCBEYW4gQnJvd24gJmx0OzxhIGhyZWY9Im1haWx0bzpkYnJvd25A Y2VydGljb20uY29tIj5kYnJvd25AY2VydGljb20uY29tPC9hPiZndDsgd3JvdGU6PGJyPg0K Jmd0OyBNYXliZSBzb21lIG9mIHRoZSBITUFDIHNlY3VyaXR5IHByb29mcyBkb24ndCB3b3Jr IGlmIEhNQUMgaXMgdHJ1bmNhdGVkLiAmbmJzcDtXZSBjb3VsZCBhc2sgQ0ZSRyBvciBCZWxs YXJlLjxicj4NCiZndDs8YnI+DQomZ3Q7IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS08 YnI+DQomZ3Q7IEZyb206IFBoaWxsaXAgSGFsbGFtLUJha2VyIFttYWlsdG86PGEgaHJlZj0i bWFpbHRvOmhhbGxhbUBnbWFpbC5jb20iPmhhbGxhbUBnbWFpbC5jb208L2E+XTxicj4NCiZn dDsgU2VudDogV2VkbmVzZGF5LCBKdWx5IDExLCAyMDEyIDA5OjA3IFBNPGJyPg0KJmd0OyBU bzogPGEgaHJlZj0ibWFpbHRvOnNhYWdAaWV0Zi5vcmciPnNhYWdAaWV0Zi5vcmc8L2E+ICZs dDs8YSBocmVmPSJtYWlsdG86c2FhZ0BpZXRmLm9yZyI+c2FhZ0BpZXRmLm9yZzwvYT4mZ3Q7 PGJyPg0KJmd0OyBTdWJqZWN0OiBbc2FhZ10gSG93IGxvbmcgc2hvdWxkIGEgTUFDIGJlPzxi cj4NCiZndDs8YnI+DQomZ3Q7IFllYWgsIHllYWgsIGRpZ2VzdHMsIGJpcnRoZGF5IGF0dGFj aywgeWFkZGEgeWFkZGEuPGJyPg0KJmd0Ozxicj4NCiZndDsgQnV0ISBBIE1BQyBpcyBub3Qg YSBkaWdlc3QsIGl0IGlzIGFuIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbS4gSWYgSTxicj4N CiZndDsgdXNlIEhNQUMtU0hBMjU2IHdpdGggYSAxMjggYml0IGtleSwgSSBhbSBnb2luZyB0 byBoYXZlIG5vIG1vcmUgdGhhbjxicj4NCiZndDsgMTI4IGJpdHMgb2YgZXJnb2RpY2l0eSBp biBteSBvdXRwdXQuIFNvIHdoYXQgaXMgdGhlIGp1c3RpZmljYXRpb24gZm9yPGJyPg0KJmd0 OyBwcmVzZW50aW5nIG1vcmUgdGhhbiAxMjggYml0cz88YnI+DQomZ3Q7PGJyPg0KJmd0OyBO b3cgSSBndWVzcyBzb21lb25lIGNhbiBhcmd1ZSAoT0sgdGhleSB3aWxsKSB0aGF0IEhNQUMt U0hBMjU2IHdpdGggYTxicj4NCiZndDsgMjU2IGJpdCBrZXkgcHJvZHVjZXMgYSBmdWxsIDI1 NiBiaXRzIG9mIGVyZ29kaWNpdHkgaW4gdGhlIG91dHB1dC4gQnV0PGJyPg0KJmd0OyBnaXZl biB0aGF0IHdlIGhhdmUgYWdyZWVkIG9uIDEyOCBiaXRzIGFzICdzdWZmaWNpZW50JyBmb3Ig ZW5jcnlwdGlvbjxicj4NCiZndDsga2V5cyAod2VsbCBmb3IgdGhlIGxpZmV0aW1lIG9mIHRo aXMgdW5pdmVyc2UgYXQgbGVhc3QpIHdoeSB0aGVuIGRlbWFuZDxicj4NCiZndDsgdXAgdG8g NTEyIGZvciBhdXRoZW50aWNhdGlvbj88YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIGtub3cgdGhh dCB0aGVyZSBhcmUgcGVyZmVjdGx5IGdvb2QgcmVhc29ucyBmb3IgdXNpbmcgQUVTLTI1Niwg aXQgaXM8YnI+DQomZ3Q7IG5vdCByZWFsbHkgdGhlIHBvc3NpYmlsaXR5IG9mIGJydXRlIGZv cmNpbmcgdGhlIGtleSB0aGF0IGlzIHRoZSBpc3N1ZTxicj4NCiZndDsgc28gbXVjaCBhcyB0 aGUgZmFjdCB0aGF0IEFFUy01MTIgaGFzIG1hbnkgbW9yZSByb3VuZHMgdGhhbiBBRVMtMTI4 IGFuZDxicj4NCiZndDsgaXMgc3Ryb25nZXIuIEFuZCB3aGVuIHNvbWVvbmUgbGlrZSBBZGkg U2hhbWlyIHN1Z2dlc3RzIEFFUyBtaWdodCBiZSBhPGJyPg0KJmd0OyBsaXR0bGUgb3Zlci1v cHRpbWl6ZWQsIHdlbGwgSSBsaXN0ZW4uPGJyPg0KJmd0Ozxicj4NCiZndDsgV2hhdCB0aGlz IGNvbWVzIGRvd24gdG8gaXMgdGhhdCBJIHRoaW5rIHdlIG5lZWQgYSBITUFDLVNIQTEyOCBh bmQ8YnI+DQomZ3Q7IG1heWJlIHBlb3BsZSB3aG8gYXJlIHJlYWxseSBsb29raW5nIGZvciAy NTYgYml0cyBvZiBhdXRoZW50aWNhdGlvbjxicj4NCiZndDsgc2hvdWxkIGJlIGN1dHRpbmcg SE1BQy1TSEE1MTIgaW4gdHdvLi4uPGJyPg0KJmd0Ozxicj4NCiZndDsgSnVzdCBhIHRob3Vn aHQuPGJyPg0KJmd0Ozxicj4NCiZndDsgLS08YnI+DQomZ3Q7IFdlYnNpdGU6IDxhIGhyZWY9 Imh0dHA6Ly9oYWxsYW1iYWtlci5jb20vIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2hhbGxh bWJha2VyLmNvbS88L2E+PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgc2FhZyBtYWlsaW5nIGxpc3Q8YnI+DQom Z3Q7IDxhIGhyZWY9Im1haWx0bzpzYWFnQGlldGYub3JnIj5zYWFnQGlldGYub3JnPC9hPjxi cj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zYWFnIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zYWFnPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxi cj4NCiZndDsgVGhpcyB0cmFuc21pc3Npb24gKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMp IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiwgcHJpdmlsZWdlZCBtYXRl cmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHByb3RlY3RlZCBieSB0aGUgc29saWNpdG9yLWNs aWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHByaXZpbGVnZXMpLCBvciBjb25zdGl0dXRlIG5v bi1wdWJsaWMgaW5mb3JtYXRpb24uIEFueSB1c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbg0KIGJ5 IGFueW9uZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRl ZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBs ZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBp bmZvcm1hdGlvbiBmcm9tIHlvdXIgc3lzdGVtLiBVc2UsIGRpc3NlbWluYXRpb24sIGRpc3Ry aWJ1dGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgdHJhbnNtaXNzaW9uDQogYnkgdW5p bnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdCBhdXRob3JpemVkIGFuZCBtYXkgYmUgdW5sYXdm dWwuPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCiZndDsgc2FhZyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9 Im1haWx0bzpzYWFnQGlldGYub3JnIj5zYWFnQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWFnIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWFn PC9hPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0Kc2FhZyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c2FhZ0Bp ZXRmLm9yZyI+c2FhZ0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhYWciIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhYWc8L2E+PGJyPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxicj4NCjwvZGl2Pg0KPGJyPg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tIDxicj4NClRoaXMgdHJhbnNtaXNzaW9uIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRz KSBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24sIHByaXZpbGVnZWQgbWF0 ZXJpYWwgKGluY2x1ZGluZyBtYXRlcmlhbCBwcm90ZWN0ZWQgYnkgdGhlIHNvbGljaXRvci1j bGllbnQgb3Igb3RoZXIgYXBwbGljYWJsZSBwcml2aWxlZ2VzKSwgb3IgY29uc3RpdHV0ZSBu b24tcHVibGljIGluZm9ybWF0aW9uLiBBbnkgdXNlIG9mIHRoaXMgaW5mb3JtYXRpb24gYnkg YW55b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVk LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxl YXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIGlu Zm9ybWF0aW9uIGZyb20geW91ciBzeXN0ZW0uIFVzZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJp YnV0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21pc3Npb24gYnkgdW5pbnRl bmRlZCByZWNpcGllbnRzIGlzIG5vdCBhdXRob3JpemVkIGFuZCBtYXkgYmUgdW5sYXdmdWwu DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_810C31990B57ED40B2062BA10D43FBF509A718XMB111CNCrimnet_-- From adam@stoicsecurity.com Thu Jul 12 18:44:02 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 D80CB11E8112 for ; Thu, 12 Jul 2012 18:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=1.144, BAYES_00=-2.599, GB_I_LETTER=-2, SARE_OBFU_PART_ORD=0.952] 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 a10Gr5C5ShCI for ; Thu, 12 Jul 2012 18:44:02 -0700 (PDT) Received: from p3plsmtpa01-09.prod.phx3.secureserver.net (p3plsmtpa01-09.prod.phx3.secureserver.net [72.167.82.89]) by ietfa.amsl.com (Postfix) with SMTP id 028A211E8087 for ; Thu, 12 Jul 2012 18:44:01 -0700 (PDT) Received: (qmail 17735 invoked from network); 13 Jul 2012 01:44:36 -0000 Received: from unknown (50.137.24.91) by p3plsmtpa01-09.prod.phx3.secureserver.net (72.167.82.89) with ESMTP; 13 Jul 2012 01:44:35 -0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Adam W. Montville" In-Reply-To: Date: Thu, 12 Jul 2012 18:44:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FFEA5CF.2050104@cs.tcd.ie> <4FFEE471.40308@cs.tcd.ie> <17445680-7176-440B-ACB3-6960BEA3E255@stoicsecurity.com> <201207121946.PAA26881@Sparkle.Rodents-Montreal.ORG> To: Yoav Nir X-Mailer: Apple Mail (2.1278) Cc: "saag@ietf.org" Subject: Re: [saag] The quest to replace passwords 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, 13 Jul 2012 01:44:03 -0000 On Jul 12, 2012, at 1:05 PM, Yoav Nir wrote: >=20 > On Jul 12, 2012, at 10:46 PM, Mouse wrote: >=20 >>> I'm stepping out of comfort here, but it seems that we could realize = some be$ >>=20 >> I agree. Randall totally nailed this in xkcd #936. >=20 I like that one. > I don't think he did. While there are only a few thousand common words = that might be chosen for the base word, 2^28 is a very large number for = guessing over the 'net. Any system worth its salt won't let an attacker = guess 1000 times a second, and he overestimates the difficulty of = remembering it. >=20 There are nearly 100,000 words in the English language (granted not more = than 10,000 or so are likely to be considered common). And, we're = looking at database leaks, not brute-force. If brute-force were the = only problem, then properly designed systems (and many are not) could = tolerate password lengths of eight with low complexity (just letters and = numbers). > On the other hand, 4 random common words are very hard to remember - = you forget the order, you replace words, and the story you invent = doesn't make sense, and gets mixed up with the stories for last month's = passphrase. People would naturally not choose 4 independently random = words. If the first word is "correct", the next is likely to be either = something that is correct, or another adjective. Not a horse. Writing them down would help here, and that's not necessarily bad advice = anymore. >=20 > Make this the rule for wiki passwords for IETF meetings, and you'll = have more than one instance of "explore strange new worlds", "rough = consensus running code", and maybe even "d**n you perry platypus". These = are the equivalents of "password", "pass1234", and "passw0rd", except = this time, nobody's making us use numerals or symbols and mixed case to = add unpredictability. Completely agree on this. It changes the game somewhat, and the = crackers would need to adjust their tactics. But, what if it could buy = some time in the short-term - until a better solution is available? =20 >=20 > Yoav >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From adam@stoicsecurity.com Thu Jul 12 18:44:52 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 3E6A911E8119 for ; Thu, 12 Jul 2012 18:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 8Nqm2sQdUtzQ for ; Thu, 12 Jul 2012 18:44:51 -0700 (PDT) Received: from p3plsmtpa01-09.prod.phx3.secureserver.net (p3plsmtpa01-09.prod.phx3.secureserver.net [72.167.82.89]) by ietfa.amsl.com (Postfix) with SMTP id CA78111E8087 for ; Thu, 12 Jul 2012 18:44:51 -0700 (PDT) Received: (qmail 18368 invoked from network); 13 Jul 2012 01:45:26 -0000 Received: from unknown (50.137.24.91) by p3plsmtpa01-09.prod.phx3.secureserver.net (72.167.82.89) with ESMTP; 13 Jul 2012 01:45:26 -0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: "Adam W. Montville" In-Reply-To: <4FFEFCBB.9070609@cs.tcd.ie> Date: Thu, 12 Jul 2012 18:45:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9830A2E1-1ADC-4E67-A4F0-23A027B0DB8D@stoicsecurity.com> References: <4FFEA5CF.2050104@cs.tcd.ie> <4FFEE471.40308@cs.tcd.ie> <17445680-7176-440B-ACB3-6960BEA3E255@stoicsecurity.com> <4FFEFCBB.9070609@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1278) Cc: Sam Hartman , "saag@ietf.org" Subject: Re: [saag] The quest to replace passwords 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, 13 Jul 2012 01:44:52 -0000 On Jul 12, 2012, at 9:35 AM, Stephen Farrell wrote: > To be clear though: I don't think the way to replace passwords is > with....passwords:-) Well, why not? We replace keys with=85keys ;-) =20= From adam@stoicsecurity.com Thu Jul 12 19:31:48 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 23CCB11E8087 for ; Thu, 12 Jul 2012 19:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.091 X-Spam-Level: X-Spam-Status: No, score=-3.091 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_00=-2.599, GB_I_LETTER=-2, SARE_OBFU_PART_ORD=0.952] 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 IeAY7uI2XT+u for ; Thu, 12 Jul 2012 19:31:47 -0700 (PDT) Received: from m1plsmtpa01-02.prod.mesa1.secureserver.net (m1plsmtpa01-02.prod.mesa1.secureserver.net [64.202.165.174]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAF611E8085 for ; Thu, 12 Jul 2012 19:31:47 -0700 (PDT) Received: from [192.168.1.5] ([50.137.24.91]) by m1plsmtpa01-02.prod.mesa1.secureserver.net with id ZeYL1j0091xvdQ201eYM9w; Thu, 12 Jul 2012 19:32:21 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: "Adam W. Montville" In-Reply-To: Date: Thu, 12 Jul 2012 19:32:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3F2E9037-2298-44F4-B5F2-CE311DE7AAB1@stoicsecurity.com> References: <4FFEA5CF.2050104@cs.tcd.ie> <4FFEE471.40308@cs.tcd.ie> <17445680-7176-440B-ACB3-6960BEA3E255@stoicsecurity.com> <201207121946.PAA26881@Sparkle.Rodents-Montreal.ORG> To: Yoav Nir X-Mailer: Apple Mail (2.1278) Cc: "saag@ietf.org" Subject: Re: [saag] The quest to replace passwords 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, 13 Jul 2012 02:31:48 -0000 On Jul 12, 2012, at 6:44 PM, Adam W. Montville wrote: >=20 > On Jul 12, 2012, at 1:05 PM, Yoav Nir wrote: >=20 >>=20 >> On Jul 12, 2012, at 10:46 PM, Mouse wrote: >>=20 >>>> I'm stepping out of comfort here, but it seems that we could = realize some be$ >>>=20 >>> I agree. Randall totally nailed this in xkcd #936. >>=20 >=20 > I like that one. >=20 >> I don't think he did. While there are only a few thousand common = words that might be chosen for the base word, 2^28 is a very large = number for guessing over the 'net. Any system worth its salt won't let = an attacker guess 1000 times a second, and he overestimates the = difficulty of remembering it. >>=20 >=20 > There are nearly 100,000 words in the English language (granted not = more than 10,000 or so are likely to be considered common). And, we're = looking at database leaks, not brute-force. If brute-force were the = only problem, then properly designed systems (and many are not) could = tolerate password lengths of eight with low complexity (just letters and = numbers). Typed too fast on that one - potentially about 1 million words=85 http://www.slate.com/articles/life/the_good_word/2006/04/word_count.html >=20 >> On the other hand, 4 random common words are very hard to remember - = you forget the order, you replace words, and the story you invent = doesn't make sense, and gets mixed up with the stories for last month's = passphrase. People would naturally not choose 4 independently random = words. If the first word is "correct", the next is likely to be either = something that is correct, or another adjective. Not a horse. >=20 > Writing them down would help here, and that's not necessarily bad = advice anymore. >=20 >>=20 >> Make this the rule for wiki passwords for IETF meetings, and you'll = have more than one instance of "explore strange new worlds", "rough = consensus running code", and maybe even "d**n you perry platypus". These = are the equivalents of "password", "pass1234", and "passw0rd", except = this time, nobody's making us use numerals or symbols and mixed case to = add unpredictability. >=20 > Completely agree on this. It changes the game somewhat, and the = crackers would need to adjust their tactics. But, what if it could buy = some time in the short-term - until a better solution is available? =20 >=20 >>=20 >> Yoav >>=20 >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From joelja@bogus.com Thu Jul 12 20:20: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 635BF21F85CD for ; Thu, 12 Jul 2012 20:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.023 X-Spam-Level: X-Spam-Status: No, score=-103.023 tagged_above=-999 required=5 tests=[AWL=0.624, BAYES_00=-2.599, GB_I_LETTER=-2, SARE_OBFU_PART_ORD=0.952, 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 9W1U+GSeYEY7 for ; Thu, 12 Jul 2012 20:20:14 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1C93521F85C0 for ; Thu, 12 Jul 2012 20:20:10 -0700 (PDT) Received: from Joels-MacBook-Pro.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q6D3KZxt072254 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 13 Jul 2012 03:20:35 GMT (envelope-from joelja@bogus.com) Message-ID: <4FFF9402.8030607@bogus.com> Date: Thu, 12 Jul 2012 20:20:34 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Adam W. Montville" References: <4FFEA5CF.2050104@cs.tcd.ie> <4FFEE471.40308@cs.tcd.ie> <17445680-7176-440B-ACB3-6960BEA3E255@stoicsecurity.com> <201207121946.PAA26881@Sparkle.Rodents-Montreal.ORG> <3F2E9037-2298-44F4-B5F2-CE311DE7AAB1@stoicsecurity.com> In-Reply-To: <3F2E9037-2298-44F4-B5F2-CE311DE7AAB1@stoicsecurity.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 13 Jul 2012 03:20:37 +0000 (UTC) Cc: "saag@ietf.org" Subject: Re: [saag] The quest to replace passwords 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, 13 Jul 2012 03:20:15 -0000 On 7/12/12 19:32 , Adam W. Montville wrote: > > On Jul 12, 2012, at 6:44 PM, Adam W. Montville wrote: > >> >> On Jul 12, 2012, at 1:05 PM, Yoav Nir wrote: >> >>> >>> On Jul 12, 2012, at 10:46 PM, Mouse wrote: >>> >>>>> I'm stepping out of comfort here, but it seems that we could realize some be$ >>>> >>>> I agree. Randall totally nailed this in xkcd #936. >>> >> >> I like that one. >> >>> I don't think he did. While there are only a few thousand common words that might be chosen for the base word, 2^28 is a very large number for guessing over the 'net. Any system worth its salt won't let an attacker guess 1000 times a second, and he overestimates the difficulty of remembering it. >>> >> >> There are nearly 100,000 words in the English language (granted not more than 10,000 or so are likely to be considered common). And, we're looking at database leaks, not brute-force. If brute-force were the only problem, then properly designed systems (and many are not) could tolerate password lengths of eight with low complexity (just letters and numbers). > > Typed too fast on that one - potentially about 1 million words… > > http://www.slate.com/articles/life/the_good_word/2006/04/word_count.html >From a slide I present about once a year. How good does a password/phrase have to be in order to protect against brute-force or dictionary attacks against the password itself? ◠Entropy found in language. – A typical english sentence has 1.2 bits of entropy per character, you need 107 characters to get a statistically random md5 hash. – Using totally random english characters you need 28 characters. – Using a random distribution of all 95 printable ascii characters you need 20 characters. * Derived from the PGP passphrase faq >> >>> On the other hand, 4 random common words are very hard to remember - you forget the order, you replace words, and the story you invent doesn't make sense, and gets mixed up with the stories for last month's passphrase. People would naturally not choose 4 independently random words. If the first word is "correct", the next is likely to be either something that is correct, or another adjective. Not a horse. >> >> Writing them down would help here, and that's not necessarily bad advice anymore. >> >>> >>> Make this the rule for wiki passwords for IETF meetings, and you'll have more than one instance of "explore strange new worlds", "rough consensus running code", and maybe even "d**n you perry platypus". These are the equivalents of "password", "pass1234", and "passw0rd", except this time, nobody's making us use numerals or symbols and mixed case to add unpredictability. >> >> Completely agree on this. It changes the game somewhat, and the crackers would need to adjust their tactics. But, what if it could buy some time in the short-term - until a better solution is available? >> >>> >>> Yoav >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From hugokraw@gmail.com Thu Jul 12 20:37: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 A641B11E80D6 for ; Thu, 12 Jul 2012 20:37:05 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdK9jryrzzRv for ; Thu, 12 Jul 2012 20:37:04 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 245CE11E809A for ; Thu, 12 Jul 2012 20:37:04 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so4538018obb.31 for ; Thu, 12 Jul 2012 20:37:39 -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:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=z73VByi23kEwEBrm68k0bzyg1KD5QQdnaxKbcUkIsMk=; b=l2qw2YiY74cbwVXuvmOTrxT5ARC/6wft3PkCXrTYF9tmeOu9Mmu7cmzBe3L8/PnoIY kNOmZhhyuPUUewBwWqCliuYt8PxI71agVsgopbncZxx2tFBp2Yri8HzqDFeiHGegrtXL 2qFu0X9+hoQuGUqIk6035r9UWl2d/oSRGicG6S74IoSAUhqZ53SPHuIVjwD94BOtn29Y ZjtGfe7EuoUKjFoQV6RoChKofAXUIcvdFfABH8//51T/jwvW++QcacdQbWLiHL1SZOkL bhR2zGQfP6lc2KA0YWMWeuJZG9JeVcD1yS0BnXZeKLj8GARVoQ8NwVt9sqX76tqDWwND koVQ== Received: by 10.182.212.36 with SMTP id nh4mr928813obc.37.1342150658791; Thu, 12 Jul 2012 20:37:38 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.182.125.97 with HTTP; Thu, 12 Jul 2012 20:37:18 -0700 (PDT) In-Reply-To: <810C31990B57ED40B2062BA10D43FBF509A718@XMB111CNC.rim.net> References: <810C31990B57ED40B2062BA10D43FBF509A718@XMB111CNC.rim.net> From: Hugo Krawczyk Date: Thu, 12 Jul 2012 23:37:18 -0400 X-Google-Sender-Auth: YwJYkR_jBEVaNaIbOADt-sApkkg Message-ID: To: Dan Brown Content-Type: multipart/alternative; boundary=e89a8f642902409ad704c4adcdc4 Cc: "hallam@gmail.com" , "saag@ietf.org" Subject: Re: [saag] How long should a MAC be? 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, 13 Jul 2012 03:37:05 -0000 --e89a8f642902409ad704c4adcdc4 Content-Type: text/plain; charset=UTF-8 RFC 2104 doesn't say what the security of SHA256 (or of any other function) is. There is one fact, however, that does not depend on the underlying function (or even on HMAC): a MAC tag of length t, even a perfect one, does not give more than t bits of security as the attacker can guess the MAC value with probability 2^{-t} (and of course the attacker's advantage increases linearly with the number of MACed messages or the number of possible guesses by the attacker). Hugo On Thu, Jul 12, 2012 at 9:21 PM, Dan Brown wrote: > So, in terms of security levels, does what RFC 2104 says mean that > HMAC-SHA256 provides 256-bit security, while truncating to 128 bits > provides 128-bit security? Or does HMAC-SHA256 only provide 128 security? > > > > *From*: Hugo Krawczyk [mailto:hugo@ee.technion.ac.il] > *Sent*: Thursday, July 12, 2012 09:05 PM > *To*: Eric Rescorla > *Cc*: Dan Brown; hallam@gmail.com ; saag@ietf.org < > saag@ietf.org> > *Subject*: Re: [saag] How long should a MAC be? > > On Thu, Jul 12, 2012 at 7:38 PM, Eric Rescorla wrote: > > Given that Bellare is a co-author on RFC 2104 and 2104 describes > truncation, > > I would certainly be sad to learn truncation wasn't OK. > > > > -Ekr > > No reason to be sad, Eric. > > The text for HMAC truncation in RFC 2104 (see below) still holds. > Confidence in this mechanism is even stronger today given the proofs (and > practical acceptance) of HMAC as a pseudo-random function [1,2,3]. This > means that any subset of t bits from HMAC's output should be > computationally indistinguishable from t random bits, therefore suitable > for MAC (the security should be considered the minimum between the length > of the MAC and the security of HMAC, typically given by half the size of > the hash length). > > [1] M. Bellare, R. Canetti, and H. Krawczyk, "Keying Hash Functions for > Message Authentication", Crypto 1996. > > [2] M. Bellare, R. Canetti, and H. Krawczyk, "Pseudorandom Functions > Revisited: The Cascade Construction", Proceedings of FOCS'96. > > [3] M. Bellare "New Proofs for NMAC and HMAC: Security without > Collision-Resistance", Crypto 2006. > > Here is the original text from the RFC > > 5. Truncated output > > A well-known practice with message authentication codes is to > truncate the output of the MAC and output only part of the bits > (e.g., [MM, ANSI]). Preneel and van Oorschot [PV] show some > analytical advantages of truncating the output of hash-based MAC > functions. The results in this area are not absolute as for the > overall security advantages of truncation. It has advantages (less > information on the hash result available to an attacker) and > disadvantages (less bits to predict for the attacker). Applications > of HMAC can choose to truncate the output of HMAC by outputting the t > leftmost bits of the HMAC computation for some parameter t (namely, > the computation is carried in the normal way as defined in section 2 > above but the end result is truncated to t bits). We recommend that > the output length t be not less than half the length of the hash > output (to match the birthday attack bound) and not less than 80 bits > (a suitable lower bound on the number of bits that need to be > predicted by an attacker). > > Hugo > > > >> On Thu, Jul 12, 2012 at 4:32 PM, Dan Brown wrote: >> > Maybe some of the HMAC security proofs don't work if HMAC is truncated. >> We could ask CFRG or Bellare. >> > >> > ----- Original Message ----- >> > From: Phillip Hallam-Baker [mailto:hallam@gmail.com] >> > Sent: Wednesday, July 11, 2012 09:07 PM >> > To: saag@ietf.org >> > Subject: [saag] How long should a MAC be? >> > >> > Yeah, yeah, digests, birthday attack, yadda yadda. >> > >> > But! A MAC is not a digest, it is an authentication mechanism. If I >> > use HMAC-SHA256 with a 128 bit key, I am going to have no more than >> > 128 bits of ergodicity in my output. So what is the justification for >> > presenting more than 128 bits? >> > >> > Now I guess someone can argue (OK they will) that HMAC-SHA256 with a >> > 256 bit key produces a full 256 bits of ergodicity in the output. But >> > given that we have agreed on 128 bits as 'sufficient' for encryption >> > keys (well for the lifetime of this universe at least) why then demand >> > up to 512 for authentication? >> > >> > I know that there are perfectly good reasons for using AES-256, it is >> > not really the possibility of brute forcing the key that is the issue >> > so much as the fact that AES-512 has many more rounds than AES-128 and >> > is stronger. And when someone like Adi Shamir suggests AES might be a >> > little over-optimized, well I listen. >> > >> > What this comes down to is that I think we need a HMAC-SHA128 and >> > maybe people who are really looking for 256 bits of authentication >> > should be cutting HMAC-SHA512 in two... >> > >> > Just a thought. >> > >> > -- >> > Website: http://hallambaker.com/ >> > _______________________________________________ >> > saag mailing list >> > saag@ietf.org >> > https://www.ietf.org/mailman/listinfo/saag >> > >> > --------------------------------------------------------------------- >> > This transmission (including any attachments) may contain confidential >> information, privileged material (including material protected by the >> solicitor-client or other applicable privileges), or constitute non-public >> information. Any use of this information by anyone other than the intended >> recipient is prohibited. If you have received this transmission in error, >> please immediately reply to the sender and delete this information from >> your system. Use, dissemination, distribution, or reproduction of this >> transmission by unintended recipients is not authorized and may be unlawful. >> > _______________________________________________ >> > 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 >> > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be > unlawful. > --e89a8f642902409ad704c4adcdc4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable RFC 2104 doesn't say what the s= ecurity of SHA256 (or of any other function) is.

There is one fact,= however, that does not depend on the underlying function (or even on HMAC)= : a MAC tag of length t, even a perfect one, does not give more than t bits= of security=C2=A0 as the attacker can guess the MAC value with probability= 2^{-t} (and of course the attacker's advantage increases linearly with= the number of MACed messages or the number of possible guesses by the atta= cker).

Hugo

On Thu, Jul 12, 20= 12 at 9:21 PM, Dan Brown <dbrown@certicom.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
So, in terms of security levels, does what RFC 2= 104 says mean that HMAC-SHA256 provides 256-bit security, while truncating = to 128 bits provides 128-bit security? Or does HMAC-SHA256 only provide 128 security?


=C2=A0
From: Hugo Krawczyk [mailto:hugo@ee.technion.ac.il]
Sent: Thursday, July 12, 2012 09:05 PM
To: Eric Rescorla <ekr@rtfm.com>
Cc: Dan Brown; hallam@gmail.com <hallam@gmail.com>; saag@ietf.org <saag@ietf.org>
Subject: Re: [saag] How long should a MAC be?
=C2=A0
On Thu, Jul 12, 2012 at 7:38 PM, Eric Rescorla <ekr@rtfm.com> wro= te:
> Given that Bellare is a co-author on RFC 2104 and 2104 describes trunc= ation,
> I would certainly be sad to learn truncation wasn't OK.
>
> -Ekr

No reason to be sad, Eric.

The text for HMAC truncation in RFC= 2104 (see below) still holds. Confidence in this mechanism is even stronge= r today given the proofs (and practical acceptance) of HMAC as a pseudo-ran= dom function [1,2,3]. This means that any subset of t bits from HMAC's output should be computationally indi= stinguishable from t random bits, therefore suitable for MAC (the security = should be considered the minimum between the length of the MAC and the secu= rity of HMAC, typically given by half the size of the hash length).

[1] M. Bellare, R. Canetti, and H. Krawczyk, "Keying Hash Functions fo= r Message Authentication", Crypto 1996.

[2] M. Bellare, R. Canetti, and H. Krawczyk, "Pseudorandom Functions R= evisited: The Cascade Construction", Proceedings of FOCS'96.

[3] M. Bellare "New Proofs for NMAC and HMAC: Security without Collisi= on-Resistance", Crypto 2006.

Here is the original text from the RFC

 
 5. Trunc=
ated output

   A well-known practice with message authentication codes is to
   truncate the output of the MAC and output only part of the bits
   (e.g., [MM, ANSI]).  Preneel and van Oorschot [PV] show some
   analytical advantages of truncating the output of hash-based MAC
   functions. The results in this area are not absolute as for the
   overall security advantages of truncation. It has advantages (less
   information on the hash result available to an attacker) and
   disadvantages (less bits to predict for the attacker).  Applications
   of HMAC can choose to truncate the output of HMAC by outputting the t
   leftmost bits of the HMAC computation for some parameter t (namely,
   the computation is carried in the normal way as defined in section 2
   above but the end result is truncated to t bits). We recommend that
   the output length t be not less than half the length of the hash
   output (to match the birthday attack bound) and not less than 80 bits
   (a suitable lower bound on the number of bits that need to be
   predicted by an attacker).

Hugo



On Thu, Jul 12, 2012 at 4:32 PM, Dan Brown <dbrown@certicom.com> wrote:
> Maybe some of the HMAC security proofs don't work if HMAC is trunc= ated. =C2=A0We could ask CFRG or Bellare.
>
> ----- Original Message -----
> From: Phillip Hallam-Baker [mailto:hallam@gmail.com]
> Sent: Wednesday, July 11, 2012 09:07 PM
> To: saag@ietf.org <saag@ietf.org= >
> Subject: [saag] How long should a MAC be?
>
> Yeah, yeah, digests, birthday attack, yadda yadda.
>
> But! A MAC is not a digest, it is an authentication mechanism. If I > use HMAC-SHA256 with a 128 bit key, I am going to have no more than > 128 bits of ergodicity in my output. So what is the justification for<= br> > presenting more than 128 bits?
>
> Now I guess someone can argue (OK they will) that HMAC-SHA256 with a > 256 bit key produces a full 256 bits of ergodicity in the output. But<= br> > given that we have agreed on 128 bits as 'sufficient' for encr= yption
> keys (well for the lifetime of this universe at least) why then demand=
> up to 512 for authentication?
>
> I know that there are perfectly good reasons for using AES-256, it is<= br> > not really the possibility of brute forcing the key that is the issue<= br> > so much as the fact that AES-512 has many more rounds than AES-128 and=
> is stronger. And when someone like Adi Shamir suggests AES might be a<= br> > little over-optimized, well I listen.
>
> What this comes down to is that I think we need a HMAC-SHA128 and
> maybe people who are really looking for 256 bits of authentication
> should be cutting HMAC-SHA512 in two...
>
> Just a thought.
>
> --
> Website: http://= hallambaker.com/
> _______________________________________________
> saag mailing list
> saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag
>
> ---------------------------------------------------------------------<= br> > This transmission (including any attachments) may contain confidential= information, privileged material (including material protected by the soli= citor-client or other applicable privileges), or constitute non-public info= rmation. Any use of this information by anyone other than the intended recipient is prohibited. If you have rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
> _______________________________________________
> saag mailing list
> saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag
_______________________________________________
saag mailing list
saag@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/saag


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful.

--e89a8f642902409ad704c4adcdc4-- From stephen.farrell@cs.tcd.ie Fri Jul 13 05:11: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 05C8921F86E2 for ; Fri, 13 Jul 2012 05:11:38 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0hXska7pV7J for ; Fri, 13 Jul 2012 05:11:37 -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 3B09821F86C6 for ; Fri, 13 Jul 2012 05:11:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 2812C153C60; Fri, 13 Jul 2012 13:12:12 +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=1342181531; bh=tc6ruJfEej+IHJ dsgK605hgA7U5aRHb9qZrGTmIICFI=; b=QMLiIyZM/8ix/ZmPWrZQAb7YmjK0GW QIlRBu9alPxqoH3E1NUgvVaCMXxMr9XzkyQqQGvdb4UP3nWKTopbdNKK+yFlD5h7 ilIELbNJMSuq1rA5jLUADH3ChEFFFrhOprHu305RZYw3lnzjvFxAzmjlIPQ5+KHd nskwRxphouLEzXYq/t8JjCufTXt5d0OxtFsqcTuKZmH16ugOaTqT7ht2YmCkUIiM B6Hvy6MUyaRIhMsbAkFzJ2sbWLbNKLxT6/6/uDvTvtnw402WA4DINLrJcy8a8l8D K1BNAc6xU7wEK4pHwvjcWtfxoReZvTnd09CUR/MTV4ehmALu9cSCjpsw== 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 RPBZiBAHWiVk; Fri, 13 Jul 2012 13:12:11 +0100 (IST) Received: from [IPv6:2001:770:10:203:256d:260a:c650:4b1] (unknown [IPv6:2001:770:10:203:256d:260a:c650:4b1]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6229C153C5E; Fri, 13 Jul 2012 13:12:10 +0100 (IST) Message-ID: <5000109A.9030403@cs.tcd.ie> Date: Fri, 13 Jul 2012 13:12:10 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Adam W. Montville" References: <4FFEA5CF.2050104@cs.tcd.ie> <4FFEE471.40308@cs.tcd.ie> <17445680-7176-440B-ACB3-6960BEA3E255@stoicsecurity.com> <4FFEFCBB.9070609@cs.tcd.ie> <9830A2E1-1ADC-4E67-A4F0-23A027B0DB8D@stoicsecurity.com> In-Reply-To: <9830A2E1-1ADC-4E67-A4F0-23A027B0DB8D@stoicsecurity.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "saag@ietf.org" Subject: Re: [saag] The quest to replace passwords 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, 13 Jul 2012 12:11:38 -0000 On 07/13/2012 02:45 AM, Adam W. Montville wrote: > > On Jul 12, 2012, at 9:35 AM, Stephen Farrell wrote: > >> To be clear though: I don't think the way to replace passwords is >> with....passwords:-) > > Well, why not? We replace keys with…keys ;-) Well, I meant replacing a password-based mechanism with another password-based mechanism is not what I think we want to do. Replacing one password with another is of course a fine thing to do sometimes. (As in today, for another 1M account holders. [1] ) S. [1] http://www.zdnet.com/android-forums-hacked-1-million-user-credentials-stolen-7000000817/ From adam@stoicsecurity.com Fri Jul 13 06:12: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 7D22C21F8839 for ; Fri, 13 Jul 2012 06:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.706 X-Spam-Level: X-Spam-Status: No, score=-2.706 tagged_above=-999 required=5 tests=[AWL=-0.107, 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 havB0eTldycq for ; Fri, 13 Jul 2012 06:12:14 -0700 (PDT) Received: from smtpauth12.prod.mesa1.secureserver.net (smtpauth12.prod.mesa1.secureserver.net [64.202.165.35]) by ietfa.amsl.com (Postfix) with SMTP id DCA3621F8830 for ; Fri, 13 Jul 2012 06:12:13 -0700 (PDT) Received: (qmail 17935 invoked from network); 13 Jul 2012 13:12:49 -0000 Received: from unknown (50.137.24.91) by smtpauth12.prod.mesa1.secureserver.net (64.202.165.35) with ESMTP; 13 Jul 2012 13:12:49 -0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: "Adam W. Montville" In-Reply-To: <5000109A.9030403@cs.tcd.ie> Date: Fri, 13 Jul 2012 06:12:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <44080A4D-323D-4411-8012-C69A453850D7@stoicsecurity.com> References: <4FFEA5CF.2050104@cs.tcd.ie> <4FFEE471.40308@cs.tcd.ie> <17445680-7176-440B-ACB3-6960BEA3E255@stoicsecurity.com> <4FFEFCBB.9070609@cs.tcd.ie> <9830A2E1-1ADC-4E67-A4F0-23A027B0DB8D@stoicsecurity.com> <5000109A.9030403@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1278) Cc: "saag@ietf.org" Subject: Re: [saag] The quest to replace passwords 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, 13 Jul 2012 13:12:15 -0000 On Jul 13, 2012, at 5:12 AM, Stephen Farrell wrote: >=20 >=20 > On 07/13/2012 02:45 AM, Adam W. Montville wrote: >>=20 >> On Jul 12, 2012, at 9:35 AM, Stephen Farrell wrote: >>=20 >>> To be clear though: I don't think the way to replace passwords is >>> with....passwords:-) >>=20 >> Well, why not? We replace keys with=85keys ;-) =20 >=20 > Well, I meant replacing a password-based mechanism > with another password-based mechanism is not what I > think we want to do. >=20 > Replacing one password with another is of course a fine > thing to do sometimes. (As in today, for another 1M > account holders. [1] ) Point. >=20 > S. >=20 > [1] > = http://www.zdnet.com/android-forums-hacked-1-million-user-credentials-stol= en-7000000817/ From prvs=954108c3cd=dbrown@certicom.com Fri Jul 13 10:28: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 C447A21F8736 for ; Fri, 13 Jul 2012 10:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.623 X-Spam-Level: X-Spam-Status: No, score=-4.623 tagged_above=-999 required=5 tests=[AWL=-1.045, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] 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 GCUe1CxrwHQA for ; Fri, 13 Jul 2012 10:27:57 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 994EF21F8732 for ; Fri, 13 Jul 2012 10:27:56 -0700 (PDT) X-AuditID: 0a41282f-b7fe56d000007bb5-6a-50005abd8359 Received: from XCT102CNC.rim.net (xct102cnc.rim.net [10.65.161.202]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs060cnc.rim.net (SBG) with SMTP id 33.A9.31669.DBA50005; Fri, 13 Jul 2012 17:28:30 +0000 (GMT) Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT102CNC.rim.net ([fe80::2066:5d4f:8c45:af55%17]) with mapi id 14.02.0298.004; Fri, 13 Jul 2012 13:28:29 -0400 From: Dan Brown To: 'Hugo Krawczyk' Thread-Topic: [saag] How long should a MAC be? Thread-Index: AQHNX8qwy5MebXb55USchhFnivaxXZcmTZ/ZgABEyYCAABhWgP//wT+agABpFgCAAIZNMA== Date: Fri, 13 Jul 2012 17:28:28 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF509A961@XMB111CNC.rim.net> References: <810C31990B57ED40B2062BA10D43FBF509A718@XMB111CNC.rim.net> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.246] Content-Type: multipart/related; boundary="_004_810C31990B57ED40B2062BA10D43FBF509A961XMB111CNCrimnet_"; type="multipart/alternative" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCJsWRmVeSWpSXmKPExsXC5bjwlO6+KIYAgycTuCxWvD7HbnF1+XEm i6evpjNbTOnvZHJg8dg+7SG7x85Zd9k9liz5yeQx+XEbcwBLVAOjTVJiSVlwZnqevp1NYl5e fkliSapCSmpxsq2ST2p6Yo5CQFFmWWJypYJLZnFyTmJmbmqRkkJmiq2SiZJCQU5icmpual6J rVJiQUFqXoqSHZcCBrABKsvMU0jNS85PycxLt1XyDPbXtbAwtdQ1VLLTTejkyfh18AtTQf8R 5ooJS++wNjC272DuYuTkkBAwkWj70sEGYYtJXLi3Hsjm4hAS6GOSaP/VxgrhbGWUuLLnPFgH m4CqxP2j58BsEQEdibnLN4J1MwtkS0zs2c8OYgsL6Eoc2zOJBaJGT2LL0fOsEHaYxLEzEDYL 0JzVDzeA1fMKuEnsWz8TavMVRokvl14DNXNwcAoESmzcYA5SwyggK7H77HUmiF3iEreezGeC uFpE4uHF01AfiEq8fPyPFcJWlHhy8hoLyExmgU5GiWOXFzNCLBOUODnzCcsERtFZSGbNQlY3 C0kdRFGuxO6bfayzgG5iFtCUWL9LHyKsKDGl+yE7hK0h0TpnLjumuI7E5ks7WWDibZ2zoXYt ZZTo2rSYFaZo4um7KJoXMPKuYhTMzSg2MDNIzkvWK8rM1ctLLdnECE6MGvo7GPv2ah1iFOBg VOLh/RXJECDEmlhWXJl7iFGCg1lJhFfHGCjEm5JYWZValB9fVJqTWnyIMR4Y7hOZpbiT84FJ O68k3tjAgByOkjjvIfbP/kIC6cCUnJ2aWpBaBLOBiYMT5AIuKZFiYGJNLUosLcmIB6X/+GJg BpBqYPSfYMm/ddmB3R0Lpy82SvqaeqKy5OjD/A36a7zFhdQP2Jfbq5nI3ZwfnTBrX2/INbeQ Se8Tgy2V04KP5M1zOiOo1mXY/Sb315+rEc1bLNmOHflk2Dr/OsO78xPn3qywt352j2f7Uykd B7vXzXenhPslsAbXZzvqHdecWjdpwnXNff5bFh+bbKPEUpyRaKjFXFScCAA70+YH5wMAAA== Cc: "hallam@gmail.com" , "saag@ietf.org" Subject: Re: [saag] How long should a MAC be? 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, 13 Jul 2012 17:28:00 -0000 --_004_810C31990B57ED40B2062BA10D43FBF509A961XMB111CNCrimnet_ Content-Type: multipart/alternative; boundary="_000_810C31990B57ED40B2062BA10D43FBF509A961XMB111CNCrimnet_" --_000_810C31990B57ED40B2062BA10D43FBF509A961XMB111CNCrimnet_ Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 UmVnYXJkaW5nIEhNQUMgc2VjdXJpdHkgbGV2ZWxzLCBOSVNUIHNheXMgWzRdIHRoYXQgSE1B Qy1TSEExIHByb3ZpZGVzIDEyOCBiaXQgc2VjdXJpdHkgYW5kIEhNQUMtU0hBMjU2IHByb3Zp ZGVzIDI1Ni1iaXQgc2VjdXJpdHkgKHByZXN1bWFibHkgd2l0aCBhIDI1Ni1iaXQga2V5KS4N Cg0KSHVnbywgd291bGQgeW91IGFncmVlPyAgQXJlIHRoZXNlIGxldmVscyBzdXBwb3J0ZWQg YnkgcHJvb2ZzPyAgRG8gdGhlIHJlY2VudCBTSEEtMSBjb2xsaXNpb24tYWxnb3JpdGhtcyBh ZmZlY3QgdGhpcz8NCg0KSW4geW91ciByZWZlcmVuY2UgWzFdLCBSZW1hcmsgNC44IGRpc2N1 c3NlcyB0cnVuY2F0aW9uLCBidXQgc2VlbXMgdG8gc3VnZ2VzdCBlcXVpdmFsZW50IHNlY3Vy aXR5IGZvciBhIGhhbGYtbGVuZ3RoIHRydW5jYXRlZCBITUFDLCBjaXRpbmcgZnJvbSBTZWN0 aW9uIDYgYSAxMjgtYml0IChiaXJ0aGRheSkgYXR0YWNrIG9uIEhNQUMtU0hBMjU2IChyZWdh cmRsZXNzIG9mIHRydW5jYXRpb24pLiAgU2VjdGlvbiA2IHdvdWxkIHN1Z2dlc3QgdGhhdCB1 bi10cnVuY2F0ZWQgSE1BQy1TSEEyNTYgY2FuIG9ubHkgcHJvdmlkZSAxMjgtYml0IHNlY3Vy aXR5LiAgIEJ1dCwgb24gdGhlIG90aGVyIGhhbmQsIHRoaXMgYXR0YWNrIHJlcXVpcmVzIG9i dGFpbmluZyAyXjEyOCBNQUMgdGFncywgc28gdGhlIGF0dGFjayBpcyB2ZXJ5IGltcHJhY3Rp Y2FsLiAgSXMgdGhlIGF0dGFjayBzbyBpbXByYWN0aWNhbCB0aGF0IG9uZSBjYW4gaWdub3Jl IGFuZCBkZWVtIEhNQUMtU0hBMjU2IGFzIHByb3ZpZGluZyAyNTYtYml0IHNlY3VyaXR5IChh cyBOSVNUIGRvZXMpPw0KDQpSZWdhcmRpbmcgcHJvdmFibGUgc2VjdXJpdHksIGFzIGl0IHVu ZGVyc3RhbmQgaXQsIHRoZSBwcm9vZiBpbiBbMV0gYW5kIFJlbWFyayA0LjYsIGltcGxpZXMg dGhhdCB0cnVuY2F0ZWQgSE1BQyBpcyBzZWN1cmUgaWYgdGhlIHRydW5jYXRlZCBjb21wcmVz c2lvbiBmdW5jdGlvbiBpcyBhIHNlY3VyZSBhcyBNQUMuICBUaGUgTUFDLXNlY3VyaXR5IG9m IHRoZSAodHJ1bmNhdGVkKSBjb21wcmVzc2lvbiBmdW5jdGlvbiBpdHNlbGYgaXMgbm90IHBy b3ZlbiAob3IgaXMgaXQgbGF0ZXIgaW4gQmVsbGFyZeKAmXMgZm9sbG93LXVwIHdvcms/KSwg YnV0IG9mIGNvdXJzZSB3ZSBtYXkgc3RpbGwgaGF2ZSBjb25maWRlbmNlIGluIGl0Lg0KDQpB bHNvLCBoYXNu4oCZdCB0aGUgd2VhayBjb2xsaXNpb24gcmVzaXN0YW5jZSBwcm9wZXJ0eSwg dXBvbiB3aGljaCBbMV0gcmVsaWVzLCBmb3IgU0hBLTEgYmVlbiB1bmRlcm1pbmVkPw0KDQpN ZW5lemVzIGFuZCBLb2JsaXR6IFs1LCBTZWN0aW9uIDRdIG5vdGUgdGhhdCB0aGUgYWR2YW50 YWdlIG9mIHRhZyB0cnVuY2F0aW9uIGluIHNvbWUgY2FzZXMgbWlnaHQgbm90IGJlIGFzIG11 Y2ggYXMgcHJldmlvdXNseSB0aG91Z2h0Lg0KDQoqKioNCg0KUGhpbGxpcCBvcmlnaW5hbGx5 IGFza2VkIGFib3V0IHRoZSBuZWVkIGZvciBITUFDLVNIQTI1NiwgYW5kIHNwZWNpZmljYWxs eSBtZW50aW9uaW5nIHRoZSBNQUMgdGFnIGxlbmd0aCwgYnV0IGhpcyBxdWVzdGlvbiBjb3Vs ZCBhbHNvIGJlIHRha2VuIGFzIGEgcXVlc3Rpb24gZm9yIHRoZSBuZWVkIGZvciAyNTYtYml0 IHNlY3VyaXR5IHZzLiAxMjgtYml0IHNlY3VyaXR5LiAgTGV04oCZcyBzdXBwb3NlIHRoYXQg MTI4LWJpdCBzZWN1cml0eSBpcyBzdWZmaWNpZW50LiAgU29tZSByZWFzb25zIGZvciBvcHRp bmcgZm9yIGEgaGlnaGVyIHNlY3VyaXR5IGxldmVsIChhdCBsZWFzdCBmb3IgSE1BQykgaW5j bHVkZSB0aGUgZm9sbG93aW5nLg0KDQotTWFyZ2luIG9mIGVycm9yLCBpbiBjYXNlIHRoZSBh bGdvcml0aG1zIGVuZCB1cCBiZWluZyB3ZWFrZXIgdGhhbiBvbmUgd291bGQgdGhpbmsgKGUu Zy4gTUQ1LCBTSEEtMSkuDQoNCi1SZXNpc3RhbmNlIHRvIHF1YW50dW0gY29tcHV0ZXJzIChl aXRoZXIgbm93IG9yIGluIHRoZSBmdXR1cmUpLiAgRnV0dXJlIGFkdmVyc2FyaWVzIGNhbm5v dCBmb3JnZSBNQUNzIHRvZGF5LCBidXQgaWYgYWxsIHRoZSBrZXlzIGFyZSAxMjggYml0cywg dGhleSBjYW4sIGF0IGEgY29zdCBhYm91dCAyXjY0IHF1YW50dW0gY29tcHV0ZXIgc3RlcHMs IHJlY292ZXIgYSBNQUMga2V5cyBmcm9tIHRoZSBtZXNzYWdlIGFuZCB0YWcsIGFuZCB0aGVu IHJlY292ZXIgdGhlIG1hc3RlciBrZXkgZnJvbSB0aGUgTUFDIGlzIG9mdGVuIGRlcml2ZWQs IGFuZCB0aGVuIHJlY292ZXIgdGhlIGVuY3J5cHRpb24ga2V5LCBhbmQgdGhlcmVieSBjb21w cm9taXNlIGFueSBvZiB0b2RheeKAmXMgY2lwaGVydGV4dHMgdGhhdCB0aGV5IGhhdmUgc3Rv cmVkLg0KDQotTXVsdGktdXNlciBzZWN1cml0eSAoc2VlIFs1LCBTZWN0aW9ucyAyLjIgYW5k IDRdLCByZWR1Y2VzIHRoZSBzZWN1cml0eSBiaXRzIGJ5IHRoZSBsb2cgb2YgdGhlIG51bWJl ciBvZiB1c2Vycy4NCg0KKioqDQoNCkJhc2VkIG9uIHRoZSBjb25zaWRlcmF0aW9ucyBhYm92 ZSwgYW5kIGdlbmVyYWwgcHJ1ZGVuY2UsIGZvciAxMjgtYml0IHNlY3VyaXR5IGFuZCBITUFD IChpZiBvbmUgY2Fubm90IHVzZSBhbiBhbHRlcm5hdGl2ZSBNQUMsIGUuZy4gQ01BQyksIEni gJlkIHJlY29tbWVuZCBITUFDLVNIQTI1NiwgYnV0IHdpdGggYSBrZXkgbGFyZ2VyIHRoYW4g MTI4IGJpdHMgKHRvIGFkZHJlc3MgbXVsdGktdXNlciBhdHRhY2tzKS4gIEl0IHNlZW1zIGp1 c3QgZmluZSB0byBtZSB0cnVuY2F0ZSB0byAxMjggYml0cyAoaS5lLiBteSBpbnR1aXRpb24g c2F5cyB0aGUgbWFyZ2luIG9mIGVycm9yIHByb3ZpZGVkIGJ5IHRoYXQgU0hBLTI1NiB1c2lu ZyAyNTYgYml0cyBpbnN0ZWFkIG9mIDEyOCwgaS5lLiBhIHdpZGUgcGlwZSwgZHVyaW5nIHRo ZSBpbnRlcm5hbCBjb21wdXRhdGlvbnMsIGlzIHN1ZmZpY2llbnQuKQ0KDQpSZWZlcmVuY2Vz DQoNCls0XSBodHRwOi8vY3NyYy5uaXN0Lmdvdi9wdWJsaWNhdGlvbnMvbmlzdHB1YnMvODAw LTU3L3NwODAwLTU3X3BhcnQxX3JldjNfZ2VuZXJhbC5wZGYNCg0KWzVdIGh0dHA6Ly9lcHJp bnQuaWFjci5vcmcvMjAxMi8wNzQNCg0KDQpBcHBlbmRpeA0KDQpKdXN0IGZvciBmdW46IGlm IG9uZSBhbGxvd3Mgc3VwZXItbG9uZyBtZXNzYWdlcyBkZWZpbmVkIGJ5IGEgZm9ybXVsYSwg dGhlbiBhY3RpdmUgSE1BQyBmb3JnZXJ5IGlzIGVhc3kuIChNYXJ0aWpuIFN0YW0gc2hvd2Vk IG1lIHRoaXMsIGhvcGUgSSBnb3QgaXQgcmlnaHQuKSAgTGV0IEIgYmUgYW55IG1lc3NhZ2Ug YmxvY2suICBMZXQgbiA9IDJeMjU2LCBpbnRlZ2VyICh3aXRoIF4gPSBleHBvbmVudGlhdGlv bikuICBMZXQgTSA9IEJebiwgYml0IHN0cmluZyAod2l0aCBeID0gcmVwZWF0ZWQgY29uY2F0 ZW50YXRpb24pLiAgTGV0IE3igJkgPSBCXihuK24hKSwgICh3aXRoICEgPSBmYWN0b3JpYWwp LiAgT2YgY291cnNlLCB0aGVzZSBtZXNzYWdlcyBhcmUgYWJzdXJkbHkgbG9uZywgYW5kIGls bGVnYWxseSBsb25nIGZvciBtb3N0IGRlZmluaXRpb25zIG9mIEhNQUMsIGFuZCBpbmZlYXNp YmxlIHRvIGNvbXB1dGUgdGhlIEhNQUMgdGFncyBvZi4gIEFueXdheSwgbm90aWNlIHRoYXQg SE1BQyhLLE0pID0gSE1BQyhLLE3igJkpLCBmb3IgYWxsIGtleXMgSy4gIFRvIHNlZSB0aGlz LCB0aGluayBhYm91dCBQb2xsYXJkIHJoby4gIFN0YXJ0aW5nIGZyb20gdGhlIGtleSwgZWFj aCBibG9jayBCIGFwcGxpZXMgdGhlIHNhbWUgZnVuY3Rpb24uICBUaGUgbiBpdGVyYXRpb25z IG1vdmUgdGhpcyBmdW5jdGlvbiBpbnRvIGEgY3ljbGUuICBUaGUgZXh0cmEgbiEgY3ljbGVz IHdyYXAgYXJvdW5kIHRoZSBjeWNsZS4gIEZvciB0aGUgYWN0aXZlIGZvcmdlcnksIGdldCB0 aGUgTUFDIHNpZ25lciB0byBjb21wdXRlIHRoZSBUPUhNQUMoSyxNKS4gIFRoZW4gcHJlc2Vu dCB0aGUgVCBhbmQgTeKAmSB0byBhIE1BQyB2ZXJpZmllciwgd2hvIHdpbGwgYWNjZXB0IFQg YXMgdmFsaWQgZXZlbiB0aG91Z2ggdGhlIE1BQyBzaWduZXIgbmV2ZXIgYXV0aGVudGljYXRl ZCBN4oCZLiAgQnkgdGhlIHdheSwgcHJvb2ZzIG11c3QgcmVzaXN0IHN1Y2ggYWJzdXJkaXRp ZXMsIHdoaWNoIEkgdGhpbmsgdGhleSBhbGwgZG8gcmF0aGVyIGVhc2lseSwgYnkgbGltaXRp bmcgdGhlIG1lc3NhZ2UgbGVuZ3RoIG9yIG51bWJlciBvZiBjb21wcmVzc2lvbiBmdW5jdGlv biBxdWVyaWVzLg0KDQpTb3JyeSBmb3IgdGhlIGxlbmd0aCBvZiB0aGlzIGVtYWlsLg0KDQpE YW5pZWwgQnJvd24NCg0KUmVzZWFyY2ggSW4gTW90aW9uIExpbWl0ZWQNCg0KDQoNCg0KW2Np ZDppbWFnZTAwMS5naWZAMDFDRDYwRUMuRkNENEI4NDBdDQoNCg0KDQpGcm9tOiBodWdva3Jh d0BnbWFpbC5jb20gW21haWx0bzpodWdva3Jhd0BnbWFpbC5jb21dIE9uIEJlaGFsZiBPZiBI dWdvIEtyYXdjenlrDQpTZW50OiBUaHVyc2RheSwgSnVseSAxMiwgMjAxMiAxMTozNyBQTQ0K VG86IERhbiBCcm93bg0KQ2M6IGVrckBydGZtLmNvbTsgaGFsbGFtQGdtYWlsLmNvbTsgc2Fh Z0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzYWFnXSBIb3cgbG9uZyBzaG91bGQgYSBNQUMg YmU/DQoNClJGQyAyMTA0IGRvZXNuJ3Qgc2F5IHdoYXQgdGhlIHNlY3VyaXR5IG9mIFNIQTI1 NiAob3Igb2YgYW55IG90aGVyIGZ1bmN0aW9uKSBpcy4NCg0KVGhlcmUgaXMgb25lIGZhY3Qs IGhvd2V2ZXIsIHRoYXQgZG9lcyBub3QgZGVwZW5kIG9uIHRoZSB1bmRlcmx5aW5nIGZ1bmN0 aW9uIChvciBldmVuIG9uIEhNQUMpOiBhIE1BQyB0YWcgb2YgbGVuZ3RoIHQsIGV2ZW4gYSBw ZXJmZWN0IG9uZSwgZG9lcyBub3QgZ2l2ZSBtb3JlIHRoYW4gdCBiaXRzIG9mIHNlY3VyaXR5 ICBhcyB0aGUgYXR0YWNrZXIgY2FuIGd1ZXNzIHRoZSBNQUMgdmFsdWUgd2l0aCBwcm9iYWJp bGl0eSAyXnstdH0gKGFuZCBvZiBjb3Vyc2UgdGhlIGF0dGFja2VyJ3MgYWR2YW50YWdlIGlu Y3JlYXNlcyBsaW5lYXJseSB3aXRoIHRoZSBudW1iZXIgb2YgTUFDZWQgbWVzc2FnZXMgb3Ig dGhlIG51bWJlciBvZiBwb3NzaWJsZSBndWVzc2VzIGJ5IHRoZSBhdHRhY2tlcikuDQoNCkh1 Z28NCk9uIFRodSwgSnVsIDEyLCAyMDEyIGF0IDk6MjEgUE0sIERhbiBCcm93biA8ZGJyb3du QGNlcnRpY29tLmNvbTxtYWlsdG86ZGJyb3duQGNlcnRpY29tLmNvbT4+IHdyb3RlOg0KU28s IGluIHRlcm1zIG9mIHNlY3VyaXR5IGxldmVscywgZG9lcyB3aGF0IFJGQyAyMTA0IHNheXMg bWVhbiB0aGF0IEhNQUMtU0hBMjU2IHByb3ZpZGVzIDI1Ni1iaXQgc2VjdXJpdHksIHdoaWxl IHRydW5jYXRpbmcgdG8gMTI4IGJpdHMgcHJvdmlkZXMgMTI4LWJpdCBzZWN1cml0eT8gT3Ig ZG9lcyBITUFDLVNIQTI1NiBvbmx5IHByb3ZpZGUgMTI4IHNlY3VyaXR5Pw0KDQoNCg0KRnJv bTogSHVnbyBLcmF3Y3p5ayBbbWFpbHRvOmh1Z29AZWUudGVjaG5pb24uYWMuaWw8bWFpbHRv Omh1Z29AZWUudGVjaG5pb24uYWMuaWw+XQ0KU2VudDogVGh1cnNkYXksIEp1bHkgMTIsIDIw MTIgMDk6MDUgUE0NClRvOiBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVr ckBydGZtLmNvbT4+DQpDYzogRGFuIEJyb3duOyBoYWxsYW1AZ21haWwuY29tPG1haWx0bzpo YWxsYW1AZ21haWwuY29tPiA8aGFsbGFtQGdtYWlsLmNvbTxtYWlsdG86aGFsbGFtQGdtYWls LmNvbT4+OyBzYWFnQGlldGYub3JnPG1haWx0bzpzYWFnQGlldGYub3JnPiA8c2FhZ0BpZXRm Lm9yZzxtYWlsdG86c2FhZ0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3NhYWddIEhvdyBs b25nIHNob3VsZCBhIE1BQyBiZT8NCg0KT24gVGh1LCBKdWwgMTIsIDIwMTIgYXQgNzozOCBQ TSwgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+PiB3 cm90ZToNCj4gR2l2ZW4gdGhhdCBCZWxsYXJlIGlzIGEgY28tYXV0aG9yIG9uIFJGQyAyMTA0 IGFuZCAyMTA0IGRlc2NyaWJlcyB0cnVuY2F0aW9uLA0KPiBJIHdvdWxkIGNlcnRhaW5seSBi ZSBzYWQgdG8gbGVhcm4gdHJ1bmNhdGlvbiB3YXNuJ3QgT0suDQo+DQo+IC1Fa3INCg0KTm8g cmVhc29uIHRvIGJlIHNhZCwgRXJpYy4NCg0KVGhlIHRleHQgZm9yIEhNQUMgdHJ1bmNhdGlv biBpbiBSRkMgMjEwNCAoc2VlIGJlbG93KSBzdGlsbCBob2xkcy4gQ29uZmlkZW5jZSBpbiB0 aGlzIG1lY2hhbmlzbSBpcyBldmVuIHN0cm9uZ2VyIHRvZGF5IGdpdmVuIHRoZSBwcm9vZnMg KGFuZCBwcmFjdGljYWwgYWNjZXB0YW5jZSkgb2YgSE1BQyBhcyBhIHBzZXVkby1yYW5kb20g ZnVuY3Rpb24gWzEsMiwzXS4gVGhpcyBtZWFucyB0aGF0IGFueSBzdWJzZXQgb2YgdCBiaXRz IGZyb20gSE1BQydzIG91dHB1dCBzaG91bGQgYmUgY29tcHV0YXRpb25hbGx5IGluZGlzdGlu Z3Vpc2hhYmxlIGZyb20gdCByYW5kb20gYml0cywgdGhlcmVmb3JlIHN1aXRhYmxlIGZvciBN QUMgKHRoZSBzZWN1cml0eSBzaG91bGQgYmUgY29uc2lkZXJlZCB0aGUgbWluaW11bSBiZXR3 ZWVuIHRoZSBsZW5ndGggb2YgdGhlIE1BQyBhbmQgdGhlIHNlY3VyaXR5IG9mIEhNQUMsIHR5 cGljYWxseSBnaXZlbiBieSBoYWxmIHRoZSBzaXplIG9mIHRoZSBoYXNoIGxlbmd0aCkuDQoN ClsxXSBNLiBCZWxsYXJlLCBSLiBDYW5ldHRpLCBhbmQgSC4gS3Jhd2N6eWssICJLZXlpbmcg SGFzaCBGdW5jdGlvbnMgZm9yIE1lc3NhZ2UgQXV0aGVudGljYXRpb24iLCBDcnlwdG8gMTk5 Ni4NCg0KWzJdIE0uIEJlbGxhcmUsIFIuIENhbmV0dGksIGFuZCBILiBLcmF3Y3p5aywgIlBz ZXVkb3JhbmRvbSBGdW5jdGlvbnMgUmV2aXNpdGVkOiBUaGUgQ2FzY2FkZSBDb25zdHJ1Y3Rp b24iLCBQcm9jZWVkaW5ncyBvZiBGT0NTJzk2Lg0KDQpbM10gTS4gQmVsbGFyZSAiTmV3IFBy b29mcyBmb3IgTk1BQyBhbmQgSE1BQzogU2VjdXJpdHkgd2l0aG91dCBDb2xsaXNpb24tUmVz aXN0YW5jZSIsIENyeXB0byAyMDA2Lg0KDQpIZXJlIGlzIHRoZSBvcmlnaW5hbCB0ZXh0IGZy b20gdGhlIFJGQw0KDQogNS4gVHJ1bmNhdGVkIG91dHB1dA0KDQoNCg0KICAgQSB3ZWxsLWtu b3duIHByYWN0aWNlIHdpdGggbWVzc2FnZSBhdXRoZW50aWNhdGlvbiBjb2RlcyBpcyB0bw0K DQogICB0cnVuY2F0ZSB0aGUgb3V0cHV0IG9mIHRoZSBNQUMgYW5kIG91dHB1dCBvbmx5IHBh cnQgb2YgdGhlIGJpdHMNCg0KICAgKGUuZy4sIFtNTSwgQU5TSV0pLiAgUHJlbmVlbCBhbmQg dmFuIE9vcnNjaG90IFtQVl0gc2hvdyBzb21lDQoNCiAgIGFuYWx5dGljYWwgYWR2YW50YWdl cyBvZiB0cnVuY2F0aW5nIHRoZSBvdXRwdXQgb2YgaGFzaC1iYXNlZCBNQUMNCg0KICAgZnVu Y3Rpb25zLiBUaGUgcmVzdWx0cyBpbiB0aGlzIGFyZWEgYXJlIG5vdCBhYnNvbHV0ZSBhcyBm b3IgdGhlDQoNCiAgIG92ZXJhbGwgc2VjdXJpdHkgYWR2YW50YWdlcyBvZiB0cnVuY2F0aW9u LiBJdCBoYXMgYWR2YW50YWdlcyAobGVzcw0KDQogICBpbmZvcm1hdGlvbiBvbiB0aGUgaGFz aCByZXN1bHQgYXZhaWxhYmxlIHRvIGFuIGF0dGFja2VyKSBhbmQNCg0KICAgZGlzYWR2YW50 YWdlcyAobGVzcyBiaXRzIHRvIHByZWRpY3QgZm9yIHRoZSBhdHRhY2tlcikuICBBcHBsaWNh dGlvbnMNCg0KICAgb2YgSE1BQyBjYW4gY2hvb3NlIHRvIHRydW5jYXRlIHRoZSBvdXRwdXQg b2YgSE1BQyBieSBvdXRwdXR0aW5nIHRoZSB0DQoNCiAgIGxlZnRtb3N0IGJpdHMgb2YgdGhl IEhNQUMgY29tcHV0YXRpb24gZm9yIHNvbWUgcGFyYW1ldGVyIHQgKG5hbWVseSwNCg0KICAg dGhlIGNvbXB1dGF0aW9uIGlzIGNhcnJpZWQgaW4gdGhlIG5vcm1hbCB3YXkgYXMgZGVmaW5l ZCBpbiBzZWN0aW9uIDINCg0KICAgYWJvdmUgYnV0IHRoZSBlbmQgcmVzdWx0IGlzIHRydW5j YXRlZCB0byB0IGJpdHMpLiBXZSByZWNvbW1lbmQgdGhhdA0KDQogICB0aGUgb3V0cHV0IGxl bmd0aCB0IGJlIG5vdCBsZXNzIHRoYW4gaGFsZiB0aGUgbGVuZ3RoIG9mIHRoZSBoYXNoDQoN CiAgIG91dHB1dCAodG8gbWF0Y2ggdGhlIGJpcnRoZGF5IGF0dGFjayBib3VuZCkgYW5kIG5v dCBsZXNzIHRoYW4gODAgYml0cw0KDQogICAoYSBzdWl0YWJsZSBsb3dlciBib3VuZCBvbiB0 aGUgbnVtYmVyIG9mIGJpdHMgdGhhdCBuZWVkIHRvIGJlDQoNCiAgIHByZWRpY3RlZCBieSBh biBhdHRhY2tlcikuDQpIdWdvDQoNCg0KT24gVGh1LCBKdWwgMTIsIDIwMTIgYXQgNDozMiBQ TSwgRGFuIEJyb3duIDxkYnJvd25AY2VydGljb20uY29tPG1haWx0bzpkYnJvd25AY2VydGlj b20uY29tPj4gd3JvdGU6DQo+IE1heWJlIHNvbWUgb2YgdGhlIEhNQUMgc2VjdXJpdHkgcHJv b2ZzIGRvbid0IHdvcmsgaWYgSE1BQyBpcyB0cnVuY2F0ZWQuICBXZSBjb3VsZCBhc2sgQ0ZS RyBvciBCZWxsYXJlLg0KPg0KPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+IEZy b206IFBoaWxsaXAgSGFsbGFtLUJha2VyIFttYWlsdG86aGFsbGFtQGdtYWlsLmNvbTxtYWls dG86aGFsbGFtQGdtYWlsLmNvbT5dDQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAxMSwgMjAx MiAwOTowNyBQTQ0KPiBUbzogc2FhZ0BpZXRmLm9yZzxtYWlsdG86c2FhZ0BpZXRmLm9yZz4g PHNhYWdAaWV0Zi5vcmc8bWFpbHRvOnNhYWdAaWV0Zi5vcmc+Pg0KPiBTdWJqZWN0OiBbc2Fh Z10gSG93IGxvbmcgc2hvdWxkIGEgTUFDIGJlPw0KPg0KPiBZZWFoLCB5ZWFoLCBkaWdlc3Rz LCBiaXJ0aGRheSBhdHRhY2ssIHlhZGRhIHlhZGRhLg0KPg0KPiBCdXQhIEEgTUFDIGlzIG5v dCBhIGRpZ2VzdCwgaXQgaXMgYW4gYXV0aGVudGljYXRpb24gbWVjaGFuaXNtLiBJZiBJDQo+ IHVzZSBITUFDLVNIQTI1NiB3aXRoIGEgMTI4IGJpdCBrZXksIEkgYW0gZ29pbmcgdG8gaGF2 ZSBubyBtb3JlIHRoYW4NCj4gMTI4IGJpdHMgb2YgZXJnb2RpY2l0eSBpbiBteSBvdXRwdXQu IFNvIHdoYXQgaXMgdGhlIGp1c3RpZmljYXRpb24gZm9yDQo+IHByZXNlbnRpbmcgbW9yZSB0 aGFuIDEyOCBiaXRzPw0KPg0KPiBOb3cgSSBndWVzcyBzb21lb25lIGNhbiBhcmd1ZSAoT0sg dGhleSB3aWxsKSB0aGF0IEhNQUMtU0hBMjU2IHdpdGggYQ0KPiAyNTYgYml0IGtleSBwcm9k dWNlcyBhIGZ1bGwgMjU2IGJpdHMgb2YgZXJnb2RpY2l0eSBpbiB0aGUgb3V0cHV0LiBCdXQN Cj4gZ2l2ZW4gdGhhdCB3ZSBoYXZlIGFncmVlZCBvbiAxMjggYml0cyBhcyAnc3VmZmljaWVu dCcgZm9yIGVuY3J5cHRpb24NCj4ga2V5cyAod2VsbCBmb3IgdGhlIGxpZmV0aW1lIG9mIHRo aXMgdW5pdmVyc2UgYXQgbGVhc3QpIHdoeSB0aGVuIGRlbWFuZA0KPiB1cCB0byA1MTIgZm9y IGF1dGhlbnRpY2F0aW9uPw0KPg0KPiBJIGtub3cgdGhhdCB0aGVyZSBhcmUgcGVyZmVjdGx5 IGdvb2QgcmVhc29ucyBmb3IgdXNpbmcgQUVTLTI1NiwgaXQgaXMNCj4gbm90IHJlYWxseSB0 aGUgcG9zc2liaWxpdHkgb2YgYnJ1dGUgZm9yY2luZyB0aGUga2V5IHRoYXQgaXMgdGhlIGlz c3VlDQo+IHNvIG11Y2ggYXMgdGhlIGZhY3QgdGhhdCBBRVMtNTEyIGhhcyBtYW55IG1vcmUg cm91bmRzIHRoYW4gQUVTLTEyOCBhbmQNCj4gaXMgc3Ryb25nZXIuIEFuZCB3aGVuIHNvbWVv bmUgbGlrZSBBZGkgU2hhbWlyIHN1Z2dlc3RzIEFFUyBtaWdodCBiZSBhDQo+IGxpdHRsZSBv dmVyLW9wdGltaXplZCwgd2VsbCBJIGxpc3Rlbi4NCj4NCj4gV2hhdCB0aGlzIGNvbWVzIGRv d24gdG8gaXMgdGhhdCBJIHRoaW5rIHdlIG5lZWQgYSBITUFDLVNIQTEyOCBhbmQNCj4gbWF5 YmUgcGVvcGxlIHdobyBhcmUgcmVhbGx5IGxvb2tpbmcgZm9yIDI1NiBiaXRzIG9mIGF1dGhl bnRpY2F0aW9uDQo+IHNob3VsZCBiZSBjdXR0aW5nIEhNQUMtU0hBNTEyIGluIHR3by4uLg0K Pg0KPiBKdXN0IGEgdGhvdWdodC4NCj4NCj4gLS0NCj4gV2Vic2l0ZTogaHR0cDovL2hhbGxh bWJha2VyLmNvbS8NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gc2FhZyBtYWlsaW5nIGxpc3QNCj4gc2FhZ0BpZXRmLm9yZzxtYWlsdG86 c2FhZ0BpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zYWFnDQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBUaGlzIHRyYW5zbWlzc2lvbiAoaW5j bHVkaW5nIGFueSBhdHRhY2htZW50cykgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9y bWF0aW9uLCBwcml2aWxlZ2VkIG1hdGVyaWFsIChpbmNsdWRpbmcgbWF0ZXJpYWwgcHJvdGVj dGVkIGJ5IHRoZSBzb2xpY2l0b3ItY2xpZW50IG9yIG90aGVyIGFwcGxpY2FibGUgcHJpdmls ZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1YmxpYyBpbmZvcm1hdGlvbi4gQW55IHVzZSBv ZiB0aGlzIGluZm9ybWF0aW9uIGJ5IGFueW9uZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFu c21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2Vu ZGVyIGFuZCBkZWxldGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIgc3lzdGVtLiBVc2Us IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMg dHJhbnNtaXNzaW9uIGJ5IHVuaW50ZW5kZWQgcmVjaXBpZW50cyBpcyBub3QgYXV0aG9yaXpl ZCBhbmQgbWF5IGJlIHVubGF3ZnVsLg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBzYWFnIG1haWxpbmcgbGlzdA0KPiBzYWFnQGlldGYu b3JnPG1haWx0bzpzYWFnQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NhYWcNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpzYWFnIG1haWxpbmcgbGlzdA0Kc2FhZ0BpZXRmLm9yZzxtYWlsdG86 c2FhZ0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2FhZw0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyB0cmFuc21pc3Npb24gKGluY2x1ZGlu ZyBhbnkgYXR0YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlv biwgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHByb3RlY3RlZCBi eSB0aGUgc29saWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHByaXZpbGVnZXMp LCBvciBjb25zdGl0dXRlIG5vbi1wdWJsaWMgaW5mb3JtYXRpb24uIEFueSB1c2Ugb2YgdGhp cyBpbmZvcm1hdGlvbiBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNz aW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciBh bmQgZGVsZXRlIHRoaXMgaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5c3RlbS4gVXNlLCBkaXNz ZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIHRyYW5z bWlzc2lvbiBieSB1bmludGVuZGVkIHJlY2lwaWVudHMgaXMgbm90IGF1dGhvcml6ZWQgYW5k IG1heSBiZSB1bmxhd2Z1bC4NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgdHJhbnNtaXNz aW9uIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgaW5mb3JtYXRpb24sIHByaXZpbGVnZWQgbWF0ZXJpYWwgKGluY2x1ZGluZyBtYXRlcmlh bCBwcm90ZWN0ZWQgYnkgdGhlIHNvbGljaXRvci1jbGllbnQgb3Igb3RoZXIgYXBwbGljYWJs ZSBwcml2aWxlZ2VzKSwgb3IgY29uc3RpdHV0ZSBub24tcHVibGljIGluZm9ybWF0aW9uLiBB bnkgdXNlIG9mIHRoaXMgaW5mb3JtYXRpb24gYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGlu dGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRv IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIGluZm9ybWF0aW9uIGZyb20geW91ciBzeXN0 ZW0uIFVzZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBvciByZXByb2R1Y3Rpb24g b2YgdGhpcyB0cmFuc21pc3Npb24gYnkgdW5pbnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdCBh dXRob3JpemVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuDQo= --_000_810C31990B57ED40B2062BA10D43FBF509A961XMB111CNCrimnet_ Content-Type: text/html; charset="utf-8" content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9 IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxt ZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRl cmVkIG1lZGl1bSkiPg0KPCEtLVtpZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0K d1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1 cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Oldpbmdk aW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6 MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhv bWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29B Y2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFs bG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDow aW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4t bGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5IVE1M UHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9v blRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0K CWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZp bml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTAxNjE1MzU4MDsNCgltc28t bGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTU1MzU2NDYyIDM5 MzM5OTA2NCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2 NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6 MTE2MTExOTE1MTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6MTMwOTk4NTgzMiAtNTMwNTYyMTE0IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5 IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0 IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6U3ltYm9sOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJp ZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDINCgl7bXNvLWxp c3QtaWQ6MTUwNzA5NDM1NjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6MTc1NTIzNzM4OCA0MjQ1NDM5NjQgNjc2OTg2OTEgNjc2OTg2OTMgNjc2 OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0K QGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWls eTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30N Cm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIyMDUwIiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+UmVnYXJkaW5nIEhNQUMgc2VjdXJpdHkgbGV2ZWxzLCBOSVNUIHNheXMgWzRdIHRo YXQgSE1BQy1TSEExIHByb3ZpZGVzIDEyOCBiaXQgc2VjdXJpdHkgYW5kIEhNQUMtU0hBMjU2 IHByb3ZpZGVzIDI1Ni1iaXQgc2VjdXJpdHkgKHByZXN1bWFibHkgd2l0aCBhIDI1Ni1iaXQN CiBrZXkpLiZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkh1Z28sIHdvdWxkIHlv dSBhZ3JlZT8mbmJzcDsgQXJlIHRoZXNlIGxldmVscyBzdXBwb3J0ZWQgYnkgcHJvb2ZzPyZu YnNwOyBEbyB0aGUgcmVjZW50IFNIQS0xIGNvbGxpc2lvbi1hbGdvcml0aG1zIGFmZmVjdCB0 aGlzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4geW91ciByZWZlcmVuY2UgWzFdLCBS ZW1hcmsgNC44IGRpc2N1c3NlcyB0cnVuY2F0aW9uLCBidXQgc2VlbXMgdG8gc3VnZ2VzdCBl cXVpdmFsZW50IHNlY3VyaXR5IGZvciBhIGhhbGYtbGVuZ3RoIHRydW5jYXRlZCBITUFDLCBj aXRpbmcgZnJvbSBTZWN0aW9uIDYgYSAxMjgtYml0DQogKGJpcnRoZGF5KSBhdHRhY2sgb24g SE1BQy1TSEEyNTYgKHJlZ2FyZGxlc3Mgb2YgdHJ1bmNhdGlvbikuJm5ic3A7IFNlY3Rpb24g NiB3b3VsZCBzdWdnZXN0IHRoYXQgdW4tdHJ1bmNhdGVkIEhNQUMtU0hBMjU2IGNhbiBvbmx5 IHByb3ZpZGUgMTI4LWJpdCBzZWN1cml0eS4mbmJzcDsgJm5ic3A7QnV0LCBvbiB0aGUgb3Ro ZXIgaGFuZCwgdGhpcyBhdHRhY2sgcmVxdWlyZXMgb2J0YWluaW5nIDJeMTI4IE1BQyB0YWdz LCBzbyB0aGUgYXR0YWNrIGlzIHZlcnkgaW1wcmFjdGljYWwuJm5ic3A7DQogSXMgdGhlIGF0 dGFjayBzbyBpbXByYWN0aWNhbCB0aGF0IG9uZSBjYW4gaWdub3JlIGFuZCBkZWVtIEhNQUMt U0hBMjU2IGFzIHByb3ZpZGluZyAyNTYtYml0IHNlY3VyaXR5IChhcyBOSVNUIGRvZXMpPzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkaW5nIHByb3ZhYmxlIHNlY3VyaXR5LCBh cyBpdCB1bmRlcnN0YW5kIGl0LCB0aGUgcHJvb2YgaW4gWzFdIGFuZCBSZW1hcmsgNC42LCBp bXBsaWVzIHRoYXQgdHJ1bmNhdGVkIEhNQUMgaXMgc2VjdXJlIGlmIHRoZSB0cnVuY2F0ZWQg Y29tcHJlc3Npb24gZnVuY3Rpb24NCiBpcyBhIHNlY3VyZSBhcyBNQUMuJm5ic3A7IFRoZSBN QUMtc2VjdXJpdHkgb2YgdGhlICh0cnVuY2F0ZWQpIGNvbXByZXNzaW9uIGZ1bmN0aW9uIGl0 c2VsZiBpcyBub3QgcHJvdmVuIChvciBpcyBpdCBsYXRlciBpbiBCZWxsYXJl4oCZcyBmb2xs b3ctdXAgd29yaz8pLCBidXQgb2YgY291cnNlIHdlIG1heSBzdGlsbCBoYXZlIGNvbmZpZGVu Y2UgaW4gaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BbHNvLCBoYXNu4oCZdCB0aGUg d2VhayBjb2xsaXNpb24gcmVzaXN0YW5jZSBwcm9wZXJ0eSwgdXBvbiB3aGljaCBbMV0gcmVs aWVzLCBmb3IgU0hBLTEgYmVlbiB1bmRlcm1pbmVkPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+TWVuZXplcyBhbmQgS29ibGl0eiBbNSwgU2VjdGlvbiA0XSBub3RlIHRoYXQgdGhlIGFk dmFudGFnZSBvZiB0YWcgdHJ1bmNhdGlvbiBpbiBzb21lIGNhc2VzIG1pZ2h0IG5vdCBiZSBh cyBtdWNoIGFzIHByZXZpb3VzbHkgdGhvdWdodC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PioqKjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGhpbGxpcCBvcmlnaW5hbGx5IGFza2Vk IGFib3V0IHRoZSBuZWVkIGZvciBITUFDLVNIQTI1NiwgYW5kIHNwZWNpZmljYWxseSBtZW50 aW9uaW5nIHRoZSBNQUMgdGFnIGxlbmd0aCwgYnV0IGhpcyBxdWVzdGlvbiBjb3VsZCBhbHNv IGJlIHRha2VuIGFzIGEgcXVlc3Rpb24NCiBmb3IgdGhlIG5lZWQgZm9yIDI1Ni1iaXQgc2Vj dXJpdHkgdnMuIDEyOC1iaXQgc2VjdXJpdHkuJm5ic3A7IExldOKAmXMgc3VwcG9zZSB0aGF0 IDEyOC1iaXQgc2VjdXJpdHkgaXMgc3VmZmljaWVudC4gJm5ic3A7U29tZSByZWFzb25zIGZv ciBvcHRpbmcgZm9yIGEgaGlnaGVyIHNlY3VyaXR5IGxldmVsIChhdCBsZWFzdCBmb3IgSE1B QykgaW5jbHVkZSB0aGUgZm9sbG93aW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LU1h cmdpbiBvZiBlcnJvciwgaW4gY2FzZSB0aGUgYWxnb3JpdGhtcyBlbmQgdXAgYmVpbmcgd2Vh a2VyIHRoYW4gb25lIHdvdWxkIHRoaW5rIChlLmcuIE1ENSwgU0hBLTEpLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+LVJlc2lzdGFuY2UgdG8gcXVhbnR1bSBjb21wdXRlcnMgKGVpdGhl ciBub3cgb3IgaW4gdGhlIGZ1dHVyZSkuJm5ic3A7IEZ1dHVyZSBhZHZlcnNhcmllcyBjYW5u b3QgZm9yZ2UgTUFDcyB0b2RheSwgYnV0IGlmIGFsbCB0aGUga2V5cyBhcmUgMTI4IGJpdHMs IHRoZXkgY2FuLCBhdA0KIGEgY29zdCBhYm91dCAyXjY0IHF1YW50dW0gY29tcHV0ZXIgc3Rl cHMsIHJlY292ZXIgYSBNQUMga2V5cyBmcm9tIHRoZSBtZXNzYWdlIGFuZCB0YWcsIGFuZCB0 aGVuIHJlY292ZXIgdGhlIG1hc3RlciBrZXkgZnJvbSB0aGUgTUFDIGlzIG9mdGVuIGRlcml2 ZWQsIGFuZCB0aGVuIHJlY292ZXIgdGhlIGVuY3J5cHRpb24ga2V5LCBhbmQgdGhlcmVieSBj b21wcm9taXNlIGFueSBvZiB0b2RheeKAmXMgY2lwaGVydGV4dHMgdGhhdCB0aGV5IGhhdmUg c3RvcmVkLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tTXVsdGktdXNlciBz ZWN1cml0eSAoc2VlIFs1LCBTZWN0aW9ucyAyLjIgYW5kIDRdLCByZWR1Y2VzIHRoZSBzZWN1 cml0eSBiaXRzIGJ5IHRoZSBsb2cgb2YgdGhlIG51bWJlciBvZiB1c2Vycy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPioqKjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmFzZWQgb24g dGhlIGNvbnNpZGVyYXRpb25zIGFib3ZlLCBhbmQgZ2VuZXJhbCBwcnVkZW5jZSwgZm9yIDEy OC1iaXQgc2VjdXJpdHkgYW5kIEhNQUMgKGlmIG9uZSBjYW5ub3QgdXNlIGFuIGFsdGVybmF0 aXZlIE1BQywgZS5nLiBDTUFDKSwgSeKAmWQgcmVjb21tZW5kIEhNQUMtU0hBMjU2LA0KIGJ1 dCB3aXRoIGEga2V5IGxhcmdlciB0aGFuIDEyOCBiaXRzICh0byBhZGRyZXNzIG11bHRpLXVz ZXIgYXR0YWNrcykuICZuYnNwO0l0IHNlZW1zIGp1c3QgZmluZSB0byBtZSB0cnVuY2F0ZSB0 byAxMjggYml0cyAoaS5lLiBteSBpbnR1aXRpb24gc2F5cyB0aGUgbWFyZ2luIG9mIGVycm9y IHByb3ZpZGVkIGJ5IHRoYXQgU0hBLTI1NiB1c2luZyAyNTYgYml0cyBpbnN0ZWFkIG9mIDEy OCwgaS5lLiBhIHdpZGUgcGlwZSwgZHVyaW5nIHRoZSBpbnRlcm5hbCBjb21wdXRhdGlvbnMs DQogaXMgc3VmZmljaWVudC4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWZlcmVuY2Vz PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bNF0NCjxhIGhyZWY9Imh0dHA6Ly9jc3JjLm5p c3QuZ292L3B1YmxpY2F0aW9ucy9uaXN0cHVicy84MDAtNTcvc3A4MDAtNTdfcGFydDFfcmV2 M19nZW5lcmFsLnBkZiI+DQpodHRwOi8vY3NyYy5uaXN0Lmdvdi9wdWJsaWNhdGlvbnMvbmlz dHB1YnMvODAwLTU3L3NwODAwLTU3X3BhcnQxX3JldjNfZ2VuZXJhbC5wZGY8L2E+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5bNV0NCjxhIGhyZWY9Imh0dHA6Ly9lcHJpbnQuaWFjci5v cmcvMjAxMi8wNzQiPmh0dHA6Ly9lcHJpbnQuaWFjci5vcmcvMjAxMi8wNzQ8L2E+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+QXBwZW5kaXg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkp1c3QgZm9yIGZ1 bjogaWYgb25lIGFsbG93cyBzdXBlci1sb25nIG1lc3NhZ2VzIGRlZmluZWQgYnkgYSBmb3Jt dWxhLCB0aGVuIGFjdGl2ZSBITUFDIGZvcmdlcnkgaXMgZWFzeS4gKE1hcnRpam4gU3RhbSBz aG93ZWQgbWUgdGhpcywgaG9wZSBJIGdvdCBpdCByaWdodC4pJm5ic3A7DQogTGV0IEIgYmUg YW55IG1lc3NhZ2UgYmxvY2suJm5ic3A7IExldCBuID0gMl4yNTYsIGludGVnZXIgKHdpdGgg XiA9IGV4cG9uZW50aWF0aW9uKS4mbmJzcDsgTGV0IE0gPSBCXm4sIGJpdCBzdHJpbmcgKHdp dGggXiA9IHJlcGVhdGVkIGNvbmNhdGVudGF0aW9uKS4mbmJzcDsgTGV0IE3igJkgPSBCXihu JiM0MztuISksICZuYnNwOyh3aXRoICEgPSBmYWN0b3JpYWwpLiZuYnNwOyBPZiBjb3Vyc2Us IHRoZXNlIG1lc3NhZ2VzIGFyZSBhYnN1cmRseSBsb25nLCBhbmQgaWxsZWdhbGx5IGxvbmcg Zm9yIG1vc3QNCiBkZWZpbml0aW9ucyBvZiBITUFDLCBhbmQgaW5mZWFzaWJsZSB0byBjb21w dXRlIHRoZSBITUFDIHRhZ3Mgb2YuICZuYnNwO0FueXdheSwgbm90aWNlIHRoYXQgSE1BQyhL LE0pID0gSE1BQyhLLE3igJkpLCBmb3IgYWxsIGtleXMgSy4mbmJzcDsgVG8gc2VlIHRoaXMs IHRoaW5rIGFib3V0IFBvbGxhcmQgcmhvLiZuYnNwOyBTdGFydGluZyBmcm9tIHRoZSBrZXks IGVhY2ggYmxvY2sgQiBhcHBsaWVzIHRoZSBzYW1lIGZ1bmN0aW9uLiZuYnNwOyBUaGUgbiBp dGVyYXRpb25zIG1vdmUgdGhpcw0KIGZ1bmN0aW9uIGludG8gYSBjeWNsZS4mbmJzcDsgVGhl IGV4dHJhIG4hIGN5Y2xlcyB3cmFwIGFyb3VuZCB0aGUgY3ljbGUuJm5ic3A7IEZvciB0aGUg YWN0aXZlIGZvcmdlcnksIGdldCB0aGUgTUFDIHNpZ25lciB0byBjb21wdXRlIHRoZSBUPUhN QUMoSyxNKS4mbmJzcDsgVGhlbiBwcmVzZW50IHRoZSBUIGFuZCBN4oCZIHRvIGEgTUFDIHZl cmlmaWVyLCB3aG8gd2lsbCBhY2NlcHQgVCBhcyB2YWxpZCBldmVuIHRob3VnaCB0aGUgTUFD IHNpZ25lciBuZXZlciBhdXRoZW50aWNhdGVkDQogTeKAmS4mbmJzcDsgQnkgdGhlIHdheSwg cHJvb2ZzIG11c3QgcmVzaXN0IHN1Y2ggYWJzdXJkaXRpZXMsIHdoaWNoIEkgdGhpbmsgdGhl eSBhbGwgZG8gcmF0aGVyIGVhc2lseSwgYnkgbGltaXRpbmcgdGhlIG1lc3NhZ2UgbGVuZ3Ro IG9yIG51bWJlciBvZiBjb21wcmVzc2lvbiBmdW5jdGlvbiBxdWVyaWVzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+U29ycnkgZm9yIHRoZSBsZW5ndGggb2YgdGhpcyBlbWFpbC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxs c3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSI2MDAiIHN0eWxlPSJ3aWR0aDo1 LjBpbiI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAyLjRw dCAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjkuMHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkRhbmllbCBCcm93 bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxl PSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLXRvcDozLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMwMDczQkMiPlJlc2VhcmNoIEluIE1vdGlvbiBMaW1pdGVkPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7ZGlzcGxheTpub25lIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3Jk ZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjYwMCIgc3R5 bGU9IndpZHRoOjUuMGluIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzow aW4gMGluIDBpbiAwaW4iPjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDtkaXNwbGF5Om5v bmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9y bWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjMiIGNlbGxwYWRkaW5nPSIwIiB3 aWR0aD0iNjAwIiBzdHlsZT0id2lkdGg6NS4waW4iPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0 eWxlPSJwYWRkaW5nOjcuOHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjE0 MSIgaGVpZ2h0PSIzNCIgaWQ9Il94MDAwMF9pMTAyNSIgc3JjPSJjaWQ6aW1hZ2UwMDEuZ2lm QDAxQ0Q2MEVDLkZDRDRCODQwIj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHdpZHRo PSI2MDAiIHN0eWxlPSJ3aWR0aDo1LjBpbjtwYWRkaW5nOjcuOHB0IDBpbiAwaW4gMGluIj48 L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGh1Z29rcmF3QGdtYWlsLmNvbSBbbWFpbHRv Omh1Z29rcmF3QGdtYWlsLmNvbV0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SHVnbyBLcmF3Y3p5 azxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVseSAxMiwgMjAxMiAxMTozNyBQTTxi cj4NCjxiPlRvOjwvYj4gRGFuIEJyb3duPGJyPg0KPGI+Q2M6PC9iPiBla3JAcnRmbS5jb207 IGhhbGxhbUBnbWFpbC5jb207IHNhYWdAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtzYWFnXSBIb3cgbG9uZyBzaG91bGQgYSBNQUMgYmU/PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5SRkMgMjEwNCBkb2Vzbid0IHNheSB3aGF0IHRoZSBz ZWN1cml0eSBvZiBTSEEyNTYgKG9yIG9mIGFueSBvdGhlciBmdW5jdGlvbikgaXMuDQo8YnI+ DQo8YnI+DQpUaGVyZSBpcyBvbmUgZmFjdCwgaG93ZXZlciwgdGhhdCBkb2VzIG5vdCBkZXBl bmQgb24gdGhlIHVuZGVybHlpbmcgZnVuY3Rpb24gKG9yIGV2ZW4gb24gSE1BQyk6IGEgTUFD IHRhZyBvZiBsZW5ndGggdCwgZXZlbiBhIHBlcmZlY3Qgb25lLCBkb2VzIG5vdCBnaXZlIG1v cmUgdGhhbiB0IGJpdHMgb2Ygc2VjdXJpdHkmbmJzcDsgYXMgdGhlIGF0dGFja2VyIGNhbiBn dWVzcyB0aGUgTUFDIHZhbHVlIHdpdGggcHJvYmFiaWxpdHkgMl57LXR9IChhbmQgb2YgY291 cnNlDQogdGhlIGF0dGFja2VyJ3MgYWR2YW50YWdlIGluY3JlYXNlcyBsaW5lYXJseSB3aXRo IHRoZSBudW1iZXIgb2YgTUFDZWQgbWVzc2FnZXMgb3IgdGhlIG51bWJlciBvZiBwb3NzaWJs ZSBndWVzc2VzIGJ5IHRoZSBhdHRhY2tlcikuPGJyPg0KPGJyPg0KPC9zcGFuPkh1Z288bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEp1bCAx MiwgMjAxMiBhdCA5OjIxIFBNLCBEYW4gQnJvd24gJmx0OzxhIGhyZWY9Im1haWx0bzpkYnJv d25AY2VydGljb20uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGJyb3duQGNlcnRpY29tLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Tbywg aW4gdGVybXMgb2Ygc2VjdXJpdHkgbGV2ZWxzLCBkb2VzIHdoYXQgUkZDIDIxMDQgc2F5cyBt ZWFuIHRoYXQgSE1BQy1TSEEyNTYgcHJvdmlkZXMgMjU2LWJpdCBzZWN1cml0eSwgd2hpbGUg dHJ1bmNhdGluZyB0byAxMjggYml0cyBwcm92aWRlcyAxMjgtYml0IHNlY3VyaXR5Pw0KIE9y IGRvZXMgSE1BQy1TSEEyNTYgb25seSBwcm92aWRlIDEyOCBzZWN1cml0eT88YnI+DQo8YnI+ DQo8L3NwYW4+PGJyPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjogSHVnbyBLcmF3Y3p5ayBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpodWdvQGVl LnRlY2huaW9uLmFjLmlsIiB0YXJnZXQ9Il9ibGFuayI+aHVnb0BlZS50ZWNobmlvbi5hYy5p bDwvYT5dDQo8YnI+DQo8Yj5TZW50PC9iPjogVGh1cnNkYXksIEp1bHkgMTIsIDIwMTIgMDk6 MDUgUE08YnI+DQo8Yj5UbzwvYj46IEVyaWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9Im1haWx0 bzpla3JAcnRmbS5jb20iIHRhcmdldD0iX2JsYW5rIj5la3JAcnRmbS5jb208L2E+Jmd0Ow0K PGJyPg0KPGI+Q2M8L2I+OiBEYW4gQnJvd247IDxhIGhyZWY9Im1haWx0bzpoYWxsYW1AZ21h aWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+aGFsbGFtQGdtYWlsLmNvbTwvYT4gJmx0OzxhIGhy ZWY9Im1haWx0bzpoYWxsYW1AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+aGFsbGFtQGdt YWlsLmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOnNhYWdAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5zYWFnQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNhYWdA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zYWFnQGlldGYub3JnPC9hPiZndDsNCjxicj4N CjxiPlN1YmplY3Q8L2I+OiBSZTogW3NhYWddIEhvdyBsb25nIHNob3VsZCBhIE1BQyBiZT8g PGJyPg0KPC9zcGFuPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ T24gVGh1LCBKdWwgMTIsIDIwMTIgYXQgNzozOCBQTSwgRXJpYyBSZXNjb3JsYSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVrckBydGZtLmNv bTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgR2l2ZW4gdGhhdCBCZWxsYXJlIGlzIGEgY28t YXV0aG9yIG9uIFJGQyAyMTA0IGFuZCAyMTA0IGRlc2NyaWJlcyB0cnVuY2F0aW9uLDxicj4N CiZndDsgSSB3b3VsZCBjZXJ0YWlubHkgYmUgc2FkIHRvIGxlYXJuIHRydW5jYXRpb24gd2Fz bid0IE9LLjxicj4NCiZndDs8YnI+DQomZ3Q7IC1Fa3I8YnI+DQo8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5ObyByZWFzb24gdG8gYmUgc2FkLCBFcmljLjwvc3Bhbj48YnI+DQo8YnI+DQo8c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5UaGUgdGV4dCBmb3IgSE1BQyB0cnVuY2F0aW9uIGluIFJGQyAyMTA0IChz ZWUgYmVsb3cpIHN0aWxsIGhvbGRzLiBDb25maWRlbmNlIGluIHRoaXMgbWVjaGFuaXNtIGlz IGV2ZW4gc3Ryb25nZXIgdG9kYXkgZ2l2ZW4gdGhlIHByb29mcyAoYW5kIHByYWN0aWNhbCBh Y2NlcHRhbmNlKSBvZiBITUFDIGFzIGEgcHNldWRvLXJhbmRvbSBmdW5jdGlvbiBbMSwyLDNd LiBUaGlzDQogbWVhbnMgdGhhdCBhbnkgc3Vic2V0IG9mIHQgYml0cyBmcm9tIEhNQUMncyBv dXRwdXQgc2hvdWxkIGJlIGNvbXB1dGF0aW9uYWxseSBpbmRpc3Rpbmd1aXNoYWJsZSBmcm9t IHQgcmFuZG9tIGJpdHMsIHRoZXJlZm9yZSBzdWl0YWJsZSBmb3IgTUFDICh0aGUgc2VjdXJp dHkgc2hvdWxkIGJlIGNvbnNpZGVyZWQgdGhlIG1pbmltdW0gYmV0d2VlbiB0aGUgbGVuZ3Ro IG9mIHRoZSBNQUMgYW5kIHRoZSBzZWN1cml0eSBvZiBITUFDLCB0eXBpY2FsbHkgZ2l2ZW4N CiBieSBoYWxmIHRoZSBzaXplIG9mIHRoZSBoYXNoIGxlbmd0aCkuPGJyPg0KPGJyPg0KWzFd IE0uIEJlbGxhcmUsIFIuIENhbmV0dGksIGFuZCBILiBLcmF3Y3p5aywgJnF1b3Q7S2V5aW5n IEhhc2ggRnVuY3Rpb25zIGZvciBNZXNzYWdlIEF1dGhlbnRpY2F0aW9uJnF1b3Q7LCBDcnlw dG8gMTk5Ni48YnI+DQo8YnI+DQpbMl0gTS4gQmVsbGFyZSwgUi4gQ2FuZXR0aSwgYW5kIEgu IEtyYXdjenlrLCAmcXVvdDtQc2V1ZG9yYW5kb20gRnVuY3Rpb25zIFJldmlzaXRlZDogVGhl IENhc2NhZGUgQ29uc3RydWN0aW9uJnF1b3Q7LCBQcm9jZWVkaW5ncyBvZiBGT0NTJzk2Ljxi cj4NCjxicj4NClszXSBNLiBCZWxsYXJlICZxdW90O05ldyBQcm9vZnMgZm9yIE5NQUMgYW5k IEhNQUM6IFNlY3VyaXR5IHdpdGhvdXQgQ29sbGlzaW9uLVJlc2lzdGFuY2UmcXVvdDssIENy eXB0byAyMDA2Ljxicj4NCjxicj4NCkhlcmUgaXMgdGhlIG9yaWdpbmFsIHRleHQgZnJvbSB0 aGUgUkZDPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHByZT4gNS4gVHJ1bmNhdGVkIG91dHB1 dDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyBBIHdlbGwta25vd24gcHJhY3RpY2Ugd2l0aCBtZXNzYWdlIGF1dGhl bnRpY2F0aW9uIGNvZGVzIGlzIHRvPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7IHRydW5jYXRlIHRoZSBvdXRwdXQgb2YgdGhlIE1BQyBhbmQgb3V0cHV0IG9ubHkgcGFy dCBvZiB0aGUgYml0czxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyAoZS5n LiwgW01NLCBBTlNJXSkuJm5ic3A7IFByZW5lZWwgYW5kIHZhbiBPb3JzY2hvdCBbUFZdIHNo b3cgc29tZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBhbmFseXRpY2Fs IGFkdmFudGFnZXMgb2YgdHJ1bmNhdGluZyB0aGUgb3V0cHV0IG9mIGhhc2gtYmFzZWQgTUFD PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGZ1bmN0aW9ucy4gVGhlIHJl c3VsdHMgaW4gdGhpcyBhcmVhIGFyZSBub3QgYWJzb2x1dGUgYXMgZm9yIHRoZTxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBvdmVyYWxsIHNlY3VyaXR5IGFkdmFudGFn ZXMgb2YgdHJ1bmNhdGlvbi4gSXQgaGFzIGFkdmFudGFnZXMgKGxlc3M8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgaW5mb3JtYXRpb24gb24gdGhlIGhhc2ggcmVzdWx0 IGF2YWlsYWJsZSB0byBhbiBhdHRhY2tlcikgYW5kPG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7IGRpc2FkdmFudGFnZXMgKGxlc3MgYml0cyB0byBwcmVkaWN0IGZvciB0 aGUgYXR0YWNrZXIpLiZuYnNwOyBBcHBsaWNhdGlvbnM8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDsmbmJzcDsgb2YgSE1BQyBjYW4gY2hvb3NlIHRvIHRydW5jYXRlIHRoZSBvdXRw dXQgb2YgSE1BQyBieSBvdXRwdXR0aW5nIHRoZSB0PG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7IGxlZnRtb3N0IGJpdHMgb2YgdGhlIEhNQUMgY29tcHV0YXRpb24gZm9y IHNvbWUgcGFyYW1ldGVyIHQgKG5hbWVseSw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsgdGhlIGNvbXB1dGF0aW9uIGlzIGNhcnJpZWQgaW4gdGhlIG5vcm1hbCB3YXkg YXMgZGVmaW5lZCBpbiBzZWN0aW9uIDI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm bmJzcDsgYWJvdmUgYnV0IHRoZSBlbmQgcmVzdWx0IGlzIHRydW5jYXRlZCB0byB0IGJpdHMp LiBXZSByZWNvbW1lbmQgdGhhdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw OyB0aGUgb3V0cHV0IGxlbmd0aCB0IGJlIG5vdCBsZXNzIHRoYW4gaGFsZiB0aGUgbGVuZ3Ro IG9mIHRoZSBoYXNoPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IG91dHB1 dCAodG8gbWF0Y2ggdGhlIGJpcnRoZGF5IGF0dGFjayBib3VuZCkgYW5kIG5vdCBsZXNzIHRo YW4gODAgYml0czxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyAoYSBzdWl0 YWJsZSBsb3dlciBib3VuZCBvbiB0aGUgbnVtYmVyIG9mIGJpdHMgdGhhdCBuZWVkIHRvIGJl PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4m bmJzcDsmbmJzcDsgcHJlZGljdGVkIGJ5IGFuIGF0dGFja2VyKS4gPG86cD48L286cD48L3By ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ SHVnbzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KT24gVGh1LCBKdWwgMTIsIDIwMTIgYXQgNDozMiBQ TSwgRGFuIEJyb3duICZsdDs8YSBocmVmPSJtYWlsdG86ZGJyb3duQGNlcnRpY29tLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmRicm93bkBjZXJ0aWNvbS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+ DQomZ3Q7IE1heWJlIHNvbWUgb2YgdGhlIEhNQUMgc2VjdXJpdHkgcHJvb2ZzIGRvbid0IHdv cmsgaWYgSE1BQyBpcyB0cnVuY2F0ZWQuICZuYnNwO1dlIGNvdWxkIGFzayBDRlJHIG9yIEJl bGxhcmUuPGJyPg0KJmd0Ozxicj4NCiZndDsgLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0t LTxicj4NCiZndDsgRnJvbTogUGhpbGxpcCBIYWxsYW0tQmFrZXIgW21haWx0bzo8YSBocmVm PSJtYWlsdG86aGFsbGFtQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmhhbGxhbUBnbWFp bC5jb208L2E+XTxicj4NCiZndDsgU2VudDogV2VkbmVzZGF5LCBKdWx5IDExLCAyMDEyIDA5 OjA3IFBNPGJyPg0KJmd0OyBUbzogPGEgaHJlZj0ibWFpbHRvOnNhYWdAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5zYWFnQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNh YWdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zYWFnQGlldGYub3JnPC9hPiZndDs8YnI+ DQomZ3Q7IFN1YmplY3Q6IFtzYWFnXSBIb3cgbG9uZyBzaG91bGQgYSBNQUMgYmU/PGJyPg0K Jmd0Ozxicj4NCiZndDsgWWVhaCwgeWVhaCwgZGlnZXN0cywgYmlydGhkYXkgYXR0YWNrLCB5 YWRkYSB5YWRkYS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBCdXQhIEEgTUFDIGlzIG5vdCBhIGRp Z2VzdCwgaXQgaXMgYW4gYXV0aGVudGljYXRpb24gbWVjaGFuaXNtLiBJZiBJPGJyPg0KJmd0 OyB1c2UgSE1BQy1TSEEyNTYgd2l0aCBhIDEyOCBiaXQga2V5LCBJIGFtIGdvaW5nIHRvIGhh dmUgbm8gbW9yZSB0aGFuPGJyPg0KJmd0OyAxMjggYml0cyBvZiBlcmdvZGljaXR5IGluIG15 IG91dHB1dC4gU28gd2hhdCBpcyB0aGUganVzdGlmaWNhdGlvbiBmb3I8YnI+DQomZ3Q7IHBy ZXNlbnRpbmcgbW9yZSB0aGFuIDEyOCBiaXRzPzxicj4NCiZndDs8YnI+DQomZ3Q7IE5vdyBJ IGd1ZXNzIHNvbWVvbmUgY2FuIGFyZ3VlIChPSyB0aGV5IHdpbGwpIHRoYXQgSE1BQy1TSEEy NTYgd2l0aCBhPGJyPg0KJmd0OyAyNTYgYml0IGtleSBwcm9kdWNlcyBhIGZ1bGwgMjU2IGJp dHMgb2YgZXJnb2RpY2l0eSBpbiB0aGUgb3V0cHV0LiBCdXQ8YnI+DQomZ3Q7IGdpdmVuIHRo YXQgd2UgaGF2ZSBhZ3JlZWQgb24gMTI4IGJpdHMgYXMgJ3N1ZmZpY2llbnQnIGZvciBlbmNy eXB0aW9uPGJyPg0KJmd0OyBrZXlzICh3ZWxsIGZvciB0aGUgbGlmZXRpbWUgb2YgdGhpcyB1 bml2ZXJzZSBhdCBsZWFzdCkgd2h5IHRoZW4gZGVtYW5kPGJyPg0KJmd0OyB1cCB0byA1MTIg Zm9yIGF1dGhlbnRpY2F0aW9uPzxicj4NCiZndDs8YnI+DQomZ3Q7IEkga25vdyB0aGF0IHRo ZXJlIGFyZSBwZXJmZWN0bHkgZ29vZCByZWFzb25zIGZvciB1c2luZyBBRVMtMjU2LCBpdCBp czxicj4NCiZndDsgbm90IHJlYWxseSB0aGUgcG9zc2liaWxpdHkgb2YgYnJ1dGUgZm9yY2lu ZyB0aGUga2V5IHRoYXQgaXMgdGhlIGlzc3VlPGJyPg0KJmd0OyBzbyBtdWNoIGFzIHRoZSBm YWN0IHRoYXQgQUVTLTUxMiBoYXMgbWFueSBtb3JlIHJvdW5kcyB0aGFuIEFFUy0xMjggYW5k PGJyPg0KJmd0OyBpcyBzdHJvbmdlci4gQW5kIHdoZW4gc29tZW9uZSBsaWtlIEFkaSBTaGFt aXIgc3VnZ2VzdHMgQUVTIG1pZ2h0IGJlIGE8YnI+DQomZ3Q7IGxpdHRsZSBvdmVyLW9wdGlt aXplZCwgd2VsbCBJIGxpc3Rlbi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBXaGF0IHRoaXMgY29t ZXMgZG93biB0byBpcyB0aGF0IEkgdGhpbmsgd2UgbmVlZCBhIEhNQUMtU0hBMTI4IGFuZDxi cj4NCiZndDsgbWF5YmUgcGVvcGxlIHdobyBhcmUgcmVhbGx5IGxvb2tpbmcgZm9yIDI1NiBi aXRzIG9mIGF1dGhlbnRpY2F0aW9uPGJyPg0KJmd0OyBzaG91bGQgYmUgY3V0dGluZyBITUFD LVNIQTUxMiBpbiB0d28uLi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBKdXN0IGEgdGhvdWdodC48 YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLTxicj4NCiZndDsgV2Vic2l0ZTogPGEgaHJlZj0iaHR0 cDovL2hhbGxhbWJha2VyLmNvbS8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vaGFsbGFtYmFr ZXIuY29tLzwvYT48YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KJmd0OyBzYWFnIG1haWxpbmcgbGlzdDxicj4NCiZndDsg PGEgaHJlZj0ibWFpbHRvOnNhYWdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zYWFnQGll dGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zYWFnIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zYWFnPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTxicj4NCiZndDsgVGhpcyB0cmFuc21pc3Npb24gKGluY2x1ZGluZyBhbnkg YXR0YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiwgcHJp dmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHByb3RlY3RlZCBieSB0aGUg c29saWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHByaXZpbGVnZXMpLCBvciBj b25zdGl0dXRlIG5vbi1wdWJsaWMgaW5mb3JtYXRpb24uIEFueSB1c2Ugb2YgdGhpcyBpbmZv cm1hdGlvbg0KIGJ5IGFueW9uZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQg aXMgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24g aW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIGFuZCBk ZWxldGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIgc3lzdGVtLiBVc2UsIGRpc3NlbWlu YXRpb24sIGRpc3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgdHJhbnNtaXNz aW9uDQogYnkgdW5pbnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdCBhdXRob3JpemVkIGFuZCBt YXkgYmUgdW5sYXdmdWwuPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgc2FhZyBtYWlsaW5nIGxpc3Q8YnI+DQom Z3Q7IDxhIGhyZWY9Im1haWx0bzpzYWFnQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2Fh Z0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2FhZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FhZzwvYT48YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNhYWcgbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNhYWdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5z YWFnQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2FhZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2FhZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tIDxicj4NClRoaXMgdHJhbnNtaXNzaW9uIChpbmNsdWRpbmcgYW55IGF0dGFj aG1lbnRzKSBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24sIHByaXZpbGVn ZWQgbWF0ZXJpYWwgKGluY2x1ZGluZyBtYXRlcmlhbCBwcm90ZWN0ZWQgYnkgdGhlIHNvbGlj aXRvci1jbGllbnQgb3Igb3RoZXIgYXBwbGljYWJsZSBwcml2aWxlZ2VzKSwgb3IgY29uc3Rp dHV0ZSBub24tcHVibGljIGluZm9ybWF0aW9uLiBBbnkgdXNlIG9mIHRoaXMgaW5mb3JtYXRp b24NCiBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGlzIHBy b2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVy cm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciBhbmQgZGVsZXRl IHRoaXMgaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5c3RlbS4gVXNlLCBkaXNzZW1pbmF0aW9u LCBkaXN0cmlidXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIHRyYW5zbWlzc2lvbg0K IGJ5IHVuaW50ZW5kZWQgcmVjaXBpZW50cyBpcyBub3QgYXV0aG9yaXplZCBhbmQgbWF5IGJl IHVubGF3ZnVsLiA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIDxicj4NClRoaXMgdHJhbnNtaXNzaW9uIChp bmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgaW5m b3JtYXRpb24sIHByaXZpbGVnZWQgbWF0ZXJpYWwgKGluY2x1ZGluZyBtYXRlcmlhbCBwcm90 ZWN0ZWQgYnkgdGhlIHNvbGljaXRvci1jbGllbnQgb3Igb3RoZXIgYXBwbGljYWJsZSBwcml2 aWxlZ2VzKSwgb3IgY29uc3RpdHV0ZSBub24tcHVibGljIGluZm9ybWF0aW9uLiBBbnkgdXNl IG9mIHRoaXMgaW5mb3JtYXRpb24gYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVk IHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRy YW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBz ZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIGluZm9ybWF0aW9uIGZyb20geW91ciBzeXN0ZW0uIFVz ZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhp cyB0cmFuc21pc3Npb24gYnkgdW5pbnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdCBhdXRob3Jp emVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuDQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_810C31990B57ED40B2062BA10D43FBF509A961XMB111CNCrimnet_-- --_004_810C31990B57ED40B2062BA10D43FBF509A961XMB111CNCrimnet_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=2577; creation-date="Fri, 13 Jul 2012 15:45:23 GMT"; modification-date="Fri, 13 Jul 2012 15:45:23 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhjQAiANUAAF5bXMrJydjX1zIvMF5bW+Xl5fLx8UE9PsvKyvPy8np3eJSTkzIvL5WTlMvK ycrKybCvr4eFhk9MTV5cXJSSk6KhoEI+PoeGhmtqaXp4eOTk5KOhoa+urmxqab68vUE9PZWTk727 vHp3d2xqauTl5LCvrtjY19nY2FBNTdnY16KgoKOhoE9MTL28vK+vrvPy8WtpaTIuLzEuL11bW4iG hkI9Pr68vIiGh09NTSMfHyQgICMfICQfIP///wAAAAAAACH/C1hNUCBEYXRhWE1QPD94cGFja2V0 IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQiPz4gPHg6eG1wbWV0YSB4 bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iQWRvYmUgWE1QIENvcmUgNS4wLWMwNjAg NjEuMTM0Nzc3LCAyMDEwLzAyLzEyLTE3OjMyOjAwICAgICAgICAiPiA8cmRmOlJERiB4bWxuczpy ZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPiA8cmRmOkRl c2NyaXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFw LzEuMC8iIHhtbG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4bWxu czpzdFJlZj0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVmIyIg eG1wOkNyZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ1M1IFdpbmRvd3MiIHhtcE1NOkluc3Rh bmNlSUQ9InhtcC5paWQ6QTk5QzA5MUNFQkExMTFFMDg4OTZBOEYxNkFFRjgzRjEiIHhtcE1NOkRv Y3VtZW50SUQ9InhtcC5kaWQ6QTk5QzA5MURFQkExMTFFMDg4OTZBOEYxNkFFRjgzRjEiPiA8eG1w TU06RGVyaXZlZEZyb20gc3RSZWY6aW5zdGFuY2VJRD0ieG1wLmlpZDpBOTlDMDkxQUVCQTExMUUw ODg5NkE4RjE2QUVGODNGMSIgc3RSZWY6ZG9jdW1lbnRJRD0ieG1wLmRpZDpBOTlDMDkxQkVCQTEx MUUwODg5NkE4RjE2QUVGODNGMSIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRGPiA8L3g6 eG1wbWV0YT4gPD94cGFja2V0IGVuZD0iciI/PgH//v38+/r5+Pf29fTz8vHw7+7t7Ovq6ejn5uXk 4+Lh4N/e3dzb2tnY19bV1NPS0dDPzs3My8rJyMfGxcTDwsHAv769vLu6ubi3trW0s7KxsK+urayr qqmop6alpKOioaCfnp2cm5qZmJeWlZSTkpGQj46NjIuKiYiHhoWEg4KBgH9+fXx7enl4d3Z1dHNy cXBvbm1sa2ppaGdmZWRjYmFgX15dXFtaWVhXVlVUU1JRUE9OTUxLSklIR0ZFRENCQUA/Pj08Ozo5 ODc2NTQzMjEwLy4tLCsqKSgnJiUkIyIhIB8eHRwbGhkYFxYVFBMSERAPDg0MCwoJCAcGBQQDAgEA ACH5BAAAAAAALAAAAACNACIAAAb/wJ5wSCwaj8ikcslsOp/QqHRKrVqv2Kx2y+16v+CweEwum89o 7oYwAQA8wgsBQOgI0vh8D6Db8XgDQn88OjwdeohmO4uLDD0Cg3+HiZRgAn6EORw9Kn08OQN3Ag8B AXdFpAgIpQ+nQyelBVsODgEJRwIItaUBDpVDBrWrGkIFugEIt3s5zDoRRZk8O54HLUMWfQ9aBn45 skY4hNLSoA2/UMyDAEQBOdLTjH8BPQY5hQZaD4UfSIv2hX925DBHSYQ0HQcgCEGxiIeEOwHG5dih gEiFaQPcABggDkMPD58ObFmgI8ekIgim6Zgz4QOzHY4oSfAEkx6jQodCEJgDYIEy/yEY3HkUYkCC tHUUpI1gp4BAjgMzSqDMYPQABoVDJvShIMTEiJ0AFLjjNwQDvCEFRBi1AMNXEQMUwN4psIEOgDYX iHigMwHfkXGLRAYoJDBHxSUHFlUgAsCPR608FguJ4AdgnwxDLhDCdNQvA3mPBkzkwaGDtJM9LhSS IQTC6NE8DgsRINrejgQQYryTEJjIgT8ikAwWx8BFj6SYDohChsDvkAQCdVRAFmIEIR0hesSY5lZz ST8CP5noscDd5nfOehT4nuAEAx06BiDo8aGQggCkKC/iWgKg+T47LFDMAPB9YgECAf0RwSc8DLHB JwM499YDtWhTDH6mDJGYedYMEf9RdJ/Ak8MNPWhQiA5CmPgHAbIkYIEfARQAHgMbBNDAdzoY4ME0 ByDAgDvK9fCCJwH9s8NSCXD0FBwCoPBHTAoQMgAIpgDwhwwc2OKODrIYMIAfBFlhQCQ7rDMEBfCQ s9kGrfUhQTGrxBgABBmAF0AGJTHgSgWjBRCBOxyVJIEyCAA0ziDP9HDRRN/0kEAfOmjzZWRCkHCi KwdMNF8Di1ggBU9h4fMheMENYeUOB7TxpSe+qKaDbCRE8FtDABnwYg40oORAMo2F6I5zCxDCwAwA fBDQDotNsOVBlTFDiz0NtrkDC4z9wYEG0/DQ4RMapCONOQ18Ep8CEjIwjQpDkPD/5Q6H8CFda+mY ly0/zcyDBGDjYNUDAZ9gJsQLLEjjKb+fMPNSQA5ssIiZPfzJQ6JCNGDPAgr4wfATHhDmh4BKYCuQ Kz1kMNEEPXQjynUHLODBAxdM5NE72R2RQkADGLUDAUNMqq+iheSwB3wo0MHTBHOQECUPYQIwkVRD VFDIi36A7ARlf+TAAAlLpLQIEQWYywMAl3wixAI8+pWAuTmgm2kOJAtxQmUUcNCIAOv9MV8PDLqS AAt+OGKWYeyUcseGMeP9x3geAuiHbFAIQEspPyURtgUUULAABqtG5oA4xIQLSAgJlGBBiPMZdJQN K3zpTgoRlHQYAdOYWfACIFDM/9HiPXAAX4AkFFDnIhA86s43JhRcBHSeDBC5GDVg0k1AKJT4hycR Jbjl1ur9yCBsec2kwyY9PNBnD2KFB94fA3wz63WbvfnAk0Os8MfFQigZ4BkCeL2ZHyMoM8H064hS ZeLTkCFA4DOG4kGpCuaKXq0jATPJlkBuloIhCOA359nBoHoQrh3AYAgV40FeijABP4gEDQaAQAMa sIAGbKBR9FiAG9jUAxcIjQIGoN0CGlWACLiBABmwVwFqxzEhpKABIMBhayiARBYijggGWAFPRmAc IYRghXfrQQmQKLW65QAO5wijGGCnA/qJ8Yz5CM8J0MjGLXxgEYxroxynwAEIwRRwjnh8ggCQIbU8 +vGPgAykIPMYBAA7 --_004_810C31990B57ED40B2062BA10D43FBF509A961XMB111CNCrimnet_-- From paul.hoffman@vpnc.org Fri Jul 13 11:02: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 7617111E80A5 for ; Fri, 13 Jul 2012 11:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4hlV5flniog for ; Fri, 13 Jul 2012 11:01:59 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C027E11E8087 for ; Fri, 13 Jul 2012 11:01:59 -0700 (PDT) Received: from [10.20.30.102] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q6DHZe9s045547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Jul 2012 10:35:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <810C31990B57ED40B2062BA10D43FBF509A961@XMB111CNC.rim.net> Date: Fri, 13 Jul 2012 11:02:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7E801570-9A4D-4BF8-9F5D-B8ED7C7BACFF@vpnc.org> References: <810C31990B57ED40B2062BA10D43FBF509A718@XMB111CNC.rim.net> <810C31990B57ED40B2062BA10D43FBF509A961@XMB111CNC.rim.net> To: Dan Brown X-Mailer: Apple Mail (2.1278) Cc: IETF Security Area Advisory Group Subject: Re: [saag] How long should a MAC be? 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, 13 Jul 2012 18:02:00 -0000 On Jul 13, 2012, at 10:28 AM, Dan Brown wrote: > Regarding HMAC security levels, NIST says [4] that HMAC-SHA1 provides = 128 bit security and HMAC-SHA256 provides 256-bit security (presumably = with a 256-bit key).=20 This is a possibly incorrect reading of that document. The table you are = referring to, Table 3 on page 65, also says HMAC-SHA1 provides 80 and = 112 bits of strength. A better reading of the table is that HMAC-SHA1 = provides at least 128 bits, but fewer than 192 bits, of strength. Notice = that NIST did not put in a row for 160 bits. --Paul Hoffman= From hugokraw@gmail.com Fri Jul 13 17:17: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 E7C9021F858E for ; Fri, 13 Jul 2012 17:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, 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 96CbEd6+aUs1 for ; Fri, 13 Jul 2012 17:17:11 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 03C2A11E80A4 for ; Fri, 13 Jul 2012 17:17:10 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so6098145obb.31 for ; Fri, 13 Jul 2012 17:17:48 -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:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=7aJmkNahVxPpBO4uRlEYtAaFYob8yNMfCeiRSg0nTAs=; b=rz+8Bc1WOBC/6bV44JHMOrXphEiqXhUpBvbEDDe1ydVh+L1/HRG5D5JJpasPbyJwOg MLwhtT5bNmPQRBocOLp6Fj4O0G1Mc5f1c7ewubaJBQyVv0Z0mFcancqs9dB1toiRDwyT 73s2A7nAszL5F8EB9F0SbImTnmoCzMr4uYabsOcIlfF8bQkBMkXgYUzf11vHS2gMYaPk k0IthYLSzX/9+9f5IaeFeDQU91/cTV2Zlp/wR7aQKQsPx4W6T8goeoNPcdEob2c4IB7S AB7DfpB9Lwj7VdpnMavhv8JKu77vyIiDqGTqcA2uRUZbL0CZgfbYOUvhcWZu+dTnSpt0 EyfA== Received: by 10.182.75.100 with SMTP id b4mr4410657obw.12.1342225067841; Fri, 13 Jul 2012 17:17:47 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.182.125.97 with HTTP; Fri, 13 Jul 2012 17:17:27 -0700 (PDT) In-Reply-To: <810C31990B57ED40B2062BA10D43FBF509A961@XMB111CNC.rim.net> References: <810C31990B57ED40B2062BA10D43FBF509A718@XMB111CNC.rim.net> <810C31990B57ED40B2062BA10D43FBF509A961@XMB111CNC.rim.net> From: Hugo Krawczyk Date: Fri, 13 Jul 2012 20:17:27 -0400 X-Google-Sender-Auth: 4bHOWnKCAgMoWe3HrphuelaRm6Y Message-ID: To: Dan Brown Content-Type: multipart/alternative; boundary=14dae93996ed60971d04c4bf200a Cc: "hallam@gmail.com" , "saag@ietf.org" Subject: Re: [saag] How long should a MAC be? 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, 14 Jul 2012 00:17:14 -0000 --14dae93996ed60971d04c4bf200a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable See below. On Fri, Jul 13, 2012 at 1:28 PM, Dan Brown wrote: > Regarding HMAC security levels, NIST says [4] that HMAC-SHA1 provides > 128 bit security and HMAC-SHA256 provides 256-bit security (presumably wi= th > a 256-bit key). **** > > ** ** > > Hugo, would you agree? Are these levels supported by proofs? Do the > recent SHA-1 collision-algorithms affect this? > I am not an expert in cryptanalysis so I would not express an opinion on the current strength of any particular function. What the NIST text seems to indicate is the strength of the keyed compression function underlying the SHA family when used as a PRF. This security is usually conjectured to be the same as the length of the hash (which is both the length of the key and the output of the compression function). Hence 160 bits for SHA-1, 256 for SHA2-256, etc. Cryptanalysis in last years has shown that this level of "perfect security" may be a bit optimistic but nothing, as far as I know, that would require a major review of these numbers (but, as said, this is not my area of expertise) As for proofs, they all relate the strength of HMAC to the strength of the underlying compression function. The security degrades quadratically with respect to the number of applications of the (compression) function, hence the birthday-type bounds that you mention below. > **** > > ** ** > > In your reference [1], Remark 4.8 discusses truncation, but seems to > suggest equivalent security for a half-length truncated HMAC, citing from > Section 6 a 128-bit (birthday) attack on HMAC-SHA256 (regardless of > truncation). Section 6 would suggest that un-truncated HMAC-SHA256 can > only provide 128-bit security. But, on the other hand, this attack > requires obtaining 2^128 MAC tags, so the attack is very impractical. Is > the attack so impractical that one can ignore and deem HMAC-SHA256 as > providing 256-bit security (as NIST does)?**** > > ** > If you have an application (e.g., the use of HMAC as PRF in TLS or IKE) that has a small worst-case bound on the number of same-key calls to the PRF then you may be less concerned about the quadratic degradation, but if you foresee 2^50 such uses with HMAC-SHA1 then security reduces to 60 bits. ** > > Regarding provable security, as it understand it, the proof in [1] and > Remark 4.6, implies that truncated HMAC is secure if the truncated > compression function is a secure as MAC. The MAC-security of the > (truncated) compression function itself is not proven (or is it later in > Bellare=E2=80=99s follow-up work?), but of course we may still have confi= dence in > it.**** > > ** > There is no assumption or reliance on a truncated compression function. The compression function is always used in non-truncated form (in particular this is the case in all the iterations of this function underlying an HMAC computation). Only the final output is truncated. > ** > > Also, hasn=E2=80=99t the weak collision resistance property, upon which [= 1] > relies, for SHA-1 been undermined?**** > > ** > The proof of Bellare 2006 does not rely on weak collision resistance. > ** > > Menezes and Koblitz [5, Section 4] note that the advantage of tag > truncation in some cases might not be as much as previously thought. > Their note is specific to the potential benefits of truncation for the multi-user case. It does not imply anything on more common settings as those that (I guess) motivated this thread in the first place. Finally, in relation to your conclusions below, I'd note that the theoretical treatment of HMAC (or the underlying NMAC scheme) does assume a key of a size equal to the hash length which is the size of keys to the underlying keyed compression function. Hence SHA-256 should use keys of size 256. Moreover, I have never seen a setting where keying SHA-256 with 128 bits is easier in any way than keying it with 256 bits, so I see no reason to entertain 128-bit keys for SHA-256 even at the pragmatic/practical level. Hugo > **** > > ** ** > > ******* > > ** ** > > Phillip originally asked about the need for HMAC-SHA256, and specifically > mentioning the MAC tag length, but his question could also be taken as a > question for the need for 256-bit security vs. 128-bit security. Let=E2= =80=99s > suppose that 128-bit security is sufficient. Some reasons for opting for= a > higher security level (at least for HMAC) include the following.**** > > ** ** > > -Margin of error, in case the algorithms end up being weaker than one > would think (e.g. MD5, SHA-1).**** > > ** ** > > -Resistance to quantum computers (either now or in the future). Future > adversaries cannot forge MACs today, but if all the keys are 128 bits, th= ey > can, at a cost about 2^64 quantum computer steps, recover a MAC keys from > the message and tag, and then recover the master key from the MAC is ofte= n > derived, and then recover the encryption key, and thereby compromise any = of > today=E2=80=99s ciphertexts that they have stored. **** > > ** ** > > -Multi-user security (see [5, Sections 2.2 and 4], reduces the security > bits by the log of the number of users.**** > > ** ** > > ******* > > ** ** > > Based on the considerations above, and general prudence, for 128-bit > security and HMAC (if one cannot use an alternative MAC, e.g. CMAC), I=E2= =80=99d > recommend HMAC-SHA256, but with a key larger than 128 bits (to address > multi-user attacks). It seems just fine to me truncate to 128 bits (i.e. > my intuition says the margin of error provided by that SHA-256 using 256 > bits instead of 128, i.e. a wide pipe, during the internal computations, = is > sufficient.)**** > > ** ** > > References**** > > ** ** > > [4] > http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_gen= eral.pdf > **** > > ** ** > > [5] http://eprint.iacr.org/2012/074**** > > ** ** > > ** ** > > Appendix**** > > ** ** > > Just for fun: if one allows super-long messages defined by a formula, the= n > active HMAC forgery is easy. (Martijn Stam showed me this, hope I got it > right.) Let B be any message block. Let n =3D 2^256, integer (with ^ = =3D > exponentiation). Let M =3D B^n, bit string (with ^ =3D repeated > concatentation). Let M=E2=80=99 =3D B^(n+n!), (with ! =3D factorial). = Of course, > these messages are absurdly long, and illegally long for most definitions > of HMAC, and infeasible to compute the HMAC tags of. Anyway, notice that > HMAC(K,M) =3D HMAC(K,M=E2=80=99), for all keys K. To see this, think abo= ut Pollard > rho. Starting from the key, each block B applies the same function. The= n > iterations move this function into a cycle. The extra n! cycles wrap > around the cycle. For the active forgery, get the MAC signer to compute > the T=3DHMAC(K,M). Then present the T and M=E2=80=99 to a MAC verifier, = who will > accept T as valid even though the MAC signer never authenticated M=E2=80= =99. By > the way, proofs must resist such absurdities, which I think they all do > rather easily, by limiting the message length or number of compression > function queries.**** > > ** ** > > Sorry for the length of this email.**** > > ** ** > > Daniel Brown**** > > Research In Motion Limited **** > > ** ** > > ** ** > > **** > > ** ** > > *From:* hugokraw@gmail.com [mailto:hugokraw@gmail.com] *On Behalf Of *Hug= o > Krawczyk > *Sent:* Thursday, July 12, 2012 11:37 PM > *To:* Dan Brown > *Cc:* ekr@rtfm.com; hallam@gmail.com; saag@ietf.org > > *Subject:* Re: [saag] How long should a MAC be?**** > > ** ** > > RFC 2104 doesn't say what the security of SHA256 (or of any other > function) is. > > There is one fact, however, that does not depend on the underlying > function (or even on HMAC): a MAC tag of length t, even a perfect one, do= es > not give more than t bits of security as the attacker can guess the MAC > value with probability 2^{-t} (and of course the attacker's advantage > increases linearly with the number of MACed messages or the number of > possible guesses by the attacker). > > Hugo**** > > On Thu, Jul 12, 2012 at 9:21 PM, Dan Brown wrote:**= * > * > > So, in terms of security levels, does what RFC 2104 says mean that > HMAC-SHA256 provides 256-bit security, while truncating to 128 bits > provides 128-bit security? Or does HMAC-SHA256 only provide 128 security? > > > **** > > *From*: Hugo Krawczyk [mailto:hugo@ee.technion.ac.il] > *Sent*: Thursday, July 12, 2012 09:05 PM > *To*: Eric Rescorla > *Cc*: Dan Brown; hallam@gmail.com ; saag@ietf.org < > saag@ietf.org> > *Subject*: Re: [saag] How long should a MAC be? > **** > > On Thu, Jul 12, 2012 at 7:38 PM, Eric Rescorla wrote: > > Given that Bellare is a co-author on RFC 2104 and 2104 describes > truncation, > > I would certainly be sad to learn truncation wasn't OK. > > > > -Ekr > > No reason to be sad, Eric. > > The text for HMAC truncation in RFC 2104 (see below) still holds. > Confidence in this mechanism is even stronger today given the proofs (and > practical acceptance) of HMAC as a pseudo-random function [1,2,3]. This > means that any subset of t bits from HMAC's output should be > computationally indistinguishable from t random bits, therefore suitable > for MAC (the security should be considered the minimum between the length > of the MAC and the security of HMAC, typically given by half the size of > the hash length). > > [1] M. Bellare, R. Canetti, and H. Krawczyk, "Keying Hash Functions for > Message Authentication", Crypto 1996. > > [2] M. Bellare, R. Canetti, and H. Krawczyk, "Pseudorandom Functions > Revisited: The Cascade Construction", Proceedings of FOCS'96. > > [3] M. Bellare "New Proofs for NMAC and HMAC: Security without > Collision-Resistance", Crypto 2006. > > Here is the original text from the RFC**** > > 5. Truncated output**** > > ** ** > > A well-known practice with message authentication codes is to**** > > truncate the output of the MAC and output only part of the bits**** > > (e.g., [MM, ANSI]). Preneel and van Oorschot [PV] show some**** > > analytical advantages of truncating the output of hash-based MAC**** > > functions. The results in this area are not absolute as for the**** > > overall security advantages of truncation. It has advantages (less**** > > information on the hash result available to an attacker) and**** > > disadvantages (less bits to predict for the attacker). Applications**= ** > > of HMAC can choose to truncate the output of HMAC by outputting the t*= *** > > leftmost bits of the HMAC computation for some parameter t (namely,***= * > > the computation is carried in the normal way as defined in section 2**= ** > > above but the end result is truncated to t bits). We recommend that***= * > > the output length t be not less than half the length of the hash**** > > output (to match the birthday attack bound) and not less than 80 bits*= *** > > (a suitable lower bound on the number of bits that need to be**** > > predicted by an attacker). **** > > Hugo**** > > ** ** > > > On Thu, Jul 12, 2012 at 4:32 PM, Dan Brown wrote: > > Maybe some of the HMAC security proofs don't work if HMAC is truncated. > We could ask CFRG or Bellare. > > > > ----- Original Message ----- > > From: Phillip Hallam-Baker [mailto:hallam@gmail.com] > > Sent: Wednesday, July 11, 2012 09:07 PM > > To: saag@ietf.org > > Subject: [saag] How long should a MAC be? > > > > Yeah, yeah, digests, birthday attack, yadda yadda. > > > > But! A MAC is not a digest, it is an authentication mechanism. If I > > use HMAC-SHA256 with a 128 bit key, I am going to have no more than > > 128 bits of ergodicity in my output. So what is the justification for > > presenting more than 128 bits? > > > > Now I guess someone can argue (OK they will) that HMAC-SHA256 with a > > 256 bit key produces a full 256 bits of ergodicity in the output. But > > given that we have agreed on 128 bits as 'sufficient' for encryption > > keys (well for the lifetime of this universe at least) why then demand > > up to 512 for authentication? > > > > I know that there are perfectly good reasons for using AES-256, it is > > not really the possibility of brute forcing the key that is the issue > > so much as the fact that AES-512 has many more rounds than AES-128 and > > is stronger. And when someone like Adi Shamir suggests AES might be a > > little over-optimized, well I listen. > > > > What this comes down to is that I think we need a HMAC-SHA128 and > > maybe people who are really looking for 256 bits of authentication > > should be cutting HMAC-SHA512 in two... > > > > Just a thought. > > > > -- > > Website: http://hallambaker.com/ > > _______________________________________________ > > saag mailing list > > saag@ietf.org > > https://www.ietf.org/mailman/listinfo/saag > > > > --------------------------------------------------------------------- > > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-publi= c > information. Any use of this information by anyone other than the intende= d > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be unlawf= ul. > > _______________________________________________ > > 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**** > > ** ** > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-publi= c > information. Any use of this information by anyone other than the intende= d > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be > unlawful. **** > > ** ** > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-publi= c > information. Any use of this information by anyone other than the intende= d > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be > unlawful. > --14dae93996ed60971d04c4bf200a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable See below.

On Fri, Jul 13, 2012 at 1:28 PM, Dan Brown <dbro= wn@certicom.com> wrote:

Regarding HMAC security l= evels, NIST says [4] that HMAC-SHA1 provides 128 bit security and HMAC-SHA2= 56 provides 256-bit security (presumably with a 256-bit key).=C2=A0

=C2=A0

Hugo, would you agree?=C2= =A0 Are these levels supported by proofs?=C2=A0 Do the recent SHA-1 collisi= on-algorithms affect this?


I am not an expert in cryptanalysis so I = would not express an opinion on the=C2=A0 current strength of any particula= r function.
What the NIST text seems to indicate is the strength of the = keyed compression function underlying the SHA family when used as a PRF. Th= is security is usually conjectured to be the same as the length of the hash= (which is both the length of the key and the output of the compression fun= ction). Hence 160 bits for SHA-1, 256 for SHA2-256, etc. Cryptanalysis in l= ast years has shown that this level of "perfect security" may be = a bit optimistic but nothing, as far as I know, that would require a major = review of these numbers (but, as said, this is not my area of expertise)
As for proofs, they all relate the strength of HMAC to the strength of = the underlying compression function. The security degrades quadratically wi= th respect to the number of applications of the (compression) function, hen= ce the birthday-type bounds that you mention below.

=C2=A0

In your reference [1], Re= mark 4.8 discusses truncation, but seems to suggest equivalent security for= a half-length truncated HMAC, citing from Section 6 a 128-bit (birthday) attack on HMAC-SHA256 (regardless of truncation).=C2=A0 Section= 6 would suggest that un-truncated HMAC-SHA256 can only provide 128-bit sec= urity.=C2=A0 =C2=A0But, on the other hand, this attack requires obtaining 2= ^128 MAC tags, so the attack is very impractical.=C2=A0 Is the attack so impractical that one can ignore and deem HMAC-SHA256 as p= roviding 256-bit security (as NIST does)?

=C2=A0

<= /div>

If you have an application (e.g., the use = of HMAC as PRF in TLS or IKE) that has a small worst-case bound on the numb= er of same-key calls to the PRF=C2=A0 then you may be less concerned about = the quadratic degradation, but if you foresee 2^50 such uses with HMAC-SHA1= then security reduces to 60 bits.

Regarding provable securi= ty, as it understand it, the proof in [1] and Remark 4.6, implies that trun= cated HMAC is secure if the truncated compression function is a secure as MAC.=C2=A0 The MAC-security of the (truncated) compression = function itself is not proven (or is it later in Bellare=E2=80=99s follow-u= p work?), but of course we may still have confidence in it.

<= /div>

There is no assumption or reliance on a truncate= d compression function. The compression function is always used in non-trun= cated form (in particular this is the case in all the iterations of this fu= nction underlying an HMAC computation). Only the final output is truncated.=
=C2=A0

=C2=A0

Also, hasn=E2=80=99t the = weak collision resistance property, upon which [1] relies, for SHA-1 been u= ndermined?

<= /div>

The proof of Bellare 2006 does not rely on weak = collision resistance.
=C2=A0

=C2=A0

Menezes and Koblitz [5, S= ection 4] note that the advantage of tag truncation in some cases might not= be as much as previously thought.


Their note is specific to the potential b= enefits of truncation for the multi-user case. It does not imply anything o= n more common settings as those that (I guess) motivated this thread in the= first place.

Finally, in relation to your conclusions below, I'd note that the t= heoretical treatment of HMAC (or the underlying NMAC scheme) does=20 assume a key of a size equal to the hash length which is the size of=20 keys to the underlying keyed compression function. Hence SHA-256 should use= keys of size 256. Moreover, I have never seen a setting where keying SHA-2= 56 with 128 bits is easier in any way than keying it with 256 bits, so I se= e no reason to entertain 128-bit keys for SHA-256 even at the pragmatic/pra= ctical level.

Hugo
=C2=A0

=C2=A0

***<= /p>

=C2=A0

Phillip originally asked = about the need for HMAC-SHA256, and specifically mentioning the MAC tag len= gth, but his question could also be taken as a question for the need for 256-bit security vs. 128-bit security.=C2=A0 Let=E2=80=99= s suppose that 128-bit security is sufficient. =C2=A0Some reasons for optin= g for a higher security level (at least for HMAC) include the following.=

=C2=A0

-Margin of error, in case= the algorithms end up being weaker than one would think (e.g. MD5, SHA-1).=

=C2=A0

-Resistance to quantum co= mputers (either now or in the future).=C2=A0 Future adversaries cannot forg= e MACs today, but if all the keys are 128 bits, they can, at a cost about 2^64 quantum computer steps, recover a MAC keys from the mess= age and tag, and then recover the master key from the MAC is often derived,= and then recover the encryption key, and thereby compromise any of today= =E2=80=99s ciphertexts that they have stored.=C2=A0

=C2=A0

-Multi-user security (see= [5, Sections 2.2 and 4], reduces the security bits by the log of the numbe= r of users.

=C2=A0

***<= /p>

=C2=A0

Based on the consideratio= ns above, and general prudence, for 128-bit security and HMAC (if one canno= t use an alternative MAC, e.g. CMAC), I=E2=80=99d recommend HMAC-SHA256, but with a key larger than 128 bits (to address multi-user attacks). =C2= =A0It seems just fine to me truncate to 128 bits (i.e. my intuition says th= e margin of error provided by that SHA-256 using 256 bits instead of 128, i= .e. a wide pipe, during the internal computations, is sufficient.)

=C2=A0

References<= /span>

=C2=A0

[4] http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_gener= al.pdf

=C2=A0

[5] http://eprint= .iacr.org/2012/074

=C2=A0

=C2=A0

Appendix

=C2=A0

Just for fun: if one allo= ws super-long messages defined by a formula, then active HMAC forgery is ea= sy. (Martijn Stam showed me this, hope I got it right.)=C2=A0 Let B be any message block.=C2=A0 Let n =3D 2^256, integer (with ^ =3D exp= onentiation).=C2=A0 Let M =3D B^n, bit string (with ^ =3D repeated concaten= tation).=C2=A0 Let M=E2=80=99 =3D B^(n+n!), =C2=A0(with ! =3D factorial).= =C2=A0 Of course, these messages are absurdly long, and illegally long for = most definitions of HMAC, and infeasible to compute the HMAC tags of. =C2=A0Any= way, notice that HMAC(K,M) =3D HMAC(K,M=E2=80=99), for all keys K.=C2=A0 To= see this, think about Pollard rho.=C2=A0 Starting from the key, each block= B applies the same function.=C2=A0 The n iterations move this function into a cycle.=C2=A0 The extra n! cycles wrap around the cycle.=C2= =A0 For the active forgery, get the MAC signer to compute the T=3DHMAC(K,M)= .=C2=A0 Then present the T and M=E2=80=99 to a MAC verifier, who will accep= t T as valid even though the MAC signer never authenticated M=E2=80=99.=C2=A0 By the way, proofs must resist such absurdities, which I= think they all do rather easily, by limiting the message length or number = of compression function queries.

=C2=A0

Sorry for the length of t= his email.

=C2=A0

Daniel Brown

R= esearch In Motion Limited

=C2=A0

=C2=A0

=

=C2=A0

From: hugokraw@gmail.com [ma= ilto:hugokraw@gmail= .com] On Behalf Of Hugo Krawczyk
Sent: Thursday, July 12, 2012 11:37 PM
To: Dan Brown
Cc: ekr@rtfm.com; hallam@gmail.com<= /a>; saag@ietf.org


Subject: Re: [saag] How long should a MAC be?

=C2=A0

RFC 2104 doesn't say = what the security of SHA256 (or of any other function) is.

There is one fact, however, that does not depend on the underlying function= (or even on HMAC): a MAC tag of length t, even a perfect one, does not giv= e more than t bits of security=C2=A0 as the attacker can guess the MAC valu= e with probability 2^{-t} (and of course the attacker's advantage increases linearly with the number of MACed m= essages or the number of possible guesses by the attacker).

Hugo

On Thu, Jul 12, 2012 at 9:21 PM, Dan Brown <dbrown@certicom.com= > wrote:

So, in terms of security = levels, does what RFC 2104 says mean that HMAC-SHA256 provides 256-bit secu= rity, while truncating to 128 bits provides 128-bit security? Or does HMAC-SHA256 only provide 128 security?


=C2=A0

From: Hugo Kra= wczyk [mailto:h= ugo@ee.technion.ac.il]
Sent: Thursday, July 12, 2012 09:05 PM
To: Eric Rescorla <ekr@rtfm.com>
Cc: Dan Brown; hallam@gmail.com <hallam@gmail.com>; saag@ietf.org <saag@ietf.org>
Subject: Re: [saag] How long should a MAC be?
=C2=A0

On Thu, Jul 12, 2012 = at 7:38 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> Given that Bellare is a co-author on RFC 2104 and 2104 describes trunc= ation,
> I would certainly be sad to learn truncation wasn't OK.
>
> -Ekr

No r= eason to be sad, Eric.

The = text for HMAC truncation in RFC 2104 (see below) still holds. Confidence in= this mechanism is even stronger today given the proofs (and practical acce= ptance) of HMAC as a pseudo-random function [1,2,3]. This means that any subset of t bits from HMAC's output should be computati= onally indistinguishable from t random bits, therefore suitable for MAC (th= e security should be considered the minimum between the length of the MAC a= nd the security of HMAC, typically given by half the size of the hash length).

[1] M. Bellare, R. Canetti, and H. Krawczyk, "Keying Hash Functions fo= r Message Authentication", Crypto 1996.

[2] M. Bellare, R. Canetti, and H. Krawczyk, "Pseudorandom Functions R= evisited: The Cascade Construction", Proceedings of FOCS'96.

[3] M. Bellare "New Proofs for NMAC and HMAC: Security without Collisi= on-Resistance", Crypto 2006.

Here is the original text from the RFC

 5. Truncated output
=C2=A0
=C2=A0=C2=A0 A well-known practice with message authentication codes i=
s to
=C2=A0=C2=A0 truncate the output of the MAC and output only part of th=
e bits
=C2=A0=C2=A0 (e.g., [MM, ANSI]).=C2=A0 Preneel and van Oorschot [PV] s=
how some
=C2=A0=C2=A0 analytical advantages of truncating the output of hash-ba=
sed MAC
=C2=A0=C2=A0 functions. The results in this area are not absolute as f=
or the
=C2=A0=C2=A0 overall security advantages of truncation. It has advanta=
ges (less
=C2=A0=C2=A0 information on the hash result available to an attacker) =
and
=C2=A0=C2=A0 disadvantages (less bits to predict for the attacker).=C2=
=A0 Applications
=C2=A0=C2=A0 of HMAC can choose to truncate the output of HMAC by outp=
utting the t
=C2=A0=C2=A0 leftmost bits of the HMAC computation for some parameter =
t (namely,
=C2=A0=C2=A0 the computation is carried in the normal way as defined i=
n section 2
=C2=A0=C2=A0 above but the end result is truncated to t bits). We reco=
mmend that
=C2=A0=C2=A0 the output length t be not less than half the length of t=
he hash
=C2=A0=C2=A0 output (to match the birthday attack bound) and not less =
than 80 bits
=C2=A0=C2=A0 (a suitable lower bound on the number of bits that need t=
o be
=C2=A0=C2=A0 predicted by an attacker).=

Hugo

=C2=A0


On Thu, Jul 12, 2012 at 4:32 PM, Dan Brown <dbrown@certicom.com> wrote:
> Maybe some of the HMAC security proofs don't work if HMAC is trunc= ated. =C2=A0We could ask CFRG or Bellare.
>
> ----- Original Message -----
> From: Phillip Hallam-Baker [mailto:hallam@gmail.com]
> Sent: Wednesday, July 11, 2012 09:07 PM
> To: saag@ietf.org <saag@ietf.org= >
> Subject: [saag] How long should a MAC be?
>
> Yeah, yeah, digests, birthday attack, yadda yadda.
>
> But! A MAC is not a digest, it is an authentication mechanism. If I > use HMAC-SHA256 with a 128 bit key, I am going to have no more than > 128 bits of ergodicity in my output. So what is the justification for<= br> > presenting more than 128 bits?
>
> Now I guess someone can argue (OK they will) that HMAC-SHA256 with a > 256 bit key produces a full 256 bits of ergodicity in the output. But<= br> > given that we have agreed on 128 bits as 'sufficient' for encr= yption
> keys (well for the lifetime of this universe at least) why then demand=
> up to 512 for authentication?
>
> I know that there are perfectly good reasons for using AES-256, it is<= br> > not really the possibility of brute forcing the key that is the issue<= br> > so much as the fact that AES-512 has many more rounds than AES-128 and=
> is stronger. And when someone like Adi Shamir suggests AES might be a<= br> > little over-optimized, well I listen.
>
> What this comes down to is that I think we need a HMAC-SHA128 and
> maybe people who are really looking for 256 bits of authentication
> should be cutting HMAC-SHA512 in two...
>
> Just a thought.
>
> --
> Website: http://= hallambaker.com/
> _______________________________________________
> saag mailing list
> saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag
>
> ---------------------------------------------------------------------<= br> > This transmission (including any attachments) may contain confidential= information, privileged material (including material protected by the soli= citor-client or other applicable privileges), or constitute non-public info= rmation. Any use of this information by anyone other than the intended recipient is prohibited. If you have rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
> _______________________________________________
> saag mailing list
> saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag
_______________________________________________
saag mailing list
saag@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/saag

=C2=A0


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient is prohibited. If you have rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. =

=C2=A0

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful.

--14dae93996ed60971d04c4bf200a-- From gregory.ietf@gmail.com Sat Jul 14 23:09: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 EC9D911E8087 for ; Sat, 14 Jul 2012 23:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMP1Lt+d5WJn for ; Sat, 14 Jul 2012 23:09:05 -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 6478E11E8072 for ; Sat, 14 Jul 2012 23:09:05 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so8438491pbc.31 for ; Sat, 14 Jul 2012 23:09:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:x-google-sender-delegation:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=BXNFC3dO/SELFYRiGLYDtrjSNCzAHCaPgXKJ3GocSZQ=; b=0b15uA3QvkkyG7ErqWV2+0EF2FFfrr+qg9Q0KT6iDHkp8A1juqegnQQPNAlbNNBKgb tVj+Bo4mK4+6FN+XXqvrRTPITqdIhiRh2TCD7DEbEb+qcaSxE5Vbo4M5XEdlh46DEuYE RVL3Ely/5gVSMdQYI6JOccfiPYXbpCVmJARaM/M+zli9Y+9Z2HsORXd8ZHhr0Urj4B+O DbDbdGxq5S3C265iYbLoeI2AXLxMjDkwMvBCkO2mkHI97XV8LtNAUIympbP0qVTDjbbo 0B6DPoTHDKN7leJyuOdj6HQSLvlgN1dWti+EgUzWC755sn3PbksHRr9IwkHp0ROxs+OE tFPg== MIME-Version: 1.0 Received: by 10.68.201.9 with SMTP id jw9mr16732993pbc.28.1342332586298; Sat, 14 Jul 2012 23:09:46 -0700 (PDT) Sender: gregorylebo@gmail.com X-Google-Sender-Delegation: gregorylebo@gmail.com Received: by 10.143.161.17 with HTTP; Sat, 14 Jul 2012 23:09:46 -0700 (PDT) In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71208D3AC46@MX15A.corp.emc.com> References: <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> <4FEE41BB.3050705@deployingradius.com> <4FF1D139.5050601@isi.edu> <4FF1D5BE.7070907@isi.edu> <4FF1DBB2.5090407@isi.edu> <8D3D17ACE214DC429325B2B98F3AE71208D3AB53@MX15A.corp.emc.com> <7CACF142-6779-4321-918A-8A0452F73D6C@gmx.net> <8D3D17ACE214DC429325B2B98F3AE71208D3AC46@MX15A.corp.emc.com> Date: Sat, 14 Jul 2012 23:09:46 -0700 X-Google-Sender-Auth: _wt0heE5bRuRqG5bL3KdpMvu6Ow Message-ID: From: Gregory Lebovitz To: david.black@emc.com Content-Type: multipart/alternative; boundary=047d7b15a973fa0db004c4d828bd Cc: saag@ietf.org Subject: Re: [saag] SSL VPN 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, 15 Jul 2012 06:09:07 -0000 --047d7b15a973fa0db004c4d828bd Content-Type: text/plain; charset=ISO-8859-1 In line, On Tue, Jul 3, 2012 at 7:03 AM, wrote: > Hi Hannes, > > > A minor remark: The reason why email and Web access is explicitly > mentioned > > because that's what people use when they access their company services > (and > > any other service on the Internet as well). > > > > Of course the SSL / TLS based VPNs could carry other protocols on top of > it. > > And they do ... > > > I am not sure why you say it isn't a clever use of TLS to access > "SSL-based > > services." > > This is because the TLS is in the VPN, not the accessed services. > Obviously, > HTTPS and the like use a second encapsulated instance of TLS, but the > primary > TLS is in the SSL VPN, and it doesn't extend to the service. Specifically, > the TLS server cert presented by the SSL VPN (at least AnyConnect) is an > SSL > VPN cert, not a cert from the accessed service - to get the latter > requires an > instance of TLS that goes all the way to the service, not just to the SSL > VPN > gateway (ok, that was obvious ...). Hence one can run traffic over an SSL > VPN > that is unencrypted on the far side (enterprise network) of the SSL VPN > gateway. > Note: Not all SSL / TLS VPNs are created equally. The Juniper solution, by default, only uses the TLS connection to authenticate the user and set up a control channel. It then pushes down through that TLS connection a SA for an ESP connection between the host and the gateway, and the rest of the traffic is sent through the tunnel goes through the ESP. If ESP fails to get through, as is the case often enough due to in-the-middle firewalls that don't handle / allow ESP, then the tunnel reverts back to TLS. The advantages of SSL / TLS over pure IPsec are: - no need for explicit software download by IT department in order to make secure first remote connection; end-user just hits a URL, and the rest happens from there. This ease of deployment is THE MAIN reason that most large enterprises ditched pure IKE / IPsec clients and went to SSL VPNs. - gets through firewalls and NATs more readily - has other modes, non-tunnel-all, so that if the remote user is on a device where they cannot load software, they can still view email and browse / download / upload network files - the policy is stored and enforced at the gateway, so any changes are always instantaneous (or immediate upon next connection), and need not be pushed out to all the remote endpoints. As I said before, most enterprises have gone the route of SSL VPNs for remote access. The customers love the stuff. Hope it helps, Gregory > > Thanks, > --David > > > -----Original Message----- > > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > > Sent: Tuesday, July 03, 2012 2:02 AM > > To: Black, David > > Cc: Hannes Tschofenig; touch@isi.edu; saag@ietf.org > > Subject: Re: [saag] SSL VPN > > > > A minor remark: The reason why email and Web access is explicitly > mentioned > > because that's what people use when they access their company services > (and > > any other service on the Internet as well). > > > > Of course the SSL / TLS based VPNs could carry other protocols on top of > it. > > > > I am not sure why you say it isn't a clever use of TLS to access > "SSL-based > > services. > > > > On Jul 2, 2012, at 9:06 PM, wrote: > > > > > Joe Touch writes: > > > > > >>>>> What, you've never heard of an SSL VPN? > > >>>> > > >>>> I've also heard of token ring, but besides the geek community, it's > not > > used > > >>>> all that much. The dominant VPNs are IPsec and PPTP. > > >>> > > >>> Yeah, that's why both Cisco and Juniper have big SSL VPN product > lines and > > >>> why Cisco AnyConnect now supports DTLS. > > >> > > >> From their pages, these appear to be focused on support for email and > > >> web access to SSL-based services. E.g., from Cisco's page: > > >> > > >> --- > > >> SSL VPN Overview > > >> > > >> Cisco IOS SSL VPN provides SSL VPN remote-access connectivity from > > >> almost any Internet-enabled location using only a web browser that > > >> natively supports SSL encryption. This feature allows your company to > > >> extend access to its secure enterprise network to any authorized user > by > > >> providing remote-access connectivity to corporate resources from any > > >> Internet-enabled location. > > >> --- > > >> > > >> I.e., that's web browser access to services. > > > > > > That's wrong, sorry. An SSL VPN provides full IP network extension - > > > it's most definitely not browser-only. The technology is effectively > IP > > > encapsulation in TLS, not clever use of TLS to access "SSL-based > services." > > > > > > EMC uses AnyConnect for secure remote access, and it effectively > > > replaced usage of remote access IPsec VPNs for the entire company. > > > > > > Thanks, > > > --David > > > ---------------------------------------------------- > > > David L. Black, Distinguished Engineer > > > EMC Corporation, 176 South St., Hopkinton, MA 01748 > > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > > david.black@emc.com Mobile: +1 (978) 394-7754 > > > ---------------------------------------------------- > > > > > > _______________________________________________ > > > 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 > -- ---- IETF related email from Gregory M. Lebovitz --047d7b15a973fa0db004c4d828bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In line,

On Tue, Jul 3, 2012 at 7:03 AM,= <david.black@emc.com> wrote:
Hi Hannes,

> A minor remark: The reason why email and Web access is explicitly ment= ioned
> because that's what people use when they access their company serv= ices (and
> any other service on the Internet as well).
>
> Of course the SSL / TLS based VPNs could carry other protocols on top = of it.

And they do ...

> I am not sure why you say it isn't a clever use of TLS to access &= quot;SSL-based
> services."

This is because the TLS is in the VPN, not the accessed services. =A0= Obviously,
HTTPS and the like use a second encapsulated instance of TLS, but the prima= ry
TLS is in the SSL VPN, and it doesn't extend to the service. =A0Specifi= cally,
the TLS server cert presented by the SSL VPN (at least AnyConnect) is an SS= L
VPN cert, not a cert from the accessed service - to get the latter requires= an
instance of TLS that goes all the way to the service, not just to the SSL V= PN
gateway (ok, that was obvious ...). =A0Hence one can run traffic over an SS= L VPN
that is unencrypted on the far side (enterprise network) of the SSL VPN gat= eway.

Note: Not all SSL / TLS VPNs are = created equally. The Juniper solution, by default, only uses the TLS connec= tion to authenticate the user and set up a =A0control channel. It then push= es down through that TLS connection a SA for an ESP connection between the = host and the gateway, and the rest of the traffic is sent through the tunne= l goes through the ESP. If ESP fails to get through, as is the case often e= nough due to in-the-middle firewalls that don't handle / allow ESP, the= n the tunnel reverts back to TLS.

The advantages of SSL / TLS over pure IPsec are:
<= div>=A0- no need for explicit software download by IT department in order t= o make secure first remote connection; end-user just hits a URL, and the re= st happens from there. This ease of deployment is THE MAIN reason that most= large enterprises ditched pure IKE / IPsec clients and went to SSL VPNs.
=A0- gets through firewalls and NATs more readily
=A0- has o= ther modes, non-tunnel-all, so that if the remote user is on a device where= they cannot load software, they can still view email and browse / download= / upload network files
=A0- the policy is stored and enforced at the gateway, so any changes = are always instantaneous (or immediate upon next connection), and need not = be pushed out to all the remote endpoints.

As I sa= id before, most enterprises have gone the route of SSL VPNs for remote acce= ss. The customers love the stuff.

Hope it helps,
Gregory

=A0

Thanks,
--David

> -----Original Message-----
> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]
> Sent: Tuesday, July 03, 2012 2:02 AM
> To: Black, David
> Cc: Hannes Tschofenig; touch@isi.edu<= /a>; saag@ietf.org
> Subject: Re: [saag] SSL VPN
>
> A minor remark: The reason why email and Web access is explicitly ment= ioned
> because that's what people use when they access their company serv= ices (and
> any other service on the Internet as well).
>
> Of course the SSL / TLS based VPNs could carry other protocols on top = of it.
>
> I am not sure why you say it isn't a clever use of TLS to access &= quot;SSL-based
> services.
>
> On Jul 2, 2012, at 9:06 PM, <david.black@emc.com> wrote:
>
> > Joe Touch writes:
> >
> >>>>> What, you've never heard of an SSL VPN?
> >>>>
> >>>> I've also heard of token ring, but besides the ge= ek community, it's not
> used
> >>>> all that much. The dominant VPNs are IPsec and PPTP.<= br> > >>>
> >>> Yeah, that's why both Cisco and Juniper have big SSL = VPN product lines and
> >>> why Cisco AnyConnect now supports DTLS.
> >>
> >> From their pages, these appear to be focused on support for e= mail and
> >> web access to SSL-based services. E.g., from Cisco's page= :
> >>
> >> ---
> >> SSL VPN Overview
> >>
> >> Cisco IOS SSL VPN provides SSL VPN remote-access connectivity= from
> >> almost any Internet-enabled location using only a web browser= that
> >> natively supports SSL encryption. This feature allows your co= mpany to
> >> extend access to its secure enterprise network to any authori= zed user by
> >> providing remote-access connectivity to corporate resources f= rom any
> >> Internet-enabled location.
> >> ---
> >>
> >> I.e., that's web browser access to services.
> >
> > That's wrong, sorry. =A0An SSL VPN provides full IP network e= xtension -
> > it's most definitely not browser-only. =A0The technology is e= ffectively IP
> > encapsulation in TLS, not clever use of TLS to access "SSL-b= ased services."
> >
> > EMC uses AnyConnect for secure remote access, and it effectively<= br> > > replaced usage of remote access IPsec VPNs for the entire company= .
> >
> > Thanks,
> > --David
> > ----------------------------------------------------
> > David L. Black, Distinguished Engineer
> > EMC Corporation, 176 South St., Hopkinton, MA =A001748
> > +1 (508) 293-7953 =A0 =A0 =A0 =A0 =A0 =A0 FAX: +1 (508) 293-7786
> > david.black@emc.com = =A0 =A0 =A0 =A0Mobile: +1 (978) 394-7754
> > ----------------------------------------------------
> >
> > _______________________________________________
> > saag mailing list
> > saag@ietf.org
> > https://www.ietf.org/mailman/listinfo/saag
>

_______________________________________________
saag mailing list
saag@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/saag



--
= ----
IETF related email from
Gregory M. Lebovitz

--047d7b15a973fa0db004c4d828bd-- From hannes.tschofenig@gmx.net Sun Jul 15 03:02: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 A0B5721F8600 for ; Sun, 15 Jul 2012 03:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.63 X-Spam-Level: X-Spam-Status: No, score=-102.63 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0BlkWFfp3NT for ; Sun, 15 Jul 2012 03:02:38 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 87E3321F85F9 for ; Sun, 15 Jul 2012 03:02:37 -0700 (PDT) Received: (qmail invoked by alias); 15 Jul 2012 10:03:17 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.106]) [88.115.216.191] by mail.gmx.net (mp027) with SMTP; 15 Jul 2012 12:03:17 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/e0Mo7SPTekFLqcHCB4OxsyjeetP7baVr6BHH2Q+ 3vJbJq2mQuXWYQ From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 15 Jul 2012 13:03:16 +0300 Message-Id: <36712B13-7409-484B-8A86-85AE8A5CB23A@gmx.net> To: saag@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [saag] draft-farrell-decade-ni-09 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, 15 Jul 2012 10:02:38 -0000 Hi all,=20 I don't really know what the right place is to discuss this document. = Hence, I trying the saag mailing list.=20 I read through the document and my impression is that it tries to = accomplish a little bit too too much.=20 As a high level comment you cannot make an assumption about what = information is hashed. Another specification is needed to explain the = semantic and these other documents exist. For example, I had asked on = the TLS mailing list whether we should use this document to convey = fingerprints of raw public keys (which come in form of a = SubjectPublicKeyInfo in our case).=20 This has an impact on the security consideration section, the hash = algorithm registry, and various statements made in the document.=20 For example, the statement that "... the hash SHOULD be calculated over = the public key in an X.509 SubjectPublicKeyInfo structure..." isn't = really useful when the document aims to provide hashes of all sorts of = objects and some might not even be X.509 certificates at all.=20 The encoding of the URI also seems a bit strange. It seems that you have = started with the Web use case and then though "Cool. This could be = useful in other protocols as well.". But the problem is that other = protocols have their own encoding. For example, in the TLS out-of-band = validation mechanism there is no internationalization issue nor a need = to do a base64 encoding. The binary encoding falls into that category as = well. =20 The .well-known seems to me pretty unrelated to this specification and = may have sneaked into the document as part of the Web use case.=20 The security consideration is a collection of random thoughts. I have = difficulty understanding what is being said there. There are in general = two problems to come up with a meaningful text. The first problem is = related to the generic nature of your document: it makes a difference = what you hash. To pick the TLS oob validation document again there we = have a hash of the public key. In other cases you are talking about = hashing some file or other objects. Then, the second problem is that you = do not know what is done with the hash as part of the overall protocol = interaction of the application that is using your URI scheme. So, in the = TLS oob validation draft the hash of the public key is associated with = the public key cached from an earlier exchange and is also linked to the = private key that is then used in the TLS handshake. In other = applications the hash just be used to point to some state information = that is retrieved.=20 In a nutshell, there is room to simplify the document.=20 Ciao Hannes PS: I am not sure what you are trying to accomplish with the Content = Type Query String.=20= From stephen.farrell@cs.tcd.ie Sun Jul 15 05:41: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 DF1CA21F8594 for ; Sun, 15 Jul 2012 05:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.887 X-Spam-Level: X-Spam-Status: No, score=-102.887 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I99Pjkpw7sPj for ; Sun, 15 Jul 2012 05:41:38 -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 9407121F8587 for ; Sun, 15 Jul 2012 05:41:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 5B59C1714E5; Sun, 15 Jul 2012 13:42:17 +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=1342356135; bh=x/GDJiapCD8NKK q9+Z/ZRVNIg8Rdt8Sg8tNPLAATXAM=; b=LCy131qI3v6zQBI4bRUacrWTa+rEDV +6KCYIcfOL0pJpKJAbDXFlgMy6ihZQF/1BcsKR5Qdcu+UvxGz6doLJhSKdz5Sgbj PvaB2zCxdsUK32TzboeXod1Ng/tJ6BWKBBrWK0iF5PzuLU4qYWBa3QDz3m+OrxTO b3HwpYRszrkMISpCWEBD1TFNrx5kY4yvzzB+IjEQ1QzHV5ESMNFBf60EYNiJ5XAZ Ro/ROzq4YKYHRdxt8EzrBQKlD+pNCisE87klvgA0+nXxq7Daghuj4dVvuQfUdWDh zsmkQnqdo5QDaVVru0xPQkDMt5SY0muPcc4Aem22WgMXXOyHryoC7+Cg== 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 6C+YeSz6kukC; Sun, 15 Jul 2012 13:42:15 +0100 (IST) Received: from [10.87.48.11] (unknown [86.42.23.214]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6D8BF1714E4; Sun, 15 Jul 2012 13:42:15 +0100 (IST) Message-ID: <5002BAA6.9030106@cs.tcd.ie> Date: Sun, 15 Jul 2012 13:42:14 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Hannes Tschofenig References: <36712B13-7409-484B-8A86-85AE8A5CB23A@gmx.net> In-Reply-To: <36712B13-7409-484B-8A86-85AE8A5CB23A@gmx.net> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: saag@ietf.org Subject: Re: [saag] draft-farrell-decade-ni-09 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, 15 Jul 2012 12:41:40 -0000 Hi Hannes, That seems like a bunch of non-actionable comments so I don't know what response you were after. My guess is you were expecting to read some other document, and were surprised when you saw the actual content here. But I'm not sure that's a problem that's fixable, nor ought be fixed via changes to this draft. On 07/15/2012 11:03 AM, Hannes Tschofenig wrote: > Hi all, > > I don't really know what the right place is to discuss this document. It was discussed on apps-discuss before IETF LC, starting from around the Paris IETF. During IETF LC it was discussed a lot (well, I think a lot:-) on ietf@ietf.org and IETF LC ended last week. The document's on next week's telechat so if you have specific concerns you might want to communicate them to an AD as well. > Hence, I trying the saag mailing list. If you look at the apps-disucss or ietf@ietf.org archives you'll maybe get some useful background that covers some of this. > I read through the document and my impression is that it tries to accomplish a little bit too too much. > > As a high level comment you cannot make an assumption about what information is hashed. Another specification is needed to explain the semantic and these other documents exist. For example, I had asked on the TLS mailing list whether we should use this document to convey fingerprints of raw public keys (which come in form of a SubjectPublicKeyInfo in our case). I have no idea what you mean. This draft can tell you how to format hash outputs but can't specify inputs if its to be useful. Part of the reason for the draft was that other protocols that can specify the inputs and the use of the outputs, were all doing it trivially differently, which seems like a bad plan. (The document says that.) > This has an impact on the security consideration section, the hash algorithm registry, and various statements made in the document. > > For example, the statement that "... the hash SHOULD be calculated over the public key in an X.509 SubjectPublicKeyInfo structure..." isn't really useful when the document aims to provide hashes of all sorts of objects and some might not even be X.509 certificates at all. I disagree. For the case of public keys, we do know that that format is useful in more than one case. MUST would be too much since generally other specs define hash inputs. Hence SHOULD. I think its correct as-is. > The encoding of the URI also seems a bit strange. It seems that you have started with the Web use case and then though "Cool. This could be useful in other protocols as well.". But the problem is that other protocols have their own encoding. For example, in the TLS out-of-band validation mechanism there is no internationalization issue nor a need to do a base64 encoding. The binary encoding falls into that category as well. So use it or don't use it, but saying its "a bit strange" is... "a bit strange." If you want the binary format, then use that rather than the ni format. That's all fine. > The .well-known seems to me pretty unrelated to this specification and may have sneaked into the document as part of the Web use case. I don't know how to handle a "sneaked in" comment. I think its a fine thing. (PHB's idea as it happens.) > The security consideration is a collection of random thoughts. Again, that's not a comment I know how to process. > I have difficulty understanding what is being said there. There are in general two problems to come up with a meaningful text. The first problem is related to the generic nature of your document: it makes a difference what you hash. To pick the TLS oob validation document again there we have a hash of the public key. In other cases you are talking about hashing some file or other objects. Then, the second problem is that you do not know what is done with the hash as part of the overall protocol interaction of the application that is using your URI scheme. So, in the TLS oob validation draft the hash of the public key is associated with the public key cached from an earlier exchange and is also linked to the private key that is then used in the TLS handshake. In other applications the hash just be used to point to some state information that is retrieved. The consequences of using these formats are IMO properly the concern of other documents. > In a nutshell, there is room to simplify the document. In a nutshell, I guess you were expecting something else. Am I right? If so, then perhaps your comments are more about that surprise rather than the content of the draft perhaps? S. > > Ciao > Hannes > > PS: I am not sure what you are trying to accomplish with the Content Type Query String. See the discussion on ietf@ietf.org where a whole bunch of folks wanted that. > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From hannes.tschofenig@gmx.net Sun Jul 15 08:10: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 5CCD521F858F for ; Sun, 15 Jul 2012 08:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.629 X-Spam-Level: X-Spam-Status: No, score=-102.629 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gtk210px8wBo for ; Sun, 15 Jul 2012 08:10:15 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 1434321F8535 for ; Sun, 15 Jul 2012 08:10:14 -0700 (PDT) Received: (qmail invoked by alias); 15 Jul 2012 15:10:55 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.106]) [88.115.216.191] by mail.gmx.net (mp069) with SMTP; 15 Jul 2012 17:10:55 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+3lvp+qga3+sO1DzjK8tmtf8rs8z3zf5ZcA8gS/Z NXyb8fxXKRD9T/ Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <5002BAA6.9030106@cs.tcd.ie> Date: Sun, 15 Jul 2012 18:10:54 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <54EAB1F1-A9EF-49E7-92B7-406556C1EC35@gmx.net> References: <36712B13-7409-484B-8A86-85AE8A5CB23A@gmx.net> <5002BAA6.9030106@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: saag@ietf.org Subject: Re: [saag] draft-farrell-decade-ni-09 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, 15 Jul 2012 15:10:16 -0000 Hi Stephen,=20 I would expect to find the NI and the NIH scheme in there and nothing = more. The rest of feature creep (commonly found in EU funded projects - = hint!). =20 Nothing about binary encoding, base64 encoding of the URI, anything = about certificate formats behind hashed with normative language, no = authority field in the URI, no query parameter in the URI, no = .well-known URI.=20 The consequence: half the size and twice as useful.=20 Ciao Hannes On Jul 15, 2012, at 3:42 PM, Stephen Farrell wrote: >=20 > Hi Hannes, >=20 > That seems like a bunch of non-actionable comments so > I don't know what response you were after. >=20 > My guess is you were expecting to read some other > document, and were surprised when you saw the actual > content here. But I'm not sure that's a problem that's > fixable, nor ought be fixed via changes to this draft. >=20 > On 07/15/2012 11:03 AM, Hannes Tschofenig wrote: >> Hi all,=20 >>=20 >> I don't really know what the right place is to discuss this document.=20= >=20 > It was discussed on apps-discuss before IETF LC, starting from > around the Paris IETF. During IETF LC it was discussed a lot > (well, I think a lot:-) on ietf@ietf.org and IETF LC ended > last week. The document's on next week's telechat so if you > have specific concerns you might want to communicate them to > an AD as well. >=20 >> Hence, I trying the saag mailing list. >=20 > If you look at the apps-disucss or ietf@ietf.org archives > you'll maybe get some useful background that covers some of > this. >=20 >> I read through the document and my impression is that it tries to = accomplish a little bit too too much.=20 >>=20 >> As a high level comment you cannot make an assumption about what = information is hashed. Another specification is needed to explain the = semantic and these other documents exist. For example, I had asked on = the TLS mailing list whether we should use this document to convey = fingerprints of raw public keys (which come in form of a = SubjectPublicKeyInfo in our case).=20 >=20 > I have no idea what you mean. This draft can tell you how to > format hash outputs but can't specify inputs if its to be > useful. Part of the reason for the draft was that other > protocols that can specify the inputs and the use of the > outputs, were all doing it trivially differently, which > seems like a bad plan. (The document says that.) >=20 >> This has an impact on the security consideration section, the hash = algorithm registry, and various statements made in the document.=20 >>=20 >> For example, the statement that "... the hash SHOULD be calculated = over the public key in an X.509 SubjectPublicKeyInfo structure..." isn't = really useful when the document aims to provide hashes of all sorts of = objects and some might not even be X.509 certificates at all.=20 >=20 > I disagree. For the case of public keys, we do know that that > format is useful in more than one case. MUST would be too > much since generally other specs define hash inputs. Hence > SHOULD. I think its correct as-is. >=20 >> The encoding of the URI also seems a bit strange. It seems that you = have started with the Web use case and then though "Cool. This could be = useful in other protocols as well.". But the problem is that other = protocols have their own encoding. For example, in the TLS out-of-band = validation mechanism there is no internationalization issue nor a need = to do a base64 encoding. The binary encoding falls into that category as = well. =20 >=20 > So use it or don't use it, but saying its "a bit strange" is... "a bit > strange." If you want the binary format, then use that rather than > the ni format. That's all fine. >=20 >> The .well-known seems to me pretty unrelated to this specification = and may have sneaked into the document as part of the Web use case.=20 >=20 > I don't know how to handle a "sneaked in" comment. I think its > a fine thing. (PHB's idea as it happens.) >=20 >> The security consideration is a collection of random thoughts.=20 >=20 > Again, that's not a comment I know how to process. >=20 >> I have difficulty understanding what is being said there. There are = in general two problems to come up with a meaningful text. The first = problem is related to the generic nature of your document: it makes a = difference what you hash. To pick the TLS oob validation document again = there we have a hash of the public key. In other cases you are talking = about hashing some file or other objects. Then, the second problem is = that you do not know what is done with the hash as part of the overall = protocol interaction of the application that is using your URI scheme. = So, in the TLS oob validation draft the hash of the public key is = associated with the public key cached from an earlier exchange and is = also linked to the private key that is then used in the TLS handshake. = In other applications the hash just be used to point to some state = information that is retrieved.=20 >=20 > The consequences of using these formats are IMO properly the > concern of other documents. >=20 >> In a nutshell, there is room to simplify the document.=20 >=20 > In a nutshell, I guess you were expecting something else. > Am I right? If so, then perhaps your comments are more about > that surprise rather than the content of the draft perhaps? >=20 > S. >=20 >>=20 >> Ciao >> Hannes >>=20 >> PS: I am not sure what you are trying to accomplish with the Content = Type Query String.=20 >=20 > See the discussion on ietf@ietf.org where a whole bunch > of folks wanted that. >=20 >=20 >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >>=20 >=20 From stephen.farrell@cs.tcd.ie Sun Jul 15 08:30: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 1757521F85B1 for ; Sun, 15 Jul 2012 08:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.868 X-Spam-Level: X-Spam-Status: No, score=-102.868 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6QHRa8Dt3g1 for ; Sun, 15 Jul 2012 08:30:19 -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 B483721F8606 for ; Sun, 15 Jul 2012 08:30:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 293201714E5; Sun, 15 Jul 2012 16:30:59 +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=1342366258; bh=WFJpQM6WALUZXb anzyelZh5Jt/zi+Q/82Uw9WU0It2g=; b=Ieeqxbr5YUtd5js7xbSSC+BIpfDYMS 4TKQ6XCksja3z0nPXf4xVXVh7mV8DnNFJqEejvu7HA21SIiME9isou+VsPPLf60Q fbmHhL03zpXAVCg+7wA/DySX8H5HTqiiTYgLj7dMoj3RAtz4oWBSJe3x7pz7YYYz YDfnx53r9TAupqAiHJmxQuCelZ6rD0kHw8/Gl1aQ/peR2msUZAV2lUv6NWqWmSh3 zv9C5AOqJS3+GvAt+8XKV5235k1Xt2Zn/B7vcg0hWiQMeLQZXsvm9M3fPc3wLUnK bxEL7+8bgjIpUxCcpyMqSIImbVh8lbehD5YxS9dulB4Pw8pHbTQxnc2Q== 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 LjX4IWqJtPTJ; Sun, 15 Jul 2012 16:30:58 +0100 (IST) Received: from [10.87.48.11] (unknown [86.42.23.214]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 4141B1714E4; Sun, 15 Jul 2012 16:30:58 +0100 (IST) Message-ID: <5002E231.4090005@cs.tcd.ie> Date: Sun, 15 Jul 2012 16:30:57 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Hannes Tschofenig References: <36712B13-7409-484B-8A86-85AE8A5CB23A@gmx.net> <5002BAA6.9030106@cs.tcd.ie> <54EAB1F1-A9EF-49E7-92B7-406556C1EC35@gmx.net> In-Reply-To: <54EAB1F1-A9EF-49E7-92B7-406556C1EC35@gmx.net> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: saag@ietf.org Subject: Re: [saag] draft-farrell-decade-ni-09 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, 15 Jul 2012 15:30:20 -0000 On 07/15/2012 04:10 PM, Hannes Tschofenig wrote: > Hi Stephen, > > I would expect to find the NI and the NIH scheme in there and nothing more. The rest of feature creep (commonly found in EU funded projects - hint!). > > Nothing about binary encoding, base64 encoding of the URI, anything about certificate formats behind hashed with normative language, no authority field in the URI, no query parameter in the URI, no .well-known URI. > > The consequence: half the size and twice as useful. Actually, the draft was half the size early this year. The functional additions were nih, the binary format and the content type, due to requirements from the core wg and then comments during IETF LC. There were a lot of small pieces of additional text added as a result of IETF LC and discussion on apps-discuss. While that was a bit of a pain, to be honest, I can't point at any and say it doesn't belong, nor did I see scope to make it a lot shorter last time I went over it. So in this case, any "creep" has been caused as a result of IETF processes, (or "review" to put it more nicely:-) and was nothing to do with (our) funding source. I think you're mis-diagnosed this one to be honest. S. > > Ciao > Hannes > > On Jul 15, 2012, at 3:42 PM, Stephen Farrell wrote: > >> >> Hi Hannes, >> >> That seems like a bunch of non-actionable comments so >> I don't know what response you were after. >> >> My guess is you were expecting to read some other >> document, and were surprised when you saw the actual >> content here. But I'm not sure that's a problem that's >> fixable, nor ought be fixed via changes to this draft. >> >> On 07/15/2012 11:03 AM, Hannes Tschofenig wrote: >>> Hi all, >>> >>> I don't really know what the right place is to discuss this document. >> >> It was discussed on apps-discuss before IETF LC, starting from >> around the Paris IETF. During IETF LC it was discussed a lot >> (well, I think a lot:-) on ietf@ietf.org and IETF LC ended >> last week. The document's on next week's telechat so if you >> have specific concerns you might want to communicate them to >> an AD as well. >> >>> Hence, I trying the saag mailing list. >> >> If you look at the apps-disucss or ietf@ietf.org archives >> you'll maybe get some useful background that covers some of >> this. >> >>> I read through the document and my impression is that it tries to accomplish a little bit too too much. >>> >>> As a high level comment you cannot make an assumption about what information is hashed. Another specification is needed to explain the semantic and these other documents exist. For example, I had asked on the TLS mailing list whether we should use this document to convey fingerprints of raw public keys (which come in form of a SubjectPublicKeyInfo in our case). >> >> I have no idea what you mean. This draft can tell you how to >> format hash outputs but can't specify inputs if its to be >> useful. Part of the reason for the draft was that other >> protocols that can specify the inputs and the use of the >> outputs, were all doing it trivially differently, which >> seems like a bad plan. (The document says that.) >> >>> This has an impact on the security consideration section, the hash algorithm registry, and various statements made in the document. >>> >>> For example, the statement that "... the hash SHOULD be calculated over the public key in an X.509 SubjectPublicKeyInfo structure..." isn't really useful when the document aims to provide hashes of all sorts of objects and some might not even be X.509 certificates at all. >> >> I disagree. For the case of public keys, we do know that that >> format is useful in more than one case. MUST would be too >> much since generally other specs define hash inputs. Hence >> SHOULD. I think its correct as-is. >> >>> The encoding of the URI also seems a bit strange. It seems that you have started with the Web use case and then though "Cool. This could be useful in other protocols as well.". But the problem is that other protocols have their own encoding. For example, in the TLS out-of-band validation mechanism there is no internationalization issue nor a need to do a base64 encoding. The binary encoding falls into that category as well. >> >> So use it or don't use it, but saying its "a bit strange" is... "a bit >> strange." If you want the binary format, then use that rather than >> the ni format. That's all fine. >> >>> The .well-known seems to me pretty unrelated to this specification and may have sneaked into the document as part of the Web use case. >> >> I don't know how to handle a "sneaked in" comment. I think its >> a fine thing. (PHB's idea as it happens.) >> >>> The security consideration is a collection of random thoughts. >> >> Again, that's not a comment I know how to process. >> >>> I have difficulty understanding what is being said there. There are in general two problems to come up with a meaningful text. The first problem is related to the generic nature of your document: it makes a difference what you hash. To pick the TLS oob validation document again there we have a hash of the public key. In other cases you are talking about hashing some file or other objects. Then, the second problem is that you do not know what is done with the hash as part of the overall protocol interaction of the application that is using your URI scheme. So, in the TLS oob validation draft the hash of the public key is associated with the public key cached from an earlier exchange and is also linked to the private key that is then used in the TLS handshake. In other applications the hash just be used to point to some state information that is retrieved. >> >> The consequences of using these formats are IMO properly the >> concern of other documents. >> >>> In a nutshell, there is room to simplify the document. >> >> In a nutshell, I guess you were expecting something else. >> Am I right? If so, then perhaps your comments are more about >> that surprise rather than the content of the draft perhaps? >> >> S. >> >>> >>> Ciao >>> Hannes >>> >>> PS: I am not sure what you are trying to accomplish with the Content Type Query String. >> >> See the discussion on ietf@ietf.org where a whole bunch >> of folks wanted that. >> >> >>> _______________________________________________ >>> saag mailing list >>> saag@ietf.org >>> https://www.ietf.org/mailman/listinfo/saag >>> >> > > > From hannes.tschofenig@gmx.net Mon Jul 16 11:22: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 DD4F611E826B for ; Mon, 16 Jul 2012 11:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.626 X-Spam-Level: X-Spam-Status: No, score=-102.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njI+PeyDa+Bd for ; Mon, 16 Jul 2012 11:22:12 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id E735111E819D for ; Mon, 16 Jul 2012 11:22:11 -0700 (PDT) Received: (qmail invoked by alias); 16 Jul 2012 18:17:07 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.102]) [88.115.216.191] by mail.gmx.net (mp031) with SMTP; 16 Jul 2012 20:17:07 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18+RqUoHvE+LnNp8QX6u8LbcLtyHahYPAhbN6sfni 3qCW7s754UE7zN From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Jul 2012 21:15:40 +0300 Message-Id: To: saag@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [saag] Password Discussion 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, 16 Jul 2012 18:22:13 -0000 Hi all,=20 given the longer discussion related to passwords I thought it makes = sense to point you to a document we had written about various problems = related to Web security:=20 http://tools.ietf.org/html/draft-tschofenig-secure-the-web-03 Ciao Hannes PS: I case you want to hear my view on standardizing a new = authentication mechanism (whatever it might be) or even an entire = authentication framework then I have to say that we have to take the = recent developments in the W3C into consideration and the work on the = JavaScript CryptoAPI looks very promising to me. With it an identity = provider can write their favorite authentication protocol and send it to = the browser. No need for standardizing a new authentication protocol = anymore nor a framework either. JavaScript is the framework.... From yaronf.ietf@gmail.com Mon Jul 16 11:46:52 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 17B3811E80E4 for ; Mon, 16 Jul 2012 11:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9OEP3fTnIr4 for ; Mon, 16 Jul 2012 11:46:51 -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 F0A8311E80D3 for ; Mon, 16 Jul 2012 11:46:50 -0700 (PDT) Received: by bkty7 with SMTP id y7so4567273bkt.31 for ; Mon, 16 Jul 2012 11:47:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=dFnGmuCBwLJMBmmfG0bc0F8QIN9qycrNT+1awRJM0KU=; b=zasu+kAGiL2QjuC0NHNy4l3S2gHrJMACUdH7kcB0amHpjtvojpc85io18prXVBIU2q byKSKmW40hm+rwrE768VPtqLJCXxZnzZuuo5DGjo6q1kRePCUVLt/aRcRLFsXjaXFbCP v+/Mtr/C5x6GgdSRQBYDPloUm2sN53BSUpeHCrZAM+fvNW7kDJL9P45CQJMVf8vnW+L+ W7ySMIpWMFaiIh7wam42RfjPJwmAizrFnHo+7iGX/W3Oyb+m4U1inx/ZhE74ej3iDZ/K XKcpMl409D2/+zhnNeMAIQtwULovTIKXDKVV80wzrkUBJBdrrijZAB0OCTmIRixRAoiE Q8jw== Received: by 10.204.128.202 with SMTP id l10mr5160026bks.127.1342464455501; Mon, 16 Jul 2012 11:47:35 -0700 (PDT) Received: from [10.0.0.3] (bzq-79-182-163-254.red.bezeqint.net. [79.182.163.254]) by mx.google.com with ESMTPS id g6sm8710339bkg.2.2012.07.16.11.47.34 (version=SSLv3 cipher=OTHER); Mon, 16 Jul 2012 11:47:35 -0700 (PDT) Message-ID: <500461C5.7020006@gmail.com> Date: Mon, 16 Jul 2012 21:47:33 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Hannes Tschofenig References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: saag@ietf.org Subject: Re: [saag] Password Discussion 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, 16 Jul 2012 18:46:52 -0000 Hi Hannes, I may be missing something big, but I'm puzzled by your postscript below. First, if you want the actual connection to the server (or to any kind of trust anchor, IdP and the like) to be secure, you need the entire protocol implementation to be trusted. Untrusted JavaScript on top of a trusted crypto layer won't cut it. As a result, I see very little value in a standard crypto API for JavaScript, compared to "industry-standard" libraries like JQuery. A standard crypto API certainly won't hurt, but I'd be surprised if it has a significant effect on Web security as a whole. On the other hand a widely deployed HTTP authentication mechanism, if it's good enough (for whatever value of "good enough") could make a real difference. Thanks, Yaron On 07/16/2012 09:15 PM, Hannes Tschofenig wrote: > Hi all, > > given the longer discussion related to passwords I thought it makes sense to point you to a document we had written about various problems related to Web security: > http://tools.ietf.org/html/draft-tschofenig-secure-the-web-03 > > Ciao > Hannes > > PS: I case you want to hear my view on standardizing a new authentication mechanism (whatever it might be) or even an entire authentication framework then I have to say that we have to take the recent developments in the W3C into consideration and the work on the JavaScript CryptoAPI looks very promising to me. With it an identity provider can write their favorite authentication protocol and send it to the browser. No need for standardizing a new authentication protocol anymore nor a framework either. JavaScript is the framework.... > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From paul.hoffman@vpnc.org Mon Jul 16 12:07:46 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 7B63A11E82EB for ; Mon, 16 Jul 2012 12:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJW3gjOPiVsm for ; Mon, 16 Jul 2012 12:07:45 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id AFD3C21F88BD for ; Mon, 16 Jul 2012 12:07:45 -0700 (PDT) Received: from [10.20.30.102] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q6GIMR1K049994 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Jul 2012 11:22:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <500461C5.7020006@gmail.com> Date: Mon, 16 Jul 2012 12:08:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <500461C5.7020006@gmail.com> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1278) Cc: IETF Security Area Advisory Group Subject: Re: [saag] Password Discussion 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, 16 Jul 2012 19:07:46 -0000 In addition, an authentication "framework" that relies on Javascript = kinda bolloxes all proxies, yes? That seems like an architectural change = that might not be considered completely positive, to say the least. --Paul Hoffman= From hannes.tschofenig@gmx.net Mon Jul 16 12:09: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 CE6B011E82F9 for ; Mon, 16 Jul 2012 12:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.626 X-Spam-Level: X-Spam-Status: No, score=-102.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQXltU1QRWWK for ; Mon, 16 Jul 2012 12:09:48 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 3D8D611E82E4 for ; Mon, 16 Jul 2012 12:09:47 -0700 (PDT) Received: (qmail invoked by alias); 16 Jul 2012 19:07:32 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.102]) [88.115.216.191] by mail.gmx.net (mp001) with SMTP; 16 Jul 2012 21:07:32 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18BzPIs48cBfKjwfsX6r9N7pYuiUqENiAd7IPgkH5 K2A5tIhst96EuR Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <500461C5.7020006@gmail.com> Date: Mon, 16 Jul 2012 22:07:31 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8CA8896B-D506-4581-8A2E-E223D6EA7584@gmx.net> References: <500461C5.7020006@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: saag@ietf.org Subject: Re: [saag] Password Discussion 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, 16 Jul 2012 19:09:55 -0000 Hi Yaron,=20 On Jul 16, 2012, at 9:47 PM, Yaron Sheffer wrote: > Hi Hannes, >=20 > I may be missing something big, but I'm puzzled by your postscript = below. >=20 > First, if you want the actual connection to the server (or to any kind = of trust anchor, IdP and the like) to be secure, you need the entire = protocol implementation to be trusted. Untrusted JavaScript on top of a = trusted crypto layer won't cut it. You do what everyone does: you use TLS with server-side authentication = (assuming you have solved the PKI issues) The CryptoAPI addresses the client-side authentication.=20 >=20 > As a result, I see very little value in a standard crypto API for = JavaScript, compared to "industry-standard" libraries like JQuery. A = standard crypto API certainly won't hurt, but I'd be surprised if it has = a significant effect on Web security as a whole. Could you expand on your concern regarding JavaScript (given that we = seem to be doing everything else in JavaScript as well these days, = including our favorite protocols)?=20 >=20 > On the other hand a widely deployed HTTP authentication mechanism, if = it's good enough (for whatever value of "good enough") could make a real = difference. *widely deployed* is exactly the problem.=20 Why would someone widely deploy something now when there are better ways = waiting just around the corner.=20 Ciao Hannes >=20 > Thanks, > Yaron >=20 > On 07/16/2012 09:15 PM, Hannes Tschofenig wrote: >> Hi all, >>=20 >> given the longer discussion related to passwords I thought it makes = sense to point you to a document we had written about various problems = related to Web security: >> http://tools.ietf.org/html/draft-tschofenig-secure-the-web-03 >>=20 >> Ciao >> Hannes >>=20 >> PS: I case you want to hear my view on standardizing a new = authentication mechanism (whatever it might be) or even an entire = authentication framework then I have to say that we have to take the = recent developments in the W3C into consideration and the work on the = JavaScript CryptoAPI looks very promising to me. With it an identity = provider can write their favorite authentication protocol and send it to = the browser. No need for standardizing a new authentication protocol = anymore nor a framework either. JavaScript is the framework.... >>=20 >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >>=20 >=20 From paul.hoffman@vpnc.org Mon Jul 16 12:12:52 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 54DC321F876F for ; Mon, 16 Jul 2012 12:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLH8BXfliVmA for ; Mon, 16 Jul 2012 12:12:52 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B8EF821F876D for ; Mon, 16 Jul 2012 12:12:51 -0700 (PDT) Received: from [10.20.30.102] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q6GIRWJ0051011 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Jul 2012 11:27:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <8CA8896B-D506-4581-8A2E-E223D6EA7584@gmx.net> Date: Mon, 16 Jul 2012 12:13:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2BDFDE8E-39F1-4686-B44F-C3426ACEA13F@vpnc.org> References: <500461C5.7020006@gmail.com> <8CA8896B-D506-4581-8A2E-E223D6EA7584@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1278) Cc: saag@ietf.org Subject: Re: [saag] Password Discussion 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, 16 Jul 2012 19:12:52 -0000 On Jul 16, 2012, at 12:07 PM, Hannes Tschofenig wrote: > Why would someone widely deploy something now when there are better = ways waiting just around the corner.=20 Security? Interoperability? Scalability? Just a few thoughts. --Paul Hoffman= From mouse@Sparkle.Rodents-Montreal.ORG Mon Jul 16 12:23: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 C828121F88C0 for ; Mon, 16 Jul 2012 12:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.715 X-Spam-Level: X-Spam-Status: No, score=-7.715 tagged_above=-999 required=5 tests=[AWL=-0.327, BAYES_50=0.001, HELO_MISMATCH_ORG=0.611, 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 aNt63c+sSEFf for ; Mon, 16 Jul 2012 12:23:51 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id 95A7821F878B for ; Mon, 16 Jul 2012 12:23:49 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id PAA05324; Mon, 16 Jul 2012 15:24:34 -0400 (EDT) Date: Mon, 16 Jul 2012 15:24:34 -0400 (EDT) From: Mouse Message-Id: <201207161924.PAA05324@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: Mon, 16 Jul 2012 15:17:05 -0400 (EDT) To: saag@ietf.org In-Reply-To: References: Subject: Re: [saag] Password Discussion 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, 16 Jul 2012 19:23:52 -0000 > PS: I case you want to hear my view on standardizing a new authentication me$ What about people who care enough about security to be unwilling to run code presented by other machines (like JavaScript)? I know *I* certainly am not going to be participating in anything that requires me to run JavaScript code - or code in pretty much any other language - offered to me by arbitrary sites. Are such users simply outside the target you're designing for, or is this a way to "persuade" them to shut up and drink the nice koolaid, or what? I doubt I'm alone in finding suspicion that it's the latter is one of my first reactions, however unjustified. Even if that's not what _you_ mean by it, I suspect it's something it will rapidly get abused for. /~\ 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 yaronf.ietf@gmail.com Mon Jul 16 12:29: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 E9B2921F8927 for ; Mon, 16 Jul 2012 12:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 531Qw+3msiKA for ; Mon, 16 Jul 2012 12:29:49 -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 681EA21F8932 for ; Mon, 16 Jul 2012 12:29:47 -0700 (PDT) Received: by bkty7 with SMTP id y7so4602610bkt.31 for ; Mon, 16 Jul 2012 12:30:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=fTAbmknzvTzrRMK1yNU+Nz7X0S9jqtGsu3wCPIzFE1k=; b=MfqKVPdvQ8mCve4//3+jsbIiHqZqqJvHauqRdxPMIDrDHdilRG9krPrxshhOldMAG+ UaGDZ0OEVdtCB0fL9i0tX2opVNZgI7WWpD71fOLD/Gx3WF6UXnlHpDyL/aWAO7786ra9 dr7AWUF40Au617oLn47euW0+zOJMtsVURFHpZXkiCs5kBBIe6SffiO5OVfUIjqh80qoQ sX62zKcD+oRY8PxBQ/QH1YEeQfGfrlO/9T/niGW/2yGsuEUeujd2aV65/pRSq2uM87cV NSXlD7rwC6KnNH+ATgU6l58uu91TqwB/aDtDPuBZ3HNfHiuINtJ6tSS4CFJmR7SEGWiY UEng== Received: by 10.204.152.152 with SMTP id g24mr5307514bkw.104.1342467031557; Mon, 16 Jul 2012 12:30:31 -0700 (PDT) Received: from [10.0.0.3] (bzq-79-182-163-254.red.bezeqint.net. [79.182.163.254]) by mx.google.com with ESMTPS id 25sm8755609bkx.9.2012.07.16.12.30.30 (version=SSLv3 cipher=OTHER); Mon, 16 Jul 2012 12:30:31 -0700 (PDT) Message-ID: <50046BD5.30404@gmail.com> Date: Mon, 16 Jul 2012 22:30:29 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Hannes Tschofenig References: <500461C5.7020006@gmail.com> <8CA8896B-D506-4581-8A2E-E223D6EA7584@gmx.net> In-Reply-To: <8CA8896B-D506-4581-8A2E-E223D6EA7584@gmx.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: saag@ietf.org Subject: Re: [saag] Password Discussion 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, 16 Jul 2012 19:29:51 -0000 Hi Hannes, On 07/16/2012 10:07 PM, Hannes Tschofenig wrote: > Hi Yaron, > > On Jul 16, 2012, at 9:47 PM, Yaron Sheffer wrote: > >> Hi Hannes, >> >> I may be missing something big, but I'm puzzled by your postscript below. >> >> First, if you want the actual connection to the server (or to any kind of trust anchor, IdP and the like) to be secure, you need the entire protocol implementation to be trusted. Untrusted JavaScript on top of a trusted crypto layer won't cut it. > > You do what everyone does: you use TLS with server-side authentication (assuming you have solved the PKI issues) > The CryptoAPI addresses the client-side authentication. > Well, I'm not assuming we have solved the PKI issues. In fact I'm not sure we can ever solve them. >> >> As a result, I see very little value in a standard crypto API for JavaScript, compared to "industry-standard" libraries like JQuery. A standard crypto API certainly won't hurt, but I'd be surprised if it has a significant effect on Web security as a whole. > > Could you expand on your concern regarding JavaScript (given that we seem to be doing everything else in JavaScript as well these days, including our favorite protocols)? > That ties into the previous paragraph, i.e. you cannot trust the downloaded code because you cannot trust the server-side authentication. In addition, the JavaScript sandbox model has had its problems. The latest incident is Microsoft's recommendation to avoid using their Gadget architecture. >> >> On the other hand a widely deployed HTTP authentication mechanism, if it's good enough (for whatever value of "good enough") could make a real difference. > > *widely deployed* is exactly the problem. > > Why would someone widely deploy something now when there are better ways waiting just around the corner. Actually, if we put the security concerns aside, and just look at market deployment, JQuery has been a major success because it can be downloaded with the application, and the application does not need to rely on browser features to use it. The W3C effort is taking the opposite approach, and so it will likely be a long time before it is adopted. > > Ciao > Hannes > >> >> Thanks, >> Yaron >> >> On 07/16/2012 09:15 PM, Hannes Tschofenig wrote: >>> Hi all, >>> >>> given the longer discussion related to passwords I thought it makes sense to point you to a document we had written about various problems related to Web security: >>> http://tools.ietf.org/html/draft-tschofenig-secure-the-web-03 >>> >>> Ciao >>> Hannes >>> >>> PS: I case you want to hear my view on standardizing a new authentication mechanism (whatever it might be) or even an entire authentication framework then I have to say that we have to take the recent developments in the W3C into consideration and the work on the JavaScript CryptoAPI looks very promising to me. With it an identity provider can write their favorite authentication protocol and send it to the browser. No need for standardizing a new authentication protocol anymore nor a framework either. JavaScript is the framework.... >>> >>> _______________________________________________ >>> saag mailing list >>> saag@ietf.org >>> https://www.ietf.org/mailman/listinfo/saag >>> >> > From hannes.tschofenig@gmx.net Mon Jul 16 12:33: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 B858521F893F for ; Mon, 16 Jul 2012 12:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.625 X-Spam-Level: X-Spam-Status: No, score=-102.625 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klPlBdr6xN4h for ; Mon, 16 Jul 2012 12:33:31 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 9A7B721F8940 for ; Mon, 16 Jul 2012 12:33:30 -0700 (PDT) Received: (qmail invoked by alias); 16 Jul 2012 19:31:19 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.102]) [88.115.216.191] by mail.gmx.net (mp036) with SMTP; 16 Jul 2012 21:31:19 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/kWGRz0qzkuNbP+a6iVTM48+Dq/5gN42fVeiJXMF yftOYoysTV0Bok Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <2BDFDE8E-39F1-4686-B44F-C3426ACEA13F@vpnc.org> Date: Mon, 16 Jul 2012 22:31:17 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <500461C5.7020006@gmail.com> <8CA8896B-D506-4581-8A2E-E223D6EA7584@gmx.net> <2BDFDE8E-39F1-4686-B44F-C3426ACEA13F@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: saag@ietf.org Subject: Re: [saag] Password Discussion 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, 16 Jul 2012 19:33:31 -0000 Hi Paul,=20 who says that the JavaScript CryptoAPI isn't secure? Why are building = the rest of the Web and smart phone applications on JavaScript then why = not also the security stuff.=20 Interoperability: the interoperability comes through the JavaScript API = but you don't have to standardize all the different authentication = protocols. Just a different form of interoperability.=20 I wonder what scalability you are concerned with? Ciao Hannes On Jul 16, 2012, at 10:13 PM, Paul Hoffman wrote: > On Jul 16, 2012, at 12:07 PM, Hannes Tschofenig wrote: >=20 >> Why would someone widely deploy something now when there are better = ways waiting just around the corner.=20 >=20 > Security? Interoperability? Scalability? Just a few thoughts. >=20 > --Paul Hoffman From ekr@rtfm.com Mon Jul 16 12:49: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 AEA8311E812B for ; Mon, 16 Jul 2012 12:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.822 X-Spam-Level: X-Spam-Status: No, score=-102.822 tagged_above=-999 required=5 tests=[AWL=0.155, 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 UibMBqpXOrdM for ; Mon, 16 Jul 2012 12:49:20 -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 0340911E80A1 for ; Mon, 16 Jul 2012 12:49:19 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4142039vbb.31 for ; Mon, 16 Jul 2012 12:50: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:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=D7/7IeMXetJIhBhWYDq6Zadi36R8/A48Mcm/ad368Q4=; b=Gz9AFj15HhNefVrc0x/xRK8+rXr5pYBP6Ie4RcE6pLE/KNZ71hdAqN06yUcatMLKUC ll9H7DJxBmsFyRlUQ2bRlNwl3AkUfpdSb7k84mAKdoF8eRKEmClYhLonjUiJ55C42k/4 J3HM/H6AqiM+Ec/313fvZTn2UpYfFGz5wQf6h5f1YrEXZNDBMi0R2vD3pTXtRPH2PIAY 5h+tnpFdVTdtnhKrL6pdRywrKGLYIdUclV8HGu5VkaMy94AnGtywk53wlBN64hUk4AWQ o8eMMa94hwd99UA9YXYOaxzeFcOQ9S4cgXo/J9/CtYO6obebqPC4FgWmCyQZg3jeDSg4 zCjw== Received: by 10.52.30.2 with SMTP id o2mr5057701vdh.132.1342468205031; Mon, 16 Jul 2012 12:50:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Mon, 16 Jul 2012 12:49:24 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <201207161924.PAA05324@Sparkle.Rodents-Montreal.ORG> References: <201207161924.PAA05324@Sparkle.Rodents-Montreal.ORG> From: Eric Rescorla Date: Mon, 16 Jul 2012 12:49:24 -0700 Message-ID: To: Mouse Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnTDu/yz9SjogpS8jFlSRIQPbqIsAgVAt+NHy3v4bO8pC5t/vsYTkTo4gA8p4XVnn6rfzFQ Cc: saag@ietf.org Subject: Re: [saag] Password Discussion 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, 16 Jul 2012 19:49:20 -0000 On Mon, Jul 16, 2012 at 12:24 PM, Mouse wrote: >> PS: I case you want to hear my view on standardizing a new authentication me$ > > What about people who care enough about security to be unwilling to run > code presented by other machines (like JavaScript)? I know *I* > certainly am not going to be participating in anything that requires me > to run JavaScript code - or code in pretty much any other language - > offered to me by arbitrary sites. So you basically don't use the Web or view PDF files? -Ekr From mouse@Sparkle.Rodents-Montreal.ORG Mon Jul 16 12:51:02 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 CA62921F875D for ; Mon, 16 Jul 2012 12:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.989 X-Spam-Level: X-Spam-Status: No, score=-8.989 tagged_above=-999 required=5 tests=[AWL=0.999, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, 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 Dq0sdoecApGw for ; Mon, 16 Jul 2012 12:51:02 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id 8E74221F8731 for ; Mon, 16 Jul 2012 12:51:01 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id PAA05561; Mon, 16 Jul 2012 15:51:45 -0400 (EDT) Date: Mon, 16 Jul 2012 15:51:45 -0400 (EDT) From: Mouse Message-Id: <201207161951.PAA05561@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: Mon, 16 Jul 2012 15:48:27 -0400 (EDT) To: saag@ietf.org In-Reply-To: <50046BD5.30404@gmail.com> References: <500461C5.7020006@gmail.com> <8CA8896B-D506-4581-8A2E-E223D6EA7584@gmx.net> <50046BD5.30404@gmail.com> Subject: Re: [saag] Password Discussion 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, 16 Jul 2012 19:51:03 -0000 > That ties into the previous paragraph, i.e. you cannot trust the > downloaded code because you cannot trust the server-side > authentication. Well, but you also cannot trust the downloaded code even if you _do_ trust the server-side authentication, in many cases. Even the best of organizations get cracked eventually, and, even if they haven't been cracked, their priorities generally do not match well with mine, so the tradeoffs that it is in their interest for me to make are usually not the ones it is in my interest to make. And then there are inside threats and various other, more arcane, threats. /~\ 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 mouse@Sparkle.Rodents-Montreal.ORG Mon Jul 16 12:54: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 2524711E815B for ; Mon, 16 Jul 2012 12:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.061 X-Spam-Level: X-Spam-Status: No, score=-9.061 tagged_above=-999 required=5 tests=[AWL=0.927, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, 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 5hYez2UOLru2 for ; Mon, 16 Jul 2012 12:54:15 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id 364F611E80A1 for ; Mon, 16 Jul 2012 12:54:15 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id PAA05590; Mon, 16 Jul 2012 15:54:59 -0400 (EDT) Date: Mon, 16 Jul 2012 15:54:59 -0400 (EDT) From: Mouse Message-Id: <201207161954.PAA05590@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: Mon, 16 Jul 2012 15:51:50 -0400 (EDT) To: saag@ietf.org In-Reply-To: References: <500461C5.7020006@gmail.com> <8CA8896B-D506-4581-8A2E-E223D6EA7584@gmx.net> <2BDFDE8E-39F1-4686-B44F-C3426ACEA13F@vpnc.org> Subject: Re: [saag] Password Discussion 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, 16 Jul 2012 19:54:16 -0000 > who says that the JavaScript CryptoAPI isn't secure? Umm...anyone who's looked at the security history of JavaScript, or for that matter of most other attempts to build client-side sandboxes? Also, "secure against what?". It may well be - I'd even go so far as to say "probably is" - secure against some relevant threats but not others. /~\ 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 stephen.farrell@cs.tcd.ie Mon Jul 16 13:17: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 0A4A111E816D for ; Mon, 16 Jul 2012 13:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ersagQvR0I4 for ; Mon, 16 Jul 2012 13:16:56 -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 B352B11E80A1 for ; Mon, 16 Jul 2012 13:16:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 3C3171714F2; Mon, 16 Jul 2012 21:17:41 +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=1342469860; bh=taeNJ2zIpe1ppK wm6WttNnknNZMpqdhYZcjOUl3K+XM=; b=lLNg3zxj+DtI6lcj8IItMjpMRW7BV5 yvStcGMYkB213hn3mqg2KzSQqdkkP9rIwIiiHI31LU5zpGAkcek7Lpp2NSc9YZ4p 1nWAZtw2GpSIyL8FomkmoI1fDKDd9qguRzKM0immT8ze6ffrTX9+vghFXFMqVt0u UG0b+2FIKVySaZAWSv+4EyQg0LDG6IeLsvTxNO0YGPNMDaLjIBGLQFwF/YROD79v RjkU4v8Mfbig50FGXGHhbGjfn3qEAiTiwiK/kqq9O3HVnQxScRGsnldygFPN+VKZ l4qmPwPDCFGQtTsRTvMv2YRSaXwi4ieyLrIlRaf4qjiQLoJxeKYxcZHQ== 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 bzWFi7F1FR0v; Mon, 16 Jul 2012 21:17:40 +0100 (IST) Received: from [10.87.48.11] (unknown [86.44.68.113]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6A7BF1714F1; Mon, 16 Jul 2012 21:17:39 +0100 (IST) Message-ID: <500476E3.3050702@cs.tcd.ie> Date: Mon, 16 Jul 2012 21:17:39 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Mouse References: <500461C5.7020006@gmail.com> <8CA8896B-D506-4581-8A2E-E223D6EA7584@gmx.net> <2BDFDE8E-39F1-4686-B44F-C3426ACEA13F@vpnc.org> <201207161954.PAA05590@Sparkle.Rodents-Montreal.ORG> In-Reply-To: <201207161954.PAA05590@Sparkle.Rodents-Montreal.ORG> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: saag@ietf.org Subject: Re: [saag] Password Discussion 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, 16 Jul 2012 20:17:06 -0000 So I don't think we need go debate all the detail of the security level of JS to be honest. (I'm not trying to stop you, but maybe change the subject line.) >From my p-o-v, JS developers exist and will do stuff. If left alone that'd probably be the usual md5("password"), and they'd call that a signature and think they're done. I reckon we ought standardise a working & usable non-password based scheme (if we can) and then people can use that in whatever programming environment they want, with whatever security properties they get. Right now, there's a chance to get that done and adopted in httpbis, which could (all going well) result in enough deployment so the JS guys would copy that. I think that's a good enough win in IETF terms to be worth it. Natural selection can take care of the rest. S. On 07/16/2012 08:54 PM, Mouse wrote: >> who says that the JavaScript CryptoAPI isn't secure? > > Umm...anyone who's looked at the security history of JavaScript, or for > that matter of most other attempts to build client-side sandboxes? > > Also, "secure against what?". It may well be - I'd even go so far as > to say "probably is" - secure against some relevant threats but not > others. > > /~\ 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 > > From marsh@extendedsubset.com Mon Jul 16 13:19: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 09E7321F8609 for ; Mon, 16 Jul 2012 13:19:16 -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 zjLXBXi2JRYL for ; Mon, 16 Jul 2012 13:19:15 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id 19F9A21F8608 for ; Mon, 16 Jul 2012 13:19:15 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1Sqrlw-0004Iw-9o; Mon, 16 Jul 2012 20:20:00 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id F0B3267AA; Mon, 16 Jul 2012 20:19:58 +0000 (UTC) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18M1/S1PGhtEBfAPOCl+b0sHHxDvyv/a0k= Message-ID: <50047769.7040601@extendedsubset.com> Date: Mon, 16 Jul 2012 15:19:53 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Eric Rescorla References: <201207161924.PAA05324@Sparkle.Rodents-Montreal.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] Password Discussion 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, 16 Jul 2012 20:19:16 -0000 On 07/16/2012 02:49 PM, Eric Rescorla wrote: > On Mon, Jul 16, 2012 at 12:24 PM, Mouse wrote: >>> PS: I case you want to hear my view on standardizing a new authentication me$ >> >> What about people who care enough about security to be unwilling to run >> code presented by other machines (like JavaScript)? I know *I* >> certainly am not going to be participating in anything that requires me >> to run JavaScript code - or code in pretty much any other language - >> offered to me by arbitrary sites. > > So you basically don't use the Web or view PDF files? I browse the web with the Firefox NoScript plugin. From within a virtual machine. For critical things that require web, like online banking, I do them from a dedicated system that's not used for anything else. For systems that need to be maximally-secure (for me personally, that's mostly stuff like the family fileserver at home that I don't want to spend a whole Saturday rebuilding) I avoid using web-based systems for them whenever possible. I have not run Adobe's PDF reader for many years. When I did, I would always turn off the Javascript functionality. These days I use a VM to run one of the 3rd party PDF viewers which does not support Javascript. In my view, this intentional blurring of the distinction between documents and applications, i.e., "executable content", is possibly the biggest single mistake ever made in the field of data security. At the time, vendors rationalized it by claiming it was useful, sandboxed, and users couldn't remember the 10 different extensions that Windows treats as executable anyway. History has shown that justification to be wrong, but for even worse reasons. Secure application development is so much harder than anyone expected and coding practices were so haphazard that even malicious document data typically ends up gaining arbitrary code execution capabilities. So, in summary, I don't like Javascript because I believe excessive Turing-completeness will attract the wrath of the Gods. Admittedly that's not a very well-defined argument, but it tends to be right some of the time. Perhaps a better argument is that it has simply proven to be an indefensibly large attack surface in practice. - Marsh From mouse@Sparkle.Rodents-Montreal.ORG Mon Jul 16 13:54: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 F049011E8091 for ; Mon, 16 Jul 2012 13:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.123 X-Spam-Level: X-Spam-Status: No, score=-9.123 tagged_above=-999 required=5 tests=[AWL=0.865, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, 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 34tl49mbCqLY for ; Mon, 16 Jul 2012 13:54:37 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9D011E8089 for ; Mon, 16 Jul 2012 13:54:30 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id QAA06113; Mon, 16 Jul 2012 16:55:14 -0400 (EDT) Date: Mon, 16 Jul 2012 16:55:14 -0400 (EDT) From: Mouse Message-Id: <201207162055.QAA06113@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: Mon, 16 Jul 2012 16:30:35 -0400 (EDT) To: saag@ietf.org In-Reply-To: <50047769.7040601@extendedsubset.com> References: <201207161924.PAA05324@Sparkle.Rodents-Montreal.ORG> <50047769.7040601@extendedsubset.com> Subject: Re: [saag] Password Discussion 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, 16 Jul 2012 20:54:38 -0000 >>> I know *I* certainly am not going to be participating in anything >>> that requires me to run JavaScript code - or code in pretty much >>> any other language - offered to me by arbitrary sites. >> So you basically don't use the Web or view PDF files? Huh? Neither of those requires running JS. Some parts of the Web do; I simply don't use those parts. PDF files, as far as I can tell, do not; certainly most of the PDF files I've run into work fine in GhostScript (which does not have a JS engine in it as far as I've been able to tell, at least not in the version I run) or xpdf's pdftotext (which also doesn't have a JS engine as far as I can tell). > For critical things that require web, like online banking, Well, there you are. I don't consider online banking critical. In fact, I won't go near it. The prices are far too high for me, both the "must pay" prices and the "chance of paying" expected (in the statistical sense) prices. > I have not run Adobe's PDF reader for many years. I've never run it, at least not on my own machines. I don't run software I didn't build from source myself. > In my view, this intentional blurring of the distinction between > documents and applications, i.e., "executable content", is possibly > the biggest single mistake ever made in the field of data security. Quite possibly. I'm not sure I agree, but I definitely don't disagree. > Perhaps a better argument is that it has simply proven to be an > indefensibly large attack surface in practice. Yeah. Like various other things in various fields, in theory it might be fine, but practice has shown it to be a problem. /~\ 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 paul.hoffman@vpnc.org Mon Jul 16 13:57: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 C66BC11E80E9 for ; Mon, 16 Jul 2012 13:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4B1EHPV6QugP for ; Mon, 16 Jul 2012 13:57:58 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2F48A11E80CD for ; Mon, 16 Jul 2012 13:57:58 -0700 (PDT) Received: from [10.20.30.102] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q6GKCelc072503 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Jul 2012 13:12:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Mon, 16 Jul 2012 13:58:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3B2B0446-2B9D-46BE-A911-D6718813C5F2@vpnc.org> References: <500461C5.7020006@gmail.com> <8CA8896B-D506-4581-8A2E-E223D6EA7584@gmx.net> <2BDFDE8E-39F1-4686-B44F-C3426ACEA13F@vpnc.org> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1278) Cc: saag@ietf.org Subject: Re: [saag] Password Discussion 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, 16 Jul 2012 20:57:58 -0000 On Jul 16, 2012, at 12:31 PM, Hannes Tschofenig wrote: > who says that the JavaScript CryptoAPI isn't secure? Many people. It depends on your definition of "secure", of course. > Why are building the rest of the Web and smart phone applications on = JavaScript then why not also the security stuff.=20 Because they have different properties? > Interoperability: the interoperability comes through the JavaScript = API but you don't have to standardize all the different authentication = protocols. Just a different form of interoperability.=20 By "different form", you mean "less", yes? That's fine, but it has not = worked out so well in the past. > I wonder what scalability you are concerned with? Killing off authenticating HTTP proxies reduces scalability. Forcing all = browsers to use a specific, current pile of JavaScript before a user can = authenticate reduces scalability. --Paul Hoffman= From ekr@rtfm.com Mon Jul 16 14:03: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 67E8711E809B for ; Mon, 16 Jul 2012 14:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.827 X-Spam-Level: X-Spam-Status: No, score=-102.827 tagged_above=-999 required=5 tests=[AWL=0.150, 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 zFzKyv8dkHgO for ; Mon, 16 Jul 2012 14:03:59 -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 CE54911E808A for ; Mon, 16 Jul 2012 14:03:58 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so2397580vcb.31 for ; Mon, 16 Jul 2012 14:04:44 -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:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=ZEfWlCOp+V5bmWPpb+muZ4WdQf8ylOY46J3R/CMHRTk=; b=bw7XaAZEg1kDkeospcj59KK3Jvbi9SEGNazb3GOpO6KNuodbxeGtG0+YYWfr3jO7Xm qZQxgjPca84V1i0DvmHlNKIMJaGdbp7OrTEz66nbCgO2jNC5ahi4XT9aeC/gEYx8hco2 ceUbq9nx6ouAnfqcQXU1GD0fat2zLd28uvDutW7J8eCIY//ogHOHBGV2FeEj2RozLFlj 0+scI/lTE686niiX5tavzd1zoKKwKyQtYawcbFE0YPUimRqEMgefSmd91MgGthim5Ub9 UclB/VRqHmNX4ijTvQM4P1nGTZz47KYji6ac6xMP7E1v+xKLFTgj/p2dIfEkQJSW/19R KYaw== Received: by 10.221.12.145 with SMTP id pi17mr5995890vcb.48.1342472683903; Mon, 16 Jul 2012 14:04:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Mon, 16 Jul 2012 14:04:03 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <3B2B0446-2B9D-46BE-A911-D6718813C5F2@vpnc.org> References: <500461C5.7020006@gmail.com> <8CA8896B-D506-4581-8A2E-E223D6EA7584@gmx.net> <2BDFDE8E-39F1-4686-B44F-C3426ACEA13F@vpnc.org> <3B2B0446-2B9D-46BE-A911-D6718813C5F2@vpnc.org> From: Eric Rescorla Date: Mon, 16 Jul 2012 14:04:03 -0700 Message-ID: To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmyeEabQwEhq/rdqkWE6djOpqDo6kaluo4BAM2uxgPzN3ANqyCuRF4c8AyhEw9t21IJJGma Cc: saag@ietf.org Subject: Re: [saag] Password Discussion 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, 16 Jul 2012 21:03:59 -0000 On Mon, Jul 16, 2012 at 1:58 PM, Paul Hoffman wrote: > On Jul 16, 2012, at 12:31 PM, Hannes Tschofenig wrote: > >> who says that the JavaScript CryptoAPI isn't secure? > > Many people. It depends on your definition of "secure", of course. Could you explain who those many people are, what definition of security they are using, and what not secure means? >> Why are building the rest of the Web and smart phone applications on JavaScript then why not also the security stuff. > > Because they have different properties? Really? >> Interoperability: the interoperability comes through the JavaScript API but you don't have to standardize all the different authentication protocols. Just a different form of interoperability. > > By "different form", you mean "less", yes? That's fine, but it has not worked out so well in the past. > >> I wonder what scalability you are concerned with? > > Killing off authenticating HTTP proxies reduces scalability. Forcing all browsers to use a specific, current pile of JavaScript before a user can authenticate reduces scalability. As the Web moves more and more towards HTTPS, authenticating proxies are going to go away naturally. As for a specific, current pile of JS, you should take a look at how many pages already require specific JS in the form of Google Analytics, JQuery, etc. -Ekr From paul.hoffman@vpnc.org Mon Jul 16 14:24: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 EB65011E819D for ; Mon, 16 Jul 2012 14:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKWsI9VWIu1m for ; Mon, 16 Jul 2012 14:24:50 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4043711E8271 for ; Mon, 16 Jul 2012 14:24:50 -0700 (PDT) Received: from [10.20.30.102] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q6GKdW4A077390 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Jul 2012 13:39:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Paul Hoffman In-Reply-To: Date: Mon, 16 Jul 2012 14:25:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <28354ED1-AB36-4350-892C-4AE146418D6C@vpnc.org> References: <500461C5.7020006@gmail.com> <8CA8896B-D506-4581-8A2E-E223D6EA7584@gmx.net> <2BDFDE8E-39F1-4686-B44F-C3426ACEA13F@vpnc.org> <3B2B0446-2B9D-46BE-A911-D6718813C5F2@vpnc.org> To: Eric Rescorla X-Mailer: Apple Mail (2.1278) Cc: saag@ietf.org Subject: Re: [saag] Password Discussion 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, 16 Jul 2012 21:24:51 -0000 On Jul 16, 2012, at 2:04 PM, Eric Rescorla wrote: > On Mon, Jul 16, 2012 at 1:58 PM, Paul Hoffman = wrote: >> On Jul 16, 2012, at 12:31 PM, Hannes Tschofenig wrote: >>=20 >>> who says that the JavaScript CryptoAPI isn't secure? >>=20 >> Many people. It depends on your definition of "secure", of course. >=20 > Could you explain who those many people are, > what definition of security they are using, and what not secure means? There have already been responders on this list. My definition for = security for client authentication means that the server has high = assurance that the system they are using to authenticate the client is = reliable; we have seen that different versions of JavaScript, and = different versions of JavaScript API modules, have different levels of = reliability. >>> Why are building the rest of the Web and smart phone applications on = JavaScript then why not also the security stuff. >>=20 >> Because they have different properties? >=20 > Really? Yes. For example, the properties needed for "I will give you access to = these records based on your identity for these records" are different = than "I will let you do this audio interaction with this other person". = We would all love the properties to all be based on the highest = standards of reliability for JavaScript implementations and API = implementations; history has proven otherwise. This isn't to say that = JavaScript sucks for everything, or even for some uses in client = authentication, just that Hannes' argument that we don't need to develop = new HTTP client auth mechanisms because they can be done in JavaScript = APIs in the future assumes a set of properties that not everyone agrees = with. >>> Interoperability: the interoperability comes through the JavaScript = API but you don't have to standardize all the different authentication = protocols. Just a different form of interoperability. >>=20 >> By "different form", you mean "less", yes? That's fine, but it has = not worked out so well in the past. >>=20 >>> I wonder what scalability you are concerned with? >>=20 >> Killing off authenticating HTTP proxies reduces scalability. Forcing = all browsers to use a specific, current pile of JavaScript before a user = can authenticate reduces scalability. >=20 > As the Web moves more and more towards HTTPS, authenticating proxies > are going to go away naturally. Fully agree. But as the deployed Web goes away from HTTPS due to = questionable firewall policies (including proxy-in-the-middle attacks), = those proxies will remain with us. More important, as the Web goes more toward HTTPS, we might be able to = greatly reduce the need for HTTP authentication. But that's not what = Hannes is arguing for. > As for a specific, current pile of JS, you should take a look at how > many pages already require specific > JS in the form of Google Analytics, JQuery, etc. I have done so. That pile is impressive. Adding to that pile does not = necessarily give the security properties that people want for = authenticating HTTP clients. --Paul Hoffman From marsh@extendedsubset.com Mon Jul 16 14:27: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 E41DF11E814E for ; Mon, 16 Jul 2012 14:27:58 -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 WHDuEAeePtWF for ; Mon, 16 Jul 2012 14:27:58 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA6B11E826D for ; Mon, 16 Jul 2012 14:27:58 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SqsqR-0008PV-N4 for saag@ietf.org; Mon, 16 Jul 2012 21:28:43 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id C8DA1693F for ; Mon, 16 Jul 2012 21:28:42 +0000 (UTC) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19vBu/1A65WMoK1LXxWhGTqiHrKtwO5+8I= Message-ID: <50048787.9000905@extendedsubset.com> Date: Mon, 16 Jul 2012 16:28:39 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: saag@ietf.org References: <500461C5.7020006@gmail.com> <8CA8896B-D506-4581-8A2E-E223D6EA7584@gmx.net> <2BDFDE8E-39F1-4686-B44F-C3426ACEA13F@vpnc.org> <3B2B0446-2B9D-46BE-A911-D6718813C5F2@vpnc.org> In-Reply-To: <3B2B0446-2B9D-46BE-A911-D6718813C5F2@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [saag] Password Discussion 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, 16 Jul 2012 21:27:59 -0000 On 07/16/2012 03:58 PM, Paul Hoffman wrote: > On Jul 16, 2012, at 12:31 PM, Hannes Tschofenig wrote: > >> Interoperability: the interoperability comes through the JavaScript >> API but you don't have to standardize all the different >> authentication protocols. Just a different form of >> interoperability. > > By "different form", you mean "less", yes? That's fine, but it has > not worked out so well in the past. With the entry of Google and Apple into the browser game, the security of browser implementation code has gotten much much better. So let's just grant for the sake of discussion that the mainstream browsers provide perfectly secure Javascript implementations on which to build new authentication and encryption mechanisms. But what does it take to get there? All the current Javascript implementations took years and years of bug-after-security-bug slogging by huge engineering teams to get to the point where they are now. Right now there are many open source Javascript implementations that could be used as a starting point for someone wishing to implement a protocol endpoint. Wikipedia lists over a dozen. But probably only two or three are battle-hardened to the point that we should consider using them for building systems with real security requirements, and these are the same ones that are in the browsers! So, yes, ECMAScript is an open international standard and open source implementations are available. But when the security requirements are real, it is impractical for any but the very largest organizations to develop a new implementation. In practice it appears that the specification is co-defined along with the implementations. It seems to me very un-IETF-like to define a protocol with such onerous dependencies that a clean, secure reimplementation from spec is all but impossible. - Marsh From marsh@extendedsubset.com Mon Jul 16 14:38: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 2E77321F8672 for ; Mon, 16 Jul 2012 14:38:31 -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 eSaJXE8vZh9f for ; Mon, 16 Jul 2012 14:38:30 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id C8A7821F8608 for ; Mon, 16 Jul 2012 14:38:21 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1Sqt0V-0007M3-9w; Mon, 16 Jul 2012 21:39:07 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id D2F546940; Mon, 16 Jul 2012 21:39:01 +0000 (UTC) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/WRCTFzrV70CprrJr0taiVu7dWAwkekIw= Message-ID: <500489F2.4040401@extendedsubset.com> Date: Mon, 16 Jul 2012 16:38:58 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Eric Rescorla References: <500461C5.7020006@gmail.com> <8CA8896B-D506-4581-8A2E-E223D6EA7584@gmx.net> <2BDFDE8E-39F1-4686-B44F-C3426ACEA13F@vpnc.org> <3B2B0446-2B9D-46BE-A911-D6718813C5F2@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , saag@ietf.org Subject: Re: [saag] Password Discussion 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, 16 Jul 2012 21:38:31 -0000 On 07/16/2012 04:04 PM, Eric Rescorla wrote: > On Mon, Jul 16, 2012 at 1:58 PM, Paul Hoffman wrote: >> On Jul 16, 2012, at 12:31 PM, Hannes Tschofenig wrote: >> >>> who says that the JavaScript CryptoAPI isn't secure? >> >> Many people. It depends on your definition of "secure", of course. > > Could you explain who those many people are, > what definition of security they are using, and what not secure means? I agree that "not secure" isn't exactly a scientific claim without all the critical context being well defined. However, in crypto, the burden of proof is on the person claiming the system *is* secure. So when critics say something is "not secure" it should at least perk our ears up and listen to what they have to say. But complexity breeds security bugs. So even beyond that, any significant new complexity needs to have a really good justification for existing. As-good is not enough, new complexity needs to be provably *more* secure than the status quo in order to be worth considering. Two of my favorite discussions about Javascript crypto: Thomas Ptacek, Matasano Security http://www.matasano.com/articles/javascript-cryptography/ Nate Lawson, Root Labs http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/ - Marsh From ekr@rtfm.com Mon Jul 16 14:59: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 4932611E826C for ; Mon, 16 Jul 2012 14:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.831 X-Spam-Level: X-Spam-Status: No, score=-102.831 tagged_above=-999 required=5 tests=[AWL=0.146, 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 31ZOW4+aoAwN for ; Mon, 16 Jul 2012 14:59:44 -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 EFCA511E82A1 for ; Mon, 16 Jul 2012 14:59:43 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4222053vbb.31 for ; Mon, 16 Jul 2012 15:00:29 -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:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=FKCKo+FipWv3RTDAx8CXlCjWziP9XXfDwPP/pZH8sFc=; b=oaZbd/5Knktz8Keoy6R3wv1u236ysVSloNaPOD/77/2NYbk1ZIi67E4paIJ1bO2GNh 8ONoy9dbTMMW/Pqzi3tC35AturWQO6kenNx3P54mAy9jPK5Szw9GhSn9qx/qs+1vncUw k9aTIioSSXVcIzpUcnoBf+Sjn8m3fqQnYBBtWPZoQj0H3YXIyTrRnmCuTX49v6fkoqKF 2NmoCnnHnvxJbUQHUBBoEnY9RR4PLKXse/YIobzmrbAfo0/AYu+UVqLlvOFhwJSn7F98 uJVXGgQlgO8DhfSEAXWmT48xfNuOVIwHF6kQTVgMCMl6KnuS4P0mlxvmvdHd84N892wd NfnQ== Received: by 10.52.99.227 with SMTP id et3mr5196324vdb.110.1342476029343; Mon, 16 Jul 2012 15:00:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Mon, 16 Jul 2012 14:59:49 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <500489F2.4040401@extendedsubset.com> References: <500461C5.7020006@gmail.com> <8CA8896B-D506-4581-8A2E-E223D6EA7584@gmx.net> <2BDFDE8E-39F1-4686-B44F-C3426ACEA13F@vpnc.org> <3B2B0446-2B9D-46BE-A911-D6718813C5F2@vpnc.org> <500489F2.4040401@extendedsubset.com> From: Eric Rescorla Date: Mon, 16 Jul 2012 14:59:49 -0700 Message-ID: To: Marsh Ray Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkJVmwuzeMY82HFWXGLqxtil1AbfL7pSwR0mcAIdQl2qVbiTHiFPl0hlGUTl9G+HhIsGCLz Cc: Paul Hoffman , saag@ietf.org Subject: Re: [saag] Password Discussion 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, 16 Jul 2012 21:59:45 -0000 On Mon, Jul 16, 2012 at 2:38 PM, Marsh Ray wrote: > On 07/16/2012 04:04 PM, Eric Rescorla wrote: >> >> On Mon, Jul 16, 2012 at 1:58 PM, Paul Hoffman >> wrote: >>> >>> On Jul 16, 2012, at 12:31 PM, Hannes Tschofenig wrote: >>> >>>> who says that the JavaScript CryptoAPI isn't secure? >>> >>> >>> Many people. It depends on your definition of "secure", of course. >> >> >> Could you explain who those many people are, >> what definition of security they are using, and what not secure means? > > > I agree that "not secure" isn't exactly a scientific claim without all the > critical context being well defined. However, in crypto, the burden of proof > is on the person claiming the system *is* secure. So when critics say > something is "not secure" it should at least perk our ears up and listen to > what they have to say. > > But complexity breeds security bugs. So even beyond that, any significant > new complexity needs to have a really good justification for existing. > As-good is not enough, new complexity needs to be provably *more* secure > than the status quo in order to be worth considering. > > Two of my favorite discussions about Javascript crypto: > > Thomas Ptacek, Matasano Security > http://www.matasano.com/articles/javascript-cryptography/ > > Nate Lawson, Root Labs > http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/ Both of these seem to be about cryptography that is implemented *in* JS. But the Webcrypto API is about cryptography implemented in the browser and exposed to JS. This isn't to say that the webcrypto API is or isn't secure (or will or won't be when it's done), but it's not clear to me that these particular arguments apply to a number of the relevant use cases. -Ekr From hannes.tschofenig@gmx.net Tue Jul 17 02:58:02 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 85BC821F86B6 for ; Tue, 17 Jul 2012 02:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0q3CPKtCDPHW for ; Tue, 17 Jul 2012 02:58:02 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 7F11321F86B5 for ; Tue, 17 Jul 2012 02:58:01 -0700 (PDT) Received: (qmail invoked by alias); 17 Jul 2012 09:57:09 -0000 Received: from unknown (EHLO [10.255.135.62]) [194.251.119.201] by mail.gmx.net (mp030) with SMTP; 17 Jul 2012 11:57:09 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+wZFh3GO+wZCeoSIoYwJjbL1X+Pv4H9u/PWfZvt3 GHzkQA1C+mFd5T Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <201207161951.PAA05561@Sparkle.Rodents-Montreal.ORG> Date: Tue, 17 Jul 2012 12:57:07 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <86A7D574-9939-4BBC-A095-7BC6C4B95C96@gmx.net> References: <500461C5.7020006@gmail.com> <8CA8896B-D506-4581-8A2E-E223D6EA7584@gmx.net> <50046BD5.30404@gmail.com> <201207161951.PAA05561@Sparkle.Rodents-Montreal.ORG> To: Mouse X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: saag@ietf.org Subject: Re: [saag] Password Discussion 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, 17 Jul 2012 09:58:02 -0000 The question of trust in downloadable code is orthogonal to the = JavaScript topic since we always use downloadable code even with native = applications.=20 In fact, not downloading the latest code (automatically) increases your = vulnerability to attacks.=20 On Jul 16, 2012, at 10:51 PM, Mouse wrote: >> That ties into the previous paragraph, i.e. you cannot trust the >> downloaded code because you cannot trust the server-side >> authentication. >=20 > Well, but you also cannot trust the downloaded code even if you _do_ > trust the server-side authentication, in many cases. Even the best of > organizations get cracked eventually, and, even if they haven't been > cracked, their priorities generally do not match well with mine, so = the > tradeoffs that it is in their interest for me to make are usually not > the ones it is in my interest to make. And then there are inside > threats and various other, more arcane, threats. >=20 > /~\ 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 From hannes.tschofenig@gmx.net Tue Jul 17 03:12: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 4CEFD21F86DA for ; Tue, 17 Jul 2012 03:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9VucdYsEnY3 for ; Tue, 17 Jul 2012 03:12:41 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 2E52C21F85C0 for ; Tue, 17 Jul 2012 03:12:41 -0700 (PDT) Received: (qmail invoked by alias); 17 Jul 2012 10:03:21 -0000 Received: from unknown (EHLO [10.255.135.62]) [194.251.119.201] by mail.gmx.net (mp035) with SMTP; 17 Jul 2012 12:03:21 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19nh/k5HCZnGzBwME5hGYZrY5ylJUglgA/spzrMMh lnXZ/LFPRZMOIm Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <50046BD5.30404@gmail.com> Date: Tue, 17 Jul 2012 13:03:09 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <500461C5.7020006@gmail.com> <8CA8896B-D506-4581-8A2E-E223D6EA7584@gmx.net> <50046BD5.30404@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: saag@ietf.org Subject: Re: [saag] Password Discussion 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, 17 Jul 2012 10:12:42 -0000 Hi Yaron,=20 On Jul 16, 2012, at 10:30 PM, Yaron Sheffer wrote: > Hi Hannes, >=20 > On 07/16/2012 10:07 PM, Hannes Tschofenig wrote: >> Hi Yaron, >>=20 >> On Jul 16, 2012, at 9:47 PM, Yaron Sheffer wrote: >>=20 >>> Hi Hannes, >>>=20 >>> I may be missing something big, but I'm puzzled by your postscript = below. >>>=20 >>> First, if you want the actual connection to the server (or to any = kind of trust anchor, IdP and the like) to be secure, you need the = entire protocol implementation to be trusted. Untrusted JavaScript on = top of a trusted crypto layer won't cut it. >>=20 >> You do what everyone does: you use TLS with server-side = authentication (assuming you have solved the PKI issues) >> The CryptoAPI addresses the client-side authentication. >>=20 >=20 > Well, I'm not assuming we have solved the PKI issues. In fact I'm not = sure we can ever solve them. I am assuming that the Web PKI issues will get addressed and I am = proposing to hold an IAB workshop on that topic. =20 >=20 >>>=20 >>> As a result, I see very little value in a standard crypto API for = JavaScript, compared to "industry-standard" libraries like JQuery. A = standard crypto API certainly won't hurt, but I'd be surprised if it has = a significant effect on Web security as a whole. >>=20 >> Could you expand on your concern regarding JavaScript (given that we = seem to be doing everything else in JavaScript as well these days, = including our favorite protocols)? >>=20 >=20 > That ties into the previous paragraph, i.e. you cannot trust the = downloaded code because you cannot trust the server-side authentication. The application community has bought into the concept of JavaScript and = as I explain in my other mail even native code is downloaded.=20 So, the question is not really whether you like that concept or not. = Take it as a fact that this is what the application community is doing = and therefore we have to figure out how to tackle some of the security = aspects.=20 As this is explained in the draft I distributed.=20 >=20 > In addition, the JavaScript sandbox model has had its problems. The = latest incident is Microsoft's recommendation to avoid using their = Gadget architecture. To my knowledge there is no relationship to JavaScript as such.=20 >=20 >>>=20 >>> On the other hand a widely deployed HTTP authentication mechanism, = if it's good enough (for whatever value of "good enough") could make a = real difference. >>=20 >> *widely deployed* is exactly the problem. >>=20 >> Why would someone widely deploy something now when there are better = ways waiting just around the corner. >=20 > Actually, if we put the security concerns aside, and just look at = market deployment, JQuery has been a major success because it can be = downloaded with the application, and the application does not need to = rely on browser features to use it. The W3C effort is taking the = opposite approach, and so it will likely be a long time before it is = adopted. I am not sure I am following your line of argument here.=20 JQuery is a JavaScript library. It is used by Web and smart phone = developers (as JQuery Mobile) to change the UI in a dynamic fashion. = JQuery is just a compilation of useful functions and no new API was = developed (like it was true with the HTML5 bundle that added all sorts = of new APIs).=20 Ciao Hannes >=20 >>=20 >> Ciao >> Hannes >>=20 >>>=20 >>> Thanks, >>> Yaron >>>=20 >>> On 07/16/2012 09:15 PM, Hannes Tschofenig wrote: >>>> Hi all, >>>>=20 >>>> given the longer discussion related to passwords I thought it makes = sense to point you to a document we had written about various problems = related to Web security: >>>> http://tools.ietf.org/html/draft-tschofenig-secure-the-web-03 >>>>=20 >>>> Ciao >>>> Hannes >>>>=20 >>>> PS: I case you want to hear my view on standardizing a new = authentication mechanism (whatever it might be) or even an entire = authentication framework then I have to say that we have to take the = recent developments in the W3C into consideration and the work on the = JavaScript CryptoAPI looks very promising to me. With it an identity = provider can write their favorite authentication protocol and send it to = the browser. No need for standardizing a new authentication protocol = anymore nor a framework either. JavaScript is the framework.... >>>>=20 >>>> _______________________________________________ >>>> saag mailing list >>>> saag@ietf.org >>>> https://www.ietf.org/mailman/listinfo/saag >>>>=20 >>>=20 >>=20 >=20 From hannes.tschofenig@gmx.net Tue Jul 17 03:19:19 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 7C7F621F86A0 for ; Tue, 17 Jul 2012 03:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2ifiePQfEv1 for ; Tue, 17 Jul 2012 03:19:18 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 56D5821F869D for ; Tue, 17 Jul 2012 03:19:18 -0700 (PDT) Received: (qmail invoked by alias); 17 Jul 2012 10:06:26 -0000 Received: from unknown (EHLO [10.255.135.62]) [194.251.119.201] by mail.gmx.net (mp070) with SMTP; 17 Jul 2012 12:06:26 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19Eitc+6YRE9pilXQ6PqxZPrqp3ZLPaBuGluy09NO I9DgTbNeALoknD Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Tue, 17 Jul 2012 13:06:23 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <500461C5.7020006@gmail.com> To: Paul Hoffman X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: IETF Security Area Advisory Group Subject: Re: [saag] Password Discussion 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, 17 Jul 2012 10:19:19 -0000 JavaScript has lead to an architectural change but that happened a while = ago.=20 We (some folks in the IAB) had tried to raise this issue in = http://tools.ietf.org/html/draft-tschofenig-post-standardization-02 and = with the Prague IETF plenary. The upcoming plenary will touch on the = topic of mobile code distribution again by looking at other ongoing = developments (outside the Web space).=20 The application community decided to use it and here we are.=20 The JavaScript CryptoAPI does not cause more or less problems for = proxies than regular JavaScript code does. So, I don't see the issue.=20 On Jul 16, 2012, at 10:08 PM, Paul Hoffman wrote: > In addition, an authentication "framework" that relies on Javascript = kinda bolloxes all proxies, yes? That seems like an architectural change = that might not be considered completely positive, to say the least. >=20 > --Paul Hoffman From hannes.tschofenig@gmx.net Tue Jul 17 03:49: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 889BB21F866E for ; Tue, 17 Jul 2012 03:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jx-15LuZ43rX for ; Tue, 17 Jul 2012 03:49:27 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id EB23621F8669 for ; Tue, 17 Jul 2012 03:49:26 -0700 (PDT) Received: (qmail invoked by alias); 17 Jul 2012 10:50:13 -0000 Received: from unknown (EHLO [10.255.135.62]) [194.251.119.201] by mail.gmx.net (mp010) with SMTP; 17 Jul 2012 12:50:13 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+L5EEeSPqLgOKVH6W0CE4YGOcSz1EBkPq3GBVzrn 1K74jrANdVfXAe From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Jul 2012 13:50:11 +0300 Message-Id: <6250FC21-C3F3-4197-BCBD-038D00E685CC@gmx.net> To: IETF Security Area Advisory Group Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [saag] JavaScript for authentication 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, 17 Jul 2012 10:49:28 -0000 Disclaimer: I am not actively participating in the W3C Web Cryptography = working group http://www.w3.org/2012/webcrypto/ for some reasons that = are outside the scope of this discussion and therefore I do not know = their latest development. Having said that I believe it would be wrong to ignore that these = activities are going on when we talk about securing authentication on = the Web (in particular when the browser community seems to be willing to = deploy these mechanisms and when the concepts are familiar to the = application developers). (Note: the Web technologies are also used by = smart phone apps -not just for use with Web pages). I don't want to create the impression that JavaScript will solve all the = problems that had been raised in discussion on this list. There is a = larger picture, which includes (at least): #1 Problems with the PKI as used in the Web (We had briefly spoken about this also at the Paris IAB technical = plenary, see http://www.ietf.org/proceedings/83/technical-plenary.html. = There is lots of work in the IETF here and there but I do not see the = direction where this is going.) =20 #2 Form-based authentication emerged because of the way the lower layer = security mechanisms weren't found attractive for many application = developers (see a short discussion about this topic in = http://tools.ietf.org/html/draft-tschofenig-secure-the-web-03). #3 The initial authentication needs to be carried across the entire = protocol session. Proposals like TLS-OBC seem to be a potential forward.=20= #4 Sharing of long-term credentials to allow one site to access = protected information of another site #5 Lack of authentication mechanisms with higher level of security. This = includes mechanisms that build on better identity proofing (which is = expensive) and multi-factor authentication (which is also expensive = since it raises the bar of what you need to possess). The problem there = is really the cost of deployment.=20 #6 Data breaches of backend databases It seems that we see an increase in the last few years but I am not sure = whether this is just a side-effect of more transparency due to data = breach notification laws all over the place. In general, it would of = course be good not to store plaintext passwords (or to have your = software be vulnerable to SQL injection attacks) but we will for sure = see these types of incidents and information will leak since sites tend = to collect more and more information about their customers. I am not = sure what is worse - your password gets stolen, your credit card, or = your medical records. In any case it is bad.=20 (I am sure that some of you could come up with other mechanisms as = well.)=20 Needless to say that one solution doesn't solve all these problems. The = JavaScript CryptAPI can really only help with item #2. #4 is being = solved by OAuth. The situation of #6 could (theoretically) be improved = by using different credentials and / or in combination of a WebSSO = solution.=20 I have gotten the impression that many people in the Web community = believe that we need to move to WebSSO solutions in order to=20 a) reduce the number of sites that run their own authentication = infrastructure. The assumption seems to be that fewer (but bigger) = players will have more expertise and incentives to secure their = authentication infrastructure, =20 and=20 b) the economies of scale will allow them to introduce authentication = mechanisms, stronger credential types, and better identity proofing = schemes.=20 If you want to read a nice writeup of these types of thoughts then have = a look at the NSTIC program, see http://www.nist.gov/nstic/.=20 Interestingly, we are moving to those systems already for a while = although much slower than some of us had expected and in a different way = than initially envisioned. When I started looking at that work in the = SAML days everyone was excited about sharing your authentication = information with other Web sites (exactly for the single-sign-on = experience). Today, we see more a focus on data sharing because the Web = with the mashups had required that Web sites focus on a very specific = task. try to do that well and get other functions done by other sites. = Typically, the data they need is protected (has also to-do with privacy) = and therefore requires a security mechanism to be in place to allow = secure data sharing (and the consent of the user prior to the sharing). = This is where OAuth comes into the picture and sharing of the = authentication information is really only an add-on to that.=20 On the other hand, these WebSSO and data sharing solutions have various = drawbacks as well. In general they require some additional "stuff" = beyond the technical protocol exchanges between the relying party and = the identity provider for various reasons, including security, privacy, = business models, and the lack of interoperability at the application = layer. =20 Hence, instead of being excited about writing specifications for yet = another authentication mechanisms or to find out how to stuff existing = authentication frameworks into HTTP I suggest to=20 * find out how the bigger picture looks like and what the relationships = between the different pieces are, (this may require a one-or two-day = workshop)=20 * work with the W3C on their CryptoAPI to make sure that it is indeed = covering users cases people in the IETF care about (*), and=20 * tackle some of the problems listed above.=20 Ciao Hannes (*) I could imagine that some folks on this list may even want to work = on some JavaScript libraries for their favorite authentication protocol = so that the Web community does not get it wrong. (Running code and all = that...) From stephen.farrell@cs.tcd.ie Tue Jul 17 04:35: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 36A4521F869C for ; Tue, 17 Jul 2012 04:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ft9w2Yjxa3od for ; Tue, 17 Jul 2012 04:35:31 -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 70F8F21F8678 for ; Tue, 17 Jul 2012 04:35:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 374D71714F3; Tue, 17 Jul 2012 12:36: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=1342524977; bh=X6PwHSA7Kh376Q ZpqpMr5QWwXoFzaADXdvXYrLV2OFg=; b=XLodGtbEcsMFHkgjlaCJcuICoCt/cM iqOhbX44zWlnoxjey4nfn868wKrc+Ki1MtiNmMTNsdtAXKWH0O4M17cTmek8i+44 eXPv9QRr+fz/G4seUv+moPTPTWcF1gxDcEtXHtJl/RHMZZkuVshfp601aiohQ14a dt9zMkBXSG6XXYlrKsefo/GO/hXGZ1oTKoC5hAGdwBhxr5ao6rWmwh+Vm/W35HNt r3VD9W1qF2o9eW8tTu1D63oNzRhxTy+61tG477RTDzMpI7HzH4Fp9QwaWSHfWAA2 2gAEpt/B2ZCJMgn/I3acd5icsEJAAau2sAsUIzyNNBvi995qORhOQdGg== 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 eV-OKCRQxc-D; Tue, 17 Jul 2012 12:36:17 +0100 (IST) Received: from [10.87.48.11] (unknown [86.45.63.34]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id BE70C1714C4; Tue, 17 Jul 2012 12:36:17 +0100 (IST) Message-ID: <50054E31.5040202@cs.tcd.ie> Date: Tue, 17 Jul 2012 12:36:17 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Hannes Tschofenig References: <6250FC21-C3F3-4197-BCBD-038D00E685CC@gmx.net> In-Reply-To: <6250FC21-C3F3-4197-BCBD-038D00E685CC@gmx.net> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF Security Area Advisory Group Subject: Re: [saag] JavaScript for authentication 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, 17 Jul 2012 11:35:32 -0000 On a meta-point, I disagree with you that JS is important to the argument here. JS is an important language, but not very relevant for this argument, which I take as being "how to do better web authentication." If there are language specific parts to that argument I'd be interested in knowing what those are. Can you help with that? The w3c stuff is of course good, and will hopefully allow for better implementation of crypto things in JS, so I'm not against what you're trying to do, but puzzled that you see JS as a critical part of the discussion. A few more nitty comments below, but the question above is my main point here. On 07/17/2012 11:50 AM, Hannes Tschofenig wrote: > #2 Form-based authentication emerged because of the way the lower layer security mechanisms weren't found attractive I agree. IMO, we ought aim for something that works for both HTTP and above (e.g. forms). And I think the route to get there, in an IETF context, is to do HTTP first, then people doing forms can copy that scheme if its good. > #3 The initial authentication needs to be carried across the entire protocol session. Proposals like TLS-OBC seem to be a potential forward. Right. And/or replicating the OBC trick at the HTTP layer. > #6 Data breaches of backend databases This, IMO, is something we have to address. WebSSO and GSS are not relevant for that part of the work. Replacing password verifiers with public keys would work if we can do it well enough. That is not something your average JS developer is gonna be able to do. (We've failed at it for years;-) So again, the route to take for me is to figure it out in HTTP first but so's it can be copied above HTTP. Cheers, S. From hannes.tschofenig@gmx.net Tue Jul 17 05:35: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 B6DCD21F86B8 for ; Tue, 17 Jul 2012 05:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.625 X-Spam-Level: X-Spam-Status: No, score=-102.625 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqC8SjQs1Ek9 for ; Tue, 17 Jul 2012 05:35:11 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 8344021F86D8 for ; Tue, 17 Jul 2012 05:35:10 -0700 (PDT) Received: (qmail invoked by alias); 17 Jul 2012 12:35:55 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.102]) [88.115.216.191] by mail.gmx.net (mp027) with SMTP; 17 Jul 2012 14:35:55 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1982/IJRuZ8q1D2qYwxj/PlVGW/UgS1fnhfWcBXp6 VQG5ilJ+qWAXfs Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <50054E31.5040202@cs.tcd.ie> Date: Tue, 17 Jul 2012 15:35:53 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <18C5A02F-B7FD-4486-9D20-769390F937BC@gmx.net> References: <6250FC21-C3F3-4197-BCBD-038D00E685CC@gmx.net> <50054E31.5040202@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: IETF Security Area Advisory Group Subject: Re: [saag] JavaScript for authentication 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, 17 Jul 2012 12:35:13 -0000 Hi Stephen,=20 On Jul 17, 2012, at 2:36 PM, Stephen Farrell wrote: >=20 > On a meta-point, I disagree with you that JS is important > to the argument here. JS is an important language, but not > very relevant for this argument, which I take as being "how > to do better web authentication." >=20 > If there are language specific parts to that argument I'd > be interested in knowing what those are. Can you help with > that? >=20 > The w3c stuff is of course good, and will hopefully allow > for better implementation of crypto things in JS, so I'm > not against what you're trying to do, but puzzled that you > see JS as a critical part of the discussion. Ok. Here is the relationship as I see it.=20 If the W3C manages to standardize the API extensions that allow us to = access keying material (and potentially offer some of the cryptographic = primitives to JavaScript, which would be useful for performance reasons) = then service providers can build their authentication protocols as they = need them (in JavaScript). They can (at any time!!!) change those = mechanisms to offer something better for their users (if the need = arises). I cannot stress the importance of this too much because the = time it takes to roll out new mechanisms (or even a minor improvement) = takes forever with the current software distribution model.=20 I hope I was able to explain the power of mobile code properly. =20 >=20 > A few more nitty comments below, but the question above is > my main point here. >=20 > On 07/17/2012 11:50 AM, Hannes Tschofenig wrote: >> #2 Form-based authentication emerged because of the way the lower = layer security mechanisms weren't found attractive=20 >=20 > I agree. IMO, we ought aim for something that works for both HTTP and > above (e.g. forms). And I think the route to get there, in an IETF > context, is to do HTTP first, then people doing forms can copy that > scheme if its good. I believe the right layer isn't HTTP but rather somewhere above it.=20 >=20 >> #3 The initial authentication needs to be carried across the entire = protocol session. Proposals like TLS-OBC seem to be a potential forward.=20= >=20 > Right. And/or replicating the OBC trick at the HTTP layer. Correct.=20 >=20 >> #6 Data breaches of backend databases >=20 > This, IMO, is something we have to address. WebSSO and GSS are > not relevant for that part of the work. Replacing password > verifiers with public keys would work if we can do it well > enough. That is not something your average JS developer is > gonna be able to do. (We've failed at it for years;-) So again, > the route to take for me is to figure it out in HTTP first > but so's it can be copied above HTTP. WebSSO should would help if you believe in the idea that fewer big = players take better care of your security. What could help any developer on the Web is to provide libraries that do = the complex stuff for them. So, in this case someone with clue would = write a good JavaScript authentication protocol library. We have seen = this happening, as Yaron mentioned, with JQuery in the UI area.=20 There are also other ideas on how to improve the situation. If you look = at the recent work in the 3GPP on standardizing software development and = security processes or the idea of regulators to introduce mandatory = audits, seals, certification, etc.=20 Ciao Hannes >=20 > Cheers, > S. From stephen.farrell@cs.tcd.ie Tue Jul 17 06:09: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 6C7EB21F86CE for ; Tue, 17 Jul 2012 06:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJeA9dlvxJTl for ; Tue, 17 Jul 2012 06:09:04 -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 50F0B21F86AB for ; Tue, 17 Jul 2012 06:09:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 14DB91714F3; Tue, 17 Jul 2012 14:09:51 +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=1342530590; bh=syL3QbC1IVzYav ZOeM6s7bOl0EXixp9PT+BXWTz2Krk=; b=i4MdWgli/2ype5m72S2aUIjxPYUyJ/ yA9eruIGbKdBCUjZZSQlw1LuEuXFZ8erAP3nZzirjZ89XYyNYqkDJz6H+eB3UOVc psZe13bhE8b9TtrI1mF6eH1Z293c9mqnZ+qmnl/roRP7YAcHdsMPkdXS1CRDLApL 2+0pof112jKZqFGW27D4henMGcGe9FU35gaTieFFIoDBVrqN+dXuW6IU5fExf2U+ 4QX6BsMM9e30qfVa0uaQVaif40Sy1GycDEpHQdO/1NZvoZnGqQ2NAj9JzRQd9WOD AYMwWbPrYZ1a6uJITM9BbJvTW5Up/OZ26+PUqMzmfRwdWdjg4/1wX2jQ== 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 w3Cwaaao+BAl; Tue, 17 Jul 2012 14:09:50 +0100 (IST) Received: from [10.87.48.11] (unknown [86.45.63.34]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 85ACA1714EB; Tue, 17 Jul 2012 14:09:50 +0100 (IST) Message-ID: <5005641E.6060700@cs.tcd.ie> Date: Tue, 17 Jul 2012 14:09:50 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Hannes Tschofenig References: <6250FC21-C3F3-4197-BCBD-038D00E685CC@gmx.net> <50054E31.5040202@cs.tcd.ie> <18C5A02F-B7FD-4486-9D20-769390F937BC@gmx.net> In-Reply-To: <18C5A02F-B7FD-4486-9D20-769390F937BC@gmx.net> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF Security Area Advisory Group Subject: Re: [saag] JavaScript for authentication 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, 17 Jul 2012 13:09:05 -0000 On 07/17/2012 01:35 PM, Hannes Tschofenig wrote: > Hi Stephen, > > > On Jul 17, 2012, at 2:36 PM, Stephen Farrell wrote: > >> >> On a meta-point, I disagree with you that JS is important >> to the argument here. JS is an important language, but not >> very relevant for this argument, which I take as being "how >> to do better web authentication." >> >> If there are language specific parts to that argument I'd >> be interested in knowing what those are. Can you help with >> that? >> >> The w3c stuff is of course good, and will hopefully allow >> for better implementation of crypto things in JS, so I'm >> not against what you're trying to do, but puzzled that you >> see JS as a critical part of the discussion. > > Ok. Here is the relationship as I see it. > > If the W3C manages to standardize the API extensions that allow us to access keying material (and potentially offer some of the cryptographic primitives to JavaScript, which would be useful for performance reasons) then service providers can build their authentication protocols as they need them (in JavaScript). They can (at any time!!!) change those mechanisms to offer something better for their users (if the need arises). I cannot stress the importance of this too much because the time it takes to roll out new mechanisms (or even a minor improvement) takes forever with the current software distribution model. > > I hope I was able to explain the power of mobile code properly. Ok, so your argument is about downloaded code and not JS in particular. I'm not sure I see the huge architectural change though, seems more like a matter of degree, given that I downloaded linux, (updated frequently), and firefox and chrome (also updated frequently). And as far as I know, most JS is not really per-site, but rather sites re-use bits of JS code and/or libraries they've gotten elsewhere. S. PS: I should probably admit I'm also a happy noscript user, so I could just be missing some JS stuff:-) > >> >> A few more nitty comments below, but the question above is >> my main point here. >> >> On 07/17/2012 11:50 AM, Hannes Tschofenig wrote: >>> #2 Form-based authentication emerged because of the way the lower layer security mechanisms weren't found attractive >> >> I agree. IMO, we ought aim for something that works for both HTTP and >> above (e.g. forms). And I think the route to get there, in an IETF >> context, is to do HTTP first, then people doing forms can copy that >> scheme if its good. > > I believe the right layer isn't HTTP but rather somewhere above it. > >> >>> #3 The initial authentication needs to be carried across the entire protocol session. Proposals like TLS-OBC seem to be a potential forward. >> >> Right. And/or replicating the OBC trick at the HTTP layer. > > Correct. > >> >>> #6 Data breaches of backend databases >> >> This, IMO, is something we have to address. WebSSO and GSS are >> not relevant for that part of the work. Replacing password >> verifiers with public keys would work if we can do it well >> enough. That is not something your average JS developer is >> gonna be able to do. (We've failed at it for years;-) So again, >> the route to take for me is to figure it out in HTTP first >> but so's it can be copied above HTTP. > > WebSSO should would help if you believe in the idea that fewer big players take better care of your security. > > What could help any developer on the Web is to provide libraries that do the complex stuff for them. So, in this case someone with clue would write a good JavaScript authentication protocol library. We have seen this happening, as Yaron mentioned, with JQuery in the UI area. > > There are also other ideas on how to improve the situation. If you look at the recent work in the 3GPP on standardizing software development and security processes or the idea of regulators to introduce mandatory audits, seals, certification, etc. > > Ciao > Hannes > >> >> Cheers, >> S. > > > From hartmans@mit.edu Tue Jul 17 07:39: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 09AEF21F86DA for ; Tue, 17 Jul 2012 07:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.042 X-Spam-Level: X-Spam-Status: No, score=-103.042 tagged_above=-999 required=5 tests=[AWL=-0.777, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQtp33v36XIv for ; Tue, 17 Jul 2012 07:39:12 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 30A9321F8533 for ; Tue, 17 Jul 2012 07:39:12 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 4AACE202D8; Tue, 17 Jul 2012 10:40:20 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 821B741F0; Tue, 17 Jul 2012 10:39:36 -0400 (EDT) From: Sam Hartman To: Stephen Farrell References: <6250FC21-C3F3-4197-BCBD-038D00E685CC@gmx.net> <50054E31.5040202@cs.tcd.ie> <18C5A02F-B7FD-4486-9D20-769390F937BC@gmx.net> <5005641E.6060700@cs.tcd.ie> Date: Tue, 17 Jul 2012 10:39:36 -0400 In-Reply-To: <5005641E.6060700@cs.tcd.ie> (Stephen Farrell's message of "Tue, 17 Jul 2012 14:09:50 +0100") 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: IETF Security Area Advisory Group Subject: Re: [saag] JavaScript for authentication 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, 17 Jul 2012 14:39:13 -0000 I'm with Hannes. There is a huge architectural difference between allowing the site to control what code you run and allowing the platform to control what code you run. The issue is not the frequency of your Firefox updates, but whether site x can depend on you having a particular update. If site x controls what code you're running, then they can have much higher confidence you have a particular feature. That's true regardless of whether the code ultimately is written by site x or imported from somewhere else. There are practical reasons that make this far more true for JS than for anything else. I might except that the architectural issue is site-controlled vs platform-controlled and JS vs other mobile code is a matter of degree. However the degree is so important that I don't think the argument worth having. While I think this web architecture makes it far easier to push out new mechanisms, I'll note that it has huge security drawbacks as well. Running your authentication mechanism from a dubiously-trusted code source has disadvantages. My current thinking is that JS allows us to make new mechanisms deployable. They won't actually give us much in the way of security because we can't actually trust them, but they won't make things particularly worse than they are today. If we do it right, I think we can eventually get security benefits as those same mechanisms make their way into the platform. There are many unsolved problems in all this, especially including the UX issues. I don't have the energy to build a consensus behind this in the IETF; I'm happy to write code and if we ever get it working standardize later. From mouse@Sparkle.Rodents-Montreal.ORG Tue Jul 17 08:23: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 3F68C21F854B for ; Tue, 17 Jul 2012 08:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.177 X-Spam-Level: X-Spam-Status: No, score=-9.177 tagged_above=-999 required=5 tests=[AWL=0.811, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, 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 dHurNxzesp4W for ; Tue, 17 Jul 2012 08:23:07 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id 25EF921F853E for ; Tue, 17 Jul 2012 08:23:06 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id LAA13455; Tue, 17 Jul 2012 11:23:53 -0400 (EDT) Date: Tue, 17 Jul 2012 11:23:53 -0400 (EDT) From: Mouse Message-Id: <201207171523.LAA13455@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: Tue, 17 Jul 2012 11:02:30 -0400 (EDT) To: saag@ietf.org In-Reply-To: <86A7D574-9939-4BBC-A095-7BC6C4B95C96@gmx.net> References: <500461C5.7020006@gmail.com> <8CA8896B-D506-4581-8A2E-E223D6EA7584@gmx.net> <50046BD5.30404@gmail.com> <201207161951.PAA05561@Sparkle.Rodents-Montreal.ORG> <86A7D574-9939-4BBC-A095-7BC6C4B95C96@gmx.net> Subject: Re: [saag] Password Discussion 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, 17 Jul 2012 15:23:08 -0000 [top-posting and no-trimming damage repaired manually] > The question of trust in downloadable code is orthogonal to the JavaScript t$ "We" do? "Always"? _I_ certainly don't. If _you_ want to turn over control of your machine to anyone whose website you visit, or anyone who happens to have cracked the hosting for website you visit, that's _your_ neck. > In fact, not downloading the latest code (automatically) increases your vuln$ While downloading it increases your vulnerability to (other) attacks. (Well, downloading it and running it, but that's true of both.) There's also a huge difference between installing an update to an application from its provider (which is what I assume you're talking about here) and running more or less arbitrary code offered up by a webpage you have no relationship to beyond looking at. For my purposes, I do applicatino-level updates relatively rarely and always with human intelligence inserted between "download" and "run". /~\ 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 stephen.farrell@cs.tcd.ie Tue Jul 17 08:39: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 DBE9D21F8552 for ; Tue, 17 Jul 2012 08:39: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAd6YvaKcK0g for ; Tue, 17 Jul 2012 08:39:03 -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 B673621F858A for ; Tue, 17 Jul 2012 08:38:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 45017153F38; Tue, 17 Jul 2012 16:39:44 +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=1342539575; bh=FIo92nPbPh6wSg ixo8dTzU26ieoT54umMWbUPQ01fXo=; b=sWa3CEyVyip2QncvJvXZq5+wv4E37u cdACRlonDS9iRnHYUbvHroYLeFRdraIvOzvpozbhdOKuGrGRJ6urE4RPloAcvW7K o1/X4JOY/8Nxdgf3ow2aMrIHNLUJLgppHY5z8CeP5RIEmft/1yt8iys5lYOKritM lHWhRTOCPlkFRYPqTOWZWOd9rR32Du4wo7E0uLBkgYVtkH0nSiSG/zQCVpRVYqbY /nND29lUGLTmtZkwOFWES4w1J8vd2Os8iSIgCx7HJ+EVXQYGIZ6X928tlJihsrQM vkQdwSNNZOPbEyFv+qPBPXb4wBWpAFL+s1Jxyt54BW+C207ZqK22LlHQ== 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 P0VitEZz+n9Y; Tue, 17 Jul 2012 16:39:35 +0100 (IST) Received: from [10.87.48.11] (unknown [86.45.63.34]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6B8F0153C74; Tue, 17 Jul 2012 16:39:33 +0100 (IST) Message-ID: <50058735.10001@cs.tcd.ie> Date: Tue, 17 Jul 2012 16:39:33 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Sam Hartman References: <6250FC21-C3F3-4197-BCBD-038D00E685CC@gmx.net> <50054E31.5040202@cs.tcd.ie> <18C5A02F-B7FD-4486-9D20-769390F937BC@gmx.net> <5005641E.6060700@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF Security Area Advisory Group Subject: Re: [saag] JavaScript for authentication 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, 17 Jul 2012 15:39:06 -0000 On 07/17/2012 03:39 PM, Sam Hartman wrote: > I'm with Hannes. There is a huge architectural difference between > allowing the site to control what code you run and allowing the platform > to control what code you run. > The issue is not the frequency of your Firefox updates, but whether site > x can depend on you having a particular update. If site x controls what > code you're running, then they can have much higher confidence you have > a particular feature. Ok, I can buy that as an architectural difference given that 90+% of clients will run anyone's code. > That's true regardless of whether the code ultimately is written by site > x or imported from somewhere else. > > There are practical reasons that make this far more true for JS than for > anything else. I might except that the architectural issue is > site-controlled vs platform-controlled Yep. I like that characterisation. > and JS vs other mobile code is a > matter of degree. However the degree is so important that I don't think > the argument worth having. Don't get that. Do you mean JS is so ubiquitous that its ok as shorthand for site-controlled vs platform-controlled? If so, I didn't get it when Hannes assumed it and am not sure its really a good shorthand. > While I think this web architecture makes it far easier to push out new > mechanisms, I'll note that it has huge security drawbacks as > well. Running your authentication mechanism from a dubiously-trusted > code source has disadvantages. Right. S. > > My current thinking is that JS allows us to make new mechanisms > deployable. They won't actually give us much in the way of security > because we can't actually trust them, but they won't make things > particularly worse than they are today. If we do it right, I think we > can eventually get security benefits as those same mechanisms make their > way into the platform. There are many unsolved problems in all this, > especially including the UX issues. > > I don't have the energy to build a consensus behind this in the IETF; > I'm happy to write code and if we ever get it working standardize later. > > From palmer@google.com Tue Jul 17 10:12: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 67FD021F86BD for ; Tue, 17 Jul 2012 10:12:57 -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 ibaj-Kl8SWy0 for ; Tue, 17 Jul 2012 10:12:56 -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 7335621F86B2 for ; Tue, 17 Jul 2012 10:12:56 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1041124lbb.31 for ; Tue, 17 Jul 2012 10:13:43 -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=p+qFGIX3Y8DK5LdkLmAVEdD2WysdSYSJka+F8ukdxv4=; b=DeYEekknFG8LlWxbW9V5zottmcuEngRbM+x97OginBrKvqgSWETYWzvHhvzxD+hNjU pa3GCUvmuUJjdpDMIRhQAIfUcVp9z7jCKYih8Exp4eK70+Y98KFZ9CdNKEWtogLQ3bct 1R3PSjy8huUryhrfEWMk2n6XI7KMZdzXNOd//JzXzOZBQXf5UGDSgCtDfs5QU2azAK8/ 6oQeDTo9MJ68zGBltXyGac7E0MDDtYW1mHafQG4YWPnuFxp+XHhx/YAUZ7FYmXvb0Pz8 Oa9H2PTyaPF8U0OKgy2U1uiAhC+9ObRQvGGym7B8PvZlgh0GDSAG6KCpPLkwQgqGbJ2N QHDw== 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=p+qFGIX3Y8DK5LdkLmAVEdD2WysdSYSJka+F8ukdxv4=; b=FqQyfqFHSr166NqWIdSgxBhOjttjItV3OwgHNVUyQ+OtH2SG7Cm+UYaMTaWFvgEUQL KsAV3s7SSyiseSJdnUvkXg1UFVXhQA2jzLymyG//Ob8GN5KCNS2Kd2ne9SGVOfARIK1n T/ypNghF/ZJZKQh9FW0ke90Pu2Kw8EIyjdMASgvl8h4wWLJSYnZQsLVYbW3EMQDT35Kb +ieiGcb9Xh1tQQrPeXz3da0cJJscLJstVlDUR+zu99pBLIMehDVhpKqxJWVI4Q3SFdU+ KzRgg3Vv5z9hC6Bo0CMX5QIpzRZkLOsgRM+dhkseSyXvK7awDD3C0QL5vvqt+GAViys8 PBjQ== Received: by 10.112.42.164 with SMTP id p4mr100397lbl.54.1342545223341; Tue, 17 Jul 2012 10:13:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.42.164 with SMTP id p4mr100391lbl.54.1342545223195; Tue, 17 Jul 2012 10:13:43 -0700 (PDT) Received: by 10.112.12.149 with HTTP; Tue, 17 Jul 2012 10:13:43 -0700 (PDT) In-Reply-To: <50058735.10001@cs.tcd.ie> References: <6250FC21-C3F3-4197-BCBD-038D00E685CC@gmx.net> <50054E31.5040202@cs.tcd.ie> <18C5A02F-B7FD-4486-9D20-769390F937BC@gmx.net> <5005641E.6060700@cs.tcd.ie> <50058735.10001@cs.tcd.ie> Date: Tue, 17 Jul 2012 10:13:43 -0700 Message-ID: From: Chris Palmer To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQkFRIKbBqkGFGGai6ifAo4r5WZwmi7af0CsoxSBhVWNLoVWhZbw+ccc+Ee+D6AYW+B8hv7jRPLER7eroa3znKsuU3rWPsJGHvP82rMqLm96tlaWFC1NbruQ+Z0HPxMHhPNnCU0Nbo9iEYRliFIM3LDKo9BFeYN1z0DYulvgdOEbYHhrIqk= Cc: Sam Hartman , IETF Security Area Advisory Group Subject: Re: [saag] JavaScript for authentication 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, 17 Jul 2012 17:12:57 -0000 I am having a hard time following this discussion, because I can't imagine how JavaScript crypto will help solve the problems. (I do believe in and understand the problems Hannes raised, of course.) Can someone (Hannes?) provide a sketch of an example of what a JavaScript crypto-based solution to the authentication problem would look like? And explain how this solution will be better than what is currently available (or at least what is currently possible)? For example, say a server delivers a blob of JS to the client. Transmission is over TLS, of course (otherwise, the blob contains code written by the attacker). The blob uses the browser's support for the JS crypto APIs to query the browser's database of public/private key pairs for the server's origin (creating a new pair if none exists, and registering the public key with the server). Then the JS code proves to the server that the client has ownership of the private key, thus authenticating the user transparently and without having to store any sensitive data (like a poorly hashed password) on the server. Yay! But, couldn't we get pretty much the same thing client certificates, possibly with TLS-OBC or some other scheme? Is it better than TLS-SRP? And then there are all the problems =E2=80=94 dealbreakers, AFAICT =E2=80= =94 raised by Ptacek and Lawson. That said, I *can* imagine a way to not need TLS: re-define the web origin concept by making it the origin be the keypair used to sign the JS blob. (This is how Android separates code origins, for example.) Then you could do all security in JS, and presumably somebody would write The Good Library That Does It Right. But re-defining the web origin concept is a major undertaking, especially since we finally defined it (RFC 6454). And especially since in the short and medium terms, most web sites would find themselves in a default "unsigned" origin, together with all the others... From hannes.tschofenig@gmx.net Tue Jul 17 11:22: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 730F411E8091 for ; Tue, 17 Jul 2012 11:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.625 X-Spam-Level: X-Spam-Status: No, score=-102.625 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wY-RckfLYVOV for ; Tue, 17 Jul 2012 11:22:37 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 2004E11E808E for ; Tue, 17 Jul 2012 11:22:36 -0700 (PDT) Received: (qmail invoked by alias); 17 Jul 2012 18:20:41 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.102]) [88.115.216.191] by mail.gmx.net (mp028) with SMTP; 17 Jul 2012 20:20:41 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+jP09r7E+jW//kvEf1bdCOFPr6kFDNzsE0Oj7EcK XobhYvy7Fa2LyD Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <5005641E.6060700@cs.tcd.ie> Date: Tue, 17 Jul 2012 21:20:39 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <02B84456-5FDF-443B-A771-53943EE4BDC1@gmx.net> References: <6250FC21-C3F3-4197-BCBD-038D00E685CC@gmx.net> <50054E31.5040202@cs.tcd.ie> <18C5A02F-B7FD-4486-9D20-769390F937BC@gmx.net> <5005641E.6060700@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: IETF Security Area Advisory Group Subject: Re: [saag] JavaScript for authentication 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, 17 Jul 2012 18:22:38 -0000 Hi Stephen,=20 >=20 > Ok, so your argument is about downloaded code and not JS > in particular. >=20 > I'm not sure I see the huge architectural change though, > seems more like a matter of degree, given that I downloaded > linux, (updated frequently), and firefox and chrome (also > updated frequently). And as far as I know, most JS is not > really per-site, but rather sites re-use bits of JS code > and/or libraries they've gotten elsewhere. >=20 There is more to that.=20 Of course there has always been the possibility to download a native = application to your device. I am, however, focusing here on how to = accomplish interoperability: I would like to pick a random web browser = in two years and connect to a Website of my choice, my identity = provider, and it should be able to run an authentication protocol that = this IdP offers with my browser (if I provide my consent).=20 This is the way how the location integration into the browser works = today for nearly all location-based applications today. =20 The difference to the way we had done our standardization work is best = illustrated with an example from the RAI area.=20 In the RAI area we have been working on SIP for a long, long time and = standardized extensions like hell. That took a long time and didn't = actually lead to great interoperability (for various reasons, as = Jonathan Rosenberg described quite nicely at the Prague IAB technical = plenary, see http://www.ietf.org/proceedings/80/slides/plenaryt-5.pdf). The same is true for XMPP. Lots of standardization was going on in the = IETF and in the XSF to reach some level of interoperability between an = XMPP client and XMPP servers. =20 Now, it turns out that you can also accomplish interoperability in a = different way: instead of standardizing every protocol exchange and = every protocol element you can as well standardize a language, = JavaScript, that is capable enough to build any of these real-time = protocol (and many more).=20 Of course this language has to provide "extensions" (call them APIs) to = connect to hardware (such as microphone, camera, GPS module, ...) so = that it can do all the stuff a native application can do but just in an = interoperable way.=20 Consequently, now we have Websites that send JavaScript to your browser = that happens to implement real-time protocols and some folks had for fun = replicated SIP, XMPP and other protocols in JavaScript to illustrate = it's power.=20 I hope that this is a better description.=20 Ciao Hannes > S. >=20 > PS: I should probably admit I'm also a happy noscript user, > so I could just be missing some JS stuff:-) >=20 From hartmans@mit.edu Tue Jul 17 11:26: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 9412811E8091 for ; Tue, 17 Jul 2012 11:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.018 X-Spam-Level: X-Spam-Status: No, score=-103.018 tagged_above=-999 required=5 tests=[AWL=-0.753, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8YACkkD9yH3 for ; Tue, 17 Jul 2012 11:26:56 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE5711E808E for ; Tue, 17 Jul 2012 11:26:56 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 83A86203BA; Tue, 17 Jul 2012 14:28:00 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 16FAA41F0; Tue, 17 Jul 2012 14:27:17 -0400 (EDT) From: Sam Hartman To: Stephen Farrell References: <6250FC21-C3F3-4197-BCBD-038D00E685CC@gmx.net> <50054E31.5040202@cs.tcd.ie> <18C5A02F-B7FD-4486-9D20-769390F937BC@gmx.net> <5005641E.6060700@cs.tcd.ie> <50058735.10001@cs.tcd.ie> Date: Tue, 17 Jul 2012 14:27:17 -0400 In-Reply-To: <50058735.10001@cs.tcd.ie> (Stephen Farrell's message of "Tue, 17 Jul 2012 16:39:33 +0100") 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: Sam Hartman , IETF Security Area Advisory Group Subject: Re: [saag] JavaScript for authentication 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, 17 Jul 2012 18:26:56 -0000 >>>>> "Stephen" == Stephen Farrell writes: >> and JS vs other mobile code is a >> matter of degree. However the degree is so important that I don't think >> the argument worth having. Stephen> Don't get that. Do you mean JS is so ubiquitous that its No, I mean that JS is the site-controlled solution that works well in practice. It's more reliable than Java or Flash or other site-controlled approaches. If someone says they're moving to a site-controlled approach I have less confidence it will actually work than if they say they are moving to something implemented in JS. Note that even with JS there are significant versioning issues. However everyone has JS. From stephen.farrell@cs.tcd.ie Tue Jul 17 13:03: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 BF57221F85C2 for ; Tue, 17 Jul 2012 13:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3Y647tmdezZ for ; Tue, 17 Jul 2012 13:03:25 -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 147F321F85F8 for ; Tue, 17 Jul 2012 13:03:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 086111714EB; Tue, 17 Jul 2012 21:04:13 +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=1342555451; bh=SLi1PnV0tmUEDE LMEU3IEGJPRvyn1/4LK5KGxrKhc+U=; b=HT3nOFrJcXdx7IwzVvtt3D/+BvaBTt QWnOvAwnAWPoJaweMI2B4l8p+rx0HsxROqZWJNqzoMQ8u96VBzixC79R21/mQH/y Kj2ftCQVmYB2bjGtgB54nz5+lZOrfzJWQS7Yn0HBb5U0XeYJJCCqSmI/e9fpdAXU ohT+0yiKi/WwxZG3cmAlV9OIqpsQTylbs/PoTaeV4/AKpyVnJKEne44pSaN1eij3 lk7mYjj2Ujn1gqswjS7B9iRAb1JgNXRosP/fI2oxgEExasdUbLtGK/nrvjW+LVlh l8qnqxbLHQhqOTF+yKR7/XannptnxZjoxYLRY2phfp5rpGzr23RjFgBQ== 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 CAYHbPzjoge9; Tue, 17 Jul 2012 21:04:11 +0100 (IST) Received: from [10.87.48.11] (unknown [86.45.63.34]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id AFEAB1714E2; Tue, 17 Jul 2012 21:04:11 +0100 (IST) Message-ID: <5005C53B.2060100@cs.tcd.ie> Date: Tue, 17 Jul 2012 21:04:11 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Hannes Tschofenig References: <6250FC21-C3F3-4197-BCBD-038D00E685CC@gmx.net> <50054E31.5040202@cs.tcd.ie> <18C5A02F-B7FD-4486-9D20-769390F937BC@gmx.net> <5005641E.6060700@cs.tcd.ie> <50058735.10001@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF Security Area Advisory Group Subject: Re: [saag] JavaScript for authentication 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, 17 Jul 2012 20:03:25 -0000 On 07/17/2012 07:27 PM, Sam Hartman wrote: > In the RAI area we have been working on SIP for a long, long time and standardized extensions like hell. That took a long time and didn't actually lead to great interoperability (for various reasons, as Jonathan Rosenberg described quite nicely at the Prague IAB technical plenary, see http://www.ietf.org/proceedings/80/slides/plenaryt-5.pdf). Yeah. Now that was ironic. So, ok, its about site-controlled as Sam nicely put it. I guess that brings us back to Chris' question as to how that might be done securely. S. From ekr@rtfm.com Tue Jul 17 14:13: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 7D38F11E80A2 for ; Tue, 17 Jul 2012 14:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.836 X-Spam-Level: X-Spam-Status: No, score=-102.836 tagged_above=-999 required=5 tests=[AWL=0.141, 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 VfLIvaVkrxXC for ; Tue, 17 Jul 2012 14:13:14 -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 CB9E421F8504 for ; Tue, 17 Jul 2012 14:13:13 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so675050vcb.31 for ; Tue, 17 Jul 2012 14:14:02 -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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=eTMrcspFUMPRd+oenH7rMKel6Y4CeYPIoS9D9ntvp18=; b=O5LTYT8Axav5tHPEsOFab5h0VkOJ5RV35iApaLzYFB3rHn2+Z9OwK6yPcqwn8Efix7 ocyOQQTNNetV68SsvrE4XOczT7DCEvpLYEl2fvu3tqZEVzctUDUIV+aggxWxytVK242B tgXqQj2ytg2d66vFtnC+U3xbOrgU8PvArV+0bV3SjJguAEOO4W+6Isrd7x8tPt4f0V+M bdsUQueAm0kJzfWO2f+biJfuwNm5F0eCkRgTJXVSY6zRLMRDdhXzdXjHLY16fmEXLAU5 r3suphZ84d2rEApZ4TI4iuLl9C18jxaOeh9Ww/Ojk4G8ZaITt4n47+EKTBiTdE7yHH1/ 8grg== Received: by 10.220.40.79 with SMTP id j15mr454910vce.48.1342559641915; Tue, 17 Jul 2012 14:14:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Tue, 17 Jul 2012 14:13:21 -0700 (PDT) X-Originating-IP: [74.95.2.169] In-Reply-To: <5005C53B.2060100@cs.tcd.ie> References: <6250FC21-C3F3-4197-BCBD-038D00E685CC@gmx.net> <50054E31.5040202@cs.tcd.ie> <18C5A02F-B7FD-4486-9D20-769390F937BC@gmx.net> <5005641E.6060700@cs.tcd.ie> <50058735.10001@cs.tcd.ie> <5005C53B.2060100@cs.tcd.ie> From: Eric Rescorla Date: Tue, 17 Jul 2012 14:13:21 -0700 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmG42WGCrACdGg1kY0rAS3sBzlcsd5IzssNWaSAS3+wzqtFqjAkfF9b1VkqvqqaXROhtLmx Cc: IETF Security Area Advisory Group Subject: Re: [saag] JavaScript for authentication 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, 17 Jul 2012 21:13:14 -0000 On Tue, Jul 17, 2012 at 1:04 PM, Stephen Farrell wrote: > > > On 07/17/2012 07:27 PM, Sam Hartman wrote: >> In the RAI area we have been working on SIP for a long, long time and st= andardized extensions like hell. That took a long time and didn't actually = lead to great interoperability (for various reasons, as Jonathan Rosenberg = described quite nicely at the Prague IAB technical plenary, see http://www.= ietf.org/proceedings/80/slides/plenaryt-5.pdf). > > Yeah. Now that was ironic. > > So, ok, its about site-controlled as Sam nicely put it. > > I guess that brings us back to Chris' question as to how > that might be done securely. I'm not sure that "that" is that well-defined. What do you believe the problem statement is here? -Ekr From stephen.farrell@cs.tcd.ie Tue Jul 17 14:55:19 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 8AC9821F84FC for ; Tue, 17 Jul 2012 14:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fI2fvV2baCiR for ; Tue, 17 Jul 2012 14:55:15 -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 3007A11E809C for ; Tue, 17 Jul 2012 14:55:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 5CA251714F3; Tue, 17 Jul 2012 22:56:01 +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=1342562160; bh=H0NgZsEAXYnk54 VUxg0Sv58Wkscq/jiJJ4S7SV6hLdk=; b=wtshIdopwrx6/tiubnOatylscDXYbP bVdRcM44QkKJJvw/M0nIFAepYk7PedsWm39XamwqfQ8KPUSDrI+RnOF8f1t+h7IT OITpThVoNj8pennS605X9xXl2cg2id7HlId+8KwsBvrrwkbngQRVeSBySmMRVW5b Aw+VlAFtcmzlClZSxA15t+Nk97cuJT+ZWexnzvF5m9HYSTRpI7V+lXhQrfMn5frQ rMaCXTbGICgbnMbhH6UZQX6YfYP1QqO1FNZtPNah0YS6DaHkMTxj95rO0QDx7lKF sJhYes7JL1ZmFBPdozuEHPRwUfqeqRbE6nr/QpeKf39lAdWYrwcOBIjQ== 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 gp3L4aBUNSqU; Tue, 17 Jul 2012 22:56:00 +0100 (IST) Received: from [10.87.48.11] (unknown [86.45.63.34]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id F2D371714EB; Tue, 17 Jul 2012 22:55:59 +0100 (IST) Message-ID: <5005DF6F.8070904@cs.tcd.ie> Date: Tue, 17 Jul 2012 22:55:59 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Eric Rescorla References: <6250FC21-C3F3-4197-BCBD-038D00E685CC@gmx.net> <50054E31.5040202@cs.tcd.ie> <18C5A02F-B7FD-4486-9D20-769390F937BC@gmx.net> <5005641E.6060700@cs.tcd.ie> <50058735.10001@cs.tcd.ie> <5005C53B.2060100@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF Security Area Advisory Group Subject: Re: [saag] JavaScript for authentication 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, 17 Jul 2012 21:55:20 -0000 On 07/17/2012 10:13 PM, Eric Rescorla wrote: > On Tue, Jul 17, 2012 at 1:04 PM, Stephen Farrell > wrote: >> >> >> On 07/17/2012 07:27 PM, Sam Hartman wrote: >>> In the RAI area we have been working on SIP for a long, long time and standardized extensions like hell. That took a long time and didn't actually lead to great interoperability (for various reasons, as Jonathan Rosenberg described quite nicely at the Prague IAB technical plenary, see http://www.ietf.org/proceedings/80/slides/plenaryt-5.pdf). >> >> Yeah. Now that was ironic. >> >> So, ok, its about site-controlled as Sam nicely put it. >> >> I guess that brings us back to Chris' question as to how >> that might be done securely. > > I'm not sure that "that" is that well-defined. What do you believe the > problem statement is here? Its obviously the inverse of the threat model:-) S > > -Ekr > > From derek@ihtfp.com Wed Jul 18 06:52:19 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 5F50221F8731 for ; Wed, 18 Jul 2012 06:52:19 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMmHiFr45iBY for ; Wed, 18 Jul 2012 06:52:18 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) by ietfa.amsl.com (Postfix) with ESMTP id 2161621F870A for ; Wed, 18 Jul 2012 06:52:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id D3960260231; Wed, 18 Jul 2012 09:53:01 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 20617-05; Wed, 18 Jul 2012 09:53:00 -0400 (EDT) Received: from mocana.ihtfp.org (unknown [IPv6:fe80::224:d7ff:fee7:8924]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 60A55260224; Wed, 18 Jul 2012 09:53:00 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id q6IDqu9q001775; Wed, 18 Jul 2012 09:52:56 -0400 From: Derek Atkins To: Stephen Farrell References: <6250FC21-C3F3-4197-BCBD-038D00E685CC@gmx.net> <50054E31.5040202@cs.tcd.ie> <18C5A02F-B7FD-4486-9D20-769390F937BC@gmx.net> <5005641E.6060700@cs.tcd.ie> <50058735.10001@cs.tcd.ie> <5005C53B.2060100@cs.tcd.ie> <5005DF6F.8070904@cs.tcd.ie> Date: Wed, 18 Jul 2012 09:52:54 -0400 In-Reply-To: <5005DF6F.8070904@cs.tcd.ie> (Stephen Farrell's message of "Tue, 17 Jul 2012 22:55:59 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: IETF Security Area Advisory Group Subject: Re: [saag] JavaScript for authentication 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, 18 Jul 2012 13:52:19 -0000 Stephen Farrell writes: > On 07/17/2012 10:13 PM, Eric Rescorla wrote: >> On Tue, Jul 17, 2012 at 1:04 PM, Stephen Farrell >> wrote: >>> >>> >>> On 07/17/2012 07:27 PM, Sam Hartman wrote: >>>> In the RAI area we have been working on SIP for a long, long time and standardized extensions like hell. That took a long time and didn't actually lead to great interoperability (for various reasons, as Jonathan Rosenberg described quite nicely at the Prague IAB technical plenary, see http://www.ietf.org/proceedings/80/slides/plenaryt-5.pdf). >>> >>> Yeah. Now that was ironic. >>> >>> So, ok, its about site-controlled as Sam nicely put it. >>> >>> I guess that brings us back to Chris' question as to how >>> that might be done securely. >> >> I'm not sure that "that" is that well-defined. What do you believe the >> problem statement is here? > > Its obviously the inverse of the threat model:-) ... which is? (Yes, I'm being rhetorical here, but I think we do need to be explicit about what the threat model is in order to have an explicit problem statement) There are obvious benefits to a site-controlled approach. There are also obvious benefits to a platform-controlled approach. The benefits of each are somewhat different, and the drawbacks to each are different. Are they necessarily disjoint? > S -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From benl@google.com Wed Jul 18 09:00: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 E4EA711E80DB for ; Wed, 18 Jul 2012 09:00: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=[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 9lyjVwI9SNuJ for ; Wed, 18 Jul 2012 09:00:50 -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 0666511E80D9 for ; Wed, 18 Jul 2012 09:00:49 -0700 (PDT) Received: by qcac10 with SMTP id c10so1155924qca.31 for ; Wed, 18 Jul 2012 09:01:40 -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=J0ESMMCeRcmANqsiGLEg0JUr0XioLO5PU2ODOFz+TbE=; b=cZFUzrWAnytsmSFYQp4sFlB+J9LTZfzJobA503RWsCsZEC2ZyhRzQ2uLe3EEJR/S37 dDOvEZxR015HvQbFNj8oQ7823kGO1JH0ORWf+I1AIspkC3gmL6SrOE9hx91Z6aqHY2EX jHITPHMfz7Gtlvsc8JH6fsnex+eULVmuUjvsKCMvKgIvMBlf98ZiNEjVmm+kZbx34Dso LDvYjoIHI0VB5sfKPNhMFlx6fIQ2UT9Kc23Mt1gLuG9hsnk2D+3Fp18D8RahxmX1zsXr cXVQbCLX2ajB6n0EQjyRfJBgTHklz18rCnU1LaayTj54IpscLvsn6BOE9UcdYdryRGEK fPFQ== 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=J0ESMMCeRcmANqsiGLEg0JUr0XioLO5PU2ODOFz+TbE=; b=R+tCntJoJI+SG2IvQyOqJivXEvunwC/IXHrLnDPw+3FqIiXfow8FDwwyBlWL78fuhh 4lsWf5fmoU0bJ0PH9Yo9dmRWtEfknrX8GD5yPbqiAplQk1r18GVhcT5hJ1dahWpaWHr5 pASMP/m7lTBS/TkQdQsp1QFbNeRhA3pspqYXnWyh0gibHwk69c2HGEv8YCUsOAfpNlwz 1xJYSSOdISoDr1imqKgwelXtejI1wAMdGj4fQGFK9ONHVmSHXe6QeaWPubgM4W+wOaff Y43gb9Kag7gJfSLVtnNX5XR50HX8xZ28zGm6V4/T9dRJIwjQZ7rGSXklI7Mm1WP0f/t7 cK/Q== Received: by 10.60.21.198 with SMTP id x6mr2127531oee.24.1342627300201; Wed, 18 Jul 2012 09:01:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.21.198 with SMTP id x6mr2127517oee.24.1342627300048; Wed, 18 Jul 2012 09:01:40 -0700 (PDT) Received: by 10.60.171.199 with HTTP; Wed, 18 Jul 2012 09:01:39 -0700 (PDT) In-Reply-To: <6250FC21-C3F3-4197-BCBD-038D00E685CC@gmx.net> References: <6250FC21-C3F3-4197-BCBD-038D00E685CC@gmx.net> Date: Wed, 18 Jul 2012 17:01:39 +0100 Message-ID: From: Ben Laurie To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnBddGbe4ndy0L89YWhIeGVIYRJuU3V7FRy6M8MapsxOb8OnRwAOAJyN8LDzImHeRqRETsll3pOMB67pXn9fn9Bz9kpOeOk2/gyWPtWBaA/Wb/r9xbM3dyiM0kGjXFj69mZqphIfJ2S7n/m7ej9neaYVdWZuvTeJT2/rThnyVcWTnorEMg= Cc: IETF Security Area Advisory Group Subject: Re: [saag] JavaScript for authentication 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, 18 Jul 2012 16:00:51 -0000 On 17 July 2012 11:50, Hannes Tschofenig wrote: > * tackle some of the problems listed above. On tackling the problems above, I should mention two things: 1. Certificate Transparency - happy to provide more links, but an overview: http://www.links.org/files/CertificateAuthorityTransparencyandAuditability.pdf. TL;DNR: keep an append-only, public, verifiable log of all certs issued and use this to detect mis-issuance. CT is s.t. the log does not have to be trusted. 2. Authentication - the real problem with passwords is not so much that they are passwords, but that it is completely impossible to follow the recommended policies (different password for each site, don't write them down) without assistance. Nigori (http://www.links.org/files/nigori/) provides a way to store your passwords centrally without having to trust the store (there's a theme here). There have been several studies that show that everything we try to replace passwords with is less good - so why fight it? Why not fix the underlying problem? Also, of course, once you have such a central store it is easy to store things like private keys in it instead of passwords... From benl@google.com Wed Jul 18 09:02: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 B30D711E80A5 for ; Wed, 18 Jul 2012 09:02:26 -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 lr8gohcLvhxW for ; Wed, 18 Jul 2012 09:02:25 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id B888611E809B for ; Wed, 18 Jul 2012 09:02:25 -0700 (PDT) Received: by qaea16 with SMTP id a16so1062809qae.10 for ; Wed, 18 Jul 2012 09:03:16 -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=wCPBoSIVnNtb84hztHC+b009L6Tz7zM6wREU/Zj8LYU=; b=bJHil2Nt23vt1ER78Y0X4NelYfaoX/qxenWsSrG2hznisYNlv4hixE9olCK/YI/GaB Mhv4qYMImuQBsmb4vAqO5lyYZlVc/uLBUX6wCrVKnSnYgyQmczvRWaJbEy4QyTKdCb2F U2gdl2UfrrQe5zl6YEGJqLEGH87kF6+SYrdlEvHuyKjwj17gglHmsHL+nCbFGEP716uR wlpo/MggGUkiYa9wc3YfryrZf6YJzFiVuef+wJ5EKGFGxNhc9HmeCXm+rgVl4cYsOm0b KzCd+7VJWvuacPSI9/5F7PsW8eoGUcfXNvjEzECZNB6a1ttLppHzpvcNVCb6hEYGI/9R ZO8A== 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=wCPBoSIVnNtb84hztHC+b009L6Tz7zM6wREU/Zj8LYU=; b=U4Fg+eB6q4Efvy5BXQaEECE8zP/je4IxLcWu8dHeoG5VFfd+rPo4SqbBji/GQbTHra cmJXXHbOSdRJdsoarx912TsgcweK1bFumMYEJM+y0OzTN7bwEEyqsyHjrjEeFVa/15oq t/oYxB21gJprfi3KaSOu3ax+Y7EIsT5S1f5Uz/yMHno1reP3sUBW9kVIOI75yRZIUqGx tQrUySsJ/9XwQCqIaAIsZ8nEmsAXQRXo3eKY30+FO9D/qalMdt4AC4kjvoUqzweZZeHn k5F02jEKHSRevU5G0EBVhT0L1Rtl/JaEMniEtAK28ui+wNu6zD+Qb1tuYEtpcIeQkyOV DcdA== Received: by 10.60.20.74 with SMTP id l10mr2199186oee.19.1342627395953; Wed, 18 Jul 2012 09:03:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.20.74 with SMTP id l10mr2199160oee.19.1342627395708; Wed, 18 Jul 2012 09:03:15 -0700 (PDT) Received: by 10.60.171.199 with HTTP; Wed, 18 Jul 2012 09:03:15 -0700 (PDT) In-Reply-To: References: <6250FC21-C3F3-4197-BCBD-038D00E685CC@gmx.net> <50054E31.5040202@cs.tcd.ie> <18C5A02F-B7FD-4486-9D20-769390F937BC@gmx.net> <5005641E.6060700@cs.tcd.ie> <50058735.10001@cs.tcd.ie> Date: Wed, 18 Jul 2012 17:03:15 +0100 Message-ID: From: Ben Laurie To: Chris Palmer Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnN8PRPt3RrO2yoQktYxEtOrUK6XMHUUgN+NBcZgAvsYTUD5t3jeZlynqsuUq6hzCbnt2gxU//MU3QM5M6hg/MsdRKEPlwS0cBvLsFjV9me7KrGU6OVo37+/g0PL6xJU6mR3QCGKnJvDK+JNI5Epe0o119CWUJjMl+YXOyxjZ9PQ4edPPw= Cc: Sam Hartman , IETF Security Area Advisory Group Subject: Re: [saag] JavaScript for authentication 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, 18 Jul 2012 16:02:26 -0000 On 17 July 2012 18:13, Chris Palmer wrote: > I am having a hard time following this discussion, because I can't > imagine how JavaScript crypto will help solve the problems. (I do > believe in and understand the problems Hannes raised, of course.) Can > someone (Hannes?) provide a sketch of an example of what a JavaScript > crypto-based solution to the authentication problem would look like? > And explain how this solution will be better than what is currently > available (or at least what is currently possible)? http://www.browserauth.net/? From hannes.tschofenig@gmx.net Thu Jul 19 01:36: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 9AF0221F8691 for ; Thu, 19 Jul 2012 01:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.207 X-Spam-Level: X-Spam-Status: No, score=-99.207 tagged_above=-999 required=5 tests=[AWL=-3.196, BAYES_00=-2.599, FB_WORD1_END_DOLLAR=3.294, FB_WORD2_END_DOLLAR=3.294, 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 QJpuS4-9Ko0o for ; Thu, 19 Jul 2012 01:36:30 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id A57F821F8685 for ; Thu, 19 Jul 2012 01:36:29 -0700 (PDT) Received: (qmail invoked by alias); 19 Jul 2012 08:37:20 -0000 Received: from unknown (EHLO [10.255.132.240]) [194.251.119.201] by mail.gmx.net (mp034) with SMTP; 19 Jul 2012 10:37:20 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18XpV1YHwgXPVzfcsAdmtWHeOQ3VWDHMuz9KSGjsx mealI0DXMSuyM1 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <201207171523.LAA13455@Sparkle.Rodents-Montreal.ORG> Date: Thu, 19 Jul 2012 11:37:17 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0D99000E-72F6-4915-9A50-F685F213A527@gmx.net> References: <500461C5.7020006@gmail.com> <8CA8896B-D506-4581-8A2E-E223D6EA7584@gmx.net> <50046BD5.30404@gmail.com> <201207161951.PAA05561@Sparkle.Rodents-Montreal.ORG> <86A7D574-9939-4BBC-A095-7BC6C4B95C96@gmx.net> <201207171523.LAA13455@Sparkle.Rodents-Montreal.ORG> To: Mouse X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: saag@ietf.org Subject: Re: [saag] Password Discussion 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, 19 Jul 2012 08:36:30 -0000 Hi On Jul 17, 2012, at 6:23 PM, Mouse wrote: > [top-posting and no-trimming damage repaired manually] >=20 >> The question of trust in downloadable code is orthogonal to the = JavaScript t$ >=20 > "We" do? "Always"? _I_ certainly don't. If _you_ want to turn over > control of your machine to anyone whose website you visit, or anyone > who happens to have cracked the hosting for website you visit, that's > _your_ neck. To quote Ekr from = http://tools.ietf.org/html/draft-ietf-rtcweb-security-03:=20 " Users can safely visit arbitrary web sites and execute scripts provided by those sites. " That's the threat model for the browser environment.=20 That's very different to the threat model for downloading native code.=20= >=20 >> In fact, not downloading the latest code (automatically) increases = your vuln$ >=20 > While downloading it increases your vulnerability to (other) attacks. > (Well, downloading it and running it, but that's true of both.) >=20 > There's also a huge difference between installing an update to an > application from its provider (which is what I assume you're talking > about here) and running more or less arbitrary code offered up by a > webpage you have no relationship to beyond looking at. >=20 > For my purposes, I do applicatino-level updates relatively rarely and > always with human intelligence inserted between "download" and "run". I would love to cite some papers now that confirm that not downloading = patches automatically leads to increased vulnerabilities. I have to search for them.=20 Ciao Hannes >=20 > /~\ 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 From ekr@rtfm.com Thu Jul 19 06:03:02 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 F114521F87D1 for ; Thu, 19 Jul 2012 06:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.84 X-Spam-Level: X-Spam-Status: No, score=-102.84 tagged_above=-999 required=5 tests=[AWL=0.137, 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 VUvudE1XlmZN for ; Thu, 19 Jul 2012 06:03:02 -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 5A8E421F87CA for ; Thu, 19 Jul 2012 06:03:02 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so2126068vcb.31 for ; Thu, 19 Jul 2012 06:03:55 -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:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=BxmHuFp2KPwoprEUlraOwqUPAY5cDnH+KYpEJhS7jHI=; b=OmsIxROceryxlknb3zsky3eJX8NmbRrJ1eqyfiEIoobbAkeFuWPgkOkaX64zr/Wx2i MMhMSLGcm0pToFGtbgH91a7P9HqC9PdCOSr/XepbFKQSyzajEIJnMazw8woZhm+M2Gc0 0vPkRBtuawMBLvaHC45N+I61RSLcSL/p0Vf3Q7NkOaNiMnkUMcgAK57C2cK1+RzCb7xo vQYJLJXAWmEKMfYwvr25xVPfWoW83Ac8x2GOgmYu5IUuoVw642TuWl1mzcdQIly7joiS 82bL2/c+ookvJNvPssIftVT5kNy3PpxdE4OGRWmiM06BhJ4zqScaJ+h0DdW3783C3fbG 2zEg== Received: by 10.220.116.3 with SMTP id k3mr908669vcq.26.1342703034958; Thu, 19 Jul 2012 06:03:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Thu, 19 Jul 2012 06:03:14 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <0D99000E-72F6-4915-9A50-F685F213A527@gmx.net> References: <500461C5.7020006@gmail.com> <8CA8896B-D506-4581-8A2E-E223D6EA7584@gmx.net> <50046BD5.30404@gmail.com> <201207161951.PAA05561@Sparkle.Rodents-Montreal.ORG> <86A7D574-9939-4BBC-A095-7BC6C4B95C96@gmx.net> <201207171523.LAA13455@Sparkle.Rodents-Montreal.ORG> <0D99000E-72F6-4915-9A50-F685F213A527@gmx.net> From: Eric Rescorla Date: Thu, 19 Jul 2012 06:03:14 -0700 Message-ID: To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQljvj8k637XPrqckmv8YPCXqoZnALtl531xBrRum+iHK8Bl7QJ/YfLA0NjRfDwBZIGi/3PF Cc: saag@ietf.org Subject: Re: [saag] Password Discussion 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, 19 Jul 2012 13:03:03 -0000 On Thu, Jul 19, 2012 at 1:37 AM, Hannes Tschofenig wrote: > Hi > > > On Jul 17, 2012, at 6:23 PM, Mouse wrote: > >> [top-posting and no-trimming damage repaired manually] >> >>> The question of trust in downloadable code is orthogonal to the JavaScript t$ >> >> "We" do? "Always"? _I_ certainly don't. If _you_ want to turn over >> control of your machine to anyone whose website you visit, or anyone >> who happens to have cracked the hosting for website you visit, that's >> _your_ neck. > > To quote Ekr from http://tools.ietf.org/html/draft-ietf-rtcweb-security-03: > > " > Users can safely visit arbitrary web sites and execute scripts > provided by those sites. > " > > That's the threat model for the browser environment. > > That's very different to the threat model for downloading native code. In fairness, I think that Mouse is arguing that browsers don't deliver on that guarantee... -Ekr From stephen.farrell@cs.tcd.ie Thu Jul 19 06:10:48 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 9481821F87BC for ; Thu, 19 Jul 2012 06:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdonnOzMyYCd for ; Thu, 19 Jul 2012 06:10:47 -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 BED1821F87B9 for ; Thu, 19 Jul 2012 06:10:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 8483717189F; Thu, 19 Jul 2012 14:11:40 +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=1342703500; bh=fFW3taq1t25X7f EQwUlQUGmpopL9oFxjhzywYIuAUJw=; b=JcSlQtlljPF4PwzENzKGm5U2vnhDxT yrHPhFwMgGARPa6iTDLnKrZeabXkB+HDTe3CfHCneadTyiuhXL9E6NSPKCUyjg4r KN/vHnkPQyPDYlj50Q5gQ7jFwhbUdmViq1AOPRmpSFSg5MsmkBWdgdb6n8A91zlX lwH7HzlTkTssij56UGxFlqWjYNNWA7nS2PR9MnEyAaj6q9sKAl8LExBvfwebESDw K07WgOnCnPjepMtQ76wrjLW8JqrGd2NsZaBjflbSZ8Voq+SNfcNFx2auS7oeHxUe GcYmq37EnGQdDVJC268MKz7ULaNiGaSdIVu7DidxGIJ/VSslnFk2Jglw== 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 zvfgunR6wgFi; Thu, 19 Jul 2012 14:11:40 +0100 (IST) Received: from [10.87.48.11] (unknown [86.45.48.236]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 083B517147B; Thu, 19 Jul 2012 14:11:37 +0100 (IST) Message-ID: <50080789.80705@cs.tcd.ie> Date: Thu, 19 Jul 2012 14:11:37 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Derek Atkins References: <6250FC21-C3F3-4197-BCBD-038D00E685CC@gmx.net> <50054E31.5040202@cs.tcd.ie> <18C5A02F-B7FD-4486-9D20-769390F937BC@gmx.net> <5005641E.6060700@cs.tcd.ie> <50058735.10001@cs.tcd.ie> <5005C53B.2060100@cs.tcd.ie> <5005DF6F.8070904@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF Security Area Advisory Group Subject: Re: [saag] JavaScript for authentication 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, 19 Jul 2012 13:10:48 -0000 On 07/18/2012 02:52 PM, Derek Atkins wrote: > Stephen Farrell writes: > >> On 07/17/2012 10:13 PM, Eric Rescorla wrote: >>> On Tue, Jul 17, 2012 at 1:04 PM, Stephen Farrell >>> wrote: >>>> >>>> >>>> On 07/17/2012 07:27 PM, Sam Hartman wrote: >>>>> In the RAI area we have been working on SIP for a long, long time and standardized extensions like hell. That took a long time and didn't actually lead to great interoperability (for various reasons, as Jonathan Rosenberg described quite nicely at the Prague IAB technical plenary, see http://www.ietf.org/proceedings/80/slides/plenaryt-5.pdf). >>>> >>>> Yeah. Now that was ironic. >>>> >>>> So, ok, its about site-controlled as Sam nicely put it. >>>> >>>> I guess that brings us back to Chris' question as to how >>>> that might be done securely. >>> >>> I'm not sure that "that" is that well-defined. What do you believe the >>> problem statement is here? >> >> Its obviously the inverse of the threat model:-) > > ... which is? Sorry, mine was just a flippant take on the "ask for problem statement"/"ask for threat model" way in which we mess with folks' heads sometimes. > > (Yes, I'm being rhetorical here, but I think we do need to be explicit > about what the threat model is in order to have an explicit problem > statement) > > There are obvious benefits to a site-controlled approach. There are > also obvious benefits to a platform-controlled approach. The benefits > of each are somewhat different, and the drawbacks to each are > different. Are they necessarily disjoint? I'd be interested in that analysis too but won't have time to do it myself. S. > >> S > > -derek > From hannes.tschofenig@gmx.net Thu Jul 19 06:52: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 8D5E921F8722 for ; Thu, 19 Jul 2012 06:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.617 X-Spam-Level: X-Spam-Status: No, score=-102.617 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Vpg-2sYlOaD for ; Thu, 19 Jul 2012 06:52:28 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 15CC521F8709 for ; Thu, 19 Jul 2012 06:52:27 -0700 (PDT) Received: (qmail invoked by alias); 19 Jul 2012 13:53:16 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.102]) [88.115.216.191] by mail.gmx.net (mp036) with SMTP; 19 Jul 2012 15:53:16 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+Iq85XmzKIm45dGZmQCqWi6XM9mF4FgjkgxKtBz4 JrLsW2Si10mr3Z Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Thu, 19 Jul 2012 16:53:13 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <500461C5.7020006@gmail.com> <8CA8896B-D506-4581-8A2E-E223D6EA7584@gmx.net> <50046BD5.30404@gmail.com> <201207161951.PAA05561@Sparkle.Rodents-Montreal.ORG> <86A7D574-9939-4BBC-A095-7BC6C4B95C96@gmx.net> <201207171523.LAA13455@Sparkle.Rodents-Montreal.ORG> <0D99000E-72F6-4915-9A50-F685F213A527@gmx.net> To: Eric Rescorla X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: saag@ietf.org Subject: Re: [saag] Password Discussion 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, 19 Jul 2012 13:52:29 -0000 > In fairness, I think that Mouse is arguing that browsers don't deliver = on > that guarantee... >=20 > -Ekr That's OK.=20 I do not have an overview of what caused security vulnerabilities in = browsers the last few years.=20 I am not sure it is fine to put all browser related aspects in one = bucket, particularly if I think about Flash, and Java vulnerabilities in = comparison to what is happening around JavaScript.=20 From palmer@google.com Thu Jul 19 10:57: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 D940821F84EE for ; Thu, 19 Jul 2012 10:57:54 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YG0sXXkW0a5 for ; Thu, 19 Jul 2012 10:57:53 -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 C349621F84F4 for ; Thu, 19 Jul 2012 10:57:52 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so4327206lbb.31 for ; Thu, 19 Jul 2012 10:58:40 -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=msObqOcbe9sVF8k6WiIz7s1beNXH9OJNpTa0HGt/ohk=; b=EDfgWtPMwTdSrQEwew+pDkZa5jrw/+zpcvxa7RsH7q2m61Zf0G9acAeFwKxIDIlShq SyflbyTnqcgLhzkCOzD9SSJknUA2AYqiDkdB4LetMoma36eRukvw45S1jcw2Gb2Wn558 K5hI80HORokjq+APTZwWtmPLpEk03i1stDfFVJykZ0NbHumBeA8JvzJKxOYZ4Kp07n0S a/WNi4fT2S/rHtseSad4i3z6BXZsnMpl/mGCpqSZ5DjQ8L9j9GGLDwN4/ucPgELjpttl NRyGUQw82oOsSD8C/TWizoy5ZTxeRQhyftjreJmyG12KBXrU0NO1jKvdB5Y4A/gFimJt OvBA== 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=msObqOcbe9sVF8k6WiIz7s1beNXH9OJNpTa0HGt/ohk=; b=I7EuMfKAVJiJZELm8gLqvTdkvQclM/TlGyJ9CUefiifa1L3eGLky6FQLshKaHgtzhY /JwkEJqDf4do0ikDuldsHRJgrfSNe7fP/MSwr4vd4gUMD79hm74HTGaMFlmw6naX5OvM ZmHgQ7ptOljJBUCgvUMkk+00wEzbzOk51VNMvwcizCaesxCJ0gB8YorIQTXsL8xlUjai caxq9fExF5Q/AA83P4W6/IPmnIt406FqJ619HllKm4xwz8zLmMPMfJ01Om6slDAN3By9 9yhJwGPdj3y5nnkY54ZFf7bZEgVGN2krVY5mzsP1KbZHkiSrQh3JXJJLBF5MwFTeyubG zKxQ== Received: by 10.112.28.137 with SMTP id b9mr1560692lbh.99.1342720720631; Thu, 19 Jul 2012 10:58:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.28.137 with SMTP id b9mr1560679lbh.99.1342720720401; Thu, 19 Jul 2012 10:58:40 -0700 (PDT) Received: by 10.112.12.149 with HTTP; Thu, 19 Jul 2012 10:58:40 -0700 (PDT) In-Reply-To: <0D99000E-72F6-4915-9A50-F685F213A527@gmx.net> References: <500461C5.7020006@gmail.com> <8CA8896B-D506-4581-8A2E-E223D6EA7584@gmx.net> <50046BD5.30404@gmail.com> <201207161951.PAA05561@Sparkle.Rodents-Montreal.ORG> <86A7D574-9939-4BBC-A095-7BC6C4B95C96@gmx.net> <201207171523.LAA13455@Sparkle.Rodents-Montreal.ORG> <0D99000E-72F6-4915-9A50-F685F213A527@gmx.net> Date: Thu, 19 Jul 2012 10:58:40 -0700 Message-ID: From: Chris Palmer To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnShWeKx3eROJSX5N4LODWW44+3ypuUf4qoWptQ4YkDAZX3AFk/FUnLYFW6vgEeGMHh7qJ4BldS0lYv3qKlRZblG/A0vS2LRxijrNO7nvL5Jg8FimtZovFrxJ5zauGb5JsBpnYopB5v8qmX6xFgZmNO/WykPn+4cIqFFAQi7nCXO1R+Mu4= Cc: saag@ietf.org Subject: Re: [saag] Password Discussion 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, 19 Jul 2012 17:57:55 -0000 On Thu, Jul 19, 2012 at 1:37 AM, Hannes Tschofenig wrote: > I would love to cite some papers now that confirm that not downloading patches automatically leads to increased vulnerabilities. > I have to search for them. http://www.techzoom.net/publications/silent-updates/ Although Eric is right that we don't always deliver on the guarantee, the only way we can even begin to is in the latest stable version. :) From palmer@google.com Thu Jul 19 11:05: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 B736E21F86AB for ; Thu, 19 Jul 2012 11:05:25 -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 FWehtnGT4i8t for ; Thu, 19 Jul 2012 11:05:24 -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 8069E21F864F for ; Thu, 19 Jul 2012 11:05:24 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so4335469lbb.31 for ; Thu, 19 Jul 2012 11:06:17 -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=3+k+ux394ZLdHOFFO/hdVXU5g9hw/YJq3Zh44mwMki4=; b=Nd71YSbO0QyYzh4bkHQGtEAyFQGeUiIXws8rs9lgpnlEH6tR77EppEufXbzhcIBgq2 uZy5bIZ/0eXIAnkfN7551MJUF5O5qAdu1LbgkvsG6YIWzbHqEBcJqB4bqPYzxXuFkhm1 wKQgPQx8JGEtxhXZtO82fo0tI0UaGIOyRj4gp87WxaIuLTD29NCvIwmnoB5au7YMPr+m 1zkjJTgI2iJLBzWDulKlJFk8pf7sytqzIpgsljQDs0KeK9GVwhDIVHPZPZsoRzszIn+u 2Zip+nJ9FY6zhBBFz5alupU6TymBBOSBofO8CCNFx/f3sFj+K993TlGrW1DZOwXsjlNs O86w== 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=3+k+ux394ZLdHOFFO/hdVXU5g9hw/YJq3Zh44mwMki4=; b=awkXqeRDAFQiX6jDS9Ih309A5uNNWf8bL5uZNjxQ4/26A5w9DA1mm9NESiseDXlYkw kWiIXxPiMhw+ab0w1rlc8dBnqu3VLQKuPHQxdn27eP2YJLjpNhIa4Arqch5BcmV/c98M iRBzqJxpoBORXwhfbEbcgpD+TxCzHMVnL0UZkhf7xxPpc7BRuO+oGeIqqio/6mIOu5sU vl4N9EwsM52wRBvRg2CLQ12mvNK/sUug6HJrGq/iEFftULKkTMmGPyrHIBbLg4UBVBLo ZXRSTCvpgU/ivGw+/YCe43PtB2Ge1h651HuJY/VKHoZm1fpvx1mBhHWeU7QpIor7edtM 1eiQ== Received: by 10.112.84.168 with SMTP id a8mr1601472lbz.92.1342721177238; Thu, 19 Jul 2012 11:06:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.84.168 with SMTP id a8mr1601461lbz.92.1342721177101; Thu, 19 Jul 2012 11:06:17 -0700 (PDT) Received: by 10.112.12.149 with HTTP; Thu, 19 Jul 2012 11:06:17 -0700 (PDT) In-Reply-To: References: <500461C5.7020006@gmail.com> <8CA8896B-D506-4581-8A2E-E223D6EA7584@gmx.net> <50046BD5.30404@gmail.com> <201207161951.PAA05561@Sparkle.Rodents-Montreal.ORG> <86A7D574-9939-4BBC-A095-7BC6C4B95C96@gmx.net> <201207171523.LAA13455@Sparkle.Rodents-Montreal.ORG> <0D99000E-72F6-4915-9A50-F685F213A527@gmx.net> Date: Thu, 19 Jul 2012 11:06:17 -0700 Message-ID: From: Chris Palmer To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkQf/D4oF+wfKpNCDkwVNUU4h/AbhnlPtajTlTXkWQqXKI0wzHvpaWwZKpdQufVF2072/vyV63ROFFOE5ZX8+lX7NQrTqfYysDdaMRTttVTo6X7zxtqOqPCvvz48XUmo3Vjba6wzqybjPw+QeMerE0MG+Wpni04UpmdBPkKftZMlYibnaM= Cc: saag@ietf.org Subject: Re: [saag] Password Discussion 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, 19 Jul 2012 18:05:25 -0000 On Thu, Jul 19, 2012 at 6:53 AM, Hannes Tschofenig wrote: > I do not have an overview of what caused security vulnerabilities in browsers the last few years. Here are two examples: http://blog.chromium.org/2012/05/tale-of-two-pwnies-part-1.html http://blog.chromium.org/2012/06/tale-of-two-pwnies-part-2.html We consider the sophistication and difficulty of these exploits to be a good sign. From mouse@Sparkle.Rodents-Montreal.ORG Mon Jul 23 09:21:27 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 E52C511E80A1 for ; Mon, 23 Jul 2012 09:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.833 X-Spam-Level: X-Spam-Status: No, score=-7.833 tagged_above=-999 required=5 tests=[AWL=-0.445, BAYES_50=0.001, HELO_MISMATCH_ORG=0.611, 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 EpRbtXQ8Y84S for ; Mon, 23 Jul 2012 09:21:27 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id 828C511E808D for ; Mon, 23 Jul 2012 09:21:26 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id MAA00174; Mon, 23 Jul 2012 12:21:24 -0400 (EDT) Date: Mon, 23 Jul 2012 12:21:24 -0400 (EDT) From: Mouse Message-Id: <201207231621.MAA00174@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: Mon, 23 Jul 2012 12:12:50 -0400 (EDT) To: saag@ietf.org In-Reply-To: <0D99000E-72F6-4915-9A50-F685F213A527@gmx.net> References: <500461C5.7020006@gmail.com> <8CA8896B-D506-4581-8A2E-E223D6EA7584@gmx.net> <50046BD5.30404@gmail.com> <201207161951.PAA05561@Sparkle.Rodents-Montreal.ORG> <86A7D574-9939-4BBC-A095-7BC6C4B95C96@gmx.net> <201207171523.LAA13455@Sparkle.Rodents-Montreal.ORG> <0D99000E-72F6-4915-9A50-F685F213A527@gmx.net> Subject: Re: [saag] Password Discussion 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, 23 Jul 2012 16:21:28 -0000 > " > Users can safely visit arbitrary web sites and execute scripts > provided by those sites. > " > That's the threat model for the browser environment. > That's very different to the threat model for downloading native > code. It is. I fear it also is living in a fantasy land. It's easy to achieve by weakening the language used by the scripts in question, but there is a constant tension between script authors, who want a powerful language, and security, which wants a weak language. So far, security has been the loser in that fight, and, as long as it continues to be, I don't expect the above ideal to become reality. /~\ 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 turners@ieca.com Mon Jul 23 21:20: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 77A1411E8108 for ; Mon, 23 Jul 2012 21:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.342 X-Spam-Level: X-Spam-Status: No, score=-102.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTEviA4ISzHR for ; Mon, 23 Jul 2012 21:20:54 -0700 (PDT) Received: from gateway11.websitewelcome.com (gateway11.websitewelcome.com [64.5.52.14]) by ietfa.amsl.com (Postfix) with ESMTP id D31D321F84D6 for ; Mon, 23 Jul 2012 21:20:53 -0700 (PDT) Received: by gateway11.websitewelcome.com (Postfix, from userid 5011) id CB52DC111B747; Mon, 23 Jul 2012 23:20:53 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway11.websitewelcome.com (Postfix) with ESMTP id BDDB4C111B725 for ; Mon, 23 Jul 2012 23:20:53 -0500 (CDT) Received: from [71.191.15.186] (port=34883 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1StWc9-0002f2-3X for saag@ietf.org; Mon, 23 Jul 2012 23:20:53 -0500 Message-ID: <500E22A4.6090200@ieca.com> Date: Tue, 24 Jul 2012 00:20:52 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: saag@ietf.org References: <078c01cd68ef$b35643e0$1a02cba0$@iab.org> In-Reply-To: <078c01cd68ef$b35643e0$1a02cba0$@iab.org> X-Forwarded-Message-Id: <078c01cd68ef$b35643e0$1a02cba0$@iab.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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) [71.191.15.186]:34883 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [saag] Fwd: IAB IPv6 privacy survey posted, response requested 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, 24 Jul 2012 04:20:54 -0000 In case you're not on the announce list. spt -------- Original Message -------- Subject: IAB IPv6 privacy survey posted, response requested Date: Mon, 23 Jul 2012 09:24:56 -0700 From: IAB Chair Reply-To: iab@iab.org Organization: Internet Architecture Board To: The IAB is working on ‘Privacy Considerations for Internet Protocols’ . In order to better understand the implementation status of IPv6 privacy mechanisms in operating system stacks, those familiar with OS IPv6 implementations are asked tocomplete a short survey . The survey responses will be used in a detailed write-up on IPv6 privacy; privacy reviews of other IETF protocols are available here. Please send responses to iab-ipv6-privacy-survey@i1b.org by August 13, 2012. If you have questions, please send them to iab-ipv6-privacy-survey@i1b.org . From fenton@bluepopcorn.net Mon Jul 23 21:27: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 5BCBC11E810F for ; Mon, 23 Jul 2012 21:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTnGLlFtsRcq for ; Mon, 23 Jul 2012 21:27:58 -0700 (PDT) Received: from kernel.bluepopcorn.net (ipv6.bluepopcorn.net [IPv6:2001:470:1f05:bfe:21a:70ff:fe11:c889]) by ietfa.amsl.com (Postfix) with ESMTP id 918B611E8109 for ; Mon, 23 Jul 2012 21:27:58 -0700 (PDT) Received: from splunge.local ([IPv6:2001:470:1f05:bfe:3e07:54ff:fe42:4ea0]) (authenticated bits=0) by kernel.bluepopcorn.net (8.14.5/8.14.4) with ESMTP id q6O4RoRT007355 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 23 Jul 2012 21:27:50 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=buttered; t=1343104071; bh=rUad2rdwT8xYcK/2sERevAMXXBTi3q7NDBuc+rs9sA8=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=inrN5RAjzh+cOvgvzItmT9fDY0iYQtLBfZodu5jvWQR1Tthgz4GBvD8+yVLJkIuyC G05v7NFZ1JjKRLsfSTmqBLN1Nf8gLRIAAleGG5W+zNpv+cb0fKEhd1DAeY14b2d Message-ID: <500E2446.5050401@bluepopcorn.net> Date: Mon, 23 Jul 2012 21:27:50 -0700 From: Jim Fenton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Chris Palmer References: <6250FC21-C3F3-4197-BCBD-038D00E685CC@gmx.net> <50054E31.5040202@cs.tcd.ie> <18C5A02F-B7FD-4486-9D20-769390F937BC@gmx.net> <5005641E.6060700@cs.tcd.ie> <50058735.10001@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Sam Hartman , IETF Security Area Advisory Group Subject: Re: [saag] JavaScript for authentication 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, 24 Jul 2012 04:27:59 -0000 Sorry for jumping in late; I was on vacation... On 7/17/12 10:13 AM, Chris Palmer wrote: > I am having a hard time following this discussion, because I can't > imagine how JavaScript crypto will help solve the problems. (I do > believe in and understand the problems Hannes raised, of course.) Can > someone (Hannes?) provide a sketch of an example of what a JavaScript > crypto-based solution to the authentication problem would look like? > And explain how this solution will be better than what is currently > available (or at least what is currently possible)? > > For example, say a server delivers a blob of JS to the client. > Transmission is over TLS, of course (otherwise, the blob contains code > written by the attacker). The blob uses the browser's support for the > JS crypto APIs to query the browser's database of public/private key > pairs for the server's origin (creating a new pair if none exists, and > registering the public key with the server). Then the JS code proves > to the server that the client has ownership of the private key, thus > authenticating the user transparently and without having to store any > sensitive data (like a poorly hashed password) on the server. Yay! That's a simplified version of what we do for authentication at OneID. It seems to work pretty well, even with existing JavaScript capabilities and using local storage for keys and such. > > But, couldn't we get pretty much the same thing client certificates, > possibly with TLS-OBC or some other scheme? Is it better than TLS-SRP? One way I look at it is that a more device-centric authentication scheme needs to have a really responsive key revocation model. Yes, that can be done with certificates but another way is for the JavaScript to be authenticating in conjunction with (using the term loosely) an IdP that can confirm validity of the endpoint in real time. JavaScript also gives us the opportunity to encrypt and decrypt user attributes at the endpoint, making the "IdP" virtually free of sensitive data in the clear. > > And then there are all the problems — dealbreakers, AFAICT — raised by > Ptacek and Lawson. Can you give a more specific citation to these? But one the subject of problems, one of the trickier ones is to ensure the user is running authentic JavaScript. Getting the code via TLS is a must, of course, but makes the server(s) sourcing the code a very attractive attack target. -Jim From palmer@google.com Tue Jul 24 11:14: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 85E7411E8096 for ; Tue, 24 Jul 2012 11:14: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXovGJ9uehuq for ; Tue, 24 Jul 2012 11:14:07 -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 C15B011E8091 for ; Tue, 24 Jul 2012 11:14:06 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so10131808lbb.31 for ; Tue, 24 Jul 2012 11:14:05 -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=etVv0CumAMvbfxuNx2YKm47c+EW42b9hCjEYPr78SeE=; b=JcOkd2NVTOMf19lJe/bqOaPpREG/DXgOhP8N3r0b9IL5aGPyAz4Kb+g0glj4N7fCQX Hg0+ExNPFMxg5UCQABVK79N8Konxd7JlbUq88bG9zAAWJV62gvOF2tfRTyyEee+YsETR TNDNpbS9ke/LYsfh5Zqj/bWZBdfFvGInQjKdbNq3yvfYQje0YjVrT1Vv+d3tjFyO3F69 VqcbtszU4i5P6y6w56anBPVa2qYDOK/juLOwjH1rDEquFhDTUpuZkfEu/a9D7FV6NhqP kzxhEDq/up4XE8KR9MpwYkFLSP7xvfcFwpz/iW4eElcairTwGdVCoNpEyRWL1RLtGuoi i60w== 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=etVv0CumAMvbfxuNx2YKm47c+EW42b9hCjEYPr78SeE=; b=jPwTRalYvRZDCV1VNIhJHYZrk6dggv1fgNZdOg3P+7IN4AR6qFrF1EDRzFxYVT/EVb dOI06xwV+e76horkLdabWDDDF+5sUCXeDbIhx9LeChIru4sKAr2QKfypAJ1EG388L+D0 eeGDztZ0rh4fdjYr/8RR4Ywlx6PNeb+jlq7B/vRZyxXDGs3jASUTTct8Ou2JcJ2io4Sy Nqpj2fjV3NpRWJp4QW782Dgq//AhBcXrYSEq4Q28E8uvJLROf2cftN2NvSR2s9eh1qp5 ZsULrjGGdyTslvyOkQjc9ceOhXWN6SCh98M065GNHa22ADooZMsi6KnpZ2SaapUfkw1A /82A== Received: by 10.152.146.169 with SMTP id td9mr22382000lab.42.1343153645602; Tue, 24 Jul 2012 11:14:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.146.169 with SMTP id td9mr22381987lab.42.1343153645415; Tue, 24 Jul 2012 11:14:05 -0700 (PDT) Received: by 10.112.12.149 with HTTP; Tue, 24 Jul 2012 11:14:05 -0700 (PDT) In-Reply-To: <500E2446.5050401@bluepopcorn.net> References: <6250FC21-C3F3-4197-BCBD-038D00E685CC@gmx.net> <50054E31.5040202@cs.tcd.ie> <18C5A02F-B7FD-4486-9D20-769390F937BC@gmx.net> <5005641E.6060700@cs.tcd.ie> <50058735.10001@cs.tcd.ie> <500E2446.5050401@bluepopcorn.net> Date: Tue, 24 Jul 2012 11:14:05 -0700 Message-ID: From: Chris Palmer To: Jim Fenton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQkWabGYKZHWIQlso3l84FB/HAsqncHHk5kDOwZVr2NmSritCFm+gMZOO207e5yD7HfjSFf7LGNRFELvZM51BAynFK0MODiZBEnT7QXU8ZubTL64ZUQkOAvXSWwe5+MTrOcd0NXIUXU/uBvwwK+iDgWWM7HdBvcsvnVsfTPYIDCTggf3Dc8= Cc: Sam Hartman , IETF Security Area Advisory Group Subject: Re: [saag] JavaScript for authentication 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, 24 Jul 2012 18:14:08 -0000 On Mon, Jul 23, 2012 at 9:27 PM, Jim Fenton wrote: >> But, couldn't we get pretty much the same thing client certificates, >> possibly with TLS-OBC or some other scheme? Is it better than TLS-SRP? > > One way I look at it is that a more device-centric authentication scheme > needs to have a really responsive key revocation model. Yes, that can > be done with certificates but another way is for the JavaScript to be > authenticating in conjunction with (using the term loosely) an IdP that > can confirm validity of the endpoint in real time. JavaScript also gives > us the opportunity to encrypt and decrypt user attributes at the > endpoint, making the "IdP" virtually free of sensitive data in the clear. When the credentials are asymmetric keypairs, credential liveness checking is possible without the liveness checker needing to have any sensitive data in the clear. (See e.g. OCSP.) So I still don't see how JavaScript crypto is strictly better than some alternatives. >> And then there are all the problems =E2=80=94 dealbreakers, AFAICT =E2= =80=94 raised by >> Ptacek and Lawson. > > Can you give a more specific citation to these? http://www.matasano.com/articles/javascript-cryptography/ http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/ > But one the subject of problems, one of the trickier ones is to ensure > the user is running authentic JavaScript. Getting the code via TLS is a > must, of course, but makes the server(s) sourcing the code a very > attractive attack target. Web servers hosting important applications are always attractive targets. Using TLS does not necessarily make them more attractive. From fenton@bluepopcorn.net Tue Jul 24 17:39: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 8651F11E809B for ; Tue, 24 Jul 2012 17:39:22 -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 rCV8s6kph0Nl for ; Tue, 24 Jul 2012 17:39:18 -0700 (PDT) Received: from kernel.bluepopcorn.net (ipv6.bluepopcorn.net [IPv6:2001:470:1f05:bfe:21a:70ff:fe11:c889]) by ietfa.amsl.com (Postfix) with ESMTP id 76C4A11E8088 for ; Tue, 24 Jul 2012 17:39:18 -0700 (PDT) Received: from splunge.local (70-90-161-117-ca.sfba.hfc.comcastbusiness.net [70.90.161.117]) (authenticated bits=0) by kernel.bluepopcorn.net (8.14.5/8.14.4) with ESMTP id q6P0d8xV012979 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 24 Jul 2012 17:39:09 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=buttered; t=1343176750; bh=kkVFMzsmaTtlNCaV4vncI6cuYceIkCXbHYUin3seXrI=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ZKmiIpBtiVGlBC6muFd294szoFnabrBzt5IMy1ByCJANZNq8GQDSxx+JEYGCc9ZwH q/+cAQ37NCBhfssgrVXVal08HBv08otMnstyPbUL5bHkkjc5ZBBZLjqChvLip0O Message-ID: <500F402C.6080508@bluepopcorn.net> Date: Tue, 24 Jul 2012 17:39:08 -0700 From: Jim Fenton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Chris Palmer References: <6250FC21-C3F3-4197-BCBD-038D00E685CC@gmx.net> <50054E31.5040202@cs.tcd.ie> <18C5A02F-B7FD-4486-9D20-769390F937BC@gmx.net> <5005641E.6060700@cs.tcd.ie> <50058735.10001@cs.tcd.ie> <500E2446.5050401@bluepopcorn.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF Security Area Advisory Group Subject: Re: [saag] JavaScript for authentication 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, 25 Jul 2012 00:39:22 -0000 On 7/24/12 11:14 AM, Chris Palmer wrote: >> On Mon, Jul 23, 2012 at 9:27 PM, Jim Fenton wrote: >> But one the subject of problems, one of the trickier ones is to ensure >> the user is running authentic JavaScript. Getting the code via TLS is a >> must, of course, but makes the server(s) sourcing the code a very >> attractive attack target. > > Web servers hosting important applications are always attractive > targets. Using TLS does not necessarily make them more attractive. Yes, of course. I didn't mean to say it quite that way. Thanks for the citations. -Jim From stephen.farrell@cs.tcd.ie Wed Jul 25 10:22: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 A554B21F86B8 for ; Wed, 25 Jul 2012 10:22:18 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id newUIN+fp9DF for ; Wed, 25 Jul 2012 10:22:17 -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 5CC9A21F86B2 for ; Wed, 25 Jul 2012 10:22:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 5333617180A for ; Wed, 25 Jul 2012 18:22:16 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-type:in-reply-to:references:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1343236935; bh=jCfVL+oSlgpvLpo4xOvx2vTw ZlqIMNWLz+5sEk9nhN8=; b=L9hbI/gg01yYo8GQBUBDvBS9dF21/mMeGjcDKniu R7dRt8HEbRwreg8LzJPZ++wmOcAkF/tcNJESLaHZALwiiFaZ6WtCG3M0heE0diKh 6Ve91UIdOY1ETw68FL8cPdaM9DiOK5nlECg6NHd0AnbSI+fEl/O9lwrliOlh59T6 ybD5+0ZEiphzNPVe0FlA8+kskYpHCI12MIqgE5kW+JhfzNHaaRyjCUwgZ4pvdmVL +rYVivTeBvyOiEKiE5FKLlvtIeN6wz1HxbOj6zAq1W4WshBRIjgCzLDCvt+LEfjT 1zWhQ6daHIGTmKp1PWxlYl49XF8dU4/xc4M/P7nzqDnTfw== 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 flCdpeTl8ucZ for ; Wed, 25 Jul 2012 18:22:15 +0100 (IST) Received: from [128.107.30.64] (unknown [128.107.30.64]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 468D0171809 for ; Wed, 25 Jul 2012 18:22:15 +0100 (IST) Message-ID: <50102B46.2000409@cs.tcd.ie> Date: Wed, 25 Jul 2012 18:22:14 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "saag@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.4.3 X-Forwarded-Message-Id: Content-Type: multipart/mixed; boundary="------------070009040900080000050602" Subject: [saag] Fwd: [ietf-privacy] Bar BoF at IETF 84: Media without censorship (CensorFree) 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, 25 Jul 2012 17:22:18 -0000 This is a multi-part message in MIME format. --------------070009040900080000050602 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI, might be of interest. S -------- Original Message -------- Subject: [ietf-privacy] Bar BoF at IETF 84: Media without censorship (CensorFree) Date: Mon, 23 Jul 2012 19:35:36 +0200 From: Johan Pouwelse To: ietf-privacy@ietf.org Dear All, At the upcoming IETF meeting I'm trying to organize a bar BoF around enhancing privacy and reducing censorship. Hopefully people on this mailinglist are interested in these matters, could help improve the discussion document or can even attend this Bar BoF in person. Bar BoF name: Media without censorship (CensorFree) Location: IETF 84, Vancouver, Canada Date: 1st Aug 2012, 20:00 (Wednesday) Room: to be announced Discussion doc: https://datatracker.ietf.org/doc/draft-pouwelse-censorfree-scenarios/ Bar BoF status: approved by Transport area directors (see CC:) Technology status: initial running code Abstract: This document describes some scenarios in which one can imagine that the ability of authoritarian regime to censor news dissemination is reduced. It tries to draw some conclusions about what's desirable and what's not acceptable for users in those scenarios. The CensorFree objective is to standardize the protocols for microblogging on smartphones with a focus on security and censorship resistance. Microblog entries are short text messages, possibly enriched with pictures or streaming video. The goal is to devise protocols which guard against all known forms of censorship such as: cyberspace sabotage, digital eavesdropping, infiltration, fraud, Internet kill switches and lawyer-based attacks with the best known protective methods. The discussion document lists some scenarios, but is still very much a work in progress. Hopefully the knowledge from draft-iab-privacy-considerations-03 and draft-iab-privacy-terminology-01 can be included in this doc real soon. Please reply if you are interested in these matters or have ideas on this direction. -Johan Pouwelse, Delft University of Technology --------------070009040900080000050602 Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy --------------070009040900080000050602-- From rbarnes@bbn.com Mon Jul 30 13:10: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 5AB3711E80A2 for ; Mon, 30 Jul 2012 13:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.458 X-Spam-Level: X-Spam-Status: No, score=-106.458 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, GB_I_LETTER=-2, MANGLED_LOAN=2.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUW+UrA6lU+Q for ; Mon, 30 Jul 2012 13:10:33 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 154CC11E8072 for ; Mon, 30 Jul 2012 13:10:33 -0700 (PDT) Received: from [128.89.254.139] (port=54540) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SvwIP-000BzL-Hz; Mon, 30 Jul 2012 16:10:29 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=utf-8 From: "Richard L. Barnes" In-Reply-To: Date: Mon, 30 Jul 2012 13:10:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <02CB01C6-835D-4C01-B9B7-8D4F525ADCBC@bbn.com> References: To: Hannes Tschofenig X-Mailer: Apple Mail (2.1278) Cc: saag@ietf.org Subject: Re: [saag] Password Discussion 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, 30 Jul 2012 20:10:35 -0000 Just to round out this thread, a literary contribution from McSweeney's = Internet Tendency. = YOUR PASSWORD MUST CONTAIN THE FOLLOWING. BY ERIC K. AULD - - - - 1. A capital letter. 2. A number. 3. One of the following symbols: = !@#$%^*()<>?=E2=88=91=C2=A9=CF=A0=D0=94=CF=AA=D0=A9=D1=9E=D3=B9=D4=8A=E0=B8= =BF=E2=8C=82=E2=86=A8&. 4. Your favorite color. 5. Your favorite brand of gin. 6. The exact date/time of your first blood clot. 7. Three distinctly different recipes for lemon basil chicken. 8. A 2000-word essay on your opinion of Pluto=E2=80=99s non-planetary = status. 9. That joke=E2=80=94you know, the one with the guy in the raincoat. 10. An mp3 of you humming Wagner=E2=80=99s Ride of the Valkyries in the = shower. 11. Your perfect Sunday. 12. A Petrarchan sonnet on the loss of your virginity. 13. One of your kidneys. 14. Your favorite polygon (and why). 15. Your best Stephen Wright impression. 16. An anecdote of that time you asked Julie Hanson out and forgot your = own name. You got drunk on Smirnoff and almost fell out the window, then = we carried you into the elevator and left you there, and you woke up and = your sideburns were gone. You remember that? Man, those were the days. 17. The original battle plans for the invasion of Normandy. 18. Your favorite Brady Bunch child. 19. A modern-day American-English translation of the Epic of Gilgamesh. 20. A lowercase letter. On Jul 16, 2012, at 11:15 AM, Hannes Tschofenig wrote: > Hi all,=20 >=20 > given the longer discussion related to passwords I thought it makes = sense to point you to a document we had written about various problems = related to Web security:=20 > http://tools.ietf.org/html/draft-tschofenig-secure-the-web-03 >=20 > Ciao > Hannes >=20 > PS: I case you want to hear my view on standardizing a new = authentication mechanism (whatever it might be) or even an entire = authentication framework then I have to say that we have to take the = recent developments in the W3C into consideration and the work on the = JavaScript CryptoAPI looks very promising to me. With it an identity = provider can write their favorite authentication protocol and send it to = the browser. No need for standardizing a new authentication protocol = anymore nor a framework either. JavaScript is the framework.... >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag