From stephen.farrell@cs.tcd.ie Mon Dec 2 07:41:03 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 898381AC7F1 for ; Mon, 2 Dec 2013 07:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoIhx6EfZBmk for ; Mon, 2 Dec 2013 07:41:02 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4D91A1F62 for ; Mon, 2 Dec 2013 07:41:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6AF5EBE68 for ; Mon, 2 Dec 2013 15:40:59 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOkjg4royP2y for ; Mon, 2 Dec 2013 15:40:59 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1BA1ABE57 for ; Mon, 2 Dec 2013 15:40:59 +0000 (GMT) Message-ID: <529CAA0C.4020203@cs.tcd.ie> Date: Mon, 02 Dec 2013 15:41:00 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "saag@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [saag] SAAG session draft minutes from Vancouver X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 15:41:03 -0000 Hi all, Thanks to Peter Yee for taking notes. I've posted the draft minutes [1] for the saag session. Please send comments/corrections to Sean and I, Thanks, S. [1] http://www.ietf.org/proceedings/88/minutes/minutes-88-saag From housley@vigilsec.com Wed Dec 4 02:41:58 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B040E1AE253 for ; Wed, 4 Dec 2013 02:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xm2AoR90lcMo for ; Wed, 4 Dec 2013 02:41:52 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id E6C151AE0ED for ; Wed, 4 Dec 2013 02:41:26 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id DFA2EF24092 for ; Wed, 4 Dec 2013 05:41:13 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id sGhBZu01-JNR for ; Wed, 4 Dec 2013 05:40:52 -0500 (EST) Received: from v150.vpn.iad.rg.net (v150.vpn.iad.rg.net [198.180.150.150]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 07057F24085 for ; Wed, 4 Dec 2013 05:40:50 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Dec 2013 05:40:33 -0500 Message-Id: <68E9129E-F1A4-4EAB-8E5F-5DA9F3EAE92D@vigilsec.com> To: IETF SAAG Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [saag] RSA-OAEP X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 10:41:58 -0000 We have known for a very long time that PKCS #1 Version 1.5 (see RFC = 2313) key transport is vulnerable to adaptive chosen ciphertext attacks. = Exploitation reveals the result of a particular RSA decryption, = requires access to an oracle which will respond to a hundreds of = thousands of ciphertexts, which are constructed adaptively in response = to previously-received replies providing information on the successes or = failures of attempted decryption operations. As a result, the attack = appears significantly less feasible in store-and-forward environments = than interactive ones. PKCS #1 Version 2.0 and Version 2.1 (see RFC 3447) include RSA-OAEP to = address this situation, but we have seen very little movement toward = RSA-OAEP. While we are reviewing algorithm choices in light of the = pervasive surveillance situation, I think we should take the time to = address known vulnerabilities like this one. If we don't, then we are = leaving an partially open door for a well funded attacker. Russ= From housley@vigilsec.com Wed Dec 4 03:05:46 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0EA1AE232 for ; Wed, 4 Dec 2013 03:05:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6OJ9oxJP7-i for ; Wed, 4 Dec 2013 03:05:44 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 4B14D1AE222 for ; Wed, 4 Dec 2013 03:05:44 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id B8BB2F24092 for ; Wed, 4 Dec 2013 06:05:31 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id dRazMQ0A948S for ; Wed, 4 Dec 2013 06:05:09 -0500 (EST) Received: from v150.vpn.iad.rg.net (v150.vpn.iad.rg.net [198.180.150.150]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 4880EF24085 for ; Wed, 4 Dec 2013 06:05:10 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Dec 2013 06:04:57 -0500 Message-Id: To: IETF SAAG Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [saag] RSA-PSS X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 11:05:46 -0000 We have known for a very long time that PKCS #1 Version 1.5 (see RFC = 2313) signature is more fragile than we might like. PKCS #1 Version 1.5 = signatures were developed in an ad hoc manner; RSASSA-PSS as specified = in PKCS #1 Version 2.1 (see RFC 3447) was developed based on = mathematical foundations. I am aware of two attacks against PKCS #1 Version 1.5 implementations: First, the Bleichenbacher attack against implementations. In this = attack, implementations do not calculate the length of the padding, but = rather scan the 0xff at the beginning until they find a 0x00 byte. = Also, a small RSA exponent (for example e=3D3). Second, fault-based attacks described by Boneh and others. By injecting = random faults into the RSA calculations, the attacker is able to = regenerate the private key from the knowledge of faulty signatures. RSA-PSS offers significant improvement against both of these attacks. We have seen very little movement toward RSA-PSS. While we are = reviewing algorithm choices in light of the pervasive surveillance = situation, I think we should take the time to consider improvements in = our algorithm choices. Russ= From robert@ripe.net Sun Dec 8 07:51:37 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D3E1ADFB8 for ; Sun, 8 Dec 2013 07:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2ShBx_-KuEo for ; Sun, 8 Dec 2013 07:51:36 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 72BC81ADFB6 for ; Sun, 8 Dec 2013 07:51:36 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Vpgdm-0003Tj-AI for saag@ietf.org; Sun, 08 Dec 2013 16:51:31 +0100 Received: from mandrill.ripe.net ([193.0.1.209] helo=[0.0.0.0]) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Vpgdm-0006ql-7h for saag@ietf.org; Sun, 08 Dec 2013 16:51:30 +0100 Message-ID: <52A49582.4070307@ripe.net> Date: Sun, 08 Dec 2013 16:51:30 +0100 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: IETF SAAG X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.0 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.1 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a2746f4d02cdb4d3d37f95aeedad11fb6131 Subject: [saag] New I-D: Password Storage Using Public Key Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 15:51:37 -0000 Hello, As you may have noticed, I created a draft about how and why to add asymmetric encryption to password storage. http://www.ietf.org/mail-archive/web/i-d-announce/current/msg55437.html Please let me know if you have comments or suggestions. Regards, Robert From skyper@thc.org Mon Dec 9 01:38:22 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5136D1ADE86 for ; Mon, 9 Dec 2013 01:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbVJqed48ICd for ; Mon, 9 Dec 2013 01:38:20 -0800 (PST) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 38E001AE092 for ; Mon, 9 Dec 2013 01:38:20 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id at1so5652114iec.33 for ; Mon, 09 Dec 2013 01:38:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GJ7gr3eYTYemjF4En9PdfFIt6/Ro6OHY68zrlk6YNng=; b=OHLux6zlxQrcA+aaleldkrUUbP1yLWuRLMnVD2RN8PaJ6LeaROGa2COQQDqKzSl9eQ hYgp1sxu97smxiX8TMgPmFzn5NYKwClalVyzQZukcUnIucx4KDtvzmgG17Yqh1HhbSu4 GU+b7EWqpvlihSY0YAwJXKAdi5o1h9lXn0k1k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GJ7gr3eYTYemjF4En9PdfFIt6/Ro6OHY68zrlk6YNng=; b=HUjGTlTm7SAAIWNLkqrX3N/DHdwgr+YubZPEVoLjI/rYFvfY5UeaqFJexRodMUs2Sf ErHxYBeEWjMFOCqmdCjTmhK1jVbE/Gy54VaRywtt6KFpHIETkRZ3QN0FWC+/hxFIlnGg vuoW9ToYbLW7xRTk9hYBnvnNhAw18xJAlr1sPtJC3WYg4JzN+0VODiE50j8cgHw9QUSY 1NesBTybZWtGveFPoPrba312m/r7cptO3lJyJimagEhOcVhL1wMnJVRXsysoR8BF3TU1 Ew886R34EKP1lUc2P0H3Gcnmo0Crn5/15+iVXZM7K7vkDSvxwVItjfOr65c+ZRC83hSt h4pg== X-Gm-Message-State: ALoCoQkLgUk+7dhRdagsiHdK9a/70srkNeF+bs7Hwy5zMx56wkiKI+G/8gfGkG66lc7lUeJ2Vsve MIME-Version: 1.0 X-Received: by 10.43.117.131 with SMTP id fm3mr69248365icc.33.1386581895291; Mon, 09 Dec 2013 01:38:15 -0800 (PST) Received: by 10.64.9.41 with HTTP; Mon, 9 Dec 2013 01:38:15 -0800 (PST) X-Originating-IP: [80.195.189.45] In-Reply-To: <52A49582.4070307@ripe.net> References: <52A49582.4070307@ripe.net> Date: Mon, 9 Dec 2013 09:38:15 +0000 Message-ID: From: Ralf Skyper Kaiser To: Robert Kisteleki Content-Type: multipart/alternative; boundary=bcaec517c938523a6404ed16c1b6 Cc: IETF SAAG Subject: Re: [saag] New I-D: Password Storage Using Public Key Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 09:38:22 -0000 --bcaec517c938523a6404ed16c1b6 Content-Type: text/plain; charset=ISO-8859-1 Hi, thanks for the I-D. Interesting idea. It solves some (but not all) problems of password authentication. I have some questions about the advantages of your I-D compared to the current work around that you mention: You mention in the I-D that the current work-around is to use multiple rounds of hashes (100x or 1000x). How many hash rounds would be sufficient to make it equally secure compared to your proposal (public key encryption)? (My gut feeling says 10.000 sha512 are more expensive than 1x 2048 rsa encrypt but I do not have figures in front of me. Both algorithms are available in hardware [gpu, verilog, ..]). What is the advantage of your I-D compared to just increasing the hash rounds? regards, ralf On Sun, Dec 8, 2013 at 3:51 PM, Robert Kisteleki wrote: > Hello, > > As you may have noticed, I created a draft about how and why to add > asymmetric encryption to password storage. > > http://www.ietf.org/mail-archive/web/i-d-announce/current/msg55437.html > > Please let me know if you have comments or suggestions. > > Regards, > Robert > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --bcaec517c938523a6404ed16c1b6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

thanks for the I-D. Interes= ting idea. It solves some (but not all) problems of password authentication= . I have some questions about the advantages of your I-D compared to the cu= rrent work around that you mention:

You mention in the I-D that the current work-around is to use multiple = rounds of hashes (100x or 1000x).

How many hash rounds w= ould be sufficient to make it equally secure compared to your proposal (pub= lic key encryption)? (My gut feeling says 10.000 sha512 are more expensive = than 1x 2048 rsa encrypt but I do not have figures in front of me. Both alg= orithms are available in hardware [gpu, verilog, ..]).

What is the advantage of your I-D compared to just increasing the= hash rounds?


regards,

ralf

=


O= n Sun, Dec 8, 2013 at 3:51 PM, Robert Kisteleki <robert@ripe.net> wrote:
Hello,

As you may have noticed, I created a draft about how and why to add
asymmetric encryption to password storage.

http://www.ietf.org/mail-archive/web/i-d-announc= e/current/msg55437.html

Please let me know if you have comments or suggestions.

Regards,
Robert

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

--bcaec517c938523a6404ed16c1b6-- From rlb@ipv.sx Mon Dec 9 08:02:20 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D25E1AE325 for ; Mon, 9 Dec 2013 08:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdChQrm6WSRa for ; Mon, 9 Dec 2013 08:02:18 -0800 (PST) Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) by ietfa.amsl.com (Postfix) with ESMTP id 60CD81AE2A4 for ; Mon, 9 Dec 2013 08:02:18 -0800 (PST) Received: by mail-ob0-f175.google.com with SMTP id uz6so3896197obc.20 for ; Mon, 09 Dec 2013 08:02:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KKkvbx4b36WNtCPEPM6VA13Zx3Ap9PtFVwskDv9r/cA=; b=ByiYxVoxTxFTqzYeGWULQMu2ZevBdREzWrRCLFEbFGd7T7Logc3dPEfKgvRhAkdMTo UIRfsu1wzT14soLFh17ghcJming4biuwpbs6vozTVgN+oiOnyDfM4LNoWT9kdygrhCzV Add6bPSaDyveMpSkxkJapULCr9r21rjfZ8k/sjgIBlWZ0Z+1UU/pZMBQoPrpo/dx6idI zkVEuLJw/aYHioOcNspn/9Pe7zjPLMXGz7j3T6SFO/5WC2/6anzxr8ffjHWwJYKlfeme yEjkMqEHVsWhhT3E056D3NtvJJA8oPC/+w0ygBFKFGqoJxfFXY5+YWlU2UQyVnZeRxXr O3eA== X-Gm-Message-State: ALoCoQnZKejYXl6mkvPDnOponofcO03GzbubPwBG4UM5/RtbtwYDNsQLcmvlGFzffcgeOKs3MIjy MIME-Version: 1.0 X-Received: by 10.182.166.40 with SMTP id zd8mr12967450obb.25.1386604933278; Mon, 09 Dec 2013 08:02:13 -0800 (PST) Received: by 10.60.31.74 with HTTP; Mon, 9 Dec 2013 08:02:13 -0800 (PST) In-Reply-To: References: <52A49582.4070307@ripe.net> Date: Mon, 9 Dec 2013 11:02:13 -0500 Message-ID: From: Richard Barnes To: Ralf Skyper Kaiser Content-Type: multipart/alternative; boundary=e89a8ff1ce027dff8604ed1c1e45 Cc: IETF SAAG Subject: Re: [saag] New I-D: Password Storage Using Public Key Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 16:02:20 -0000 --e89a8ff1ce027dff8604ed1c1e45 Content-Type: text/plain; charset=ISO-8859-1 I may be misunderstanding things, but when I read the document, it seemed like the number of rounds didn't actually matter. As long as people use a relatively fixed set of choices for the number of rounds (say 10, 100, 1000), an attacker can build a rainbow table for that number of rounds. It may be 10x / 100x / 1000x more expensive to build that table, but it may also be possible to optimize 1000xSHA1 to bring down that cost (and 1000x is not a huge number anyway). So if I'm understanding things correctly here, the mitigation would be to have a large *and* *randomized* number of rounds. Which seems like more of a hassle to manage than Robert's proposal. --Richard On Mon, Dec 9, 2013 at 4:38 AM, Ralf Skyper Kaiser wrote: > Hi, > > thanks for the I-D. Interesting idea. It solves some (but not all) > problems of password authentication. I have some questions about the > advantages of your I-D compared to the current work around that you mention: > > You mention in the I-D that the current work-around is to use multiple > rounds of hashes (100x or 1000x). > > How many hash rounds would be sufficient to make it equally secure > compared to your proposal (public key encryption)? (My gut feeling says > 10.000 sha512 are more expensive than 1x 2048 rsa encrypt but I do not have > figures in front of me. Both algorithms are available in hardware [gpu, > verilog, ..]). > > What is the advantage of your I-D compared to just increasing the hash > rounds? > > > regards, > > ralf > > > > On Sun, Dec 8, 2013 at 3:51 PM, Robert Kisteleki wrote: > >> Hello, >> >> As you may have noticed, I created a draft about how and why to add >> asymmetric encryption to password storage. >> >> http://www.ietf.org/mail-archive/web/i-d-announce/current/msg55437.html >> >> Please let me know if you have comments or suggestions. >> >> Regards, >> Robert >> >> _______________________________________________ >> 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 > > --e89a8ff1ce027dff8604ed1c1e45 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I may be misunderstanding things, but when I read the docu= ment, it seemed like the number of rounds didn't actually matter. =A0As= long as people use a relatively fixed set of choices for the number of rou= nds (say 10, 100, 1000), an attacker can build a rainbow table for that num= ber of rounds. =A0It may be 10x / 100x / 1000x more expensive to build that= table, but it may also be possible to optimize 1000xSHA1 to bring down tha= t cost (and 1000x is not a huge number anyway).

So if I'm understanding things correctly here, the mitig= ation would be to have a large *and* *randomized* number of rounds. =A0Whic= h seems like more of a hassle to manage than Robert's proposal.

--Richard

On Mon, Dec 9, 2013 at 4:38 AM, Ralf Skyper Kai= ser <skyper@thc.org> wrote:
Hi,
=
thanks for the I-D. Interesting idea. It solves some (but not all) prob= lems of password authentication. I have some questions about the advantages= of your I-D compared to the current work around that you mention:

You mention in the I-D that the current work-around is to use multiple = rounds of hashes (100x or 1000x).

How many hash rounds w= ould be sufficient to make it equally secure compared to your proposal (pub= lic key encryption)? (My gut feeling says 10.000 sha512 are more expensive = than 1x 2048 rsa encrypt but I do not have figures in front of me. Both alg= orithms are available in hardware [gpu, verilog, ..]).

What is the advantage of your I-D compared to just increasing the= hash rounds?


regards,

ralf

=


On Sun, Dec 8, 2013 at 3:51 PM, Robert K= isteleki <robert@ripe.net> wrote:
Hello,

As you may have noticed, I created a draft about how and why to add
asymmetric encryption to password storage.

http://www.ietf.org/mail-archive/web/i-d-announc= e/current/msg55437.html

Please let me know if you have comments or suggestions.

Regards,
Robert

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


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


--e89a8ff1ce027dff8604ed1c1e45-- From kivinen@iki.fi Thu Dec 5 03:16:08 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE3A1ADED5 for ; Thu, 5 Dec 2013 03:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4F-PxXeXNQ52 for ; Thu, 5 Dec 2013 03:16:07 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 104FB1ADF26 for ; Thu, 5 Dec 2013 03:16:06 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id rB5BG16D028314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 5 Dec 2013 13:16:01 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rB5BG0Lh019834; Thu, 5 Dec 2013 13:16:00 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21152.24688.575258.209944@fireball.kivinen.iki.fi> Date: Thu, 5 Dec 2013 13:16:00 +0200 From: Tero Kivinen To: Russ Housley In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 5 min X-Mailman-Approved-At: Mon, 09 Dec 2013 08:04:22 -0800 Cc: IETF SAAG Subject: [saag] RSA-PSS X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 11:16:08 -0000 Russ Housley writes: > We have seen very little movement toward RSA-PSS. While we are > reviewing algorithm choices in light of the pervasive surveillance > situation, I think we should take the time to consider improvements > in our algorithm choices. In the IPsecME WG we have draft-kivinen-ipsecme-signature-auth document which allows also using the RSASSA-PSS in addition to the RSASSA-PKCS1-v1_5 in the IKEv2. Unfortunately I have not received that many reviews on the document, especially for the RSASSA-PSS parts. The RSASSA-PSS is quite a lot more complex than RSASSA-PKCS1-v1_5, especially with all the ASN.1 in the parameters etc, and I am not sure if the text I have written about it is correct. It would be useful if someone who is really familiar with RSASSA-PSS would review the draft... -- kivinen@iki.fi From robert@ripe.net Mon Dec 9 08:20:06 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 504731AE2DE for ; Mon, 9 Dec 2013 08:20:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1XwGmN45jJD for ; Mon, 9 Dec 2013 08:20:04 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 138941ADF73 for ; Mon, 9 Dec 2013 08:20:04 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Vq3Yr-0005Gm-RU; Mon, 09 Dec 2013 17:19:59 +0100 Received: from mandrill.ripe.net ([193.0.1.209] helo=[0.0.0.0]) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Vq3Yr-0001Ic-Oq; Mon, 09 Dec 2013 17:19:57 +0100 Message-ID: <52A5EDAD.8070209@ripe.net> Date: Mon, 09 Dec 2013 17:19:57 +0100 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Richard Barnes , Ralf Skyper Kaiser References: <52A49582.4070307@ripe.net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.0 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.1 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a27431f967c39ba9dfb62b408e20abf4d795 Cc: IETF SAAG Subject: Re: [saag] New I-D: Password Storage Using Public Key Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 16:20:06 -0000 On 2013.12.09. 17:02, Richard Barnes wrote: > like the number of rounds didn't actually matter. As long as people use a > relatively fixed set of choices for the number of rounds (say 10, 100, > 1000), an attacker can build a rainbow table for that number of rounds. It > may be 10x / 100x / 1000x more expensive to build that table, but it may > also be possible to optimize 1000xSHA1 to bring down that cost (and 1000x is > not a huge number anyway). > > So if I'm understanding things correctly here, the mitigation would be to > have a large *and* *randomized* number of rounds. Which seems like more of > a hassle to manage than Robert's proposal. > --Richard Indeed that's the case. One can even reuse the same tables for cracking multiple password databases, if they share the same amount of rounds. Hardly anyone changes these settings to, say, 8563. Robert > On Mon, Dec 9, 2013 at 4:38 AM, Ralf Skyper Kaiser > wrote: > > Hi, > > thanks for the I-D. Interesting idea. It solves some (but not all) > problems of password authentication. I have some questions about the > advantages of your I-D compared to the current work around that you mention: > > You mention in the I-D that the current work-around is to use multiple > rounds of hashes (100x or 1000x). > > How many hash rounds would be sufficient to make it equally secure > compared to your proposal (public key encryption)? (My gut feeling says > 10.000 sha512 are more expensive than 1x 2048 rsa encrypt but I do not > have figures in front of me. Both algorithms are available in hardware > [gpu, verilog, ..]). > > What is the advantage of your I-D compared to just increasing the hash > rounds? > > > regards, > > ralf > > > > On Sun, Dec 8, 2013 at 3:51 PM, Robert Kisteleki > wrote: > > Hello, > > As you may have noticed, I created a draft about how and why to add > asymmetric encryption to password storage. > > http://www.ietf.org/mail-archive/web/i-d-announce/current/msg55437.html > > Please let me know if you have comments or suggestions. > > Regards, > Robert > > _______________________________________________ > 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 kent@bbn.com Mon Dec 9 08:32:09 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA6D81ADFC8 for ; Mon, 9 Dec 2013 08:32:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgO2CeWypKIH for ; Mon, 9 Dec 2013 08:32:05 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 604AE1AE31D for ; Mon, 9 Dec 2013 08:32:05 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:57604 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Vq3kW-0006zH-22 for saag@ietf.org; Mon, 09 Dec 2013 11:32:00 -0500 Message-ID: <52A5F07F.9020207@bbn.com> Date: Mon, 09 Dec 2013 11:31:59 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: saag References: <52A49582.4070307@ripe.net> <52A5EDAD.8070209@ripe.net> In-Reply-To: <52A5EDAD.8070209@ripe.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [saag] New I-D: Password Storage Using Public Key Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 16:32:09 -0000 If this proposal includes a salt with the password that is encrypted, and the salt is per user, and stored in the password table, as is common for hashed password tables, then how does an atacker amortize the cost of the processing over multiple sites, or even multiple users at the same site? A rainbow table doesn't work against salted passwords, right? Steve From skyper@thc.org Mon Dec 9 08:48:54 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B79931AE371 for ; Mon, 9 Dec 2013 08:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iFvNirSP_oV for ; Mon, 9 Dec 2013 08:48:53 -0800 (PST) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id D5E7F1AE36E for ; Mon, 9 Dec 2013 08:48:52 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id e14so6546239iej.14 for ; Mon, 09 Dec 2013 08:48:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NNmJfzyVPikkQBIei65gfR3j+bI2uUFqKYWGvJwAk1U=; b=Kub/8qTyYnLOnBHA5oFvrcOsqKXQ6ZwpTHVZPat3KnXOtKonK0Wcjv+p/x11KLpTXS lrTi8tx4t4MHKOM54EiJ5X997XRQP6iam7INx9/D4szacqdllf+9qCsLmDpFQPkp6YYF adO+IL+3tRvTob4349/yKBMPHipFlSlxRuldc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NNmJfzyVPikkQBIei65gfR3j+bI2uUFqKYWGvJwAk1U=; b=b++2lbJocedFAJlzAEMzxPOyLxOoKCfGlGm7ZHA0f79IQ+DFvKl5d2hKFM1uSQB/Sp NpI9n9qcz5D1Rr4vUDswAm0myXuACEQTdWEOyDGFr/Q7yOubU91u4Uaofic2BOpZ1P+K 8LrUZgRJt3gYAignTrzvire2w7PlDpScYYq9v7o5lQbhK0ICCtHeYax4xvoUcJgZUCmP UDQQJaddUloP6Eknp7m2RkaNRyB8NWg1Uw6OHINHep8ieY3/UloJbc7dhInc7E27PpBx cV+1PYm1zLT/zGn9ZjN+HiSZT4KDq9nOA5a2ullWydciH9tW/F5/hXn5xwbb6k3DR5bp YpCg== X-Gm-Message-State: ALoCoQmGbdTnHe7XrDWhGy+CrC4nbT9mpD/XBRjajCfl1cWcAVIBjgSrv1kBqJTSC8OmT4G+AOPF MIME-Version: 1.0 X-Received: by 10.50.92.8 with SMTP id ci8mr16280368igb.23.1386607727729; Mon, 09 Dec 2013 08:48:47 -0800 (PST) Received: by 10.64.9.41 with HTTP; Mon, 9 Dec 2013 08:48:47 -0800 (PST) X-Originating-IP: [86.178.80.136] In-Reply-To: References: <52A49582.4070307@ripe.net> Date: Mon, 9 Dec 2013 16:48:47 +0000 Message-ID: From: Ralf Skyper Kaiser To: Richard Barnes Content-Type: multipart/alternative; boundary=047d7b10cf270df3e604ed1cc523 Cc: IETF SAAG Subject: Re: [saag] New I-D: Password Storage Using Public Key Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 16:48:55 -0000 --047d7b10cf270df3e604ed1cc523 Content-Type: text/plain; charset=ISO-8859-1 Hi, not possible to build a rainbow table if salts are used (unless the salts are to small). Increasing the salts to say 64 bit would make it pretty hard to generate a rainbow table (it would be 2^64 times more expense than not using salts). yes, 1000x SHA1 can be optimized in HW but so can RSA_encrypt. I have the feeling that 1000x SHA512 is more expensive than RSA_encrypt and thus a 64 bit salt + 1000x SHA512 might (at the current time) provide better security and is surely easier to implement/roll-out?! Just a thought.... regards, ralf On Mon, Dec 9, 2013 at 4:02 PM, Richard Barnes wrote: > I may be misunderstanding things, but when I read the document, it seemed > like the number of rounds didn't actually matter. As long as people use a > relatively fixed set of choices for the number of rounds (say 10, 100, > 1000), an attacker can build a rainbow table for that number of rounds. It > may be 10x / 100x / 1000x more expensive to build that table, but it may > also be possible to optimize 1000xSHA1 to bring down that cost (and 1000x > is not a huge number anyway). > > So if I'm understanding things correctly here, the mitigation would be to > have a large *and* *randomized* number of rounds. Which seems like more of > a hassle to manage than Robert's proposal. > > --Richard > > > On Mon, Dec 9, 2013 at 4:38 AM, Ralf Skyper Kaiser wrote: > >> Hi, >> >> thanks for the I-D. Interesting idea. It solves some (but not all) >> problems of password authentication. I have some questions about the >> advantages of your I-D compared to the current work around that you mention: >> >> You mention in the I-D that the current work-around is to use multiple >> rounds of hashes (100x or 1000x). >> >> How many hash rounds would be sufficient to make it equally secure >> compared to your proposal (public key encryption)? (My gut feeling says >> 10.000 sha512 are more expensive than 1x 2048 rsa encrypt but I do not have >> figures in front of me. Both algorithms are available in hardware [gpu, >> verilog, ..]). >> >> What is the advantage of your I-D compared to just increasing the hash >> rounds? >> >> >> regards, >> >> ralf >> >> >> >> On Sun, Dec 8, 2013 at 3:51 PM, Robert Kisteleki wrote: >> >>> Hello, >>> >>> As you may have noticed, I created a draft about how and why to add >>> asymmetric encryption to password storage. >>> >>> http://www.ietf.org/mail-archive/web/i-d-announce/current/msg55437.html >>> >>> Please let me know if you have comments or suggestions. >>> >>> Regards, >>> Robert >>> >>> _______________________________________________ >>> 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 >> >> > --047d7b10cf270df3e604ed1cc523 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

not possible to build a ra= inbow table if salts are used (unless the salts are to small).

Increasing the salts to say 64 bit would make it pretty hard to generate a= rainbow table (it would be 2^64 times more expense than not using salts).<= br>
yes, 1000x SHA1 can be optimized in HW but so can RSA_encryp= t.

I have the feeling that 1000x SHA512 is more expensive than RSA_e= ncrypt and thus a 64 bit salt + 1000x SHA512 might (at the current time) pr= ovide better security and is surely easier to implement/roll-out?! Just a t= hought....

regards,

ralf



On Mon, Dec 9, 2013 at 4:02 PM, R= ichard Barnes <rlb@ipv.sx> wrote:
I may be misunderstanding t= hings, but when I read the document, it seemed like the number of rounds di= dn't actually matter. =A0As long as people use a relatively fixed set o= f choices for the number of rounds (say 10, 100, 1000), an attacker can bui= ld a rainbow table for that number of rounds. =A0It may be 10x / 100x / 100= 0x more expensive to build that table, but it may also be possible to optim= ize 1000xSHA1 to bring down that cost (and 1000x is not a huge number anywa= y).

So if I'm understanding things correctly here, the mitig= ation would be to have a large *and* *randomized* number of rounds. =A0Whic= h seems like more of a hassle to manage than Robert's proposal.

--Richard


On Mon, Dec 9, 2013 at 4:38 AM, Ralf Skyper Kaiser <skyper@thc.org= > wrote:
Hi,
=
thanks for the I-D. Interesting idea. It solves some (but not all) prob= lems of password authentication. I have some questions about the advantages= of your I-D compared to the current work around that you mention:

You mention in the I-D that the current work-around is to use multiple = rounds of hashes (100x or 1000x).

How many hash rounds w= ould be sufficient to make it equally secure compared to your proposal (pub= lic key encryption)? (My gut feeling says 10.000 sha512 are more expensive = than 1x 2048 rsa encrypt but I do not have figures in front of me. Both alg= orithms are available in hardware [gpu, verilog, ..]).

What is the advantage of your I-D compared to just increasing the= hash rounds?


regards,

ralf

=


On Sun, Dec 8, 2013 at 3:51 PM, Robert K= isteleki <robert@ripe.net> wrote:
Hello,

As you may have noticed, I created a draft about how and why to add
asymmetric encryption to password storage.

http://www.ietf.org/mail-archive/web/i-d-announc= e/current/msg55437.html

Please let me know if you have comments or suggestions.

Regards,
Robert

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


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



--047d7b10cf270df3e604ed1cc523-- From paul@marvell.com Mon Dec 9 10:29:08 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6341AE427 for ; Mon, 9 Dec 2013 10:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08HmSxN6gFMg for ; Mon, 9 Dec 2013 10:29:07 -0800 (PST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id E71FA1AE418 for ; Mon, 9 Dec 2013 10:29:06 -0800 (PST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id rB9IT1Gv022877; Mon, 9 Dec 2013 10:29:01 -0800 Received: from sc-owa02.marvell.com ([199.233.58.137]) by mx0b-0016f401.pphosted.com with ESMTP id 1gk9994ffy-15 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 09 Dec 2013 10:29:01 -0800 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Mon, 9 Dec 2013 10:28:59 -0800 From: Paul Lambert To: Ralf Skyper Kaiser , Richard Barnes , IETF SAAG Date: Mon, 9 Dec 2013 10:28:58 -0800 Thread-Topic: [saag] New I-D: Password Storage Using Public Key Encryption Thread-Index: Ac71DIbUqvNdUdjfR36jcPcemYKsfg== Message-ID: References: <52A49582.4070307@ripe.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CECB4B2C29896paulmarvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.72, 1.0.14, 0.0.0000 definitions=2013-12-09_02:2013-12-09,2013-12-09,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1312090115 Subject: Re: [saag] New I-D: Password Storage Using Public Key Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 18:29:09 -0000 --_000_CECB4B2C29896paulmarvellcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, not possible to build a rainbow table if salts are used (unless the salts a= re to small). Yes. So it seems unnecessary to introduce public key into the hashing proc= ess if the salt is large enough. However, why are we making such changes to support the continued use of sh= ared symmetric secrets for authentication. Why not just store and use publ= ic keys? Paul Increasing the salts to say 64 bit would make it pretty hard to generate a = rainbow table (it would be 2^64 times more expense than not using salts). yes, 1000x SHA1 can be optimized in HW but so can RSA_encrypt. I have the feeling that 1000x SHA512 is more expensive than RSA_encrypt and= thus a 64 bit salt + 1000x SHA512 might (at the current time) provide bett= er security and is surely easier to implement/roll-out?! Just a thought.... regards, ralf On Mon, Dec 9, 2013 at 4:02 PM, Richard Barnes > wrote: I may be misunderstanding things, but when I read the document, it seemed l= ike the number of rounds didn't actually matter. As long as people use a r= elatively fixed set of choices for the number of rounds (say 10, 100, 1000)= , an attacker can build a rainbow table for that number of rounds. It may = be 10x / 100x / 1000x more expensive to build that table, but it may also b= e possible to optimize 1000xSHA1 to bring down that cost (and 1000x is not = a huge number anyway). So if I'm understanding things correctly here, the mitigation would be to h= ave a large *and* *randomized* number of rounds. Which seems like more of = a hassle to manage than Robert's proposal. --Richard On Mon, Dec 9, 2013 at 4:38 AM, Ralf Skyper Kaiser > wrote: Hi, thanks for the I-D. Interesting idea. It solves some (but not all) problems= of password authentication. I have some questions about the advantages of = your I-D compared to the current work around that you mention: You mention in the I-D that the current work-around is to use multiple roun= ds of hashes (100x or 1000x). How many hash rounds would be sufficient to make it equally secure compared= to your proposal (public key encryption)? (My gut feeling says 10.000 sha5= 12 are more expensive than 1x 2048 rsa encrypt but I do not have figures in= front of me. Both algorithms are available in hardware [gpu, verilog, ..])= . What is the advantage of your I-D compared to just increasing the hash roun= ds? regards, ralf On Sun, Dec 8, 2013 at 3:51 PM, Robert Kisteleki > wrote: Hello, As you may have noticed, I created a draft about how and why to add asymmetric encryption to password storage. http://www.ietf.org/mail-archive/web/i-d-announce/current/msg55437.html Please let me know if you have comments or suggestions. Regards, Robert _______________________________________________ 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 --_000_CECB4B2C29896paulmarvellcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable


Hi,

not possible to build a rainbow table if salts are used (unless the salts a= re to small).
Yes. &n= bsp;So it seems unnecessary to introduce public key into the hashing proces= s if the salt is large enough.

However,  why = are we making such changes to support the continued use of shared symmetric= secrets for authentication.  Why not just store and use public keys?<= /div>

Paul




Increasing the salts to say 64 bit would make it pretty hard to generate a = rainbow table (it would be 2^64 times more expense than not using salts).
yes, 1000x SHA1 can be optimized in HW but so can RSA_encr= ypt.

I have the feeling that 1000x SHA512 is more expensive than RSA_encrypt and= thus a 64 bit salt + 1000x SHA512 might (at the current time) provide bett= er security and is surely easier to implement/roll-out?! Just a thought....=

regards,

ralf



On Mon, Dec 9, 2013 at 4:02 PM, Richard Barnes <rlb@ipv.sx> wrote:
I may be misun= derstanding things, but when I read the document, it seemed like the number= of rounds didn't actually matter.  As long as people use a relatively= fixed set of choices for the number of rounds (say 10, 100, 1000), an atta= cker can build a rainbow table for that number of rounds.  It may be 10x / 100= x / 1000x more expensive to build that table, but it may also be possible t= o optimize 1000xSHA1 to bring down that cost (and 1000x is not a huge numbe= r anyway).

So if I'm understanding things correctly here, the miti= gation would be to have a large *and* *randomized* number of rounds.  = Which seems like more of a hassle to manage than Robert's proposal.

--Richard<= /div>


On Mon, Dec 9, 2013 at = 4:38 AM, Ralf Skyper Kaiser <skyper@thc.org&= gt; wrote:
<= div>
Hi,

thanks for the I-D. Interesting idea. It solves some (but not all) problems= of password authentication. I have some questions about the advantages of = your I-D compared to the current work around that you mention:

You mention in the I-D that the current work-around is to use multiple roun= ds of hashes (100x or 1000x).

How many hash rounds would be sufficient to make it equally secure compared= to your proposal (public key encryption)? (My gut feeling says 10.000 sha5= 12 are more expensive than 1x 2048 rsa encrypt but I do not have figures in= front of me. Both algorithms are available in hardware [gpu, verilog, ..]).

What is the advantage of your I-D compared to just increasing the hash roun= ds?


regards,

ralf


_______________________________________________
saag mailing list
saa= g@ietf.org
https://www.ietf.org/mailman/listinfo/saag





--_000_CECB4B2C29896paulmarvellcom_-- From huitema@microsoft.com Mon Dec 9 11:06:07 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F4E1AE313 for ; Mon, 9 Dec 2013 11:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlMFaFd4a4x3 for ; Mon, 9 Dec 2013 11:06:05 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) by ietfa.amsl.com (Postfix) with ESMTP id F1B6D1AE4AF for ; Mon, 9 Dec 2013 11:06:04 -0800 (PST) Received: from BLUPR03CA034.namprd03.prod.outlook.com (10.141.30.27) by BLUPR03MB033.namprd03.prod.outlook.com (10.255.209.145) with Microsoft SMTP Server (TLS) id 15.0.837.10; Mon, 9 Dec 2013 19:05:58 +0000 Received: from BY2FFO11FD036.protection.gbl (2a01:111:f400:7c0c::143) by BLUPR03CA034.outlook.office365.com (2a01:111:e400:879::27) with Microsoft SMTP Server (TLS) id 15.0.842.7 via Frontend Transport; Mon, 9 Dec 2013 19:05:58 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD036.mail.protection.outlook.com (10.1.14.221) with Microsoft SMTP Server (TLS) id 15.0.825.6 via Frontend Transport; Mon, 9 Dec 2013 19:05:58 +0000 Received: from TK5EX14MBXC274.redmond.corp.microsoft.com ([169.254.3.230]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0158.002; Mon, 9 Dec 2013 19:05:04 +0000 From: Christian Huitema To: Paul Lambert , Ralf Skyper Kaiser , Richard Barnes , IETF SAAG Thread-Topic: [saag] New I-D: Password Storage Using Public Key Encryption Thread-Index: AQHO9C1j2z4tIp9oQESClvFgeGh5HZpLnGmAgABrSICAAA0CgIAAG/4AgAAFvkA= Date: Mon, 9 Dec 2013 19:05:03 +0000 Message-ID: References: <52A49582.4070307@ripe.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(51704005)(47976001)(50986001)(59766001)(53806001)(54316002)(81686001)(51856001)(74876001)(66066001)(80022001)(65816001)(74706001)(50466002)(551544002)(56776001)(54356001)(76482001)(20776003)(74662001)(47446002)(74502001)(77982001)(47776003)(63696002)(83072002)(85852003)(33656001)(81816001)(31966008)(85306002)(81342001)(56816005)(80976001)(23756003)(76786001)(76796001)(81542001)(83322001)(77096001)(44976005)(74366001)(6806004)(49866001)(55846006)(46102001)(47736001)(79102001)(2656002)(87266001)(90146001)(87936001)(4396001)(69226001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB033; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 00550ABE1F X-OriginatorOrg: microsoft.com Subject: Re: [saag] New I-D: Password Storage Using Public Key Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 19:06:07 -0000 >> not possible to build a rainbow table if salts are used (unless the salt= s are to small). > Yes. =A0So it seems unnecessary to introduce public key into the hashing = process if the salt is large enough. > > However, =A0why are we making such changes to support the continued use o= f shared symmetric secrets for authentication. =A0Why not just store and us= e public keys? Well, the alternative is to keep not improving password based security in t= he hope that sites will just switch to something else. I am not holding my = breath... >> Increasing the salts to say 64 bit would make it pretty hard to generate= a rainbow table (it would be 2^64 times more expense than not using salts)= . >> yes, 1000x SHA1 can be optimized in HW but so can RSA_encrypt. Doing the same thing a fixed number of times does not really hampers a mass= ively parallel attack. Yes, many iterations make every attempt is slower, b= ut they can still be accelerated. To really slow the attacker, you need som= ething much more varied, something that breaks vector pipelines and GPU imp= lementations. For example, a test and a branch inside the inner loop, which= really harms GPU implementation. Or a variable combination of multiple alg= orithms, which explodes the size of hardware implementations.=20 -- Christian Huitema =20 From skyper@thc.org Mon Dec 9 11:21:21 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0B11AE4B8 for ; Mon, 9 Dec 2013 11:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t24FnvxEvKul for ; Mon, 9 Dec 2013 11:21:20 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3F71AE3F3 for ; Mon, 9 Dec 2013 11:21:19 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id uq1so1574481igb.1 for ; Mon, 09 Dec 2013 11:21:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RkI72PJN1ntym02fnQJrk5gtb/P/Le0TOHzc+st7VLI=; b=aNZV4TrBE0VbKvh9Cd8Yiwvk1S0PRJL8Kkqleaa6X1xtllIz4p4++wfkI9le+7Nvkr aTgckkAcEhsy2muuSgadNhGCsXyRhJrGlpORZMHE5o+zyB9/F2muorISmOXLIZajj6oD y0c68fHvzLzylko6ChW1m7MXkwbVdmqIyu52I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RkI72PJN1ntym02fnQJrk5gtb/P/Le0TOHzc+st7VLI=; b=kg9P2dVRPLO58cQl6296LO/sQ9SxhCKJOgyelodhnoV86wZUdfVNoccitpA8XPQf1f EKk5HhSSmhHHc0aq/gUhGR767vglMQPwNfPM6E5J9Q7ctN5Wx+wU0E6WasUMm9euFazn z7Sc/uVyJH3mjV+P/zvGnPv51ORMjtnxlf0gcUiOh/S2JLUDDuysqypK34f+dKBeDW6r iE/8mnl9NoNJSZFgmQSeD6G90EJbbeNVvBz785UCbSIjb5uU9aOOAokwiaa/KMJLMYGK ul2SDzNhUItBscOifF9+oN+L6XWykNG/hQL6W+9tuU9fgfgJqbbyF132bXCfNLYuyjE7 W3gw== X-Gm-Message-State: ALoCoQn5ttote+1+BinktXcO2mjsVANN5wVxhAVOajbI2mVZSbhhhQnonbkHkg5II9b2ntC9ngT+ MIME-Version: 1.0 X-Received: by 10.50.25.129 with SMTP id c1mr16907929igg.23.1386616875039; Mon, 09 Dec 2013 11:21:15 -0800 (PST) Received: by 10.64.9.41 with HTTP; Mon, 9 Dec 2013 11:21:14 -0800 (PST) X-Originating-IP: [80.195.189.45] In-Reply-To: References: <52A49582.4070307@ripe.net> Date: Mon, 9 Dec 2013 19:21:14 +0000 Message-ID: From: Ralf Skyper Kaiser To: Christian Huitema Content-Type: multipart/alternative; boundary=047d7bdc10ec46ffa804ed1ee676 Cc: IETF SAAG Subject: Re: [saag] New I-D: Password Storage Using Public Key Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 19:21:21 -0000 --047d7bdc10ec46ffa804ed1ee676 Content-Type: text/plain; charset=ISO-8859-1 Hi, On Mon, Dec 9, 2013 at 7:05 PM, Christian Huitema wrote: > >> not possible to build a rainbow table if salts are used (unless the > salts are to small). > > Yes. So it seems unnecessary to introduce public key into the hashing > process if the salt is large enough. > > > > However, why are we making such changes to support the continued use of > shared symmetric secrets for authentication. Why not just store and use > public keys? > > Well, the alternative is to keep not improving password based security in > the hope that sites will just switch to something else. I am not holding my > breath... > Correct. It wont happen in the near future. In the meantime let's improve password security. The goal is to make dictionary/rainbow attacks more expensive. > > >> Increasing the salts to say 64 bit would make it pretty hard to > generate a rainbow table (it would be 2^64 times more expense than not > using salts). > >> yes, 1000x SHA1 can be optimized in HW but so can RSA_encrypt. > > Doing the same thing a fixed number of times does not really hampers a > massively parallel attack. Yes, many iterations make every attempt is > slower, but they can still be accelerated. To really slow the attacker, you > need something much more varied, something that breaks vector pipelines and > GPU implementations. For example, a test and a branch inside the inner > loop, which really harms GPU implementation. Or a variable combination of > multiple algorithms, which explodes the size of hardware implementations. > > The cost increase is linear for all suggested solutions. Unless the solution increases the cost exponentially there is no real benefit to using a large salt and 10.000x SHA512. Comments welcome. regards, skyper --047d7bdc10ec46ffa804ed1ee676 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,


On Mon, Dec 9, 2013 at 7:05 PM, Christian Huitema <hu= itema@microsoft.com> wrote:
>> not possible to b= uild a rainbow table if salts are used (unless the salts are to small).
> Yes. =A0So it seems unnecessary to introduce public key into the hashi= ng process if the salt is large enough.
>
> However, =A0why are we making such changes to support the continued us= e of shared symmetric secrets for authentication. =A0Why not just store and= use public keys?

Well, the alternative is to keep not improving password based securit= y in the hope that sites will just switch to something else. I am not holdi= ng my breath...

Correct. It wont happen= in the near future. In the meantime let's improve password security. T= he goal is to make dictionary/rainbow attacks more expensive.
=A0

>> Increasing the salts to say 64 bit would make it pretty hard to ge= nerate a rainbow table (it would be 2^64 times more expense than not using = salts).
>> yes, 1000x SHA1 can be optimized in HW but so can RSA_encrypt.

Doing the same thing a fixed number of times does not really hampers = a massively parallel attack. Yes, many iterations make every attempt is slo= wer, but they can still be accelerated. To really slow the attacker, you ne= ed something much more varied, something that breaks vector pipelines and G= PU implementations. For example, a test and a branch inside the inner loop,= which really harms GPU implementation. Or a variable combination of multip= le algorithms, which explodes the size of hardware implementations.


The cost increase is linear for all suggested solutions. U= nless the solution increases the cost exponentially there is no real benefi= t to using a large salt and 10.000x SHA512. Comments welcome.

regards,

skyper

--047d7bdc10ec46ffa804ed1ee676-- From huitema@microsoft.com Mon Dec 9 11:47:32 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603EF1AE50F for ; Mon, 9 Dec 2013 11:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpYNr0GYUyn3 for ; Mon, 9 Dec 2013 11:47:30 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4991AE509 for ; Mon, 9 Dec 2013 11:47:29 -0800 (PST) Received: from DM2PR03CA001.namprd03.prod.outlook.com (10.141.52.149) by BL2PR03MB179.namprd03.prod.outlook.com (10.255.230.154) with Microsoft SMTP Server (TLS) id 15.0.837.10; Mon, 9 Dec 2013 19:47:24 +0000 Received: from BY2FFO11FD015.protection.gbl (2a01:111:f400:7c0c::104) by DM2PR03CA001.outlook.office365.com (2a01:111:e400:2414::21) with Microsoft SMTP Server (TLS) id 15.0.837.10 via Frontend Transport; Mon, 9 Dec 2013 19:47:24 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD015.mail.protection.outlook.com (10.1.14.131) with Microsoft SMTP Server (TLS) id 15.0.825.6 via Frontend Transport; Mon, 9 Dec 2013 19:47:23 +0000 Received: from TK5EX14MBXC274.redmond.corp.microsoft.com ([169.254.3.230]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.03.0158.002; Mon, 9 Dec 2013 19:46:41 +0000 From: Christian Huitema To: Ralf Skyper Kaiser Thread-Topic: [saag] New I-D: Password Storage Using Public Key Encryption Thread-Index: AQHO9C1j2z4tIp9oQESClvFgeGh5HZpLnGmAgABrSICAAA0CgIAAG/4AgAAFvkCAAAjdAIAAA1Vg Date: Mon, 9 Dec 2013 19:46:41 +0000 Message-ID: References: <52A49582.4070307@ripe.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(49866001)(20776003)(56776001)(47776003)(74662001)(54316002)(80022001)(79102001)(33656001)(51856001)(81342001)(76786001)(76796001)(4396001)(50986001)(47976001)(54356001)(74366001)(59766001)(47736001)(55846006)(77982001)(74502001)(63696002)(31966008)(76482001)(23726002)(66066001)(65816001)(69226001)(87936001)(47446002)(87266001)(2656002)(46102001)(81686001)(50466002)(46406003)(81816001)(81542001)(53806001)(74706001)(77096001)(74876001)(80976001)(83322001)(551544002)(44976005)(90146001)(6806004)(85306002)(56816005)(85852003)(83072002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB179; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 00550ABE1F X-OriginatorOrg: microsoft.com Cc: IETF SAAG Subject: Re: [saag] New I-D: Password Storage Using Public Key Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 19:47:32 -0000 >The cost increase is linear for all suggested solutions. Unless the soluti= on increases the cost exponentially=20 > there is no real benefit to using a large salt and 10.000x SHA512. Commen= ts welcome. The salt has to be large enough to make rainbow tables unpractical. In the = age of big data, the bad guys too can use terabytes of storage. "Use 64 ran= dom bits of salt" looks like a very practical recommendation. The linear increase of "N times SHA512" does slow down the attacker. It wil= l take N times longer for the attacker to try their dictionary, and that wi= ll give N times more time for potential victims to be notified and change t= heir passwords. The problem is that doing this also makes password verifica= tion slower, so we end up with a balance between performance and security. = Make N too large and the performance are not acceptable. Make N too small a= nd the attacker just have to use N times more resource. I think the algorithm should be specifically designed to thwart GPU impleme= ntations, i.e. SIMD parallelism. You can get that by having variable number= of steps, a random mix of SHA512 and SHA1 and even MD5, specifiying branch= ing inside the inner loop, etc. -- Christian Huitema From openpgp@brainhub.org Mon Dec 9 12:08:13 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DB41AE07F for ; Mon, 9 Dec 2013 12:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpK_YRT5Y3Vg for ; Mon, 9 Dec 2013 12:08:11 -0800 (PST) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:56]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF621AE064 for ; Mon, 9 Dec 2013 12:08:11 -0800 (PST) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta06.emeryville.ca.mail.comcast.net with comcast id zSXQ1m0071vN32cA6Y86PR; Mon, 09 Dec 2013 20:08:06 +0000 Received: from [192.168.1.8] ([71.202.164.227]) by omta22.emeryville.ca.mail.comcast.net with comcast id zY7v1m00W4uhcbK8iY86F3; Mon, 09 Dec 2013 20:08:06 +0000 Message-ID: <52A6231B.6050306@brainhub.org> Date: Mon, 09 Dec 2013 12:07:55 -0800 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: saag@ietf.org References: <52A49582.4070307@ripe.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386619686; bh=cI1dXTNTq2U9idBY+EqerHnYeyPay6T5YQ8TX+KjHwo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=X3MQW7UNdkPvAasGEJug5uHIoIp445Zqr3fA2uZoqdiIXOaINHATprDQFzW55EZ+G VJ4LJQu7Mxy2EjnCYTke7lzms4+QLOv/+KokUdvBhgWj9X3LoN3ecpvu4MLL6CogNs BCFN/XDoBu8P5X1UPdRtjVo339siy3fAWLrDGP0dHbRHvEm8EeksQdWgMKWIaS3mrc rGWVFEpWAs+M6xJ0F6d+tWm7i6rJAq3sw9/LtOk/FYpMotTLz8ccP66+JC1TRL4Ylg 9kqaCzRi04BJktdLpyL6fNZsBlDu6gSHpzbxFv8ANPPjn3SS8QHJmr8mNSy6/VX8SU gmkbL4ac9VUGA== Subject: Re: [saag] New I-D: Password Storage Using Public Key Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 20:08:13 -0000 As a side note, that's unfortunate that the iteration count N in popular iterative hashed password algorithms has an incremental property. This is true for PBKDF2 and OpenPGP string-to-key, for example. By this I mean that to go from N to N+1 one only needs to do one hashing (and not N). In practice N will not be entirely random, but a predictable range. This is not an issue for random salts, but there is no reason why N should not be "hashed" as part of the derivation algorithm. On 12/09/2013 11:46 AM, Christian Huitema wrote: >> The cost increase is linear for all suggested solutions. Unless the solution increases the cost exponentially >> there is no real benefit to using a large salt and 10.000x SHA512. Comments welcome. > > The salt has to be large enough to make rainbow tables unpractical. In the age of big data, the bad guys too can use terabytes of storage. "Use 64 random bits of salt" looks like a very practical recommendation. > > The linear increase of "N times SHA512" does slow down the attacker. It will take N times longer for the attacker to try their dictionary, and that will give N times more time for potential victims to be notified and change their passwords. The problem is that doing this also makes password verification slower, so we end up with a balance between performance and security. Make N too large and the performance are not acceptable. Make N too small and the attacker just have to use N times more resource. > > I think the algorithm should be specifically designed to thwart GPU implementations, i.e. SIMD parallelism. You can get that by having variable number of steps, a random mix of SHA512 and SHA1 and even MD5, specifiying branching inside the inner loop, etc. From kent@bbn.com Tue Dec 10 07:06:43 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFE71ADF34 for ; Tue, 10 Dec 2013 07:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRja4j_AMrID for ; Tue, 10 Dec 2013 07:06:41 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id D5C681AE10A for ; Tue, 10 Dec 2013 07:06:41 -0800 (PST) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:51498) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VqOtQ-000MZh-BE for saag@ietf.org; Tue, 10 Dec 2013 10:06:36 -0500 Message-ID: <52A72DFC.70906@bbn.com> Date: Tue, 10 Dec 2013 10:06:36 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: saag@ietf.org References: <52A49582.4070307@ripe.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090105030909050709060400" Subject: Re: [saag] New I-D: Password Storage Using Public Key Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 15:06:43 -0000 This is a multi-part message in MIME format. --------------090105030909050709060400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ralf, > ... > > > > The cost increase is linear for all suggested solutions. Unless the > solution increases the cost exponentially there is no real benefit to > using a large salt and 10.000x SHA512. Comments welcome. I don't agree that a linear cost increase is not worth pursuing, if the muyltiplier is big enough. Attackers have to spend money to perform password searches on hashed/encrypted password tables that they acquire. If we increase the cost by 10^5, their costs increase accordingly. While one might argue that, in an academic context, only an exponential increase merits publication, that it not the context for this discussion. Steve --------------090105030909050709060400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ralf,
...


The cost increase is linear for all suggested solutions. Unless the solution increases the cost exponentially there is no real benefit to using a large salt and 10.000x SHA512. Comments welcome.
I don't agree that a linear cost increase is not worth pursuing, if the muyltiplier is big enough. Attackers have to spend money to perform password searches on hashed/encrypted password tables that they acquire. If we increase the cost by 10^5, their costs increase accordingly. While one might argue that, in an academic context,
only an exponential increase merits publication, that it not the context for this
discussion.

Steve
--------------090105030909050709060400-- From scott@ties.org Mon Dec 9 11:02:52 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED58C1AE4B0 for ; Mon, 9 Dec 2013 11:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikoaBoO7dHwO for ; Mon, 9 Dec 2013 11:02:48 -0800 (PST) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by ietfa.amsl.com (Postfix) with ESMTP id E7E3C1AE4AB for ; Mon, 9 Dec 2013 11:02:47 -0800 (PST) Received: by mail-vc0-f171.google.com with SMTP id ik5so3703212vcb.2 for ; Mon, 09 Dec 2013 11:02:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ELbacwbOBPdbI6Y157NfglyOcxkpMRzuODfNoQ5GXpE=; b=mTetsc1I+CEQH8183i/mL6fLFMmTc5s51qXJKe5C3xe35jHjSyNa4Kr/PVNw2CAQA5 76sNdXNePs8VdI/K2/0LHbXOw7BvcfBNTDg/wJ/1UM6fmc1+KjAdHZNoD58J72JrO/lZ 0XhMiQFX3XNHfwcAZQdI0wqdJ/jg/7XFJCiGISOJ53SoVG6BgUERDVk83FLgJAuS2bhC wxsdhZnMQ7hV5WH2YleQ95X82RIzk3cv8qS/DI0suVG67xKTHQAFVTkxWGWXpzpGmc16 hnShRhuQSYbxKNQpw0C+cIB6ebOIcc8Ufdz5SBtvTrRP3J+f4I84OjkmYP3Dlf8MMydk NE3Q== X-Gm-Message-State: ALoCoQlxqyguc9yLMrC3IGadCxlfGh9Bu+3jsSSJI3809drC0dJA4VdTyHvS9/3Vuve9TjxjI6b4 X-Received: by 10.58.67.9 with SMTP id j9mr11725786vet.3.1386615762567; Mon, 09 Dec 2013 11:02:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.67.71 with HTTP; Mon, 9 Dec 2013 11:02:02 -0800 (PST) X-Originating-IP: [74.137.124.186] In-Reply-To: References: <52A49582.4070307@ripe.net> From: "Scott R. Corzine" Date: Mon, 9 Dec 2013 14:02:02 -0500 Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary=047d7b339e07f88a3e04ed1ea31b X-Mailman-Approved-At: Tue, 10 Dec 2013 08:02:50 -0800 Cc: IETF SAAG Subject: Re: [saag] New I-D: Password Storage Using Public Key Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 19:12:39 -0000 --047d7b339e07f88a3e04ed1ea31b Content-Type: text/plain; charset=UTF-8 What if you were to randomly generate the number of rounds and then save it as we currently do for a salt? For implementations which provide for specific storage of salt + hash but aren't flexible enough to accommodate salt+rounds+hash you could use the kludge of using the last n bits (say 16) of the salt to double as the number of rounds (or add say 1000 to it to ensure a minimum number of rounds). -Scott- On Mon, Dec 9, 2013 at 11:02 AM, Richard Barnes wrote: > I may be misunderstanding things, but when I read the document, it seemed > like the number of rounds didn't actually matter. As long as people use a > relatively fixed set of choices for the number of rounds (say 10, 100, > 1000), an attacker can build a rainbow table for that number of rounds. It > may be 10x / 100x / 1000x more expensive to build that table, but it may > also be possible to optimize 1000xSHA1 to bring down that cost (and 1000x > is not a huge number anyway). > > So if I'm understanding things correctly here, the mitigation would be to > have a large *and* *randomized* number of rounds. Which seems like more of > a hassle to manage than Robert's proposal. > > --Richard > > > On Mon, Dec 9, 2013 at 4:38 AM, Ralf Skyper Kaiser wrote: > >> Hi, >> >> thanks for the I-D. Interesting idea. It solves some (but not all) >> problems of password authentication. I have some questions about the >> advantages of your I-D compared to the current work around that you mention: >> >> You mention in the I-D that the current work-around is to use multiple >> rounds of hashes (100x or 1000x). >> >> How many hash rounds would be sufficient to make it equally secure >> compared to your proposal (public key encryption)? (My gut feeling says >> 10.000 sha512 are more expensive than 1x 2048 rsa encrypt but I do not have >> figures in front of me. Both algorithms are available in hardware [gpu, >> verilog, ..]). >> >> What is the advantage of your I-D compared to just increasing the hash >> rounds? >> >> >> regards, >> >> ralf >> >> >> >> On Sun, Dec 8, 2013 at 3:51 PM, Robert Kisteleki wrote: >> >>> Hello, >>> >>> As you may have noticed, I created a draft about how and why to add >>> asymmetric encryption to password storage. >>> >>> http://www.ietf.org/mail-archive/web/i-d-announce/current/msg55437.html >>> >>> Please let me know if you have comments or suggestions. >>> >>> Regards, >>> Robert >>> >>> _______________________________________________ >>> 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 > > --047d7b339e07f88a3e04ed1ea31b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What if you were to randomly generate the number of rounds= and then save it as we currently do for a salt? =C2=A0For implementations = which provide for specific storage of salt + hash but aren't flexible e= nough to accommodate salt+rounds+hash you could use the kludge of using the= last n bits (say 16) of the salt to double as the number of rounds (or add= say 1000 to it to ensure a minimum number of rounds).

-Scott-


On Mon, Dec 9, 2013 at 11:02 AM, Richard Barnes <rlb@ipv.sx<= /a>> wrote:
I may be misunderstanding t= hings, but when I read the document, it seemed like the number of rounds di= dn't actually matter. =C2=A0As long as people use a relatively fixed se= t of choices for the number of rounds (say 10, 100, 1000), an attacker can = build a rainbow table for that number of rounds. =C2=A0It may be 10x / 100x= / 1000x more expensive to build that table, but it may also be possible to= optimize 1000xSHA1 to bring down that cost (and 1000x is not a huge number= anyway).

So if I'm understanding things correctly here, the mitig= ation would be to have a large *and* *randomized* number of rounds. =C2=A0W= hich seems like more of a hassle to manage than Robert's proposal.

--Richard


On Mon, Dec 9, 2013 at 4:38 AM, Ralf Skyper Kaiser <skyper@thc.org= > wrote:
Hi,
=
thanks for the I-D. Interesting idea. It solves some (but not all) prob= lems of password authentication. I have some questions about the advantages= of your I-D compared to the current work around that you mention:

You mention in the I-D that the current work-around is to use multiple = rounds of hashes (100x or 1000x).

How many hash rounds w= ould be sufficient to make it equally secure compared to your proposal (pub= lic key encryption)? (My gut feeling says 10.000 sha512 are more expensive = than 1x 2048 rsa encrypt but I do not have figures in front of me. Both alg= orithms are available in hardware [gpu, verilog, ..]).

What is the advantage of your I-D compared to just increasing the= hash rounds?


regards,

ralf

=


On Sun, Dec 8, 2013 at 3:51 PM, Robert K= isteleki <robert@ripe.net> wrote:
Hello,

As you may have noticed, I created a draft about how and why to add
asymmetric encryption to password storage.

http://www.ietf.org/mail-archive/web/i-d-announc= e/current/msg55437.html

Please let me know if you have comments or suggestions.

Regards,
Robert

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


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



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


--047d7b339e07f88a3e04ed1ea31b-- From skyper@thc.org Tue Dec 10 08:19:23 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7001F1ADFC3 for ; Tue, 10 Dec 2013 08:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnzT75W_p9ea for ; Tue, 10 Dec 2013 08:19:21 -0800 (PST) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 4C80E1ADF4F for ; Tue, 10 Dec 2013 08:19:21 -0800 (PST) Received: by mail-ig0-f182.google.com with SMTP id c10so2518343igq.3 for ; Tue, 10 Dec 2013 08:19:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e4x2dyRk6LJd00cFZxYJ9zqJbGmjJuTPsZlXdUkWdjg=; b=E4XNUKpFpS/QDaMz8B7JAVklpWAv0Z3BN9LlbbLtp6lvoG4XvD9ZiLiR+MiKNFIYp8 CDgeB1pD4IjcBBR6s0vUIjRmKg2qvxplGB6dsF1x2T9vzQhsYWq10Bs1bFgnrWT+nVv8 hRdKmjlrC6oISjvTnxp07HMMGaH0uw8lyEPfg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=e4x2dyRk6LJd00cFZxYJ9zqJbGmjJuTPsZlXdUkWdjg=; b=FVOy/5gNoeyEWDIPbOXlKct1K5zw/8oJnDB/qsmFkWnuhMfVVG/wqiXh1K1hiqcacm MGOHhP4pIY6eCZZwVmUQz+lQigNLYFPHGgejy09ZIm6uBhio6TYFH0BUCIdsqS5naFls gSUXh9A4CKqvVWfQBnL41PkL6a3irvhKyv9KN7H1H/4wR6Mzo4pt8bX+fudriZf6SUl3 1E9GaSJECkzaRLPYwi7VUWOT/g3sTqgkXkXuyZEAZ49NQ+YHxvQU6uy8t3IWL10tW/ME L3+twz4Vh6psQ4J1q1DIViMIwybvFg4I0EXf2zRuetG/mVkAJitmS793Mqj86N7sjsYD 6a8Q== X-Gm-Message-State: ALoCoQkD2E/wox+rfQYg6444ZD3CLfeIrbOUjpyzf6/bXYuPwI1FyV5WdGEUmzOxIVsjAjokyPkO MIME-Version: 1.0 X-Received: by 10.42.62.196 with SMTP id z4mr1805037ich.49.1386692355788; Tue, 10 Dec 2013 08:19:15 -0800 (PST) Received: by 10.64.9.41 with HTTP; Tue, 10 Dec 2013 08:19:15 -0800 (PST) X-Originating-IP: [31.55.30.202] In-Reply-To: <52A72DFC.70906@bbn.com> References: <52A49582.4070307@ripe.net> <52A72DFC.70906@bbn.com> Date: Tue, 10 Dec 2013 16:19:15 +0000 Message-ID: From: Ralf Skyper Kaiser To: Stephen Kent Content-Type: multipart/alternative; boundary=90e6ba614a7647bbe504ed3079fc Cc: IETF SAAG Subject: Re: [saag] New I-D: Password Storage Using Public Key Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 16:19:23 -0000 --90e6ba614a7647bbe504ed3079fc Content-Type: text/plain; charset=ISO-8859-1 Stephen, On Tue, Dec 10, 2013 at 3:06 PM, Stephen Kent wrote: > Ralf, > > ... > > >> > The cost increase is linear for all suggested solutions. Unless the > solution increases the cost exponentially there is no real benefit to using > a large salt and 10.000x SHA512. Comments welcome. > > I don't agree that a linear cost increase is not worth pursuing, if the > muyltiplier is big enough. Attackers have to spend money to perform > password searches on hashed/encrypted password tables that they acquire. If > we increase the cost by 10^5, their costs increase accordingly. While one > might argue that, in an academic context, > only an exponential increase merits publication, that it not the context > for this > discussion. > That's exactly my point. A linear cost increase is worth pursuing. I'm all for it. We discussed two proposals: A. Using Public key to store passwords B. Using 64 bit salt + 10.000x hash (or whatever number is best) I proposed solution B as it is less complex with no (security)-disadvantage over the proposed solution A. My 'that's just linear comment' was regarding the two suggested items to make B more secure. Suggested was: 1. use two hashing algorithms 2. use a branch-statement Both (1. and 2.) are a linear increase in attack cost. Both (1. and 2.) come at the cost of complexity. (bad) Both (1. and 2.) would make GPU/FPGA implementations harder. (good!) Item 1. means the attacker would have to double the hardware cost. (good!) Item 2. insignificantly increases the attack cost (neutral). My favorite is B. and I have not made up my mind if the extra complexity of 1. justifies the gained security. Comments welcome. regards, ralf > Steve > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > --90e6ba614a7647bbe504ed3079fc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Stephen,


On Tue, Dec 10, 2013 at 3:06 PM, Stephen Kent <kent@bbn.com> wrote:
=20 =20 =20
Ralf,
...



The cost increase is linear for all suggested solutions. Unless the solution increases the cost exponentially there is no real benefit to using a large salt and 10.000x SHA512. Comments welcome.
I don't agree that a linear cost increase is not worth pursuing, if the muyltiplier is big enough. Attackers have to spend money to perform password searches on hashed/encrypted password tables that they acquire. If we increase the cost by 10^5, their costs increase accordingly. While one might argue that, in an academic context,
only an exponential increase merits publication, that it not the context for this
discussion.

That's exactl= y my point. A linear cost increase is worth pursuing. I'm all for it. <= br>
We discussed two proposals:
A. Using Public key to sto= re passwords
B. Using 64 bit salt + 10.000x hash (or whatever number is best)

I proposed solution B as it is less complex with no (security)-disa= dvantage over the proposed solution A.

My 'that'= s just linear comment' was regarding the two suggested items to make B = more secure. Suggested was:
1. use two hashing algorithms
2. use a branch-stat= ement

Both (1. and 2.) are a linear increase in attack c= ost.

Both (1. and 2.) come at= the cost of complexity. (bad)

Both (1. and 2.) would make GPU/FPGA implementations harder. (good!)
Item 1. means the attacker would have to double the hardware cost. (go= od!)
Item 2. insignificantly increases the attack cost (neutral).

My favorite is B. and I have not made = up my mind if the extra complexity of 1. justifies the gained security. Com= ments welcome.

regards,
ralf


Steve

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


--90e6ba614a7647bbe504ed3079fc-- From pkampana@cisco.com Tue Dec 10 12:03:06 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5D41AE068 for ; Tue, 10 Dec 2013 12:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JodFxxKOUhJZ for ; Tue, 10 Dec 2013 12:03:04 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id CAF3D1ADEC8 for ; Tue, 10 Dec 2013 12:03:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17706; q=dns/txt; s=iport; t=1386705779; x=1387915379; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=mzhMsreNKIBWbkDXIngZCasvwRaeQWs2GNXS8dZjopo=; b=dIVFHtypqvnCN264Xf2741zmUFp/VENtk3p0A8oZ7rSaRaRywROqgkNA 1HZ7e8QiGwovRDmGfh7f6d52Xzb3Jtd/vCD0ioDykmGy45oGYpuaaKver Pp5knMpb2pUXGfqLkVQc/unnjytP2Hbj3bayhpBwVjdiuJtdTeukb3qx0 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFADNzp1KtJV2a/2dsb2JhbABZgkNEOFOCf7YeGIEJFnSCJQEBAQQBAQEgCkELEAIBCBEEAQELDg8DAgICJQsUCQgCBAENBQgBh3kNsUWPVBeONAEBBhgtBAYBGIJUNYETBKongymBaQgXIg X-IronPort-AV: E=Sophos;i="4.93,866,1378857600"; d="scan'208,217";a="290467693" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 10 Dec 2013 20:02:58 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rBAK2wbr016190 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Dec 2013 20:02:58 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Tue, 10 Dec 2013 14:02:57 -0600 From: "Panos Kampanakis (pkampana)" To: "Scott R. Corzine" , Richard Barnes Thread-Topic: [saag] New I-D: Password Storage Using Public Key Encryption Thread-Index: AQHO9cFUfkmjs89V406H5CSpI82QbppN2NaA Date: Tue, 10 Dec 2013 20:02:57 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A750FA95D8D@xmb-rcd-x10.cisco.com> References: <52A49582.4070307@ripe.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.89.107] Content-Type: multipart/alternative; boundary="_000_1C9F17D1873AFA47A969C4DD98F98A750FA95D8Dxmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: IETF SAAG Subject: Re: [saag] New I-D: Password Storage Using Public Key Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 20:03:07 -0000 --_000_1C9F17D1873AFA47A969C4DD98F98A750FA95D8Dxmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdCBpcyBhbiBpbnRlcmVzdGluZyBzY2hlbWUgYWxzby4gSSBhbSBub3Qgc3VyZSBpZiB1c2lu ZyBlbmNyeXB0aW9uIHdvdWxkIG9mZmVyIG1vcmUgYmVuZWZpdCB0aGFuIHRoYXQgc2NoZW1lLg0K QWRkaXRpb25hbGx5LCBkZXBlbmRpbmcgb24gdGhlIHJvdW5kcywgc29tZW9uZSBjb3VsZCBtYWtl IHRoZSBwYXNzd29yZCBndWVzc2luZyBhcyBoYXJkIGFzIGhlIHdhbnRlZC4NCg0KTXkgcXVlc3Rp b24gaW4gdGhpcyBjYXNlIHdvdWxkIGJlLCBob3cgbWFueSByb3VuZC1iaXRzIGRvZXMgc29tZW9u ZSBuZWVkIHRvIGFwcHJveGltYXRlbHkgaGF2ZSB0aGUgc2FtZSBvdmVyaGVhZCBhcyBhbiBlbmNy eXB0aW9uIG9wZXJhdGlvbi4NCg0KUGFub3MNCg0KDQoNCg0KRnJvbTogc2FhZyBbbWFpbHRvOnNh YWctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNjb3R0IFIuIENvcnppbmUNClNlbnQ6 IE1vbmRheSwgRGVjZW1iZXIgMDksIDIwMTMgMjowMiBQTQ0KVG86IFJpY2hhcmQgQmFybmVzDQpD YzogSUVURiBTQUFHDQpTdWJqZWN0OiBSZTogW3NhYWddIE5ldyBJLUQ6IFBhc3N3b3JkIFN0b3Jh Z2UgVXNpbmcgUHVibGljIEtleSBFbmNyeXB0aW9uDQoNCldoYXQgaWYgeW91IHdlcmUgdG8gcmFu ZG9tbHkgZ2VuZXJhdGUgdGhlIG51bWJlciBvZiByb3VuZHMgYW5kIHRoZW4gc2F2ZSBpdCBhcyB3 ZSBjdXJyZW50bHkgZG8gZm9yIGEgc2FsdD8gIEZvciBpbXBsZW1lbnRhdGlvbnMgd2hpY2ggcHJv dmlkZSBmb3Igc3BlY2lmaWMgc3RvcmFnZSBvZiBzYWx0ICsgaGFzaCBidXQgYXJlbid0IGZsZXhp YmxlIGVub3VnaCB0byBhY2NvbW1vZGF0ZSBzYWx0K3JvdW5kcytoYXNoIHlvdSBjb3VsZCB1c2Ug dGhlIGtsdWRnZSBvZiB1c2luZyB0aGUgbGFzdCBuIGJpdHMgKHNheSAxNikgb2YgdGhlIHNhbHQg dG8gZG91YmxlIGFzIHRoZSBudW1iZXIgb2Ygcm91bmRzIChvciBhZGQgc2F5IDEwMDAgdG8gaXQg dG8gZW5zdXJlIGEgbWluaW11bSBudW1iZXIgb2Ygcm91bmRzKS4NCg0KLVNjb3R0LQ0KDQpPbiBN b24sIERlYyA5LCAyMDEzIGF0IDExOjAyIEFNLCBSaWNoYXJkIEJhcm5lcyA8cmxiQGlwdi5zeDxt YWlsdG86cmxiQGlwdi5zeD4+IHdyb3RlOg0KSSBtYXkgYmUgbWlzdW5kZXJzdGFuZGluZyB0aGlu Z3MsIGJ1dCB3aGVuIEkgcmVhZCB0aGUgZG9jdW1lbnQsIGl0IHNlZW1lZCBsaWtlIHRoZSBudW1i ZXIgb2Ygcm91bmRzIGRpZG4ndCBhY3R1YWxseSBtYXR0ZXIuICBBcyBsb25nIGFzIHBlb3BsZSB1 c2UgYSByZWxhdGl2ZWx5IGZpeGVkIHNldCBvZiBjaG9pY2VzIGZvciB0aGUgbnVtYmVyIG9mIHJv dW5kcyAoc2F5IDEwLCAxMDAsIDEwMDApLCBhbiBhdHRhY2tlciBjYW4gYnVpbGQgYSByYWluYm93 IHRhYmxlIGZvciB0aGF0IG51bWJlciBvZiByb3VuZHMuICBJdCBtYXkgYmUgMTB4IC8gMTAweCAv IDEwMDB4IG1vcmUgZXhwZW5zaXZlIHRvIGJ1aWxkIHRoYXQgdGFibGUsIGJ1dCBpdCBtYXkgYWxz byBiZSBwb3NzaWJsZSB0byBvcHRpbWl6ZSAxMDAweFNIQTEgdG8gYnJpbmcgZG93biB0aGF0IGNv c3QgKGFuZCAxMDAweCBpcyBub3QgYSBodWdlIG51bWJlciBhbnl3YXkpLg0KDQpTbyBpZiBJJ20g dW5kZXJzdGFuZGluZyB0aGluZ3MgY29ycmVjdGx5IGhlcmUsIHRoZSBtaXRpZ2F0aW9uIHdvdWxk IGJlIHRvIGhhdmUgYSBsYXJnZSAqYW5kKiAqcmFuZG9taXplZCogbnVtYmVyIG9mIHJvdW5kcy4g IFdoaWNoIHNlZW1zIGxpa2UgbW9yZSBvZiBhIGhhc3NsZSB0byBtYW5hZ2UgdGhhbiBSb2JlcnQn cyBwcm9wb3NhbC4NCg0KLS1SaWNoYXJkDQoNCk9uIE1vbiwgRGVjIDksIDIwMTMgYXQgNDozOCBB TSwgUmFsZiBTa3lwZXIgS2Fpc2VyIDxza3lwZXJAdGhjLm9yZzxtYWlsdG86c2t5cGVyQHRoYy5v cmc+PiB3cm90ZToNCkhpLA0KDQp0aGFua3MgZm9yIHRoZSBJLUQuIEludGVyZXN0aW5nIGlkZWEu IEl0IHNvbHZlcyBzb21lIChidXQgbm90IGFsbCkgcHJvYmxlbXMgb2YgcGFzc3dvcmQgYXV0aGVu dGljYXRpb24uIEkgaGF2ZSBzb21lIHF1ZXN0aW9ucyBhYm91dCB0aGUgYWR2YW50YWdlcyBvZiB5 b3VyIEktRCBjb21wYXJlZCB0byB0aGUgY3VycmVudCB3b3JrIGFyb3VuZCB0aGF0IHlvdSBtZW50 aW9uOg0KDQpZb3UgbWVudGlvbiBpbiB0aGUgSS1EIHRoYXQgdGhlIGN1cnJlbnQgd29yay1hcm91 bmQgaXMgdG8gdXNlIG11bHRpcGxlIHJvdW5kcyBvZiBoYXNoZXMgKDEwMHggb3IgMTAwMHgpLg0K DQpIb3cgbWFueSBoYXNoIHJvdW5kcyB3b3VsZCBiZSBzdWZmaWNpZW50IHRvIG1ha2UgaXQgZXF1 YWxseSBzZWN1cmUgY29tcGFyZWQgdG8geW91ciBwcm9wb3NhbCAocHVibGljIGtleSBlbmNyeXB0 aW9uKT8gKE15IGd1dCBmZWVsaW5nIHNheXMgMTAuMDAwIHNoYTUxMiBhcmUgbW9yZSBleHBlbnNp dmUgdGhhbiAxeCAyMDQ4IHJzYSBlbmNyeXB0IGJ1dCBJIGRvIG5vdCBoYXZlIGZpZ3VyZXMgaW4g ZnJvbnQgb2YgbWUuIEJvdGggYWxnb3JpdGhtcyBhcmUgYXZhaWxhYmxlIGluIGhhcmR3YXJlIFtn cHUsIHZlcmlsb2csIC4uXSkuDQpXaGF0IGlzIHRoZSBhZHZhbnRhZ2Ugb2YgeW91ciBJLUQgY29t cGFyZWQgdG8ganVzdCBpbmNyZWFzaW5nIHRoZSBoYXNoIHJvdW5kcz8NCg0KcmVnYXJkcywNCg0K cmFsZg0KDQoNCk9uIFN1biwgRGVjIDgsIDIwMTMgYXQgMzo1MSBQTSwgUm9iZXJ0IEtpc3RlbGVr aSA8cm9iZXJ0QHJpcGUubmV0PG1haWx0bzpyb2JlcnRAcmlwZS5uZXQ+PiB3cm90ZToNCkhlbGxv LA0KDQpBcyB5b3UgbWF5IGhhdmUgbm90aWNlZCwgSSBjcmVhdGVkIGEgZHJhZnQgYWJvdXQgaG93 IGFuZCB3aHkgdG8gYWRkDQphc3ltbWV0cmljIGVuY3J5cHRpb24gdG8gcGFzc3dvcmQgc3RvcmFn ZS4NCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2ktZC1hbm5vdW5jZS9j dXJyZW50L21zZzU1NDM3Lmh0bWwNCg0KUGxlYXNlIGxldCBtZSBrbm93IGlmIHlvdSBoYXZlIGNv bW1lbnRzIG9yIHN1Z2dlc3Rpb25zLg0KDQpSZWdhcmRzLA0KUm9iZXJ0DQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzYWFnIG1haWxpbmcgbGlzdA0K c2FhZ0BpZXRmLm9yZzxtYWlsdG86c2FhZ0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2FhZw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpzYWFnIG1haWxpbmcgbGlzdA0Kc2FhZ0BpZXRmLm9yZzxtYWls dG86c2FhZ0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2FhZw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpzYWFnIG1haWxpbmcgbGlzdA0Kc2FhZ0BpZXRmLm9yZzxtYWlsdG86c2FhZ0BpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FhZw0KDQo= --_000_1C9F17D1873AFA47A969C4DD98F98A750FA95D8Dxmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxl LW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYXQgaXMgYW4gaW50ZXJlc3Rpbmcgc2NoZW1lIGFs c28uIEkgYW0gbm90IHN1cmUgaWYgdXNpbmcgZW5jcnlwdGlvbiB3b3VsZCBvZmZlciBtb3JlIGJl bmVmaXQgdGhhbiB0aGF0IHNjaGVtZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5B ZGRpdGlvbmFsbHksIGRlcGVuZGluZyBvbiB0aGUgcm91bmRzLCBzb21lb25lIGNvdWxkIG1ha2Ug dGhlIHBhc3N3b3JkIGd1ZXNzaW5nIGFzIGhhcmQgYXMgaGUgd2FudGVkLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TXkg cXVlc3Rpb24gaW4gdGhpcyBjYXNlIHdvdWxkIGJlLCBob3cgbWFueSByb3VuZC1iaXRzIGRvZXMg c29tZW9uZSBuZWVkIHRvIGFwcHJveGltYXRlbHkgaGF2ZSB0aGUgc2FtZSBvdmVyaGVhZCBhcyBh biBlbmNyeXB0aW9uIG9wZXJhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBhbm9zPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBzYWFnIFttYWlsdG86c2FhZy1ib3VuY2VzQGlldGYub3Jn XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5TY290dCBSLiBDb3J6aW5lPGJyPg0KPGI+U2VudDo8L2I+ IE1vbmRheSwgRGVjZW1iZXIgMDksIDIwMTMgMjowMiBQTTxicj4NCjxiPlRvOjwvYj4gUmljaGFy ZCBCYXJuZXM8YnI+DQo8Yj5DYzo8L2I+IElFVEYgU0FBRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW3NhYWddIE5ldyBJLUQ6IFBhc3N3b3JkIFN0b3JhZ2UgVXNpbmcgUHVibGljIEtleSBFbmNy eXB0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hhdCBpZiB5b3Ug d2VyZSB0byByYW5kb21seSBnZW5lcmF0ZSB0aGUgbnVtYmVyIG9mIHJvdW5kcyBhbmQgdGhlbiBz YXZlIGl0IGFzIHdlIGN1cnJlbnRseSBkbyBmb3IgYSBzYWx0PyAmbmJzcDtGb3IgaW1wbGVtZW50 YXRpb25zIHdoaWNoIHByb3ZpZGUgZm9yIHNwZWNpZmljIHN0b3JhZ2Ugb2Ygc2FsdCAmIzQzOyBo YXNoIGJ1dCBhcmVuJ3QgZmxleGlibGUgZW5vdWdoIHRvIGFjY29tbW9kYXRlIHNhbHQmIzQzO3Jv dW5kcyYjNDM7aGFzaA0KIHlvdSBjb3VsZCB1c2UgdGhlIGtsdWRnZSBvZiB1c2luZyB0aGUgbGFz dCBuIGJpdHMgKHNheSAxNikgb2YgdGhlIHNhbHQgdG8gZG91YmxlIGFzIHRoZSBudW1iZXIgb2Yg cm91bmRzIChvciBhZGQgc2F5IDEwMDAgdG8gaXQgdG8gZW5zdXJlIGEgbWluaW11bSBudW1iZXIg b2Ygcm91bmRzKS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi1TY290dC08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIERlYyA5LCAyMDEzIGF0 IDExOjAyIEFNLCBSaWNoYXJkIEJhcm5lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJsYkBpcHYuc3gi IHRhcmdldD0iX2JsYW5rIj5ybGJAaXB2LnN4PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBtYXkgYmUgbWlzdW5kZXJzdGFuZGluZyB0 aGluZ3MsIGJ1dCB3aGVuIEkgcmVhZCB0aGUgZG9jdW1lbnQsIGl0IHNlZW1lZCBsaWtlIHRoZSBu dW1iZXIgb2Ygcm91bmRzIGRpZG4ndCBhY3R1YWxseSBtYXR0ZXIuICZuYnNwO0FzIGxvbmcgYXMg cGVvcGxlIHVzZSBhIHJlbGF0aXZlbHkgZml4ZWQgc2V0IG9mIGNob2ljZXMgZm9yIHRoZSBudW1i ZXIgb2Ygcm91bmRzIChzYXkgMTAsIDEwMCwgMTAwMCksIGFuIGF0dGFja2VyDQogY2FuIGJ1aWxk IGEgcmFpbmJvdyB0YWJsZSBmb3IgdGhhdCBudW1iZXIgb2Ygcm91bmRzLiAmbmJzcDtJdCBtYXkg YmUgMTB4IC8gMTAweCAvIDEwMDB4IG1vcmUgZXhwZW5zaXZlIHRvIGJ1aWxkIHRoYXQgdGFibGUs IGJ1dCBpdCBtYXkgYWxzbyBiZSBwb3NzaWJsZSB0byBvcHRpbWl6ZSAxMDAweFNIQTEgdG8gYnJp bmcgZG93biB0aGF0IGNvc3QgKGFuZCAxMDAweCBpcyBub3QgYSBodWdlIG51bWJlciBhbnl3YXkp LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gaWYgSSdt IHVuZGVyc3RhbmRpbmcgdGhpbmdzIGNvcnJlY3RseSBoZXJlLCB0aGUgbWl0aWdhdGlvbiB3b3Vs ZCBiZSB0byBoYXZlIGEgbGFyZ2UgKmFuZCogKnJhbmRvbWl6ZWQqIG51bWJlciBvZiByb3VuZHMu ICZuYnNwO1doaWNoIHNlZW1zIGxpa2UgbW9yZSBvZiBhIGhhc3NsZSB0byBtYW5hZ2UgdGhhbiBS b2JlcnQncyBwcm9wb3NhbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6Izg4ODg4OCI+LS1SaWNoYXJkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBEZWMgOSwgMjAxMyBhdCA0OjM4IEFNLCBSYWxm IFNreXBlciBLYWlzZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpza3lwZXJAdGhjLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPnNreXBlckB0aGMub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhp LDxicj4NCjxicj4NCnRoYW5rcyBmb3IgdGhlIEktRC4gSW50ZXJlc3RpbmcgaWRlYS4gSXQgc29s dmVzIHNvbWUgKGJ1dCBub3QgYWxsKSBwcm9ibGVtcyBvZiBwYXNzd29yZCBhdXRoZW50aWNhdGlv bi4gSSBoYXZlIHNvbWUgcXVlc3Rpb25zIGFib3V0IHRoZSBhZHZhbnRhZ2VzIG9mIHlvdXIgSS1E IGNvbXBhcmVkIHRvIHRoZSBjdXJyZW50IHdvcmsgYXJvdW5kIHRoYXQgeW91IG1lbnRpb246PGJy Pg0KPGJyPg0KWW91IG1lbnRpb24gaW4gdGhlIEktRCB0aGF0IHRoZSBjdXJyZW50IHdvcmstYXJv dW5kIGlzIHRvIHVzZSBtdWx0aXBsZSByb3VuZHMgb2YgaGFzaGVzICgxMDB4IG9yIDEwMDB4KS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+SG93IG1hbnkgaGFzaCByb3VuZHMgd291bGQgYmUgc3VmZmljaWVudCB0byBt YWtlIGl0IGVxdWFsbHkgc2VjdXJlIGNvbXBhcmVkIHRvIHlvdXIgcHJvcG9zYWwgKHB1YmxpYyBr ZXkgZW5jcnlwdGlvbik/IChNeSBndXQgZmVlbGluZyBzYXlzIDEwLjAwMCBzaGE1MTIgYXJlIG1v cmUgZXhwZW5zaXZlIHRoYW4gMXggMjA0OCByc2EgZW5jcnlwdCBidXQgSSBkbyBub3QNCiBoYXZl IGZpZ3VyZXMgaW4gZnJvbnQgb2YgbWUuIEJvdGggYWxnb3JpdGhtcyBhcmUgYXZhaWxhYmxlIGlu IGhhcmR3YXJlIFtncHUsIHZlcmlsb2csIC4uXSkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+V2hhdCBpcyB0 aGUgYWR2YW50YWdlIG9mIHlvdXIgSS1EIGNvbXBhcmVkIHRvIGp1c3QgaW5jcmVhc2luZyB0aGUg aGFzaCByb3VuZHM/PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPnJlZ2FyZHMsPGJyPg0KPGJyPg0KcmFsZjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU3VuLCBEZWMgOCwgMjAxMyBhdCAzOjUx IFBNLCBSb2JlcnQgS2lzdGVsZWtpICZsdDs8YSBocmVmPSJtYWlsdG86cm9iZXJ0QHJpcGUubmV0 IiB0YXJnZXQ9Il9ibGFuayI+cm9iZXJ0QHJpcGUubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyw8YnI+DQo8YnI+DQpBcyB5b3UgbWF5 IGhhdmUgbm90aWNlZCwgSSBjcmVhdGVkIGEgZHJhZnQgYWJvdXQgaG93IGFuZCB3aHkgdG8gYWRk PGJyPg0KYXN5bW1ldHJpYyBlbmNyeXB0aW9uIHRvIHBhc3N3b3JkIHN0b3JhZ2UuPGJyPg0KPGJy Pg0KPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2ktZC1hbm5v dW5jZS9jdXJyZW50L21zZzU1NDM3Lmh0bWwiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3Lmll dGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaS1kLWFubm91bmNlL2N1cnJlbnQvbXNnNTU0MzcuaHRt bDwvYT48YnI+DQo8YnI+DQpQbGVhc2UgbGV0IG1lIGtub3cgaWYgeW91IGhhdmUgY29tbWVudHMg b3Igc3VnZ2VzdGlvbnMuPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQpSb2JlcnQ8YnI+DQo8YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNh YWcgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNhYWdAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5zYWFnQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FhZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FhZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0Kc2FhZyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c2FhZ0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNhYWdAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWFnIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWFnPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpzYWFnIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpzYWFnQGlldGYub3JnIj5zYWFnQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FhZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FhZzwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_1C9F17D1873AFA47A969C4DD98F98A750FA95D8Dxmbrcdx10ciscoc_-- From skyper@thc.org Tue Dec 10 12:18:18 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425221AE068 for ; Tue, 10 Dec 2013 12:18:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tS1JIFM0aBOa for ; Tue, 10 Dec 2013 12:18:16 -0800 (PST) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6961AE067 for ; Tue, 10 Dec 2013 12:18:16 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id e14so9565130iej.12 for ; Tue, 10 Dec 2013 12:18:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6YfAXgCvHp4Lz2SmMpMxJQGfS9eRXwA4OV+r5QOFeHA=; b=cdrR/dD0F40LVhxxqBbT/2AyRX+vUalhe6VPcaKgNtisGpDafDu89MvUMF6Ehzch+3 sJdfJq37eIrigSBN1DGrltbXzATVyrZn7dYpr/uwsPzkbQT9OIgs6GRQLbTseNbUWcTQ frnU7Srv1aID2W8p+Z5CtE75XOXFP7Pqr3nJM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6YfAXgCvHp4Lz2SmMpMxJQGfS9eRXwA4OV+r5QOFeHA=; b=XV9hZGu0EBu7pgP5Cv5KSTxZEFoZJ3YwRYRZd0B9Qe5tpnxuHubI8p1UTxvL4nNDD+ IvaG9Ow91WaEEEE0MwxY4Fy8k1cTvFvIag7TqmDgu1DZmHIOUs2f273UXJtZ+gldihv8 TQhNufJ87NepxT+nBPxlRQKgV8Q2UkNz9+SH+Obrgn1Xf4Qmt7HJ7XepRpUkPOZOc6SJ 6G4xHL48QENz99QUnlfWTbynIAtTsKPBYgswFM6ZlE7jl8I5OnWVPLzHNQPUBDsCGkUl dh2wW5eQiCsjMYPoobfor68twNaAx9QWmygwaz0+mrXho6Mp9LXmq58zGl9ZgYAmlyq/ olEA== X-Gm-Message-State: ALoCoQlGBmp/sxqN3UPmyoUzCtgSJixG8VIV3acjwd7m3YQbpQATWA91eoxbhfwF0RilsSZPhf4W MIME-Version: 1.0 X-Received: by 10.50.25.129 with SMTP id c1mr21568128igg.23.1386706690915; Tue, 10 Dec 2013 12:18:10 -0800 (PST) Received: by 10.64.9.41 with HTTP; Tue, 10 Dec 2013 12:18:10 -0800 (PST) X-Originating-IP: [80.195.189.45] In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A750FA95D8D@xmb-rcd-x10.cisco.com> References: <52A49582.4070307@ripe.net> <1C9F17D1873AFA47A969C4DD98F98A750FA95D8D@xmb-rcd-x10.cisco.com> Date: Tue, 10 Dec 2013 20:18:10 +0000 Message-ID: From: Ralf Skyper Kaiser To: "Panos Kampanakis (pkampana)" Content-Type: multipart/alternative; boundary=047d7bdc10ecb8587404ed33cfa9 Cc: "Scott R. Corzine" , IETF SAAG Subject: Re: [saag] New I-D: Password Storage Using Public Key Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 20:18:18 -0000 --047d7bdc10ecb8587404ed33cfa9 Content-Type: text/plain; charset=ISO-8859-1 Hi, On my server (AMD Athlon(tm) 64 Processor 3500+) openssl speed sha512 rsa2048 sha512 on 512 bit: 59768k / second rsa2048 encrypt 9430 / second 59768 * 1024 / 9430 = 6490 SHA512 are as expensive as 1 RSA-2048_encrypt. regards, skyper On Tue, Dec 10, 2013 at 8:02 PM, Panos Kampanakis (pkampana) < pkampana@cisco.com> wrote: > That is an interesting scheme also. I am not sure if using encryption > would offer more benefit than that scheme. > > Additionally, depending on the rounds, someone could make the password > guessing as hard as he wanted. > > > > My question in this case would be, how many round-bits does someone need > to approximately have the same overhead as an encryption operation. > > > > Panos > > > > > > > > > > *From:* saag [mailto:saag-bounces@ietf.org] *On Behalf Of *Scott R. > Corzine > *Sent:* Monday, December 09, 2013 2:02 PM > *To:* Richard Barnes > *Cc:* IETF SAAG > *Subject:* Re: [saag] New I-D: Password Storage Using Public Key > Encryption > > > > What if you were to randomly generate the number of rounds and then save > it as we currently do for a salt? For implementations which provide for > specific storage of salt + hash but aren't flexible enough to accommodate > salt+rounds+hash you could use the kludge of using the last n bits (say 16) > of the salt to double as the number of rounds (or add say 1000 to it to > ensure a minimum number of rounds). > > > > -Scott- > > > > On Mon, Dec 9, 2013 at 11:02 AM, Richard Barnes wrote: > > I may be misunderstanding things, but when I read the document, it seemed > like the number of rounds didn't actually matter. As long as people use a > relatively fixed set of choices for the number of rounds (say 10, 100, > 1000), an attacker can build a rainbow table for that number of rounds. It > may be 10x / 100x / 1000x more expensive to build that table, but it may > also be possible to optimize 1000xSHA1 to bring down that cost (and 1000x > is not a huge number anyway). > > > > So if I'm understanding things correctly here, the mitigation would be to > have a large *and* *randomized* number of rounds. Which seems like more of > a hassle to manage than Robert's proposal. > > > > --Richard > > > > On Mon, Dec 9, 2013 at 4:38 AM, Ralf Skyper Kaiser wrote: > > Hi, > > thanks for the I-D. Interesting idea. It solves some (but not all) > problems of password authentication. I have some questions about the > advantages of your I-D compared to the current work around that you mention: > > You mention in the I-D that the current work-around is to use multiple > rounds of hashes (100x or 1000x). > > > > How many hash rounds would be sufficient to make it equally secure > compared to your proposal (public key encryption)? (My gut feeling says > 10.000 sha512 are more expensive than 1x 2048 rsa encrypt but I do not have > figures in front of me. Both algorithms are available in hardware [gpu, > verilog, ..]). > > What is the advantage of your I-D compared to just increasing the hash > rounds? > > regards, > > ralf > > > > > > On Sun, Dec 8, 2013 at 3:51 PM, Robert Kisteleki wrote: > > Hello, > > As you may have noticed, I created a draft about how and why to add > asymmetric encryption to password storage. > > http://www.ietf.org/mail-archive/web/i-d-announce/current/msg55437.html > > Please let me know if you have comments or suggestions. > > Regards, > Robert > > _______________________________________________ > 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 > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > --047d7bdc10ecb8587404ed33cfa9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

On my server (AMD Athlon(tm= ) 64 Processor 3500+)

openssl speed sha512 rsa2048

sha5= 12 on 512 bit: 59768k / second
rsa2048 encrypt 9430 / second
59768 * 1024 / 9430 =3D 6490 SHA512 are as expensive as 1 RSA-2048_en= crypt.


regards,

skyper

<= /div>


On Tue, Dec 10, 2013 at 8:02 PM, Panos Kampanakis (pkampana) <pkampana@ci= sco.com> wrote:

That is an interesting sc= heme also. I am not sure if using encryption would offer more benefit than = that scheme.

Additionally, depending o= n the rounds, someone could make the password guessing as hard as he wanted= .

=A0<= /p>

My question in this case = would be, how many round-bits does someone need to approximately have the s= ame overhead as an encryption operation.

=A0<= /p>

Panos

=A0<= /p>

=A0<= /p>

=A0<= /p>

=A0<= /p>

From: saag [ma= ilto:saag-bounce= s@ietf.org] On Behalf Of Scott R. Corzine
Sent: Monday, December 09, 2013 2:02 PM
To: Richard Barnes
Cc: IETF SAAG
Subject: Re: [saag] New I-D: Password Storage Using Public Key Encry= ption

=A0

What if you were to randomly generate the number of = rounds and then save it as we currently do for a salt? =A0For implementatio= ns which provide for specific storage of salt + hash but aren't flexibl= e enough to accommodate salt+rounds+hash you could use the kludge of using the last n bits (say 16) of the salt to = double as the number of rounds (or add say 1000 to it to ensure a minimum n= umber of rounds).

=A0

-Scott-

=A0

On Mon, Dec 9, 2013 at 11:02 AM, Richard Barnes <= rlb@ipv.sx> wrote:

I may be misunderstanding things, but when I read th= e document, it seemed like the number of rounds didn't actually matter.= =A0As long as people use a relatively fixed set of choices for the number = of rounds (say 10, 100, 1000), an attacker can build a rainbow table for that number of rounds. =A0It may be 10x / 10= 0x / 1000x more expensive to build that table, but it may also be possible = to optimize 1000xSHA1 to bring down that cost (and 1000x is not a huge numb= er anyway).

=A0

So if I'm understanding things correctly here, t= he mitigation would be to have a large *and* *randomized* number of rounds.= =A0Which seems like more of a hassle to manage than Robert's proposal.=

=A0

--Richard

=A0

On Mon, Dec 9, 2013 at 4:38 AM, Ralf Skyper Kaiser &= lt;skyper@thc.org&g= t; wrote:

Hi,

thanks for the I-D. Interesting idea. It solves some (but not all) problems= of password authentication. I have some questions about the advantages of = your I-D compared to the current work around that you mention:

You mention in the I-D that the current work-around is to use multiple roun= ds of hashes (100x or 1000x).

=A0

How many hash rounds = would be sufficient to make it equally secure compared to your proposal (pu= blic key encryption)? (My gut feeling says 10.000 sha512 are more expensive= than 1x 2048 rsa encrypt but I do not have figures in front of me. Both algorithms are available in hardware [gp= u, verilog, ..]).

What is the advantage= of your I-D compared to just increasing the hash rounds?

regards,

ralf

=A0

=A0

On Sun, Dec 8, 2013 at 3:51 PM, Robert Kisteleki <= ;robert@ripe.net&g= t; wrote:

Hello,

As you may have noticed, I created a draft about how and why to add
asymmetric encryption to password storage.

http://www.ietf.org/mail-archive/web/i-d-announc= e/current/msg55437.html

Please let me know if you have comments or suggestions.

Regards,
Robert

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

=A0


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

=A0


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

=A0


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


--047d7bdc10ecb8587404ed33cfa9-- From pkampana@cisco.com Tue Dec 10 12:29:37 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77211AE219 for ; Tue, 10 Dec 2013 12:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0P3Y193beK1 for ; Tue, 10 Dec 2013 12:29:33 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 52F151AE1A1 for ; Tue, 10 Dec 2013 12:29:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21442; q=dns/txt; s=iport; t=1386707368; x=1387916968; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1s8cxSbYingZ1D/jgu3wMXxElssowYnVq+mnvqeWxXo=; b=mBK5CPtaVxd6a15JIoJekHAeZmip+Vk82NDea+3bLV9nWEz+FWLOFWIZ /ok3hRkErBUbX4nsIg198hd1R9XZCknbtSJX1aRpZ2B8Sc1c5CLza/pIE wzGVGK/cKCYpb+FSJODT8pxJOz0VHEgV06NBdmvtayK5qQA/u+C0rlWh0 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAAB5p1KtJXG9/2dsb2JhbABZgkNEOFO5HYEhFnSCJQEBAQQBAQEqQQsQAgEIEQQBAQsOCAcHJwsUCQgCBA4FCAGHeQ3BExeONAEBBhgtBAYBGIMJgRMEqieDKYFpCBci X-IronPort-AV: E=Sophos;i="4.93,866,1378857600"; d="scan'208,217";a="290680035" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 10 Dec 2013 20:29:27 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rBAKTRwx027099 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Dec 2013 20:29:27 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Tue, 10 Dec 2013 14:29:26 -0600 From: "Panos Kampanakis (pkampana)" To: Ralf Skyper Kaiser Thread-Topic: [saag] New I-D: Password Storage Using Public Key Encryption Thread-Index: AQHO9eTxfkmjs89V406H5CSpI82QbppN3zaQ Date: Tue, 10 Dec 2013 20:29:26 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A750FA95E2E@xmb-rcd-x10.cisco.com> References: <52A49582.4070307@ripe.net> <1C9F17D1873AFA47A969C4DD98F98A750FA95D8D@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.89.107] Content-Type: multipart/alternative; boundary="_000_1C9F17D1873AFA47A969C4DD98F98A750FA95E2Exmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "Scott R. Corzine" , IETF SAAG Subject: Re: [saag] New I-D: Password Storage Using Public Key Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 20:29:38 -0000 --_000_1C9F17D1873AFA47A969C4DD98F98A750FA95E2Exmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you Ralf. So, for SH256 or SH512 16 bits could give approximately as much or more ove= rhead as 2048-bit RSA. With SHA-3, maybe more might bits will be needed, bu= t not necessarily to many more. Again, the benefit of such a scheme is that by changing the rounds, the pas= sword guessing can be made harder. I am wondering if there is a benefit to = using encryption over variable rounds. I can't see any, except possibly if = the salt's last x-bits could not be assumed uniformly distributed. Panos From: Ralf Skyper Kaiser [mailto:skyper@thc.org] Sent: Tuesday, December 10, 2013 3:18 PM To: Panos Kampanakis (pkampana) Cc: Scott R. Corzine; Richard Barnes; IETF SAAG Subject: Re: [saag] New I-D: Password Storage Using Public Key Encryption Hi, On my server (AMD Athlon(tm) 64 Processor 3500+) openssl speed sha512 rsa2048 sha512 on 512 bit: 59768k / second rsa2048 encrypt 9430 / second 59768 * 1024 / 9430 =3D 6490 SHA512 are as expensive as 1 RSA-2048_encrypt. regards, skyper On Tue, Dec 10, 2013 at 8:02 PM, Panos Kampanakis (pkampana) > wrote: That is an interesting scheme also. I am not sure if using encryption would= offer more benefit than that scheme. Additionally, depending on the rounds, someone could make the password gues= sing as hard as he wanted. My question in this case would be, how many round-bits does someone need to= approximately have the same overhead as an encryption operation. Panos From: saag [mailto:saag-bounces@ietf.org] On = Behalf Of Scott R. Corzine Sent: Monday, December 09, 2013 2:02 PM To: Richard Barnes Cc: IETF SAAG Subject: Re: [saag] New I-D: Password Storage Using Public Key Encryption What if you were to randomly generate the number of rounds and then save it= as we currently do for a salt? For implementations which provide for spec= ific storage of salt + hash but aren't flexible enough to accommodate salt+= rounds+hash you could use the kludge of using the last n bits (say 16) of t= he salt to double as the number of rounds (or add say 1000 to it to ensure = a minimum number of rounds). -Scott- On Mon, Dec 9, 2013 at 11:02 AM, Richard Barnes > wrote: I may be misunderstanding things, but when I read the document, it seemed l= ike the number of rounds didn't actually matter. As long as people use a r= elatively fixed set of choices for the number of rounds (say 10, 100, 1000)= , an attacker can build a rainbow table for that number of rounds. It may = be 10x / 100x / 1000x more expensive to build that table, but it may also b= e possible to optimize 1000xSHA1 to bring down that cost (and 1000x is not = a huge number anyway). So if I'm understanding things correctly here, the mitigation would be to h= ave a large *and* *randomized* number of rounds. Which seems like more of = a hassle to manage than Robert's proposal. --Richard On Mon, Dec 9, 2013 at 4:38 AM, Ralf Skyper Kaiser > wrote: Hi, thanks for the I-D. Interesting idea. It solves some (but not all) problems= of password authentication. I have some questions about the advantages of = your I-D compared to the current work around that you mention: You mention in the I-D that the current work-around is to use multiple roun= ds of hashes (100x or 1000x). How many hash rounds would be sufficient to make it equally secure compared= to your proposal (public key encryption)? (My gut feeling says 10.000 sha5= 12 are more expensive than 1x 2048 rsa encrypt but I do not have figures in= front of me. Both algorithms are available in hardware [gpu, verilog, ..])= . What is the advantage of your I-D compared to just increasing the hash roun= ds? regards, ralf On Sun, Dec 8, 2013 at 3:51 PM, Robert Kisteleki > wrote: Hello, As you may have noticed, I created a draft about how and why to add asymmetric encryption to password storage. http://www.ietf.org/mail-archive/web/i-d-announce/current/msg55437.html Please let me know if you have comments or suggestions. Regards, Robert _______________________________________________ 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 _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --_000_1C9F17D1873AFA47A969C4DD98F98A750FA95E2Exmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank you Ralf.

So, for SH256 or SH512 16= bits could give approximately as much or more overhead as 2048-bit RSA. Wi= th SHA-3, maybe more might bits will be needed, but not necessarily to many more.

 <= /p>

Again, the benefit of suc= h a scheme is that by changing the rounds, the password guessing can be mad= e harder. I am wondering if there is a benefit to using encryption over variable rounds. I can’t see any, except possibly if= the salt’s last x-bits could not be assumed uniformly distributed.

 <= /p>

Panos

 <= /p>

 <= /p>

 <= /p>

From: Ralf Sky= per Kaiser [mailto:skyper@thc.org]
Sent: Tuesday, December 10, 2013 3:18 PM
To: Panos Kampanakis (pkampana)
Cc: Scott R. Corzine; Richard Barnes; IETF SAAG
Subject: Re: [saag] New I-D: Password Storage Using Public Key Encry= ption

 

Hi,

On my server (AMD Athlon(tm) 64 Processor 3500+)

openssl speed sha512 rsa2048

sha512 on 512 bit: 59768k / second

rsa2048 encrypt 9430 = / second

59768 * 1024 / 9430 = =3D 6490 SHA512 are as expensive as 1 RSA-2048_encrypt.

regards,

skyper

 

 

On Tue, Dec 10, 2013 at 8:02 PM, Panos Kampanakis (p= kampana) <pkampa= na@cisco.com> wrote:

That is an interesting scheme also. I a= m not sure if using encryption would offer more benefit than that scheme.

Additionally, depending on the rounds, = someone could make the password guessing as hard as he wanted.<= /o:p>

 

My question in this case would be, how = many round-bits does someone need to approximately have the same overhead as an encryption operation.

 

Panos

 

 

 

 

From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Scott R. Corzine
Sent: Monday, December 09, 2013 2:02 PM
To: Richard Barnes
Cc: IETF SAAG
Subject: Re: [saag] New I-D: Password Storage Using Public Key Encry= ption

 

What if you were to randomly generate the number of rounds and the= n save it as we currently do for a salt?  For implementations which pr= ovide for specific storage of salt + hash but aren't flexible enough to accommodate salt+rounds+hash you cou= ld use the kludge of using the last n bits (say 16) of the salt to double a= s the number of rounds (or add say 1000 to it to ensure a minimum number of= rounds).

 

-Scott-

 

On Mon, Dec 9, 2013 at 11:02 AM, Richard Barnes <rlb@ipv.sx> wrote:

I may be misunderstanding things, but when I read the document, it= seemed like the number of rounds didn't actually matter.  As long as = people use a relatively fixed set of choices for the number of rounds (say 10, 100, 1000), an attacker can build a rain= bow table for that number of rounds.  It may be 10x / 100x / 1000x mor= e expensive to build that table, but it may also be possible to optimize 10= 00xSHA1 to bring down that cost (and 1000x is not a huge number anyway).

 

So if I'm understanding things correctly here, the mitigation woul= d be to have a large *and* *randomized* number of rounds.  Which seems= like more of a hassle to manage than Robert's proposal.

 

--Richard

 

On Mon, Dec 9, 2013 at 4:38 AM, Ralf Skyper Kaiser <skyper@thc.org> wrote:=

Hi,

thanks for the I-D. Interesting idea. It solves some (but not all) problems= of password authentication. I have some questions about the advantages of = your I-D compared to the current work around that you mention:

You mention in the I-D that the current work-around is to use multiple roun= ds of hashes (100x or 1000x).

 

How many hash rounds would be sufficient to make it equally secure compa= red to your proposal (public key encryption)? (My gut feeling says 10.000 s= ha512 are more expensive than 1x 2048 rsa encrypt but I do not have figures in front of me. Both algorithms are = available in hardware [gpu, verilog, ..]).

What is the advantage of your I-D compared to just increasing the hash r= ounds?

regards,

ralf

 

 

On Sun, Dec 8, 2013 at 3:51 PM, Robert Kisteleki <robert@ripe.net> wrote:=

Hello,

As you may have noticed, I created a draft about how and why to add
asymmetric encryption to password storage.

http://www.ietf.org/mail-archive/web/i-d-announc= e/current/msg55437.html

Please let me know if you have comments or suggestions.

Regards,
Robert

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

 


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

 


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

 


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

 

--_000_1C9F17D1873AFA47A969C4DD98F98A750FA95E2Exmbrcdx10ciscoc_-- From rlb@ipv.sx Tue Dec 10 14:16:38 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F361AE08B for ; Tue, 10 Dec 2013 14:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fra3H9YXhVqc for ; Tue, 10 Dec 2013 14:16:35 -0800 (PST) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF7A1AE06D for ; Tue, 10 Dec 2013 14:16:35 -0800 (PST) Received: by mail-ob0-f179.google.com with SMTP id wm4so6042212obc.38 for ; Tue, 10 Dec 2013 14:16:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ui6EQ3YjspaJ6BX2+cm/lGxoo5qNKJK8RB506++HQgA=; b=dlfQenOCCRonct8JEG+Rl6piKtL7f7qXbbMm+ONSzGOwMmbGZTuHHlpdiBVUM7D0ul Kzknv/CGJCcf/udTiZ+iN7BmJ8rsK4Po4rXY6y3mbp/hiumdy7nb/v6DDGBpqb7NMSlG Bpt+kwn461/zb3G4c9T2Z26rOkINu0zrN3/n8yDD/y/fMHj7e3YYbcE1SrJRvP1M5KOb bbNwheS0JZBT1Tfgz+Z+5gPdnW4s1ib+4rKF6YmE7VXFxC3SHBk9orMfhminfFF3bU0Z /lxVTqhXbdlVxSjagF07z919mvAKgZV9tPsEDeJmsNUgLCWJLtZ+e2pYvuZBGJQFkIVL +6oA== X-Gm-Message-State: ALoCoQmMCuqKi8BWEzkGErrTXQUPvnZVKdUEVVcBLqQKK82LC7tPesGD2tsG9ZIkjbUDzVpKBWpZ MIME-Version: 1.0 X-Received: by 10.60.63.102 with SMTP id f6mr2012597oes.76.1386713790001; Tue, 10 Dec 2013 14:16:30 -0800 (PST) Received: by 10.60.31.74 with HTTP; Tue, 10 Dec 2013 14:16:29 -0800 (PST) In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A750FA95E2E@xmb-rcd-x10.cisco.com> References: <52A49582.4070307@ripe.net> <1C9F17D1873AFA47A969C4DD98F98A750FA95D8D@xmb-rcd-x10.cisco.com> <1C9F17D1873AFA47A969C4DD98F98A750FA95E2E@xmb-rcd-x10.cisco.com> Date: Tue, 10 Dec 2013 17:16:29 -0500 Message-ID: From: Richard Barnes To: "Panos Kampanakis (pkampana)" Content-Type: multipart/alternative; boundary=001a11c25532dbd5bb04ed35765b Cc: "Scott R. Corzine" , IETF SAAG Subject: Re: [saag] New I-D: Password Storage Using Public Key Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 22:16:38 -0000 --001a11c25532dbd5bb04ed35765b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I did a slightly more thorough (though still anecdotal) comparison using `openssl speed`. The upshot is that one RSA-4096 operation is worth ~44,000 iterations of SHA1 or SHA2. Algorithm Ops Sec Ops/Sec sha1 8166584 3.00 0.00000037 sha256 4309619 3.00 0.00000070 sha512 6191854 3.00 0.00000048 512rsa 110009 9.98 0.00009072 1024rsa 30557 9.90 0.00032398 2048rsa 5271 9.99 0.00189528 4096rsa 611 9.80 0.01603928 Of course, this doesn't account for hardware optimization of any of the algorithms. If you want to do the test on your favorite system (you'll have to add the headings yourself): openssl speed sha1 sha256 sha512 rsa 2>&1 \ > | grep "64 size blocks\|private RSA's" \ > | sed -e "s/^.*: //; s/ bit private RSA/rsa/; s/'s in//; s/s$//;" \ > | perl -lane '$spo =3D $F[2] / $F[0]; printf "%-10s%10d%10d%12.8f\n", $F[1], $F[0], $F[2], $spo;' sha1 8166584 3.00 0.00000037 sha256 4309619 3.00 0.00000070 sha512 6191854 3.00 0.00000048 512rsa 110009 9.98 0.00009072 1024rsa 30557 9.90 0.00032398 2048rsa 5271 9.99 0.00189528 4096rsa 611 9.80 0.01603928 On Tue, Dec 10, 2013 at 3:29 PM, Panos Kampanakis (pkampana) < pkampana@cisco.com> wrote: > Thank you Ralf. > > So, for SH256 or SH512 16 bits could give approximately as much or more > overhead as 2048-bit RSA. With SHA-3, maybe more might bits will be neede= d, > but not necessarily to many more. > > > > Again, the benefit of such a scheme is that by changing the rounds, the > password guessing can be made harder. I am wondering if there is a benefi= t > to using encryption over variable rounds. I can=92t see any, except possi= bly > if the salt=92s last x-bits could not be assumed uniformly distributed. > > > > Panos > > > > > > > > *From:* Ralf Skyper Kaiser [mailto:skyper@thc.org] > *Sent:* Tuesday, December 10, 2013 3:18 PM > *To:* Panos Kampanakis (pkampana) > *Cc:* Scott R. Corzine; Richard Barnes; IETF SAAG > > *Subject:* Re: [saag] New I-D: Password Storage Using Public Key > Encryption > > > > Hi, > > On my server (AMD Athlon(tm) 64 Processor 3500+) > > openssl speed sha512 rsa2048 > > sha512 on 512 bit: 59768k / second > > rsa2048 encrypt 9430 / second > > 59768 * 1024 / 9430 =3D 6490 SHA512 are as expensive as 1 RSA-2048_encryp= t. > > regards, > > skyper > > > > > > On Tue, Dec 10, 2013 at 8:02 PM, Panos Kampanakis (pkampana) < > pkampana@cisco.com> wrote: > > That is an interesting scheme also. I am not sure if using encryption > would offer more benefit than that scheme. > > Additionally, depending on the rounds, someone could make the password > guessing as hard as he wanted. > > > > My question in this case would be, how many round-bits does someone need > to approximately have the same overhead as an encryption operation. > > > > Panos > > > > > > > > > > *From:* saag [mailto:saag-bounces@ietf.org] *On Behalf Of *Scott R. > Corzine > *Sent:* Monday, December 09, 2013 2:02 PM > *To:* Richard Barnes > *Cc:* IETF SAAG > *Subject:* Re: [saag] New I-D: Password Storage Using Public Key > Encryption > > > > What if you were to randomly generate the number of rounds and then save > it as we currently do for a salt? For implementations which provide for > specific storage of salt + hash but aren't flexible enough to accommodate > salt+rounds+hash you could use the kludge of using the last n bits (say 1= 6) > of the salt to double as the number of rounds (or add say 1000 to it to > ensure a minimum number of rounds). > > > > -Scott- > > > > On Mon, Dec 9, 2013 at 11:02 AM, Richard Barnes wrote: > > I may be misunderstanding things, but when I read the document, it seemed > like the number of rounds didn't actually matter. As long as people use = a > relatively fixed set of choices for the number of rounds (say 10, 100, > 1000), an attacker can build a rainbow table for that number of rounds. = It > may be 10x / 100x / 1000x more expensive to build that table, but it may > also be possible to optimize 1000xSHA1 to bring down that cost (and 1000x > is not a huge number anyway). > > > > So if I'm understanding things correctly here, the mitigation would be to > have a large *and* *randomized* number of rounds. Which seems like more = of > a hassle to manage than Robert's proposal. > > > > --Richard > > > > On Mon, Dec 9, 2013 at 4:38 AM, Ralf Skyper Kaiser wrote= : > > Hi, > > thanks for the I-D. Interesting idea. It solves some (but not all) > problems of password authentication. I have some questions about the > advantages of your I-D compared to the current work around that you menti= on: > > You mention in the I-D that the current work-around is to use multiple > rounds of hashes (100x or 1000x). > > > > How many hash rounds would be sufficient to make it equally secure > compared to your proposal (public key encryption)? (My gut feeling says > 10.000 sha512 are more expensive than 1x 2048 rsa encrypt but I do not ha= ve > figures in front of me. Both algorithms are available in hardware [gpu, > verilog, ..]). > > What is the advantage of your I-D compared to just increasing the hash > rounds? > > regards, > > ralf > > > > > > On Sun, Dec 8, 2013 at 3:51 PM, Robert Kisteleki wrote: > > Hello, > > As you may have noticed, I created a draft about how and why to add > asymmetric encryption to password storage. > > http://www.ietf.org/mail-archive/web/i-d-announce/current/msg55437.html > > Please let me know if you have comments or suggestions. > > Regards, > Robert > > _______________________________________________ > 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 > > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > > --001a11c25532dbd5bb04ed35765b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I did a slightly more thorough (though still anecdotal) co= mparison using `openssl speed`. =A0The upshot is that one RSA-4096 operatio= n is worth ~44,000 iterations of SHA1 or SHA2.

Algo= rithm =A0 =A0 =A0 =A0Ops =A0 =A0 =A0 Sec =A0 =A0 Ops/Sec
sha1 =A0 =A0 =A0 =A0 8166584 =A0 =A0 =A03.00 =A00.00000037
s= ha256 =A0 =A0 =A0 4309619 =A0 =A0 =A03.00 =A00.00000070
sha512 = =A0 =A0 =A0 6191854 =A0 =A0 =A03.00 =A00.00000048
512rsa =A0 =A0 = =A0 =A0110009 =A0 =A0 =A09.98 =A00.00009072
1024rsa =A0 =A0 =A0 = =A030557 =A0 =A0 =A09.90 =A00.00032398
2048rsa =A0 =A0 =A0 =A0 5271 =A0 =A0 =A09.99 =A00.00189528
4= 096rsa =A0 =A0 =A0 =A0 =A0611 =A0 =A0 =A09.80 =A00.01603928

Of course, this doesn't account for hardware optimizati= on of any of the algorithms.

If you want to do the test on your favorite system (you= 'll have to add the headings yourself):

o= penssl speed sha1 sha256 sha512 rsa 2>&1 \
> =A0 =A0 | = grep "64 size blocks\|private RSA's" \
> =A0 =A0 | sed -e "s/^.*: //; s/ bit private RSA/rsa/; s/'= ;s in//; s/s$//;" \
> =A0 =A0 | perl -lane '$spo =3D = $F[2] / $F[0]; printf "%-10s%10d%10d%12.8f\n", $F[1], $F[0], $F[2= ], $spo;'
sha1 =A0 =A0 =A0 =A0 8166584 =A0 =A0 =A03.00 =A00.00000037
<= div>sha256 =A0 =A0 =A0 4309619 =A0 =A0 =A03.00 =A00.00000070
sha5= 12 =A0 =A0 =A0 6191854 =A0 =A0 =A03.00 =A00.00000048
512rsa =A0 = =A0 =A0 =A0110009 =A0 =A0 =A09.98 =A00.00009072
1024rsa =A0 =A0 =A0 =A030557 =A0 =A0 =A09.90 =A00.00032398
2048rs= a =A0 =A0 =A0 =A0 5271 =A0 =A0 =A09.99 =A00.00189528
4096rsa =A0 = =A0 =A0 =A0 =A0611 =A0 =A0 =A09.80 =A00.01603928

=


=A0


On Tue,= Dec 10, 2013 at 3:29 PM, Panos Kampanakis (pkampana) <= ;pkampana@cisco.com= > wrote:

Thank you Ralf.=

So, for SH256 or SH512 16= bits could give approximately as much or more overhead as 2048-bit RSA. Wi= th SHA-3, maybe more might bits will be needed, but not necessarily to many more.

=A0<= /p>

Again, the benefit of suc= h a scheme is that by changing the rounds, the password guessing can be mad= e harder. I am wondering if there is a benefit to using encryption over variable rounds. I can=92t see any, except possibly if the= salt=92s last x-bits could not be assumed uniformly distributed.=

=A0<= /p>

Panos

=A0<= /p>

=A0<= /p>

=A0<= /p>

From: Ralf Sky= per Kaiser [mailto:skyp= er@thc.org]
Sent: Tuesday, December 10, 2013 3:18 PM
To: Panos Kampanakis (pkampana)
Cc: Scott R. Corzine; Richard Barnes; IETF SAAG


Subject: Re: [saag] New I-D: Password Storage Using Public Key Encry= ption

=A0

Hi,

On my server (AMD Athlon(tm) 64 Processor 3500+)

openssl speed sha512 rsa2048

sha512 on 512 bit: 59768k / second

rsa2048 encrypt 9430 = / second

59768 * 1024 / 9430 = =3D 6490 SHA512 are as expensive as 1 RSA-2048_encrypt.

regards,

skyper

=A0

=A0

On Tue, Dec 10, 2013 at 8:02 PM, Panos Kampanakis (p= kampana) <pkampa= na@cisco.com> wrote:

That is an interesting sc= heme also. I am not sure if using encryption would offer more benefit than that scheme.

Additionally, depending o= n the rounds, someone could make the password guessing as hard as he wanted= .

=A0<= /p>

My question in this case = would be, how many round-bits does someone need to approximately have the same overhead as an encryption operation.

=A0<= /p>

Panos

=A0<= /p>

=A0<= /p>

=A0<= /p>

=A0<= /p>

From: saag [ma= ilto:saag-bounce= s@ietf.org] On Behalf Of Scott R. Corzine
Sent: Monday, December 09, 2013 2:02 PM
To: Richard Barnes
Cc: IETF SAAG
Subject: Re: [saag] New I-D: Password Storage Using Public Key Encry= ption

=A0

What if you were to randomly generate the number of = rounds and then save it as we currently do for a salt? =A0For implementatio= ns which provide for specific storage of salt + hash but aren't flexible enough to accommodate salt+rounds+hash you could u= se the kludge of using the last n bits (say 16) of the salt to double as th= e number of rounds (or add say 1000 to it to ensure a minimum number of rou= nds).

=A0

-Scott-

=A0

On Mon, Dec 9, 2013 at 11:02 AM, Richard Barnes <= rlb@ipv.sx> wrote:

I may be misunderstanding things, but when I read th= e document, it seemed like the number of rounds didn't actually matter.= =A0As long as people use a relatively fixed set of choices for the number of rounds (say 10, 100, 1000), an attacker can build a rain= bow table for that number of rounds. =A0It may be 10x / 100x / 1000x more e= xpensive to build that table, but it may also be possible to optimize 1000x= SHA1 to bring down that cost (and 1000x is not a huge number anyway).

=A0

So if I'm understanding things correctly here, t= he mitigation would be to have a large *and* *randomized* number of rounds.= =A0Which seems like more of a hassle to manage than Robert's proposal.

=A0

--Richard

=A0

On Mon, Dec 9, 2013 at 4:38 AM, Ralf Skyper Kaiser &= lt;skyper@thc.org&g= t; wrote:

Hi,

thanks for the I-D. Interesting idea. It solves some (but not all) problems= of password authentication. I have some questions about the advantages of = your I-D compared to the current work around that you mention:

You mention in the I-D that the current work-around is to use multiple roun= ds of hashes (100x or 1000x).

=A0

How many hash rounds = would be sufficient to make it equally secure compared to your proposal (pu= blic key encryption)? (My gut feeling says 10.000 sha512 are more expensive= than 1x 2048 rsa encrypt but I do not have figures in front of me. Both algorithms are = available in hardware [gpu, verilog, ..]).

What is the advantage= of your I-D compared to just increasing the hash rounds?

regards,

ralf

=A0

=A0

On Sun, Dec 8, 2013 at 3:51 PM, Robert Kisteleki <= ;robert@ripe.net&g= t; wrote:

Hello,

As you may have noticed, I created a draft about how and why to add
asymmetric encryption to password storage.

http://www.ietf.org/mail-archive/web/i-d-announc= e/current/msg55437.html

Please let me know if you have comments or suggestions.

Regards,
Robert

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

=A0


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

=A0


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

=A0


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

=A0


--001a11c25532dbd5bb04ed35765b-- From skyper@thc.org Tue Dec 10 14:34:18 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6781AE235 for ; Tue, 10 Dec 2013 14:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vp8F34zHd9rr for ; Tue, 10 Dec 2013 14:34:15 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 83F2B1AE17C for ; Tue, 10 Dec 2013 14:34:15 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id as1so9754025iec.41 for ; Tue, 10 Dec 2013 14:34:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JDINJ8SiR9X4NW5sPwqG/SdxgbZndGTnD2f+slj9wbc=; b=an5Lg4a1JVvML6jOiaE5kYwIeVWdhyOwyvmdhtUpLua5e5ilzJNbF77PleKCj3a8p3 qeN6mlXYEmqmI5BUrc7vYZda9w9k/vk65MDFoa8UGIaKC3jXSKUU1a7tdoiWXSYanU5G YhJixB/bv4CzFDDkcbioeRdMZlzYvjLwO4JV0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JDINJ8SiR9X4NW5sPwqG/SdxgbZndGTnD2f+slj9wbc=; b=Mp0Wwq7ZxilfAlGbmGI1bZ22n3JUmXxooDqziE5sEPihwB84eINXZstn4PhgXa3NNO udJbLzKnd/oIfoygkCbfIHuo+HmQMG0dtsl1NfeBOLAchShKGOOUJcJqE+0A15Q1w0Q1 kMvIU3kshrKI/pZmCcyzg2/KxsUQbhcZKYaBwdrICh66cZYG2qIR6McVdc/WRwfHRXDG cCjaK4mznnTkVK8w741NT7gxSZXfQkJfeCQCASM24PdNUgdPDQr7L8/jPbSmDJBAOQB6 XEmd6K40Fy5si+NoptYQtukjbZTMEMytnEzEvzWlvTUjXXE2WTL09Rg9reBoUtvoV5Al eOnQ== X-Gm-Message-State: ALoCoQlm2JVFeol2gu56IRBVNNtiMQN6T+oUDMx/9XSlvXc/eK22g97ji9YODIWqCgyLF15kSnUG MIME-Version: 1.0 X-Received: by 10.50.92.8 with SMTP id ci8mr85362igb.23.1386714850101; Tue, 10 Dec 2013 14:34:10 -0800 (PST) Received: by 10.64.9.41 with HTTP; Tue, 10 Dec 2013 14:34:10 -0800 (PST) X-Originating-IP: [80.195.189.45] In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A750FA95E2E@xmb-rcd-x10.cisco.com> References: <52A49582.4070307@ripe.net> <1C9F17D1873AFA47A969C4DD98F98A750FA95D8D@xmb-rcd-x10.cisco.com> <1C9F17D1873AFA47A969C4DD98F98A750FA95E2E@xmb-rcd-x10.cisco.com> Date: Tue, 10 Dec 2013 22:34:10 +0000 Message-ID: From: Ralf Skyper Kaiser To: "Panos Kampanakis (pkampana)" Content-Type: multipart/alternative; boundary=047d7b10cf270babd204ed35b681 Cc: "Scott R. Corzine" , IETF SAAG Subject: Re: [saag] New I-D: Password Storage Using Public Key Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 22:34:18 -0000 --047d7b10cf270babd204ed35b681 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, On Tue, Dec 10, 2013 at 8:29 PM, Panos Kampanakis (pkampana) < pkampana@cisco.com> wrote: > Thank you Ralf. > > So, for SH256 or SH512 16 bits could give approximately as much or more > overhead as 2048-bit RSA. With SHA-3, maybe more might bits will be neede= d, > but not necessarily to many more. > I do not understand '16 bits could give...'. If the SHA512 is done 6490 times then it takes as long as one 2048-bit RSA encrypt (on my server) I believe multiple SHA512 rounds is less complex to implement and I have no reason to believe that it is less secure (My gut says its more secure. I trust SHA512 _for this application_ more than RNG's, prime numbers and factoring). > > Again, the benefit of such a scheme is that by changing the rounds, the > password guessing can be made harder. I am wondering if there is a benefi= t > to using encryption over variable rounds. I can=92t see any, except possi= bly > if the salt=92s last x-bits could not be assumed uniformly distributed. > You are right, there is also the 3. option of variable number of rounds which I missed in my previous email: 1. use two hashing algorithms 2. use a branch-statement 3. Variable number of SHA512 rounds. Item 1. doubles the attack cost (GPU, FPGA) at no extra (processing)-cost for the user. It does add complexity. Item 2. only slightly increases the attack cost. Item 3. All attacks that would exploit be made harder by this would also be equally made harder by using a random/semi-unique salt (say 64 bit) for each password. regards, ralf Panos > > > > > > > > *From:* Ralf Skyper Kaiser [mailto:skyper@thc.org] > *Sent:* Tuesday, December 10, 2013 3:18 PM > *To:* Panos Kampanakis (pkampana) > *Cc:* Scott R. Corzine; Richard Barnes; IETF SAAG > > *Subject:* Re: [saag] New I-D: Password Storage Using Public Key > Encryption > > > > Hi, > > On my server (AMD Athlon(tm) 64 Processor 3500+) > > openssl speed sha512 rsa2048 > > sha512 on 512 bit: 59768k / second > > rsa2048 encrypt 9430 / second > > 59768 * 1024 / 9430 =3D 6490 SHA512 are as expensive as 1 RSA-2048_encryp= t. > > regards, > > skyper > > > > > > On Tue, Dec 10, 2013 at 8:02 PM, Panos Kampanakis (pkampana) < > pkampana@cisco.com> wrote: > > That is an interesting scheme also. I am not sure if using encryption > would offer more benefit than that scheme. > > Additionally, depending on the rounds, someone could make the password > guessing as hard as he wanted. > > > > My question in this case would be, how many round-bits does someone need > to approximately have the same overhead as an encryption operation. > > > > Panos > > > > > > > > > > *From:* saag [mailto:saag-bounces@ietf.org] *On Behalf Of *Scott R. > Corzine > *Sent:* Monday, December 09, 2013 2:02 PM > *To:* Richard Barnes > *Cc:* IETF SAAG > *Subject:* Re: [saag] New I-D: Password Storage Using Public Key > Encryption > > > > What if you were to randomly generate the number of rounds and then save > it as we currently do for a salt? For implementations which provide for > specific storage of salt + hash but aren't flexible enough to accommodate > salt+rounds+hash you could use the kludge of using the last n bits (say 1= 6) > of the salt to double as the number of rounds (or add say 1000 to it to > ensure a minimum number of rounds). > > > > -Scott- > > > > On Mon, Dec 9, 2013 at 11:02 AM, Richard Barnes wrote: > > I may be misunderstanding things, but when I read the document, it seemed > like the number of rounds didn't actually matter. As long as people use = a > relatively fixed set of choices for the number of rounds (say 10, 100, > 1000), an attacker can build a rainbow table for that number of rounds. = It > may be 10x / 100x / 1000x more expensive to build that table, but it may > also be possible to optimize 1000xSHA1 to bring down that cost (and 1000x > is not a huge number anyway). > > > > So if I'm understanding things correctly here, the mitigation would be to > have a large *and* *randomized* number of rounds. Which seems like more = of > a hassle to manage than Robert's proposal. > > > > --Richard > > > > On Mon, Dec 9, 2013 at 4:38 AM, Ralf Skyper Kaiser wrote= : > > Hi, > > thanks for the I-D. Interesting idea. It solves some (but not all) > problems of password authentication. I have some questions about the > advantages of your I-D compared to the current work around that you menti= on: > > You mention in the I-D that the current work-around is to use multiple > rounds of hashes (100x or 1000x). > > > > How many hash rounds would be sufficient to make it equally secure > compared to your proposal (public key encryption)? (My gut feeling says > 10.000 sha512 are more expensive than 1x 2048 rsa encrypt but I do not ha= ve > figures in front of me. Both algorithms are available in hardware [gpu, > verilog, ..]). > > What is the advantage of your I-D compared to just increasing the hash > rounds? > > regards, > > ralf > > > > > > On Sun, Dec 8, 2013 at 3:51 PM, Robert Kisteleki wrote: > > Hello, > > As you may have noticed, I created a draft about how and why to add > asymmetric encryption to password storage. > > http://www.ietf.org/mail-archive/web/i-d-announce/current/msg55437.html > > Please let me know if you have comments or suggestions. > > Regards, > Robert > > _______________________________________________ > 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 > > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > > --047d7b10cf270babd204ed35b681 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi,


On Tue, Dec 10, 2013 at 8:29 PM, Panos Kampanakis (pkampana) <= pkampana@cisco.com> wrote:

Thank you Ralf.

So, for SH256 or SH5= 12 16 bits could give approximately as much or more overhead as 2048-bit RS= A. With SHA-3, maybe more might bits will be needed, but not necessarily to many more.


I do not understand '16 bits could give...'.

If the SHA512 is done 6490 times then it takes as long as one 2048-bit R= SA encrypt (on my server)

I believe multiple SHA512 rounds is less complex to implemen= t and I have no reason to believe that it is less secure (My gut says its m= ore secure. I trust SHA512 _for this application_ more than RNG's, prim= e numbers and factoring).

=A0

Again, the benefit o= f such a scheme is that by changing the rounds, the password guessing can b= e made harder. I am wondering if there is a benefit to using encryption over variable rounds. I can=92t see any, except possibly if the= salt=92s last x-bits could not be assumed uniformly distributed.


You are right, there is also = the 3. option of variable number of rounds which I missed in my previous em= ail:

1. use two hashing algorithms
2. use a branch-statement <= br>
3. Variable number of SHA512 rounds.

Item 1= . doubles the attack cost (GPU, FPGA) at no extra (processing)-cost for the= user. It does add complexity.
Item 2. only slightly increases the attack cost.
= Item 3. All attacks that would exploit be made harder by this would also be= equally made harder by using a random/semi-unique salt (say 64 bit) for ea= ch password.

regards,

ralf

Panos<= /span>

=A0

=A0

=A0

From: Ralf Skyper = Kaiser [mailto:skyper@t= hc.org]
Sent: Tuesday, December 10, 2013 3:18 PM
To: Panos Kampanakis (pkampana)
Cc: Scott R. Corzine; Richard Barnes; IETF SAAG


Subject: Re: [saag] New I-D: Password Storage Using Public Key Encry= ption

=A0

Hi,

On my server (AMD Athlon(tm) 64 Processor 3500+)

openssl speed sha512 rsa2048

sha512 on 512 bit: 59768k / second

rsa2048 encrypt 9430 / = second

59768 * 1024 / 9430 =3D= 6490 SHA512 are as expensive as 1 RSA-2048_encrypt.

regards,

skyper

=A0

=A0

On Tue, Dec 10, 2013 at 8:02 PM, Panos Kampanakis (p= kampana) <pkampa= na@cisco.com> wrote:

That is an interesti= ng scheme also. I am not sure if using encryption would offer more benefit = than that scheme.

Additionally, depend= ing on the rounds, someone could make the password guessing as hard as he w= anted.

=A0=

My question in this = case would be, how many round-bits does someone need to approximately have = the same overhead as an encryption operation.

=A0=

Panos<= u>

=A0=

=A0=

=A0=

=A0=

From: saag [mailto= :saag-bounces@ie= tf.org] On Behalf Of Scott R. Corzine
Sent: Monday, December 09, 2013 2:02 PM
To: Richard Barnes
Cc: IETF SAAG
Subject: Re: [saag] New I-D: Password Storage Using Public Key Encry= ption

=A0

What if you were to randomly generate the number of = rounds and then save it as we currently do for a salt? =A0For implementatio= ns which provide for specific storage of salt + hash but aren't flexible enough to accommodate salt+rounds+hash you could u= se the kludge of using the last n bits (say 16) of the salt to double as th= e number of rounds (or add say 1000 to it to ensure a minimum number of rou= nds).

=A0

-Scott-

=A0

On Mon, Dec 9, 2013 at 11:02 AM, Richard Barnes <= rlb@ipv.sx> wrote:

I may be misunderstanding things, but when I read th= e document, it seemed like the number of rounds didn't actually matter.= =A0As long as people use a relatively fixed set of choices for the number of rounds (say 10, 100, 1000), an attacker can build a rain= bow table for that number of rounds. =A0It may be 10x / 100x / 1000x more e= xpensive to build that table, but it may also be possible to optimize 1000x= SHA1 to bring down that cost (and 1000x is not a huge number anyway).

=A0

So if I'm understanding things correctly here, t= he mitigation would be to have a large *and* *randomized* number of rounds.= =A0Which seems like more of a hassle to manage than Robert's proposal.

=A0=

--Richard

=A0

On Mon, Dec 9, 2013 at 4:38 AM, Ralf Skyper Kaiser &= lt;skyper@thc.org&g= t; wrote:

Hi,

thanks for the I-D. Interesting idea. It solves some (but not all) problems= of password authentication. I have some questions about the advantages of = your I-D compared to the current work around that you mention:

You mention in the I-D that the current work-around is to use multiple roun= ds of hashes (100x or 1000x).

=A0

How many hash rounds wo= uld be sufficient to make it equally secure compared to your proposal (publ= ic key encryption)? (My gut feeling says 10.000 sha512 are more expensive t= han 1x 2048 rsa encrypt but I do not have figures in front of me. Both algorithms are = available in hardware [gpu, verilog, ..]).

What is the advantage o= f your I-D compared to just increasing the hash rounds?

regards,

ralf

=A0

=A0

On Sun, Dec 8, 2013 at 3:51 PM, Robert Kisteleki <= ;robert@ripe.net&g= t; wrote:

Hello,

As you may have noticed, I created a draft about how and why to add
asymmetric encryption to password storage.

http://www.ietf.org/mail-archive/web/i-d-announc= e/current/msg55437.html

Please let me know if you have comments or suggestions.

Regards,
Robert

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

=A0


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

=A0


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

=A0


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

=A0


--047d7b10cf270babd204ed35b681-- From scott@ties.org Tue Dec 10 18:28:54 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772ED1AE323 for ; Tue, 10 Dec 2013 18:28:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBnAuYoKABgz for ; Tue, 10 Dec 2013 18:28:50 -0800 (PST) Received: from mail-ve0-f172.google.com (mail-ve0-f172.google.com [209.85.128.172]) by ietfa.amsl.com (Postfix) with ESMTP id BC3191AE0C5 for ; Tue, 10 Dec 2013 18:28:49 -0800 (PST) Received: by mail-ve0-f172.google.com with SMTP id jw12so5519645veb.17 for ; Tue, 10 Dec 2013 18:28:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=b+0EHOEwJn84iWDzIozYr5TmQPH03zFKR9EDbdWZiBA=; b=gmmLfAsx8fdcdEU2GV0ppvbKUuCSjnLQ4Ngfmqf9YhGLMflJBOIkU4fkNmBrlKYSvq TtYshbnemhY6pRPI1Ir6askpS5W9cbbCebxTKNAj+LleMnOtsTv2MfBWmPVW664olaXX H2zNWNzzC4Pe6MkGDhbNo/ef8EMyBjolmBi8AAekPmJdyy/0R27/j/JWXT79MWhkwfqp 9Gm4KsnJBt+yjLec3ZDdbt1t1eQ04qaZ5oycNfqpASqSW5d35L9OGYQ931yqBWMm9C+y LDUUX9pi3lFJSroA1w4VNnBnuAZGhD/Qn2GxlQGJd6d+4UVKb0TRplnEe4Iw2pTB8ONM SsTw== X-Gm-Message-State: ALoCoQkBn+kFIx6jmtRB+i6O57C7Lz+JxDHl7BA0D7okgz/OLnlX3T7Zx+WJloQy2ngQyodPyVp9 X-Received: by 10.52.22.40 with SMTP id a8mr21655vdf.49.1386728923989; Tue, 10 Dec 2013 18:28:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.67.71 with HTTP; Tue, 10 Dec 2013 18:28:03 -0800 (PST) X-Originating-IP: [216.68.167.54] In-Reply-To: References: <52A49582.4070307@ripe.net> <1C9F17D1873AFA47A969C4DD98F98A750FA95D8D@xmb-rcd-x10.cisco.com> <1C9F17D1873AFA47A969C4DD98F98A750FA95E2E@xmb-rcd-x10.cisco.com> From: "Scott R. Corzine" Date: Tue, 10 Dec 2013 21:28:03 -0500 Message-ID: To: Ralf Skyper Kaiser Content-Type: multipart/alternative; boundary=20cf30776473ea232b04ed38fc33 Cc: IETF SAAG Subject: Re: [saag] New I-D: Password Storage Using Public Key Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 02:28:54 -0000 --20cf30776473ea232b04ed38fc33 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Folks, I realize in my enthusiasm to contribute I skipped a whole lot of steps and context, then thought about some refinements. Mostly I'm pulling together what I've seen others saying or what seems obvious. I've added a little opinion, thoughts, and glue from me in the corners. Sorry, this is long but I wanted to get what I was seeing into a whole. This mostly focuses on mechanics which will be applied for num_rounds iterations of various algorithms. Other people are making the pros and cons for doing this and how many rounds would be appropriate. I'm trying to keep aan eye on with an eye towards easing the ability to retrofit existing protocols and software (1) The number of rounds (num_rounds) really has to be variable as time goes on. ------Any fixed number will be too much for some, too little for others, and become outdated over the course of time. ------Even a "fixed" number is likely to get IETF recommendations to be increased some years from now. If we don't treat it as variable we'll risk interoperability issues between old and new. (2) Num_rounds needs to be stored and transmitted with the hash & salt. ------This affects protocols, APIs, storage formats, and existing software. ------Even when implementations can share an external configuration source for num_rounds, they are going to want to increase it over time creating the problem of old passwords having one value and new passwords having a different value. (3) How num_rounds was determined is mostly irrelevant as long as it's available. This makes the choice between random and static an implementation/configuration choice on the generator. ------RFC recommended values, local administrative settings, user specification, or randomly generated num_rounds all work without the verifier needing to know to generation (except for my salt kludge below). (4) Randomly generated num_rounds can be governed within a lower_bound to upper_bound range. ------These can allow for recommended default values with local override. ------Arbitrary non-random values can be achieved by setting lower_bound=3Dupper_bound. ------This allows implementations to skip randomizing num_rounds or even supplying the randomization code without affecting interoperability. (5) A big issue now becomes how do we pass this additional num_rounds information in protocols, APIs, storage, application code (passing around passwords/hashes), etc. (5a) The best option is of course to add num_rounds as its own distinct field. --------This works well for new protocols and extensible implementations. --------It's going to be difficult to do this in many cases unless they are alread (5b) Next option is to concatenate or otherwise merge num_rounds with the salt or hash. --------This works well as long as the field sizes are extensible, mostly treated as opaque, clear mappings can be defined, etc. --------The semantics and capabilities are basically the same as 5a. --------This requires all intermediaries to handle the num_rounds+salt+password in an opaque manner and to support variable lengths for salts/hashes. --------Implementations with 5a & 5b designs are likely to interoperate with a common interoperabiliy point. (5c) The kludge: overload part of the salt to also convey num_rounds. --------This is only for compatibility modes with existing implementations that can't support either 5a or 5b. --------This will produce inferior results to 5a or 5b, but will be significantly better that their status quo. --------Some alternatives like public keys are likely to be unavailable for this class. --------To preserve all current entropy in the salt we continue to generate it as before then derive the num_rounds from it. --------Num_rounds is therefore constrained and has to be calculated according to a well known formula shared by all the parties. --------One example: num_rounds=3Dsalt%(hival-lowval)+low_val. A change fr= om last night's message. --------Inside an enterprise (which is the scope of most passwords) this could be done by storing the parameters in a directory service such as LDAP= . --------For each salt there will only be one num_rounds (for a given formula, hival, and lowval) but different salts will have different, non-independent num_rounds. --------Custom rainbow tables will have to be generated for different combinations of formula, hival, and lowval. --------This is partially compatible with 5a&5b: As long as the password hashes were generated on a 5c system (or another in compatibility mode) all 5a, 5b, & 5c systems will be able to use it to interoperate. --------Yes, It's a kludge. But that's often required when trying to give older systems features not originally designed. (5d) Like 5c but both num_rounds and base_salt are randomly generated, then combined to produce real_salt. --------Trades off some entropy in the salt for more flexibility in num_rounds. (6) Lastly, we can make num_rounds automatically scale over time for new password generations. ------We just define a multiplier to the base lower_bound & upper_bound (recommended or locally specified) that scales over time. ------Example: real_lower_bound=3Dint(base_lower_bound * 2^((year-2014)/2))= . ------Reasonable minimums and maximums will be required to deal with incorrect clocks and the like. ------Newly generated hashes then will tend to grow automatically in computational costs as machine capacity grows. How does that look? Did I miss anything in this part? Thanks, -Scott- On Tue, Dec 10, 2013 at 5:34 PM, Ralf Skyper Kaiser wrote: > Hi, > > > On Tue, Dec 10, 2013 at 8:29 PM, Panos Kampanakis (pkampana) < > pkampana@cisco.com> wrote: > >> Thank you Ralf. >> >> So, for SH256 or SH512 16 bits could give approximately as much or more >> overhead as 2048-bit RSA. With SHA-3, maybe more might bits will be need= ed, >> but not necessarily to many more. >> > > I do not understand '16 bits could give...'. > > If the SHA512 is done 6490 times then it takes as long as one 2048-bit RS= A > encrypt (on my server) > > I believe multiple SHA512 rounds is less complex to implement and I have > no reason to believe that it is less secure (My gut says its more secure.= I > trust SHA512 _for this application_ more than RNG's, prime numbers and > factoring). > > >> >> Again, the benefit of such a scheme is that by changing the rounds, the >> password guessing can be made harder. I am wondering if there is a benef= it >> to using encryption over variable rounds. I can=E2=80=99t see any, excep= t possibly >> if the salt=E2=80=99s last x-bits could not be assumed uniformly distrib= uted. >> > > You are right, there is also the 3. option of variable number of rounds > which I missed in my previous email: > > > 1. use two hashing algorithms > 2. use a branch-statement > 3. Variable number of SHA512 rounds. > > Item 1. doubles the attack cost (GPU, FPGA) at no extra (processing)-cost > for the user. It does add complexity. > Item 2. only slightly increases the attack cost. > Item 3. All attacks that would exploit be made harder by this would also > be equally made harder by using a random/semi-unique salt (say 64 bit) fo= r > each password. > > regards, > > ralf > > Panos >> >> >> >> >> >> >> >> *From:* Ralf Skyper Kaiser [mailto:skyper@thc.org] >> *Sent:* Tuesday, December 10, 2013 3:18 PM >> *To:* Panos Kampanakis (pkampana) >> *Cc:* Scott R. Corzine; Richard Barnes; IETF SAAG >> >> *Subject:* Re: [saag] New I-D: Password Storage Using Public Key >> Encryption >> >> >> >> Hi, >> >> On my server (AMD Athlon(tm) 64 Processor 3500+) >> >> openssl speed sha512 rsa2048 >> >> sha512 on 512 bit: 59768k / second >> >> rsa2048 encrypt 9430 / second >> >> 59768 * 1024 / 9430 =3D 6490 SHA512 are as expensive as 1 RSA-2048_encry= pt. >> >> regards, >> >> skyper >> >> >> >> >> >> On Tue, Dec 10, 2013 at 8:02 PM, Panos Kampanakis (pkampana) < >> pkampana@cisco.com> wrote: >> >> That is an interesting scheme also. I am not sure if using encryption >> would offer more benefit than that scheme. >> >> Additionally, depending on the rounds, someone could make the password >> guessing as hard as he wanted. >> >> >> >> My question in this case would be, how many round-bits does someone need >> to approximately have the same overhead as an encryption operation. >> >> >> >> Panos >> >> >> >> >> >> >> >> >> >> *From:* saag [mailto:saag-bounces@ietf.org] *On Behalf Of *Scott R. >> Corzine >> *Sent:* Monday, December 09, 2013 2:02 PM >> *To:* Richard Barnes >> *Cc:* IETF SAAG >> *Subject:* Re: [saag] New I-D: Password Storage Using Public Key >> Encryption >> >> >> >> What if you were to randomly generate the number of rounds and then save >> it as we currently do for a salt? For implementations which provide for >> specific storage of salt + hash but aren't flexible enough to accommodat= e >> salt+rounds+hash you could use the kludge of using the last n bits (say = 16) >> of the salt to double as the number of rounds (or add say 1000 to it to >> ensure a minimum number of rounds). >> >> >> >> -Scott- >> >> >> >> On Mon, Dec 9, 2013 at 11:02 AM, Richard Barnes wrote: >> >> I may be misunderstanding things, but when I read the document, it seeme= d >> like the number of rounds didn't actually matter. As long as people use= a >> relatively fixed set of choices for the number of rounds (say 10, 100, >> 1000), an attacker can build a rainbow table for that number of rounds. = It >> may be 10x / 100x / 1000x more expensive to build that table, but it may >> also be possible to optimize 1000xSHA1 to bring down that cost (and 1000= x >> is not a huge number anyway). >> >> >> >> So if I'm understanding things correctly here, the mitigation would be t= o >> have a large *and* *randomized* number of rounds. Which seems like more= of >> a hassle to manage than Robert's proposal. >> >> >> >> --Richard >> >> >> >> On Mon, Dec 9, 2013 at 4:38 AM, Ralf Skyper Kaiser >> wrote: >> >> Hi, >> >> thanks for the I-D. Interesting idea. It solves some (but not all) >> problems of password authentication. I have some questions about the >> advantages of your I-D compared to the current work around that you ment= ion: >> >> You mention in the I-D that the current work-around is to use multiple >> rounds of hashes (100x or 1000x). >> >> >> >> How many hash rounds would be sufficient to make it equally secure >> compared to your proposal (public key encryption)? (My gut feeling says >> 10.000 sha512 are more expensive than 1x 2048 rsa encrypt but I do not h= ave >> figures in front of me. Both algorithms are available in hardware [gpu, >> verilog, ..]). >> >> What is the advantage of your I-D compared to just increasing the hash >> rounds? >> >> regards, >> >> ralf >> >> >> >> >> >> On Sun, Dec 8, 2013 at 3:51 PM, Robert Kisteleki wrote= : >> >> Hello, >> >> As you may have noticed, I created a draft about how and why to add >> asymmetric encryption to password storage. >> >> http://www.ietf.org/mail-archive/web/i-d-announce/current/msg55437.html >> >> Please let me know if you have comments or suggestions. >> >> Regards, >> Robert >> >> _______________________________________________ >> 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 >> >> >> >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> >> >> > > --20cf30776473ea232b04ed38fc33 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Folks,

I realize in my en= thusiasm to contribute I skipped a whole lot of steps and context, then tho= ught about some refinements. =C2=A0Mostly I'm pulling together what I&#= 39;ve seen others saying or what seems obvious. =C2=A0I've added a litt= le opinion, thoughts, and glue from me in the corners. =C2=A0Sorry, this is= long but I wanted to get what I was seeing into a whole.


This mostly focuses on mechanics w= hich will be applied for num_rounds iterations of various algorithms. =C2= =A0Other people are making the pros and cons for doing this and how many ro= unds would be appropriate. =C2=A0I'm trying to keep aan eye on with an = eye towards easing the ability to retrofit existing protocols and software<= br>

(1) The number of rounds (num_rounds) really has = to be variable as time goes on.
------Any fixed number will be to= o much for some, too little for others, and become outdated over the course= of time.
------Even a "fixed" number is likely to get IETF recommenda= tions to be increased some years from now. =C2=A0If we don't treat it a= s variable we'll risk interoperability issues between old and new.
<= /div>

(2) Num_rou= nds needs to be stored and transmitted with the hash & salt.
------This affects protocols, APIs, storage formats, = and existing software.
------Even when implementations can share an ext= ernal configuration source for num_rounds, they are going to want to increa= se it over time creating the problem of old passwords having one value and = new passwords having a different value.

(3) H= ow num_rounds was determined is mostly irrelevant as long as it's avail= able. =C2=A0This makes the choice between random and static an implementati= on/configuration choice on the generator.
------RFC recommended values, local administrati= ve settings, user specification, or randomly generated num_rounds all work = without the verifier needing to know to generation (except for my salt klud= ge below).

(4) Randoml= y generated num_rounds can be governed within a lower_bound to upper_bound = range.
------These can allow for recommende= d default values with local override.
------Arbitrary non-random values can be achieve= d by setting lower_bound=3Dupper_bound.
---= ---This allows implementations to skip randomizing num_rounds or even suppl= ying the randomization code without affecting interoperability.


<= div class=3D"gmail_extra">(5) A big issue now becomes how do we pass this a= dditional num_rounds information in protocols, APIs, storage, application c= ode (passing around passwords/hashes), etc.

(5a) The be= st option is of course to add num_rounds as its own distinct field.
--------This works well for new protocols and exte= nsible implementations.
--------It's going to be difficult to do thi= s in many cases unless they are alread
=
(5b) Next option is to concatenate or = otherwise merge num_rounds with the salt or hash.
--------This works well as long as the field siz= es are extensible, mostly treated as opaque, clear mappings can be defined,= etc.
--------The semantics and capabilities are basically the same as 5= a.
--------This requires all intermediaries t= o handle the num_rounds+salt+password in an opaque manner and to support va= riable lengths for salts/hashes.
------= --Implementations with 5a & 5b designs are likely to interoperate with = a common interoperabiliy point.


<= /div>
(5c) The kludge: overload part of the salt = to also convey num_rounds.
--------This is = only for compatibility modes with existing implementations that can't s= upport either 5a or 5b.
--------This will produce inferior results= to 5a or 5b, but will be significantly better that their status quo.
=
--------Some alternatives like public keys are l= ikely to be unavailable for this class.
--------To preserve all current entropy in= the salt we continue to generate it as before then derive the num_rounds f= rom it.
--------Num_rounds is therefore= constrained and has to be calculated according to a well known formula sha= red by all the parties.
--------One example: num_rounds=3Dsalt%(hi= val-lowval)+low_val. =C2=A0A change from last night's message.
--------Inside an enterprise (which is the scop= e of most passwords) this could be done by storing the parameters in a dire= ctory service such as LDAP.
--------For each salt there will only be o= ne num_rounds (for a given formula, hival, and lowval) but different salts = will have different, non-independent num_rounds.
--------Custom rainbow tables will have to be generated for different combi= nations of formula, hival, and lowval.
= --------This is partially compatible with 5a&5b: As long as the passwor= d hashes were generated on a 5c system (or another in compatibility mode) a= ll 5a, 5b, & 5c systems will be able to use it to interoperate.
--------Yes, It's a kludge. =C2=A0But = that's often required when trying to give older systems features not or= iginally designed.


(5d) Like 5c but both num_rounds and b= ase_salt are randomly generated, then combined to produce real_salt.
<= div class=3D"gmail_extra">--------Trades off some entropy in the salt for m= ore flexibility in num_rounds.


<= /div>
(6) Lastly, we can make num_rounds automati= cally scale over time for new password generations.
------We just define a multiplier to the base lower_bound & upper_bound= (recommended or locally specified) that scales over time.
------Example: real_lower_bound=3Dint(base_lower_bound * 2= ^((year-2014)/2)).
------Reasonable minimums and maximums will be r= equired to deal with incorrect clocks and the like.
------Newly generated hashes then will tend to grow automatica= lly in computational costs as machine capacity grows.


<= /div>
How does that look? =C2=A0Did I miss anythi= ng in this part?

Thanks,
-Scott-

On Tue, Dec 10, 2013 at 5:34 PM, Ralf S= kyper Kaiser <skyper@thc.org> wrote:
Hi,

On Tue, Dec 10, 2013 at 8:29 PM, Panos Kampanakis (pkampa= na) <pkampana@cisco.com> wrote:

Thank you Ralf.

So, for SH256 or SH512 16 bits could give ap= proximately as much or more overhead as 2048-bit RSA. With SHA-3, maybe mor= e might bits will be needed, but not necessarily to many more.


I do not understand '16 bits could give...'.

If the SHA512 is done 6490 times then it takes as long as one 2048= -bit RSA encrypt (on my server)

I believe multiple SHA512 rounds is less complex to implemen= t and I have no reason to believe that it is less secure (My gut says its m= ore secure. I trust SHA512 _for this application_ more than RNG's, prim= e numbers and factoring).

=C2=A0

Again, the benefit of such a scheme is that = by changing the rounds, the password guessing can be made harder. I am wond= ering if there is a benefit to using encryption over variable rounds. I can=E2=80=99t see any, except possibly = if the salt=E2=80=99s last x-bits could not be assumed uniformly distribute= d.


You are rig= ht, there is also the 3. option of variable number of rounds which I missed= in my previous email:


1. use two hashing algorithms
2. use a branch-statement <= br>
3. Variable number of SHA512 rounds.

= Item 1. doubles the attack cost (GPU, FPGA) at no extra (processing)-cost f= or the user. It does add complexity.
Item 2. only slightly increases the attack cost.
= Item 3. All attacks that would exploit be made harder by this would also be= equally made harder by using a random/semi-unique salt (say 64 bit) for ea= ch password.

regards,

ralf

Panos

=C2=A0

=C2=A0

=C2=A0

From: Ralf Skyper Kaiser [mailto:skyper@thc.org]
Sent: Tuesday, December 10, 2013 3:18 PM
To: Panos Kampanakis (pkampana)
Cc: Scott R. Corzine; Richard Barnes; IETF SAAG

=
Subject: Re: [saag] New I-D: Password Storage Using Public Key Encry= ption

=C2=A0

Hi,

On my server (AMD Athlon(tm) 64 Processor 3500+)

openssl speed sha512 rsa2048

sha512 on 512 bit: 59768k / second

rsa2048 encrypt 9430 / = second

59768 * 1024 / 9430 =3D= 6490 SHA512 are as expensive as 1 RSA-2048_encrypt.

regards,

skyper

=C2=A0

=C2=A0

On Tue, Dec 10, 2013 at 8:02 PM, Panos Kampanakis (p= kampana) <pkampa= na@cisco.com> wrote:

That is an interesting scheme also. I am not= sure if using encryption would offer more benefit than that scheme.

Additionally, depending on the rounds, someo= ne could make the password guessing as hard as he wanted.<= /u>

=C2=A0

My question in this case would be, how many = round-bits does someone need to approximately have the same overhead as an encryption operation.

=C2=A0

Panos

=C2=A0

=C2=A0

=C2=A0

=C2=A0

From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Scott R. Corzine
Sent: Monday, December 09, 2013 2:02 PM
To: Richard Barnes
Cc: IETF SAAG
Subject: Re: [saag] New I-D: Password Storage Using Public Key Encry= ption

=C2=A0

What if you were to randomly generate the number of = rounds and then save it as we currently do for a salt? =C2=A0For implementa= tions which provide for specific storage of salt + hash but aren't flexible enough to accommodate salt+rounds+hash you could u= se the kludge of using the last n bits (say 16) of the salt to double as th= e number of rounds (or add say 1000 to it to ensure a minimum number of rou= nds).

=C2=A0

-Scott-

=C2=A0

On Mon, Dec 9, 2013 at 11:02 AM, Richard Barnes <= rlb@ipv.sx> wrote:

I may be misunderstanding things, but when I read th= e document, it seemed like the number of rounds didn't actually matter.= =C2=A0As long as people use a relatively fixed set of choices for the number of rounds (say 10, 100, 1000), an attacker can build a rain= bow table for that number of rounds. =C2=A0It may be 10x / 100x / 1000x mor= e expensive to build that table, but it may also be possible to optimize 10= 00xSHA1 to bring down that cost (and 1000x is not a huge number anyway).

=C2=A0

So if I'm understanding things correctly here, t= he mitigation would be to have a large *and* *randomized* number of rounds.= =C2=A0Which seems like more of a hassle to manage than Robert's proposal.

=C2=A0=

--Richard

=C2=A0

On Mon, Dec 9, 2013 at 4:38 AM, Ralf Skyper Kaiser &= lt;skyper@thc.org&g= t; wrote:

Hi,

thanks for the I-D. Interesting idea. It solves some (but not all) problems= of password authentication. I have some questions about the advantages of = your I-D compared to the current work around that you mention:

You mention in the I-D that the current work-around is to use multiple roun= ds of hashes (100x or 1000x).

=C2=A0

How many hash rounds wo= uld be sufficient to make it equally secure compared to your proposal (publ= ic key encryption)? (My gut feeling says 10.000 sha512 are more expensive t= han 1x 2048 rsa encrypt but I do not have figures in front of me. Both algorithms are = available in hardware [gpu, verilog, ..]).

What is the advantage o= f your I-D compared to just increasing the hash rounds?

regards,

ralf

=C2=A0

=C2=A0

On Sun, Dec 8, 2013 at 3:51 PM, Robert Kisteleki <= ;robert@ripe.net&g= t; wrote:

Hello,

As you may have noticed, I created a draft about how and why to add
asymmetric encryption to password storage.

http://www.ietf.org/mail-archive/web/i-d-announc= e/current/msg55437.html

Please let me know if you have comments or suggestions.

Regards,
Robert

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

=C2=A0


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

=C2=A0


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

=C2=A0


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

=C2=A0



--20cf30776473ea232b04ed38fc33-- From robert@ripe.net Wed Dec 11 01:36:46 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4E71ADFD5 for ; Wed, 11 Dec 2013 01:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztTs56HACLxD for ; Wed, 11 Dec 2013 01:36:45 -0800 (PST) Received: from koko.ripe.net (koko.ripe.net [193.0.19.72]) by ietfa.amsl.com (Postfix) with ESMTP id A19FC1ADFE6 for ; Wed, 11 Dec 2013 01:36:42 -0800 (PST) Received: from titi.ripe.net ([193.0.23.11]) by koko.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VqgDb-0003sL-MU; Wed, 11 Dec 2013 10:36:36 +0100 Received: from mandrill.ripe.net ([193.0.1.209] helo=[0.0.0.0]) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1VqgDb-0002Si-Ix; Wed, 11 Dec 2013 10:36:35 +0100 Message-ID: <52A83226.8030503@ripe.net> Date: Wed, 11 Dec 2013 10:36:38 +0100 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Ralf Skyper Kaiser , IETF SAAG References: <52A779E4.5020609@ripe.net> In-Reply-To: <52A779E4.5020609@ripe.net> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <52A779E4.5020609@ripe.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274fad13acc022a8fd53b009a6b06757c97 Subject: [saag] Fwd: Re: New I-D: Password Storage Using Public Key Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 09:36:46 -0000 (Trying again, my message failed to show up on the list in the past 12 hours...) On 2013.12.10. 21:18, Ralf Skyper Kaiser wrote: > Hi, > > On my server (AMD Athlon(tm) 64 Processor 3500+) > > openssl speed sha512 rsa2048 > > sha512 on 512 bit: 59768k / second > rsa2048 encrypt 9430 / second > > 59768 * 1024 / 9430 = 6490 SHA512 are as expensive as 1 RSA-2048_encrypt. While these are likely to be representative for your general purpose CPU, GPU implementations are *much* more effective for hashing (I know, [citation needed] ... maybe [1] will do) If that's correct, your numbers on real life difference may be orders of magnitude off. Robert [1] http://en.wikipedia.org/wiki/Graphics_processing_unit#Stream_Processing_and_General_Purpose_GPUs_.28GPGPU.29 From robert@ripe.net Wed Dec 11 04:12:22 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3FF71AC82B for ; Wed, 11 Dec 2013 04:12:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGvgUAJrnOlK for ; Wed, 11 Dec 2013 04:12:21 -0800 (PST) Received: from koko.ripe.net (koko.ripe.net [193.0.19.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0FABB1A1F7C for ; Wed, 11 Dec 2013 04:12:21 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by koko.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VqieE-00056C-0g; Wed, 11 Dec 2013 13:12:15 +0100 Received: from mandrill.ripe.net ([193.0.1.209] helo=[0.0.0.0]) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1VqTwu-0008U1-9V; Tue, 10 Dec 2013 21:30:32 +0100 Message-ID: <52A779E4.5020609@ripe.net> Date: Tue, 10 Dec 2013 21:30:28 +0100 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Ralf Skyper Kaiser References: <52A49582.4070307@ripe.net> <1C9F17D1873AFA47A969C4DD98F98A750FA95D8D@xmb-rcd-x10.cisco.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a2742959daabf392730057e99a8c83d1ae8b Cc: IETF SAAG Subject: Re: [saag] New I-D: Password Storage Using Public Key Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 12:12:23 -0000 On 2013.12.10. 21:18, Ralf Skyper Kaiser wrote: > Hi, > > On my server (AMD Athlon(tm) 64 Processor 3500+) > > openssl speed sha512 rsa2048 > > sha512 on 512 bit: 59768k / second > rsa2048 encrypt 9430 / second > > 59768 * 1024 / 9430 = 6490 SHA512 are as expensive as 1 RSA-2048_encrypt. While these are likely to be representative for your general purpose CPU, GPU implementations are *much* more effective for hashing (I know, [citation needed] ... maybe [1] will do) If that's correct, your numbers on real life difference may be orders of magnitude off. Robert [1] http://en.wikipedia.org/wiki/Graphics_processing_unit#Stream_Processing_and_General_Purpose_GPUs_.28GPGPU.29 From skyper@thc.org Wed Dec 11 05:46:34 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23FE31ADE86 for ; Wed, 11 Dec 2013 05:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zmiiSaaz9Zr for ; Wed, 11 Dec 2013 05:46:32 -0800 (PST) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 510911ADEB1 for ; Wed, 11 Dec 2013 05:46:32 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id e14so10965286iej.40 for ; Wed, 11 Dec 2013 05:46:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KWP2+qBW1iC2aSOd6wYwvd632zEOVePyWD/GaGptnPc=; b=OhqX356dgysig91A1ugBZwT7fcjSiCdzavrt8IQm2CrGIfGHMaQIRbbLELV8l6k+Wy MoBScDiUePaazEICpA86t9AaUTrwud6jgtqXE2MPWKQJr6QlKFcxsNaRlo0zjC30eYnQ jR/1JMzWcNn3bOqtMRAvm4cfJStI3FInyXVhY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KWP2+qBW1iC2aSOd6wYwvd632zEOVePyWD/GaGptnPc=; b=YDa23CzMgUvGL8x6OPGc9JXeJqjkqfmbzkb6nV7m1lpFIxUvAg+VTHHHDomkwh48Df nuiH2FTj83o5xidd1ECHwqRAz46UsZ8CdBf12cWemM5YKaKy+njwi20iSwnwtNkLgcne 3PbihARIYjwPRZAV1vQd8QLYF+vgb8oSCndKekeDoSXqKAJibBe7V+AFdPVAnizcVZHB YhiWiYF2Md0sq1F12X4dgUnL920SjxAujGw4F1b51vaGNa/cxchlaO00sHQqbi6+qz/p Xuz9WbUWCEAstLK0KFYrrxJVOs1e+QptfSAycVscCsekDtthukAcfR5x5cgfrchrvCBJ He7g== X-Gm-Message-State: ALoCoQlC8MMTQ6hg0NoJj9l0M+joSZSx+UV1sM5EVYic/bqjp+/sXU0nIvq7zRS1vv+grBPgFCsq MIME-Version: 1.0 X-Received: by 10.50.25.129 with SMTP id c1mr24566303igg.23.1386769586588; Wed, 11 Dec 2013 05:46:26 -0800 (PST) Received: by 10.64.9.41 with HTTP; Wed, 11 Dec 2013 05:46:26 -0800 (PST) X-Originating-IP: [81.156.248.122] In-Reply-To: <52A779E4.5020609@ripe.net> References: <52A49582.4070307@ripe.net> <1C9F17D1873AFA47A969C4DD98F98A750FA95D8D@xmb-rcd-x10.cisco.com> <52A779E4.5020609@ripe.net> Date: Wed, 11 Dec 2013 13:46:26 +0000 Message-ID: From: Ralf Skyper Kaiser To: Robert Kisteleki Content-Type: multipart/alternative; boundary=047d7bdc10ec9824cd04ed4274d6 Cc: IETF SAAG Subject: Re: [saag] New I-D: Password Storage Using Public Key Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 13:46:34 -0000 --047d7bdc10ec9824cd04ed4274d6 Content-Type: text/plain; charset=ISO-8859-1 Hi, the comparison was how much faster SHA512 is compared to RSA2048 regardless of the platform/HW. (If i double my CPU power than SHA512 is still 6490 times faster than RSA2048 on my HW). Data about RSA2048 and SHA512 speed on a GPU would be interesting but wont change that multiple rounds of SHA512 can be as expensive as a single round of RSA2048. In general we can assume that SHA512 is 4,000 - 20,000x faster than RSA2048 on most given HW. I agree with Scott that the number of rounds should be variable with a recommended value (say 6000 rounds for year 2014). Recommendation should be that the number of rounds should double in accordance with Moor's law. (btw, it's currently 1 round so we are making the attack 6000x more expensive. Not bad to start with...). regards, ralf On Tue, Dec 10, 2013 at 8:30 PM, Robert Kisteleki wrote: > On 2013.12.10. 21:18, Ralf Skyper Kaiser wrote: > > Hi, > > > > On my server (AMD Athlon(tm) 64 Processor 3500+) > > > > openssl speed sha512 rsa2048 > > > > sha512 on 512 bit: 59768k / second > > rsa2048 encrypt 9430 / second > > > > 59768 * 1024 / 9430 = 6490 SHA512 are as expensive as 1 RSA-2048_encrypt. > > > While these are likely to be representative for your general purpose CPU, > GPU implementations are *much* more effective for hashing (I know, > [citation > needed] ... maybe [1] will do) > > If that's correct, your numbers on real life difference may be orders of > magnitude off. > > Robert > > > [1] > > http://en.wikipedia.org/wiki/Graphics_processing_unit#Stream_Processing_and_General_Purpose_GPUs_.28GPGPU.29 > > > --047d7bdc10ec9824cd04ed4274d6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

the comparison was how much faster SH= A512 is compared to RSA2048 regardless of the platform/HW. (If i double my = CPU power than SHA512 is still 6490 times faster than RSA2048 on my HW).
Data about RSA2048 and SHA512 speed on a GPU would be interesting but w= ont change that multiple rounds of SHA512
can be as expensive= as a single round of RSA2048.

In general we can assume t= hat SHA512 is 4,000 - 20,000x faster than RSA2048 on most given HW.

I agree with Scott that the number of rounds should be variable w= ith a recommended value (say 6000 rounds for year 2014). Recommendation sho= uld be that the number of rounds should double in accordance with Moor'= s law.

(btw, it's currently 1 round so we are making the attack= 6000x more expensive. Not bad to start with...).

r= egards,

ralf



On Tue, Dec 10, 2013 at 8:30 PM, Robert = Kisteleki <robert@ripe.net> wrote:
On 2013.12.10. 21:18, Ralf Skyper Kaiser wrote:
> Hi,
>
> On my server (AMD Athlon(tm) 64 Processor 3500+)
>
> openssl speed sha512 rsa2048
>
> sha512 on 512 bit: 59768k / second
> rsa2048 encrypt 9430 / second
>
> 59768 * 1024 / 9430 =3D 6490 SHA512 are as expensive as 1 RSA-2048_enc= rypt.


While these are likely to be representative for your general purpose = CPU,
GPU implementations are *much* more effective for hashing (I know, [citatio= n
needed] ... maybe [1] will do)

If that's correct, your numbers on real life difference may be orders o= f
magnitude off.

Robert


[1]
http://en.w= ikipedia.org/wiki/Graphics_processing_unit#Stream_Processing_and_General_Pu= rpose_GPUs_.28GPGPU.29



--047d7bdc10ec9824cd04ed4274d6-- From gerdes@tzi.de Wed Dec 11 05:49:07 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17641ADE7C; Wed, 11 Dec 2013 05:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZ-07BSEa9s7; Wed, 11 Dec 2013 05:49:05 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 364A81ADDDA; Wed, 11 Dec 2013 05:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rBBDksGc018161; Wed, 11 Dec 2013 14:46:55 +0100 (CET) Received: from [134.102.218.230] (dynamic-218-c.informatik.uni-bremen.de [134.102.218.230]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7D110C4B; Wed, 11 Dec 2013 14:46:54 +0100 (CET) Message-ID: <52A86CCE.3090906@tzi.de> Date: Wed, 11 Dec 2013 14:46:54 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "core@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: saag@ietf.org, dtls-iot@ietf.org, jose@ietf.org, oauth@ietf.org Subject: [saag] Invitation to New Non-WG Mailing List: Authentication and Authorization for Constrained Environments (ace) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 13:49:08 -0000 Hi everybody, As a result of discussions in the CoRE WG in Berlin and Vancouver the new non-WG mailing list Authentication and Authorization for Constrained Environments (ace) was created. The purpose of this list is to organize interest in a group to define the charter for work on Authentication and Authorization for Constrained Environments. Our mailing list can be found at (1), existing work can be found at (2), and the draft charter can be found at (3). Please feel welcome to join the list and provide your feedback! Thanks, Kind Regards Kepeng & Stefanie (1)Mailing List https://www.ietf.org/mailman/listinfo/ace (2)Existing work: Use Cases: http://tools.ietf.org/id/draft-garcia-core-security http://tools.ietf.org/id/draft-greevenbosch-core-authreq http://tools.ietf.org/id/draft-seitz-core-sec-usecases Solutions http://tools.ietf.org/id/draft-gerdes-core-dcaf-authorize http://tools.ietf.org/id/draft-kang-core-secure-reconfiguration http://tools.ietf.org/id/draft-selander-core-access-control http://tools.ietf.org/id/draft-zhu-core-groupauth http://tools.ietf.org/id/draft-pporamba-dtls-certkey http://tools.ietf.org/id/draft-schmitt-two-way-authentication-for-iot http://tools.ietf.org/id/draft-seitz-core-security-modes (3)Draft Charter - Authentication and Authorization for Constrained Environment (ACE) The CoAP (Constrained Application Protocol) is a light-weight application layer protocol, especially suitable for applications such as smart energy, smart home, building automation, remote patient monitoring etc. Due to the nature of these applications, including a critical, unattended infrastructure and usage in the personal sphere, security and privacy protection are critical components. Currently, a problem with constrained devices is the realization of such secure communication. The devices only have limited resources such as memory, storage and transmission capacity. These constraints severely limit the security functions and communications the device can perform. Missing functionality includes authentication, which provides trust and ensures an entity is who it says it is, and authorization, which defines and enforces access rights for different clients. The ACE WG focuses on providing constrained devices with the necessary prerequisites to use REST operations in a secure way. Constrained devices will thus be enabled to authenticate communications from other (constrained or less-constrained) devices, to communicate securely with them and to verify their individual authorization to access specific resources. To achieve this, ACE will be able to employ an architecture with one or more trusted less-constrained devices which will relieve the constrained nodes from complex security related tasks (e.g. managing authorization policies and a large number of keys). ACE will use CoAP and employ security properties of DTLS whenever possible. The ACE WG has the following tasks: - Document the use cases and high-level requirements for secured communication between constrained devices. - Define certificate profiling (what kinds of certificates and which attributes are to be used). - Define a mechanism for authenticated and protected transfer of authorization information suitable for constrained device to constrained device communication. - Define an access ticket and authorization information format suitable for constrained devices. - Define bootstrapping for authorization information using the Resource Directory. From rstruik.ext@gmail.com Wed Dec 11 06:45:24 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C8D1ADF81; Wed, 11 Dec 2013 06:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdY_MpxXnw2h; Wed, 11 Dec 2013 06:45:21 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 581201ADF80; Wed, 11 Dec 2013 06:45:21 -0800 (PST) Received: by mail-ig0-f179.google.com with SMTP id hk11so847716igb.0 for ; Wed, 11 Dec 2013 06:45:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=scWuz0UoFiPFuRINImNeTz68NxM7A/ZPXBXnVRbrz58=; b=ajoarEEUcuuSlhu4jc+Lmw7INGKir3YpySyrYDOd8no2qdbpDsLvPfvufjn+aILQm3 bfw/oVgUTzA9sp6u/plb//bwp0z97PMV5rqoEkxKJwVk7b6BvM1xNWhWzPlWOTlv8VvB jIULTafdkyroeMHxaGdbLkn9LjabYToAxK2t4t1bjGzod64ADaOvgOSQDvSeO8OMqKx7 YJyK4s0jUjdBfeE0giwEiapC2Y8DkLmxyXl/b2dWoSZDCcfD07XUd3ouj3Qd+aQsa97f c2acJiQmuW7reKDChnFPjoqsKeI7PHV6HMcjJ/DT2LgPFl6wnp+2VMp/YaPlxQpveDNN tXJA== X-Received: by 10.42.208.211 with SMTP id gd19mr1165897icb.15.1386773115664; Wed, 11 Dec 2013 06:45:15 -0800 (PST) Received: from [192.168.1.103] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.230.254.17]) by mx.google.com with ESMTPSA id k6sm9308420igx.8.2013.12.11.06.45.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Dec 2013 06:45:14 -0800 (PST) Message-ID: <52A87A6F.8030304@gmail.com> Date: Wed, 11 Dec 2013 09:45:03 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Stefanie Gerdes , "core@ietf.org" References: <52A86CCE.3090906@tzi.de> In-Reply-To: <52A86CCE.3090906@tzi.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: saag@ietf.org, dtls-iot@ietf.org, jose@ietf.org, oauth@ietf.org Subject: Re: [saag] Invitation to New Non-WG Mailing List: Authentication and Authorization for Constrained Environments (ace) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 14:45:24 -0000 [apologies for replying to all the IETF lists in the original cc] Dear colleagues: I have some initial feedback on the potential draft charter. I believe it is really premature to write potential point solutions into = a draft charter, in casu definition of a less constrained device that can= be used to outsource computational, storage, or management functionality= to. (Does this imply one envisions to have to buy a separate box/single = point of failure to take on this task?) It would make much more sense to = look into this problem space in terms of requirements first, with an eye = towards scalability towards billion+ devices. This does not preclude this= potential solution direction, but questions as to what this entails in t= erms of usability, scalability, and communications impact need to be clea= r first. This is an ambitious undertaking and many efforts in the past ha= ve been far less successful than initially thought. There is also an unde= rcurrent in the draft charter text that there is a need for different "de= vice types", which is not a priori clear. To realize the full potential o= f constrained networks, one should reflect upon "trust" endowed upon sing= le nodes, of whatever type, and consider limiting the impact of violation= of this trust, should this occur, as an explicit design criterium. In the end, this may be an undertaking that would be suitable as an IAB w= ork item, considering potential scope. Best regards, Rene =3D=3D To achieve this, ACE will be able to employ an architecture with one or more trusted less-constrained devices which will relieve the constrained nodes from complex security related tasks (e.g. managing authorization policies and a large number of keys). ACE will use CoAP and employ security properties of DTLS whenever possible. On 12/11/2013 8:46 AM, Stefanie Gerdes wrote: > Hi everybody, > > As a result of discussions in the CoRE WG in Berlin and Vancouver the > new non-WG mailing list Authentication and Authorization for Constraine= d > Environments (ace) was created. > > The purpose of this list is to organize interest in a group to define > the charter for work on Authentication and Authorization for Constraine= d > Environments. > > Our mailing list can be found at (1), existing work can be found at (2)= , > and the draft charter can be found at (3). > > Please feel welcome to join the list and provide your feedback! > > Thanks, > > Kind Regards > Kepeng & Stefanie > > > (1)Mailing List > > https://www.ietf.org/mailman/listinfo/ace > > (2)Existing work: > > Use Cases: > http://tools.ietf.org/id/draft-garcia-core-security > http://tools.ietf.org/id/draft-greevenbosch-core-authreq > http://tools.ietf.org/id/draft-seitz-core-sec-usecases > > Solutions > http://tools.ietf.org/id/draft-gerdes-core-dcaf-authorize > http://tools.ietf.org/id/draft-kang-core-secure-reconfiguration > http://tools.ietf.org/id/draft-selander-core-access-control > http://tools.ietf.org/id/draft-zhu-core-groupauth > http://tools.ietf.org/id/draft-pporamba-dtls-certkey > http://tools.ietf.org/id/draft-schmitt-two-way-authentication-for-iot > http://tools.ietf.org/id/draft-seitz-core-security-modes > > (3)Draft Charter - Authentication and Authorization for Constrained > Environment (ACE) > > The CoAP (Constrained Application Protocol) is a light-weight > application layer protocol, especially suitable for applications such a= s > smart energy, smart home, building automation, remote patient monitorin= g > etc. Due to the nature of these applications, including a critical, > unattended infrastructure and usage in the personal sphere, security an= d > privacy protection are critical components. > > Currently, a problem with constrained devices is the realization of suc= h > secure communication. The devices only have limited resources such as > memory, storage and transmission capacity. These constraints severely > limit the security functions and communications the device can perform.= > Missing functionality includes authentication, which provides trust and= > ensures an entity is who it says it is, and authorization, which define= s > and enforces access rights for different clients. > > The ACE WG focuses on providing constrained devices with the necessary > prerequisites to use REST operations in a secure way. Constrained > devices will thus be enabled to authenticate communications from other > (constrained or less-constrained) devices, to communicate securely with= > them and to verify their individual authorization to access specific > resources. To achieve this, ACE will be able to employ an architecture > with one or more trusted less-constrained devices which will relieve th= e > constrained nodes from complex security related tasks (e.g. managing > authorization policies and a large number of keys). ACE will use CoAP > and employ security properties of DTLS whenever possible. > > The ACE WG has the following tasks: > - Document the use cases and high-level requirements for secured > communication between constrained devices. > - Define certificate profiling (what kinds of certificates and which > attributes are to be used). > - Define a mechanism for authenticated and protected transfer of > authorization information suitable for constrained device to constraine= d > device communication. > - Define an access ticket and authorization information format suitable= > for constrained devices. > - Define bootstrapping for authorization information using the Resource= > Directory. --=20 email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From ietf@rozanak.com Wed Dec 11 07:56:59 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9821ADF5F; Wed, 11 Dec 2013 07:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I87Nd3Ltp-CA; Wed, 11 Dec 2013 07:56:57 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0121ADC03; Wed, 11 Dec 2013 07:56:57 -0800 (PST) Received: from kopoli ([141.89.226.146]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MUp6q-1W2zUv3QoG-00YriV; Wed, 11 Dec 2013 10:56:50 -0500 From: "Hosnieh Rafiee" To: , , , References: In-Reply-To: Date: Wed, 11 Dec 2013 16:56:41 +0100 Message-ID: <004101cef689$99b93f90$cd2bbeb0$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0042_01CEF691.FB7F0720" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac72iSvPgVYgbXT9Tp2rb9e4S1H5BQAABB3g Content-Language: en-us X-Provags-ID: V02:K0:zsorZVhW8HgeflfAdkqx44XEhAz1ybLvxGiEIOStOdR l6APmNSpArup54roxvO9Uil1wRt+vU2S8n5NF1qF2IZvqk9Urn 8+zdGx8jNCUMNu+jibJdw9ekKma8VAmZiEv4xBVQiSoEt5odYs 8+lqvf5E0supOsi8Cg3PsJ17ki+OfTmOzzDdPJUXyaa6ofnfy4 b7E16COcPOxjWS1Rfxi7JypZv7WKu96HJrB3L/k2K+ADOmr/u6 a+XNj0mY4xcXCqvKwJAPc4RHfHikBps5GLzWWJBatVoqfzW+JN dzgpMURtRaqsMwVc0Da//ZBinNwv0QGMi+U/S8QCQ1tDIQ+mtU q3lmcZ2n6HT80UoXWwaI= Subject: [saag] new mailing list in security area X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 15:56:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0042_01CEF691.FB7F0720 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, There is a new mailing list in security area. The discussion will be fruitful if there are people from different backgrounds and not only security (security, operational views, application layer, network layer, privacy, etc). I already invited the people who I could remember. If I missed to invite you, just feel free to join this mailing list. The purpose is to find solutions to automate authentication and use network layer for this means but at the same time take care of performance, privacy and the possibility of this solution. https://www.ietf.org/mailman/listinfo/secauth This is the description of this mailing list. This list is for the discussions relating to using the IP layer as a means of authentication in other upper layers, especially the application layer, by considering both security and privacy on one hand and performance on the other hand. The goal is to come up with the implementation of a library for this purpose. The focus is on both nodes with limited resources (battery, memory, etc) and other nodes. We are also discussing the possible implementation or implementation barriers from operational points of view. Looking forward to see your participations there :-) Thanks, Smile Hosnieh ------=_NextPart_000_0042_01CEF691.FB7F0720 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hello,

 

There = is a new mailing list in security area. The discussion will be fruitful = if there are people from different backgrounds and not only security = (security, operational views, application layer, network layer, privacy, = etc). I already invited the people who I could remember. If I missed to = invite you, just feel free to join this mailing list. The purpose is to = find solutions to automate authentication and use network layer for this = means but at the same time take care of performance, privacy and the = possibility of this solution.

https://www.ietf.org/mail= man/listinfo/secauth

 

This = is the description of this mailing list.

 

This = list is for the discussions relating to using the IP layer as a  = means of authentication in other upper layers, especially the  = application layer, by considering both security and privacy on one  = hand and performance on the other hand. The goal is to come up = with  the implementation of a library for this purpose. The focus = is on  both nodes with limited resources (battery, memory, etc) and = other nodes.

We are also = discussing the possible implementation or implementation  barriers = from operational points of view.

 

Looking forward to see your participations there = :-)

 

 

Thanks,

 

Smile

 

= Hosnieh

 

 

------=_NextPart_000_0042_01CEF691.FB7F0720-- From hilarie@purplestreak.com Tue Dec 10 10:26:13 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C2B1AE171 for ; Tue, 10 Dec 2013 10:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cd9KQ0Sbxs_e for ; Tue, 10 Dec 2013 10:26:11 -0800 (PST) Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) by ietfa.amsl.com (Postfix) with ESMTP id D6C361AE052 for ; Tue, 10 Dec 2013 10:26:11 -0800 (PST) Received: from in02.mta.xmission.com ([166.70.13.52]) by out02.mta.xmission.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1VqS0S-00017Q-Hs for saag@ietf.org; Tue, 10 Dec 2013 11:26:04 -0700 Received: from [72.250.219.84] (helo=sylvester.rhmr.com) by in02.mta.xmission.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1VqS0R-0004CH-G8 for saag@ietf.org; Tue, 10 Dec 2013 11:26:04 -0700 Received: from sylvester.rhmr.com (localhost [127.0.0.1]) by sylvester.rhmr.com (8.14.4/8.14.4/Debian-2ubuntu1) with ESMTP id rBAIPsGE006918 for ; Tue, 10 Dec 2013 11:25:54 -0700 Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id rBAIPrsL006916; Tue, 10 Dec 2013 11:25:53 -0700 Date: Tue, 10 Dec 2013 11:25:53 -0700 Message-Id: <201312101825.rBAIPrsL006916@sylvester.rhmr.com> From: "Hilarie Orman" To: saag@ietf.org In-reply-to: Yourmessage <52A72DFC.70906@bbn.com> X-XM-AID: U2FsdGVkX18n5fb4JuUuxSzxSGo/+aYr X-SA-Exim-Connect-IP: 72.250.219.84 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;saag@ietf.org X-Spam-Relay-Country: X-SA-Exim-Version: 4.2.1 (built Wed, 14 Nov 2012 14:26:46 -0700) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) X-Mailman-Approved-At: Wed, 11 Dec 2013 08:11:11 -0800 Subject: Re: [saag] New I-D: Password Storage Using Public Key Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Hilarie Orman List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 18:26:13 -0000 > Date: Tue, 10 Dec 2013 10:06:36 -0500 > From: Stephen Kent > To: saag@ietf.org > Subject: Re: [saag] New I-D: Password Storage Using Public Key Encryption > Ralf, > > ... > > > > > > > > The cost increase is linear for all suggested solutions. Unless the > > solution increases the cost exponentially there is no real benefit to > > using a large salt and 10.000x SHA512. Comments welcome. > I don't agree that a linear cost increase is not worth pursuing, if the > muyltiplier is big enough. Attackers have to spend money to perform > password searches on hashed/encrypted password tables that they acquire. > If we increase the cost by 10^5, their costs increase accordingly. While > one might argue that, in an academic context, > only an exponential increase merits publication, that it not the context > for this > discussion. > Steve It's because Moore's Law refuses to die, and that means that parallelism will eat up linear factors. In this case, changing the algorithm to be parallel-unfriendly will be more effective than changing the constants. But maybe all the hardware will be so busy mining BitCoins that no one will bother with password cracking anymore. Hilarie From kent@bbn.com Wed Dec 11 08:19:14 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DA11AE07E for ; Wed, 11 Dec 2013 08:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6BKj2DAVe_E for ; Wed, 11 Dec 2013 08:19:13 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id D0C601AE07D for ; Wed, 11 Dec 2013 08:19:12 -0800 (PST) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:53161) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VqmV9-000Gjz-6S for saag@ietf.org; Wed, 11 Dec 2013 11:19:07 -0500 Message-ID: <52A8907B.5060109@bbn.com> Date: Wed, 11 Dec 2013 11:19:07 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: saag@ietf.org References: <201312101825.rBAIPrsL006916@sylvester.rhmr.com> In-Reply-To: <201312101825.rBAIPrsL006916@sylvester.rhmr.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [saag] New I-D: Password Storage Using Public Key Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 16:19:14 -0000 ... > It's because Moore's Law refuses to die, and that means that > parallelism will eat up linear factors. In this case, changing the > algorithm to be parallel-unfriendly will be more effective than > changing the constants. But maybe all the hardware will be so busy > mining BitCoins that no one will bother with password cracking > anymore. > > Hilarie > touche' Steve From benl@google.com Wed Dec 11 10:33:06 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B69E1AE085 for ; Wed, 11 Dec 2013 10:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIJNdQ1azWrJ for ; Wed, 11 Dec 2013 10:33:05 -0800 (PST) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2418A1AC4C5 for ; Wed, 11 Dec 2013 10:33:05 -0800 (PST) Received: by mail-vc0-f180.google.com with SMTP id if17so5800834vcb.25 for ; Wed, 11 Dec 2013 10:32:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ni5C9w+7qny63dmRG3PiuwWWKhBpBoarH/hWJ1h/b68=; b=f9/WsxsGYTLyqaMiybL9VEJuBkY5Db6jXVCbK6mg04JUr1MGiQVy4z6FGproF28uXk TT50v/UL8C6TneCcN82HMnr0YHTB5kD6am7XGCguTCZMcbP79sJPYonYKnQelx12AYQU j+ryAEMYGNap6lX4BS7rpYLHiC0VOMzN2mlDIBxw2IFMtaJzebB3ZlwZprTNJfKe0R+d HPjk2IhOMef7JvH5FnAmlSApKRG+05ZqJObrCvj13T5MCzx3sNynj9qpXtRBBB1klUn2 Zi0pTM3G3Qr6c3SQ6w9q6MQJg89edQLAtaMjhPQWBm2AGT9p+uS1aAr0IrLV/A4EFkRW YA2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=ni5C9w+7qny63dmRG3PiuwWWKhBpBoarH/hWJ1h/b68=; b=gLkCdD5RU39LnFfX9+0v7jXZ5br4zio8twj9Jj+LLGIrjKN4qg4qgtXJCN5JfaZiCz KPVVqKJVE3/AXfo/9G0HdJvlzyoANCGVtO69LRJIyIb1c6Pw+h0LWRWpVjk36D9fM/qh hbZjpdCFVRD4sHVyz24OBZeYK5TurHuVs532aroLcbFf7TFJIoMhhyZEP8EBRPzO82cR 5lZlrYpIA6qwj+EquMt+36GD6KEENkJkCgL1BMBKsl8O8hNh3JjrX3nMMOvVEBdVZP+B irdsyfZwPa0uJkVYpYv3OIOXtiltLt7DsBjrWganzEI803S6E4hJ38+/eB/r2PqSq5OR YJ4w== X-Gm-Message-State: ALoCoQky5OHIyYr9upLc5LWRziDJqTro2M1MPxdwpTd51WFA8bPh0VcS0kze6kgpbrurcgmreMSw5bmRxC7IFYLlYbSF1yDJ6dnY96o1g/x8NdtUihmtAP5hKfHBC/z+6EiAcAgG7FwkpauMo3+u7sP/IuRGXb9Xcfjw7j8QRZkUwpx20KjP6G6RFbDIUpn1md/Px576iLaY MIME-Version: 1.0 X-Received: by 10.52.22.40 with SMTP id a8mr943914vdf.49.1386786779345; Wed, 11 Dec 2013 10:32:59 -0800 (PST) Received: by 10.52.183.65 with HTTP; Wed, 11 Dec 2013 10:32:59 -0800 (PST) Date: Wed, 11 Dec 2013 18:32:59 +0000 Message-ID: From: Ben Laurie To: perpass , "saag@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [saag] Draft charter for a Transparency Working Group X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 18:33:06 -0000 http://www.ietf.org/mail-archive/web/therightkey/current/msg00680.html From dhc@dcrocker.net Wed Dec 11 10:42:37 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390981AE109; Wed, 11 Dec 2013 10:42:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRYuw8EiFuXA; Wed, 11 Dec 2013 10:42:35 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id C3D471AE107; Wed, 11 Dec 2013 10:42:34 -0800 (PST) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id rBBIgOww008968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Dec 2013 10:42:27 -0800 Message-ID: <52A8B1D0.2080304@dcrocker.net> Date: Wed, 11 Dec 2013 10:41:20 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Ben Laurie , perpass , "saag@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 11 Dec 2013 10:42:27 -0800 (PST) Subject: Re: [saag] [perpass] Draft charter for a Transparency Working Group X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 18:42:37 -0000 On 12/11/2013 10:32 AM, Ben Laurie wrote: > http://www.ietf.org/mail-archive/web/therightkey/current/msg00680.html The text isn't a draft charter. It's a very generic statement of an idea. Formulating that into the detail an actual charter will be helpful. The text needs to give some explanation of what is being proposed, beyond a highly cryptic label like "Cryptographically verifiable logs". A term like that could mean many things and from the message, I can't tell what is meant. The text needs to explain what sort of usage scenario is expected, with enough detail to make the scenario substantive. That permits the reader to get a sense of basic/likely relevance to operational environments. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From benl@google.com Wed Dec 11 10:53:07 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160F21ADF74 for ; Wed, 11 Dec 2013 10:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayeH3BQBUJm4 for ; Wed, 11 Dec 2013 10:53:06 -0800 (PST) Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id AFC701AE150 for ; Wed, 11 Dec 2013 10:53:02 -0800 (PST) Received: by mail-vb0-f47.google.com with SMTP id q12so1913500vbe.20 for ; Wed, 11 Dec 2013 10:52:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GulL1XNID9Z/onmYIilfZWVDcoTsC7wlDeqmEAr39n8=; b=IcQZGKFMS5jx63rpNl0Br7av9kdt2c+7MZVyReCdVeA3OVxnwp59Osj+FbrY/Lezqo 9RVb4V95dfrPRy5z+nbiBpdaiwt2kMuEJvOY5DPgCULjeRS2SEnQ8Hul1x+dFMxheEyG M0rBPhOsZZjQ+9tIA78NF1FX/yo32sbEPB/sNegJ76PwaZr9ogRmoUhmxWwN17lSbPq5 ioZA3QZJr/BJWbVsr46angHrR5xzuYowvWeWe2sava4lOwMLjhae7jkzBKcRyiD08u5x eY+WOVxbwahjSIlhEhkXy9JfInVOLV1c/GJftt4gnLil9aGFm5UAhi1R5erMpxuYz06e X51Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GulL1XNID9Z/onmYIilfZWVDcoTsC7wlDeqmEAr39n8=; b=YWhuu9KDxgeTW1QPZLIvqH3v6IC+b7CRNSq8iY+YIlaPDMw9byz0Jd3DdJBh2vyNvJ dEFUFPGfPpU/8E7dzdvx5MX+z2P6pwpBGHRqyolApIdqhrgFWZfOiNHEpKGsk37jvmQO NbeF0Or3UPHP54fVAg6D4lORZjyTEYqT+pEdqHa+JBw89cFLyB2f+SFsT+NOnWyrL/iQ xt+wILx0h4GYzAMxA/cfTNAX8JyYzcTBmG5N28a8JTlCkC3nxNn9k5cGZ89M5e1OYzLh JF4fVWoxQOt6fj02Lg31M8Z+gHwfNvdHw3d6E91qYcyUkUffbadMtMMakktTRkIfJ6rG mn9Q== X-Gm-Message-State: ALoCoQkn6MKFj5SaqPqV7xen3o8/64DwoGcTQuArE/8U1dNvhxviesYo7/62T7jSRX7RBbvIBH7kQQXMzAG6uo/Wf3dyVThFkvBwK+50hHoxu7ctYwT7jI5M0I8KVf+dkQuVQ8SMb+uyDzUq+kW/qymHhkOrRIiFrP2H8vWfGRMD+NX88vs/Rfyo94taIXm4NEdu35AJ7I4z MIME-Version: 1.0 X-Received: by 10.52.232.135 with SMTP id to7mr633102vdc.58.1386787976907; Wed, 11 Dec 2013 10:52:56 -0800 (PST) Received: by 10.52.183.65 with HTTP; Wed, 11 Dec 2013 10:52:56 -0800 (PST) In-Reply-To: <52A8B1D0.2080304@dcrocker.net> References: <52A8B1D0.2080304@dcrocker.net> Date: Wed, 11 Dec 2013 18:52:56 +0000 Message-ID: From: Ben Laurie To: Dave Crocker Content-Type: text/plain; charset=ISO-8859-1 Cc: perpass , "saag@ietf.org" Subject: Re: [saag] [perpass] Draft charter for a Transparency Working Group X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 18:53:07 -0000 On 11 December 2013 18:41, Dave Crocker wrote: > On 12/11/2013 10:32 AM, Ben Laurie wrote: >> >> http://www.ietf.org/mail-archive/web/therightkey/current/msg00680.html > > > > The text isn't a draft charter. It's a very generic statement of an idea. > Formulating that into the detail an actual charter will be helpful. > > The text needs to give some explanation of what is being proposed, beyond a > highly cryptic label like "Cryptographically verifiable logs". A term like > that could mean many things and from the message, I can't tell what is > meant. > > The text needs to explain what sort of usage scenario is expected, with > enough detail to make the scenario substantive. That permits the reader to > get a sense of basic/likely relevance to operational environments. Am I allowed to refer to RFC 6962 for background? Reiterating what's in there doesn't seem useful. From scott.brim@gmail.com Wed Dec 11 11:02:32 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33891ADBCD; Wed, 11 Dec 2013 11:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrvwBGx2pYfh; Wed, 11 Dec 2013 11:02:31 -0800 (PST) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id D517A1AD8D5; Wed, 11 Dec 2013 11:02:30 -0800 (PST) Received: by mail-oa0-f48.google.com with SMTP id l6so7725320oag.21 for ; Wed, 11 Dec 2013 11:02:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=795yZDj7DdiP12YnAA7TxcketLfq0rVudJbrto9egtY=; b=lTDwakyGst7PvmVqYGCrcWxsxos8MAniri3M0aco11rnMLOu+KUi1KNBXFOuCEugkL 3OLPFIS9i74cUOBuhLSgqkdQZBCSth6JzP3YoaO8NWIvSMzhwiKnv7gsJ5oFwIzkWTQO 57DizCFCJvXurkFSVQ/5/xjpR/oW5BhiR22MkbCFwUWfcE6plWj6MeccMFVz1sO0oJ+Z UtBGr/CW4BysZJs1QQN7fsnAy1NzhCZB+ssdI/fv9hcL7Ruu2xe81lVVgbP+hhfK4kMV dwD8xvlNrKnGEY3uowFF3g60GpTJA1pwDzuftkHEMjbRH02w8Xp+XQgs2rWxeSgEAH2l km3Q== X-Received: by 10.60.146.229 with SMTP id tf5mr2362568oeb.27.1386788545081; Wed, 11 Dec 2013 11:02:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.48.9 with HTTP; Wed, 11 Dec 2013 11:02:04 -0800 (PST) In-Reply-To: <004101cef689$99b93f90$cd2bbeb0$@rozanak.com> References: <004101cef689$99b93f90$cd2bbeb0$@rozanak.com> From: Scott Brim Date: Wed, 11 Dec 2013 14:02:04 -0500 Message-ID: To: Hosnieh Rafiee Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Ops WG , IETF Security Area Advisory Group , "<, apps-discuss@ietf.org>, " , sacm@ietf.org Subject: Re: [saag] [apps-discuss] new mailing list in security area X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 19:02:32 -0000 On Wed, Dec 11, 2013 at 10:56 AM, Hosnieh Rafiee wrote: > The purpose > is to find solutions to automate authentication and use network layer for > this means but at the same time take care of performance, privacy and the > possibility of this solution. > > https://www.ietf.org/mailman/listinfo/secauth Hosnieh, I look forward to this. I start out skeptical, because I suspect that all the reasons for the end-to-end argument will be applicable here, but I remain open-minded. Scott From mouse@Chip.Rodents-Montreal.ORG Wed Dec 11 11:46:05 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 710891AE1A3 for ; Wed, 11 Dec 2013 11:46:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2kgj3vrAg74 for ; Wed, 11 Dec 2013 11:46:04 -0800 (PST) Received: from Chip.Rodents-Montreal.ORG (Chip.Rodents-Montreal.ORG [216.46.0.66]) by ietfa.amsl.com (Postfix) with ESMTP id 70CF31ADFAD for ; Wed, 11 Dec 2013 11:46:04 -0800 (PST) Received: (from mouse@localhost) by Chip.Rodents-Montreal.ORG (8.8.8/8.8.8) id OAA29160; Wed, 11 Dec 2013 14:40:03 -0500 (EST) Date: Wed, 11 Dec 2013 14:40:03 -0500 (EST) From: Mouse Message-Id: <201312111940.OAA29160@Chip.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: Wed, 11 Dec 2013 14:35:39 -0500 (EST) To: saag@ietf.org In-Reply-To: <004101cef689$99b93f90$cd2bbeb0$@rozanak.com> References: <004101cef689$99b93f90$cd2bbeb0$@rozanak.com> Subject: Re: [saag] new mailing list in security area X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 19:46:05 -0000 > There is a new mailing list in security area. [...] Sounds possibly up my alley. But... > Looking forward to see your participations there :-) ...it'd help if you gave the list management address (or at least the list post address, to which I trust we can just append -request). All I saw was a Web URL (oddly, present twice, with no explanation of why), and one that was HTTPS and thus useless to me even if I were willing to use the Web to manage email (which I'm not). /~\ 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 ietf@rozanak.com Wed Dec 11 12:13:49 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7611AE0E3; Wed, 11 Dec 2013 12:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6Jo81IobzgX; Wed, 11 Dec 2013 12:13:48 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 07E9E1ADFA1; Wed, 11 Dec 2013 12:13:48 -0800 (PST) Received: from kopoli (g231191095.adsl.alicedsl.de [92.231.191.95]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LmbFL-1VIKM82IcN-00a1zI; Wed, 11 Dec 2013 15:13:42 -0500 From: "Hosnieh Rafiee" To: "'Mouse'" , , , , References: <004101cef689$99b93f90$cd2bbeb0$@rozanak.com> <201312111940.OAA29160@Chip.Rodents-Montreal.ORG> In-Reply-To: <201312111940.OAA29160@Chip.Rodents-Montreal.ORG> Date: Wed, 11 Dec 2013 21:13:30 +0100 Message-ID: <004201cef6ad$7b2991a0$717cb4e0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEbq7nIPHMLdLerYKkR6aMsmA3rUQIznEoGm6RhcbA= Content-Language: en-us X-Provags-ID: V02:K0:oflu91ICOJRXypAx6hSBhPz7vQ4+vbOdldVUBGMY/Et hofng2iypgYTDfKHK0x1C/4hv746RJi9VZ3y73mZ3LMPV7FtGr NZlGxgw/5QelW9ArmkN4gC881vsmN22OJpcJA7e+a73C4ZnEyp EGBHWVovX4KbZ0KVIs2MJewgcqvKVpRiV5MwIDUUfe/41GJSQ0 553grgsCeCQj6yYyaEtdjPxjRFNwos8aFvrDXa1CXo6ME7Eiwc 72lEwpI6JvJHPkiBVoi1Sqagj5p5qfOD2lXpF0grRaUHl/Uq9I 9zSvaelSzxV+jS+YaTZEFyc77G7NNjV52EjL/a4kzSEfEzYyQT wW5oZHaFG5Y/QX8ad1bU= Subject: Re: [saag] new mailing list in security area X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 20:13:49 -0000 Hi, > -----Original Message----- > From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Mouse > Sent: Wednesday, December 11, 2013 8:40 PM > To: saag@ietf.org > Subject: Re: [saag] new mailing list in security area > > > There is a new mailing list in security area. [...] > > Sounds possibly up my alley. But... > > > Looking forward to see your participations there :-) > > ...it'd help if you gave the list management address (or at least the list post > address, to which I trust we can just append -request). All I saw was a Web > URL (oddly, present twice, with no explanation of why), and one that was > HTTPS and thus useless to me even if I were willing to use the Web to manage > email (which I'm not). To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/secauth or, via email, send a message with subject or body 'help' to secauth-request@ietf.org You can reach the person managing the list at: secauth-owner@ietf.org Send secaut mailing list submissions to: secauth@ietf.org thanks, smile, Hosnieh From hallam@gmail.com Wed Dec 11 13:50:17 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5C61AE12D; Wed, 11 Dec 2013 13:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KlNblSQJCldC; Wed, 11 Dec 2013 13:50:15 -0800 (PST) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 6D26B1AE11B; Wed, 11 Dec 2013 13:50:15 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id w62so7213185wes.3 for ; Wed, 11 Dec 2013 13:50:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YdmJWSnNncl1loJeB6cYYWy3ycRbKGb3wgMVHc7zTSQ=; b=l5u3y8o3tMR/x32hBwc1tC7ZWp5JzF6/0GnxReCWqDdfxKS6VJez+uSb7d/ZxGyY7O BmI2tF9hgtIaJLEI792qJPo/qmRbnwpOzx0pllOVQ5YilByCE3zORvtlfIxazuL4/RfO cYG1fFBD0s99r+jun8jcI9AGFZCFazeOXFM+HHkBlbJi9F6by8hPAXyV9mNVgjM6WJ4w iFF1BEGKPUNtT3i6nazgK+79qB3JfoZ77xyb5xgExeDjF+8ic+xRHwFRy/GIQ0XreO9j uw5kSnSfTbCzGxiUoIFZH60zGACK3BDd/Yn3tIRLCuWMj0NVcvmjX7HKNraN7ZpVZWPg 1L7A== MIME-Version: 1.0 X-Received: by 10.194.11.38 with SMTP id n6mr3357557wjb.25.1386798609207; Wed, 11 Dec 2013 13:50:09 -0800 (PST) Received: by 10.194.243.136 with HTTP; Wed, 11 Dec 2013 13:50:08 -0800 (PST) In-Reply-To: References: <52A8B1D0.2080304@dcrocker.net> Date: Wed, 11 Dec 2013 16:50:08 -0500 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=047d7b5d57107a377504ed4936fc Cc: perpass , Dave Crocker , "saag@ietf.org" Subject: Re: [saag] [perpass] Draft charter for a Transparency Working Group X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 21:50:17 -0000 --047d7b5d57107a377504ed4936fc Content-Type: text/plain; charset=ISO-8859-1 On Wed, Dec 11, 2013 at 1:52 PM, Ben Laurie wrote: > On 11 December 2013 18:41, Dave Crocker wrote: > > On 12/11/2013 10:32 AM, Ben Laurie wrote: > >> > >> http://www.ietf.org/mail-archive/web/therightkey/current/msg00680.html > > > > > > > > The text isn't a draft charter. It's a very generic statement of an > idea. > > Formulating that into the detail an actual charter will be helpful. > > > > The text needs to give some explanation of what is being proposed, > beyond a > > highly cryptic label like "Cryptographically verifiable logs". A term > like > > that could mean many things and from the message, I can't tell what is > > meant. > > > > The text needs to explain what sort of usage scenario is expected, with > > enough detail to make the scenario substantive. That permits the reader > to > > get a sense of basic/likely relevance to operational environments. > > Am I allowed to refer to RFC 6962 for background? > > Reiterating what's in there doesn't seem useful. Well how far do we want the group to be allowed to stray from RFC 6962? One approach would be to divide the problem up into two parts: * An append only log that provides a cryptographic assurance of integrity that is independent of the trustworthiness of the log maintainer from the time of the last checkpoint. * Application of the above to the specific use cases Initial use cases that the WG agreed to deliver might be * PKIX certificate signing certificates * PKIX TLS end entity certificates Use cases that are in scope but without a delivery undertaking might be OpenPGP, S/MIME, etc. -- Website: http://hallambaker.com/ --047d7b5d57107a377504ed4936fc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Dec 11, 2013 at 1:52 PM, Ben Laurie <<= a href=3D"mailto:benl@google.com" target=3D"_blank">benl@google.com>= wrote:
On 11 December 2013 18:41,= Dave Crocker <dhc@dcrocker.net&= gt; wrote:
> On 12/11/2013 10:32 AM, Ben Laurie wrote:
>>
>> http://www.ietf.org/mail-archive/web/the= rightkey/current/msg00680.html
>
>
>
> The text isn't a draft charter. =A0It's a very generic stateme= nt of an idea.
> Formulating that into the detail an actual charter will be helpful. >
> The text needs to give some explanation of what is being proposed, bey= ond a
> highly cryptic label like "Cryptographically verifiable logs"= ;. =A0A term like
> that could mean many things and from the message, I can't tell wha= t is
> meant.
>
> The text needs to explain what sort of usage scenario is expected, wit= h
> enough detail to make the scenario substantive. =A0That permits the re= ader to
> get a sense of basic/likely relevance to operational environments.

Am I allowed to refer to RFC 6962 for background?

Reiterating what's in there doesn't seem useful.
<= br>
Well how far do we want the group to be allowed to stray from= RFC 6962?

One approach would be to divide the pro= blem up into two parts:

* An append only log that provides a cryptographic assu= rance of integrity that is independent of the trustworthiness of the log ma= intainer from the time of the last checkpoint.

* Application of the above to the specific use cases

Initial use cases that the WG agreed to deliver might be
<= br>
* PKIX certificate signing certificates
* PKIX TLS = end entity certificates

Use cases that are in scope but without a delivery unde= rtaking might be OpenPGP, S/MIME, etc.


<= div>

--
Website: http://hallambaker.com/
--047d7b5d57107a377504ed4936fc-- From benl@google.com Wed Dec 11 13:57:02 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF39B1AE117 for ; Wed, 11 Dec 2013 13:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taLnZj8LnNVT for ; Wed, 11 Dec 2013 13:57:01 -0800 (PST) Received: from mail-vb0-x236.google.com (mail-vb0-x236.google.com [IPv6:2607:f8b0:400c:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFE71AE01E for ; Wed, 11 Dec 2013 13:57:01 -0800 (PST) Received: by mail-vb0-f54.google.com with SMTP id g10so2123682vbg.27 for ; Wed, 11 Dec 2013 13:56:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=h0eD1n/qbWAHOSFWMo/Tt3zemr505xe+E8q27A830Z8=; b=DvNUodh/H4kR/LMKCyQL4cYDSTuXA3LLOJeWEmJmLahgygcud/S9MwYB6A5VJDNb8+ qDghJo7aSOgoBipIvhwD6IASMr+EWyT234LfZdj2MkjWxNk2Iigi4EG4KxSmOM/dSCbe b90Lk5x7x6GzWwnUbVTYm0wwOp3aWrGtEixN7pvEf+NQ8btjApsu4KU2LCtRJeF/dVsP 04cGDXGb8pdnWnwHWRLrZlageBYG960E0pTmgxpVIRrHYwqGZJUkxGoGnqYgOGsTUvGu UxkCaVYFuG9aYiCygNO490VWHF+huz3+Cf3d/Be4aHGjeDGiTx3Un6RKQU6K2fMwfRdI YrfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=h0eD1n/qbWAHOSFWMo/Tt3zemr505xe+E8q27A830Z8=; b=FdgPWwZ3dmsFw8dQbnH94BC5HhOr91JP+ZLogfKzxfdjL7G83b0AEnPi3pP0Lyb2H1 1TJaI2OlQLYumWAkO6JmnFkDLryLyZdDA+5kpm1S7lIwvTir4rBlhdwGVGL8lljt/+vH lUSMCgmZ0tJDHSZb5n0gQRYC8qTPQo0Ukj4qYh+1uMLavfR2pMjr0rlc2sxaXqj72lDP 5t6xJPLpiA4QFgF5VPz6JvSX64gp2JMK3T7mAZldVATettwsbVw9T5So3W62s3aijE80 UUkd6KFbZmR5A2hlxDJt4eQksLjVEXBDmmtZm22XSjg+lWyfoH0TmHsBFHeEmWL/aGZS myKQ== X-Gm-Message-State: ALoCoQnzMdPK5iU5DXEtL9eELmPDnParPizOPzRAFTCW5Qe9W3/VK4qwxAzRPEnTOEsyQ25jl1AT56QUBrMl5+0sF6xfIz6rNFGwuhOW3t1QqjrjnoJCWubmTZ0fwEgLLuJBzEA87peWVLEpleBRhgSmZ17e8R4nBPU1xRItNKtbX63NMVEZWr5sRrQA9/83tCZFpS00wNoR MIME-Version: 1.0 X-Received: by 10.221.64.17 with SMTP id xg17mr1589166vcb.5.1386799015491; Wed, 11 Dec 2013 13:56:55 -0800 (PST) Received: by 10.52.183.65 with HTTP; Wed, 11 Dec 2013 13:56:55 -0800 (PST) In-Reply-To: References: <52A8B1D0.2080304@dcrocker.net> Date: Wed, 11 Dec 2013 21:56:55 +0000 Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 Cc: perpass , Dave Crocker , "saag@ietf.org" Subject: Re: [saag] [perpass] Draft charter for a Transparency Working Group X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 21:57:03 -0000 On 11 December 2013 21:50, Phillip Hallam-Baker wrote: > > > > On Wed, Dec 11, 2013 at 1:52 PM, Ben Laurie wrote: >> >> On 11 December 2013 18:41, Dave Crocker wrote: >> > On 12/11/2013 10:32 AM, Ben Laurie wrote: >> >> >> >> http://www.ietf.org/mail-archive/web/therightkey/current/msg00680.html >> > >> > >> > >> > The text isn't a draft charter. It's a very generic statement of an >> > idea. >> > Formulating that into the detail an actual charter will be helpful. >> > >> > The text needs to give some explanation of what is being proposed, >> > beyond a >> > highly cryptic label like "Cryptographically verifiable logs". A term >> > like >> > that could mean many things and from the message, I can't tell what is >> > meant. >> > >> > The text needs to explain what sort of usage scenario is expected, with >> > enough detail to make the scenario substantive. That permits the reader >> > to >> > get a sense of basic/likely relevance to operational environments. >> >> Am I allowed to refer to RFC 6962 for background? >> >> Reiterating what's in there doesn't seem useful. > > > Well how far do we want the group to be allowed to stray from RFC 6962? > > One approach would be to divide the problem up into two parts: > > * An append only log that provides a cryptographic assurance of integrity > that is independent of the trustworthiness of the log maintainer from the > time of the last checkpoint. > > * Application of the above to the specific use cases > > Initial use cases that the WG agreed to deliver might be > > * PKIX certificate signing certificates > * PKIX TLS end entity certificates > > Use cases that are in scope but without a delivery undertaking might be > OpenPGP, S/MIME, etc. Agree, I just want to be able to refer to 6962 for what "cryptographically verifiable log" means. From dhc@dcrocker.net Wed Dec 11 14:03:31 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2D81ADEBB; Wed, 11 Dec 2013 14:03:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kkagd7zmzJyZ; Wed, 11 Dec 2013 14:03:30 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 78EB61ADDBD; Wed, 11 Dec 2013 14:03:30 -0800 (PST) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id rBBM3Kh6012986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Dec 2013 14:03:23 -0800 Message-ID: <52A8E0E9.5020409@dcrocker.net> Date: Wed, 11 Dec 2013 14:02:17 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Ben Laurie References: <52A8B1D0.2080304@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 11 Dec 2013 14:03:24 -0800 (PST) Cc: perpass , "saag@ietf.org" Subject: Re: [saag] [perpass] Draft charter for a Transparency Working Group X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 22:03:31 -0000 On 12/11/2013 1:56 PM, Ben Laurie wrote: > Agree, I just want to be able to refer to 6962 for what > "cryptographically verifiable log" means. Being able to cite a doc that defines the term is always nice; so yes, please do cite freely. My own view is that charters need to have some pedagogy, since one goal of a charter is to explain the work to folk who might get involved (eventually). While a citation is formally sufficient, it's not the best pedagogy. So I tend to prefer to have a charter be somewhat self-explanatory about its basic constructs, unless they are already very well established in industry. In this case, I think what you mean is /not/ obvious to a reader who is not already immersed in the topic. So some sort of superficial explanation would help, with the citation pointing the reader to the deeper discussion. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From paul@marvell.com Wed Dec 11 17:39:17 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6071AE0A3 for ; Wed, 11 Dec 2013 17:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKkeOdVMuVsr for ; Wed, 11 Dec 2013 17:39:16 -0800 (PST) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5391AE06B for ; Wed, 11 Dec 2013 17:39:16 -0800 (PST) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id rBC1dASN009279; Wed, 11 Dec 2013 17:39:10 -0800 Received: from sc-owa01.marvell.com ([199.233.58.136]) by mx0a-0016f401.pphosted.com with ESMTP id 1gpfqaauxf-34 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 11 Dec 2013 17:39:10 -0800 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Wed, 11 Dec 2013 17:39:05 -0800 From: Paul Lambert To: "Scott R. Corzine" , Ralf Skyper Kaiser Date: Wed, 11 Dec 2013 17:39:04 -0800 Thread-Topic: [saag] New I-D: Password Storage Using Public Key Encryption Thread-Index: Ac72GL9jdMR+RmvrRX2bt1LIZPtSpAAwd38Q Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D018B7B36F30@SC-VEXCH2.marvell.com> References: <52A49582.4070307@ripe.net> <1C9F17D1873AFA47A969C4DD98F98A750FA95D8D@xmb-rcd-x10.cisco.com> <1C9F17D1873AFA47A969C4DD98F98A750FA95E2E@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7BAC95F5A7E67643AAFB2C31BEE662D018B7B36F30SCVEXCH2marve_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2013-12-11_06:2013-12-11,2013-12-11,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1312110158 Cc: IETF SAAG Subject: Re: [saag] New I-D: Password Storage Using Public Key Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 01:39:17 -0000 --_000_7BAC95F5A7E67643AAFB2C31BEE662D018B7B36F30SCVEXCH2marve_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQo+SG93IGRvZXMgdGhhdCBsb29rPyAgRGlkIEkgbWlzcyBhbnl0aGluZyBpbiB0aGlzIHBhcnQ/ DQoNCkkgbWlzc2VkIHNvbWV0aGluZywgaWYgeW91IHVzZSBhIGxhcmdlIHJhbmRvbSBzYWx0IGlz IHlvdXIgcHJvcG9zYWwgdXNlZnVsPw0KDQpQYXVsDQo= --_000_7BAC95F5A7E67643AAFB2C31BEE662D018B7B36F30SCVEXCH2marve_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpw Lk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+ PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRh aG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZndDs8L3NwYW4+PC9iPkhvdyBkb2Vz IHRoYXQgbG9vaz8gJm5ic3A7RGlkIEkgbWlzcyBhbnl0aGluZyBpbiB0aGlzIHBhcnQ/PG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5JIG1pc3NlZCBzb21ldGhpbmcsIGlm IHlvdSB1c2UgYSBsYXJnZSByYW5kb20gc2FsdCBpcyB5b3VyIHByb3Bvc2FsIHVzZWZ1bD88bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2sn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjpibGFjayc+UGF1bDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48 L2JvZHk+PC9odG1sPg== --_000_7BAC95F5A7E67643AAFB2C31BEE662D018B7B36F30SCVEXCH2marve_-- From benl@google.com Thu Dec 12 03:00:03 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9C31AE20D for ; Thu, 12 Dec 2013 03:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybXQiCrU1zEB for ; Thu, 12 Dec 2013 03:00:02 -0800 (PST) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 326401AE087 for ; Thu, 12 Dec 2013 03:00:02 -0800 (PST) Received: by mail-ve0-f171.google.com with SMTP id pa12so161802veb.30 for ; Thu, 12 Dec 2013 02:59:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eacEjswDijWna5jYWqt65RIk1B5Rh7IWLNcsQxUgtH8=; b=JTW4BMkZNYr1+ntUmmrHyPbzjInbfEBMu1/wzt+7r4IoMSlTsPoVFhOh+RjoANFFhs Hudlpb3zRZfG1ikhnEVruNUSsSSSsCIjgA9By8o1Y3PIZqWToNKoGDegUegcEPyP27dQ wJ+/h8WGnukZZLMtTltxgaw6Cgb6CwFEsxXp8Rx8WGK0CIj7duPZwLUB6M9farX11+aO lXGCXb3D4Yy8zhL0ACRozevkZaofDC4Wh7Vn+WMXIE8EPN3xhCnl+VhR/nM1D8uLM0TT 2nTGAY6G+KTDZaUoOXatfOAa/BsLM/IuhQbTmfzjOiTR/Vw1rEIWeiXifNi1Y4DxchUZ x8IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eacEjswDijWna5jYWqt65RIk1B5Rh7IWLNcsQxUgtH8=; b=AsHNOITRIfswJnYK+OGwwO731PiSqcNKt/Z8zfb8VK1IyOPSkiNDLKVWzU5Xq7qyNP Bog3JhQdEylE+LCoZLPccEK0e8Vc76YacO71EayBApFXG1Ww+XldCH7/HqBlISpKUGEy 4KPYWzIC36KNs2IO2voHntWmG9jSmR/ptotK1jNFSKIC8D6jqG03hMo/P8Sx3k8GYzag jHTQaUyg+hofn5L6LW4Id2yg/3xZI5xnU3axwEwHMkBH0D71yfaksEr0979u3Zrt5sW1 vNWxLLJifb50v2UY0xDNw1zRbs0n2xkvnhV17qTkW3rKgKV2gxff1zLYaJ/PZzQQyHKW UYMA== X-Gm-Message-State: ALoCoQkqid5fv7SgcEXHlwWmN686O2F1teOZGX+tdB+EqjBhePHip4G6Zefvwfvy28QustQBZ5lhK9ZVWavvVIcaKYtaE1/HqrGYYyRdH0TfLYv5PTHGOtf3YKewo+H+/lKjUiwGsIUcXJww2bDFUk76j/VXer4OdV2qgV5tIu1FEZYVft5QZv6XH/QuLbM57Mva5NK4WR1u MIME-Version: 1.0 X-Received: by 10.220.144.80 with SMTP id y16mr3265725vcu.4.1386845995978; Thu, 12 Dec 2013 02:59:55 -0800 (PST) Received: by 10.52.183.65 with HTTP; Thu, 12 Dec 2013 02:59:55 -0800 (PST) In-Reply-To: <52A8E0E9.5020409@dcrocker.net> References: <52A8B1D0.2080304@dcrocker.net> <52A8E0E9.5020409@dcrocker.net> Date: Thu, 12 Dec 2013 10:59:55 +0000 Message-ID: From: Ben Laurie To: Dave Crocker , "therightkey@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: perpass , "saag@ietf.org" Subject: Re: [saag] [perpass] Draft charter for a Transparency Working Group X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 11:00:03 -0000 [please include therightkey on replies] On 11 December 2013 22:02, Dave Crocker wrote: > On 12/11/2013 1:56 PM, Ben Laurie wrote: >> >> Agree, I just want to be able to refer to 6962 for what >> "cryptographically verifiable log" means. > > > > Being able to cite a doc that defines the term is always nice; so yes, > please do cite freely. > > My own view is that charters need to have some pedagogy, since one goal of a > charter is to explain the work to folk who might get involved (eventually). > While a citation is formally sufficient, it's not the best pedagogy. So I > tend to prefer to have a charter be somewhat self-explanatory about its > basic constructs, unless they are already very well established in industry. > > In this case, I think what you mean is /not/ obvious to a reader who is not > already immersed in the topic. So some sort of superficial explanation > would help, with the citation pointing the reader to the deeper discussion. How about this footnote? "A cryptographically verifiable log is an append-only log of hashes of more-or-less anything that can prove its own correctness cryptographically. See RFC 6962, http://www.links.org/files/CertificateTransparencyVersion2.1a.pdf and http://www.links.org/files/RevocationTransparency.pdf for background." From benl@google.com Thu Dec 12 03:06:33 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A74F1AE216 for ; Thu, 12 Dec 2013 03:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43leYLMsDa3G for ; Thu, 12 Dec 2013 03:06:32 -0800 (PST) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D59631AE1EC for ; Thu, 12 Dec 2013 03:06:31 -0800 (PST) Received: by mail-vc0-f174.google.com with SMTP id id10so159736vcb.33 for ; Thu, 12 Dec 2013 03:06:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/C//b7RfRfNcZF3yIEQq1pZ7cT8QuUVfudAWowNhHQA=; b=mRRRGVjYYbieMZwlMMgVnohI6OphgBXVBNydg6HaRk2zL4t8GptaomJbWUhh3shq5S h9VEniux84YJinbNd2POsAWqc8aRYD73Wk50ASX37RsAGNY2DzP1nJpcZD7DqF/2WehP qpbBwyIeaRavApXdyNkgok49YZm1+zdCJcsQnJ4r8GhYC8NFyXeizMQA+jDeFwkwLHwn 15TZFTIcGmoMoVLdXekgufKn1Pm/4K7a5Q1IdncqHQr6QSmBVpSEikrAZiKQX9oe2+S5 2sQqD6cOHaAz5K8x6Iucka1UB7ImJRwEQRKNIouTqLhCDtGgQGZwXiMYy/jaXWWtCSaZ JIbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/C//b7RfRfNcZF3yIEQq1pZ7cT8QuUVfudAWowNhHQA=; b=lmnJtlHy4iLtonugVxXMiJ3pumu8GHf4Luxk8dXhjj/hjCX3mTrj0ZRlDgrK0QILXc Ma3fOpb7Ju57K170cquVmlXFcZV5QdYwl47LwwqWPfWdqpz5LX0nzjwXw8vLgP2C2Cz5 8S8Sq8cEIRwtv4q8KO4yWRQ43jCDq1LhYIdTsOl93ME+XMcdEntzJ1dRjTR4uKw9VLXn Ud4ExCum2+bvQZg/r/IZ7mtiBOy+YBewO+TWmF/gpBU2vbEptP/bqo3S+tG7WrCTJNOi Fj8oobBiowwRC6B0qTBCwcx20+qz2i7e8Edb59RQR/Na+5vBK+fE5lmaEYcSXuuKh5Fj Zw7g== X-Gm-Message-State: ALoCoQlUYonkUlLAXomVopd+7KD9bX3XmBYyJzrlJlkn4yqzcJLJT7sGPtSQ0M2eeLmoSsNLas1LK6b6uzQW3yPRm06q2FmPlnV53PwvbJ0HdNChLX4GhHVXY5xkb3d0S1Dk3zomkheKi7wMZAVQSBRykhBoWHWWp92pVmD935WxGbDROdk3nMMPZtlB8B+004y/CoWP+gCB MIME-Version: 1.0 X-Received: by 10.58.54.69 with SMTP id h5mr3166755vep.25.1386846385755; Thu, 12 Dec 2013 03:06:25 -0800 (PST) Received: by 10.52.183.65 with HTTP; Thu, 12 Dec 2013 03:06:25 -0800 (PST) In-Reply-To: References: <52A8B1D0.2080304@dcrocker.net> Date: Thu, 12 Dec 2013 11:06:25 +0000 Message-ID: From: Ben Laurie To: Douglas Otis Content-Type: text/plain; charset=ISO-8859-1 Cc: perpass , Phillip Hallam-Baker , Dave Crocker , "saag@ietf.org" Subject: Re: [saag] [perpass] Draft charter for a Transparency Working Group X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 11:06:33 -0000 On 11 December 2013 23:48, Douglas Otis wrote: > > On Dec 11, 2013, at 1:56 PM, Ben Laurie wrote: > > Agree, I just want to be able to refer to 6962 for what > "cryptographically verifiable log" means. > > > Dear Ben, > > There was an eXtensible Access Method, XAM, developed by SNIA. This > permitted vendors a means to implement strategies for handling massive > amounts of data in a manner called Content Addressable Storage, such as > EMC^2's Centera product. The data blobs create multiple secure hashes that > act within a standardized label. The blobs are combined with timestamps and > XML MIME tags. This removes a need for difficult to manage file hierarchy. > One of the benefits of this scheme is data can not change without detection. A brief romp through the spec suggests that XUIDs could be hashes, but don't have to be. In particular, identical XSets do not have to have identical XUIDs. In the case where they are hashes (or are otherwise one-to-one linked to XSets), then a transparent log might well be usefully applied to them. From hallam@gmail.com Thu Dec 12 05:58:41 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C968D1AE2CF; Thu, 12 Dec 2013 05:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7HML06Udnjv; Thu, 12 Dec 2013 05:58:38 -0800 (PST) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD0E1AE2B5; Thu, 12 Dec 2013 05:58:38 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id z2so2512693wiv.6 for ; Thu, 12 Dec 2013 05:58:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tBFcfDpAKp4bMDkp2SeS+kWP177NdjlQx41ferR2l20=; b=ssjFnXmxC2Qvd7OtPmSoGJHCNfmhGsS7aGi6SmRXrtymheL3zirqp7czehp4rKoxWW JgxnldM9OZKnh3hk4Qxy5HTJC8vUj+hUjy6M7Ct3wGfoVXWCE1Yx5I+L9uLLrt1TQATY 7c1uRKkkD7EmAK0K9wPZknDbU6ukmxWd65oqz5ut2DPgfP7eRmm2GfPjfiNGfuTkawrf h21YIj4htTGDWWPumCfFzEl3FnKzUvBhwfWk0mxAvJj7VbaU8vUTXlHsnZz1VrXo5Tvy VFM2sRrByQJtnVdBZ+L4LenrUjK7VnOAujEk1pMXhn45A9jfkUujYT/pAvAmm8THUdLi OHXQ== MIME-Version: 1.0 X-Received: by 10.180.109.201 with SMTP id hu9mr7690708wib.59.1386856711905; Thu, 12 Dec 2013 05:58:31 -0800 (PST) Received: by 10.194.243.136 with HTTP; Thu, 12 Dec 2013 05:58:31 -0800 (PST) In-Reply-To: References: <52A8B1D0.2080304@dcrocker.net> Date: Thu, 12 Dec 2013 08:58:31 -0500 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=e89a8f2356bdaae8fc04ed56bdf3 Cc: "saag@ietf.org" , perpass , Douglas Otis , Dave Crocker Subject: Re: [saag] [perpass] Draft charter for a Transparency Working Group X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 13:58:42 -0000 --e89a8f2356bdaae8fc04ed56bdf3 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 12, 2013 at 6:06 AM, Ben Laurie wrote: > On 11 December 2013 23:48, Douglas Otis wrote: > > > > On Dec 11, 2013, at 1:56 PM, Ben Laurie wrote: > > > > Agree, I just want to be able to refer to 6962 for what > > "cryptographically verifiable log" means. > > > > > > Dear Ben, > > > > There was an eXtensible Access Method, XAM, developed by SNIA. This > > permitted vendors a means to implement strategies for handling massive > > amounts of data in a manner called Content Addressable Storage, such as > > EMC^2's Centera product. The data blobs create multiple secure hashes > that > > act within a standardized label. The blobs are combined with timestamps > and > > XML MIME tags. This removes a need for difficult to manage file > hierarchy. > > One of the benefits of this scheme is data can not change without > detection. > > A brief romp through the spec suggests that XUIDs could be hashes, but > don't have to be. In particular, identical XSets do not have to have > identical XUIDs. > > In the case where they are hashes (or are otherwise one-to-one linked > to XSets), then a transparent log might well be usefully applied to > them. > If we get into that area I have to point out that I am currently engaged by a client who is defending a case in which a relevant patent is being asserted. -- Website: http://hallambaker.com/ --e89a8f2356bdaae8fc04ed56bdf3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Dec 12, 2013 at 6:06 AM, Ben Laurie <<= a href=3D"mailto:benl@google.com" target=3D"_blank">benl@google.com>= wrote:
On 11 December 2013 23:48,= Douglas Otis <doug.mtview@gmai= l.com> wrote:
>
> On Dec 11, 2013, at 1:56 PM, Ben Laurie <benl@google.com> wrote:
>
> Agree, I just want to be able to refer to 6962 for what
> "cryptographically verifiable log" means.
>
>
> Dear Ben,
>
> There was an eXtensible Access Method, XAM, developed by SNIA. =A0This=
> permitted vendors a means to implement strategies for handling massive=
> amounts of data in a manner called Content Addressable Storage, such a= s
> EMC^2's Centera product. The data blobs create multiple secure has= hes that
> act within a standardized label. The blobs are combined with timestamp= s and
> XML MIME tags. This removes a need for difficult to manage file hierar= chy.
> One of the benefits of this scheme is data can not change without dete= ction.

A brief romp through the spec suggests that XUIDs could be hashes, bu= t
don't have to be. In particular, identical XSets do not have to have identical XUIDs.

In the case where they are hashes (or are otherwise one-to-one linked
to XSets), then a transparent log might well be usefully applied to
them.

If we get into that area I have to point out that I = am currently engaged by a client who is defending a case in which a relevan= t patent is being asserted.


--
Website: http://h= allambaker.com/
--e89a8f2356bdaae8fc04ed56bdf3-- From doug.mtview@gmail.com Wed Dec 11 15:48:42 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7781AE17D; Wed, 11 Dec 2013 15:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYU1zYu_rwi0; Wed, 11 Dec 2013 15:48:41 -0800 (PST) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 067F91AE154; Wed, 11 Dec 2013 15:48:40 -0800 (PST) Received: by mail-pb0-f54.google.com with SMTP id un15so11002308pbc.27 for ; Wed, 11 Dec 2013 15:48:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=g/uFLdeCHwhqZ8DsOtxNEZEoVwDWI/zhDaLnFcmteis=; b=jxXU35zKeppK8OXLpjIao/e+A19HPUrAo0rvUXtnqirCPIy/rilU5uorNGIk0Qh219 Ae+pkUbPJm6WXdGtxSdA5cHOELrVz2rSDGdx4B/cZiSapsm9zfEV6OA4S3OHIsKx1OzC h0KI9Vn6R/4w7iFWxL6cdZ0JKCCy+rUx5ftL652VxRuwKBoOLTgjfPttcVeiOlluINMi RzVhwvmoBie5hLRKcFXCzxymAo9H9ABF0VBBDVLjPNf4k6q/KHuBydpLMgco/fuOiKF0 MN1PE3M4RkvmnNfzkDUTuwKFUpAQOqK6tkRfaSWafOsDimvlMKsjwgk5g9btmskOCjP9 tkQQ== X-Received: by 10.68.236.133 with SMTP id uu5mr5836245pbc.153.1386805715350; Wed, 11 Dec 2013 15:48:35 -0800 (PST) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id hw10sm35438286pbc.24.2013.12.11.15.48.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Dec 2013 15:48:34 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_7668D34D-229A-4CED-916E-7CD7BBF2477B" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Douglas Otis In-Reply-To: Date: Wed, 11 Dec 2013 15:48:31 -0800 Message-Id: References: <52A8B1D0.2080304@dcrocker.net> To: Ben Laurie X-Mailer: Apple Mail (2.1822) X-Mailman-Approved-At: Thu, 12 Dec 2013 08:01:16 -0800 Cc: perpass , Phillip Hallam-Baker , Dave Crocker , "saag@ietf.org" Subject: Re: [saag] [perpass] Draft charter for a Transparency Working Group X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 23:48:42 -0000 --Apple-Mail=_7668D34D-229A-4CED-916E-7CD7BBF2477B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 11, 2013, at 1:56 PM, Ben Laurie wrote: > Agree, I just want to be able to refer to 6962 for what > "cryptographically verifiable log" means. Dear Ben, There was an eXtensible Access Method, XAM, developed by SNIA. This = permitted vendors a means to implement strategies for handling massive = amounts of data in a manner called Content Addressable Storage, such as = EMC^2's Centera product. The data blobs create multiple secure hashes = that act within a standardized label. The blobs are combined with = timestamps and XML MIME tags. This removes a need for difficult to = manage file hierarchy. One of the benefits of this scheme is data can = not change without detection. SNIA now seems focused on identifying individuals. Perhaps this is an = outgrowth of their data-deduplication? http://www.snia.org/tech_activities/standards/curr_standards/xam Regards, Douglas Otis --Apple-Mail=_7668D34D-229A-4CED-916E-7CD7BBF2477B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Dec 11, 2013, at 1:56 PM, = Ben Laurie <benl@google.com> = wrote:

Agree, I just want to be able to = refer to 6962 for what
"cryptographically verifiable log" = means.

Dear Ben,

There = was an eXtensible Access Method, XAM, developed by SNIA.  This = permitted vendors a means to implement strategies for handling massive = amounts of data in a manner called Content Addressable Storage, such as = EMC^2's Centera product. The data blobs create multiple secure hashes = that act within a standardized label. The blobs are combined with = timestamps and XML MIME tags. This removes a need for difficult to = manage file hierarchy.  One of the benefits of this scheme is data = can not change without detection.

SNIA now = seems focused on identifying individuals.  Perhaps this is an = outgrowth of their data-deduplication?
=

Regards,
Douglas = Otis



<= /html>= --Apple-Mail=_7668D34D-229A-4CED-916E-7CD7BBF2477B-- From kent@bbn.com Thu Dec 12 08:36:52 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1DA1ADFF8; Thu, 12 Dec 2013 08:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGO89yiL6ZgQ; Thu, 12 Dec 2013 08:36:50 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id BC1071ADF9A; Thu, 12 Dec 2013 08:36:50 -0800 (PST) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:54108) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Vr9Fk-00083k-Fx; Thu, 12 Dec 2013 11:36:44 -0500 Message-ID: <52A9E61C.8030300@bbn.com> Date: Thu, 12 Dec 2013 11:36:44 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: perpass@ietf.org, saag References: <52A8B1D0.2080304@dcrocker.net> <52A8E0E9.5020409@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [saag] [perpass] Draft charter for a Transparency Working Group X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 16:36:52 -0000 Ben > How about this footnote? > > "A cryptographically verifiable log is an append-only log of hashes of > more-or-less anything that can prove its own correctness > cryptographically. See RFC 6962, > I'd like something a bit more technical, since the phrase "prove its own correctness" is pretty general. Hopefully there is text in 6962 that you can use. Steve From dhc@dcrocker.net Thu Dec 12 08:41:49 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D18C1AE034; Thu, 12 Dec 2013 08:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSxyo1VVPNZf; Thu, 12 Dec 2013 08:41:48 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E4BCB1ADFFE; Thu, 12 Dec 2013 08:41:47 -0800 (PST) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id rBCGfZhN029845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Dec 2013 08:41:38 -0800 Message-ID: <52A9E6FE.6060207@dcrocker.net> Date: Thu, 12 Dec 2013 08:40:30 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Stephen Kent , Ben Laurie References: <52A8B1D0.2080304@dcrocker.net> <52A8E0E9.5020409@dcrocker.net> <52A9E61C.8030300@bbn.com> In-Reply-To: <52A9E61C.8030300@bbn.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.0 (sbh17.songbird.com [72.52.113.66]); Thu, 12 Dec 2013 08:41:38 -0800 (PST) Cc: perpass@ietf.org, saag Subject: Re: [saag] [perpass] Draft charter for a Transparency Working Group X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 16:41:49 -0000 On 12/12/2013 8:36 AM, Stephen Kent wrote: > I'd like something a bit more technical, since the phrase "prove its > own correctness" is pretty general. Hopefully there is text in 6962 > that you can use. Ben, The other piece of information I'm suggesting is some text that explains how this mechanism will be used for the purpose that's claimed. Enough text to make clear why this is useful work. Although the utility might seem intuitively obvious (to some folk), having the charter make this explicit will help other readers who are less immersed in the topic. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From paul@marvell.com Thu Dec 12 08:48:43 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A471AE028; Thu, 12 Dec 2013 08:48:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z_TCEVqsxf1X; Thu, 12 Dec 2013 08:48:42 -0800 (PST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD0D1AD2EC; Thu, 12 Dec 2013 08:48:42 -0800 (PST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id rBCGmSHd019528; Thu, 12 Dec 2013 08:48:28 -0800 Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0b-0016f401.pphosted.com with ESMTP id 1gpgd4n56a-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 12 Dec 2013 08:48:28 -0800 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA.marvell.com ([::1]) with mapi; Thu, 12 Dec 2013 08:48:27 -0800 From: Paul Lambert To: Douglas Otis , Ben Laurie Date: Thu, 12 Dec 2013 08:48:26 -0800 Thread-Topic: [saag] [perpass] Draft charter for a Transparency Working Group Thread-Index: Ac73Wfrd+LJkHtEQRe2UEqFDYRYh6A== Message-ID: References: <52A8B1D0.2080304@dcrocker.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CECF27342A043paulmarvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2013-12-12_04:2013-12-12,2013-12-12,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1312120072 Cc: perpass , Phillip Hallam-Baker , Dave Crocker , "saag@ietf.org" Subject: Re: [saag] [perpass] Draft charter for a Transparency Working Group X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 16:48:44 -0000 --_000_CECF27342A043paulmarvellcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Dec 11, 2013, at 1:56 PM, Ben Laurie > wrote: Agree, I just want to be able to refer to 6962 for what "cryptographically verifiable log" means. Dear Ben, There was an eXtensible Access Method, XAM, developed by SNIA. This permit= ted vendors a means to implement strategies for handling massive amounts of= data in a manner called Content Addressable Storage, such as EMC^2's Cente= ra product. The data blobs create multiple secure hashes that act within a = standardized label. The blobs are combined with timestamps and XML MIME tag= s. This removes a need for difficult to manage file hierarchy. One of the = benefits of this scheme is data can not change without detection. Interesting =85 in IEEE we=92re defining =91services=92 as a hash/UUID-lik= e identifier https://mentor.ieee.org/802.11/dcn/12/11-12-0706-00-0isd-servi= ce-discovery-proposal.pptx ). UPnP and Bonjour are both mapped to a hash. = We=92re truncating them to 6 octets =85 but that=92s a different discussio= n. In looking at Transparency for =93X=94, I=92d suggest that the X can be an = arbitrary service identified as a hash. Paul SNIA now seems focused on identifying individuals. Perhaps this is an outg= rowth of their data-deduplication? http://www.snia.org/tech_activities/standards/curr_standards/xam Regards, Douglas Otis --_000_CECF27342A043paulmarvellcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

On Dec 11, 2013, at 1:56 PM, Ben Laurie <benl@google.com> wrote:

Agree, = I just want to be able to refer to 6962 for what
"cryptographically verifiable log" means.
Dear Ben,

There was an eXtensible Access Method, XAM, developed b= y SNIA.  This permitted vendors a means to implement strategies for ha= ndling massive amounts of data in a manner called Content Addressable Stora= ge, such as EMC^2's Centera product. The data blobs create multiple secure hashes that act within a standardized label. The bl= obs are combined with timestamps and XML MIME tags. This removes a need for= difficult to manage file hierarchy.  One of the benefits of this sche= me is data can not change without detection.
=

Interesting =85 in IEEE we=92re  defining = =91services=92 as a hash/UUID-like identifier htt= ps://mentor.ieee.org/802.11/dcn/12/11-12-0706-00-0isd-service-discovery-pro= posal.pptx ).  UPnP and Bonjour are both mapped to a hash. &n= bsp;We=92re truncating them to 6 octets =85 but that=92s a different discus= sion.

In looking at Transparency for =93X=94, I=92= d suggest that the X can be an arbitrary service identified as a hash. &nbs= p;

Paul


SNIA now seems focused on identif= ying individuals.  Perhaps this is an outgrowth of their data-deduplic= ation?

Regards,
Douglas Otis
=





--_000_CECF27342A043paulmarvellcom_-- From benl@google.com Thu Dec 12 10:51:57 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C76FC1AE3C0 for ; Thu, 12 Dec 2013 10:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rV_Ie_8EnH6 for ; Thu, 12 Dec 2013 10:51:56 -0800 (PST) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B652E1AE3A7 for ; Thu, 12 Dec 2013 10:51:56 -0800 (PST) Received: by mail-vc0-f174.google.com with SMTP id id10so594324vcb.33 for ; Thu, 12 Dec 2013 10:51:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=LC886EfhybIYLGMdPT6RkODYa4OITZ8eIEjiH6Rx7CY=; b=K3pZlCnBiXXOCAMYSE9Zm2PjK3E71MhcNLuc70mH7SH1PPNaeHmuVGnc7aVz+X2D90 GZ7D8RupojFwzFxyIh6myOhzviCFsdC39OSb9Wc2wlA9Nzob7+1OQXGKnf9ZdUWmZEVr M7tUzhx/cPOrTAHuR73xa5/lUtOmyyA296toObzQZSaFgGpnPdzihn1tn55UYZICVEuU 5g+6DBIcRXtC2XK6hseFiwBplIEn0OaenanTRJX+Ec82jo612o2H97uUqlK6mxDOno/q i1HnjCma9c3Cxk4W2H5+FSfnTBQcybrs6t09PqznuSAZBA9yC2pxH4bNdbPfaB+YGhnN XDqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LC886EfhybIYLGMdPT6RkODYa4OITZ8eIEjiH6Rx7CY=; b=M35LvVB7K9phyjqlLw5FQj8wpXpVLSsVa3YFDR2OVgfSqes+RL+tJebKGfREOFSaso ZVthL9QRZZGq5BBZCzJ0/7iNamZHLHpUoIpJTHamnoM0RetXOz2UjiSZ74ZzeJ3oKDt/ eJH1aoDlUECmbsjzpIU+agtGTwoyrUnz9KxtRFHZrARFfnqay4YnnXHkhomQQWTcjsPq dcBBsaGniYCm5CmbORksegRPCxXijQ+YbnsMvKlByq3vpUeEtvf3IWdnIs4Y0mgN700M WvRGCb48OxUuN3XAvMawMMoFcOwCwDO7VSqyIFCY/lSuqSM77q8d3hJUtoYmLqQEsFGZ J7eA== X-Gm-Message-State: ALoCoQkbvzQaSjBjpRTmYTZ3tiDJKFRgOyy1T/4mmRqwFodbax6zy1naMrglZfE2gf/yebRWQk74q/KAPbnPJ2dcDAKfxjYDPI1qc5EVAd/oN97Bmc5VyPCIhT9YWAfdcF4n1SEdyrdZtJ9ikUQr8tawFpNKDehO2xZcOMg3qxcIvhPPE9FjOKNYvFpA3lW5FA6BaVFes/2m MIME-Version: 1.0 X-Received: by 10.220.84.65 with SMTP id i1mr307084vcl.51.1386874310544; Thu, 12 Dec 2013 10:51:50 -0800 (PST) Received: by 10.52.183.65 with HTTP; Thu, 12 Dec 2013 10:51:50 -0800 (PST) In-Reply-To: <52A9E61C.8030300@bbn.com> References: <52A8B1D0.2080304@dcrocker.net> <52A8E0E9.5020409@dcrocker.net> <52A9E61C.8030300@bbn.com> Date: Thu, 12 Dec 2013 18:51:50 +0000 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: perpass , saag Subject: Re: [saag] [perpass] Draft charter for a Transparency Working Group X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 18:51:58 -0000 How's this? [1] A cryptographically verifiable log is an append-only log of hashes of more-or-less anything that can prove its own correctness cryptographically. For example, from RFC 6962: =93The append-only property of each log is technically achieved using Merkle Trees, which can be used to show that any particular version of the log is a superset of any particular previous version. Likewise, Merkle Trees avoid the need to blindly trust logs: if a log attempts to show different things to different people, this can be efficiently detected by comparing tree roots and consistency proofs. Similarly, other misbehaviours of any log (e.g., issuing signed timestamps for certificates they then don't log) can be efficiently detected and proved to the world at large.=94 See RFC 6962, http://www.links.org/files/CertificateTransparencyVersion2.1a= .pdf and http://www.links.org/files/RevocationTransparency.pdf for background. On 12 December 2013 16:36, Stephen Kent wrote: > Ben > > >> How about this footnote? >> >> "A cryptographically verifiable log is an append-only log of hashes of >> more-or-less anything that can prove its own correctness >> cryptographically. See RFC 6962, >> > I'd like something a bit more technical, since the phrase "prove its > own correctness" is pretty general. Hopefully there is text in 6962 > that you can use. > > Steve > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From trevp@trevp.net Thu Dec 12 16:06:24 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D541AE213 for ; Thu, 12 Dec 2013 16:06:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inO_kLpwW_19 for ; Thu, 12 Dec 2013 16:06:22 -0800 (PST) Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) by ietfa.amsl.com (Postfix) with ESMTP id 206AC1AE4C1 for ; Thu, 12 Dec 2013 16:06:18 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id x55so1191856wes.40 for ; Thu, 12 Dec 2013 16:06:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=gCiZEPnJ4AKEWLIP4X8+DUqu4ppnfxZMPlp3K+1Cz4o=; b=iNONC/efn2Xf0nOSqZEbkczNk02wACBcx42SaIHhr4RQm7X8+LQS58iqQBoy/8nxxv 8MPMsP9lT+ZJg1QFj0B+Av4qQNirBfHo8OHtWzcGQCUPCLvJ9jNEZ1u0vLtkpgCwlufV aoqCIFFv2wRfC/O8+kX0Ex47hAzVgk6+S3bP3uv+i9pufSyoar4F9jLDvCPTQ5bFu2f/ COUWQLlnoiv0Jema+ItffV+XgkVKHARKvB61jGdhQoeUhnLcSyXZLECWqMM3k5+taCuc MAju7nef+zMbAY7uPl2PYntmfRkSaY/nGPCOBVYlkD2BYuAed60yoPa1izxh/9fZ8xOE ab2Q== X-Gm-Message-State: ALoCoQmvDMeJZlfqTDIvlbB+hE6lAxSl6WPl+OAjyoNYoWxhRVrgPM2ecIaAu9ppQHhlhIwTC+Io MIME-Version: 1.0 X-Received: by 10.194.2.108 with SMTP id 12mr9019827wjt.64.1386893172520; Thu, 12 Dec 2013 16:06:12 -0800 (PST) Received: by 10.216.214.134 with HTTP; Thu, 12 Dec 2013 16:06:12 -0800 (PST) X-Originating-IP: [12.27.66.5] Date: Thu, 12 Dec 2013 16:06:12 -0800 Message-ID: From: Trevor Perrin To: cfrg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: "tls@ietf.org" , saag@ietf.org Subject: [saag] Question regarding CFRG process X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 00:06:24 -0000 Dear CFRG (cc: TLS, SAAG), I'd like to understand how the CFRG decides on guidance to provide IETF WGs. It appears the CFRG chairs provide this guidance based on their own opinions, disregarding any feedback from the mailing list or IETF meetings. In particular, the CFRG chairs have repeatedly endorsed the "Dragonfly" protocol to the TLS WG. However, I find no evidence of *ANY* positive feedback regarding Dragonfly in the CFRG mailing list or meeting minutes, except from the draft's author and CFRG co-chair Kevin Igoe. Compared to Kevin's enthusiasm, note: * Respected cryptographers and security engineers like Jonathan Katz, Adam Back, and Rene Struik expressed skepticism on the list * The single in-depth discussion at an IETF meeting was a string of complaints * Alternative proposals were made to CFRG (J-PAKE, AugPAKE). Could the chairs please clarify how they decided to endorse Dragonfly to TLS WG? Below is a summary of all CFRG discussion of Dragonfly. ===== Feb 2008 - Dan Harkins proposes early Dragonfly to CFRG http://www.ietf.org/mail-archive/web/cfrg/current/msg02205.html - Scott Fluhrer breaks it http://www.ietf.org/mail-archive/web/cfrg/current/msg02206.html ... Nov 2011 - David McGrew appoints Kevin Igoe as CFRG co-chair http://www.ietf.org/mail-archive/web/cfrg/current/msg03026.html Dec 2011 - Dan Harkins asks CFRG to look at TLS-PWD, based on Dragonfly http://www.ietf.org/mail-archive/web/cfrg/current/msg03044.html - Scott Fluhrer points out a problem http://www.ietf.org/mail-archive/web/cfrg/current/msg03045.html - Adam Back questions necessity of it, and lack of security analysis http://www.ietf.org/mail-archive/web/cfrg/current/msg03046.html Jan 2012 - Kevin Igoe's first email to CFRG: "I really like this idea & can find no problems." http://www.ietf.org/mail-archive/web/cfrg/current/msg03047.html - Jonathan Katz questions lack of security analysis, points out problems http://www.ietf.org/mail-archive/web/cfrg/current/msg03052.html http://www.ietf.org/mail-archive/web/cfrg/current/msg03053.html March 2012 - At IETF 83 CFRG meeting, concerns are raised about: - SPEKE patents - necessity of a new scheme - timing attacks - non-augmented properties http://www.ietf.org/proceedings/83/minutes/minutes-83-cfrg.txt May 2012 - Kevin Igoe points out a limitation due to "hunting-and-pecking" http://www.ietf.org/mail-archive/web/cfrg/current/msg03099.html - Zhou Sujing and Dan have an exchange that's hard to follow. http://www.ietf.org/mail-archive/web/cfrg/current/msg03115.html July 2012 - At IETF 84 TLS meeting (CFRG does not meet): - Kevin Igoe informs TLS WG, as the CFRG chair: "We approve of it, very clear and usable for general setting." http://www.ietf.org/proceedings/84/minutes/minutes-84-tls Oct 2012 - Kevin Igoe calls CFRG attention to Dragonfly draft-00 http://www.ietf.org/mail-archive/web/cfrg/current/msg03214.html - Jonathan Katz asks for a security proof - there is none http://www.ietf.org/mail-archive/web/cfrg/current/msg03215.html http://www.ietf.org/mail-archive/web/cfrg/current/msg03216.html Dec 2012 - Kevin Igoe calls CFRG attention to Dragonfly - raises timing attack issue, proposes 2 fixes, including rediscovery of Dan's original broken method (2008) http://www.ietf.org/mail-archive/web/cfrg/current/msg03258.html - Rene Struik points out the error in Kevin's proposal, and the inefficiency of Dragonfly relative to SPEKE http://www.ietf.org/mail-archive/web/cfrg/current/msg03259.html - Scott Fluhrer points out the error in Kevin's proposal, and proposes a flawed "mostly constant time" fix. Dan and Kevin embrace it. http://www.ietf.org/mail-archive/web/cfrg/current/msg03260.html http://www.ietf.org/mail-archive/web/cfrg/current/msg03262.html http://www.ietf.org/mail-archive/web/cfrg/current/msg03263.html http://www.ietf.org/mail-archive/web/cfrg/current/msg03264.html http://www.ietf.org/mail-archive/web/cfrg/current/msg03265.html Feb 2013 - draft-01 is uploaded with flawed sidechannel fix - also quietly fixes security issue reported by Dylan Clarke and Feng Hao http://www.ietf.org/mail-archive/web/cfrg/current/msg03309.html http://www.ietf.org/mail-archive/web/cfrg/current/msg03529.html Apr 2013 - Kevin Igoe mentions a last call for Dragonfly "The design looks mature, it addresses a real need, and no one has raised any issues." http://www.ietf.org/mail-archive/web/cfrg/current/msg03383.html May 2013 - Feng Hao asks CFRG to consider J-PAKE (an alternative) http://www.ietf.org/mail-archive/web/cfrg/current/msg03430.html July 2013 - Rene Struik points out spec bugs, raises timing attack issue again http://www.ietf.org/mail-archive/web/cfrg/current/msg03486.html http://www.ietf.org/mail-archive/web/cfrg/current/msg03489.html - IETF 87, CFRG meeting: - "The author is working on a new (and hopefully final) draft" http://www.ietf.org/proceedings/87/minutes/minutes-87-cfrg Aug 2013 - draft-02 is uploaded with modifications to "hunting-and-pecking" http://www.ietf.org/mail-archive/web/cfrg/current/msg03509.html Sep 2013 - SeongHan Shin asks CFRG to consider AugPAKE (an alternative) http://www.ietf.org/mail-archive/web/cfrg/current/msg03523.html Nov/Dec 2013 - Joe Saloway begins TLS-PWD last call, and informs TLS WG that: "The underlying cryptographic protocol for TLS-PWD has been reviewed by the IRTF CFRG group with satisfactory results." http://www.ietf.org/mail-archive/web/tls/current/msg10476.html - Uproar on TLS WG: - Many object to lack of formal security analysis: Douglas Stebila, Uri Blumenthal, Bodo Moeller, Rene Struik, Watson Ladd - Many point out better alternatives: SeongHan Shin, Robert Ransom, Watson Ladd, Trevor Perrin - Security flaws are pointed out by Bodo Moeller and CodesInChaos http://www.ietf.org/mail-archive/web/tls/current/msg10708.html http://www.ietf.org/mail-archive/web/tls/current/msg10768.html - Rene Struik and Bodo Moeller dispute that CFRG approved this http://www.ietf.org/mail-archive/web/tls/current/msg10769.html http://www.ietf.org/mail-archive/web/tls/current/msg10812.html - Eric Rescorla (TLS WG chair) states: "we did have a verbal report back from the chair of the CFRG that they considered it satisfactory" http://www.ietf.org/mail-archive/web/tls/current/msg10819.html Trevor From dharkins@lounge.org Thu Dec 12 17:59:04 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AEBF1AE166; Thu, 12 Dec 2013 17:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnAh_VoZRG-k; Thu, 12 Dec 2013 17:59:02 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 44C6F1ADFDF; Thu, 12 Dec 2013 17:59:02 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 3D74D10224008; Thu, 12 Dec 2013 17:58:56 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 12 Dec 2013 17:58:56 -0800 (PST) Message-ID: <18138981706be6221b2d05187da48394.squirrel@www.trepanning.net> In-Reply-To: References: Date: Thu, 12 Dec 2013 17:58:56 -0800 (PST) From: "Dan Harkins" To: "Trevor Perrin" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: cfrg@ietf.org, "tls@ietf.org" , saag@ietf.org Subject: Re: [saag] Question regarding CFRG process X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 01:59:04 -0000 On Thu, December 12, 2013 4:06 pm, Trevor Perrin wrote: ...an extremely misleading email. Using pejoratives like "bug", "flaw", and "attack" he attempts a smear of people, a protocol, and process. In reality there is no security bug or flaw or attack with dragonfly. There is obviously some personal animosity and taste involved but that is not technical. Read on. > Dear CFRG (cc: TLS, SAAG), > > I'd like to understand how the CFRG decides on guidance to provide IETF > WGs. > > It appears the CFRG chairs provide this guidance based on their own > opinions, disregarding any feedback from the mailing list or IETF > meetings. > > In particular, the CFRG chairs have repeatedly endorsed the > "Dragonfly" protocol to the TLS WG. However, I find no evidence of > *ANY* positive feedback regarding Dragonfly in the CFRG mailing list > or meeting minutes, except from the draft's author and CFRG co-chair > Kevin Igoe. > > Compared to Kevin's enthusiasm, note: > * Respected cryptographers and security engineers like Jonathan Katz, > Adam Back, and Rene Struik expressed skepticism on the list Let's look at those, read on. > * The single in-depth discussion at an IETF meeting was a string of > complaints That's what comments are. And they get addressed. > * Alternative proposals were made to CFRG (J-PAKE, AugPAKE). > > Could the chairs please clarify how they decided to endorse Dragonfly to > TLS WG? > > > Below is a summary of all CFRG discussion of Dragonfly. > > ===== > > Feb 2008 > - Dan Harkins proposes early Dragonfly to CFRG > http://www.ietf.org/mail-archive/web/cfrg/current/msg02205.html > > - Scott Fluhrer breaks it > http://www.ietf.org/mail-archive/web/cfrg/current/msg02206.html An event mentioned in the acknowledgments. Thank you Scott. His review and comments have been most helpful. > > Nov 2011 > - David McGrew appoints Kevin Igoe as CFRG co-chair > http://www.ietf.org/mail-archive/web/cfrg/current/msg03026.html Completely and utterly irrelevant. > Dec 2011 > - Dan Harkins asks CFRG to look at TLS-PWD, based on Dragonfly > http://www.ietf.org/mail-archive/web/cfrg/current/msg03044.html > > - Scott Fluhrer points out a problem > http://www.ietf.org/mail-archive/web/cfrg/current/msg03045.html A simple "sanity" check that the an ECC point is not "infinity". Again, a good comment. > - Adam Back questions necessity of it, and lack of security > analysis > http://www.ietf.org/mail-archive/web/cfrg/current/msg03046.html He does no such thing. He notices that SRP is not mentioned in the draft. Quite true. And he asks what key exchange is being implemented because "its harder than it looks". Which is also quite true. > Jan 2012 > - Kevin Igoe's first email to CFRG: > "I really like this idea & can find no problems." > http://www.ietf.org/mail-archive/web/cfrg/current/msg03047.html > > - Jonathan Katz questions lack of security analysis, points out > problems > http://www.ietf.org/mail-archive/web/cfrg/current/msg03052.html > http://www.ietf.org/mail-archive/web/cfrg/current/msg03053.html Yes, helpful comments on the draft. The susceptibility to attack under the random oracle model is, in fact, mentioned in my slide deck when I presented to the CFRG in Paris at IETF 83. It is a highly contrived scenario and completely unlikely a real world protocol but it does raise the question of making a formal proof in that model. You should link to my slide deck in your next broadside. > March 2012 > - At IETF 83 CFRG meeting, concerns are raised about: > - SPEKE patents > - necessity of a new scheme > - timing attacks > - non-augmented properties > http://www.ietf.org/proceedings/83/minutes/minutes-83-cfrg.txt Wow, you make it sound as if you were there. But you weren't. And your summary is not an accurate description of the meeting. The sole mention in the minutes of SPEKE is from me. And the "concerns" are a recitation of comments received. That's how it works. You get comments and you resolve them. > May 2012 > - Kevin Igoe points out a limitation due to "hunting-and-pecking" > http://www.ietf.org/mail-archive/web/cfrg/current/msg03099.html He does no such thing. He just said that if the prime defining the curve p = 3 mod 4 that it's easier to compute the square root. > - Zhou Sujing and Dan have an exchange that's hard to follow. > http://www.ietf.org/mail-archive/web/cfrg/current/msg03115.html > > July 2012 > - At IETF 84 TLS meeting (CFRG does not meet): > - Kevin Igoe informs TLS WG, as the CFRG chair: > "We approve of it, very clear and usable for general setting." > http://www.ietf.org/proceedings/84/minutes/minutes-84-tls Also note the comment: "Tie Dragonfly into EST would be very useful" Yes, it would. > Oct 2012 > - Kevin Igoe calls CFRG attention to Dragonfly draft-00 > http://www.ietf.org/mail-archive/web/cfrg/current/msg03214.html > > - Jonathan Katz asks for a security proof - there is none > http://www.ietf.org/mail-archive/web/cfrg/current/msg03215.html > http://www.ietf.org/mail-archive/web/cfrg/current/msg03216.html Correct. There is no formal proof of security. See my slides from IETF 83. > Dec 2012 > - Kevin Igoe calls CFRG attention to Dragonfly > - raises timing attack issue, proposes 2 fixes, including > rediscovery of Dan's original broken method (2008) > http://www.ietf.org/mail-archive/web/cfrg/current/msg03258.html This is further discussion on addressing a side channel attack. Your attempt to spin this as "broken" is somewhat desperate. > - Rene Struik points out the error in Kevin's proposal, and > the inefficiency of Dragonfly relative to SPEKE > http://www.ietf.org/mail-archive/web/cfrg/current/msg03259.html He does no such thing. His "Suppose A and B…" is a recitation of a version of SPEKE that does not hash the password into a group in the domain parameter set. It's neither here nor there with respect to dragonfly. He further goes on to suggest on a check for "point at infinity". Which is already part of dragonfly. There is no "error" noted and no "inefficiency" mentioned either. > - Scott Fluhrer points out the error in Kevin's proposal, and > proposes a flawed "mostly constant time" fix. Dan and Kevin > embrace it. > http://www.ietf.org/mail-archive/web/cfrg/current/msg03260.html > http://www.ietf.org/mail-archive/web/cfrg/current/msg03262.html > http://www.ietf.org/mail-archive/web/cfrg/current/msg03263.html > http://www.ietf.org/mail-archive/web/cfrg/current/msg03264.html > http://www.ietf.org/mail-archive/web/cfrg/current/msg03265.html As noted in the email thread, the described fix was added to the draft at the time. Your opinion on it being "flawed" has already been noted. > Feb 2013 > - draft-01 is uploaded with flawed sidechannel fix > - also quietly fixes security issue reported by Dylan Clarke > and Feng Hao > http://www.ietf.org/mail-archive/web/cfrg/current/msg03309.html > http://www.ietf.org/mail-archive/web/cfrg/current/msg03529.html This is a small sub-group attack possible if one does not check validity of received elements. All incarnations of dragonfly-- TLS-PWD, EAP-PWD and 802.11 already did this. It is entirely my fault that I left that crucial step out of the -00 version of the CFRG draft but it is hardly a flaw. > Apr 2013 > - Kevin Igoe mentions a last call for Dragonfly > "The design looks mature, it addresses a real need, and no one > has raised any issues." > http://www.ietf.org/mail-archive/web/cfrg/current/msg03383.html That's correct. You are included in that "no one". > May 2013 > - Feng Hao asks CFRG to consider J-PAKE (an alternative) > http://www.ietf.org/mail-archive/web/cfrg/current/msg03430.html Completely irrelevant. > July 2013 > - Rene Struik points out spec bugs, raises timing attack issue > again > http://www.ietf.org/mail-archive/web/cfrg/current/msg03486.html > http://www.ietf.org/mail-archive/web/cfrg/current/msg03489.html "Spec bugs", in other words typos. Yes, he brings up an issue that had previously been addressed. > - IETF 87, CFRG meeting: > - "The author is working on a new (and hopefully final) draft" > http://www.ietf.org/proceedings/87/minutes/minutes-87-cfrg Sadly, it's not. I have to address the "Spec bugs" and address Rene's other comments, none of which demonstrate security flaws. > Aug 2013 > - draft-02 is uploaded with modifications to "hunting-and-pecking" > http://www.ietf.org/mail-archive/web/cfrg/current/msg03509.html Don't forget comments dealing with internationalization! The change is from a comment received from, if I recall, Russ Housley to use the technique from FIPS 186-3 to hide the bias added by the modular reduction. Again, a very nice comment, happily accepted. > Sep 2013 > - SeongHan Shin asks CFRG to consider AugPAKE (an alternative) > http://www.ietf.org/mail-archive/web/cfrg/current/msg03523.html Completely irrelevant. (Again, not sure why you're have become such a cheerleader for AugPAKE). > Nov/Dec 2013 > - Joe Saloway begins TLS-PWD last call, and informs TLS WG that: > "The underlying cryptographic protocol for TLS-PWD has been > reviewed by the IRTF CFRG group with satisfactory results." > http://www.ietf.org/mail-archive/web/tls/current/msg10476.html > > - Uproar on TLS WG: > > - Many object to lack of formal security analysis: > Douglas Stebila, Uri Blumenthal, Bodo Moeller, Rene Struik, > Watson Ladd Missing, of course, the caveat "-- except I believe that whenever possible the IETF should aim to standardize cryptographic protocols that are unencumbered by license fees and patents. If the choice arises between a protocol that carries both (provable security and Intellectual Property) and a protocol that has neither - I'd strongly prefer the latter." > - Many point out better alternatives: > SeongHan Shin, Robert Ransom, Watson Ladd, Trevor Perrin And you're all free to write up Internet Drafts on them too! In fact, SeongHan Shin has been following me around EMU, IPsec, CFRG and now TLS doing just that. After I write a dragonfly I-D he writes an AugPAKE I-D. Nothing is stopping you from doing it too. > - Security flaws are pointed out by Bodo Moeller and > CodesInChaos > http://www.ietf.org/mail-archive/web/tls/current/msg10708.html > http://www.ietf.org/mail-archive/web/tls/current/msg10768.html Bodo's comment has been addressed. I dispute the use of the term "security flaw" to describe it but that is consistent with the rest of your email. CodesInChaos suggested using PBKDF2 to hash the password. This really provides no additional benefit,, as I noted in a subsequent email (see coWPAtty and family attacks against a protocol that uses PBKDF2). > - Rene Struik and Bodo Moeller dispute that CFRG approved this > http://www.ietf.org/mail-archive/web/tls/current/msg10769.html > > http://www.ietf.org/mail-archive/web/tls/current/msg10812.html Actually, Rene notes that CFRG has not issued a LC. He does raise some comments, many of which are already addressed in the draft and he points out the "Spec bug" you allude to earlier. He suggests relaxation of one of the restrictions on parameter generation that I decline to accept. And he finds some additional typos and an erroneous description of point addition. Helpful comments. > - Eric Rescorla (TLS WG chair) states: > "we did have a verbal report back from the chair of the CFRG > that they considered it satisfactory" > http://www.ietf.org/mail-archive/web/tls/current/msg10819.html Indeed. So what you've brought up is that there has been discussion of dragonfly on the list and it has, in fact, been reviewed. Quite a few comments have been made and resolved, security critical issues have been raised and properly addressed. There are no flaws in the key exchange. It has some aspects to it that some may feel is a benefit and some may feel is a detriment. Personal taste is not something that can be universally accommodated. Nothing you have raised here is reason to stop advancement of this draft. Dan. From dharkins@lounge.org Thu Dec 12 23:15:25 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6021AE17C; Thu, 12 Dec 2013 23:15:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBm3wehTu4t4; Thu, 12 Dec 2013 23:15:18 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 380DA1AE15F; Thu, 12 Dec 2013 23:15:18 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id F258A10224008; Thu, 12 Dec 2013 23:15:11 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 12 Dec 2013 23:15:12 -0800 (PST) Message-ID: In-Reply-To: References: <18138981706be6221b2d05187da48394.squirrel@www.trepanning.net> Date: Thu, 12 Dec 2013 23:15:12 -0800 (PST) From: "Dan Harkins" To: "Watson Ladd" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: cfrg@ietf.org, "tls@ietf.org" , saag@ietf.org Subject: Re: [saag] [TLS] Question regarding CFRG process X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 07:15:25 -0000 On Thu, December 12, 2013 7:36 pm, Watson Ladd wrote: > On Thu, Dec 12, 2013 at 5:58 PM, Dan Harkins wrote: >> >> On Thu, December 12, 2013 4:06 pm, Trevor Perrin wrote: >> >> ...an extremely misleading email. >> >> Using pejoratives like "bug", "flaw", and "attack" he attempts a >> smear of people, a protocol, and process. In reality there is no >> security bug or flaw or attack with dragonfly. >> >> There is obviously some personal animosity and taste involved >> but that is not technical. Read on. > This is not quite true. Dragonfly's vaunted resistance to offline > attack doesn't hold > in the standard model or the ROM because there are some hash functions > (like hashing+exponentiation) > which break it. This is a very serious issue: it means we don't know > what it means for Dragonfly to be secure. "vaunted"? The fact that you have to exaggerate reveals much. If "it looks good to me" is not enough for you then certainly "it doesn't have a security proof" is not evidence of flaws and susceptibility to attack. So instead of "that is not quite true", it actually is. Quite. >>> Dear CFRG (cc: TLS, SAAG), >>> >>> I'd like to understand how the CFRG decides on guidance to provide IETF >>> WGs. >>> >>> It appears the CFRG chairs provide this guidance based on their own >>> opinions, disregarding any feedback from the mailing list or IETF >>> meetings. >>> >>> In particular, the CFRG chairs have repeatedly endorsed the >>> "Dragonfly" protocol to the TLS WG. However, I find no evidence of >>> *ANY* positive feedback regarding Dragonfly in the CFRG mailing list >>> or meeting minutes, except from the draft's author and CFRG co-chair >>> Kevin Igoe. >>> >>> Compared to Kevin's enthusiasm, note: >>> * Respected cryptographers and security engineers like Jonathan Katz, >>> Adam Back, and Rene Struik expressed skepticism on the list >> >> Let's look at those, read on. >> >>> * The single in-depth discussion at an IETF meeting was a string of >>> complaints >> >> That's what comments are. And they get addressed. >> >>> * Alternative proposals were made to CFRG (J-PAKE, AugPAKE). >>> >>> Could the chairs please clarify how they decided to endorse Dragonfly >>> to >>> TLS WG? >>> >>> >>> Below is a summary of all CFRG discussion of Dragonfly. >>> >>> ===== >>> >>> Feb 2008 >>> - Dan Harkins proposes early Dragonfly to CFRG >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg02205.html >>> >>> - Scott Fluhrer breaks it >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg02206.html >> >> An event mentioned in the acknowledgments. Thank you Scott. >> His review and comments have been most helpful. >> >>> >>> Nov 2011 >>> - David McGrew appoints Kevin Igoe as CFRG co-chair >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03026.html >> >> Completely and utterly irrelevant. >> >>> Dec 2011 >>> - Dan Harkins asks CFRG to look at TLS-PWD, based on Dragonfly >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03044.html >>> >>> - Scott Fluhrer points out a problem >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03045.html >> >> A simple "sanity" check that the an ECC point is not "infinity". >> Again, >> a good comment. >> >>> - Adam Back questions necessity of it, and lack of security >>> analysis >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03046.html >> >> He does no such thing. He notices that SRP is not mentioned in the >> draft. Quite true. And he asks what key exchange is being implemented >> because "its harder than it looks". Which is also quite true. >> >>> Jan 2012 >>> - Kevin Igoe's first email to CFRG: >>> "I really like this idea & can find no problems." >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03047.html >>> >>> - Jonathan Katz questions lack of security analysis, points out >>> problems >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03052.html >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03053.html >> >> Yes, helpful comments on the draft. The susceptibility to attack under >> the random oracle model is, in fact, mentioned in my slide deck when >> I presented to the CFRG in Paris at IETF 83. It is a highly contrived >> scenario and completely unlikely a real world protocol but it does raise >> the question of making a formal proof in that model. > On the contrary: "it looks secure to me" is not an acceptable foundation > for > cryptographic protocols. I do not want any protocol I approve to be a > CRYPTO > keynote in the future. Cryptographic protocols that you approve? Since when are you the gatekeeper? What cryptographic protocols have you approved of? Here's an idea: find an attack on dragonfly and present it to CRYPTO in the future. Something to pad your CV. >> You should link to my slide deck in your next broadside. >> >>> March 2012 >>> - At IETF 83 CFRG meeting, concerns are raised about: >>> - SPEKE patents >>> - necessity of a new scheme >>> - timing attacks >>> - non-augmented properties >>> http://www.ietf.org/proceedings/83/minutes/minutes-83-cfrg.txt >> >> Wow, you make it sound as if you were there. But you weren't. And >> your summary is not an accurate description of the meeting. The >> sole mention in the minutes of SPEKE is from me. And the "concerns" >> are a recitation of comments received. That's how it works. You get >> comments and you resolve them. >> >>> May 2012 >>> - Kevin Igoe points out a limitation due to "hunting-and-pecking" >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03099.html >> >> He does no such thing. He just said that if the prime defining the >> curve p = 3 mod 4 that it's easier to compute the square root. >> >>> - Zhou Sujing and Dan have an exchange that's hard to follow. >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03115.html >>> >>> July 2012 >>> - At IETF 84 TLS meeting (CFRG does not meet): >>> - Kevin Igoe informs TLS WG, as the CFRG chair: >>> "We approve of it, very clear and usable for general setting." >>> http://www.ietf.org/proceedings/84/minutes/minutes-84-tls >> >> Also note the comment: "Tie Dragonfly into EST would be very useful" >> Yes, it would. >> >>> Oct 2012 >>> - Kevin Igoe calls CFRG attention to Dragonfly draft-00 >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03214.html >>> >>> - Jonathan Katz asks for a security proof - there is none >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03215.html >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03216.html >> >> Correct. There is no formal proof of security. See my slides from >> IETF 83. >> >>> Dec 2012 >>> - Kevin Igoe calls CFRG attention to Dragonfly >>> - raises timing attack issue, proposes 2 fixes, including >>> rediscovery of Dan's original broken method (2008) >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03258.html >> >> This is further discussion on addressing a side channel attack. >> Your attempt to spin this as "broken" is somewhat desperate. > Modern cryptographic practice demands constant time, jump-free, > no variable memory access cryptography. >> >>> - Rene Struik points out the error in Kevin's proposal, and >>> the inefficiency of Dragonfly relative to SPEKE >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03259.html >> >> He does no such thing. His "Suppose A and B…" is a recitation of >> a version of SPEKE that does not hash the password into a group in >> the domain parameter set. It's neither here nor there with respect >> to dragonfly. He further goes on to suggest on a check for "point at >> infinity". Which is already part of dragonfly. >> >> There is no "error" noted and no "inefficiency" mentioned either. >> >>> - Scott Fluhrer points out the error in Kevin's proposal, and >>> proposes a flawed "mostly constant time" fix. Dan and Kevin >>> embrace it. >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03260.html >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03262.html >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03263.html >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03264.html >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03265.html >> >> As noted in the email thread, the described fix was added to the >> draft at the time. Your opinion on it being "flawed" has already been >> noted. >> >>> Feb 2013 >>> - draft-01 is uploaded with flawed sidechannel fix >>> - also quietly fixes security issue reported by Dylan Clarke >>> and Feng Hao >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03309.html >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03529.html >> >> This is a small sub-group attack possible if one does not check >> validity of received elements. All incarnations of dragonfly-- TLS-PWD, >> EAP-PWD and 802.11 already did this. It is entirely my fault that I left >> that >> crucial step out of the -00 version of the CFRG draft but it is hardly >> a flaw. >> >>> Apr 2013 >>> - Kevin Igoe mentions a last call for Dragonfly >>> "The design looks mature, it addresses a real need, and no one >>> has raised any issues." >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03383.html >> >> That's correct. You are included in that "no one". >> >>> May 2013 >>> - Feng Hao asks CFRG to consider J-PAKE (an alternative) >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03430.html >> >> Completely irrelevant. >> > I don't think so. Your repeated insistence to the contrary, there are > people who > will use RC4 on TLS connections, etc, etc. Our endorsing a protocol > when superior > alternatives exist is a bad thing, because insecure options have a > nasty habit of being > turned on. You've argued that because you and your employer don't see > an issue, we should > be happy to endorse this. RC4? What the hell does that have to do with anything? And when did I insist that people will not use RC4? And when did I mention my employer? Never and never. You are obviously very confused. >>> July 2013 >>> - Rene Struik points out spec bugs, raises timing attack issue >>> again >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03486.html >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03489.html >> >> "Spec bugs", in other words typos. Yes, he brings up an issue that >> had previously been addressed. >> >>> - IETF 87, CFRG meeting: >>> - "The author is working on a new (and hopefully final) draft" >>> http://www.ietf.org/proceedings/87/minutes/minutes-87-cfrg >> >> Sadly, it's not. I have to address the "Spec bugs" and address >> Rene's other comments, none of which demonstrate security flaws. >> >>> Aug 2013 >>> - draft-02 is uploaded with modifications to "hunting-and-pecking" >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03509.html >> >> Don't forget comments dealing with internationalization! >> >> The change is from a comment received from, if I recall, Russ Housley >> to use the technique from FIPS 186-3 to hide the bias added by the >> modular reduction. Again, a very nice comment, happily accepted. > Knuth discusses this in detail in Volume 2. Bleichenbacher got a lot > of mileage from > this. So? Aside from giving you an opportunity to name drop, what does that have to do with anything? The comment was made, it was not asserted as being some original insight, and it was accepted. >>> Sep 2013 >>> - SeongHan Shin asks CFRG to consider AugPAKE (an alternative) >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03523.html >> >> Completely irrelevant. (Again, not sure why you're have become such >> a cheerleader for AugPAKE). >> >>> Nov/Dec 2013 >>> - Joe Saloway begins TLS-PWD last call, and informs TLS WG that: >>> "The underlying cryptographic protocol for TLS-PWD has been >>> reviewed by the IRTF CFRG group with satisfactory results." >>> http://www.ietf.org/mail-archive/web/tls/current/msg10476.html >>> >>> - Uproar on TLS WG: >>> >>> - Many object to lack of formal security analysis: >>> Douglas Stebila, Uri Blumenthal, Bodo Moeller, Rene Struik, >>> Watson Ladd >> >> Missing, of course, the caveat "-- except I believe that whenever >> possible the IETF should aim to standardize cryptographic protocols >> that are unencumbered by license fees and patents. If the choice >> arises between a protocol that carries both (provable security and >> Intellectual Property) and a protocol that has neither - I'd strongly >> prefer the latter." >> >>> - Many point out better alternatives: >>> SeongHan Shin, Robert Ransom, Watson Ladd, Trevor Perrin >> >> And you're all free to write up Internet Drafts on them too! > Why do you want Dragonfly as opposed to J-PAKE? If you think it is > going to slow, call up Feng Hao and offer to help. That would satisfy the > need you identify in your usecase in the TLS WG. > Or is this not about solving the problem of password authenticated key > exchange, > but putting your protocol into things? Why don't you do a draft on J-PAKE? I asked you before to please write an Internet Draft. Please. I would really appreciate the opportunity to review such a document. Why don't you offer to help Feng Hao? What this has to do with is a desire to have a TLS cipher suite to satisfy legitimate use cases yesterday. You come along 2+ years late and then say that it should all be abandoned and something else pursued. Because _you_ don't approve. Your suggestions might've been helpful 2+ years ago, now they're just a delaying tactic. >> In fact, SeongHan Shin has been following me around EMU, IPsec, >> CFRG and now TLS doing just that. After I write a dragonfly I-D he >> writes an AugPAKE I-D. Nothing is stopping you from doing it too. >> >>> - Security flaws are pointed out by Bodo Moeller and >>> CodesInChaos >>> http://www.ietf.org/mail-archive/web/tls/current/msg10708.html >>> http://www.ietf.org/mail-archive/web/tls/current/msg10768.html >> >> Bodo's comment has been addressed. I dispute the use of the term >> "security flaw" to describe it but that is consistent with the rest of >> your email. >> >> CodesInChaos suggested using PBKDF2 to hash the password. This >> really provides no additional benefit,, as I noted in a subsequent >> email (see coWPAtty and family attacks against a protocol that uses >> PBKDF2). >> >>> - Rene Struik and Bodo Moeller dispute that CFRG approved this >>> http://www.ietf.org/mail-archive/web/tls/current/msg10769.html >>> >>> http://www.ietf.org/mail-archive/web/tls/current/msg10812.html >> >> Actually, Rene notes that CFRG has not issued a LC. He does raise >> some comments, many of which are already addressed in the draft >> and he points out the "Spec bug" you allude to earlier. He suggests >> relaxation of one of the restrictions on parameter generation that I >> decline to accept. And he finds some additional typos and an >> erroneous description of point addition. Helpful comments. >> >>> - Eric Rescorla (TLS WG chair) states: >>> "we did have a verbal report back from the chair of the CFRG >>> that they considered it satisfactory" >>> http://www.ietf.org/mail-archive/web/tls/current/msg10819.html >> >> Indeed. >> >> So what you've brought up is that there has been discussion of >> dragonfly on the list and it has, in fact, been reviewed. Quite a few >> comments have been made and resolved, security critical issues have >> been raised and properly addressed. > Sorry, but review is not enough. Approval is. What standard is the > chair applying here? The existing standard that is in place for TLS and the IETF. >> There are no flaws in the key exchange. It has some aspects to it >> that some may feel is a benefit and some may feel is a detriment. >> Personal taste is not something that can be universally accommodated. >> >> Nothing you have raised here is reason to stop advancement of >> this draft. > I disagree. This draft is reminiscent of the worst of 90's > cryptography: ad-hoc assumptions, > no formal statement of security, gratuitously not a circuit, and not > subject by review by anyone > who is a cryptographer. It may be that this draft has exposed a fault > line between those who think > the current process is acceptable and those who do not. It lacks a formal security proof. That is all. There is no other problem with it. The side channel attack issue was already addressed after a long thread a long time ago. One might consider revisiting it if the people harping about it really wanted a change, instead of just using it as a box on which to stand so as to shout more loudly. Lacking any valid issue with dragonfly I suggest you go back to obsessing over RC4. Dan. From dharkins@lounge.org Fri Dec 13 00:36:06 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D54E1AE6C3; Fri, 13 Dec 2013 00:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDtH6cvOdz-d; Fri, 13 Dec 2013 00:36:02 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD001AE6C5; Fri, 13 Dec 2013 00:36:02 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id D013610224008; Fri, 13 Dec 2013 00:35:55 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 13 Dec 2013 00:35:56 -0800 (PST) Message-ID: <8cf8a51b9dcfd0c40b80ae2aad2cff7c.squirrel@www.trepanning.net> In-Reply-To: References: <18138981706be6221b2d05187da48394.squirrel@www.trepanning.net> Date: Fri, 13 Dec 2013 00:35:56 -0800 (PST) From: "Dan Harkins" To: "Watson Ladd" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: cfrg@ietf.org, "tls@ietf.org" , saag@ietf.org Subject: Re: [saag] [TLS] Question regarding CFRG process X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 08:36:06 -0000 On Fri, December 13, 2013 12:00 am, Watson Ladd wrote: > On Thu, Dec 12, 2013 at 11:15 PM, Dan Harkins wrote: >> >> On Thu, December 12, 2013 7:36 pm, Watson Ladd wrote: >>> On Thu, Dec 12, 2013 at 5:58 PM, Dan Harkins >>> wrote: >>>> >>>> On Thu, December 12, 2013 4:06 pm, Trevor Perrin wrote: >>>> >>>> ...an extremely misleading email. >>>> >>>> Using pejoratives like "bug", "flaw", and "attack" he attempts a >>>> smear of people, a protocol, and process. In reality there is no >>>> security bug or flaw or attack with dragonfly. >>>> >>>> There is obviously some personal animosity and taste involved >>>> but that is not technical. Read on. >>> This is not quite true. Dragonfly's vaunted resistance to offline >>> attack doesn't hold >>> in the standard model or the ROM because there are some hash functions >>> (like hashing+exponentiation) >>> which break it. This is a very serious issue: it means we don't know >>> what it means for Dragonfly to be secure. >> >> "vaunted"? The fact that you have to exaggerate reveals much. >> >> If "it looks good to me" is not enough for you then certainly >> "it doesn't have a security proof" is not evidence of flaws and >> susceptibility to attack. > > The consequences of adopting a protocol we think is secure that > isn't: dead people. > > The consequences of ruling out a protocol that is secure because we > think it isn't: In this case nothing as the usecase is already handled. > > Are you seriously arguing that Dragonfly's security is independent of ZF? You obviously read too much fiction and have too little practical experience. Dragonfly is not a threat to human life. Get a grip. >> >> So instead of "that is not quite true", it actually is. Quite. >> [snip] >>>> Yes, helpful comments on the draft. The susceptibility to attack >>>> under >>>> the random oracle model is, in fact, mentioned in my slide deck when >>>> I presented to the CFRG in Paris at IETF 83. It is a highly contrived >>>> scenario and completely unlikely a real world protocol but it does >>>> raise >>>> the question of making a formal proof in that model. >>> On the contrary: "it looks secure to me" is not an acceptable >>> foundation >>> for >>> cryptographic protocols. I do not want any protocol I approve to be a >>> CRYPTO >>> keynote in the future. >> >> Cryptographic protocols that you approve? Since when are you the >> gatekeeper? What cryptographic protocols have you approved of? > > I'm not the gatekeeper, merely someone with the training required to do > cryptography. By all accounts such a person hasn't been on the TLS WG > in a long time. Yet you're not; you're just bloviating. >> >> Here's an idea: find an attack on dragonfly and present it to CRYPTO >> in the future. Something to pad your CV. >> [snip] >>>>> May 2013 >>>>> - Feng Hao asks CFRG to consider J-PAKE (an alternative) >>>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03430.html >>>> >>>> Completely irrelevant. >>>> >>> I don't think so. Your repeated insistence to the contrary, there are >>> people who >>> will use RC4 on TLS connections, etc, etc. Our endorsing a protocol >>> when superior >>> alternatives exist is a bad thing, because insecure options have a >>> nasty habit of being >>> turned on. You've argued that because you and your employer don't see >>> an issue, we should >>> be happy to endorse this. >> >> RC4? What the hell does that have to do with anything? >> >> And when did I insist that people will not use RC4? And when did I >> mention my employer? Never and never. >> >> You are obviously very confused. > > Your argument seems to be that even if dragonfly is later discovered > insecure, > or we don't want to use it, it will be fine because people will configure > their systems appropriately. Our experience shows that is not the case. > > I have a much more cynical view: systems are only fixed when broken, and > not even then. We are the sole line between a bunch of idiots and the NSA. Uhm, no. My _statement_ was that I never said anything about RC4 or how often, or not, if ever, RC4 is used. Nor did I mention my employer. You spun this entire thing out of thin air. Or, possibly, you have confused me with someone else. >> [snip] >> Why don't you do a draft on J-PAKE? I asked you before to please write >> an Internet Draft. Please. I would really appreciate the opportunity to >> review such a document. Why don't you offer to help Feng Hao? > > He already wrote a such a draft. I'm not the right person to bri^H^H^H > lobby > the WG chairs to get this through, because I don't have thousands of > dollars of > other people's money to spend on junkets in Honolulu. I also don't have a > need > for a PAKE: TOFU with certificates works well enough for my usecases. But > for > embedded devices I see the utility. Your ignorance of IETF process has been well demonstrated. >> >> What this has to do with is a desire to have a TLS cipher suite to >> satisfy legitimate use cases yesterday. You come along 2+ years late >> and then say that it should all be abandoned and something else pursued. >> Because _you_ don't approve. Your suggestions might've been helpful >> 2+ years ago, now they're just a delaying tactic. > > SRP satisfies this use case and was available then. J-PAKE was 3 years > old then. The Socialist Millionaire's Protocol was 5 years old. No, it doesn't. TLS-SRP does not support ECC and it is an augmented PAKE scheme. And your suggestion now to use something else is, as I have said, useless and 2+ years late. >> [snip] >>>>> - Eric Rescorla (TLS WG chair) states: >>>>> "we did have a verbal report back from the chair of the CFRG >>>>> that they considered it satisfactory" >>>>> http://www.ietf.org/mail-archive/web/tls/current/msg10819.html >>>> >>>> Indeed. >>>> >>>> So what you've brought up is that there has been discussion of >>>> dragonfly on the list and it has, in fact, been reviewed. Quite a few >>>> comments have been made and resolved, security critical issues have >>>> been raised and properly addressed. >>> Sorry, but review is not enough. Approval is. What standard is the >>> chair applying here? >> >> The existing standard that is in place for TLS and the IETF. > > I don't think you noticed that this standard produced IPSEC with > encrypt only, IKE1, > TLS bugs galore, and many other issues. As I mention below, this seems to > be the > real difference: you are the first person who ran into the tougher > standards many of > us think are warranted. I don't know what "IPSEC (sic) with encrypt only" is. But I am aware of IKEv1. It's provably secure in its signature-mode of authentication. I'm also familiar with well-respected cryptographers who participated in the IPsec WG in the 90s. You are nobody compared to them and your ignorant reference confirms that. >>>> There are no flaws in the key exchange. It has some aspects to it >>>> that some may feel is a benefit and some may feel is a detriment. >>>> Personal taste is not something that can be universally accommodated. >>>> >>>> Nothing you have raised here is reason to stop advancement of >>>> this draft. >>> I disagree. This draft is reminiscent of the worst of 90's >>> cryptography: ad-hoc assumptions, >>> no formal statement of security, gratuitously not a circuit, and not >>> subject by review by anyone >>> who is a cryptographer. It may be that this draft has exposed a fault >>> line between those who think >>> the current process is acceptable and those who do not. >> >> It lacks a formal security proof. That is all. There is no other >> problem >> with it. The side channel attack issue was already addressed after a >> long thread a long time ago. One might consider revisiting it if the >> people harping about it really wanted a change, instead of just using >> it as a box on which to stand so as to shout more loudly. > > Could you please define what you mean by secure? I've been trying for > the past week to come up with a formal definition for the security of > dragonfly, and > not one of them has been any good. Try harder. >> Lacking any valid issue with dragonfly I suggest you go back to >> obsessing over RC4. > > If RC4 was the only cryptography mistake the TLS WG made, life would be > nice. And if you made useful contributions to TLS it would be nice. Dan. From trevp@trevp.net Fri Dec 13 02:29:33 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B9B1AE1E6 for ; Fri, 13 Dec 2013 02:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJ-ejWL8y_Bq for ; Fri, 13 Dec 2013 02:29:28 -0800 (PST) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id DDFF11A8034 for ; Fri, 13 Dec 2013 02:29:27 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id bz8so852318wib.10 for ; Fri, 13 Dec 2013 02:29:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xJtJNRyUzrpp+pYiY85WWJVK0advwfW3WSaKnEQU9hc=; b=ic5P0JTCv033DEKE3IIc+Jz+BjivJgnJzO/vvGf0Z8O/aQ/IF25ZI79ivxZDnTMtew CmE1IGe5bgKC8LCs1vnv407FyBSiA9zv1Wgquu9Ry06Sz+IRxljGhd8K/d7hSWMYlllV MsPymTcQqgf8ldC/nfqcmM3owS4GlqAkjK0bKBdGtM3qjNYn5MLoeTh8csp5puJbmdru gDtGfdTStGWhHJ4iQwkGuG8ER+yokUd/NrqFYWkDvwGxfAb8BmldnfXXmAAADeVShDxw JCFTMh8/fThUmijuuI5YD6m9GKTbxu6rubUuihGUo/5EEgJj8+aIaPKFcNQPT4MCjU0p C2Cw== X-Gm-Message-State: ALoCoQkN2H1s61elCWob0iF52cHkK3eo7H5qjRqD/BcNVNIdogCedcxXQ1VAEJoqdpRt1i/XDZnB MIME-Version: 1.0 X-Received: by 10.180.94.164 with SMTP id dd4mr2313846wib.20.1386930561131; Fri, 13 Dec 2013 02:29:21 -0800 (PST) Received: by 10.216.214.134 with HTTP; Fri, 13 Dec 2013 02:29:21 -0800 (PST) X-Originating-IP: [199.83.223.81] In-Reply-To: <18138981706be6221b2d05187da48394.squirrel@www.trepanning.net> References: <18138981706be6221b2d05187da48394.squirrel@www.trepanning.net> Date: Fri, 13 Dec 2013 02:29:21 -0800 Message-ID: From: Trevor Perrin To: Dan Harkins Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: cfrg@ietf.org, "tls@ietf.org" , saag@ietf.org Subject: Re: [saag] Question regarding CFRG process X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 10:29:33 -0000 Dan, all, My message was directed at the CFRG chairs. I believe CFRG consensus has been misrepresented regarding Dragonfly. I'd appreciate if the chairs would respond to this. Regarding Dan's objections to my summary, I attempt to set the record straight below. On Thu, Dec 12, 2013 at 5:58 PM, Dan Harkins wrote: > >> >> Below is a summary of all CFRG discussion of Dragonfly. >> >> =3D=3D=3D=3D=3D >> >> Feb 2008 >> - Dan Harkins proposes early Dragonfly to CFRG >> http://www.ietf.org/mail-archive/web/cfrg/current/msg02205.html >> >> - Scott Fluhrer breaks it >> http://www.ietf.org/mail-archive/web/cfrg/current/msg02206.html > > An event mentioned in the acknowledgments. Thank you Scott. > His review and comments have been most helpful. > >> >> Nov 2011 >> - David McGrew appoints Kevin Igoe as CFRG co-chair >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03026.html > > Completely and utterly irrelevant. > >> Dec 2011 >> - Dan Harkins asks CFRG to look at TLS-PWD, based on Dragonfly >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03044.html >> >> - Scott Fluhrer points out a problem >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03045.html > > A simple "sanity" check that the an ECC point is not "infinity". Again, > a good comment. A crucial security check! >> - Adam Back questions necessity of it, and lack of security >> analysis >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03046.html > > He does no such thing. He notices that SRP is not mentioned in the > draft. Quite true. And he asks what key exchange is being implemented > because "its harder than it looks". Which is also quite true. I believe my description is accurate. >> Jan 2012 >> - Kevin Igoe's first email to CFRG: >> "I really like this idea & can find no problems." >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03047.html >> >> - Jonathan Katz questions lack of security analysis, points out >> problems >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03052.html >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03053.html > > Yes, helpful comments on the draft. The susceptibility to attack under > the random oracle model is, in fact, mentioned in my slide deck when > I presented to the CFRG in Paris at IETF 83. It is a highly contrived > scenario and completely unlikely a real world protocol but it does raise > the question of making a formal proof in that model. > > You should link to my slide deck in your next broadside. The random oracle model is a well-accepted methodology for analyzing crypto protocols. The SPEKE protocol, which Dragonfly is based on, has some degree of formal security proof in the random oracle model. If this proof does not carry over to Dragonfly, that's a source of concern: https://eprint.iacr.org/2001/057.pdf >> March 2012 >> - At IETF 83 CFRG meeting, concerns are raised about: >> - SPEKE patents >> - necessity of a new scheme >> - timing attacks >> - non-augmented properties >> http://www.ietf.org/proceedings/83/minutes/minutes-83-cfrg.txt > > Wow, you make it sound as if you were there. But you weren't. And > your summary is not an accurate description of the meeting. I wasn't there. I believe my summary of the minutes is accurate. > The > sole mention in the minutes of SPEKE is from me. """ Yoav Nir - there are no IPR? Really? Is it really enough different from speke that they won't go after. """ > And the "concerns" > are a recitation of comments received. That's how it works. You get > comments and you resolve them. The "concerns" seem critical of the whole enterprise: - "there are no IPR? Really?" - "Why the not use what IEEE already had defined in P1363" - "The difference between the scheme and SRP. Here both sides need to have same secret." - "could you scheme be made to be like SRP." This don't sound like CFRG approval. Yet after no significant further discussion, at IETF 84 the CFRG chair claims: """ Kevin Igoe: We approve of it, very clear and usable for general setting. """ >> May 2012 >> - Kevin Igoe points out a limitation due to "hunting-and-pecking" >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03099.html > > He does no such thing. He just said that if the prime defining the > curve p =3D 3 mod 4 that it's easier to compute the square root. Kevin recommended constraining Dragonfly to elliptic curves over those fiel= ds. This would eliminate Curve25519, and probably some other curves. >> - Zhou Sujing and Dan have an exchange that's hard to follow. >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03115.html >> >> July 2012 >> - At IETF 84 TLS meeting (CFRG does not meet): >> - Kevin Igoe informs TLS WG, as the CFRG chair: >> "We approve of it, very clear and usable for general setting." >> http://www.ietf.org/proceedings/84/minutes/minutes-84-tls > > Also note the comment: "Tie Dragonfly into EST would be very useful" > Yes, it would. I appreciate that the CFRG chairs are fond of Dragonfly. I'd like to understand where this approval comes from. >> Oct 2012 >> - Kevin Igoe calls CFRG attention to Dragonfly draft-00 >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03214.html >> >> - Jonathan Katz asks for a security proof - there is none >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03215.html >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03216.html > > Correct. There is no formal proof of security. See my slides from > IETF 83. I read Jonathan's re-iteration of this point as expressing concern. >> Dec 2012 >> - Kevin Igoe calls CFRG attention to Dragonfly >> - raises timing attack issue, proposes 2 fixes, including >> rediscovery of Dan's original broken method (2008) >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03258.html > > This is further discussion on addressing a side channel attack. > Your attempt to spin this as "broken" is somewhat desperate. Kevin's paragraph starting "A possible fix" is a rediscovery of the older Dragonfly technique which Scott Fluhrer broke in 2008. >> - Rene Struik points out the error in Kevin's proposal, and >> the inefficiency of Dragonfly relative to SPEKE >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03259.html > > He does no such thing. His "Suppose A and B=85" is a recitation of > a version of SPEKE that does not hash the password into a group in > the domain parameter set. It's neither here nor there with respect > to dragonfly. Rene describes how Kevin's proposal leads to an attack, in the context of SPEKE. I agree it would be clearer if he described it in the context of Dragonfly, but the attack is more or less the same. > He further goes on to suggest on a check for "point at > infinity". Which is already part of dragonfly. > > There is no "error" noted and no "inefficiency" mentioned either. "...but requires two full scalar multiplications (rather than one scalar multiplication as, e.g., SPEKE requires)." >> - Scott Fluhrer points out the error in Kevin's proposal, and >> proposes a flawed "mostly constant time" fix. Dan and Kevin >> embrace it. >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03260.html >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03262.html >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03263.html >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03264.html >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03265.html > > As noted in the email thread, the described fix was added to the > draft at the time. Your opinion on it being "flawed" has already been > noted. If you've "noted" the significant sidechannel risk, and the simple mitigation that's been suggested repeatedly (don't mix in the nonces), why doesn't your latest TLS-PWD (as of hours ago) include that fix? >> Feb 2013 >> - draft-01 is uploaded with flawed sidechannel fix >> - also quietly fixes security issue reported by Dylan Clarke >> and Feng Hao >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03309.html >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03529.html > > This is a small sub-group attack possible if one does not check > validity of received elements. All incarnations of dragonfly-- TLS-PWD, > EAP-PWD and 802.11 already did this. It is entirely my fault that I left = that > crucial step out of the -00 version of the CFRG draft but it is hardly > a flaw. I described it as a "security issue", which it is. >> Apr 2013 >> - Kevin Igoe mentions a last call for Dragonfly >> "The design looks mature, it addresses a real need, and no one >> has raised any issues." >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03383.html > > That's correct. You are included in that "no one". I don't think that's correct: * The design remains immature, with a major problem regarding timing side-channels. * I doubt the design addresses an important need. There are many better PAKEs, including SRP, which has been standardized and deployed in TLS (RFC 5054). In any case, there is little demand for TLS PAKE. * Many issues were raised. >> May 2013 >> - Feng Hao asks CFRG to consider J-PAKE (an alternative) >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03430.html > > Completely irrelevant. I think it's relevant that CFRG was made aware of other PAKEs, yet made no effort to perform a comparative analysis, or question whether Dragonfly was the best tool for the job. >> July 2013 >> - Rene Struik points out spec bugs, raises timing attack issue >> again >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03486.html >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03489.html > > "Spec bugs", in other words typos. Yes, he brings up an issue that > had previously been addressed. Rene doesn't seem to think the timing attack issue has been properly addressed, and neither do I. >> - IETF 87, CFRG meeting: >> - "The author is working on a new (and hopefully final) draft" >> http://www.ietf.org/proceedings/87/minutes/minutes-87-cfrg > > Sadly, it's not. I have to address the "Spec bugs" and address > Rene's other comments, none of which demonstrate security flaws. Rene's last message does, indeed, describe security flaws: http://www.ietf.org/mail-archive/web/cfrg/current/msg03527.html >> Aug 2013 >> - draft-02 is uploaded with modifications to "hunting-and-pecking" >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03509.html > > Don't forget comments dealing with internationalization! > > The change is from a comment received from, if I recall, Russ Housley > to use the technique from FIPS 186-3 to hide the bias added by the > modular reduction. Again, a very nice comment, happily accepted. Another security fix. >> Sep 2013 >> - SeongHan Shin asks CFRG to consider AugPAKE (an alternative) >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03523.html > > Completely irrelevant. (Again, not sure why you're have become such > a cheerleader for AugPAKE). I'm not. There are many PAKEs that are superior to Dragonfly *and* have a clearer IPR situation: SPAKE2, DH-EKE, SRP, J-PAKE, AugPAKE, and probably others. >> Nov/Dec 2013 >> - Joe Saloway begins TLS-PWD last call, and informs TLS WG that: >> "The underlying cryptographic protocol for TLS-PWD has been >> reviewed by the IRTF CFRG group with satisfactory results." >> http://www.ietf.org/mail-archive/web/tls/current/msg10476.html >> >> - Uproar on TLS WG: >> >> - Many object to lack of formal security analysis: >> Douglas Stebila, Uri Blumenthal, Bodo Moeller, Rene Struik, >> Watson Ladd > > Missing, of course, the caveat "-- except I believe that whenever > possible the IETF should aim to standardize cryptographic protocols > that are unencumbered by license fees and patents. If the choice > arises between a protocol that carries both (provable security and > Intellectual Property) and a protocol that has neither - I'd strongly > prefer the latter." That choice doesn't have to be made. There are protocols without current patents *and* with formal security arguments (SPAKE2, DH-EKE, J-PAKE). >> - Many point out better alternatives: >> SeongHan Shin, Robert Ransom, Watson Ladd, Trevor Perrin > > And you're all free to write up Internet Drafts on them too! I did, years ago - RFC 5054. TLS/SRP is a better PAKE than Dragonfly, has royalty-free IPR, and has been deployed. > In fact, SeongHan Shin has been following me around EMU, IPsec, > CFRG and now TLS doing just that. After I write a dragonfly I-D he > writes an AugPAKE I-D. Nothing is stopping you from doing it too. > >> - Security flaws are pointed out by Bodo Moeller and >> CodesInChaos >> http://www.ietf.org/mail-archive/web/tls/current/msg10708.html >> http://www.ietf.org/mail-archive/web/tls/current/msg10768.html > > Bodo's comment has been addressed. I dispute the use of the term > "security flaw" to describe it but that is consistent with the rest of > your email. The flaw is only present in the TLS-PWD draft, not the CFRG draft. I don't believe your latest TLS-PWD draft fixes it, however. You would have to introduce mandatory-to-implement domain parameters, as in RFC 5054. > CodesInChaos suggested using PBKDF2 to hash the password. This > really provides no additional benefit,, as I noted in a subsequent > email (see coWPAtty and family attacks against a protocol that uses > PBKDF2). Using an "expensive" password hash is standard practice for server-side password storage, to mitigate the effect of a server-side compromise. >> - Rene Struik and Bodo Moeller dispute that CFRG approved this >> http://www.ietf.org/mail-archive/web/tls/current/msg10769.html >> >> http://www.ietf.org/mail-archive/web/tls/current/msg10812.html > > Actually, Rene notes that CFRG has not issued a LC. He does raise > some comments, many of which are already addressed in the draft > and he points out the "Spec bug" you allude to earlier. He suggests > relaxation of one of the restrictions on parameter generation that I > decline to accept. And he finds some additional typos and an > erroneous description of point addition. Helpful comments. > >> - Eric Rescorla (TLS WG chair) states: >> "we did have a verbal report back from the chair of the CFRG >> that they considered it satisfactory" >> http://www.ietf.org/mail-archive/web/tls/current/msg10819.html > > Indeed. > > So what you've brought up is that there has been discussion of > dragonfly on the list and it has, in fact, been reviewed. Quite a few > comments have been made and resolved, security critical issues have > been raised and properly addressed. I agree that Dragonfly has had light review. Some bugs have been picked out of the CFRG and TLS drafts, some bugs remain. What I don't understand is how the CFRG chairs decided the protocol was "satisfactory". This seems a decision made by the chairs that neither reflects CFRG consensus nor was communicated to the broader CFRG group prior to informing TLS. Trevor From hallam@gmail.com Fri Dec 13 06:08:40 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9928A1AE29B; Fri, 13 Dec 2013 06:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMJ89fghltla; Fri, 13 Dec 2013 06:08:39 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id A32401AE28B; Fri, 13 Dec 2013 06:08:38 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hn9so1114194wib.13 for ; Fri, 13 Dec 2013 06:08:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AxXzbcHWcTDgTy0T2xecALWFBj4PHbcM4Xqn7lewtkg=; b=P4roaLWrzKnC6YIZd+9YRtsK3YhQiVdcAug7u984MMQ614ZbmoZSRwYceVn2CxFv5q cWzxUt7SAVJgdaKVeI171viefOtWbe0GNThIVl7enNjrya3yKJmKheophMQkQwHfGhl7 QAm0Wpb+uYEP6rq8e1XW6jU/kzNM056HRuPlTZXP4Y+rd6li5Su/1+uscdIZBTkRsKDM I0f3yAfy65Kv/UidbsJHeMqf6ZfDRT8CsAPk65ZnUnEvHbzr9KoQTTrtfK/H3d0KwBH4 +KCX+vGP6tHdXiYRSu38Hjia4RJmLBuAsjNUdXZt5vF9cOq9IUUAZylTL9E8uQ6rwemH UiHw== MIME-Version: 1.0 X-Received: by 10.194.94.167 with SMTP id dd7mr2493667wjb.43.1386943711881; Fri, 13 Dec 2013 06:08:31 -0800 (PST) Received: by 10.194.243.136 with HTTP; Fri, 13 Dec 2013 06:08:30 -0800 (PST) In-Reply-To: <52A9E61C.8030300@bbn.com> References: <52A8B1D0.2080304@dcrocker.net> <52A8E0E9.5020409@dcrocker.net> <52A9E61C.8030300@bbn.com> Date: Fri, 13 Dec 2013 09:08:30 -0500 Message-ID: From: Phillip Hallam-Baker To: Stephen Kent Content-Type: multipart/alternative; boundary=047d7bb03c464531d304ed6aff70 Cc: perpass , saag Subject: Re: [saag] [perpass] Draft charter for a Transparency Working Group X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 14:08:40 -0000 --047d7bb03c464531d304ed6aff70 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 12, 2013 at 11:36 AM, Stephen Kent wrote: > Ben > > > How about this footnote? >> >> "A cryptographically verifiable log is an append-only log of hashes of >> more-or-less anything that can prove its own correctness >> cryptographically. See RFC 6962, >> >> I'd like something a bit more technical, since the phrase "prove its > own correctness" is pretty general. Hopefully there is text in 6962 > that you can use. > How about just call it a catenate certificate append-only notary log which is the technical term of are that Harber and Stornetta introduced in their paper and patents? -- Website: http://hallambaker.com/ --047d7bb03c464531d304ed6aff70 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Dec 12, 2013 at 11:36 AM, Stephen Kent &l= t;kent@bbn.com> wrote:
Ben


How about this footnote?

"A cryptographically verifiable log is an append-only log of hashes of=
more-or-less anything that can prove its own correctness
cryptographically. See RFC 6962,

I'd like something a bit more technical, since the phrase "prove i= ts
own correctness" is pretty general. Hopefully there is text in 6962 that you can use.

How about just call i= t a catenate certificate append-only notary log which is the technical term= of are that Harber and Stornetta introduced in their paper and patents?

=A0
--
Website: http://hallambaker.com/
--047d7bb03c464531d304ed6aff70-- From hallam@gmail.com Fri Dec 13 06:17:14 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1EF81AE2B4; Fri, 13 Dec 2013 06:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7cnG8KbhsHs; Fri, 13 Dec 2013 06:17:12 -0800 (PST) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 412881AE2B0; Fri, 13 Dec 2013 06:17:12 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id w61so1943958wes.15 for ; Fri, 13 Dec 2013 06:17:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mluI2uBD81K80pxJsICygTVb1wQ3spH0o+tS+rCSCDE=; b=YjGOwlCgGwC2zyjjO3pkk7wppRCKPsLJibJn4zZEebtxUoEqckKKBUVMmF70zc3gAD yeuSsAGIAaKdQ48PmGCtZ1JEWRK3usl+utBtMFVE5n9d7Wv3/FyDi9jtimtR1IhVtr6K 3hWDN63toAAA5VNsjg8RJ2TKwJuSfbnNraL+eZtT8mL4VYORjh2MuoPl+zaHySdpp7dP Ji2SgKUOLHcW5lgjLNaxqoGlxpnihDokiESr+Q4qqfPhTtez+QJCDoUQOSdOyvdVSVY8 AWzK+Oxqkg5+bltRudxDkRGA2W4jJDsaEZfUmdsOaN9Q7SmfdcZ8NeycUoeFg+BDEmWJ xdog== MIME-Version: 1.0 X-Received: by 10.194.119.132 with SMTP id ku4mr2473022wjb.51.1386944225447; Fri, 13 Dec 2013 06:17:05 -0800 (PST) Received: by 10.194.243.136 with HTTP; Fri, 13 Dec 2013 06:17:05 -0800 (PST) In-Reply-To: References: <52A8B1D0.2080304@dcrocker.net> <52A8E0E9.5020409@dcrocker.net> <52A9E61C.8030300@bbn.com> Date: Fri, 13 Dec 2013 09:17:05 -0500 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=089e01228d72e1991904ed6b1d5c Cc: perpass , saag Subject: Re: [saag] [perpass] Draft charter for a Transparency Working Group X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 14:17:15 -0000 --089e01228d72e1991904ed6b1d5c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Dec 12, 2013 at 1:51 PM, Ben Laurie wrote: > How's this? > > [1] A cryptographically verifiable log is an append-only log of hashes > of more-or-less anything that can prove its own correctness > cryptographically. > > For example, from RFC 6962: =93The append-only property of each log is > technically achieved using Merkle Trees, which can be used to show > that any particular version of the log is a superset of any particular > previous version. Likewise, Merkle Trees avoid the need to blindly > trust logs: if a log attempts to show different things to different > people, this can be efficiently detected by comparing tree roots and > consistency proofs. Similarly, other misbehaviours of any log (e.g., > issuing signed timestamps for certificates they then don't log) can be > efficiently detected and proved to the world at large.=94 I disagree. The Merkle tree part is only relevant to verification efficiency. And I would want to look into it a lot further before committing to that particular approach due to the Micali patents and other patents applying Merkle to catenate certs. The property that is important is the chaining of one hash to the next and that is the property that is definitively out of patent. For email security I am not planning to use trees at all or at least not in that way. Chains are simpler to debug and the additional overhead largely irrelevant as all the certificate validation and evaluation can be done offline. Latency is not a concern as this is a store and forward protocol or a messaging protocol. The time it takes someone to pick up the phone is always going to be much longer than any key evaluation process. --=20 Website: http://hallambaker.com/ --089e01228d72e1991904ed6b1d5c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Thu, Dec 12, 2013 at 1:51 PM, Ben Laurie <<= a href=3D"mailto:benl@google.com" target=3D"_blank">benl@google.com>= wrote:
How's this?

[1] A cryptographically verifiable log is an append-only log of hashes
of more-or-less anything that can prove its own correctne= ss
cryptographically.

For example, from RFC 6962: =93The append-only property of each log i= s
technically achieved using Merkle Trees, which can be used to show
that any particular version of the log is a superset of any particular
previous version. Likewise, Merkle Trees avoid the need to blindly
trust logs: if a log attempts to show different things to different
people, this can be efficiently detected by comparing tree roots and
consistency proofs. Similarly, other misbehaviours of any log (e.g.,
issuing signed timestamps for certificates they then don't log) can be<= br> efficiently detected and proved to the world at large.=94
=
I disagree. The Merkle tree part is only relevant to verific= ation efficiency. And I would want to look into it a lot further before com= mitting to that particular approach due to the Micali patents and other pat= ents applying Merkle to catenate certs.
=A0
The property that is important is the chaining of = one hash to the next and that is the property that is definitively out of p= atent.


For email security I am not = planning to use trees at all or at least not in that way. Chains are simple= r to debug and the additional overhead largely irrelevant as all the certif= icate validation and evaluation can be done offline.

Latency is not a concern as this is a store and forward= protocol or a messaging protocol. The time it takes someone to pick up the= phone is always going to be much longer than any key evaluation process.

--
Website: http://h= allambaker.com/
--089e01228d72e1991904ed6b1d5c-- From benl@google.com Fri Dec 13 06:25:32 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE2D1AE263 for ; Fri, 13 Dec 2013 06:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQSOe4wLxFTO for ; Fri, 13 Dec 2013 06:25:31 -0800 (PST) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id A66841ADBF7 for ; Fri, 13 Dec 2013 06:25:31 -0800 (PST) Received: by mail-ve0-f182.google.com with SMTP id jy13so1434845veb.13 for ; Fri, 13 Dec 2013 06:25:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=6K4SDPkNl0Y8hAvxrxYgE3eFqKN6ebP2kVJIcYipmtw=; b=KDBY63wpqHYQOqd89c5WVeO9OskPdnyEFMcRmT3VRHLNBMaGRbnCyP96w+nBuZ+Pdp BR7WZtv+VDP+sNODGLNolYARER1p7AJ3uxU6Wy7VPhh5LYMiErL3Yk9YTEJuoxtsTU1S dRHCxSfYwgOjL1HJg8ApEjMe62TB4WXG7m3SVvxCiB9qpLNBs6HK8bqUInCCfx558oZI BVo5B9gn6FDYogEPoJhX7zpBYIbeMQhZceE2DSQpH45KV3UTKVn1oKIfOtTgF16G12ka OHLH9LQqOse1FpiVuWuCjWqfqjKre5cF4QDuAzrWxVoaeZre9qlL7Hyz7PIdDzSiqsFB B35Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6K4SDPkNl0Y8hAvxrxYgE3eFqKN6ebP2kVJIcYipmtw=; b=EvfBWf9YuHOqmhnMk4V80TNshWvORWOumU/Ur40fruXrbc3yj462jTaasvSPNz0YDI sB2pKBuzLVcJ8Ru1xJjp4BgDbVkvupbPrjFyq5Tdoij2+v/SksRVyhqXmNtgFghE4v2y MSEGBcNWZAkXO7beX/TfsbiYuRnXDMnHDAIxqJx/40Sv2wAlZEHldGwh/CY1rk+HS7zT /nGsLKvArd5TkKxbGNTyRexyHRPlzlh8DIeqbqEQYvH+bp/BGgybfaMd2GkUfPojBfTT TBL2dGN4zz9mMvOWM97h/MNtGUKlVhUGvVdHqb8gUSn8DhzWGca0U2t70ZUgHcngsQIX CNLQ== X-Gm-Message-State: ALoCoQmnolS8yN8ssPOvr7sTwmi/PStGPirwRqGrMwQWvOxyYCA4FJTjRgyeKpnF2coV5ljqltMItnwuMCvr2t5805/YfZ5oGBWCsE/tvF4HNp6WUcjBKdYihBzT/64xxMyJEjbYYYq7AguFR1Ot8VcNeE01g95ehrToH9yWwES7SW5EHU0I3mq6Y8q1JRd4SiED4rXI2I1V MIME-Version: 1.0 X-Received: by 10.58.118.84 with SMTP id kk20mr1316676veb.26.1386944725023; Fri, 13 Dec 2013 06:25:25 -0800 (PST) Received: by 10.52.183.65 with HTTP; Fri, 13 Dec 2013 06:25:24 -0800 (PST) In-Reply-To: References: <52A8B1D0.2080304@dcrocker.net> <52A8E0E9.5020409@dcrocker.net> <52A9E61C.8030300@bbn.com> Date: Fri, 13 Dec 2013 14:25:24 +0000 Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: perpass , saag Subject: Re: [saag] [perpass] Draft charter for a Transparency Working Group X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 14:25:33 -0000 On 13 December 2013 14:17, Phillip Hallam-Baker wrote: > > > > On Thu, Dec 12, 2013 at 1:51 PM, Ben Laurie wrote: >> >> How's this? >> >> [1] A cryptographically verifiable log is an append-only log of hashes >> of more-or-less anything that can prove its own correctness >> cryptographically. >> >> For example, from RFC 6962: =93The append-only property of each log is >> technically achieved using Merkle Trees, which can be used to show >> that any particular version of the log is a superset of any particular >> previous version. Likewise, Merkle Trees avoid the need to blindly >> trust logs: if a log attempts to show different things to different >> people, this can be efficiently detected by comparing tree roots and >> consistency proofs. Similarly, other misbehaviours of any log (e.g., >> issuing signed timestamps for certificates they then don't log) can be >> efficiently detected and proved to the world at large.=94 > > > I disagree. The Merkle tree part is only relevant to verification > efficiency. And I would want to look into it a lot further before committ= ing > to that particular approach due to the Micali patents and other patents > applying Merkle to catenate certs. You disagree that RFC 6962 provides an example? I'm not sure what you're disagreeing with... > The property that is important is the chaining of one hash to the next an= d > that is the property that is definitively out of patent. The property that is important is the ability to prove correctness, by whatever means. From TurnerS@ieca.com Fri Dec 13 07:54:33 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651181AE4E1 for ; Fri, 13 Dec 2013 07:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkN88U4-bzh3 for ; Fri, 13 Dec 2013 07:54:29 -0800 (PST) Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [67.18.70.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7001ADFC8 for ; Fri, 13 Dec 2013 07:54:28 -0800 (PST) Received: by gateway13.websitewelcome.com (Postfix, from userid 5007) id 35AAD5CACDA4; Fri, 13 Dec 2013 09:54:22 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway13.websitewelcome.com (Postfix) with ESMTP id 8274F5CAC4EB for ; Fri, 13 Dec 2013 09:54:19 -0600 (CST) Received: from [96.231.219.103] (port=59166 helo=[192.168.1.5]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1VrV4D-0000Ql-Jr; Fri, 13 Dec 2013 09:54:18 -0600 From: Sean Turner Content-Type: multipart/signed; boundary="Apple-Mail=_04771388-67F5-48AB-8A62-F66AEEA0C686"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <1D142D8E-2BBE-4BD2-B454-A07A7D31ECD1@ieca.com> Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Date: Fri, 13 Dec 2013 10:54:58 -0500 References: <18138981706be6221b2d05187da48394.squirrel@www.trepanning.net> To: cfrg@ietf.org, "tls@ietf.org" , saag@ietf.org In-Reply-To: X-Mailer: Apple Mail (2.1822) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.219.103 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.5]) [96.231.219.103]:59166 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 10 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Subject: Re: [saag] [Cfrg] Question regarding CFRG process X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 15:54:33 -0000 --Apple-Mail=_04771388-67F5-48AB-8A62-F66AEEA0C686 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 All further responses to this thread need to be sent to the CFRG list = not the TLS or SAAG list. spt On Dec 13, 2013, at 05:29, Trevor Perrin wrote: > Dan, all, >=20 > My message was directed at the CFRG chairs. I believe CFRG consensus > has been misrepresented regarding Dragonfly. >=20 > I'd appreciate if the chairs would respond to this. >=20 >=20 > Regarding Dan's objections to my summary, I attempt to set the record > straight below. >=20 > On Thu, Dec 12, 2013 at 5:58 PM, Dan Harkins = wrote: >>=20 >>>=20 >>> Below is a summary of all CFRG discussion of Dragonfly. >>>=20 >>> =3D=3D=3D=3D=3D >>>=20 >>> Feb 2008 >>> - Dan Harkins proposes early Dragonfly to CFRG >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg02205.html >>>=20 >>> - Scott Fluhrer breaks it >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg02206.html >>=20 >> An event mentioned in the acknowledgments. Thank you Scott. >> His review and comments have been most helpful. >>=20 >>>=20 >>> Nov 2011 >>> - David McGrew appoints Kevin Igoe as CFRG co-chair >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03026.html >>=20 >> Completely and utterly irrelevant. >>=20 >>> Dec 2011 >>> - Dan Harkins asks CFRG to look at TLS-PWD, based on Dragonfly >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03044.html >>>=20 >>> - Scott Fluhrer points out a problem >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03045.html >>=20 >> A simple "sanity" check that the an ECC point is not "infinity". = Again, >> a good comment. >=20 > A crucial security check! >=20 >=20 >>> - Adam Back questions necessity of it, and lack of security >>> analysis >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03046.html >>=20 >> He does no such thing. He notices that SRP is not mentioned in the >> draft. Quite true. And he asks what key exchange is being implemented >> because "its harder than it looks". Which is also quite true. >=20 > I believe my description is accurate. >=20 >=20 >>> Jan 2012 >>> - Kevin Igoe's first email to CFRG: >>> "I really like this idea & can find no problems." >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03047.html >>>=20 >>> - Jonathan Katz questions lack of security analysis, points out >>> problems >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03052.html >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03053.html >>=20 >> Yes, helpful comments on the draft. The susceptibility to attack = under >> the random oracle model is, in fact, mentioned in my slide deck when >> I presented to the CFRG in Paris at IETF 83. It is a highly contrived >> scenario and completely unlikely a real world protocol but it does = raise >> the question of making a formal proof in that model. >>=20 >> You should link to my slide deck in your next broadside. >=20 > The random oracle model is a well-accepted methodology for analyzing > crypto protocols. >=20 > The SPEKE protocol, which Dragonfly is based on, has some degree of > formal security proof in the random oracle model. If this proof does > not carry over to Dragonfly, that's a source of concern: >=20 > https://eprint.iacr.org/2001/057.pdf >=20 >=20 >>> March 2012 >>> - At IETF 83 CFRG meeting, concerns are raised about: >>> - SPEKE patents >>> - necessity of a new scheme >>> - timing attacks >>> - non-augmented properties >>> http://www.ietf.org/proceedings/83/minutes/minutes-83-cfrg.txt >>=20 >> Wow, you make it sound as if you were there. But you weren't. And >> your summary is not an accurate description of the meeting. >=20 > I wasn't there. I believe my summary of the minutes is accurate. >=20 >=20 >> The >> sole mention in the minutes of SPEKE is from me. >=20 > """ > Yoav Nir - there are no IPR? Really? Is it really enough different > from speke that they won't go after. > """ >=20 >=20 >> And the "concerns" >> are a recitation of comments received. That's how it works. You get >> comments and you resolve them. >=20 > The "concerns" seem critical of the whole enterprise: > - "there are no IPR? Really?" > - "Why the not use what IEEE already had defined in P1363" > - "The difference between the scheme and SRP. Here both > sides need to have same secret." > - "could you scheme be made to be like SRP." >=20 > This don't sound like CFRG approval. Yet after no significant further > discussion, at IETF 84 the CFRG chair claims: >=20 > """ > Kevin Igoe: We approve of it, very clear and usable for general = setting. > """ >=20 >=20 >>> May 2012 >>> - Kevin Igoe points out a limitation due to "hunting-and-pecking" >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03099.html >>=20 >> He does no such thing. He just said that if the prime defining the >> curve p =3D 3 mod 4 that it's easier to compute the square root. >=20 > Kevin recommended constraining Dragonfly to elliptic curves over those = fields. >=20 > This would eliminate Curve25519, and probably some other curves. >=20 >=20 >>> - Zhou Sujing and Dan have an exchange that's hard to follow. >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03115.html >>>=20 >>> July 2012 >>> - At IETF 84 TLS meeting (CFRG does not meet): >>> - Kevin Igoe informs TLS WG, as the CFRG chair: >>> "We approve of it, very clear and usable for general setting." >>> http://www.ietf.org/proceedings/84/minutes/minutes-84-tls >>=20 >> Also note the comment: "Tie Dragonfly into EST would be very useful" >> Yes, it would. >=20 > I appreciate that the CFRG chairs are fond of Dragonfly. >=20 > I'd like to understand where this approval comes from. >=20 >=20 >>> Oct 2012 >>> - Kevin Igoe calls CFRG attention to Dragonfly draft-00 >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03214.html >>>=20 >>> - Jonathan Katz asks for a security proof - there is none >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03215.html >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03216.html >>=20 >> Correct. There is no formal proof of security. See my slides from >> IETF 83. >=20 > I read Jonathan's re-iteration of this point as expressing concern. >=20 >=20 >>> Dec 2012 >>> - Kevin Igoe calls CFRG attention to Dragonfly >>> - raises timing attack issue, proposes 2 fixes, including >>> rediscovery of Dan's original broken method (2008) >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03258.html >>=20 >> This is further discussion on addressing a side channel attack. >> Your attempt to spin this as "broken" is somewhat desperate. >=20 > Kevin's paragraph starting "A possible fix" is a rediscovery of the > older Dragonfly technique which Scott Fluhrer broke in 2008. >=20 >=20 >>> - Rene Struik points out the error in Kevin's proposal, and >>> the inefficiency of Dragonfly relative to SPEKE >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03259.html >>=20 >> He does no such thing. His "Suppose A and B=85" is a recitation of >> a version of SPEKE that does not hash the password into a group in >> the domain parameter set. It's neither here nor there with respect >> to dragonfly. >=20 > Rene describes how Kevin's proposal leads to an attack, in the context > of SPEKE. I agree it would be clearer if he described it in the > context of Dragonfly, but the attack is more or less the same. >=20 >=20 >> He further goes on to suggest on a check for "point at >> infinity". Which is already part of dragonfly. >>=20 >> There is no "error" noted and no "inefficiency" mentioned either. >=20 > "...but requires two full scalar multiplications (rather than one > scalar multiplication as, e.g., SPEKE requires)." >=20 >=20 >>> - Scott Fluhrer points out the error in Kevin's proposal, and >>> proposes a flawed "mostly constant time" fix. Dan and Kevin >>> embrace it. >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03260.html >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03262.html >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03263.html >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03264.html >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03265.html >>=20 >> As noted in the email thread, the described fix was added to the >> draft at the time. Your opinion on it being "flawed" has already been >> noted. >=20 > If you've "noted" the significant sidechannel risk, and the simple > mitigation that's been suggested repeatedly (don't mix in the nonces), > why doesn't your latest TLS-PWD (as of hours ago) include that fix? >=20 >=20 >>> Feb 2013 >>> - draft-01 is uploaded with flawed sidechannel fix >>> - also quietly fixes security issue reported by Dylan Clarke >>> and Feng Hao >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03309.html >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03529.html >>=20 >> This is a small sub-group attack possible if one does not check >> validity of received elements. All incarnations of dragonfly-- = TLS-PWD, >> EAP-PWD and 802.11 already did this. It is entirely my fault that I = left that >> crucial step out of the -00 version of the CFRG draft but it is = hardly >> a flaw. >=20 > I described it as a "security issue", which it is. >=20 >=20 >>> Apr 2013 >>> - Kevin Igoe mentions a last call for Dragonfly >>> "The design looks mature, it addresses a real need, and no one >>> has raised any issues." >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03383.html >>=20 >> That's correct. You are included in that "no one". >=20 > I don't think that's correct: > * The design remains immature, with a major problem regarding timing > side-channels. > * I doubt the design addresses an important need. There are many > better PAKEs, including SRP, which has been standardized and deployed > in TLS (RFC 5054). In any case, there is little demand for TLS PAKE. > * Many issues were raised. >=20 >=20 >>> May 2013 >>> - Feng Hao asks CFRG to consider J-PAKE (an alternative) >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03430.html >>=20 >> Completely irrelevant. >=20 > I think it's relevant that CFRG was made aware of other PAKEs, yet > made no effort to perform a comparative analysis, or question whether > Dragonfly was the best tool for the job. >=20 >=20 >>> July 2013 >>> - Rene Struik points out spec bugs, raises timing attack issue >>> again >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03486.html >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03489.html >>=20 >> "Spec bugs", in other words typos. Yes, he brings up an issue that >> had previously been addressed. >=20 > Rene doesn't seem to think the timing attack issue has been properly > addressed, and neither do I. >=20 >=20 >>> - IETF 87, CFRG meeting: >>> - "The author is working on a new (and hopefully final) draft" >>> http://www.ietf.org/proceedings/87/minutes/minutes-87-cfrg >>=20 >> Sadly, it's not. I have to address the "Spec bugs" and address >> Rene's other comments, none of which demonstrate security flaws. >=20 > Rene's last message does, indeed, describe security flaws: >=20 > http://www.ietf.org/mail-archive/web/cfrg/current/msg03527.html >=20 >=20 >>> Aug 2013 >>> - draft-02 is uploaded with modifications to "hunting-and-pecking" >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03509.html >>=20 >> Don't forget comments dealing with internationalization! >>=20 >> The change is from a comment received from, if I recall, Russ = Housley >> to use the technique from FIPS 186-3 to hide the bias added by the >> modular reduction. Again, a very nice comment, happily accepted. >=20 > Another security fix. >=20 >=20 >>> Sep 2013 >>> - SeongHan Shin asks CFRG to consider AugPAKE (an alternative) >>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03523.html >>=20 >> Completely irrelevant. (Again, not sure why you're have become such >> a cheerleader for AugPAKE). >=20 > I'm not. There are many PAKEs that are superior to Dragonfly *and* > have a clearer IPR situation: SPAKE2, DH-EKE, SRP, J-PAKE, AugPAKE, > and probably others. >=20 >=20 >>> Nov/Dec 2013 >>> - Joe Saloway begins TLS-PWD last call, and informs TLS WG that: >>> "The underlying cryptographic protocol for TLS-PWD has been >>> reviewed by the IRTF CFRG group with satisfactory results." >>> http://www.ietf.org/mail-archive/web/tls/current/msg10476.html >>>=20 >>> - Uproar on TLS WG: >>>=20 >>> - Many object to lack of formal security analysis: >>> Douglas Stebila, Uri Blumenthal, Bodo Moeller, Rene Struik, >>> Watson Ladd >>=20 >> Missing, of course, the caveat "-- except I believe that whenever >> possible the IETF should aim to standardize cryptographic protocols >> that are unencumbered by license fees and patents. If the choice >> arises between a protocol that carries both (provable security and >> Intellectual Property) and a protocol that has neither - I'd strongly >> prefer the latter." >=20 > That choice doesn't have to be made. There are protocols without > current patents *and* with formal security arguments (SPAKE2, DH-EKE, > J-PAKE). >=20 >=20 >>> - Many point out better alternatives: >>> SeongHan Shin, Robert Ransom, Watson Ladd, Trevor Perrin >>=20 >> And you're all free to write up Internet Drafts on them too! >=20 > I did, years ago - RFC 5054. TLS/SRP is a better PAKE than Dragonfly, > has royalty-free IPR, and has been deployed. >=20 >=20 >> In fact, SeongHan Shin has been following me around EMU, IPsec, >> CFRG and now TLS doing just that. After I write a dragonfly I-D he >> writes an AugPAKE I-D. Nothing is stopping you from doing it too. >>=20 >>> - Security flaws are pointed out by Bodo Moeller and >>> CodesInChaos >>> http://www.ietf.org/mail-archive/web/tls/current/msg10708.html >>> http://www.ietf.org/mail-archive/web/tls/current/msg10768.html >>=20 >> Bodo's comment has been addressed. I dispute the use of the term >> "security flaw" to describe it but that is consistent with the rest = of >> your email. >=20 > The flaw is only present in the TLS-PWD draft, not the CFRG draft. >=20 > I don't believe your latest TLS-PWD draft fixes it, however. You > would have to introduce mandatory-to-implement domain parameters, as > in RFC 5054. >=20 >=20 >> CodesInChaos suggested using PBKDF2 to hash the password. This >> really provides no additional benefit,, as I noted in a subsequent >> email (see coWPAtty and family attacks against a protocol that uses >> PBKDF2). >=20 > Using an "expensive" password hash is standard practice for > server-side password storage, to mitigate the effect of a server-side > compromise. >=20 >=20 >>> - Rene Struik and Bodo Moeller dispute that CFRG approved this >>> http://www.ietf.org/mail-archive/web/tls/current/msg10769.html >>>=20 >>> http://www.ietf.org/mail-archive/web/tls/current/msg10812.html >>=20 >> Actually, Rene notes that CFRG has not issued a LC. He does raise >> some comments, many of which are already addressed in the draft >> and he points out the "Spec bug" you allude to earlier. He suggests >> relaxation of one of the restrictions on parameter generation that I >> decline to accept. And he finds some additional typos and an >> erroneous description of point addition. Helpful comments. >>=20 >>> - Eric Rescorla (TLS WG chair) states: >>> "we did have a verbal report back from the chair of the CFRG >>> that they considered it satisfactory" >>> http://www.ietf.org/mail-archive/web/tls/current/msg10819.html >>=20 >> Indeed. >>=20 >> So what you've brought up is that there has been discussion of >> dragonfly on the list and it has, in fact, been reviewed. Quite a few >> comments have been made and resolved, security critical issues have >> been raised and properly addressed. >=20 > I agree that Dragonfly has had light review. Some bugs have been > picked out of the CFRG and TLS drafts, some bugs remain. >=20 > What I don't understand is how the CFRG chairs decided the protocol > was "satisfactory". This seems a decision made by the chairs that > neither reflects CFRG consensus nor was communicated to the broader > CFRG group prior to informing TLS. >=20 >=20 > Trevor > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg --Apple-Mail=_04771388-67F5-48AB-8A62-F66AEEA0C686 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEgDCCBHww ggJkoAMCAQICCQCdWMxKNutUeTANBgkqhkiG9w0BAQsFADAiMQswCQYDVQQGEwJVUzETMBEGA1UE ChMKSUVDQSwgSW5jLjAeFw0xMzA0MDMxNDUxMThaFw0xNDA0MDMxNDUxMThaMDgxCzAJBgNVBAYT AlVTMRMwEQYDVQQKEwpJRUNBLCBJbmMuMRQwEgYDVQQDEwtTZWFuIFR1cm5lcjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAOpCGCRptT1m+bIpLTmbahZLZ0Qe4X99f8SgTQ7QISvUfpmn tfOD1oA1AttXlOULEERYubzvDnUTXvstFomQx0XTA67IaV+mw9ODRtG1hPN/erdKX6sU6rH4tsEb ba3Drr/I0HT3YVvD3SjWtGXjF12XLvTP6+LfMIIDTCAPiEd9KPG23D7skVu/4BvvmdLFI96OARhg wQ86M+lTIn83KRJlbbfAeIevbRx/rUB7D+uvMdWxOzR0KZJhd6dEeTXVwBXZG4rnQ4uFM+mRSiD4 rxDCyOuIuOzR07tnOyCRio6sRipOZvwQUWttdsgMEs6IxLdWsaTXcs1HjCsxrdedovMCAwEAAaOB njCBmzAOBgNVHQ8BAf8EBAMCBeAwHwYDVR0jBBgwFoAUAHRsSeXJUmFxTVY4q2HJ8uHl+w0wGwYD VR0RBBQwEoEQVHVybmVyU0BpZWNhLmNvbTAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vd3d3Lmll Y2EuY29tL2NybHMvaWVjYS5jcmwwFwYDVR0gBBAwDjAMBgorBgEEAYHXAAAAMA0GCSqGSIb3DQEB CwUAA4ICAQAimDYm77ppTi4vK6qJSUhyvCDMGb8mngiEXEYKxsfdHPWoDO7+06j7dAZ8sDD9/FtE kiUMyoNGSUmKHR+tGperVnNiM/Zk6WwCJv8dYZwhGXNQeEGzeys/UkFv7CFX7uDSn8GQeB8sOAZ1 N1hxV/TvT8qXvcRxP5+aWTAGAq3TKtCQxZjuU74L3st2hZiOhJlhjhqz0K5FIwWzXUK9uwhZe1th GUpDbRustVgmKN2Xa0pzwqI1VUO0jnWt24A4u59xo6DJQXzQVMhCx0xhpemuT9BrsBDTX8eJdI1i Wv9wp3ivSrfHjKXp8y8OGD+usiG40HCjj0W9C+dH0VfbgrB6QOI4vA9+kTg4mANth1cxyxwPYOSJ v0zi1qR0eDIGI//2v2/s6TmGuNqbnRa26Ldv5gGqS7xj32Fiaby6UOXs4+aAIWGZEOH+BXjozcvE eGBwjU/VRQYu6itR28PaNhNVji4D5ITaGxWWiycqK1EUaFraWHtk7W100ROX69xTeFVZP86D2ymi /aohl5Vb1vlYHdqlbgqjDRl9dPbTxVCXEHf+jkexcuwlLTvr7F+5DIN6c/EbCpRqQx3edy193L48 OGyRDh1/Wmzpew0VWWAWOSXGl/P9VzXf3Z6GPt7flN/V9iEJAa3Mo+w+eIdzJkHBWR+yJcqQcCRM MSyishMwLDGCAjgwggI0AgEBMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C CQCdWMxKNutUeTAJBgUrDgMCGgUAoIHfMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEzMTIxMzE1NTQ1OFowIwYJKoZIhvcNAQkEMRYEFKU2rnUjd7xUWmuJTj9nahlB eDcAMD4GCSsGAQQBgjcQBDExMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C CQCdWMxKNutUeTBABgsqhkiG9w0BCRACCzExoC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklF Q0EsIEluYy4CCQCdWMxKNutUeTANBgkqhkiG9w0BAQEFAASCAQBhRRDfHjayGOsDbfUdp3B9UeGZ XcBns4HVT15a9FuzoB+lBu5Auf482PejB/gf7s9sEsrYXxeTv3n6y/7CwbZ1z2rvLQAI0B4HyeIf szNTYcZ9dK2PxXcJ9umBeqPY/WwbQbxOjiCf8BO2kzx+T/TFfWLB8raeifyjoQpYWJVZeDBg31NJ m2dCG/8NdmjJGtwW0zi3Vn2yo7OUXmL1wv+Tk3RPgK8eeU40mvslQqMf3QyNam7z71o4EgP4Pj+z tBKNvCsA7EWjG/fI+ivz99cq/bL9P21+2bUiN6K/0mp9ZY5DtISWbGLg7cn1awyj73wjam9VmOv6 stWpNK4dPD+MAAAAAAAA --Apple-Mail=_04771388-67F5-48AB-8A62-F66AEEA0C686-- From hallam@gmail.com Fri Dec 13 09:14:15 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64EAD1AE36B for ; Fri, 13 Dec 2013 09:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SI2lbC7bN_sf for ; Fri, 13 Dec 2013 09:14:13 -0800 (PST) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id DEA101AE64F for ; Fri, 13 Dec 2013 09:14:12 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id n12so2115916wgh.2 for ; Fri, 13 Dec 2013 09:14:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=P19+WZmr1prw9j5C8FXxCC17aEB1hBl+U10FJNP4ibE=; b=vIC5Wdca56Ueyr59k6riRy/IdN8ya2aWFX1U32ng+h8WGBj+DG5P1rprUDsa/f/K8x yLBuFh/ICjyKr61tHR+cumvJcHaQjGuMm4baOaO+RCrq/9dyS4MFGEq0IcsgvZ1I8w47 yJV4FG6aLZLLv0nPjNm1tXqYSrSlsLwOb+XI/7AzVAti+wC4gu3Cbgpr1tDNCB8+8dk9 qMoU0Svs9iYEvFkPJeYJqA1VH1FP/zbv4lhuHkTWGd8RvaugMDrFo+QydCAY8cVtOYjO 9xxRsSuFMhwKOmZFoTdeswQ17nDpVtLUc0rwUoDB5Yo8fWOu2NyxT/BJ/ZwKx8zVNuqU 5mog== MIME-Version: 1.0 X-Received: by 10.194.237.99 with SMTP id vb3mr3369004wjc.28.1386954845993; Fri, 13 Dec 2013 09:14:05 -0800 (PST) Received: by 10.194.243.136 with HTTP; Fri, 13 Dec 2013 09:14:05 -0800 (PST) Date: Fri, 13 Dec 2013 12:14:05 -0500 Message-ID: From: Phillip Hallam-Baker To: "saag@ietf.org" Content-Type: multipart/alternative; boundary=089e01494224ea444504ed6d9657 Subject: [saag] New approach to allocating OIDs in experimental work X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 17:14:15 -0000 --089e01494224ea444504ed6d9657 Content-Type: text/plain; charset=ISO-8859-1 One of the commonly occurring problems in IETF process is what to do when a project is transferred from private to public space. In particular should names be registered in a corporate namespace or an IETF namespace and if the latter what should be done with earlier registrations. Once in use it is practically impossible to kill an existing code point. For example Comodo has a Netscape email OID in its S/MIME certs to this day. I was just wondering if I should knife it since I doubt that there is any client that relies on that identifier being used and supports use of SHA-2-512. So what I was thinking about as an alternative approach is the following: 1) Ask IANA for a new OID assignment for each new project that might transition into public space, give the arc the name of the project. 2) If the IETF accepts change control then turn over management of the arc with the project. The big advantage of this approach is that it is completely clean. There is no need to duplicate code points. One possible objection is that the registry might bloat but that is also manageable, if it gets out of hand then IANA cuts a new oid off its arc for 'projects'. Anyway, I have decided to do a trial run on this approach for the email security scheme based on strong email addresses and phingerprint blocks. -- Website: http://hallambaker.com/ --089e01494224ea444504ed6d9657 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
One of the commonly occurring problems in IETF process is = what to do when a project is transferred from private to public space. In p= articular should names be registered in a corporate namespace or an IETF na= mespace and if the latter what should be done with earlier registrations.
Once in use it is practically impossible to kill an existing= code point. For example Comodo has a Netscape email OID in its S/MIME cert= s to this day. I was just wondering if I should knife it since I doubt that= there is any client that relies on that identifier being used and supports= use of SHA-2-512.

So what I was thinking about as an alternative approach= is the following:

1) Ask IANA for a new OID assig= nment for each new project that might transition into public space, give th= e arc the name of the project.

2) If the IETF accepts change control then turn over ma= nagement of the arc with the project.=A0


The big advantage of this approach is that it is completely clean. Th= ere is no need to duplicate code points.

One possible objection is that the registry might bloat= but that is also manageable, if it gets out of hand then IANA cuts a new o= id off its arc for 'projects'.

Anyway, I h= ave decided to do a trial run on this approach for the email security schem= e based on strong email addresses and phingerprint blocks.

--
Website: http://h= allambaker.com/
--089e01494224ea444504ed6d9657-- From blueroofmusic@gmail.com Fri Dec 13 10:16:08 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A7B1AE0F4 for ; Fri, 13 Dec 2013 10:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57aNiDSG5f1c for ; Fri, 13 Dec 2013 10:16:06 -0800 (PST) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8AB1ADF5C for ; Fri, 13 Dec 2013 10:16:05 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id x13so3230125ief.6 for ; Fri, 13 Dec 2013 10:15:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LPyNGlCsNdYzVqFyjeS1JaeJReYT5+9RhluF4TClnWc=; b=qwh0Hk1S9ZlRWiHID/Yb6tVsKN/kXP8LnTODhkf/1InBBk88zAlyuaGdx2rYMc9oqU BXcITz3eTjHcZbYDiLBRaxalpjDpGkPQXsMfezkgdMtOYDt8KI+hYE55OgNyHJ/6bo2b 9olFP0CWaHsKIMCKdAImHMzXT1EjDUXmCupQevq/sSHRNR608TLiKCt8+5IDpc2C5cpp k1KzIWsdgb2Xf+WVEzgSUkcfsPF+uxW8QfQL49tr+B3W4QEzq1/VQ81mYLUkqJxG52lW gLvls+n7DJeo7JUsC+IOwF5bgnfdqcnBUYHPgkbZRbDkL0CiNUUFJdbw/y0lelOBH8GA dipQ== X-Received: by 10.50.92.8 with SMTP id ci8mr3933935igb.23.1386958559510; Fri, 13 Dec 2013 10:15:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.203.38 with HTTP; Fri, 13 Dec 2013 10:15:39 -0800 (PST) In-Reply-To: References: From: Ira McDonald Date: Fri, 13 Dec 2013 13:15:39 -0500 Message-ID: To: Phillip Hallam-Baker , Ira McDonald Content-Type: multipart/alternative; boundary=047d7b10cf2742090304ed6e74b7 Cc: "saag@ietf.org" Subject: Re: [saag] New approach to allocating OIDs in experimental work X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 18:16:09 -0000 --047d7b10cf2742090304ed6e74b7 Content-Type: text/plain; charset=ISO-8859-1 Hi, I endorse this proposal. The use of the 'experimental' arc in MIB development has for years caused implementors to have to retain BOTH the 'experimental' and 'mib-2' arcs indefinitely in their code for interoperability and simply causes confusion, with no obvious benefit. Cheers, - Ira (editor of Printer MIB v2, Finisher MIB, and Charset MIB) Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Fri, Dec 13, 2013 at 12:14 PM, Phillip Hallam-Baker wrote: > One of the commonly occurring problems in IETF process is what to do when > a project is transferred from private to public space. In particular should > names be registered in a corporate namespace or an IETF namespace and if > the latter what should be done with earlier registrations. > > Once in use it is practically impossible to kill an existing code point. > For example Comodo has a Netscape email OID in its S/MIME certs to this > day. I was just wondering if I should knife it since I doubt that there is > any client that relies on that identifier being used and supports use of > SHA-2-512. > > So what I was thinking about as an alternative approach is the following: > > 1) Ask IANA for a new OID assignment for each new project that might > transition into public space, give the arc the name of the project. > > 2) If the IETF accepts change control then turn over management of the arc > with the project. > > > The big advantage of this approach is that it is completely clean. There > is no need to duplicate code points. > > One possible objection is that the registry might bloat but that is also > manageable, if it gets out of hand then IANA cuts a new oid off its arc for > 'projects'. > > Anyway, I have decided to do a trial run on this approach for the email > security scheme based on strong email addresses and phingerprint blocks. > > -- > Website: http://hallambaker.com/ > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > --047d7b10cf2742090304ed6e74b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I endorse this proposal.

The use of the 'experimental&= #39; arc in MIB development has for years
caused implementors to h= ave to retain BOTH the 'experimental'
and 'mib-2' arcs indefinitely in their code for interoperabil= ity and
simply causes confusion, with no obvious benefit.

<= /div>Cheers,
- Ira (editor of Printer MIB v2, Finisher MIB, and Ch= arset MIB)



Ira McDonald (Musician / Software Architect)
Co-Chair = - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printi= ng WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Int= ernet Printing Protocol WG
IETF Designated Expert - IPP & Printer MI= B
Blue Roof Music / High North Inc
http:= //sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthincmailto: blue= roofmusic@gmail.com
Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 734-944-0094
Summer= =A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2434



On Fri, Dec 13, 2013 at 12:14 PM, Philli= p Hallam-Baker <hallam@gmail.com> wrote:
One of the commonly occurring problems in IETF process is = what to do when a project is transferred from private to public space. In p= articular should names be registered in a corporate namespace or an IETF na= mespace and if the latter what should be done with earlier registrations.
Once in use it is practically impossible to kill an existing= code point. For example Comodo has a Netscape email OID in its S/MIME cert= s to this day. I was just wondering if I should knife it since I doubt that= there is any client that relies on that identifier being used and supports= use of SHA-2-512.

So what I was thinking about as an alternative approach= is the following:

1) Ask IANA for a new OID assig= nment for each new project that might transition into public space, give th= e arc the name of the project.

2) If the IETF accepts change control then turn over ma= nagement of the arc with the project.=A0


The big advantage of this approach is that it is completely clean. Th= ere is no need to duplicate code points.

One possible objection is that the registry might bloat= but that is also manageable, if it gets out of hand then IANA cuts a new o= id off its arc for 'projects'.

Anyway, I h= ave decided to do a trial run on this approach for the email security schem= e based on strong email addresses and phingerprint blocks.

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

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


--047d7b10cf2742090304ed6e74b7-- From nico@cryptonector.com Fri Dec 13 10:53:33 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876581AE3B9 for ; Fri, 13 Dec 2013 10:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5xrMkNhXMTU for ; Fri, 13 Dec 2013 10:53:32 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8218E1ADFE5 for ; Fri, 13 Dec 2013 10:53:32 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 29ACA438057; Fri, 13 Dec 2013 10:53:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Ox2pxBQrdaAD2+ UjIGTK92Sg+pE=; b=L5ithybXxxu12nchJyBRbUoqJ8K/K2YlVyOuJpKO3embj4 buW26GHZAo/S3OahoZ5ZiLWTCRBgsvQv+tHRluOPfbIkn/8iaK3nz/ocU1iQwEep BRuJH2TNp4RlMM3rsuB1N9hbqrlii44s8dXeJekvHEM3vJ9O1t1A69cCLQkxA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPA id B3D3643806C; Fri, 13 Dec 2013 10:53:25 -0800 (PST) Date: Fri, 13 Dec 2013 12:53:24 -0600 From: Nico Williams To: Phillip Hallam-Baker Message-ID: <20131213185320.GP4067@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "saag@ietf.org" Subject: Re: [saag] New approach to allocating OIDs in experimental work X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 18:53:33 -0000 On Fri, Dec 13, 2013 at 12:14:05PM -0500, Phillip Hallam-Baker wrote: > 1) Ask IANA for a new OID assignment for each new project that might > transition into public space, give the arc the name of the project. > > 2) If the IETF accepts change control then turn over management of the arc > with the project. 3) When the project completes (successfully or otherwise) change control goes back to the IETF/IANA. > One possible objection is that the registry might bloat but that is also > manageable, if it gets out of hand then IANA cuts a new oid off its arc for > 'projects'. It's one arc per-project. It's like saying that we have mailing list bloat. (OK, we do have mailing list bloat, but we live with it.) +1! Nico -- From stephen.farrell@cs.tcd.ie Fri Dec 13 13:49:46 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 316A41AE332 for ; Fri, 13 Dec 2013 13:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6RZnvTDjPFX for ; Fri, 13 Dec 2013 13:49:44 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3811ADF6C for ; Fri, 13 Dec 2013 13:49:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9A6A8BEB0; Fri, 13 Dec 2013 21:49:36 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDqZkyXgAEXs; Fri, 13 Dec 2013 21:49:35 +0000 (GMT) Received: from [10.87.48.4] (unknown [86.45.53.231]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 65B4DBEA4; Fri, 13 Dec 2013 21:49:35 +0000 (GMT) Message-ID: <52AB80EF.2060701@cs.tcd.ie> Date: Fri, 13 Dec 2013 21:49:35 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Nico Williams , Phillip Hallam-Baker References: <20131213185320.GP4067@localhost> In-Reply-To: <20131213185320.GP4067@localhost> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "saag@ietf.org" Subject: Re: [saag] New approach to allocating OIDs in experimental work X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 21:49:46 -0000 Sounds reasonable. Do we need an oid to start from based on an IANA one? Can someone write up the details in a mail and I can ask IANA to start a FCFS registry as a management item on some IESG telechat. Please try suggest the parent OID/arc from which you want IANA to allocate a new one as the parent of these. Let's see if we can do this without an RFC, unless someone wants to document it in one (no harm but could happen later). S. On 12/13/2013 06:53 PM, Nico Williams wrote: > On Fri, Dec 13, 2013 at 12:14:05PM -0500, Phillip Hallam-Baker wrote: >> 1) Ask IANA for a new OID assignment for each new project that might >> transition into public space, give the arc the name of the project. >> >> 2) If the IETF accepts change control then turn over management of the arc >> with the project. > > 3) When the project completes (successfully or otherwise) change control > goes back to the IETF/IANA. > >> One possible objection is that the registry might bloat but that is also >> manageable, if it gets out of hand then IANA cuts a new oid off its arc for >> 'projects'. > > It's one arc per-project. It's like saying that we have mailing list > bloat. (OK, we do have mailing list bloat, but we live with it.) > > +1! > > Nico > From nico@cryptonector.com Fri Dec 13 14:11:38 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C9E1ADFC5 for ; Fri, 13 Dec 2013 14:11:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFsWl8MiD201 for ; Fri, 13 Dec 2013 14:11:35 -0800 (PST) Received: from homiemail-a67.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id E4B401ADF80 for ; Fri, 13 Dec 2013 14:11:34 -0800 (PST) Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id 9F79327BC064; Fri, 13 Dec 2013 14:11:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Wi3M85V7mk7X8o 21H4jYfi14D0s=; b=h55eLFfnNELWqYlvrSmd+X0h9wlF4ipiZ+jixfXJxvE0WH SG7+txkkvjOBNhFFa5fqxllvjeaWr2TUVl11RCi0zE0+OyLyXlgfKb6tFzxmD2zB sC6ojCzNe7+cLcGa+r9z2RUqzHLwF46Hg8p+P2eyA3ZRMP5QJ2I56MZMyEmJw= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPA id 0F85A27BC05D; Fri, 13 Dec 2013 14:11:27 -0800 (PST) Date: Fri, 13 Dec 2013 16:11:27 -0600 From: Nico Williams To: Stephen Farrell Message-ID: <20131213221123.GS4067@localhost> References: <20131213185320.GP4067@localhost> <52AB80EF.2060701@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52AB80EF.2060701@cs.tcd.ie> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Phillip Hallam-Baker , "saag@ietf.org" Subject: Re: [saag] New approach to allocating OIDs in experimental work X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 22:11:38 -0000 On Fri, Dec 13, 2013 at 09:49:35PM +0000, Stephen Farrell wrote: > Sounds reasonable. Do we need an oid to start from based > on an IANA one? Can someone write up the details in a mail > and I can ask IANA to start a FCFS registry as a management > item on some IESG telechat. Please try suggest the parent > OID/arc from which you want IANA to allocate a new one > as the parent of these. > > Let's see if we can do this without an RFC, unless someone > wants to document it in one (no harm but could happen later). I think all we need is to ask IANA. IANA may want the IESG's say-so. From stephen.farrell@cs.tcd.ie Fri Dec 13 15:31:18 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054831ADFD6 for ; Fri, 13 Dec 2013 15:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVfD3aHSwvkh for ; Fri, 13 Dec 2013 15:31:15 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF981AE055 for ; Fri, 13 Dec 2013 15:31:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9AFCDBEC0; Fri, 13 Dec 2013 23:31:08 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfgkhTF0Xb3I; Fri, 13 Dec 2013 23:31:07 +0000 (GMT) Received: from [10.87.48.4] (unknown [86.45.53.231]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6A7ACBE63; Fri, 13 Dec 2013 23:31:07 +0000 (GMT) Message-ID: <52AB98BB.5000607@cs.tcd.ie> Date: Fri, 13 Dec 2013 23:31:07 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Nico Williams References: <20131213185320.GP4067@localhost> <52AB80EF.2060701@cs.tcd.ie> <20131213221123.GS4067@localhost> In-Reply-To: <20131213221123.GS4067@localhost> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Phillip Hallam-Baker , "saag@ietf.org" Subject: Re: [saag] New approach to allocating OIDs in experimental work X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 23:31:18 -0000 On 12/13/2013 10:11 PM, Nico Williams wrote: > On Fri, Dec 13, 2013 at 09:49:35PM +0000, Stephen Farrell wrote: >> Sounds reasonable. Do we need an oid to start from based >> on an IANA one? Can someone write up the details in a mail >> and I can ask IANA to start a FCFS registry as a management >> item on some IESG telechat. Please try suggest the parent >> OID/arc from which you want IANA to allocate a new one >> as the parent of these. >> >> Let's see if we can do this without an RFC, unless someone >> wants to document it in one (no harm but could happen later). > > I think all we need is to ask IANA. IANA may want the IESG's say-so. I think they will. I'm happy to ask the IESG the question (that'd be done as a "management item" on an IESG telechat). But, we can either wait until I get around to it, or else send me a mail with all the details so's I can just do a bit of cut'n'paste. The latter will be much quicker;-) S. > > From alexey.melnikov@isode.com Tue Dec 17 14:09:42 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723EC1AD9AE for ; Tue, 17 Dec 2013 14:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHBy5cc3c9AS for ; Tue, 17 Dec 2013 14:09:40 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE261AD75F for ; Tue, 17 Dec 2013 14:09:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1387318178; d=isode.com; s=selector; i=@isode.com; bh=480HE3IM7g3FeWnjoZq2U6ikeLTBnwE8pHaKkaWgZ9Q=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=KG3AcIOLNftYBdCtp+gYBAgxaMJWwPHKNQav9z98BlcSI/ZWwhfH4VdqMDjc6qBWNt/R00 WbpTxh5ettQJpCQ4JRqQNTrYbH5P+F/nz4KlIiYigYgHMvZR9yAzD/4HmdL6s7a3CEGJ7k g7vDXOXmy21WIsmj/BtFsuj/3TkVma8=; Received: from [192.168.0.4] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 17 Dec 2013 22:09:38 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <52B0CBA6.1010403@isode.com> Date: Tue, 17 Dec 2013 22:09:42 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: Nico Williams , Phillip Hallam-Baker References: <20131213185320.GP4067@localhost> In-Reply-To: <20131213185320.GP4067@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "saag@ietf.org" Subject: Re: [saag] New approach to allocating OIDs in experimental work X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 22:09:42 -0000 On 13/12/2013 18:53, Nico Williams wrote: > On Fri, Dec 13, 2013 at 12:14:05PM -0500, Phillip Hallam-Baker wrote: >> 1) Ask IANA for a new OID assignment for each new project that might >> transition into public space, give the arc the name of the project. >> >> 2) If the IETF accepts change control then turn over management of the arc >> with the project. > 3) When the project completes (successfully or otherwise) change control > goes back to the IETF/IANA. Agreed, but "completion" needs to be better defined, in case people disagree. >> One possible objection is that the registry might bloat but that is also >> manageable, if it gets out of hand then IANA cuts a new oid off its arc for >> 'projects'. > It's one arc per-project. It's like saying that we have mailing list > bloat. (OK, we do have mailing list bloat, but we live with it.) > > +1! Sounds like a good idea to me. From scott.mansfield@ericsson.com Thu Dec 19 07:09:50 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B641A1ADF9F for ; Thu, 19 Dec 2013 07:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.309 X-Spam-Level: X-Spam-Status: No, score=0.309 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dExLAOA4fJ8 for ; Thu, 19 Dec 2013 07:09:48 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 741401ADBCF for ; Thu, 19 Dec 2013 07:09:48 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-1d-52b30c3869d0 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 6C.25.04556.83C03B25; Thu, 19 Dec 2013 16:09:45 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0347.000; Thu, 19 Dec 2013 10:09:25 -0500 From: Scott Mansfield To: "saag@ietf.org" , Joel Halpern , Eliot Lear , "Ross Callon (rcallon@juniper.net)" Thread-Topic: =?Windows-1252?Q?announcement_of_the_fifth_meeting_of_ITU-T_Joint_Coordin?= =?Windows-1252?Q?ation_Activity_on_Child_Online_Protection_(JCA-COP),_Gen?= =?Windows-1252?Q?eva,_Switzerland,_15_January_2014,_18:00_=96_19:30_CET?= Thread-Index: Ac78uQ1LIAQ067/qSt2yNHRaVDTUtAAEDjtw Date: Thu, 19 Dec 2013 15:09:25 +0000 Message-ID: References: <6a4c905cbfbc4894a40fd8d4f9d95249@TUCM02.TUECSP.UNICC.ORG> In-Reply-To: <6a4c905cbfbc4894a40fd8d4f9d95249@TUCM02.TUECSP.UNICC.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/mixed; boundary="_006_EF35EE4B92789843B1DECBC0E245586439823DD6eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUyuXRPlK4lz+Ygg33d0hZf/3WwWPxdcYXF Ykp/J5MDs8eU3xtZPZYs+cnkcb3pKnsAcxSXTUpqTmZZapG+XQJXxrFHhxgL5t9mr7j2U6GB cet29i5GTg4JAROJ/z0voWwxiQv31rN1MXJxCAkcYZR4vvorlLOcUWL2t22MIFVsQB1bd01n BEmICKxklOh9/ZgZxBEW6GCS6Or5yAaR+cwo0XHrCAtIi4iAkUTbrHesIDaLgKrEpjnbwUbx CvhKHDt4ESwuJOAm8eTBHzCbU8Bd4vDUdWA1jEBHfT+1hgnEZhYQl7j1ZD4TxLEiEg8vnmaD sEUlXj7+xwphK0t8n/OIBaI+U+L8kZVMELsEJU7OfMIygVFkFpJRs5CUzUJSBhHvZpS48FAO ws6XmNczCypuIPH+3HxmCFtbYtnC11C2vsTGL2cZMcV1JH5/62KDsBUlbl+dygphL2OUeNgk AVPz/esTVpiaKd0P2SHsCIldbQuBbA4g20ni352iWcDgZRY4yygx//AMqPnWEl9WXWJE1ruA UXgVI0dpcWpZbrqR4SZGYOo5JsHmuINxwSfLQ4zSHCxK4rxf3joHCQmkJ5akZqemFqQWxReV 5qQWH2Jk4uCUamD0uRxQKvlWZMd0zb0hs7ctOGRqpLy9YQ73z2sLZ7h6KT9dm+69TEmCdXG5 kceUHKkLsQKnnF9ebLae99D8faJnXNre9fW5so0feXck+gvLCbQvNl6QwXtcdHvoQ6OGrhN/ trhH37CeVTN9aUKwl+CqX49unksXun4i5Sy7XnNBrk3qn83H9v9QYinOSDTUYi4qTgQA236d IAsDAAA= Subject: [saag] =?windows-1252?q?FW=3A_announcement_of_the_fifth_meeting_o?= =?windows-1252?q?f_ITU-T_Joint_Coordination_Activity_on_Child_Online_Prot?= =?windows-1252?q?ection_=28JCA-COP=29=2C_Geneva=2C_Switzerland=2C_15_Janu?= =?windows-1252?q?ary_2014=2C_18=3A00_=96_19=3A30_CET?= X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 15:09:50 -0000 --_006_EF35EE4B92789843B1DECBC0E245586439823DD6eusaamb105erics_ Content-Type: multipart/related; boundary="_005_EF35EE4B92789843B1DECBC0E245586439823DD6eusaamb105erics_"; type="multipart/alternative" --_005_EF35EE4B92789843B1DECBC0E245586439823DD6eusaamb105erics_ Content-Type: multipart/alternative; boundary="_000_EF35EE4B92789843B1DECBC0E245586439823DD6eusaamb105erics_" --_000_EF35EE4B92789843B1DECBC0E245586439823DD6eusaamb105erics_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I will be in Geneva this week and attend this meeting in person. I will no= t be representing the IETF (I=92ll register as Ericsson to avoid confusion)= , but I will **probably** be asked what the IETF is doing. Much like what = I have already presented, I think it is useful to continue to educate the I= TU-T on what exactly the IETF is doing in the Security area and also the ap= ps area. The underlying technologies that enable the technical solutions n= eeded to protect everyone on the Internet are being progressed in the IETF.= I think it is best to point out that the protocol work on such topics bel= ongs in the IETF. Maybe if we repeat that enough, the message will get thr= ough. I have some material already. If any of you know about material that would= be useful to include please let me know. Again it bears repeating --- This is just one of the =93big picture=94 issu= es that the ITU-T is working on and asking the IETF about. CoP, IoT, SDN, = Energy Efficiency, and Smart Cars are just a sample of the areas the ITU-T = is looking into. Asking an IETF participant what the IETF is doing on any = of those topics will either draw a blank stare or a deep dive into some bit= of engineering minutia which doesn=92t really provide the breadth of the w= ork going on in the IETF for a particular topic. It also bears repeating --- At no point am I representing the IETF. I don= =92t register as the IETF, I=92m not speaking for the IETF, I hold no IETF = leadership position. What I can do is report on what the IETF is doing and= advocate for the IETF to be the venue for any protocol work that needs to = be done to enable the solutions above. Please feel free to bring anyone else into this discussion that you feel wo= uld be interested=85 Thoughts? Regards, -scott. From: Euchner, Martin [mailto:martin.euchner@itu.int] Sent: Thursday, December 19, 2013 7:56 AM To: jcacop@lists.itu.int; Euchner, Martin Subject: [JCA-COP] announcement of the fifth meeting of ITU-T Joint Coordin= ation Activity on Child Online Protection (JCA-COP), Geneva, Switzerland, 1= 5 January 2014, 18:00 =96 19:30 CET All, Fifth meeting of ITU-T Joint Coordination Activity on Child Online Protecti= on (JCA-COP), Geneva, Switzerland, 15 January 2014, 18:00 =96 19:30 CET. PS: The draft agenda will follow later and separately. With kind regards Martin Euchner. Advisor of Study Group 17 Telecommunication Standardization Bureau (TSB) International Telecommunication Union (ITU) e-mail : Martin.Euchner@itu.int Phone : +41 22 730 5866 Mobile: +41 79 592 4688 URL : http://www.itu.int/ITU-T/studygroups/com17 Office No : M.415 [cid:image001.png@01CEFCC2.01C25110] Place des Nations CH-1211 Geneva 20 Switzerland --_000_EF35EE4B92789843B1DECBC0E245586439823DD6eusaamb105erics_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

 

I will be in Geneva th= is week and attend this meeting in person.  I will not be representing= the IETF (I=92ll register as Ericsson to avoid confusion), but I will **pr= obably** be asked what the IETF is doing.  Much like what I have already presented, I think it is useful to continue = to educate the ITU-T on what exactly the IETF is doing in the Security area= and also the apps area.  The underlying technologies that enable the = technical solutions needed to protect everyone on the Internet are being progressed in the IETF.  I think i= t is best to point out that the protocol work on such topics belongs in the= IETF.  Maybe if we repeat that enough, the message will get through.<= o:p>

 

I have some material a= lready.  If any of you know about material that would be useful to inc= lude please let me know.

 

Again it bears repeati= ng --- This is just one of the =93big picture=94 issues that the ITU-T is w= orking on and asking the IETF about.  CoP, IoT, SDN, Energy Efficiency= , and Smart Cars are just a sample of the areas the ITU-T is looking into.  Asking an IETF participant what the IETF = is doing on any of those topics will either draw a blank stare or a deep di= ve into some bit of engineering minutia which doesn=92t really provide the = breadth of the work going on in the IETF for a particular topic.

 

It also bears repeatin= g --- At no point am I representing the IETF.  I don=92t register as t= he IETF, I=92m not speaking for the IETF, I hold no IETF leadership positio= n.  What I can do is report on what the IETF is doing and advocate for the IETF to be the venue for any protocol work t= hat needs to be done to enable the solutions above.

 

Please feel free to br= ing anyone else into this discussion that you feel would be interested=85

 

Thoughts?

 

Regards,

-scott.

 

From: Euchner,= Martin [mailto:martin.euchner@itu.int]
Sent: Thursday, December 19, 2013 7:56 AM
To: jcacop@lists.itu.int; Euchner, Martin
Subject: [JCA-COP] announcement of the fifth meeting of ITU-T Joint = Coordination Activity on Child Online Protection (JCA-COP), Geneva, Switzer= land, 15 January 2014, 18:00 =96 19:30 CET

 

All,

 

Fifth meeting of ITU-T Joint Coordination Activity o= n Child Online Protection (JCA-COP), Geneva, Switzerland, 15 January 2014, = 18:00 =96 19:30 CET.

 

PS: The draft agenda will follow later and separatel= y.

 

With kind regards

 

Martin Euchner.

 

Advis= or of Study Group 17

Telec= ommunication Standardization Bureau (TSB)

Inter= national Telecommunication Union (ITU)

e-mail= : M= artin.Euchner@itu.int
Phone : +41 22 730 5866

Mobile= : +41 79 592 4688

URL&nb= sp;: http:/= /www.itu.int/ITU-T/studygroups/com17
Office No : M.415

 
Place des Nations
CH-1211 Geneva 20
Switzerland

 

--_000_EF35EE4B92789843B1DECBC0E245586439823DD6eusaamb105erics_-- --_005_EF35EE4B92789843B1DECBC0E245586439823DD6eusaamb105erics_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=13895; creation-date="Thu, 19 Dec 2013 12:55:36 GMT"; modification-date="Thu, 19 Dec 2013 12:55:36 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAMcAAABVCAIAAAByyWfZAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAANexJREFUeF7tfQd4XNWZ9vTem8pIo94ly7IlF2xjGxcSg8FACC0hJKTubpJN SMizm0KSTdg/fwjJJpsNhEBgQyBgmqk2uDfZlixZsvqojkaa3nv/33OvLMsSEIMlr/2v7jOWZ245 99xz3vv17zvMdDrNZDIZi9viCMzTCGQyGSZQNU+tLTazOAJkBECkWIsjsTgC8z4Ci6ia9yFdbJCx iKpFEMz/CCw8qqAJLCoD8z9xV3SLC4kqJjOTSqdDsUwyswisKxoF8925hURVJsNis9L+cLzfxFyE 1XzP3JXc3kKiitYy2azkhDsxbF20il3JOJjfvi0sqjIMBkcjY/J5gffaMskUQDa/vV9s7cocgYVF FSOTYbBYvPJcRjwReP3EIqauTBDMe68WGFUM4CrDzVHx6gqCe1rixomL54NEd4Q4Rn/m/bkXG1zI EVhwVNGdFzaUcbJVzl+/nIknP4gPAnAzN+o0JogdsUzMOrbISRcSE5fe9mXxAxJiwwwe6rD921+U d1yn+tI2ELDprlMIIf/S6UwgEg/FkqlkOpXORBOpeJJ4KVksBo/D4nPZbCaDzWLKJXyJgDsNzZlN XfpwLLZw6SNAKMDl8S6TG8USjoefD7x6XP+nbwlXVBDP9jmS4w1FLc6IMxB1esPOQCwcTWTSDA6H JeRzOBx2IpmMxtJxCPuZNIfN4vPZZbnyAq1UKuZp5UK6kUVsXToa5quFy4cq2sgQ7RqduO+XnGyl /unvcjRyYMHqjQxO+I51T8bj6RK9vLZQVaCTiYS8DBCUZqQBlkwmlkRUBRN4iiUzVlfgibfPBqOJ lRU5SgkvTy3K1YgLdVKKdC1Ca76AcUntEGvSQw89dEltXPTF5GYaeTqe8D71NpPLDVYV9VgD+06b /rS71+mLbGrIL8mRxxIpqydkcQXtntCEM2jxhH2hBNhjJJ4adwRGLD6XPwa8xeKZbI0UHLF7zDXh CvsjCTaTKRfzL14VuOheL574kUfgstIqmlxlLC7XV3/jO9HV/vlbjlRU8hNxSFhFuQoem5UAUWIy k5kMm8FgMRnYDwuqgMvl8ZgWR7Df5JZL+cvKs/N10pZea7vRBtpWZtAAiC5fWCXmVRmUS0u0Yohc i0TrIyNhPi+4rKiipXJbJHHkZy9qH35cUFTwzp03OIsL71xVAEBIBBChgCXSJcL2GHAhMqPxJD4v HTb2mbwNxRouj4VzBHyeUiroHXFkaaQiAbfP5FFKOHyBIBCMacXc1TU5OqVwUdKaT5h8xLYuHwek eBNzYMILfjeSZpeL+XnN7bJovPzmFWvWlLEolQF6XyKVTuAvpQOS0GdGRiERjFj8JXrF3ZvK5RJB JJZy+MKgT+3DTk8oXlekFvM477SbhyYDMongRO8kaJheI9EqpqT4jzggi6fPwwhcJlTR4k7fuPuv BwYUQt6dn2oqqMoOHuvid/bmivm8tTVMsSgDkRyRqSwml82CYE5Zqoj1gcVknh1zo4XqAhWfz1VK hQIue3DSMzTphVDV2mcLR1JVxVlgoMe6Jgy5cpVU1D3mlgu52Srxopg1Dxj56E1cPlQNWXyvHB+t MKh2rC6W8LkZLRRARmJfawLhDEK+cEUVh8/jMDLAE21Jp4BF/D0CHtvujYRiiVgifbzH0jPitHtD PB53ZWWOTMwPh+NyuUgp5G2szwWJAuDW1RsYLPaJbotKwtcpRR99TBavuNQRWHBUUf4W5og18NKx oYo85fq6PPC4VCrNFfE5OZrMuCvefjbWZWarpcKlpTBNQU5PU/ZR6He4lMtlgRv2mzy7jg1ZnCHg RiEVVBZqlpbq9FqpIUueSGXUMj5A1jZgl4t4kw5/KpOpK8kOxNPNvZMGjUglBSu81GFavP4jjQBm fKE9Nkx3IPrS0UGYy1dX58SBKcr4mYkkOIVZnts2TMpzGTar56fPBnbuJ7k+JHCGSaR2BhMBf809 1mfe7cdVW5YbYF7PUYq2Nhmy1RLY3COxpELCR3tCLuvaen15kW7CFTw76vKGU7FEssKg1iil75wc s3lCi6GoHwkT83LyAtqrKMN95uWjQ++emfjMlhqRgJPKMAgNYjEhOgl4LCNTNGj1Fo1Zkk5XvG2I a1ALq4qIMMRkDox73moe8YXjhTmymkL16hq9RiFs7p4cswVzVCIBnw1LOxgkbBEOX1TIY5flqVQK 0YDJbbL5QMPEQq5aJjw7GYxG40U6CY8LIri4XaYRWEAOSNsRhi2+5w4M5GulWxoLQa4IpNjsjD+Q 6jUybe6EPxzhsoV2L99sT3j9sZZBXr4qVpL/buv4mQF7aa6isSKrpkAl4HGisaRKLoKoNGoLtBgd kUhSI+dzuRytTHB2xIlmi7LloWjc6gwJBAKbJ8zlsCVigVDE7xiw6WT8HPWi5H6ZIEVbJRfKD4iW 3f7Ioc7JDpNXIeTevqEcbAsUgw0rpcMd/Y+/xfecZLBFUbA9l4/n8CCyPcOIi4r1pnu3WTesaijP KtSIgEyKaTKIzwYiPIflDcaHJrxjNr/dH4Fgn5+lONZlVoq4OVrJpCNUmKOsKNYNjTm6Ru215Xl5 WfKWfouUnbrjmiKNQrTo0Lk8yFooWkWr9F1j7s4Rd7leEYokKw0qyEmAMQcRCHJxxuaJv3AgZbFw nR52OAbGSAVTsZMeH7N9sKxMVXxdfZLNSQKJ5yBFohiSGR6HnaMSKmVCCFUKmQg38gRikLFytbJy g6YgV8HnsFVyIThj16BDIOAV5Cqbe+35KmGeRrIotl/1qPIEom1Gh1Iu4vI4dneorlhDCeowmWcg VLELszJuf7KtD5FXsEmde1pgkcWPxRitA2GPn1dTzFRKoQPCBoFLiRyVJtbReDqDWAadQqSW8BEV o1WIwuGYIUtRUahG4Ewc+TwMplImckZSQ5MeWB94fJ7d5S/UiiVC3vSwEir9wSibR/xNN/Xhd/zw +aZV6Xns1YLCawF1QKs7NGwLVpXooPwDGXQ4FQaHDbkqnmCqFII7N3Fry9IMECocnf4APayY2xd4 9GXn1x+NnOrOkKgqBhggaYIaWdjcYVsHfYoCRAwm/DaIAwyE44kEbBYZqI+RBES4DHyCQhbDOO7U yYUjtqDNG545lCCchHZOhZvSMz41a9T/5+fw3LEp+8TMn9Pfpyd87snTTeF2SfJiUeNwfqN/zthD D9SMPfiJnsIccxUVxJh/ywJGDEYjuz/G47HFfA4fPI/DSqQZXA7yuJhwxqQwm9EEd2WN+Cs38eRS EDM4kGd+eDwxN8OKv90S+OqvE399KxWPpZls+AWJ15jY34nxHR82LKVMJqzqUC0jySRuignIpDMQ 3vENt2usyfMGYpPuUIjJ6RrzxoBmasPk/vyFtof+cgqxEpDnMNUJEimIrwQ6dl/0ndYxsyNAzz7u idCu6WgwaLX4AB/UZJN8R1xLHSVowE+cjL80zpz+yLttpjF7EF3b227+l6dPoHG6TZg/qEboCB7S FH6SoZkKF2OgWXxwEOcf7Z782u8OtQzYrxZ6Nf+WBTy51R1uGXBUF6hzVSIeiwXXsVrEwWTz2EzI PZg9PpsB9wsnV8cr17OXFfE3LeFtrLvgs6mev66OU5HP4GRYCgk3Sw0+iBYEXFjYiNiNtwFmLSkf tI/VNeIUCLg5IFrJtFzIkQlYEi5LzmepJbwcCVevFjlCyTGrp86gRLQMJhsT/7tdHaP24I0rCwcn PHtaTe1DziNGd5aUi7Yf3tn+i51tHCazqSIrEEm+enx4T9u43RMu0El9kfhf9g/Ag+T0RrIUwleO D7ePuA53TY67QhV6BQC9u3X8tROj3aMurVICYviz51p/+nwrnnpFRdaILTBg9m5Yos9k0rtbTLtO jvaMueGe0inFuPvbp/DT09xrheNcLRMYJ7zPHTQe6bIgBKgoW3a02/LnvX3ranMr8hQLyrzmpXEA gDMvDc1qxBuIOjyRzU1Fw+Oup3f34kXEG5hIpAxZsluuLS3RK2GcfGtfX4fRyWHzGXw9/YLOtIET soOu8TJJf0J70naHVF2SK8cpB9vNbzYP08wUJOLTG8uXVen5PG48xQRbBNHSSHnvnRw+1mUB6IA8 aAH3bq1SsxLNg3anv8SgO99T2h57oHPyv14/+9nNFW+3mKL+4Bc+UY0XIRlLYbJB7f7wVvef9vSs rc5++ZAR7oB8reynz7VU5ym+fctSbzD2yKtnspWi4izZE7t7sFMq5L55agyQbemzmhzBh+5ZAYuG NxyH5Af/ptHse6/d/M2bluw5bf3li22fu77qWI/lteMjzzy4dX+H+al3e29aWbi/YwK23J/eu+po t7V1wI6QxtdPjlTnKyFHIogDcFyIyVqINueZA9KMIBQjAg6s4aMW/1N7e5/Y3/vHfX1Pvde78/iQ 3RXicVn+YPytU2NPvtn5+Ls9j+8beHxf/+MHjY8fGjz/OWB8fG8/Dj25f/C/Dw2NW33w5wA0rUbb H9/teWJf3x/39f7pvZ6uUTie4SsE/UojUhQ0DLTrYNfkH946+4d3un7/Ttdju3sQ/Tc04XaGkkES ykVJLRR/JMSTQfiOQibYsjxfpxRYoxmEodYUKGViHuGJqbQ/FI0mkvFUJksjgQ0MvA6c9671ZZ9o KiD8l8GoylOsrsoGHfWFE90m994zpjDi7jMMxEnDg7mkWC0T8fECwAiSyDAIp8RfwBnR90KegMdF JDX4HIicUszfUKfHX18o7g3Fdp82IZ4MRC4aT0UTabwgiNoH618IBCxEm/PMAYnUkkoP24NQwcqz ZUDDy8eHpmTUZFqjFG1pMOTnKGKxpMnuD6fSiCc2aMQqKR+TEYsmIUYQsTyVBg2oNSjzNOJcrbRK r9i4RK+DaYDBONE9eejs5NRApDJbmwrry7J6x1yYHa1cBNRopfy9raNt/XY68A+zePu1ZYgjnQgk V5RqyrIkmBt0EqwNoaeNZTogSy0VgNkJWMwavawqX6mU8gPRJGwTdQVqwAKyG7Jj6wvVm5bmgVyl WcwNtXq9RoyHQk+Xl+pKc6FoclZVZAFBwCJs+g2l2mWl2rpCNMyDVoGmlhZrAH3E6ly7JA9AhF33 7LhHLRd96foqmHkRQ5atFK+szIaHHaFmuC8UDsRmVOYpGko0TeVZXA4T8sKqqmydgoSOXeEbkUbn V7VAg8FIHJTc6k9sXWY40Wm691d7E5hbzF4sWVOs+dUX1zTW6n3+KIRVMRWfjni9gTHX9/584uCZ cSTTECAk09++reEHdze5/FGXNyKX8PRaSSwFAsN+9MUWSCpTKYKp9K++vO6e62tfPWqMZ9i1RVoM d12+7Pt/PPTEW10MHvHScJnMvz64edAZfrXF/Nk1RZ/fVCYRnbcvzJgeomHSQaRzuDElTlM0mDp6 PkCe/k6Tv3MCO71nKkGDboq2vk5/pyVuQrCovecvPHfvmXki1E3Pp41cjCGXbv+jXjWPSEUH5p+o Qn6KxDJcPp+yHF0YMMAEbNg2T+SNEyMkaorFhN0BkjePeF/Axc4/mlTAEUv57mjq1ID93faJg13W frMXIgsJlLlwIwoULkS4H/WZNe44As5RX1skFIsgskD2wtWxeBKROQMTnhGbH82aHUFiFaPAQU0J cV/CMgJM4wu9mwLK9K2nDAPnOkJhZ+oc8pXeP72HbpTeP63EURE/BILTh6bHapaihx7YveFRm5/u /NS9pxu98PdMSIWiCXjM4N2/8Kqpbsy4bvaQXjrCFgBVqUwwGqffbXCbWV3EjjGrLxhPVRfpQpE4 RgpYIZaYC2V1oCPuDkJzvH5jNUJf+kyugx2TkJBmtUemmugBBBNQCQlvmws7yswKAwcchST9i8GA oP38YSOo41d/d/DhF05DcYNsg/2uQJSeOZBb7P/bQWOUOh/ceXpuqMfKkJCvSIIGD/5h/rCHuJYo IgFhCO3g6fAdHBAf9BIAhfcJ+9E49uMSJKgRBMNRlYBwRexngDsdBEvOjCeD1C3w2hzptkIlRLeJ gJFOw9GJy6cNH55gDKIYDR2Y5V44ZITSgBtZ3OFn9w+cGXLSYwKJDZ54+jRwapyAftKdmTtolwis BdEBiagbj6dSxHY3s38gSCar3x9LQm/icNlR8kSMeIZocxBfzp8J7HDY8T3NkTEX894bigs1hdky szME6XWKqMw4F5OHREKBkO+JJDyhRIkWbpwLxoQEwzMYMMRDIYTIjA3C+M0ri82O0K6jgzfeWbhx aS4At/PIoMUbYWUYN60u1MjhtHaB3cXiqa5R1972SXBqWOd3XFMMcysMCkiFhWV287J8pJod77Ic 67FSxjn2LWtKoKM8/V4/+B5goZIIMACBcOzuTRUiLufZ/X2gialUSiriE1UgHL9vSyVevJeODVfl q5CIdqhj4u6N5d5w7JVjw6DWgAskv21NhcAlMAFFYdwefOPUiNMfRTAZDA2QulqNjoMkNiOxtEi1 ucEAx+sDfzxalqdcUqTGk8I8FqGQ+nbLaLfJC85g0IqhbLr90VebRxDr4QtEK/OVUD4gMs5gFZcI qgWo4Eh4GSM96QoSrFw4wWBGeOkRh04MfskUFfhJ5BCS/DCT/wFsiBftGs38+1Psx16Ku70xoQBh VcjWmiJ+55Q5XGW2B5BRaLQG+sdd/WYX6M0FQ0IkIkInJFKhQi5GB3AUinpdoao8Vy6T8JeV6SC2 H+ma/Ocnjp7qsz5/sP+N5hG8xETYZzL84QSMpU/u6WodtP9mV+e4M/jC4cGH/nIyRyE0OQOwVE26 Qv/65+YDZ80KMf/hv51+4aBxwhl+7K2zr58YwWSD4Bmt/j+82XWww4yO/f7NrjdODsNq8PMXW5GF 9sTb3QcggHrCv32980j35Kl+23+80eHwhjtHXb98pf1Ev31fu/l3r3eCUnaOuGAzC0RSzx0y/t+X 2uUiPiwXh7sn0ebOI0P7zoy/dnzo319om3CG8D4gQ0QjEyglfJhv3m4dHbEHxh3Bb//xGGKyWYz0 vzzdfKDTbHaFHn3tzJlhgshHXj6DsMrZssql4Wr+OSAUHFCpfrMH2taUp+ZcFyFyFeTI1i4zDFkC CJYCmwMEaenrggodlAGdCc3Hb0v94m+Znz7FMI7GeTwwkhmZ9KRRWBHh3oMJVCrgIi/CoBLBighO OD0mVK4OwSAPYTMCpmBGnBVxEjEYsIRTOONmK4WYJJVCqFGISYcQ3MxhoXvZChGXyw5E08U5IBAc eBgNGqnDH5MJBXq1FPcy5MigAdiDMZ1arCZZGAwYCNZU50Cny9FIbl1TolGJYMzEE6qVorV1+lVV Wfka6Y2ri3E+aIxKKijJlrX0W08b7QqxAE8OAyxusX1l0YqqHGjFcEzxeSzQEhYTgdkCWF+9gQi0 zpIcWTiWGpz0OTxhBJCxOWzcAopncbbM4g7BrM/i8UQivoBYJJiFWbJ0KuMPxQ1aqYzoKxnADiTq mupsVByAPHppKJp99fxbFuC46zG5D3dZ19Xn+3xB2Kan/G0pYlm4oalwWXUum8NFBLrDE0R8AdiE zx850DE+NOGDcEQ6mGasW16wip8OHOpmhEPMjhHGwFhCq1BU5rcY7YegKlIwBCLW1ekbSnQjrlCW SpKXo5JLhCUqwRsnhs4OOuimALtPryvNCIWdo+7KLOGSQtW5CD4m7EkI4WoqR640T68WG3TSPK0E swLzN1yH4JgwEFTkycvzFVD7i3MVm5fkwkBQnqfMVgjBWWCAAD6Ks6VwIQDsEIZuaCoAi8R8q6X8 pjJYHOSwU9QVKNFsY5kWjajlwuXFWqTzV+erqos02L+sVAMQ5KqgDbOBrY1L8+oRsyPmF+gky0u1 OWpRbaEaaSBQkyvzlLBWlOcpkD4EFqmRC1dXZsP+AuNfmZ7YzMAQqw0qdBt3FxDMyRG9iFeisViN PuNC1K1AKNE9G8vX1+nBpvVqCR5HrxKDiZNUJZJHOT/bAlgWKGnw8NnJn7/UfsvaMg2fffcv9py3 LJRoHvnCNaVFOhgk3f7w8c5x8LqtjUUiDuM7Txx599QYhGrCDhPpH9236puby0yPvcF+7FWm1Q4Q JUryDT+/f6dQ8+CzrX5fhIAmllxZl/u9W5cW5cgZXK5AKOCzGAdbh3/8fItp0keMFKl0YY78sX/a EOJLXjw08LlVudc36PHinjMQfMggTlkH5pwxe/98iLofdK8ZBPcDSy3NufaceWJmzy+mkxdjs7hI 0M2/ZYEWeGCs00r4Xn8E78dM/QL0BXwHhnfIK6Ar1y4rhGGwrc86aPZQ0ti5jYAomVIp4p/bnvzB fZmyQmIgGBoN/OL5NYzwmqUGRgwaUAYQPNln+/mLbS8fHz7ZOX7weP9vX2r5t7+1mmyBKbtXPLW9 MV8gwstNVCyFBD7JqdSdATPJ/cJN3IFY57CLUqlmbsSMNO6Owq6BMjUzDhBbwMwJOGe+Ijs/7ka1 +GHbh5ww5xDdvws39P/v3WIeJXUyWvMvV6FREZ9dqlcZcpRQk4ln/lycC7FHpxnQRODVALAg6zRV 6UsNKjw14ezT4TBU+EE6Ek+wuPEdm8IPfSm1vJrN4Po7jLlH2/9hraGyJo8RjIMD4h0+3WP52V9O fuep5u/8+cRvXmwbmfASQRsGgmhyS6Ph0+sr3AnmoNUn4TKQikjhA0ay9G9fP/vE7t5QNNlmtD/4 1HGkEOJAJJaAAATNC5MAuBjNnr1t41C+cAjC2aQ7gqAx2uQEOMIgHowmveToHGPGRb7U//+eNs9y FcUAmQIO2x1NOsJJDY/1XusYm8vmQt1jM/NV4o0N+UKJ0BeG045ESsFOBJEWJoPmjokhhx9SM2AO AXNjfV5dWbbNA1E1Ey/MjVUXcTx+rtEU6R8vzZY23bJCkqMOhGJOT4SBJmCeiCRQpoHML5xwXPay Yu0XPln1pRuWRDmCUX/i4EljnU6wuSEPmgR6CKD/eldHJJ7evrKgyxJ8/J2um1YUIJjiJ8+2NMPj 2zwy6gjWGJRtA7bdLWPrl+TGU+lfvNgG3W1PK2KbI5CWoJ09+kp725DrbweMfMhnObKryEm30GCe f7mK7jHaPdFv290+cd/G8rZ+C4gHPKlwh8EGg6DNiWDSE04K4NxlwjeTQZ5xnozjdAcsvqiAQ/yp MM9AfpTKJF2TQSI4sFgwNLAnrfI/7xL9dbdQxJNvbYqur58sKRzjCc2BJEhIPBIHHIV8klkI16FK JmTweM5YxhZInjFaWs6O/eT2pTtWF9LuFNzitp+9A6bw1Leue6/D8uATR3Z+/3rkvm7/yVt3b6oZ mnCBOb72o227T4//ZteZZ7+7tWfU9ZPnWn50zwoYIGBi+OuD1+86PfFfL7V8/54V/7mr49ranF9/ ZR06OI+iyUJP/IK2j3mdf1pFo4rDZAzbAuYI1DDuoC1QWqgLJBhj7iiDB3MlXn4if8IkDg8tgBXN MMRioVopVSjESoU0GE8jSgTmRxafh7BgiEQwqcYUCl9DVVou5rYPRE93s1uHdb3D5YMjVR67oTQ7 t7GyuDAbUeparYItErmTrBFPzOyNdQ9arA5/RZbkllUFiFuiHXqIHvSFYse7LScH7Ic7zMtKtLev LwOU97aPIx4BAQLoOSwCMOpAc7x5dZGQx2nut4FBmz3hQp38xiYDYDfpDH51W03HkFMi4m5dboCy uaBTdRU1vnC0igTF7umwPNdqgeLda5xkcLhQiV0O3zXLSjiMtACMDoimyigAWvgxLS5i1iHfePwR RCYhrCESSRiyFSUGNZeZ4fQP617dq959KhMIU6bTJC5kcfipgiz3xuVD2za6cnIhsiUSSTRrc/iG zS4YDGHj/nST/uaV+XBO0+QENBLOkI4Rl80bgY5NFGyNBP4Q0KQyvRyivSsQqS9So1YWgh1gpAYd gmXSDm7LYtYVqKCNY7/FG67KU/ZPeBHdVZOvmOubuopwML9dXShU0eQKQbpP7h8K80QQnIZMjt4x N6L21i8rzqSgGIIVEZsTF/5mOr9mSnkmsw4ZBWZ3iMNIc/AHws6eUUN7d/3gmHjSznEHWCThYdpm j/PhoE2muPxwfpb1uqbBNY39Gb7VGUQMXY5ODmd2POD/yqZS2Gzm6G4XDuYco8GFvsmZJ7+PfWF+ J+aqbm1BUQXuxjhwZvyvJ8ara4pTicSJM6NOl/+GDbUw003FFiCNeYYGhblC+B3tu8nwuIIxc/6B o5LW/uiQDXn10nSUqPWIOH4/vRVSOhvY4vA9KkXbDWsnNq8XqhUyIbdrwLKtWrVjZQGcaLPkHsp3 T6Zv2l5PsE4DlvpCU7WpLx908oUtXNVomK/Oz7+9arpnZHpYzMZyXWORcmDExhfwivLVsXTmRJdp wh3yx9ORFFX5kyjtUx/KlMWIpRlxWB8SabdC4WLzeMZxtdOuSCOOk5tGxPEcSGHeASmi2TF5aS43 sqyMs2apOhfBczyz1V8iZ68uVc+FFAEThaeZLiD6O72f3s5/+aCTL2xhvibmam9nnqP2Zg0HYIuK CX/aZ+SpVPDVj0+4+XwOan4W5Kr02Uoum5i5ab8yKXWNrCyKtxAhC99J+FVc2dFV/uI7yrZ+JBJS kLrAX01ICS7jciLZCsequvENq/xFhjSfD7kqGI5bx21fvq4I4ZrzbOO72ud8gfu/gByQ7jnFQZj7 OydfaLWg0JTdGYCsA2/U4JgDwlMJwjKEJCB7KjhuztNmqNwsocNR8PZ+w1vHhHYPTkE4AY0tSPuh Qp27rtxVV+6uKI5oNGkB0fI4JBMrOThk2dGQvX1FAR5yUedfYCBd0PxCWRZm3gT3KMqS8hmp4z2T CVKFn5GXpdAoJQiQM47YAAIBAkHp5L6ZwTA0KClSlpRIHHVV0eoCrt/Psnu4KSq8ndIhreuXG+/c 7lxah+JohOMiGZCBVLv0yIhlXbn2xhWFUPEWIXU5IUWRkoWxV83lgwAWzOuITEfcHNgfaI1KJlIq xKhjNmnzEeYHPsZmI9D4wkgrKrA3TZLo/Trdibw8l0qmiyX4gSArmQC/lA1OiF3OSLYmolETIwNl lRgbs68tUX7qmgK4+hchdZkhdflQhTuB35XlyJDF2Wf2oFgjIqIQmYSgFL1OIRHxRyfcNleApAKn MgiOQqoJMf+ck6CQs5VMpAZHbO5Igr9mWeTahoSEzwnGeKhTFAtLh02KvrGUmBvWqn1MltXq3lAi v211Icyni5C6/JCiUXVR0jrlPp2fmPmOIcdzR4ZiPLFcIUEmMUKQweSAuWAoZhxzBIMRtVIsk4oQ rgls4T/EMoTCsZEJTzgSKzVolAoJqF2amZE5HPkHjmcfbpeZrDyfL8rmDn/imuYldStvaty+qmh+ +vo/MidX8k0v7jX9+6iaxhPqAiBcOhoDNfmYcYNEt8tkEP+KkgZvnx7vccW5IiFqEmMPKfUCbDFZ yWTSNOmZdPoBKYmQD8dtIhYHpGCYqC3PAVUjPJvUcYANAsaGtNBul+4+lnWorTIQ0IZ9rEK97Os7 GDeusSgUcAcJ0qlz9ib6nZhPsFHJxP8rlEso1PBZIWcT7ziF+b/z3H8HVXRoFNb/QMh925ADLg63 H/kBxDj0MTa0RhIBhDykfd68ogCR5vt67D7AlM1TK1EZj0vHAIFuwUMCj03fsNVkdiL7RKGUokAC qBcsWyTfEuslUStyIQ/C7ouE4onrlKwv8hOR3S2Og2350XCqvnR/dc1BbZaJLwQAuZnUuTi9eUUV EltnBVB/jEG54i+hTNMslPRFYv6KymxU2jFoJR+OrA9DFY4hYuTd0+NPvdvzTqsJNajpJMtLHYdM Rijm3dhU+OVP1iCkBH60M+NeZ4QRSmZQshjBvhCowA3hq0FqilQsLIYHkMMGE6QymeLhaDwcSSBR HcEzWikKPooaChQIDu6zBf/8erv7QHujxdJos+sjoSGl4tWsvGaVzi0QkZ5fRXV6LnWIF+B6yufA 5XO3Lsv/8raaLQ0FQt4HKtcfiCocQFL273d1/sdrHWaLDySCzjmZnw00J57SasQ3rSm9dW1Jda4M ofvDjjCS1lE4b8jqRW4kgvtLDBqNSoLMOMJrUiSpAR5DEZuJoGyEa+dKWcgsl4t5SKzYeWwIJT08 SHYDiUalmUhgtcN2jcORlYrZhIKTMs0RTZZlEVuXOHm0zyGe1OikX99e/61blsDT+r688P1RRbGq zG9e7/zhMyfAYOjU8vnfSGpcWq4SbajN/USjodaAcrK8WDJpcUcC8RSLw8O6ImBzEOehDyLBBDYt EYepEKCMrBDJd/5g5Myw68AZ86Eei98TJmHs07EoUCNRuT2TqvN7VrkdWfGYW8AfFoi6Jcpxgi1C v+f/cf73tJhIQYX/17sav3d7A5z3c4H1gbTqvbbxex55z+nGbC0MpKbnANhCoDCHlZ8lQ0QKaleU 5ciRW6JAkDL8wZh/SnYBTiDje0IxszOMZPZeswcpcmbk5ICvIYHi/WOb4Lsm8BLEoyu9Tm0q4edy rXy+jSdysDhUfNfi9nFHIJmWSfl/+c7mG1YUzK1RMBtVlAGB6fJHvvDofuRJksm8PLFoJFaKBLQT IiLiYoVShZjE6yEgGIQKdiwSJB5BinzMBTaHPHF0FCXUQZ+m5bzZwSkzxgvnAF5MZm40JEvFXVy+ iwVH9dWJqg95zI+LkAuum9s+TdbnjlYitaEh7+kHtiDJbJZWOAdVlMvsvfbx2x/egxJTKG73/l0F COgcB0wY6MScYgof5wEJzybZDYQ60o3TrIp+KmqNN/KX/sza6CRJ0ttzh+hrZ+kWdBQXMQdcXg5I azmkoEKSDNdHXVJgqrNUlRJ8x3u+QIWsaMkJd5kxyNSyetgzh7rASMTj/Pd3tuy4pghuuFmxa7PP Ri3qY90WrA76AXgikSt8NquuSIPsW6Q25GIFoks326TSqPL4hW01KMtOL2TDg9dZzCMTgMAGAYew OYh3IE5zIRVL3rCy6MFPLcNKzITa0Vs6jQzg2S8F8SoCf5cRUqSud0qIbifTSGv++m1LsWTruRfm 4l49iAcISaRqcd2wovC7tzXo5KIF0WczGajfX9tWc//WKlLnklRhRQx46r7rKr51Uz1S7MmeCzdU cDjeZ5mT9EYRgVmnIidp0OydeidmPzjRz0v18t9/bd1j/7gBPfjK9dUkpZoySiLnkxAbOmQJs4sP Xk3sBGujv9CJWTgHh8jJSdJR+ksmgzh3MYeFamkiEe+BTzfcdW1Zyh/VyIQ/vrvpptVFDCqbaupC uilsGHHk8cWTt60p3t5YAKxP4TsUv3VtMbJPs+RC0vh0B2gOO3PDIbSGD1XKlpxJ/6QLDxFdNTl1 U/pa0tS5/lPlYqirzj0O3Sv6KjQSTaLw32c3V3/jpiUYNxnsuqS8HwlcpQaHuoqequlb43GmXwzs D8exStm/3bsSUc6QMu9aX4ocdjcybKdHgNKmyc+Zj0YPMiFsFHWkG8SZ+EJVnJvqHn0JfTLVCFL/ v3h9NTKkSeUckvqGdYcZd2wob6rKIsLTbOMcMQJCWycVb+Zss2vC4EZRoIQKu5y9JdIatfiX968p zpL+6uUz/ZM+3AhVOrCwzB3ry1AUtcfk2Xl4EOuKbK3Pg6cOVTFD8eTpPtua2hz48p49OIDqNlvr 85Eyj5MR+t035tmyLB/VDZ7Z24fEVFBUvJOonImSaKhfGI8mkDb+wG1LW432gWF3r8N/67Wlqytz IPb97cjg6LjnhlWFm5YZ+sfc9YWqziEXahWDUEO5uH1zxc8+vxpGB7s/+vyBgdoizbamAhTq2Nc2 9l7HxFRlDvIiJlfX5OIQctvfOjmKiq4rK7M2LTUgUAfFMJoH7A1l2sayLBSGLNfLOgYdu1rGVpVl l2XLWVwW8s1R9+Kd0yb0eUt9XmNlFsS+nYeHhqz+pUUaJFBIhNy+MbdUIvin7XUZZsZo8bu9YdRy Hrf7b15TjGLxsAYrpPw3To21dE/C7LupPnfdkjwEr+JGO48OBoGGNAMLZPz486tubCoQCnky/nCW VEjGZ8cSlPvaeXRocMxVmq9EXEZRluxorxVVX5DeCNBUF6qvrcnZ321x+SJ3ritFPD6Ga3llNnLR 3mgZzZEJSekHhehQh3lXy6heJUHlSFJeGnWgown06sSgHbkCd2+pREr+mC0Am+f+dhNqyLwv2w2E YBR/H1/LXH45FX8yG1KoGMtmbarN3VCv/8M7Pf+9p/dk50TLaRNehCe+uXFNZRbK531lWw3STooV gu99atknGw0Y8QduXXr/9dVSPufeTRW3NBqqdJIf3b18dblWJeL/+J4VO1YVojwmrlpfm7uiXHfz 2hLIPaiiAabXOmCz+SKIdAjEks09Nizp9tAdy++5tszuCG5bXnD76qK7ryv/wT1NiPVrLNWh0EDH iDMIQZDEwmQkWDZCwj816Ogb99xyTdHDn18l4rIRMvHzz61eW5WDSj/kJU6lb11X+puvrMUS8wNj bmAClP/H9zShzrVBLXr4vtXVeuTSFH3j5vpcGR8ZEA98qqEkS3bPhoqvba9FpRDUOPjHG+uKtJJv 7ViCSrVuV3DLUsMXrq/e1mj43dfWotqx0eTFTEjhPteIj5wxx6PxzQ3519bnw0PwzZvq71xXBnbz qWuKP3tduVjM//Fdjd++dSno2Zpy3a1rikleLvVKi0U81HQYcwabey3QYPRZUoc3isUQv/bJmi3L 8or1ioc/typPJcbSiV/fVrMGj0YRZlRl+tyWqnq9fF2FDvUKsSAjKh/ff31VvUG1sSr7kS+u0SGB LpP54V2Nm2r1K0t1+HL/lir4NlCLIZZIYInr+z9Z/c83L4G1+ZqqnHytpMfsxULF7ytkA460A2bW NhtVqCACskFOnUWrwHf5nKoCldsXbe62kHtw2Xyl8N4NZciiefSVjif39qHYGeotFWTL1XLBrqND x8+OgzidHLBhBVukXsFRXG5QwZr57N7+MyPOeCK9t2PicJ8F/QK2kK8CPwzAhAmG7eCpff0gBuFE ElP+2zc6DNny+7fWgAAYdGLUfsRiSfduroQ++MNnT7aZXFZ3BMlhhLNAbKRW4cLi8jsPGc+Oue7f VuMLRn/56pkXjw1lKYVFOikVZppBIY2vb6+zukJIqP+vN89afZHPbqmEteKR1ztfPTlSmiOtyJah OpTJ6nuxechIRIIMynIsKdHgnBePDZvsAcg6dfmqL22rkYp5RXkqNgfZH/5/2FYDfvCDv7Y8+V7v m+3jw46ANxh96t2+9jHP0hINjL1QbHO00rdPm15vNSFJWsrl7FhVdMe6kqf39L54ZBCVbc2eUBRC LYhSKu0MRn2B+NGOidfe68XCiHjb/rKvdy+kXtRFFgs+s7ECubh4dbF8sMmFNRP8RBXAIgZIvMxk QKFBNcEuUQj5llVFeqWwc8R546pi4ACj8czBAbGIi8IkS0u1cIL99s2zf3qlXSzmYejEfC4IAYp1 /5+d7YM2PwoRTsIc+AGyKAraXFDK4By4ZqMKNUbw/ISRzGqIim6AYgjOUpuvIlX0mQwYLRqKtVZP CKWFc6V8eItQExHZLAhyOtZrzdHJItHkkQ4ziuOgMVT0Wl6mQ2nytmFnhUFhdQdP9lgKtRIQOX8o BkvVMAqmReIo6GO2gTm65DJBcbYcZaImJrxNlVkYrwMd5jdOjn71Pw+1Djkr8pVYJ8frCJXmyOH2 nnQHp0h0Mo3yKTBu9Yx7NBJ+cZa8c8hpswcqC1RYEJWAj6LYBqUISVrwbGIRL9QcNqhITZiTvVaP P9pQonUH4hADcrXio33WCU8kP1s+MumX8zlYP2XfGcw71peTD054awtUeCX2njK90Tx8/6/27W43 VxZpukbck44grLcIIkR1sglXuNPkEgjYBWpR75ADy8rB13Goc0IlIXYTk82/tV6PHLXXmocr9XK9 Tnp6wDE1Nak0oI/lWLvGPWgLz4uCeif7rFBKwHawdPmKMi2KUO5tMz3yypkHnjw+aPUT5YbFxLuN p9ixtpTNYb14yAjCdNeG8rZhV9uoa2mZFsMyanKjDgxeLX8gigI1Lf32t1vGfKl0fb4SNevw6qII VnOvDW5W5GQbJ3ykQt/7aJ1EbsNYSUXvU0xmFqpI5WcUXirNkp3X6umnRBB5NPV669jQpP9f71n+ yOdXP3jr0hWFGpSDBmC/d0fjA59uBK6x6ChkjgELqrbEq/NUKOVo80Vr84GzpMMf0SuEfWNOBKSX 6mSjDpjQM6i5M+wI+uNJiBp9IAkcNl7KaoNydXlWDpKa2azaAnVTdY6D8CjC9VEfRy7gQrRCKh/K 93z3rsabVhSOI/TPGZoi0ZmMTsrJUgg21uSKOWzUSrimJveHdzfds77shUODp4fsxHKBdQZ84T6z 7/oVBQ9sX7JtZSEUGTOK+q8o+slnVmxtyP/T7h5EyUPxQTkkrLdUqJMYJ72oeIt3Y8jmz1cIsToB VpAjkhyDAahppQLyeoTjfSb3tbW537mlHkX3xDxuvlKE+u83NxVW5ip5Iv6QI4gV56yeCOo3g0uC SJw02pzROAbw69uXfGNHPbxSZ4YcU0bdNOI7OKCvNXmKDY0GkH9MMMo6VOQrULsCr7EzGEPlAezP 1SGmiEckbrIxfdE4m8cib+mE5/BZ84pq1DjiHeyc7DN5xqz+ZcWa739m5X2bK99pMQ2afahVhIw6 1FkpQrE/LLA44RudxCIaqU+uKPjhPStQk6h/wkOqV861MaUzuRrJmppssKC5Mvjs3GXwPnhOUCnl SK+VKHczNXkszhaMneq3BmNJvEbuYPxwjwWZ79FwIlct6Rh2/vrVM6OuECIOjvRYjJN+IYcJitUx 6sJKbmdGXCgvC110f5cF4jkiWg50TaKcgZTHwY1QLA91zfefnRi3ktKcqN/Vb/GdGXaiUCKYdqfJ s6fN5PbFcrWoyMACSUMp7GFHCLTa5Aqc7rfDwNZt9pC0COrjDpE6j1jq7diAHUVjSElqqeDlw4PP HBggpTioWHi03DnkABeDqD7qDJ40OvATlR2hMDzzbt/O5iEAGiTwzVYTxgxxE++2jaMEGSC1r3MC yiY4Cw61DDsn7cEsLEHB46A6GY62G+2omqxUCEHQkJgKSRnTjNgwUN9xR2hfhxkvcduQ86TRLhNw URrvjVOm7jGvxx2G+op6VwDNr1/tQPgO/SBwWMWiCVcghkcG+TnSbTHaA0oBF9T37TZzr9kLNQz8 NBCMIxbSD/2RsuoBmqgQ39xlea11zIk3N558/eQouo34AEwBDEtalXhX88hje3qguICo7zkzYbUH MKE44UC35fQAljuIwcfXa/K0DTjw4CNYfAX28JniE6UP3re94dNrirHW9SzL0gf6Acfs/vt/vR81 KogUMhOnRBdNoxoHoIPek9qs6QyUJvyEoStBWfmgPtPpfpDk6OWA8IUy4CG5gexBh6gYKbILCjMV WzV1iIqEQfl/0jhsHIiKAUcGh8KSbmgXZRRwEVkDAqhB7Qb0AX5nqjb+LHaNFjAvdPfgNAQBBrEk zp/pl4Sy+OEQxALSc5Kcn0H+Dzga2Dc6hjxXnAsJBXsoIWeqci5ZgImSUMlCFMj0YGExcqJHk15R exDgSi8XjWaxn66/QA5RjdBDgVEh1SthpZMJ11dlowjuNbU5WAX4qT19v3+9g5RJOrfhfDJEFNem FwEgJfeIskEkevQfT4oSN5QP/vxGmSXJ2jiUlZoM9VRQHIobcnEJC1UhIeBiWT08Ja0ckP6Q0ifE kY+HAncmS20Qa/QcayRlnlhdnf3kA1uq8hUX6wekpXoIzt/4wxHwV6IxAVgzfSO0UYo2dmOjTSMz f9JvG90f+gu+0l/oQ8QuP+MLbfKmotfPm3fp82ko0JdMnzN9iO4V3dT0RtuIKa5N7kv3lm5k5jbr 0NRPyoRHKyv0VfQDkmtp0/aFh+ge0j2n2585GjOPTl073QgxJhnylN/dUY9q/4FIArVD32g1oXj3 Bf2krUS0oWf2qJ57tOmRn346+qrznT/Xt7mjMd15+tD0Lehhn74p3TJ+QoNmMqEKwGZ57RI92TcH dR8WCYMLOoedP3m+BYtF+QOUEZJyE16lDrQL8HSF/KDmjCxfDk0Iw0tWQrxQ5Lhy+omegKSxmGKp cMMSIqeuLCNrJnyESBj6WagXj4n6pC8cGkAVZaPFB3ZL1yufAu4ckM4YhCkrBnllPuy0K2TYLnc3 pm08FC0jtJRaD5D6d6UNF9VXSJkQBCH5bV9f8Zl1UPxIvdoP6unfizA+By7U5cE6RFBKYX2hl+Ej 3GC2Cf/83JCe0Mrlh552uSfzCrkftVrS+/flyhsudBVyJGJ0aw3qmkIUhSdL4X0womh6dBE5NjTR ukJmZLEb/9Mj8PdTQC4KVdOPMUvY/Z9+vMX7X9YRuHjO/NFQdVkfYvFmV+0IAFWXJ9bzqh2hxY5/ rBFYRNXHGrbFiz50BBar8CwCZP5H4P8BYDg8ChVIynQAAAAASUVORK5CYII= --_005_EF35EE4B92789843B1DECBC0E245586439823DD6eusaamb105erics_-- --_006_EF35EE4B92789843B1DECBC0E245586439823DD6eusaamb105erics_ Content-Type: application/msword; name="DOC045_fifth_meeting_JCA-COP_announcement.doc" Content-Description: DOC045_fifth_meeting_JCA-COP_announcement.doc Content-Disposition: attachment; filename="DOC045_fifth_meeting_JCA-COP_announcement.doc"; size=68608; creation-date="Wed, 04 Dec 2013 13:05:23 GMT"; modification-date="Wed, 04 Dec 2013 15:50:49 GMT" Content-ID: Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAawAAAAAAAAAA EAAAbwAAAAEAAAD+////AAAAAGoAAAB9AAAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAD8AJBAAA+BK/AAAAAAAAMAAAAAAACAAALBoAAA4AYmpiak8LTwsAAAAAAAAAAAAAAAAAAAAA AAAJBBYAN0IAAC1hAQAtYQEA7BEAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAALcAAAAAAIgiAAAAAAAAiCIAAOIv AAAAAAAA4i8AAAAAAADiLwAAAAAAAOIvAAAAAAAA4i8AABQAAAAAAAAAAAAAAP////8AAAAA9i8A AAAAAAD2LwAAAAAAAPYvAAA4AAAALjAAAEwAAAB6MAAAVAAAAPYvAAAAAAAAyDsAADYCAADOMAAA XgAAACwxAAAWAAAAQjEAAAAAAABCMQAAAAAAAEIxAAAAAAAAdjIAAKIAAAAYMwAAVAAAAGwzAAAs AAAARzsAAAIAAABJOwAAAAAAAEk7AAAAAAAASTsAAAAAAABJOwAAAAAAAEk7AAAAAAAASTsAACQA AAD+PQAAsgIAALBAAACcAQAAbTsAABUAAAAAAAAAAAAAAAAAAAAAAAAA4i8AAAAAAACYMwAAAAAA AAAAAAAAAAAAAAAAAAAAAAB2MgAAAAAAAHYyAAAAAAAAmDMAAAAAAACYMwAAAAAAAG07AAAAAAAA AAAAAAAAAADiLwAAAAAAAOIvAAAAAAAAQjEAAAAAAAAAAAAAAAAAAEIxAAA0AQAAgjsAABYAAABC NQAAAAAAAEI1AAAAAAAAQjUAAAAAAACYMwAAXgAAAOIvAAAAAAAAQjEAAAAAAADiLwAAAAAAAEIx AAAAAAAARzsAAAAAAAAAAAAAAAAAAEI1AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAmDMAAAAAAABHOwAAAAAAAAAAAAAAAAAAQjUAAAAAAABCNQAA HgAAAAM4AABoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAezgAAAwAAABCMQAAAAAAAP////8AAAAAkPXOmgjx zgEAAAAAAAAAAP////8AAAAA9jMAAMoAAABrOAAACAAAAAAAAAAAAAAAMzsAABQAAACYOwAAMAAA AMg7AAAAAAAAczgAAAgAAABMQgAAAAAAAMA0AACCAAAATEIAABAAAACHOAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH OAAAFAAAAExCAAAAAAAAAAAAAAAAAADiLwAAAAAAAJs4AACYAgAAmDMAAAAAAACYMwAAAAAAAEI1 AAAAAAAAmDMAAAAAAACYMwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAmDMA AAAAAACYMwAAAAAAAJgzAAAAAAAAbTsAAAAAAABtOwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAQjUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJgzAAAA AAAAmDMAAAAAAACYMwAAAAAAAMg7AAAAAAAAmDMAAAAAAACYMwAAAAAAAJgzAAAAAAAAmDMAAAAA AAAAAAAAAAAAAP////8AAAAA/////wAAAAD/////AAAAAAAAAAAAAAAA/////wAAAAD/////AAAA AP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA /////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAExCAAAAAAAAmDMAAAAAAACY MwAAAAAAAJgzAAAAAAAAmDMAAAAAAACYMwAAAAAAAJgzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACYMwAAAAAAAJgzAAAAAAAAmDMA AAAAAACIIgAAIAwAAKguAAA6AQAABQASAQAACQQECAEEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAElOVEVS TkFUSU9OQUwgVEVMRUNPTU1VTklDQVRJT04gVU5JT04HSm9pbnQgQ29vcmRpbmF0aW9uIEFjdGl2 aXR5IE9uIENoaWxkIE9ubGluZSBQcm90ZWN0aW9uBwdURUxFQ09NTVVOSUNBVElPTgtTVEFOREFS RElaQVRJT04gU0VDVE9SDVNUVURZIFBFUklPRCAyMDEzLTIwMTYHRE9DIDA0NQcHB0VuZ2xpc2gg b25seQ1PcmlnaW5hbDogRW5nbGlzaAcHBwdHZW5ldmEsIDE1IEphbnVhcnkgMjAxNAcHRE9DVU1F TlQHB1NvdXJjZToHVFNCBwdUaXRsZToHRmlmdGggbWVldGluZyBvZiBJVFUtVCBKb2ludCBDb29y ZGluYXRpb24gQWN0aXZpdHkgb24gQ2hpbGQgT25saW5lIFByb3RlY3Rpb24gKEpDQS1DT1ApLCBH ZW5ldmEsIFN3aXR6ZXJsYW5kLCAxNSBKYW51YXJ5IDIwMTQsIDE4OjAwIJYgMTk6MzAgQ0VUBwdU aGlzIGRvY3VtZW50IHByb3ZpZGVzIGluZm9ybWF0aW9uIG9uIHRoZSBmaWZ0aCBtZWV0aW5nIG9m IHRoZSBJVFUtVCBKb2ludCBDb29yZGluYXRpb24gQWN0aXZpdHkgb24gQ2hpbGQgT25saW5lIFBy b3RlY3Rpb24gKEpDQS1DT1ApLg0xCVRoZSBmaWZ0aCBtZWV0aW5nIG9mIHRoZSBKQ0EtQ09QIGlz IHNjaGVkdWxlZCBvbiAxNSBKYW51YXJ5IDIwMTQsIDE4OjAwIJYgMTk6MzAgQ0VULiBUaGlzIGZp ZnRoIEpDQS1DT1AgbWVldGluZyB3aWxsIGJlIGhlbGQgaW4gR2VuZXZhLCBTd2l0emVybGFuZCBh bmQgd2lsbCB1dGlsaXplIHRlbGVjb25mZXJlbmNpbmcgZmFjaWxpdGllcyBmb3IgcmVtb3RlIHBh cnRpY2lwYXRpb24uDTIJVGhpcyBKQ0EtQ09QIGlzIG9wZW4gYXMgZGVzY3JpYmVkIGJ5IDIuMi4z IG9mIFJlY29tbWVuZGF0aW9uIElUVS1UIEEuMS4NMwlUaGUgZHJhZnQgYWdlbmRhIGZvciB0aGUg NXRoIEpDQS1DT1AgYXBwZWFycyBpbiATSFlQRVJMSU5LICJodHRwOi8vaWZhLml0dS5pbnQvdC9z ZnRwL2pjYWNvcC8yMDE0XzAxX0pDQS1DT1BfR2VuZXZhL0RPQzA0Nl9hZ2VuZGFfZm9yX3RoZV9m aWZ0aF9KQ0EtQ09QX21lZXRpbmcuZG9jeCIBFEpDQS1DT1AgRE9DMDQ2FSAoYW5kIHJldmlzaW9u cyB0aGVyZW9mKS4NNAlDb250cmlidXRpb25zIGFyZSBzcGVjaWZpY2FsbHkgc291Z2h0IHJlZ2Fy ZGluZyBDT1AgYWN0aXZpdGllcyBpbiBJVFUtVCBTdHVkeSBHcm91cHMgYW5kIG90aGVyIElUVSBC dXJlYXVzOyBNZW1iZXIgYWN0aXZpdGllczsgYW5kIGFjdGl2aXRpZXMgb2Ygb3RoZXIgSkNBLUNP UCByZXByZXNlbnRhdGl2ZXMuDTUJSW5mb3JtYXRpb24gcmVsYXRlZCB0byB0aGUgbWVldGluZyBh cyB3ZWxsIGFzIHRoZSBkb2N1bWVudHMgcmVjZWl2ZWQgd2lsbCBiZSBtYWRlIGF2YWlsYWJsZSBv biB0aGUgSkNBLUNPUCB3ZWIgcGFnZSBhdCATIEhZUEVSTElOSyAiaHR0cDovL3d3dy5pdHUuaW50 L2VuL0lUVS1UL2pjYS9DT1AvIiAUaHR0cDovL3d3dy5pdHUuaW50L2VuL0lUVS1UL2pjYS9DT1Av FS4NTm8gcmVnaXN0cmF0aW9uIGZlZSBpcyByZXF1aXJlZCBmb3IgcGFydGljaXBhdGluZyBpbiB0 aGlzIG1lZXRpbmcuDVRoZSBkaXNjdXNzaW9ucyB3aWxsIGJlIGhlbGQgaW4gRW5nbGlzaCBvbmx5 Lg1JbiBwcmVwYXJpbmcgZG9jdW1lbnRzLCBwbGVhc2UgdXNlIHRoZSBiYXNpYyB0ZW1wbGF0ZSBm b3IgdGhlIEpDQS1DT1AgZG9jdW1lbnRzIGF2YWlsYWJsZSBmcm9tIHRoZSBKQ0EtQ09QIHdlYiBw YWdlLiBQYXJ0aWNpcGFudHMgc2hhbGwgc3VibWl0IGlucHV0IGRvY3VtZW50cyB0byB0aGUgSkNB LUNPUCBpbiBlbGVjdHJvbmljIGZvcm1hdCB0byBUU0IgYnkgc2VuZGluZyB0aGUgZG9jdW1lbnRz IGJ5IGUtbWFpbCB0byATIEhZUEVSTElOSyAibWFpbHRvOnRzYmpjYWNvcEBpdHUuaW50IiAUdHNi amNhY29wQGl0dS5pbnQVLg02CVRvIGVuYWJsZSBUU0IgdG8gbWFrZSB0aGUgbmVjZXNzYXJ5IGFy cmFuZ2VtZW50cyBjb25jZXJuaW5nIHRoZSBvcmdhbml6YXRpb24gb2YgdGhlIEpDQS1DT1AgbWVl dGluZywgcGxlYXNlIHJlZ2lzdGVyIHZpYSB0aGUgb24tbGluZSBmb3JtIGF0IBMgSFlQRVJMSU5L ICJodHRwOi8vd3d3Lml0dS5pbnQvZW4vSVRVLVQvamNhL0NPUCIgFGh0dHA6Ly93d3cuaXR1Lmlu dC9lbi9JVFUtVC9qY2EvQ09QFSwgYXMgc29vbiBhcyBwb3NzaWJsZSwgYnV0IG5vdCBsYXRlciB0 aGFuIDEzIEphbnVhcnkgMjAxNC4gUGxlYXNlIG5vdGUgdGhhdCBwcmUtcmVnaXN0cmF0aW9uIG9m IHBhcnRpY2lwYW50cyB0byB0aGUgbWVldGluZyBpcyBjYXJyaWVkIG91dCBleGNsdXNpdmVseSBv bmxpbmUuIFRvIGVhc2lseSBwcm92aWRlIHlvdSB3aXRoIGFueSB1cGRhdGVzIGNvbmNlcm5pbmcg dGhlIG1lZXRpbmcgcGxhbm5pbmcsIHBsZWFzZSBmaWxsIGluIHlvdXIgdmFsaWQgZS1tYWlsIGFk ZHJlc3Mgb24geW91ciByZWdpc3RyYXRpb24gZm9ybSBhdAsTIEhZUEVSTElOSyAiaHR0cDovL3d3 dy5pdHUuaW50L29ubGluZS9yZWdzeXMvSVRVLVQvbWlzYy9lZHJzLnJlZ2lzdHJhdGlvbi5mb3Jt P19ldmVudGlkPTMwMDA2MTYiIBRodHRwOi8vd3d3Lml0dS5pbnQvb25saW5lL3JlZ3N5cy9JVFUt VC9taXNjL2VkcnMucmVnaXN0cmF0aW9uLmZvcm0/X2V2ZW50aWQ9MzAwMDYxNhUNNwlUaGUgZnJv bnQgZGVzayBhdCB0aGUgSVRVIE1vbnRicmlsbGFudCBidWlsZGluZyB3aWxsIGJlIG9wZW4gdW50 aWwgMTg6MzAgb24gMTUgSmFudWFyeSAyMDE1LiBEZWxlZ2F0ZXMgYXR0ZW5kaW5nIHRoaXMgSkNB LUNPUCBtZWV0aW5nIGluIHBlcnNvbiBraW5kbHkgYm9hcmQgYmVmb3JlIDE4OjMwLg0MQU5ORVgg MQsNDVRoaXMgY29uZmlybWF0aW9uIGZvcm0gc2hvdWxkIGJlIHNlbnQgZGlyZWN0IHRvIHRoZSBo b3RlbCBvZiB5b3VyIGNob2ljZQ0HBwEHC0lOVEVSTkFUSU9OQUwgVEVMRUNPTU1VTklDQVRJT04g VU5JT04LBwEHBw1URUxFQ09NTVVOSUNBVElPTiBTVEFOREFSRElaQVRJT04gU0VDVE9SCw0NSVRV LVQgSkNBLUNPUCBtZWV0aW5nIG9uIDE1IEphbnVhcnkgMjAxNA0NDUNvbmZpcm1hdGlvbiBvZiB0 aGUgcmVzZXJ2YXRpb24gbWFkZSBvbiAoZGF0ZSkgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tICB3 aXRoIChob3RlbCkgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NDQ1hdCB0aGUgSVRV IHByZWZlcmVudGlhbCB0YXJpZmYgDQ0NLS0tLS0tLS0tLS0tIHNpbmdsZS9kb3VibGUgcm9vbShz KQ0NYXJyaXZpbmcgb24gKGRhdGUpLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gYXQgKHRp bWUpICAtLS0tLS0tLS0tLS0tIGRlcGFydGluZyBvbiAoZGF0ZSktLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0NDUdFTkVWQSBUUkFOU1BPUlQgQ0FSRCA6IEhvdGVscyBhbmQgcmVzaWRl bmNlcyBpbiB0aGUgY2FudG9uIG9mIEdlbmV2YSBub3cgcHJvdmlkZSBhIGZyZWUgIkdlbmV2YSBU cmFuc3BvcnQgQ2FyZCIgdmFsaWQgZm9yIHRoZSBkdXJhdGlvbiBvZiB0aGUgc3RheS4gVGhpcyBj YXJkIHdpbGwgZ2l2ZSB5b3UgZnJlZSBhY2Nlc3MgdG8gR2VuZXZhIHB1YmxpYyB0cmFuc3BvcnQs IGluY2x1ZGluZyBidXNlcywgdHJhbXMsIGJvYXRzIGFuZCB0cmFpbnMgYXMgZmFyIGFzIFZlcnNv aXggYW5kIHRoZSBhaXJwb3J0LiANDQ1GYW1pbHkgbmFtZSAgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0NRmlyc3QgbmFtZSAgLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQ0N DUFkZHJlc3MgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAgICAgICAgVGVsOiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQ0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAgICAgRmF4OiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQ0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSAgIEUtbWFpbDogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQ0NDUNyZWRp dCBjYXJkIHRvIGd1YXJhbnRlZSB0aGlzIHJlc2VydmF0aW9uOiAgIEFYL1ZJU0EvRElORVJTL0VD ICAob3Igb3RoZXIpIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQ0NTm8uIC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tICB2 YWxpZCB1bnRpbCAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQ0NRGF0ZSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0gIFNpZ25hdHVyZSAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDV9fX19fXw0DDQ0EDQ0DDQ0EDQ0NDS0gEyBQQUdFICBcKiBNRVJHRUZP Uk1BVCAUMhUgLQ1ET0MgMDQ1DQ0NDQ0NDQ0NDQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAACYIAABBCAAAQggA AEUIAABcCAAAXQgAAF4IAACHCAAAlAgAAJYIAACYCAAAnAgAAJ0IAACeCAAAowgAAKUIAACmCAAA pwgAAKgIAADGCAAAxwgAAMgIAADJCAAA0ggAANQIAADcCAAA4AgAAOEIAADjCAAA7AgAAO0IAAD1 CAAA+ggAAAAJAAABCQAA9+3j7dnMxbn3s62zraOakYXFuXxwxWbFYl7FYsVmxWbFZsUAAAAAAAAA AAAGFmgFVW0AAAYWaJpG8AAAEhVoJTZlABZoJTZlADUIgVwIgQAWFWglNmUAFmglNmUANQiBQ0oc AFwIgQAQFmglNmUANQiBQ0ocAFwIgQAWFWglNmUAFmglNmUANQiBQ0ooAFwIgQAQFmiaRvAANQiB Q0ooAFwIgQAQFmgmBcoANQiBQ0ooAFwIgQATFWglNmUAFmglNmUAOgiBQ0oUAAoWaAVVbQBDShQA AAoWaCU2ZQBDShQAABYVaCU2ZQAWaCU2ZQA1CIFDShoAXAiBAAwVaCU2ZQAWaCU2ZQAAGRVoJTZl ABZoJTZlADUIgToIgUNKHABcCIETFmi1DRkANQiBOgiBQ0ocAFwIgRMWaIl/dgA1CIE6CIFDShwA XAiBExZoJTZlADUIgToIgUNKHABcCIEQFWglNmUAFmglNmUAQ0oUACMACAAAJggAAF0IAABeCAAA hwgAAJ4IAACmCAAA9gAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAACaAAAAAAAAAAAAAAAA9gAAAAAA AAAAAAAAAJEAAAAAAAAAAAAAAACFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAMkAhYkAUlmAQAAAGEkAmdkmkbwAAkAABYkAUlmAQAA AGdkBVVtAABPAABrZAAAAAAWJAEXJAFJZgEAAAACljkAAzQBCNYwAALH/8ASiiYABvkSAAAAAAAA AAAAAAAAAAAAAAAGyhMAAAAAAAAAAAAAAAAAAAAAFPYDwyYX9gMAABrWCAAAAP8AAAD/G9YIAAAA /wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/NNYGAAEFAwAANNYGAAEKAzkAYfYDAABmNAEMAAAD JAIWJAFJZgEAAABhJAJnZIl/dgAJAAAWJAFJZgEAAABnZCU2ZQAABqYIAACnCAAAqAgAALUIAADH CAAAyAgAAMkIAADKCAAArQAAAAAAAAAAAAAAAKQAAAAAAAAAAAAAAACYAAAAAAAAAAAAAAAAmAAA AAAAAAAAAAAAAEYAAAAAAAAAAAAAAACkAAAAAAAAAAAAAAAApAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAFEAAGtktwAAABYkARckAUlmAQAAAAKWOQADNAEHlGMBCNYwAALH/8ASiiYgBvkS AAAAAAAAAAAMAQAAAAAAAAAGyhMAAAAAAAAAAAwBAAAAAAAAFPYDwyYX9gMAABrWCAAAAP8AAAD/ G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/NNYGAAEFAwAANNYGAAEKAzkAYfYDAABm NAEMAAADJAIWJAFJZgEAAABhJAJnZCU2ZQAJAAAWJAFJZgEAAABnZCU2ZQAAUQAAa2RQAAAAFiQB FyQBSWYBAAAAApY5AAM0AQeUzQEI1jAAAsf/wBKKJmAG+RIAAAAAAAAAAP////8AAAAAAAbKEwAA AAAAAAAA/////wAAAAAU9gPDJhf2AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCP////////// HdYIAAAA/wAAAP801gYAAQUDAAA01gYAAQoDOQBh9gMAAGY0AQAHyggAAOIIAADjCAAA7AgAAO0I AAD1CAAA+QgAAPMAAAAAAAAAAAAAAACOAAAAAAAAAAAAAAAAggAAAAAAAAAAAAAAAEMAAAAAAAAA AAAAAAA6AAAAAAAAAAAAAAAAOgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAWJAFJZgEAAABnZCU2 ZQAAPgAAa2SAAQAAFiQBFyQBSWYBAAAAApY5AAM0AQeUZQEI1hoAAcf/iiYABsMmAAAAAAAAAAAA AAAAAAAAABT2A8MmF/YDAAAa1gQAAAD/G9YEAAAA/xzWBAAAAP8d1gQAAAD/NNYGAAEFAwAANNYG AAEKAzkAYfYDAABmNAEMAAADJAEWJAFJZgEAAABhJAFnZCU2ZQAAZAAAa2QeAQAAFiQBFyQBSWYB AAAAApY5AAM0AQeUZQEI1kYAA8f/GAbAEoomAAZRBgAAAAAAAAAAAAAAAAAAAAAABqgMAAAAAAAA AAAAAAAAAAAAAAAGyhMAAAAAAAAAAAAAAAAAAAAAFPYDwyYX9gMAABrWDAAAAP8AAAD/AAAA/xvW DAAAAP8AAAD/AAAA/xzWDAAAAP8AAAD/AAAA/x3WDAAAAP8AAAD/AAAA/zTWBgABBQMAADTWBgAB CgM5AGH2AwAAZjQBDAAAAyQCFiQBSWYBAAAAYSQCZ2SaRvAAAAb5CAAA+ggAAAEJAACSCQAAkwkA ABoKAACtAAAAAAAAAAAAAAAAogAAAAAAAAAAAAAAAJcAAAAAAAAAAAAAAABFAAAAAAAAAAAAAAAA NgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAAANxg4ABBoDpwQ0BsEHAAAAABOk8ABn ZIMNWgAAUQAAa2QaAgAAFiQBFyQBSWYBAAAAApY5AAM0AQeUZQEI1jAAAsf/GAaKJgAGUQYAAAAA AAAAAAwBAAAAAAAAAAZyIAAAAAAAAAAADAEAAAAAAAAU9gPDJhf2AwAAGtYIAAAA/wAAAP8b1ggA AAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP801gYAAQUDAAA01gYAAQoDOQBh9gMAAGY0AQsA ABSkeAAWJAFJZgEAAABnZJpG8AALAAAUpHgAFiQBSWYBAAAAZ2QlNmUAAFEAAGtkxgEAABYkARck AUlmAQAAAAKWOQADNAEHlGUBCNYwAALH/xgGiiYABlEGAAAAAAAAAAAAAAAAAAAAAAAGciAAAAAA AAAAAAAAAAAAAAAAFPYDwyYX9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3W CAAAAP8AAAD/NNYGAAEFAwAANNYGAAEKAzkAYfYDAABmNAEABQEJAAACCQAABAkAAAYJAAASCQAA GAkAADcJAABOCQAAVAkAAFcJAABaCQAAbQkAAG8JAABxCQAAcgkAAHkJAAB9CQAAfgkAAIEJAACC CQAAiQkAAIwJAACRCQAAkwkAAL0JAADCCQAA0gkAANgJAAD3CQAADgoAABQKAAAXCgAAGAoAABoK AAAbCgAAHQoAACAKAAAlCgAANQoAADkKAAA8CgAASgoAAE0KAAD8+Pzx7fHp8enx+PH45fje+Nr4 2vja8czCubOtp62nrcyViH95f3Ntf3MAAAAAChZoHWCbAFBKBAAAChZo43y4AFBKBAAAChZoPB1f AFBKBAAAEBVo43y4ABZo43y4AFBKBAAAGBVo43y4ABZo43y4AFBKBABtSAkEc0gJBAAjFWjjfLgA FmjjfLgAUEoDAG1ICQRuSBEEbygBc0gJBHRIEQQKFmiLcUEAUEoDAAAKFmglNmUAUEoDAAAKFmg+ ABoAUEoDAAAQFWjjfLgAFmjjfLgAUEoDAAASFmiDDVoAUEoDAG5IEQR0SBEEABsVaON8uAAWaON8 uABQSgMAbkgRBG8oAXRIEQQGFmj1OyIAAAwVaAVVbQAWaAVVbQAABhZo+xD6AAAGFmgYbjsAAAYW aC96BwAADBVoJTZlABZoJTZlAAAGFmiaRvAAAAYWaDBP3wAqTQoAAFcKAABbCgAAbwoAAHAKAAB2 CgAAewoAAJQKAACvCgAA9goAAPcKAAD4CgAA+QoAAAELAAAFCwAABgsAAAgLAABACwAAQQsAAEcL AABNCwAAXAsAAF0LAABfCwAAYAsAAHMLAAB0CwAA6AsAAOkLAADqCwAA8wsAAPYLAAD4CwAA+QsA APoLAAD89fzs5uDm2ubRw+y9t7G9sauln6XalY+lh4N4h3Jpcl9ZAAAAAAoWaEAsbwBQSgQAABMD agAAAAAWaEAsbwAwSm0AVQgBEBVobXo0ABZoQCxvADBKbQAAChZoQCxvADBKbQAAFQIIgQNqfAIA AAYIARZoQCxvAFUIAQYWaEAsbwAADwNqAAAAABZoQCxvAFUIAQoWaKsIQgBQSgQAABMVaKsIQgAW aKsIQgBIKgFQSgQAChZo7T9uAFBKBAAAChZoqkcnAFBKBAAAChZo43y4AFBKBAAAChZoexISAFBK BAAAChZopmW1AFBKBAAAChZoJTZlAFBKBAAAGxVo43y4ABZo43y4AFBKAwBuSBEEbygBdEgRBBAV aAFnQAAWaON8uABQSgQAAAoWaE5+mABQSgQAAAoWaDwdXwBQSgQAAAoWaAFnQABQSgQAABAVaON8 uAAWaON8uABQSgQAAAwVaAVVbQAWaDwdXwAABhZoPB1fACIaCgAA9woAAEELAAATDAAAxQwAAJkN AADcDQAACg4AADYPAAABEgAArhIAAO4AAAAAAAAAAAAAAADbAAAAAAAAAAAAAAAAyAAAAAAAAAAA AAAAALUAAAAAAAAAAAAAAACiAAAAAAAAAAAAAAAAkAAAAAAAAAAAAAAAAH4AAAAAAAAAAAAAAABs AAAAAAAAAAAAAAAAZwAAAAAAAAAAAAAAAGIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAQAAGdkxyaDAAAEAABnZFB0nAASAAANxhABpwQEGgNTAzQGwQcAAAAADoRbAF2EWwBnZNlS swASAAANxhABpwQEGgNTAzQGwQcAAAAADoRbAF2EWwBnZON8uAASAAANxhABpwQEGgNTAzQGwQcA AAAADoRbAF2EWwBnZFBW7wATAAANxg4ABBoDpwQ0BsEHAAAAAA6EAv4TpPAAXYQC/mdkJBn1ABMA AA3GDgAEGgOnBDQGwQcAAAAADoQC/hOk8ABdhAL+Z2TZUrMAEwAADcYOAAQaA6cENAbBBwAAAAAO hAL+E6TwAF2EAv5nZEAsbwATAAANxg4ABBoDpwQ0BsEHAAAAAA6EAv4TpPAAXYQC/mdkJTZlABEA AA3GDgAEGgOnBDQGwQcAAAAADoRbAF2EWwBnZE5+mAAACvoLAAD7CwAA/wsAABEMAAASDAAAFQwA ACIMAAA7DAAAxAwAAMUMAADGDAAA+QwAAAINAAAqDQAALQ0AADENAAA6DQAAPg0AAD8NAABLDQAA bw0AAHENAAByDQAAlg0AAJcNAAAKDgAASA4AAEsOAABPDgAAbQ4AAHAOAAB0DgAArA4AALMOAAC3 DgAA+vTr5d/W0MrBt66orqiirqiYoo+imISYrndtY3dtWXdtYwAAAAASFmiTHHAAUEoEAG1ICQRz SAkEABIWaANzJgBQSgQAbUgJBHNICQQAEhZoexISAFBKBABtSAkEc0gJBAAYFWjjfLgAFmjjfLgA UEoEAG1ICQRzSAkEABQVaBVaIwAWaCQZ9QAwSm0AUEoEAAAQFWgkGfUAFmgkGfUAUEoEAAATA2oA AAAAFmgkGfUAUEoEAFUIAQoWaCQZ9QBQSgQAAAoWaHsSEgBQSgQAABAVaON8uAAWaON8uABQSgQA ABIWaNsNfQBQSgMAbkgRBHRIEQQAEBVo43y4ABZoqkcnAFBKBAAAChZoq0n0AFBKBAAAChZoqkcn AFBKBAAAEBVoWlizABZoqkcnAFBKBAAAChZo2w19AFBKBAAAChZo3lYiAFBKBAAAEBVoWlizABZo WlizAFBKBAAAChZoWlizAFBKBAAAChZoHW24AFBKBAAitw4AANQOAADrDgAA7A4AAPoOAAD7DgAA Dg8AAB8PAAAhDwAAIg8AADMPAAA0DwAANQ8AADYPAAA3DwAAjA8AAI8PAACTDwAAnQ8AAKMPAADF DwAAxg8AANIPAAD1DwAA9w8AAPgPAAAbEAAAHBAAADcQAADz6d/p0ce6x9Gr0emelIuFf4txi2dh WGFnTWeLAAAAAAAAAAAAABQVaBVaIwAWaJkuhgAwSm0AUEoEAAAQFWiZLoYAFmiZLoYAUEoEAAAK FmiZLoYAUEoEAAATA2oAAAAAFmiZLoYAUEoEAFUIARsVaON8uAAWaON8uABQSgMAbkgRBG8oAXRI EQQKFmhvFYgAUEoEAAAKFmgkdnsAUEoEAAAQFWjjfLgAFmjjfLgAUEoEAAASFmhTbHEAUEoDAG5I EQR0SBEEABgVaNlSswAWaON8uABQSgQAbUgJBHNICQQAHBVoFVojABZoYWUsADBKbQBQSgQAbUgJ BHNICQQAGBVoYWUsABZoYWUsAFBKBABtSAkEc0gJBAASFmhhZSwAUEoEAG1ICQRzSAkEABsDagAA AAAWaGFlLABQSgQAVQgBbUgJBHNICQQSFmgkdnsAUEoEAG1ICQRzSAkEABIWaHsSEgBQSgQAbUgJ BHNICQQAGBVo43y4ABZo43y4AFBKBABtSAkEc0gJBBw3EAAARhAAAFUQAABXEAAAsxAAALsQAABF EQAASREAAEoRAABWEQAAqREAAKsRAACsEQAA/xEAAAASAAABEgAASxIAAF4SAACtEgAArhIAAK8S AAC3EgAAuBIAALkSAADQEgAA9e7l2crlxLq0q7S6oLqakoqSgnlsYVVJAAAAAAAAAAAAAAAAAAAA AAAAAAAAABcVaON8uAAWaG5k6wA2CIFQSgQAYUoYABcVaON8uAAWaG5k6wA2CIFDShQAUEoEABQV aON8uAAWaG5k6wBDShAAUEoEAAAYFWjjfLgAFmhuZOsAUEoEAG1ICQRzSAkEABAVaON8uAAWaG5k 6wBQSgQAAA4WaNdYywBtSAkEc0gJBAAOFmjHJoMAbUgJBHNICQQADhZoUHo2AG1ICQRzSAkEAAoW aGVHuABQSgQAABQVaIxNzAAWaFB0nAAwSm0AUEoEAAAQFWhQdJwAFmhQdJwAUEoEAAAKFmhQdJwA UEoEAAATA2oAAAAAFmhQdJwAUEoEAFUIAQoWaFpYswBQSgQAABwVaON8uAAWaON8uAA1CIE2CIFQ SgQAXAiBXQiBABYVaON8uAAWaON8uAA1CIFQSgQAXAiBABAVaON8uAAWaON8uABQSgQAAA0WaNFQ hwA1CIFQSgQAExVo43y4ABZo43y4ADUIgVBKBAAAGK4SAAC4EgAAuRIAAAITAAADEwAABBMAAAYT AAAuEwAA5AAAAAAAAAAAAAAAAMkAAAAAAAAAAAAAAADJAAAAAAAAAAAAAAAAsgAAAAAAAAAAAAAA AHAAAAAAAAAAAAAAAABXAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAFwAAAyQBDcYFAAGn JQEOhNj/EmTwAAAAFiQBSWYBAAAAXYTY/2EkAWdkBRQmABkAAAMkAQ3GBQABpyUBDoRQ/xJk8AAA ABOkOQAWJAFJZgEAAABdhFD/YSQBZ2QFFCYAAEEAAGtk1wMAABYkARckAUlmAQAAAABUAQAClmwA AzQBCNYaAAGU/yQkAAaQJAYBAAAGAQAABgEAAAYBAAAU9gPjJhf2AwAAGPYDUwIa1gQAAAD/G9YE AAAA/xzWBAAAAP8d1gQAAAD/NNYGAAEKA2wAYfYDAABmNAF5dAUUJgCKVAEAFwAAAyQBDoSCABJk IAEAABOkAAAUpGQAFiQBSWYBAAAAXYSCAGEkAWdkBRQmAAAaAAADJAENxggAAqAFxyEAAA6EhQAS ZCABAAATpAAAFiQBSWYBAAAAXYSFAGEkAWdkBRQmAAAaAAADJAENxg0EGgOnBDQGwQcBYhMBEmTw AAAANSQBNyQBOCQBOUQEAEgkAWEkAWdkbmTrAAAH0BIAANcSAADzEgAAAhMAAAMTAAAEEwAABRMA AAYTAAAHEwAALhMAAC8TAAAxEwAAMhMAAFwTAABdEwAAYxMAAHYTAAB3EwAA8uTYybypno97aJ5e TMlDOi4AAAAXFWh4RN4AFmhuZOsANgiBQ0oUAFBKBAARFmhuZOsANgiBQ0oUAFBKBAARFmjKPeYA NgiBQ0oUAFBKBAAiFWjjfLgAFmhuZOsANQiBUEoEAFwIgWFKGABtSAkEc0gJBAATFWjjfLgAFmhu ZOsANQiBUEoEACQDatQXAAAVaON8uAAWaG5k6wBQSgQAVQgBbUgABG5IAAR1CAEAJhVo43y4ABZo bmTrADUIgUNKHABQSgQAXAiBYUocAG1ICgRzSAoEABwVaON8uAAWaG5k6wBDShoAUEoEAG1ICgRz SAoEABQVaON8uAAWaG5k6wBDShwAUEoEAAAkA2o2BAAAFWjjfLgAFmhuZOsAUEoEAFUIAW1IAARu SAAEdQgBABgVaON8uAAWaG5k6wBQSgQAbUgJBHNICQQAHBVo43y4ABZobmTrAENKFABQSgQAbUgJ BHNICQQAFxVo43y4ABZobmTrADYIgVBKBABhShgAGhVo43y4ABZobmTrADUIgTYIgVBKBABhShgA ABoVaON8uAAWaG5k6wA2CIFQSgQAXAiBYUoYABEuEwAAMBMAADETAAAyEwAAXBMAAF0TAADiAAAA AAAAAAAAAAAAegAAAAAAAAAAAAAAAGEAAAAAAAAAAAAAAABIAAAAAAAAAAAAAAAAMgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABUAAA3GBQABoAUADoRx/w+EHAESZPAAAAATpAAAXYRx/16EHAFnZG5k 6wAAGAAAAyQBDcYFAAFGEgEOhHH/D4QcARJk8AAAABOkAABdhHH/XoQcAWEkAWdkbmTrAAAYAAAD JAENxgUAAaAFAA6Ecf8PhBwBEmTwAAAAE6QAAF2Ecf9ehBwBYSQBZ2RuZOsAAGcAAGtkcisAABYk ARckAUlmAQAAAABUAQAClmwAAzQBCNZGAAOU/58E/yB3JgAGCwUAAAAAAAAAAAAAAAAAAAAAAAZg HAAAAAAAAAAAAAAAAAAAAAAABngFAAAAAAAAAAAAAAAAAAAAABT2A+MmF/YDAAAY9gMAABrWDAAA AP8AAAD/AAAA/xvWDAAAAP8AAAD/AAAA/xzWDAAAAP8AAAD/AAAA/x3WDAAAAP8AAAD/AAAA/zTW BgABCgNsAGH2AwAAZjQBeXQFFCYAilQBAB0AAAMkAQ3GBQABpyUBDoS2/w+Ecv8SZPAAAAATpDkA FiQBSWYBAAAAXYS2/16Ecv9hJAFnZAUUJgAABXcTAACFEwAAhhMAAIgTAAAAFAAAARQAACAUAAAh FAAAIxQAAMQUAADGFAAA3hQAAOgVAADqFQAA9RUAAGwWAAB3FgAA8RYAAPkWAABKFwAAVxgAAHoY AACjGAAAuxgAAL0YAAC+GAAA6BgAAOsYAADvGAAAKRkAADQZAAD26tvq28i42+qtlH7bbttu227b XNvqrU6tbttc224AABoVaON8uAAWaG5k6wA2CIFDShQAUEoEAF0IgQAiFWjjfLgAFmhuZOsANgiB Q0oUAFBKBABdCIFtSAkEc0gJBAAfFWjjfLgAFmhuZOsANgiBQ0oUAFBKBABtSAkEc0gJBCoVaON8 uAAWaG5k6wA2CIFDShQAUEoFAF0IgW1ICQRuSAQIc0gJBHRIBAgAMBVo43y4ABZobmTrADUIgTYI gUNKFABQSgUAXAiBXQiBbUgJBG5IBAhzSAkEdEgECAAUFWjjfLgAFmhuZOsAQ0oUAFBKBAAAHxVo 43y4ABZobmTrAD4qAVBKBABhShgAbUgJBHNICQQlFWjjfLgAFmhuZOsANQiBNgiBPioBUEoEAGFK GABtSAkEc0gJBBwVaON8uAAWaG5k6wBDShQAUEoEAG1ICQRzSAkEABcVaON8uAAWaG5k6wA2CIFD ShQAUEoEABEWaMo95gA2CIFDShQAUEoEAAAeXRMAAIYTAACHEwAAiBMAAP8TAAAAFAAAARQAACEU AAAiFAAAIxQAAEYUAABHFAAAxBQAAMUUAADGFAAA6BUAAOkVAADqFQAAaxYAAGwWAADuFgAA7xYA AOkAAAAAAAAAAAAAAADTAAAAAAAAAAAAAAAA0wAAAAAAAAAAAAAAANMAAAAAAAAAAAAAAADTAAAA AAAAAAAAAAAA0wAAAAAAAAAAAAAAANMAAAAAAAAAAAAAAADTAAAAAAAAAAAAAAAA0wAAAAAAAAAA AAAAANMAAAAAAAAAAAAAAADTAAAAAAAAAAAAAAAA0wAAAAAAAAAAAAAAANMAAAAAAAAAAAAAAADT AAAAAAAAAAAAAAAAuwAAAAAAAAAAAAAAANMAAAAAAAAAAAAAAADTAAAAAAAAAAAAAAAA0wAAAAAA AAAAAAAAANMAAAAAAAAAAAAAAADTAAAAAAAAAAAAAAAA0wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAFwAADcYKBBoDpwQ0BsEHAA+EHAETpGQAFKRkAEAmA1skAVwkAV6EHAFnZG5k6wAAFQAADcYF AAGgBQAOhAMCD4QcARJk8AAAABOkAABdhAMCXoQcAWdkbmTrAAAVAAANxgUAAaAFAA6EAwIPhBwB EmTwAAAAE6QAAF2EAwJehBwBZ2TKPeYAABXvFgAA8BYAAPEWAABvFwAAcBcAAPMXAAD0FwAAdxgA AHgYAAB5GAAAehgAAOkYAADqGAAA6xgAAGcZAABoGQAAaRkAAOUZAADsGQAA7hkAAO8ZAADxGQAA 8hkAAPQZAAD1GQAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAA AAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAA AADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAA AAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAA AAAAAADQAAAAAAAAAAAAAAAAzgAAAAAAAAAAAAAAAM4AAAAAAAAAAAAAAADOAAAAAAAAAAAAAAAA zgAAAAAAAAAAAAAAAM4AAAAAAAAAAAAAAADOAAAAAAAAAAAAAAAAAAEAAAAYAAADJAENxhcABxoD pwSKBTQGpgbBB3AIAAAAAAAAAA6EXABdhFwAYSQBZ2SAFCYAABUAAA3GBQABoAUADoQDAg+EHAES ZPAAAAATpAAAXYQDAl6EHAFnZG5k6wAAGDQZAABpGQAAbRkAAKYZAACwGQAA5BkAAOUZAADrGQAA 7BkAAO0ZAADvGQAA8BkAAPIZAADzGQAA9RkAAPYZAAD4GQAA+RkAAPoZAAD8GQAA/RkAABMaAAAU GgAAFRoAABYaAAAYGgAAGRoAACAaAAAhGgAAIhoAACMaAAAkGgAAJRoAACYaAAAnGgAAKBoAACka AAAqGgAAKxoAACwaAADx5drl2tbQx7+7v7u/u7+7t7OsoayhmKGskdasjbezt7O3s4SAu8cAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGFmhP UVMAABAVaCU2ZQAWaCU2ZQBDShIAAAYWaA4udgAADBVoJTZlABZoDi52AAARFmgHTPAAbUgABG5I AAR1CAEVA2oAAAAAFWglNmUAFmglNmUAVQgBDBVoJTZlABZoJTZlAAAGFmi/RZ8AAAYWaAJifgAA BhZoBRQmAAAPA2oAAAAAFmgFFCYAVQgBEBVo43y4ABZoLn24AFBKBAAAChZogBQmAFBKBAAABhZo bmTrAAAUFWjjfLgAFmhuZOsAQ0oUAFBKBAAAFxVo43y4ABZobmTrADYIgUNKFABQSgQAHBVo43y4 ABZobmTrAENKFABQSgQAbUgJBHNICQQn9RkAAPcZAAD4GQAA+RkAAPoZAAAZGgAAIRoAACIaAAAj GgAAJBoAACUaAAAmGgAAJxoAACgaAAApGgAAKhoAACsaAAAsGgAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAADvAAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAOYAAAAAAAAAAAAAAADhAAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAMgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAAADJAENxhcABxoDpwSKBTQGpgbBB3AIAAAAAAAA AA6EXABdhFwAYSQBZ2SAFCYAAAQpAGdkJTZlAAAGAAATpAAAZ2QlNmUAAAEpAAAGMAAUpPAAZ2QC Yn4AAAQwAGdkJTZlAAABMAAAAQAAABE1AAowATGQRgE6cCU2ZQAfsIMuILDIQSGwbgQisG4EI5CJ BSSQiQUlsAAAF7DQAhiw0AIMkNACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAE4AFiQBFyQBSWYBAAAAAZYAACF2AAJoASN2AAH5EiN2AQLK EzpWCwACljkAAzQBFPYDwyY11gUAAQP5EjXWBQECA8oTNNYGAAEKAzkAZjQBZQAWJAEXJAFJZgEA AAABlgAAIXYAAmgBI3YAAfkSI3YBAsoTOlYLAAKWOQADNAEHlM0BFPYDwyYr1gIAAzXWBQABA/kS NdYFAQIDyhMv1gsAAgT//////////zTWBgABCgM5AGY0AWUAFiQBFyQBSWYBAAAAAZYAACF2AAJo ASN2AAH5EiN2AQLKEzpWCwACljkAAzQBB5RjART2A8MmK9YCAAE11gUAAQP5EjXWBQECA8oTL9YL AAIEAAAA/wwBAAA01gYAAQoDOQBmNAFgABYkARckAUlmAQAAAAGWAAAhdgADaAEjdgABUQYjdgEC qAwjdgIDyhM6VgsAApY5AAM0AQeUZQEU9gPDJjXWBQABA1EGNdYFAQIDqAw11gUCAwPKEzTWBgAB CgM5AGY0AUQAFiQBFyQBSWYBAAAAAZYAACF2AAFoASN2AAHDJjpWCwACljkAAzQBB5RlART2A8Mm NdYFAAEDwyY01gYAAQoDOQBmNAFSABYkARckAUlmAQAAAAGWAAAhdgACaAEjdgABUQYjdgECciA6 VgsAApY5AAM0AQeUZQEU9gPDJjXWBQABA1EGNdYFAQIDciA01gYAAQoDOQBmNAFgABYkARckAUlm AQAAAAGWAAAhdgACaAEjdgABUQYjdgECciA6VgsAApY5AAM0AQeUZQEU9gPDJjXWBQABA1EGNdYF AQIDciAv1gsAAgQAAAD/DAEAADTWBgABCgM5AGY0AVsBAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANDJ6nn5us4RjIIAqgBL qQsCAAAAAwAAAODJ6nn5us4RjIIAqgBLqQvqAAAAaAB0AHQAcAA6AC8ALwBpAGYAYQAuAGkAdAB1 AC4AaQBuAHQALwB0AC8AcwBmAHQAcAAvAGoAYwBhAGMAbwBwAC8AMgAwADEANABfADAAMQBfAEoA QwBBAC0AQwBPAFAAXwBHAGUAbgBlAHYAYQAvAEQATwBDADAANAA2AF8AYQBnAGUAbgBkAGEAXwBm AG8AcgBfAHQAaABlAF8AZgBpAGYAdABoAF8ASgBDAEEALQBDAE8AUABfAG0AZQBlAHQAaQBuAGcA LgBkAG8AYwB4AAAAeViB9Dsdf0ivLIJdxIUnYwAAAAClqwAAXQAWJAEXJAFJZgEAAAABlgAAIXYA AWgBI3YAAZAkOlYLAAKWbAADNAEU9gPjJhj2A1MCNdYFAAEDkCQv1gsAAQ8AAAD/BgEAADTWBgAB BQAAAGY0AXl0BRQmAIpUAQCeEwAARABkAB4J7wkAAAoAAAAAAAAAAAAAAAAAKwWiBe4C1wIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ABPAwAAAAsgQK8AgAAAABBAAAAAoAACMAC/AM AAAABEEBAAAA/wEAAAgAAAAQ8AQAAAAAAACAMgAH8BoTAAADBAp5tBEvwxMdjPtw1t2TbZP/APYS AAACAAAAegQAAAAADBhgIRvw7hIAAAp5tBEvwxMdjPtw1t2TbZNwLgAAifj///f9//8g/P//4AEA ADDSDAAY+A0AvBIAAAD+eNqtWQeUlUWyrp4BhgFGMZAkSh7JwgCCShhYYEBgYAI5DUEY0rDASHJg WSRIEJ6OqBhQDKCCEVERURAQRBbEwFMWhWURCRLE+avq0rXVfS97Xjq75zx+zvlO962u/qr6766q 7sFAIkB86woAxaCEAf1XXFE6rujq4sD1ysSdjn88Pir70VyTVYg8Hl9MeyWMgQRtI3EAIgKOBaCR 8pTUluKcdnQkKjdwbdYN2tZW3sXBj6ZGxMFZdPjRROfCP/9F58b9n5bifXtBLV4b/a9z4H/Z7ent 1oE3sNA6HMSF9iLOsLfQRNucRtm+NNjmUT/7CGXYjdTH7lP8rP047mcr8xDbnEfZbjzJDuFZdjIv suP4EduP59vOPMM2UXklvt8Cj7B/pyE6d5ByDFKuIfaPNMJm0BibQpNsOXrAXsH59mtcad/B5zyc L9fW+f9bWZpfWS1YHbCsDk7Kk8F+eS7YLC8HT8tbwQL5OBgvXwaZciy4Ry4FdaUk3iA1MLB34Qmb gV/aPPzQrsBXvCfOo8fwDZuPO+wA/Ma2wzO2LoKUxfJCQUM5FaTKN8FA2R1Mka3BYnkzWCsbgi2y Ljggz6vt570PLNe3osZ+ReWAeYQ4XOUxIpwrJjJZ4iNTpXhkhpSIzJGSkfmSGFmkY0vE8gKJ8DzV nyPID0gRT5UrPEku67yLPNrDcV2fZ9dOUTy1FYcGlCx9qJLMpCRZS/Gyh9iepyJ7M1+xKfy7zWay 09nIo1xKNnJ52cV15HtuKee4u/fGeXWS0+Urvle2cyPZwNXkEb5VpnJpyeRiksIgN7Mop5G9VFxe UDuzqYJkUi1pQs0lgTp7OF/CWdlvwc8evwQH4GTwLpwInoC/B3PgbDAcfg9SIR7rQTksBfXxnLTD g9If35V8fFIKca5swfvlB0z33jivjmN/2YaTZQ0ukjn4vAzHj6QLfitN8bJUxbKQhA0AsIvy5sCF oADOqa1fg7fV/n6wwd88nC/Xt7I7/MpugRvxBlMGS5mSWMIUQ2MMRuBqUAQUXIKi4Jy35CxKcAri 8CwUx4uQiL9DGWQoi2BuxWKmApY0jiec832Oo7jE1eEKN4CAWwFxJ0W6Yoj+Hq/yGXCG8+E8j4ML KrugYxdU5zzfpfJG8DPXghNcycNxhXMKhlEgDgV0Wp6ho7KNvpKjtE+IPpNK/Imey+3SW5HLO2Q+ 75Gn+IBs4iOyg0/KYb4kP3Gc98Z5dYRLwhdM8hGfk1f5J3lc9ebxIRnL+5Vjr3LtVc59EqEDcoy+ lu1q73k6JfPpsozUcuDgfAlnZQ9jF+MwH5ubAqxuHsREMxcvwwI8CsvwM1iNm+BFXA3v4jzYjbnw PWbCZewApakR1KXK0JESvTfOq650EzSkmnATpQBiNziBg+EA5sFHuBBex2fgOXwbHsfPYQUegyV4 BRaprcVY1SzDZuYxTPVwvoRzvo/gErMfF5hP8EHzLuabV3GSWYujzRM4yKzCvt6Ss/gk3qfyLLMe h5k3cYz5UPU+w+nmIM4yR3GucTzhnO8xvMtjPH8LufwLjOarMJDLmvu4pmnLKaYudzZJnGESOc3U 4HtMCjcynbmK6culzCBGGM4/wwg+AoN5r4fjCsezT+l9j+9pI1yhlyCJn4fairv4RejBr8Egfs9b c1Yz+GPoypuhFW9SnddU9zUoojfgGG2BXbTDw3GF49k46mwcRlELxe3av8FMI4Y/0Wl4jL6F9bTH W3NWN9Ff4CnSs0W/whwyZirdbCZRLcWd2u/g4bjC8cztlMNvNNT8J402n9BY86qiUPt/piFqLcNb c1ZnUw+ziLLMahqkOkNVd6j5TvsXKNPvtoPjCsezIrrNOCRwVVOBa5j6er7acG2TxnXNAMVYxXT9 /QA31n5TlTXVsaamtf6uyw1NOb7DFOd65grV9nBc4WSbZCyyDvWxnjTETEnB+dIRN0lf/F7ux2Lw J62Az2E6fIJT4W9YCGXoHWipuzqcTsFKisAOSvLeOK8+oQpmGZUwg+kiNKXvoARthb9qlnkfZ2vW yoaZ2AyGaWXuhsekNb4tDXCB1MRsqaa2q6sP1WO+hJNt7sH/sK1xrW2Br9tm+IFtjLttQzxsG+Ax e4feGpNjFmto/3aV1cRDtjZ+ZuvhFh1/VfWfts1xhXU8Id0WqaZxuEJNzXlqZ05ST/ODnsuvaILZ SzPNdnrIvEcrzSZabLbQXPMpTTX7aIw5TP3MUUozf6O25gw1NBepmofjuj7PlnvPOkMmDbQOY+l+ O5vy7XJ6yD5HhfZNesVupw/sAfrC/kDH7Gm6bK9Qohi9BZbm5nILd5PKPExq6n02mVdIY35Z7uSP tWIekVZaZVtzKc1KtaAl3w0tOBOa8WRoyIuhHr8ANXgrVNK8W5YvQAlO9Ktxq4pQcVOCz8KN/BWU 5w+gKq+FmrxQ50yEO5SjoXI1Us7Gyt1IbTRQW/W14tfm9VKdV0pFnik38UhJ5PvUz1ZSRDXlnN5K fyK0h+mk3U2H7BbabtfTRruanrGLaLmdTgU2hybb3pTj4b5FOKfwEjayhprZG6mlrUJ322TqqC+t rrY99bLdKdNbcha76Ovubsq2zfRVV4d62Ir0B1ua2tur2NZewFbW8YR0f6aqxuFWLmOacwC9+YTW v/3wZ60ga/gZeJMXwE7Oha+5NxzX+955rgxFeluyfEriIl/o++YtfeesltKRQknSfhmVlYycVlkx vQ9Wh7PcFo5ylt6o8uB9fhjW8TpYyttgCn8NWXxGKxiY2/hWE1A9D+dLOO/L8npvTsaKpj3WN9mY YvKwg1mKaWYDpps9mG1OYX9TkgaYZI2nNK0FuRp/y7UebKI25hA18p44j76hVuZt6mQeoV5mgur2 0BhNphE6d6Ry5JhdONy8ggPNEswwE7C76YvtTBtsamphDXOD3r2dH+Hs1V+CFzxOBp/rrf8cVMEk tXSHGYSd9G44wLyI4/VGNcv8hgtNNVpuutAqk6cZ5Claaj6j+Zplpmm9yTGVeYK5RAVmNy0zT1Oh 6jylumtMFVptLuFK87neytbqDWsWjjBZ2MO0wDv1NVHOFAWX4ai+s3YFL3s4X8JZ2UocYB1ycZLt gos1675kS+FO+2vwd3skSNT3exPZEmTLa0GBvBisl7XBIX27X5WXg7rwRtAbtgUzvTfOq3eCB+Gl oA88HdSH1arzuOo+Fbys+nNkY9BXPgoayMGguJwKfrRxuE2z/jO2A86zo3CMXYa9PZwv4azsO64s Djv0hb2eD9ql/KadyI/aHjzDJnOOjed0zaUd7TuaEZZQEzucGthW1NDeoFniBLaxH2BX743zajPe a3/CprYM1VOdmqp7u11Kdexm1f+RWtsE7mIb8UDbh/PsVF5qH+X19k3eZ/fxr/Y4VxAH50s4K3Mn yeEe7mmGcwszjyuYZ/UW/L5m8QP8DvzEy/XlNxoifC/ER8pDQuSslIh86rNFwBPkF+7kvXFe/cbt NZvk+ixSVnVuUt2kSEUoEWmvL8tx+nJcBd/yFviEj8LLLLCYq5sxfLdJ5Sx/mh2cL/9uZQUFBf9i Ze7virXj58EruBSewYfhUcUSxTzFA4qJipE6NgCXwVicpDeYvvo+a6W6VeAtvR3twjPyPR6Si/ih JNA60RiUFjRDutMofZ2mSz7dK8uoob4Wb5NCukUeojLyRyqmY1dtTyqy99Al24TO27p01nakb+wQ +tTO0rr0BK3RPX5Y69Vse4km2Jt4qG3Cfex93NmO57vsEm6sZ6uW3c0V7UlOsvGReHuBy9ijXN7u 5ep2MyfbF7iFXcH32lnczd7PGTZDOTpyrvLk26o835bhFZbVzlmt8UfpXfsrvW+Bt9myvNPW4L2q d9C24yO2Fx+3Q/ms7cRo63NJSdLdu0T15Vu6S7ZSD1lLQ2UhTZEJtFAy6ClpS29ILdolpel7+Q0v yl8xAfZgZb0JVoGLWBXiqBrcTDXgdn2X3kl14A+UDAOpsb5b20EypetbdZS+VWfCcVwJ+3C9vnM/ hWfxB92XIpiKt5ih+jbthr00R0001XCFKYlvmIvBIfN7sMdEgq2mGL5myuCTmoUfMrfjZNNIs34b rQRdMNlkYFkzQnkm63u3APfoe/oteFJvqG7//91J+u9/Rf6fJ6mij5FSMA3byxjsqUiV+R49ZRoO 8u18bad5tJfrs1bNW0uCdOwvDpnYXYaqtXHKPM1jkExU5OJgmYADFf09nO71Wb7ZW05Qy91j6B9j 7w4TYrLrs1DbWyir8ZYF+ThSWUfCcBwBWdjfszsr47Eb5GJXmKTIVyzwuq6N9t3ccPYzHzOVLccz LvDIUVmebxdom++RGZK14spaFGR6RsdcFOTB6SAn1kb7Ticca0XBSGXL8oyO+XSQpbKuvj2tbZHH SAjnrFbVfXOoqPuYpPtpdF8du7MiinjduzjdV6M6JqYbzlmtqucziu4x9v5iYrJwzmqCRjcGGtUa ezdqHFbSeKwas2I0/uI1DkHjEYNBciboGWujfTc3nP3EIF3ZUj2jYz4TpKqlFN+e0RY90kOy5jLc NEz3jI55Gqb4jBdto32nc313j5beWiXNq465p4xXjMLeMhz7asbrr+iu2SEdRmvETPRZwMFFjEMW gP4uqWNJqnOj6t6oc5J0bqJyxPldc3DcqSF9l8HUQdKpl6KTjPfoJUNpsG/H0yDfdzrhRFUbGigO 91Bv6UxdpRelenZnJUsrc18aplV5iOg708PphrPOrpSq1lO8B1H2FJXVi8mjY64fTgznKpNDV496 2r+G67XQwluoCEuoMqymJHicKkGh3k1WUkNYSi3gIWoDc6g9TKWOMS/qwWSqC3mKqVQbpqvuDL3T zNT5s6gczFaOJSTi2tnaLvGoHFLOXqSshcq2xEP0VimyzstcG+07nXCsFVKmsuV4xnUeOSrL8+06 bQs9wqp+WzRuN2isOkbHvEEr4Bovc220vyW06rdB76RbMMkzrvFIUpmIa9dou8EjrH17RVk3K9sG D5HNip1e5tpo3+lcn7Vrf2n8BlM99mNH2IHt4UNso/foFrAJG6r1mrAeK3lrzupnWE7fMZVhN1aD z3VsP9aGA1gXDiq+wXoxpIb0HRL8/0Slxjysp/16cAZTvDxBo8uNuX44WSNB81IUKd7KGa3FDgnX nQWvVf4L2EtOYAe5pPUjgl2lmOZhx+6snMUhch6HyS84VH7SG8Bh1Y22g3zfzQ3nqx7HPsrWyTMe 9ugkx7Glbw9re9yjT0jWXGUbQn08o2MeQi19pYu20b7TCeevDkM8cy+tZOnSgzKkG2VLV/3CXXVP cxVTNEfnU3PN0U1gHjWABfqmXKT5eDFV0AzpMqODyyIOLuKS4D2soHFfTeOiDnyMDTQOmujZb67n voWeSndCHQZKgNlyBTN0F9N1pb0UzpdOEk6UtuPm4tCXW8j93FpmcTtZwd3kOc6WjTxG3uNZ8iGv kmcVT/N8KeR8Wcq5UsDDJY/7yzDOkF7cWzl6xdA8JM+20ypx2EmzZD+Nlh8oS85TN4lTD8urpw3U 46j3vaSJelBNPSmjHkVouOqNk5M0Xf5K83XeKg/HFU5Eb6e0GFbF2NPgh5gsnIjeSP1gq2fsFkOU 3Vn5Tsf+QsNhF41SndGwV39v9Ejzc1w/nBjbqvVvo55ax7jXI0dlmTF5dMz1w7HWinMgmfM8o7OS zJlQWWWtPPL8mOuHYy2Z05Stn2es7NFPZaNj8uiY64dzQ66jTNdQ27fdPLuzWJ1Hwa08DEpzFiSq LDGmF85ZrcNPSBRpMfYnJDEmCydOe3CBOHTmuXIvz5OW/Gdpygs1Ph+W+rxCLT3qrTmrpXmplFWd CppFavIkacjjVH+MdOCRypETQ0FInk1Ri1E8KpPUk/G8RMaoZyPUwwHqRV/1OOp9jmSrByPUk/Hq Ub56NpcfkIWqs1Q9Xq4cy2Nc4ezKFN2JKJ6IsafB8pgsnAwyUM/vWGWb/E9LUTgrS3RsLo+AqXr6 xiry9fdAjzQ/x/XDibKxGrMDNbocY75HjsoyY/LomOuHY+2Qsu1UtrEemdrPhM0qO+SR58cOhZZB duqXOqRrcoybPfqpbHRMHh3bGVoG+VCZruEDzR7bFI7dWdyiGWQjD4cX1OKzKns2phfOWXXVP4q0 GHv0NuBk13e7mukttIXXlWmDxuHzGneFeq9YyJkynXvISP6DpHNHrfAdpJG2t+nvBJVfoUyt7sPk CE2Ug1QgX2oN/lIr3xeUDnu0cuygbK0groK6iuLQD2pyNlTR81CRe0MFXUUFjbqK/IhU4UVyu8Z5 st5zmmlWasNTJZWnaE7Ik0xth+jvMSqfpOPTVW+W6hfovLk6f67yPMjpMEMz9xQfbw7uDDr00y+X De+ozU2q87rqvv4vvli8/1L/AEiBRDSeEwAARABkAB4J7wkAAAoAAAAAAAAAAAAAAAAAKwWiBe4C 1wIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ABPAwAAAAsgQK8AgAAAACBAAAAAoA ACMAC/AMAAAABEEBAAAA/wEAAAgAAAAQ8AQAAAABAACAMgAH8BoTAAADBAp5tBEvwxMdjPtw1t2T bZP/APYSAAACAAAAGBgAAAAADBhgIRvw7hIAAAp5tBEvwxMdjPtw1t2TbZNwLgAAifj///f9//8g /P//4AEAADDSDAAY+A0AvBIAAAD+eNqtWQeUlUWyrp4BhgFGMZAkSh7JwgCCShhYYEBgYAI5DUEY 0rDASHJgWSRIEJ6OqBhQDKCCEVERURAQRBbEwFMWhWURCRLE+avq0rXVfS97Xjq75zx+zvlO962u /qr6766q7sFAIkB86woAxaCEAf1XXFE6rujq4sD1ysSdjn88Pir70VyTVYg8Hl9MeyWMgQRtI3EA IgKOBaCR8pTUluKcdnQkKjdwbdYN2tZW3sXBj6ZGxMFZdPjRROfCP/9F58b9n5bifXtBLV4b/a9z 4H/Z7ent1oE3sNA6HMSF9iLOsLfQRNucRtm+NNjmUT/7CGXYjdTH7lP8rP047mcr8xDbnEfZbjzJ DuFZdjIvsuP4EduP59vOPMM2UXklvt8Cj7B/pyE6d5ByDFKuIfaPNMJm0BibQpNsOXrAXsH59mtc ad/B5zycL9fW+f9bWZpfWS1YHbCsDk7Kk8F+eS7YLC8HT8tbwQL5OBgvXwaZciy4Ry4FdaUk3iA1 MLB34QmbgV/aPPzQrsBXvCfOo8fwDZuPO+wA/Ma2wzO2LoKUxfJCQUM5FaTKN8FA2R1Mka3BYnkz WCsbgi2yLjggz6vt570PLNe3osZ+ReWAeYQ4XOUxIpwrJjJZ4iNTpXhkhpSIzJGSkfmSGFmkY0vE 8gKJ8DzVnyPID0gRT5UrPEku67yLPNrDcV2fZ9dOUTy1FYcGlCx9qJLMpCRZS/Gyh9iepyJ7M1+x Kfy7zWay09nIo1xKNnJ52cV15HtuKee4u/fGeXWS0+Urvle2cyPZwNXkEb5VpnJpyeRiksIgN7Mo p5G9VFxeUDuzqYJkUi1pQs0lgTp7OF/CWdlvwc8evwQH4GTwLpwInoC/B3PgbDAcfg9SIR7rQTks BfXxnLTDg9If35V8fFIKca5swfvlB0z33jivjmN/2YaTZQ0ukjn4vAzHj6QLfitN8bJUxbKQhA0A sIvy5sCFoADOqa1fg7fV/n6wwd88nC/Xt7I7/MpugRvxBlMGS5mSWMIUQ2MMRuBqUAQUXIKi4Jy3 5CxKcAri8CwUx4uQiL9DGWQoi2BuxWKmApY0jiec832Oo7jE1eEKN4CAWwFxJ0W6Yoj+Hq/yGXCG 8+E8j4MLKrugYxdU5zzfpfJG8DPXghNcycNxhXMKhlEgDgV0Wp6ho7KNvpKjtE+IPpNK/Imey+3S W5HLO2Q+75Gn+IBs4iOyg0/KYb4kP3Gc98Z5dYRLwhdM8hGfk1f5J3lc9ebxIRnL+5Vjr3LtVc59 EqEDcoy+lu1q73k6JfPpsozUcuDgfAlnZQ9jF+MwH5ubAqxuHsREMxcvwwI8CsvwM1iNm+BFXA3v 4jzYjbnwPWbCZewApakR1KXK0JESvTfOq650EzSkmnATpQBiNziBg+EA5sFHuBBex2fgOXwbHsfP YQUegyV4BRaprcVY1SzDZuYxTPVwvoRzvo/gErMfF5hP8EHzLuabV3GSWYujzRM4yKzCvt6Ss/gk 3qfyLLMeh5k3cYz5UPU+w+nmIM4yR3GucTzhnO8xvMtjPH8LufwLjOarMJDLmvu4pmnLKaYudzZJ nGESOc3U4HtMCjcynbmK6culzCBGGM4/wwg+AoN5r4fjCsezT+l9j+9pI1yhlyCJn4fairv4RejB r8Egfs9bc1Yz+GPoypuhFW9SnddU9zUoojfgGG2BXbTDw3GF49k46mwcRlELxe3av8FMI4Y/0Wl4 jL6F9bTHW3NWN9Ff4CnSs0W/whwyZirdbCZRLcWd2u/g4bjC8cztlMNvNNT8J402n9BY86qiUPt/ piFqLcNbc1ZnUw+ziLLMahqkOkNVd6j5TvsXKNPvtoPjCsezIrrNOCRwVVOBa5j6er7acG2TxnXN AMVYxXT9/QA31n5TlTXVsaamtf6uyw1NOb7DFOd65grV9nBc4WSbZCyyDvWxnjTETEnB+dIRN0lf /F7ux2LwJ62Az2E6fIJT4W9YCGXoHWipuzqcTsFKisAOSvLeOK8+oQpmGZUwg+kiNKXvoARthb9q lnkfZ2vWyoaZ2AyGaWXuhsekNb4tDXCB1MRsqaa2q6sP1WO+hJNt7sH/sK1xrW2Br9tm+IFtjLtt QzxsG+Axe4feGpNjFmto/3aV1cRDtjZ+ZuvhFh1/VfWfts1xhXU8Id0WqaZxuEJNzXlqZ05ST/OD nsuvaILZSzPNdnrIvEcrzSZabLbQXPMpTTX7aIw5TP3MUUozf6O25gw1NBepmofjuj7PlnvPOkMm DbQOY+l+O5vy7XJ6yD5HhfZNesVupw/sAfrC/kDH7Gm6bK9Qohi9BZbm5nILd5PKPExq6n02mVdI Y35Z7uSPtWIekVZaZVtzKc1KtaAl3w0tOBOa8WRoyIuhHr8ANXgrVNK8W5YvQAlO9Ktxq4pQcVOC z8KN/BWU5w+gKq+FmrxQ50yEO5SjoXI1Us7Gyt1IbTRQW/W14tfm9VKdV0pFnik38UhJ5PvUz1ZS RDXlnN5KfyK0h+mk3U2H7BbabtfTRruanrGLaLmdTgU2hybb3pTj4b5FOKfwEjayhprZG6mlrUJ3 22TqqC+trrY99bLdKdNbcha76Ovubsq2zfRVV4d62Ir0B1ua2tur2NZewFbW8YR0f6aqxuFWLmOa cwC9+YTWv/3wZ60ga/gZeJMXwE7Oha+5NxzX+955rgxFeluyfEriIl/o++YtfeesltKRQknSfhmV lYycVlkxvQ9Wh7PcFo5ylt6o8uB9fhjW8TpYyttgCn8NWXxGKxiY2/hWE1A9D+dLOO/L8npvTsaK pj3WN9mYYvKwg1mKaWYDpps9mG1OYX9TkgaYZI2nNK0FuRp/y7UebKI25hA18p44j76hVuZt6mQe oV5mgur20BhNphE6d6Ry5JhdONy8ggPNEswwE7C76YvtTBtsamphDXOD3r2dH+Hs1V+CFzxOBp/r rf8cVMEktXSHGYSd9G44wLyI4/VGNcv8hgtNNVpuutAqk6cZ5Claaj6j+Zplpmm9yTGVeYK5RAVm Ny0zT1Oh6jylumtMFVptLuFK87neytbqDWsWjjBZ2MO0wDv1NVHOFAWX4ai+s3YFL3s4X8JZ2Uoc YB1ycZLtgos1675kS+FO+2vwd3skSNT3exPZEmTLa0GBvBisl7XBIX27X5WXg7rwRtAbtgUzvTfO q3eCB+GloA88HdSH1arzuOo+Fbys+nNkY9BXPgoayMGguJwKfrRxuE2z/jO2A86zo3CMXYa9PZwv 4azsO64sDjv0hb2eD9ql/KadyI/aHjzDJnOOjed0zaUd7TuaEZZQEzucGthW1NDeoFniBLaxH2BX 743zajPea3/CprYM1VOdmqp7u11Kdexm1f+RWtsE7mIb8UDbh/PsVF5qH+X19k3eZ/fxr/Y4VxAH 50s4K3MnyeEe7mmGcwszjyuYZ/UW/L5m8QP8DvzEy/XlNxoifC/ER8pDQuSslIh86rNFwBPkF+7k vXFe/cbtNZvk+ixSVnVuUt2kSEUoEWmvL8tx+nJcBd/yFviEj8LLLLCYq5sxfLdJ5Sx/mh2cL/9u ZQUFBf9iZe7virXj58EruBSewYfhUcUSxTzFA4qJipE6NgCXwVicpDeYvvo+a6W6VeAtvR3twjPy PR6Si/ihJNA60RiUFjRDutMofZ2mSz7dK8uoob4Wb5NCukUeojLyRyqmY1dtTyqy99Al24TO27p0 1nakb+wQ+tTO0rr0BK3RPX5Y69Vse4km2Jt4qG3Cfex93NmO57vsEm6sZ6uW3c0V7UlOsvGReHuB y9ijXN7u5ep2MyfbF7iFXcH32lnczd7PGTZDOTpyrvLk26o835bhFZbVzlmt8UfpXfsrvW+Bt9my vNPW4L2qd9C24yO2Fx+3Q/ms7cRo63NJSdLdu0T15Vu6S7ZSD1lLQ2UhTZEJtFAy6ClpS29ILdol pel7+Q0vyl8xAfZgZb0JVoGLWBXiqBrcTDXgdn2X3kl14A+UDAOpsb5b20EypetbdZS+VWfCcVwJ +3C9vnM/hWfxB92XIpiKt5ih+jbthr00R0001XCFKYlvmIvBIfN7sMdEgq2mGL5myuCTmoUfMrfj ZNNIs34brQRdMNlkYFkzQnkm63u3APfoe/oteFJvqG7//91J+u9/Rf6fJ6mij5FSMA3byxjsqUiV +R49ZRoO8u18bad5tJfrs1bNW0uCdOwvDpnYXYaqtXHKPM1jkExU5OJgmYADFf09nO71Wb7ZW05Q y91j6B9j7w4TYrLrs1DbWyir8ZYF+ThSWUfCcBwBWdjfszsr47Eb5GJXmKTIVyzwuq6N9t3ccPYz HzOVLcczLvDIUVmebxdom++RGZK14spaFGR6RsdcFOTB6SAn1kb7Ticca0XBSGXL8oyO+XSQpbKu vj2tbZHHSAjnrFbVfXOoqPuYpPtpdF8du7MiinjduzjdV6M6JqYbzlmtqucziu4x9v5iYrJwzmqC RjcGGtUaezdqHFbSeKwas2I0/uI1DkHjEYNBciboGWujfTc3nP3EIF3ZUj2jYz4TpKqlFN+e0RY9 0kOy5jLcNEz3jI55Gqb4jBdto32nc313j5beWiXNq465p4xXjMLeMhz7asbrr+iu2SEdRmvETPRZ wMFFjEMWgP4uqWNJqnOj6t6oc5J0bqJyxPldc3DcqSF9l8HUQdKpl6KTjPfoJUNpsG/H0yDfdzrh RFUbGigO91Bv6UxdpRelenZnJUsrc18aplV5iOg708PphrPOrpSq1lO8B1H2FJXVi8mjY64fTgzn KpNDV4962r+G67XQwluoCEuoMqymJHicKkGh3k1WUkNYSi3gIWoDc6g9TKWOMS/qwWSqC3mKqVQb pqvuDL3TzNT5s6gczFaOJSTi2tnaLvGoHFLOXqSshcq2xEP0VimyzstcG+07nXCsFVKmsuV4xnUe OSrL8+06bQs9wqp+WzRuN2isOkbHvEEr4Bovc220vyW06rdB76RbMMkzrvFIUpmIa9dou8EjrH17 RVk3K9sGD5HNip1e5tpo3+lcn7Vrf2n8BlM99mNH2IHt4UNso/foFrAJG6r1mrAeK3lrzupnWE7f MZVhN1aDz3VsP9aGA1gXDiq+wXoxpIb0HRL8/0Slxjysp/16cAZTvDxBo8uNuX44WSNB81IUKd7K Ga3FDgnXnQWvVf4L2EtOYAe5pPUjgl2lmOZhx+6snMUhch6HyS84VH7SG8Bh1Y22g3zfzQ3nqx7H PsrWyTMe9ugkx7Glbw9re9yjT0jWXGUbQn08o2MeQi19pYu20b7TCeevDkM8cy+tZOnSgzKkG2VL V/3CXXVPcxVTNEfnU3PN0U1gHjWABfqmXKT5eDFV0AzpMqODyyIOLuKS4D2soHFfTeOiDnyMDTQO mujZb67nvoWeSndCHQZKgNlyBTN0F9N1pb0UzpdOEk6UtuPm4tCXW8j93FpmcTtZwd3kOc6WjTxG 3uNZ8iGvkmcVT/N8KeR8Wcq5UsDDJY/7yzDOkF7cWzl6xdA8JM+20ypx2EmzZD+Nlh8oS85TN4lT D8urpw3U46j3vaSJelBNPSmjHkVouOqNk5M0Xf5K83XeKg/HFU5Eb6e0GFbF2NPgh5gsnIjeSP1g q2fsFkOU3Vn5Tsf+QsNhF41SndGwV39v9Ejzc1w/nBjbqvVvo55ax7jXI0dlmTF5dMz1w7HWinMg mfM8o7OSzJlQWWWtPPL8mOuHYy2Z05Stn2es7NFPZaNj8uiY64dzQ66jTNdQ27fdPLuzWJ1Hwa08 DEpzFiSqLDGmF85ZrcNPSBRpMfYnJDEmCydOe3CBOHTmuXIvz5OW/Gdpygs1Ph+W+rxCLT3qrTmr pXmplFWdCppFavIkacjjVH+MdOCRypETQ0FInk1Ri1E8KpPUk/G8RMaoZyPUwwHqRV/1OOp9jmSr ByPUk/HqUb56NpcfkIWqs1Q9Xq4cy2Nc4ezKFN2JKJ6IsafB8pgsnAwyUM/vWGWb/E9LUTgrS3Rs Lo+AqXr6xiry9fdAjzQ/x/XDibKxGrMDNbocY75HjsoyY/LomOuHY+2Qsu1UtrEemdrPhM0qO+SR 58cOhZZBduqXOqRrcoybPfqpbHRMHh3bGVoG+VCZruEDzR7bFI7dWdyiGWQjD4cX1OKzKns2phfO WXXVP4q0GHv0NuBk13e7mukttIXXlWmDxuHzGneFeq9YyJkynXvISP6DpHNHrfAdpJG2t+nvBJVf oUyt7sPkCE2Ug1QgX2oN/lIr3xeUDnu0cuygbK0groK6iuLQD2pyNlTR81CRe0MFXUUFjbqK/IhU 4UVyu8Z5st5zmmlWasNTJZWnaE7Ik0xth+jvMSqfpOPTVW+W6hfovLk6f67yPMjpMEMz9xQfbw7u DDr00y+XDe+ozU2q87rqvv4vvli8/1L/AEiBRDRrABYkARckAUlmAQAAAAGWAAAhdgADaAEjdgAB CwUjdgECYBwjdgIDeAU6VgsAApZsAAM0ART2A+MmGPYDAAA11gUAAQMLBTXWBQECA2AcNdYFAgMD eAU01gYAAQUAAABmNAF5dAUUJgCKVAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA XgRzABIAAQALAQ8ABwAAAAAAAAAAAAQACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAI AAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAADAGAAAAAAAACAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAMgYAABgAAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAgBAAA MAQAAEAEAABQBAAAYAQAAHAEAACABAAAkAQAAMADAADQAwAA4AMAAPADAAAABAAAEAQAADIGAAAo AgAA2AEAAOgBAAAgBAAAMAQAAEAEAABQBAAAYAQAAHAEAACABAAAkAQAAMADAADQAwAA4AMAAPAD AAAABAAAEAQAACAEAAAwBAAAQAQAAFAEAABgBAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMA AAAEAAAQBAAAIAQAADAEAABABAAAUAQAAGAEAABwBAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAA AAQAABAEAAAgBAAAMAQAAEAEAABQBAAAYAQAAHAEAACABAAAkAQAAMADAADQAwAA4AMAAPADAAAA BAAAEAQAACAEAAAwBAAAQAQAAFAEAABgBAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMAAAAE AAAQBAAAIAQAADAEAABABAAAUAQAAGAEAABwBAAAgAQAAJAEAAA4AQAAWAEAAPgBAAAIAgAAGAIA AFYCAAB+AgAAFAAAAF9IAQRtSAkEbkgECHNICQR0SAQIAAAAAGIAAGDx/wIAYgAMEAAAAAAAAAAA BgBOAG8AcgBtAGEAbAAAACcAAAANxg4ABBoDpwQ0BsEHwMDAwBOkeAA1JAA3JAA4JAA5RAIASCQA ABQAQ0oYAF9IAQRtSAkIc0gJCHRICQRQAAFAAQACAFAADBAAAAAAAAAAAAkASABlAGEAZABpAG4A ZwAgADEAAAAfAAEABSQBBiQBD4QaAxGE5vwTpGgBQCYAXoQaA2CE5vwAAwA1CIEANgACABEAAgA2 AAwQAAAAAAAAAAAJAEgAZQBhAGQAaQBuAGcAIAAyAAAACQACABOk8ABAJgEAAAA2AAMAEQACADYA DBAAAAAAAAAAAAkASABlAGEAZABpAG4AZwAgADMAAAAJAAMAE6SgAEAmAgAAAEwABAAxAAIATAAM EAAAAAAAAAAACQBIAGUAYQBkAGkAbgBnACAANAAAAB8ABAANxgcBGgMB/QPAD4T9AxGEA/xAJgNe hP0DYIQD/AAAADIABQBBAAIAMgAMEAAAAAAAAAAACQBIAGUAYQBkAGkAbgBnACAANQAAAAUABQBA JgQAAABKAAYAQQACAEoADBAAAAAAAAAAAAkASABlAGEAZABpAG4AZwAgADYAAAAeAAYADcYGAv0D pwQAD4Q0BhGEzPlAJgVehDQGYITM+QAAMgAHAGEAAgAyAAwQAAAAAAAAAAAJAEgAZQBhAGQAaQBu AGcAIAA3AAAABQAHAEAmBgAAADIACABhAAIAMgAMEAAAAAAAAAAACQBIAGUAYQBkAGkAbgBnACAA OAAAAAUACABAJgcAAAAyAAkAYQACADIADBAAAAAAAAAAAAkASABlAGEAZABpAG4AZwAgADkAAAAF AAkAQCYIAAAARABBIPL/oQBEAAwBAAAAAAAAAAAWAEQAZQBmAGEAdQBsAHQAIABQAGEAcgBhAGcA cgBhAHAAaAAgAEYAbwBuAHQAAAAAAFYAaUDz/7MAVgAMBQAAAAAAAAAADABUAGEAYgBsAGUAIABO AG8AcgBtAGEAbAAAACAAOlYLABf2AwAANNYGAAEFAwAANNYGAAEKA2wAYfYDAAACAAsAAAAoAGsg 9P/BACgAAAUAAAAAAAAAAAcATgBvACAATABpAHMAdAAAAAIADAAAAAAAVAD+TwEAAgBUAAwAAAAA AAAAAAAQAEEAbgBuAGUAeABfAE4AbwAgACYAIAB0AGkAdABsAGUAAAASAA8AAyQBBSQBBiQBE6Tg AWEkAQcANQiBQ0ocAAA2AP5v8v8BATYADAAAAAAAAAAAAAcAQQBwAHAAXwBkAGUAZgAAAA8ANQiB T0oAAFFKAABrSOQEACYA/g+iABEBJgAMAAAAAAAAAAAABwBBAHAAcABfAHIAZQBmAAAAAABCAP4P 8QACAEIADAAAAAAAAAAAABMAQQBwAHAAZQBuAGQAaQB4AF8ATgBvACAAJgAgAHQAaQB0AGwAZQAA AAIAEgAAADYA/m/y/zEBNgAMAAAAAAAAAAAABwBBAHIAdABfAGQAZQBmAAAADwA1CIFPSgAAUUoA AGtI5AQARAD+TwEAAgBEAAwAAAAAAAAAAAALAEEAcgB0AF8AaABlAGEAZABpAG4AZwAAAAwAFAAD JAETpOABYSQBBwA1CIFDShwAAEAA/k8BAAIAQAAMAAAAAAAAAAAABgBBAHIAdABfAE4AbwAAABIA FQADJAEFJAEGJAETpOABYSQBBwA7CIFDShwAACYA/g+iAGEBJgAMAAAAAAAAAAAABwBBAHIAdABf AHIAZQBmAAAAAABGAP5PAQACAEYADAAAAAAAAAAAAAkAQQByAHQAXwB0AGkAdABsAGUAAAASABcA AyQBBSQBBiQBE6TwAGEkAQcANQiBQ0ocAABwAP5PAQCCAXAABAAAAAAAAAAAAAUAQQBTAE4ALgAx AAAAMQAYAA3GKAQaA6cENAbBBwo3Am4EpQbcCBMLSg2BD7gR7xMmFgAAAAAAAAAAAAATpAAAABoA NQiBQ0oUAE9KBgBRSgYAbUgABG5IAAR1CAE6AP5PAQACADoADAAAAAAAAAAAAAQAQwBhAGwAbAAA ABQAGQAFJAEGJAEPhBoDE6SgAF6EGgMDADYIgQBWAP5PAQACAFYADAAAAAAAAAAAAAcAQwBoAGEA cABfAE4AbwAAACMAGgADJAEFJAEGJAENxg4ABBoDpwQ0BsEHAAAAABOk4AFhJAEACgA1CIE7CIFD ShwASAD+TwEAAgBIAAwAAAAAAAAAAAAKAEMAaABhAHAAXwB0AGkAdABsAGUAAAASABsAAyQBBSQB BiQBE6TwAGEkAQcANQiBQ0ocAAA+ACpg8v/BAT4ADAEAAAAAAAAAABEARQBuAGQAbgBvAHQAZQAg AFIAZQBmAGUAcgBlAG4AYwBlAAAAAwBIKgEAQAD+DwEA0gFAAAwAAAAAAAAAAAAIAGUAbgB1AG0A bABlAHYAMQAAABYAHQAPhBoDEYTm/BOkUABehBoDYITm/AAAPAD+D9EB4gE8AAwAAAAAAAAAAAAI AGUAbgB1AG0AbABlAHYAMgAAABIAHgAPhKcEEYRz/l6EpwRghHP+AAA0AP4P4QHyATQADAAAAAAA AAAAAAgAZQBuAHUAbQBsAGUAdgAzAAAACgAfAA+ENAZehDQGAAA+AP4PAQACAj4ADAAAAAAAAAAA AAgARQBxAHUAYQB0AGkAbwBuAAAAEwAgAA3GDgOnBDQGwQcC1BKnJcHCAAAAXAD+DwEAEgJcAAwA AAAAAAAAAAAPAEUAcQB1AGEAdABpAG8AbgBfAGwAZQBnAGUAbgBkAAAAJAAhAA3GCwMaA6cENAYB FgfCD4TBBxGEP/gTpFAAXoTBB2CEP/gAADwA/g8BAAIAPAAMAAAAAAAAAAAABgBGAGkAZwB1AHIA ZQAAABYAIgADJAEFJAEGJAETpPAAFKR4AGEkAQAAVgD+TwEAMgJWAAwAAAAAAAAAAAANAEYAaQBn AHUAcgBlAF8AbABlAGcAZQBuAGQAAAAdACMABSQBBiQBDcYKBBoDpwQ0BsEHABOkFAAUpBQAAAQA Q0oSAFQA/k8BAAIAVAAMAAAAAAAAAAAAEQBGAGkAZwB1AHIAZQBfAE4AbwAgACYAIAB0AGkAdABs AGUAAAATACQAAyQBBSQBE6TwABSkeABhJAEAAwA1CIEATAD+TwEAAgBMAAwAAAAAAAAAAAAMAEYA aQBnAHUAcgBlAF8ATgBvAF8AQgBSAAAAFgAlAAMkAQUkAQYkAROk4AEUpHgAYSQBAwA7CIEAUAD+ TwEAAgBQAAwAAAAAAAAAAAAOAFQAYQBiAGwAZQBfAHQAaQB0AGwAZQBfAEIAUgAAABYAJgADJAEF JAEGJAETpAAAFKR4AGEkAQMANQiBAEIA/g9hAgIAQgAMAAAAAAAAAAAADwBGAGkAZwB1AHIAZQBf AHQAaQB0AGwAZQBfAEIAUgAAAAkAJwAGJAAUpOABAAAAVgD+DwEAAgBWAAwAAAAAAAAAAAAUAEYA aQBnAHUAcgBlAF8AdwBpAHQAaABvAHUAdABfAHQAaQB0AGwAZQAAABMAKAADJAEFJAETpPAAFKR4 AGEkAQAAAFIAIEABAJICUgAEAHIAAAAAAAAABgBGAG8AbwB0AGUAcgAAABkAKQANxhAEGgOnBDQG wQcCQhenJQACE6QAAAASADsIgUNKEABtSAAEbkgABHUIAVYA/k+RAqICVgAMAAAAAAAAAAAACwBG AGkAcgBzAHQARgBvAG8AdABlAHIAAAAfACoADcYGAkIXpyUAE6QoADUkATckATgkATlEBABIJAEA BgA7CIF1CABQAP5PAQCyAlAADAAAAAAAAAAAAAkARgBvAG8AdABlAHIAXwBRAFAAAAAcACsADcYT BBoDpwQ0BsEHA4sDVSKnJcDCwhOkAAAHADUIgUNKFgAARAAmYPL/wQJEAAwBAAAAAAAAAAASAEYA bwBvAHQAbgBvAHQAZQAgAFIAZQBmAGUAcgBlAG4AYwBlAAAACABDShIARUgGADoA/g8BANICOgAM AAAAAAAAAAAABABOAG8AdABlAAAAFwAtAA3GDgAEGgOnBDQGwQcAAAAAE6RQAAAAAFIAHQDRAuIC UgAMAQAAAAAAAAAADQBGAG8AbwB0AG4AbwB0AGUAIABUAGUAeAB0AAAAHQAuAAUkAQ3GBQAB/wAA D4T/ABGEAf9ehP8AYIQB/wAAAFAA/k+BAfICUAAEAAAAAAAAAAAABgBGAG8AcgBtAGEAbAAAACUA LwANxiAACjcCbgSlBtwIEwtKDYEPuBHvEyYWwMDAwMDAwMDAwAADADUIgQCaAB9AAQACA5oADABx AAAAAAAAADEASABlAGEAZABlAHIALABoAGUAYQBkAGUAcgAgAG8AZABkACwAaABlAGEAZABlAHIA IABlAG4AdAByAHkALABIAEUALABoACwASABlAGEAZABlAHIALwBGAG8AbwB0AGUAcgAAABkAMAAD JAENxgoEGgOnBDQGwQcAE6QAAGEkAQAEAENKEgA6AP5PAQACADoADAAAAAAAAAAAAAkASABlAGEA ZABpAG4AZwBfAGIAAAAJADEABiQBE6SgAAADADUIgQA6AP5PAQACADoADAAAAAAAAAAAAAkASABl AGEAZABpAG4AZwBfAGkAAAAJADIABiQBE6SgAAADADYIgQAqAAoAAQACACoADAEAAAAAAAAAAAcA SQBuAGQAZQB4ACAAMQAAAAIAMwAAADIACwABAAIAMgAMAQAAAAAAAAAABwBJAG4AZABlAHgAIAAy AAAACgA0AA+EGwFehBsBAAAyAAwAAQACADIADAEAAAAAAAAAAAcASQBuAGQAZQB4ACAAMwAAAAoA NQAPhDYCXoQ2AgAARAD+DwEAAgBEAAwAAAAAAAAAAAASAE4AbwByAG0AYQBsAF8AYQBmAHQAZQBy AF8AdABpAHQAbABlAAAABgA2ABOkaAEAAC4AKQCiAHEDLgAMAAAAAAAAAAAACwBQAGEAZwBlACAA TgB1AG0AYgBlAHIAAAAAAEYA/k8BAAIARgAMAAAAAAAAAAAABwBQAGEAcgB0AF8ATgBvAAAAFgA4 AAMkAQUkAQYkAROk4AEUpFAAYSQBBwA7CIFDShwAADwA/g8BAAIAPAAMAAAAAAAAAAAACABQAGEA cgB0AF8AcgBlAGYAAAASADkAAyQBBSQBBiQBE6QYAWEkAQAATAD+TwEAYgNMAAwAAAAAAAAAAAAK AFAAYQByAHQAXwB0AGkAdABsAGUAAAAWADoAAyQBBSQBBiQBE6TwABSkGAFhJAEHADUIgUNKHAAA TgD+TwEAYgNOAAwAAAAAAAAAAAAIAFIAZQBjAF8AZABhAHQAZQAAABsAOwADJAIFJAEGJAENxgoE GgOnBDQGwQcAYSQCAAcANgiBQ0oWAAA2AP4PsQNiAzYADAAAAAAAAAAAAA0AUQB1AGUAcwB0AGkA bwBuAF8AZABhAHQAZQAAAAIAPAAAADoA/k8BAAIAOgAMAAAAAAAAAAAABgBSAGUAYwBfAE4AbwAA AAwAPQAFJAEGJAETpAAABwA1CIFDShwAADIA/g/RAwIAMgAMAAAAAAAAAAAACwBRAHUAZQBzAHQA aQBvAG4AXwBOAG8AAAACAD4AAABGAP5PAQACAEYADAAAAAAAAAAAAAkAUgBlAGMAXwBOAG8AXwBC AFIAAAASAD8AAyQBBSQBBiQBE6TgAWEkAQcAOwiBQ0ocAAA4AP4P8QMCADgADAAAAAAAAAAAAA4A UQB1AGUAcwB0AGkAbwBuAF8ATgBvAF8AQgBSAAAAAgBAAAAASAD+TwEAsgNIAAwAAAAAAAAAAAAH AFIAZQBjAF8AcgBlAGYAAAAbAEEAAyQBBSQBBiQBDcYKBBoDpwQ0BsEHAGEkAQADADYIgQA0AP4P EQTCAzQADAAAAAAAAAAAAAwAUQB1AGUAcwB0AGkAbwBuAF8AcgBlAGYAAAACAEIAAABGAP5PAQBi A0YADAAAAAAAAAAAAAkAUgBlAGMAXwB0AGkAdABsAGUAAAASAEMAAyQBBSQBBiQBE6RoAWEkAQcA NQiBQ0ocAAA4AP4PMQQiBDgADAAAAAAAAAAAAA4AUQB1AGUAcwB0AGkAbwBuAF8AdABpAHQAbABl AAAAAgBEAAAAKgD+b/L/UQQqAAwAAAAAAAAAAAAHAFIAZQBjAF8AZABlAGYAAAADADUIgQA8AP4P AQBiBDwADAAAAAAAAAAAAAgAUgBlAGYAXwB0AGUAeAB0AAAAEgBGAA+EGgMRhOb8XoQaA2CE5vwA ADwA/k8BAGIEPAAMAAAAAAAAAAAACQBSAGUAZgBfAHQAaQB0AGwAZQAAAAwARwADJAETpOABYSQB AwA1CIEALAD+D7EDYgMsAAwAAAAAAAAAAAAIAFIAZQBwAF8AZABhAHQAZQAAAAIASAAAACgA/g/R AwIAKAAMAAAAAAAAAAAABgBSAGUAcABfAE4AbwAAAAIASQAAAC4A/g/xAwIALgAMAAAAAAAAAAAA CQBSAGUAcABfAE4AbwBfAEIAUgAAAAIASgAAACoA/g8RBIIEKgAMAAAAAAAAAAAABwBSAGUAcABf AHIAZQBmAAAAAgBLAAAALgD+DzEEsgQuAAwAAAAAAAAAAAAJAFIAZQBwAF8AdABpAHQAbABlAAAA AgBMAAAALAD+D7EDYgMsAAwAAAAAAAAAAAAIAFIAZQBzAF8AZABhAHQAZQAAAAIATQAAADYA/m/y /+EENgAMAAAAAAAAAAAABwBSAGUAcwBfAGQAZQBmAAAADwA1CIFPSgAAUUoAAGtI5AQAKAD+D9ED AgAoAAwAAAAAAAAAAAAGAFIAZQBzAF8ATgBvAAAAAgBPAAAALgD+D/EDAgAuAAwAAAAAAAAAAAAJ AFIAZQBzAF8ATgBvAF8AQgBSAAAAAgBQAAAAKgD+DxEE0gQqAAwAAAAAAAAAAAAHAFIAZQBzAF8A cgBlAGYAAAACAFEAAAAuAP4PMQQSBS4ADAAAAAAAAAAAAAkAUgBlAHMAXwB0AGkAdABsAGUAAAAC AFIAAABKAP5PAQACAEoADAAAAAAAAAAAAAkAUwBlAGMAdABpAG8AbgBfADEAAAAZAFMAAyQBDcYK BBoDpwQ0BsEHABOkcAJhJAEAAwA1CIEASgD+TwEAAgBKAAwAAAAAAAAAAAAJAFMAZQBjAHQAaQBv AG4AXwAyAAAAGQBUAAMkAQ3GCgQaA6cENAbBBwATpPAAYSQBAAMANgiBAEwA/k8BAAIATAAMAAAA AAAAAAAACgBTAGUAYwB0AGkAbwBuAF8ATgBvAAAAFgBVAAMkAQUkAQYkAROk4AEUpFAAYSQBBwA7 CIFDShwAAFIA/k8BAGIDUgAMAAAAAAAAAAAADQBTAGUAYwB0AGkAbwBuAF8AdABpAHQAbABlAAAA FgBWAAMkAQUkAQYkAROk4AEUpBgBYSQBBwA1CIFDShwAAD4A/k8BAGIDPgAMAAAAAAAAAAAABgBT AG8AdQByAGMAZQAAABAAVwADJAETpEgDFKTIAGEkAQcANQiBQ0ocAABYAP5PkQKCBVgADAAAAAAA AAAAAA4AUwBwAGUAYwBpAGEAbAAgAEYAbwBvAHQAZQByAAAAHABYAAMkAw3GEQAFNwJuBKUG3AgT C8DAwMDAYSQDBgA7CIF1CAA4AP5v8v+RBTgADAAAAAAAAAAAAAoAVABhAGIAbABlAF8AZgByAGUA cQAAAAwANQiBQioAcGgAAAD/fAD+TwEAAgB8AAwAAAAAAAAAAAAKAFQAYQBiAGwAZQBfAGgAZQBh AGQAAABFAFoAAyQBBiQBDcYvAxoDpwQ0Bg0cATcCUwNuBIoFpQbcCPgJEwsvDEoNZg6BD8DAwMDA wMDAwMDAwMATpFAAFKRQAGEkAQAHADUIgUNKFgAAbgD+TwEAsgVuAAwAAAAAAAAAAAAMAFQAYQBi AGwAZQBfAGwAZQBnAGUAbgBkAAAAOABbAA3GLwMaA6cENAYNHAE3AlMDbgSKBaUG3Aj4CRMLLwxK DWYOgQ/AwMDAwMDAwMDAwMDAFKQoAAQAQ0oWAFQA/k8BAKIFVAAMAAAAAAAAAAAAEABUAGEAYgBs AGUAXwBOAG8AIAAmACAAdABpAHQAbABlAAAAFgBcAAMkAQUkAQYkAROkaAEUpHgAYSQBAwA1CIEA SAD+TwEAYgJIAAwAAAAAAAAAAAALAFQAYQBiAGwAZQBfAE4AbwBfAEIAUgAAABMAXQADJAEGJAET pDACFKR4AGEkAQADADsIgQBAAP4PAQBiAkAADAAAAAAAAAAAAAkAVABhAGIAbABlAF8AcgBlAGYA AAATAF4AAyQBBiQBE6QAABSkeABhJAEAAAByAP5PAQDyBXIADAAAAAAAAAAAAAoAVABhAGIAbABl AF8AdABlAHgAdAAAAD8AXwANxjIDGgOnBDQGDhwBNwJTA24EigWlBsEH3Aj4CRMLLwxKDWYOgQ9A QEBAQEBAQEBAQEBAQBOkKAAUpCgAAAQAQ0oWAFQA/k9xBQIAVAAMAAAAAAAAAAAABwBUAGkAdABs AGUAIAAxAAAAJgBgAA3GGQQaA6cENAbBBwU3Am4EpQbcCBMLwMDAwMATpPAAFKQAAAYANQiBOwiB KgD+TwEGAgAqAAwAAAAAAAAAAAAHAFQAaQB0AGwAZQAgADIAAAACAGEAAAAuAP5PEQYCAC4ADAAA AAAAAAAAAAcAVABpAHQAbABlACAAMwAAAAIAYgADADsIgQAuAP5PIQYSAC4ADAAAAAAAAAAAAAcA VABpAHQAbABlACAANAAAAAIAYwADADUIgQA6AP5PAQBSBjoADAAAAAAAAAAAAAUAdABvAGMAIAAw AAAAEgBkAA3GDQQaA6cENAbBBwGnJQIDADUIgQBcABMAAQBSBlwADAEAAAAAAAAAAAUAVABPAEMA IAAxAAAANwBlAAUkAQ3GEwQaA6cENAbBBwPEA1UipyUACAIOhFMDD4SoAhGEWP0TpPAAXYRTA16E qAJghFj9AAAAOgAUAFEGYgY6AAwBAAAAAAAAAAAFAFQATwBDACAAMgAAABYAZgAPhPsFEYSt/BOk UABehPsFYISt/AAAJgAVAGEGcgYmAAwBAAAAAAAAAAAFAFQATwBDACAAMwAAAAIAZwAAACYAFgBx BoIGJgAMAQAAAAAAAAAABQBUAE8AQwAgADQAAAACAGgAAAAmABcAgQaSBiYADAEAAAAAAAAAAAUA VABPAEMAIAA1AAAAAgBpAAAAJgAYAIEGogYmAAwBAAAAAAAAAAAFAFQATwBDACAANgAAAAIAagAA ACYAGQCBBrIGJgAMAQAAAAAAAAAABQBUAE8AQwAgADcAAAACAGsAAAAmABoAgQbCBiYADAEAAAAA AAAAAAUAVABPAEMAIAA4AAAAAgBsAAAAXgBVYPL/0QZeAAwEAAB7EhIAMAYdAEgAeQBwAGUAcgBs AGkAbgBrACwAhY2nfv6UpWMsAFMAdAB5AGwAZQAgADUAOAAsAIWNPwA/AD8APwAAAAwAPioBQioA cGgAAP8ATACZQAEA4gZMAAwEbwCqRycAAAAMAEIAYQBsAGwAbwBvAG4AIABUAGUAeAB0AAAABgBu ABOkAAAUAENKEABPSgcAUUoHAF5KBwBhShAAVgD+b/L/8QZWAAwAbgCqRycAAAARAEIAYQBsAGwA bwBvAG4AIABUAGUAeAB0ACAAQwBoAGEAcgAAABwAQ0oQAE9KBwBRSgcAXkoHAGFKEABtSAkIc0gJ CEYAVmDy/wEHRgAMBAAA7T9uAAAAEQBGAG8AbABsAG8AdwBlAGQASAB5AHAAZQByAGwAaQBuAGsA AAAMAD4qAUIqAHBogACAAMYA/m/y/xEHxgAMADAA11jLAAAATwBIAGUAYQBkAGUAcgAgAEMAaABh AHIALABoAGUAYQBkAGUAcgAgAG8AZABkACAAQwBoAGEAcgAsAGgAZQBhAGQAZQByACAAZQBuAHQA cgB5ACAAQwBoAGEAcgAsAEgARQAgAEMAaABhAHIALABoACAAQwBoAGEAcgAsAEgAZQBhAGQAZQBy AC8ARgBvAG8AdABlAHIAIABDAGgAYQByAAAAEABDShIAbUgJCHNICQh0SAkESAD+b/L/IQdIAAQA KQBuZOsAAAALAEYAbwBvAHQAZQByACAAQwBoAGEAcgAAABoAOwiBQ0oQAG1IAARuSAAEc0gJCHRI CQR1CAFQSwMEFAAGAAgAAAAhAOneD7//AAAAHAIAABMAAABbQ29udGVudF9UeXBlc10ueG1srJHL TsMwEEX3SPyD5S1KnLJACCXpgseOx6J8wMiZJBbJ2LKnVfv3TNJUQqggFmws2TP3njvjcr0fB7XD mJynSq/yQisk6xtHXaXfN0/ZrVaJgRoYPGGlD5j0ur68KDeHgEmJmlKle+ZwZ0yyPY6Qch+QpNL6 OALLNXYmgP2ADs11UdwY64mROOPJQ9flA7awHVg97uX5mCTikLS6PzZOrEpDCIOzwJLU7Kj5RskW Qi7KuSf1LqQriaHNWcJU+Rmw6F5lNdE1qN4g8guMEsOwDIlfz2cgGS3mvzueiezb1llsvN2Oso58 Nl7MTsH/FGD1P+gT08x/W38CAAD//wMAUEsDBBQABgAIAAAAIQCl1qfnwAAAADYBAAALAAAAX3Jl bHMvLnJlbHOEj89qwzAMh++FvYPRfVHSwxgldi+lkEMvo30A4Sh/aCIb2xvr20/HBgq7CISk7/ep Pf6ui/nhlOcgFpqqBsPiQz/LaOF2Pb9/gsmFpKclCFt4cIaje9u1X7xQ0aM8zTEbpUi2MJUSD4jZ T7xSrkJk0ckQ0kpF2zRiJH+nkXFf1x+YnhngNkzT9RZS1zdgro+oyf+zwzDMnk/Bf68s5UUEbjeU TGnkYqGoL+NTvZCoZarUHtC1uPnW/QEAAP//AwBQSwMEFAAGAAgAAAAhAGt5lhaDAAAAigAAABwA AAB0aGVtZS90aGVtZS90aGVtZU1hbmFnZXIueG1sDMxNCsMgEEDhfaF3kNk3Y7soRWKyy6679gBD nBpBx6DSn9vX5eODN87fFNWbSw1ZLJwHDYplzS6It/B8LKcbqNpIHMUsbOHHFebpeBjJtI0T30nI c1F9I9WQha213SDWtSvVIe8s3V65JGo9i0dX6NP3KeJF6ysmCgI4/QEAAP//AwBQSwMEFAAGAAgA AAAhADDdQymoBgAApBsAABYAAAB0aGVtZS90aGVtZS90aGVtZTEueG1s7FlPb9s2FL8P2HcgdG9j J3YaB3WK2LGbLU0bxG6HHmmJlthQokDSSX0b2uOAAcO6YYcV2G2HYVuBFtil+zTZOmwd0K+wR1KS xVhekjbYiq0+JBL54/v/Hh+pq9fuxwwdEiEpT9pe/XLNQyTxeUCTsO3dHvYvrXlIKpwEmPGEtL0p kd61jfffu4rXVURigmB9Itdx24uUSteXlqQPw1he5ilJYG7MRYwVvIpwKRD4COjGbGm5VltdijFN PJTgGMjeGo+pT9BQk/Q2cuI9Bq+JknrAZ2KgSRNnhcEGB3WNkFPZZQIdYtb2gE/Aj4bkvvIQw1LB RNurmZ+3tHF1Ca9ni5hasLa0rm9+2bpsQXCwbHiKcFQwrfcbrStbBX0DYGoe1+v1ur16Qc8AsO+D plaWMs1Gf63eyWmWQPZxnna31qw1XHyJ/sqczK1Op9NsZbJYogZkHxtz+LXaamNz2cEbkMU35/CN zma3u+rgDcjiV+fw/Sut1YaLN6CI0eRgDq0d2u9n1AvImLPtSvgawNdqGXyGgmgookuzGPNELYq1 GN/jog8ADWRY0QSpaUrG2Ico7uJ4JCjWDPA6waUZO+TLuSHNC0lf0FS1vQ9TDBkxo/fq+fevnj9F xw+eHT/46fjhw+MHP1pCzqptnITlVS+//ezPxx+jP55+8/LRF9V4Wcb/+sMnv/z8eTUQ0mcmzosv n/z27MmLrz79/btHFfBNgUdl+JDGRKKb5Ajt8xgUM1ZxJScjcb4VwwjT8orNJJQ4wZpLBf2eihz0 zSlmmXccOTrEteAdAeWjCnh9cs8ReBCJiaIVnHei2AHucs46XFRaYUfzKpl5OEnCauZiUsbtY3xY xbuLE8e/vUkKdTMPS0fxbkQcMfcYThQOSUIU0nP8gJAK7e5S6th1l/qCSz5W6C5FHUwrTTKkIyea Zou2aQx+mVbpDP52bLN7B3U4q9J6ixy6SMgKzCqEHxLmmPE6nigcV5Ec4piVDX4Dq6hKyMFU+GVc TyrwdEgYR72ASFm15pYAfUtO38FQsSrdvsumsYsUih5U0byBOS8jt/hBN8JxWoUd0CQqYz+QBxCi GO1xVQXf5W6G6HfwA04WuvsOJY67T68Gt2noiDQLED0zERW+vE64E7+DKRtjYkoNFHWnVsc0+bvC zShUbsvh4go3lMoXXz+ukPttLdmbsHtV5cz2iUK9CHeyPHe5COjbX5238CTZI5AQ81vUu+L8rjh7 //nivCifL74kz6owFGjdi9hG27Td8cKue0wZG6gpIzekabwl7D1BHwb1OnPiJMUpLI3gUWcyMHBw ocBmDRJcfURVNIhwCk173dNEQpmRDiVKuYTDohmupK3x0Pgre9Rs6kOIrRwSq10e2OEVPZyfNQoy RqrQHGhzRiuawFmZrVzJiIJur8OsroU6M7e6Ec0URYdbobI2sTmUg8kL1WCwsCY0NQhaIbDyKpz5 NWs47GBGAm1366PcLcYLF+kiGeGAZD7Ses/7qG6clMfKnCJaDxsM+uB4itVK3Fqa7BtwO4uTyuwa C9jl3nsTL+URPPMSUDuZjiwpJydL0FHbazWXmx7ycdr2xnBOhsc4Ba9L3UdiFsJlk6+EDftTk9lk +cybrVwxNwnqcPVh7T6nsFMHUiHVFpaRDQ0zlYUASzQnK/9yE8x6UQpUVKOzSbGyBsHwr0kBdnRd S8Zj4quys0sj2nb2NSulfKKIGETBERqxidjH4H4dqqBPQCVcd5iKoF/gbk5b20y5xTlLuvKNmMHZ cczSCGflVqdonskWbgpSIYN5K4kHulXKbpQ7vyom5S9IlXIY/89U0fsJ3D6sBNoDPlwNC4x0prQ9 LlTEoQqlEfX7AhoHUzsgWuB+F6YhqOCC2vwX5FD/tzlnaZi0hkOk2qchEhT2IxUJQvagLJnoO4VY Pdu7LEmWETIRVRJXplbsETkkbKhr4Kre2z0UQaibapKVAYM7GX/ue5ZBo1A3OeV8cypZsffaHPin Ox+bzKCUW4dNQ5PbvxCxaA9mu6pdb5bne29ZET0xa7MaeVYAs9JW0MrS/jVFOOdWayvWnMbLzVw4 8OK8xjBYNEQp3CEh/Qf2Pyp8Zr926A11yPehtiL4eKGJQdhAVF+yjQfSBdIOjqBxsoM2mDQpa9qs ddJWyzfrC+50C74njK0lO4u/z2nsojlz2Tm5eJHGzizs2NqOLTQ1ePZkisLQOD/IGMeYz2TlL1l8 dA8cvQXfDCZMSRNM8J1KYOihByYPIPktR7N04y8AAAD//wMAUEsDBBQABgAIAAAAIQAN0ZCftgAA ABsBAAAnAAAAdGhlbWUvdGhlbWUvX3JlbHMvdGhlbWVNYW5hZ2VyLnhtbC5yZWxzhI9NCsIwFIT3 gncIb2/TuhCRJt2I0K3UA4TkNQ02PyRR7O0NriwILodhvplpu5edyRNjMt4xaKoaCDrplXGawW24 7I5AUhZOidk7ZLBggo5vN+0VZ5FLKE0mJFIoLjGYcg4nSpOc0IpU+YCuOKOPVuQio6ZByLvQSPd1 faDxmwF8xSS9YhB71QAZllCa/7P9OBqJZy8fFl3+UUFz2YUFKKLGzOAjm6pMBMpburrE3wAAAP// AwBQSwECLQAUAAYACAAAACEA6d4Pv/8AAAAcAgAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRf VHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCl1qfnwAAAADYBAAALAAAAAAAAAAAAAAAAADABAABf cmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBreZYWgwAAAIoAAAAcAAAAAAAAAAAAAAAAABkCAAB0 aGVtZS90aGVtZS90aGVtZU1hbmFnZXIueG1sUEsBAi0AFAAGAAgAAAAhADDdQymoBgAApBsAABYA AAAAAAAAAAAAAAAA1gIAAHRoZW1lL3RoZW1lL3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEADdGQ n7YAAAAbAQAAJwAAAAAAAAAAAAAAAACyCQAAdGhlbWUvdGhlbWUvX3JlbHMvdGhlbWVNYW5hZ2Vy LnhtbC5yZWxzUEsFBgAAAAAFAAUAXQEAAK0KAAAAADw/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rp bmc9IlVURi04IiBzdGFuZGFsb25lPSJ5ZXMiPz4NCjxhOmNsck1hcCB4bWxuczphPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvZHJhd2luZ21sLzIwMDYvbWFpbiIgYmcxPSJsdDEi IHR4MT0iZGsxIiBiZzI9Imx0MiIgdHgyPSJkazIiIGFjY2VudDE9ImFjY2VudDEiIGFjY2VudDI9 ImFjY2VudDIiIGFjY2VudDM9ImFjY2VudDMiIGFjY2VudDQ9ImFjY2VudDQiIGFjY2VudDU9ImFj Y2VudDUiIGFjY2VudDY9ImFjY2VudDYiIGhsaW5rPSJobGluayIgZm9sSGxpbms9ImZvbEhsaW5r Ii8+AAAAACwSAAAlAABCAAAAAP////8AAAAAAwAAAAYAAAAGAAAACQAAAAwAAAAMAAAADgAAADYA AAA4AAAAOgAAADwAAAA+AAAAQQAAAAAIAAABCQAATQoAAPoLAAC3DgAANxAAANASAAB3EwAANBkA ACwaAAAOAAAAEwAAABQAAAAWAAAAFwAAABgAAAAaAAAAHAAAAB8AAAAACAAApggAAMoIAAD5CAAA GgoAAK4SAAAuEwAAXRMAAO8WAAD1GQAALBoAAA8AAAAQAAAAEQAAABIAAAAVAAAAGQAAABsAAAAd AAAAHgAAACAAAABzAwAA6QMAAPgDAAA+BQAAcQUAAJYFAAD6BgAAIQcAADMHAADFBwAA9wcAABsI AABJCQAAqwkAAP8JAAAsEgAAE1gU/5WME1gU/xWAE1gU/xWAE1gU/xWAE1gU/xWAEAAAACcAAAAp AAAAQQAAABMhFP+VgA8AAPBAAAAAAAAG8CAAAAABCAAAAwAAAAIAAAACAAAAAQAAAAIAAAACAAAA AQAAAEAAHvEQAAAA//8AAAAA/wCAgIAA9wAAEAEPAALwSAAAACAACPAIAAAAAQAAAAAIAAAPAAPw MAAAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAACAAABQAAAAAPAALw kgAAABAACPAIAAAAAQAAAAEEAAAPAAPwMAAAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAA AAAAAgAK8AgAAAAABAAABQAAAA8ABPBCAAAAEgAK8AgAAAABBAAAAA4AAFMAC/AeAAAAvwEAABAA ywEAAAAA/wEAAAgABAMJAAAAPwMBAAEAAAAR8AQAAAABAAAA//8KAAAAAwBkAHMAZwAIAGQAdABh AGIAbABlAGEAdQAEAGQAbgB1AG0ABwBkAG8AcgBsAGEAbgBnAAgAZABtAGUAZQB0AGkAbgBnAAkA ZABiAGwAdQBlAHAAaQBuAGsABgBkAHQAaQB0AGwAZQAHAGQAcwBvAHUAcgBjAGUABwBkAHQAaQB0 AGwAZQAxAAkAcwB1AGkAdABlAHQAZQB4AHQAAAAAAAAAAABeAAAApwAAAMgAAADIAAAA4wAAAO0A AAD6AAAAGgIAAC0SAAAAAAGCBwAAAAEAAYICAAGCAwACgwQAAYIFAACBBgABgggAAYIJAAAAXgAA AKcAAADIAAAA4wAAAOMAAADtAAAA+gAAAJMBAACTAQAAGgIAAC0SAAAAAAAAHQoAACkKAADODQAA 1Q0AAOwRAADuEQAA7xEAAPERAADyEQAA9BEAAPURAAD3EQAA+BEAACoSAAAtEgAABwAcAAcAHAAH AAcAAgAHAAIABwACAAcAAgAHAAIAAAAAAGAKAACtCgAAtwsAANULAAABDAAAAwwAAEcMAABPDAAA 1wwAAN0MAADxDQAAag4AAHIOAADtDgAA8Q4AAEIPAAC2EAAAuxAAAO8QAAAuEQAAbhEAAK8RAADs EQAA7hEAAO8RAADxEQAA8hEAAPQRAAD1EQAA9xEAAPgRAAAqEgAALRIAAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAHAAIABwACAAcAAgAHAAIABwACAAAAAAAK BgAACgYAAK4KAACuCgAAhQsAAIULAADlEQAA6xEAAOwRAADuEQAA7xEAAPERAADyEQAA9BEAAPUR AAD3EQAA+BEAAPwRAAAWEgAAKhIAAC0SAAADAAQAAwAEAAMABAADAAQAAwAHAAIABwACAAcAAgAH AAIABAAHAAQAAgABAPv///8uwGzq/w//D/8P/w8FAAYABwAIAAkAAAABAAAAAAABAAAAAAAAAAAA AAAAAAAAAAADGAAAD4SwARGEUP4VxgUAAbABBl6EsAFghFD+bygAAQAAAAEAAAAAAAEDAAAAAAAA AAAAAAAAAAAAAAMYAQAPhEACEYTA/RXGBQABQAIGXoRAAmCEwP1vKAADAAAALgABAAEAAAAAAAED BQAAAAAAAAAAAAAAAAAAAAMYAgAPhNACEYQw/RXGBQAB0AIGXoTQAmCEMP1vKAAFAAAALgABAC4A AgABAAAAAAABAwUHAAAAAAAAAAAAAAAAAAADGAMAD4RgAxGEoPwVxgUAAWADBl6EYANghKD8bygA BwAAAC4AAQAuAAIALgADAAEAAAAAAAEDBQcJAAAAAAAAAAAAAAAAAAMYBAAPhPADEYQQ/BXGBQAB 8AMGXoTwA2CEEPxvKAAJAAAALgABAC4AAgAuAAMALgAEAAEAAAAAAAEDBQcJCwAAAAAAAAAAAAAA AAMYBQAPhIAEEYSA+xXGBQABgAQGXoSABGCEgPtvKAALAAAALgABAC4AAgAuAAMALgAEAC4ABQAB AAAAAAABAwUHCQsNAAAAAAAAAAAAAAADGAYAD4QQBRGE8PoVxgUAARAFBl6EEAVghPD6bygADQAA AC4AAQAuAAIALgADAC4ABAAuAAUALgAGAAEAAAAAAAEDBQcJCw0PAAAAAAAAAAAAAAMYBwAPhKAF EYRg+hXGBQABoAUGXoSgBWCEYPpvKAAPAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAAEA AAAAAAEDBQcJCw0PEQAAAAAAAAAAAAMYCAAPhDAGEYTQ+RXGBQABMAYGXoQwBmCE0PlvKAARAAAA LgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAC4ACAAFAAAA+////wAAAAAAAAAAAAAAAPv///8A AAAAAAAAAAAAAAD7////AAAAAAAAAAAAAAAA+////wAAAAAAAAAAAAAAAPv///8AAAAAAAAAAAAA AAD/////////////////////////////AQAAAAAA//8BAAAAAAABAAAAAAAHBAACCQABAHtLVg0A AAAAAAAAAAABAgACAKAAAAAEAAAACAAAAOUAAAAAAAAAnwAAAP1PBQB9aQcAL3oHAOJcCACpDw4A XnMPALNPEQB7EhIA0zUUALkfFQB4dBgAtQ0ZAD4AGgBUMhsAEhIeAKUIHwCLQSAA9TsiAApIIgDe ViIA/2ciAAUUJgCAFCYAA3MmAKpHJwDEISgA3jYoAERfKQABaSkA1QcrAGFlLACtJS4Acw0yAPMc NABQejYARwQ4ANUSOABbcDgAGG47AC8XPQAUJz0AMB4+AAFnQACLcUEAqwhCALMqRgAVUkkAfHJK APg8TQCHZE8AT1FTAI1XVADsZlkAgw1aAFNsXAD+Al0APB1fAKNxZAAlNmUAqkZmAJEabQA6H20A BVVtAO0/bgBALG8AkxxwAHUucABTbHEADi52AHF7dgCJf3YA8D53AOMuegCwPHoAJHZ7ANsNfQBj RX4AAmJ+AMcmgwAsKoYAmS6GAFI1hwDRUIcAbxWIALYIigCpHosAjSSLAOhcjQCNCZYATn6YAMQY mQB6HpsADy+bAB1gmwBQdJwAAjCdAGZQnQDZaJ0AImyeAL9FnwCCaJ8A5QCjAEhAowBqXKcALWCr AH1FrgAjAa8ApnCxAJtzsgDGCLMA2VKzAFpYswCubrQApmW1AP9XtwCiRLgAZUe4AB1tuADjfLgA Ln24ABkavADuN74A1UG+AOYkxgAwasYAJgXKANdYywDyMs4ATD7PAHF10QDBZtIAN3rVAFV/1gDY VtcAN1vdAHhE3gAwT98ARwTgALUD4gDhJ+IAeXzjAGkq5ABkQuUA6XjlAMo95gBuZOsATWzsAHxO 7QBQVu8AmkbwAAdM8ADXP/IAx1vzAKtJ9AAkGfUAJGH4ABZ9+QD7EPoAKlX7ALpZ/QAAAAAA7BEA AO4RAAAAAAAAAQAAAP9AAYABAOsRAADrEQAAAAAAAAEAAQDrEQAAAAAAAOsRAACU/1cmAhAAAAAA AAAALBIAACgBABAAQAAA//8BAAAABwBVAG4AawBuAG8AdwBuAP//AQAIAAAAAAAAAAAAAAD//wEA AAAAAP//AAACAP//AAAAAP//AAACAP//AAAAAAkAAABHHpABAAACAgYDBQQFAgME/yoA4EF4AMAJ AAAAAAAAAP8BAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1HpABAgAFBQEC AQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzLpABAAACCwYEAgIC AgIE/yoA4EN4AMAJAAAAAAAAAP8BAAAAAAAAQQByAGkAYQBsAAAARz2QAYAKAgIGCQQCBQgDBP8C AOD7/cdqEgAAAAAAAACfAAIAAAAAAE0AUwAgAE0AaQBuAGMAaABvAAAALf8z/yAADmYdZwAAQy6Q AYEAAgsFAwIAAAIABK8CAJD7fNcJEgAAAAAAAAABAAgAAAAAAE0AYQBsAGcAdQBuACAARwBvAHQA aABpAGMAAAA7DpABhgcCAQYAAwEBAQEBAwAAAAAAjygWAAAAAAAAAAEABAAAAAAAUwBpAG0AUwB1 AG4AAACLW1NPAAA/PZABAAACBwMJAgIFAgQEhyoAIAAAAAAAAAAAAAAAAP8BAAAAAAAAQwBvAHUA cgBpAGUAcgAgAE4AZQB3AAAANS6QAQAAAgsGBAMFBAQCBP8uAOFbYADAKQAAAAAAAAD/AQEAAAAA AFQAYQBoAG8AbQBhAAAAQR6QAQAAAgQFAwUEBgMCBP8CAOD/JABCAAAAAAAAAACfAQAAAAAAAEMA YQBtAGIAcgBpAGEAIABNAGEAdABoAAAAIgAEAEMADBhW/DcC5ASpAQAAAAD1whGHMiQcZx4KaIY9 ALcAAACsAgAAQA8AAAIACQAAAAQAgwAgAAAArAIAAEAPAAACAAkAAAAgAAAAAAAAAGEEVvwQBAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKUGwAe0ALQAgAAyNAAAAAAAAAAAAAAAAAAA4xEAAOMR AAAAAAAATTP8JAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAACAAAAAAAAAAAACDODcVb8EATf3//9AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhIWAAA AAAI8P8PAQgBPwAA5AQAAP///3////9/////f////3////9/////f////38OLnYAAAYAADIAAAAA AAAAAAAAAAAAAAAAAAAAAAAhBAAAAAAAAAAAAAAAAAAAAAAAABAcAAAIAAAAAAAAAAAAeAAAAHgA AAAAAAAAAAAAAKAFAAAAAAAACwAAAAAAAADcAAAA//8SAAAAAAA5AEMAOgBcAFQAcgBhAHYAYQBp AGwAXABXAG8AcgBkAFwAUwBhAHUAdgBlAEcAYQByAGQAZQBcAEEAbgBnAGwAYQBpAHMAXABJAHQA dQB0AEIAYQBzAGkAYwAtAFQAZQBtAHAAbABhAHQAZQAuAGQAbwB0AG4ARgBpAHIAcwB0ACAAbQBl AGUAdABpAG4AZwAgAG8AZgAgAEoAbwBpAG4AdAAgAEMAbwBvAHIAZABpAG4AYQB0AGkAbwBuACAA QQBjAHQAaQB2AGkAdAB5ACAAbwBuACAAUwBtAGEAcgB0ACAARwByAGkAZAAgAGEAbgBkACAASABv AG0AZQAgAE4AZQB0AHcAbwByAGsAaQBuAGcAIAAoAEoAQwBBAC0AUwBHACYASABOACkALAAgAEcA ZQBuAGUAdgBhACwAIAA5ACAATQBhAHkAIAAyADAAMQAyAAAAAAAAAAMAVABTAEIADwBFAHUAYwBo AG4AZQByACwAIABNAGEAcgB0AGkAbgAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAGAAAAAQAAAAAA DAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABgECAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlP aBCrkQgAKyez2TAAAABcAgAAEgAAAAEAAACYAAAAAgAAAKAAAAADAAAAGAEAAAQAAAAkAQAABQAA ADABAAAGAAAAPAEAAAcAAACoAQAACAAAAMgBAAAJAAAA4AEAABIAAADsAQAACgAAAAwCAAALAAAA GAIAAAwAAAAkAgAADQAAADACAAAOAAAAPAIAAA8AAABEAgAAEAAAAEwCAAATAAAAVAIAAAIAAADk BAAAHgAAAHAAAABGaXJzdCBtZWV0aW5nIG9mIEpvaW50IENvb3JkaW5hdGlvbiBBY3Rpdml0eSBv biBTbWFydCBHcmlkIGFuZCBIb21lIE5ldHdvcmtpbmcgKEpDQS1TRyZITiksIEdlbmV2YSwgOSBN YXkgMjAxMgAAHgAAAAQAAAAAAAAAHgAAAAQAAABUU0IAHgAAAAQAAAAAAAAAHgAAAGQAAABKQ0Et U0cmSE4tSS04ICBGb3I6IEdlbmV2YSwgOSBNYXkgMjAxMg1Eb2N1bWVudCBkYXRlOiANU2F2ZWQg YnkgSE8tMTA3NDMxIGF0IDExOjA4OjU1IG9uIDA1LjA0LjIwMTIAHgAAABgAAABJdHV0QmFzaWMt VGVtcGxhdGUuZG90AAAeAAAAEAAAAEV1Y2huZXIsIE1hcnRpbgAeAAAABAAAADYxAAAeAAAAGAAA AE1pY3Jvc29mdCBPZmZpY2UgV29yZAAAAEAAAAAACpeQGQAAAEAAAAAAjDg+LTnCAUAAAAAAzsX5 IPrNAUAAAAAAhAd9CPHOAQMAAAACAAAAAwAAAKwCAAADAAAAQA8AAAMAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA/v8AAAYBAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss +a5EAAAABdXN1ZwuGxCTlwgAKyz5rtwBAACYAQAADQAAAAEAAABwAAAADgAAAHgAAAAPAAAAiAAA AAUAAAC8AAAABgAAAMQAAAARAAAAzAAAABcAAADUAAAACwAAANwAAAAQAAAA5AAAABMAAADsAAAA FgAAAPQAAAANAAAA/AAAAAwAAAB3AQAAAgAAAOQEAAAeAAAACAAAAElUVS1UAAAAHgAAACwAAABJ bnRlcm5hdGlvbmFsIFRlbGVjb21tdW5pY2F0aW9uIFVuaW9uIChJVFUpAAMAAAAgAAAAAwAAAAkA AAADAAAA4xEAAAMAAAAAAA4ACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAA AG8AAABGaXJzdCBtZWV0aW5nIG9mIEpvaW50IENvb3JkaW5hdGlvbiBBY3Rpdml0eSBvbiBTbWFy dCBHcmlkIGFuZCBIb21lIE5ldHdvcmtpbmcgKEpDQS1TRyZITiksIEdlbmV2YSwgOSBNYXkgMjAx MgAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAAAAAAAQBQAACwAAAAAAAABgAAAAAQAAABwB AAACAAAAJAEAAAMAAAB4BAAABAAAAIQEAAAFAAAAkAQAAAYAAACoBAAABwAAALQEAAAIAAAA3AQA AAkAAADoBAAACgAAAAQFAAAJAAAAAgAAAAwAAABfUElEX0hMSU5LUwADAAAAGQAAAFB1Ymxpc2hp bmdFeHBpcmF0aW9uRGF0ZQAEAAAAFAAAAFB1Ymxpc2hpbmdTdGFydERhdGUABQAAAAcAAABEb2Nu dW0ABgAAAAgAAABEb2NkYXRlAAcAAAAKAAAARG9jb3JsYW5nAAgAAAAMAAAARG9jYmx1ZXBpbmsA CQAAAAgAAABEb2NkZXN0AAoAAAAKAAAARG9jYXV0aG9yAAIAAADkBAAAQQAAAEwDAAAeAAAAAwAA AD8AQgADAAAADAAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAVAAAAGgAdAB0AHAAOgAvAC8AdwB3AHcA LgBpAHQAdQAuAGkAbgB0AC8AbwBuAGwAaQBuAGUALwByAGUAZwBzAHkAcwAvAEkAVABVAC0AVAAv AG0AaQBzAGMALwBlAGQAcgBzAC4AcgBlAGcAaQBzAHQAcgBhAHQAaQBvAG4ALgBmAG8AcgBtAD8A XwBlAHYAZQBuAHQAaQBkAD0AMwAwADAAMAA2ADEANgAAAB8AAAABAAAAAAAAAAMAAAAlADUAAwAA AAkAAAADAAAAAAAAAAMAAAAFAAAAHwAAACQAAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQB0AHUA LgBpAG4AdAAvAGUAbgAvAEkAVABVAC0AVAAvAGoAYwBhAC8AQwBPAFAAAAAfAAAAAQAAAAAAAAAD AAAAKQAFAAMAAAAGAAAAAwAAAAAAAAADAAAABQAAAB8AAAAZAAAAbQBhAGkAbAB0AG8AOgB0AHMA YgBqAGMAYQBjAG8AcABAAGkAdAB1AC4AaQBuAHQAAAAAAB8AAAABAAAAAAAAAAMAAABVABoAAwAA AAMAAAADAAAAAAAAAAMAAAAFAAAAHwAAACUAAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQB0AHUA LgBpAG4AdAAvAGUAbgAvAEkAVABVAC0AVAAvAGoAYwBhAC8AQwBPAFAALwAAAAAAHwAAAAEAAAAA AAAAAwAAACwAAAADAAAAAAAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAaQAAAGgAdAB0AHAAOgAvAC8A aQBmAGEALgBpAHQAdQAuAGkAbgB0AC8AdAAvAHMAZgB0AHAALwBqAGMAYQBjAG8AcAAvADIAMAAx ADQAXwAwADEAXwBKAEMAQQAtAEMATwBQAF8ARwBlAG4AZQB2AGEALwBEAE8AQwAwADQANgBfAGEA ZwBlAG4AZABhAF8AZgBvAHIAXwB0AGgAZQBfAGYAaQBmAHQAaABfAEoAQwBBAC0AQwBPAFAAXwBt AGUAZQB0AGkAbgBnAC4AZABvAGMAeAAAAAAAHwAAAAEAAAAAAAAAHgAAAAQAAAAAAAAAHgAAAAQA AAAAAAAAHgAAABAAAABKQ0EtU0cmSE4tSS04AAAAHgAAAAQAAAAAAAAAHgAAACAAAABFbmdsaXNo IG9ubHkgT3JpZ2luYWw6IEVuZ2xpc2gAAB4AAAAEAAAAAAAAAB4AAAAUAAAAR2VuZXZhLCA5IE1h eSAyMDEyAAAeAAAABAAAAFRTQgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0A AAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAA ABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAAP7///8jAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAA KgAAACsAAAAsAAAALQAAAC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAD+ ////OQAAADoAAAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAAAEMAAABEAAAARQAAAEYA AABHAAAASAAAAEkAAABKAAAASwAAAEwAAABNAAAATgAAAE8AAABQAAAAUQAAAFIAAABTAAAAVAAA AFUAAABWAAAAVwAAAFgAAABZAAAA/v///1sAAABcAAAAXQAAAF4AAABfAAAAYAAAAGEAAAD+//// YwAAAGQAAABlAAAAZgAAAGcAAABoAAAAaQAAAP7////9////bAAAAG0AAABuAAAA/v////7///9x AAAAgwAAAHMAAAB0AAAAdQAAAHYAAAB3AAAAeAAAAHkAAAB6AAAAewAAAHwAAAB+AAAA/f///38A AACAAAAAUgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAAAAAAAAAAAA 4LjPmgjxzgFwAAAAgAcAAAAAAABEAGEAdABhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgACAf///////////////wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAACIAAADfKwAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIAAQAAAP////////// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAAAFxCAAAAAAAAVwBvAHIAZABE AG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoA AgENAAAABQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAN0IA AAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAKAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAFoAAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYA bwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIBBAAAAP//////////AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAYgAAAAAQAAAAAAAATQBzAG8ARABhAHQAYQBTAHQAbwByAGUA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAQD//////////wcAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAIBdzJoI8c4BkPXOmgjxzgEAAAAAAAAAAAAAAABNADUATQBPAEEA xQDKANwAzADEAMYA1QBFAFUAWgDOAEUA0wBMADEA2gBRAD0APQAAAAAAAAAAAAAAAAAAAAAAMgAB Af////8KAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgF3MmgjxzgEwC86aCPHOAQAAAAAAAAAA AAAAAEkAdABlAG0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAKAAIB/////wkAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAANsAAAAAAAAAUAByAG8AcABlAHIAdABpAGUAcwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYAAgD///////////////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAATwEAAAAAAABUAEEAxQDMANUAyABJAEoAUwDUAFMAzgDK AMQA2gBQAEkAwgBCAMYA0gDAAD0APQAAAAAAAAAAAAAAAAAAAAAAMgABAP//////////CwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAgF3MmgjxzgGQ9c6aCPHOAQAAAAAAAAAAAAAAAEkAdABlAG0AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAIB /////wwAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcgAAAJEeAAAA AAAAUAByAG8AcABlAHIAdABpAGUAcwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAABYAAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAKAAAARgQAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAQIAAAAGAAAA/////wAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAABwAAAByAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/ //////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAABAAAAAgAAAAMAAAD+////BQAAAAYAAAAHAAAACAAAAAkAAAD+////CwAAAAwAAAANAAAADgAA AA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAD+//// HQAAAP7///////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /zw/bXNvLWNvbnRlbnRUeXBlPz48Rm9ybVRlbXBsYXRlcyB4bWxucz0iaHR0cDovL3NjaGVtYXMu bWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3YzL2NvbnRlbnR0eXBlL2Zvcm1zIj48RGlzcGxheT5E b2N1bWVudExpYnJhcnlGb3JtPC9EaXNwbGF5PjxFZGl0PkRvY3VtZW50TGlicmFyeUZvcm08L0Vk aXQ+PE5ldz5Eb2N1bWVudExpYnJhcnlGb3JtPC9OZXc+PC9Gb3JtVGVtcGxhdGVzPgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5n PSJVVEYtOCIgc3RhbmRhbG9uZT0ibm8iPz4NCjxkczpkYXRhc3RvcmVJdGVtIGRzOml0ZW1JRD0i ezAyMEVGMzMxLUJDNUEtNDlCMi1CNTExLTQ2NkUxMzMyREJFOX0iIHhtbG5zOmRzPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvb2ZmaWNlRG9jdW1lbnQvMjAwNi9jdXN0b21YbWwi PjxkczpzY2hlbWFSZWZzPjxkczpzY2hlbWFSZWYgZHM6dXJpPSJodHRwOi8vc2NoZW1hcy5taWNy b3NvZnQuY29tL3NoYXJlcG9pbnQvdjMvY29udGVudHR5cGUvZm9ybXMiLz48L2RzOnNjaGVtYVJl ZnM+PC9kczpkYXRhc3RvcmVJdGVtPgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCIgc3RhbmRh bG9uZT0ibm8iPz4NCjxkczpkYXRhc3RvcmVJdGVtIGRzOml0ZW1JRD0ie0Q2NkMwOTRDLTA5ODIt NDQ0Qi1BRUFBLTRFOEYyMjIwNjZDQX0iIHhtbG5zOmRzPSJodHRwOi8vc2NoZW1hcy5vcGVueG1s Zm9ybWF0cy5vcmcvb2ZmaWNlRG9jdW1lbnQvMjAwNi9jdXN0b21YbWwiPjxkczpzY2hlbWFSZWZz PjxkczpzY2hlbWFSZWYgZHM6dXJpPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmlj ZS8yMDA2L21ldGFkYXRhL2NvbnRlbnRUeXBlIi8+PGRzOnNjaGVtYVJlZiBkczp1cmk9Imh0dHA6 Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNlLzIwMDYvbWV0YWRhdGEvcHJvcGVydGllcy88 P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJ1dGYtOCI/PjxjdDpjb250ZW50VHlwZVNjaGVt YSBjdDpfPSIiIG1hOl89IiIgbWE6Y29udGVudFR5cGVOYW1lPSJEb2N1bWVudCIgbWE6Y29udGVu dFR5cGVJRD0iMHgwMTAxMDA1QzBFMjdFMDMwOUVEMTQ1QjdFOTA3REE4QzRGODA0NyIgbWE6Y29u dGVudFR5cGVWZXJzaW9uPSIxIiBtYTpjb250ZW50VHlwZURlc2NyaXB0aW9uPSJDcmVhdGUgYSBu ZXcgZG9jdW1lbnQuIiBtYTpjb250ZW50VHlwZVNjb3BlPSIiIG1hOnZlcnNpb25JRD0iNjQyYzQy OTcxOWVlODQzYWJhNDk4MDE2YzU1ZjZiOTYiIHhtbG5zOmN0PSJodHRwOi8vc2NoZW1hcy5taWNy b3NvZnQuY29tL29mZmljZS8yMDA2L21ldGFkYXRhL2NvbnRlbnRUeXBlIiB4bWxuczptYT0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNi9tZXRhZGF0YS9wcm9wZXJ0aWVz L21ldGFBdHRyaWJ1dGVzIj4NCjx4c2Q6c2NoZW1hIHRhcmdldE5hbWVzcGFjZT0iaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNi9tZXRhZGF0YS9wcm9wZXJ0aWVzIiBtYTpy b290PSJ0cnVlIiBtYTpmaWVsZHNJRD0iYTQ0NzIwNmRhYjAwMTVmOGI5Zjg5MjQ1MzUxOTNlOGMi IG5zMTpfPSIiIHhtbG5zOnhzZD0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiIHht bG5zOnhzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6cD0iaHR0cDov L3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNi9tZXRhZGF0YS9wcm9wZXJ0aWVzIiB4 bWxuczpuczE9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC92MyI+DQo8 eHNkOmltcG9ydCBuYW1lc3BhY2U9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVw b2ludC92MyIvPg0KPHhzZDplbGVtZW50IG5hbWU9InByb3BlcnRpZXMiPg0KPHhzZDpjb21wbGV4 VHlwZT4NCjx4c2Q6c2VxdWVuY2U+DQo8eHNkOmVsZW1lbnQgbmFtZT0iZG9jdW1lbnRNYW5hZ2Vt ZW50Ij4NCjx4c2Q6Y29tcGxleFR5cGU+DQo8eHNkOmFsbD4NCjx4c2Q6ZWxlbWVudCByZWY9Im5z MTpQdWJsaXNoaW5nU3RhcnREYXRlIiBtaW5PY2N1cnM9IjAiLz4NCjx4c2Q6ZWxlbWVudCByZWY9 Im5zMTpQdWJsaXNoaW5nRXhwaXJhdGlvbkRhdGUiIG1pbk9jY3Vycz0iMCIvPg0KPC94c2Q6YWxs Pg0KPC94c2Q6Y29tcGxleFR5cGU+DQo8L3hzZDplbGVtZW50Pg0KPC94c2Q6c2VxdWVuY2U+DQo8 L3hzZDpjb21wbGV4VHlwZT4NCjwveHNkOmVsZW1lbnQ+DQo8L3hzZDpzY2hlbWE+DQo8eHNkOnNj aGVtYSB0YXJnZXROYW1lc3BhY2U9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVw b2ludC92MyIgZWxlbWVudEZvcm1EZWZhdWx0PSJxdWFsaWZpZWQiIHhtbG5zOnhzZD0iaHR0cDov L3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiIHhtbG5zOnhzPSJodHRwOi8vd3d3LnczLm9yZy8y MDAxL1hNTFNjaGVtYSIgeG1sbnM6ZG1zPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29m ZmljZS8yMDA2L2RvY3VtZW50TWFuYWdlbWVudC90eXBlcyIgeG1sbnM6cGM9Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNlL2luZm9wYXRoLzIwMDcvUGFydG5lckNvbnRyb2xzIj4N Cjx4c2Q6aW1wb3J0IG5hbWVzcGFjZT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kb2N1bWVudE1hbmFnZW1lbnQvdHlwZXMiLz4NCjx4c2Q6aW1wb3J0IG5hbWVzcGFj ZT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvaW5mb3BhdGgvMjAwNy9QYXJ0 bmVyQ29udHJvbHMiLz4NCjx4c2Q6ZWxlbWVudCBuYW1lPSJQdWJsaXNoaW5nU3RhcnREYXRlIiBt YTppbmRleD0iOCIgbmlsbGFibGU9InRydWUiIG1hOmRpc3BsYXlOYW1lPSJTY2hlZHVsaW5nIFN0 YXJ0IERhdGUiIG1hOmRlc2NyaXB0aW9uPSIiIG1hOmhpZGRlbj0idHJ1ZSIgbWE6aW50ZXJuYWxO YW1lPSJQdWJsaXNoaW5nU3RhcnREYXRlIj4NCjx4c2Q6c2ltcGxlVHlwZT4NCjx4c2Q6cmVzdHJp Y3Rpb24gYmFzZT0iZG1zOlVua25vd24iLz4NCjwveHNkOnNpbXBsZVR5cGU+DQo8L3hzZDplbGVt ZW50Pg0KPHhzZDplbGVtZW50IG5hbWU9IlB1Ymxpc2hpbmdFeHBpcmF0aW9uRGF0ZSIgbWE6aW5k ZXg9IjkiIG5pbGxhYmxlPSJ0cnVlIiBtYTpkaXNwbGF5TmFtZT0iU2NoZWR1bGluZyBFbmQgRGF0 ZSIgbWE6ZGVzY3JpcHRpb249IiIgbWE6aGlkZGVuPSJ0cnVlIiBtYTppbnRlcm5hbE5hbWU9IlB1 Ymxpc2hpbmdFeHBpcmF0aW9uRGF0ZSI+DQo8eHNkOnNpbXBsZVR5cGU+DQo8eHNkOnJlc3RyaWN0 aW9uIGJhc2U9ImRtczpVbmtub3duIi8+DQo8L3hzZDpzaW1wbGVUeXBlPg0KPC94c2Q6ZWxlbWVu dD4NCjwveHNkOnNjaGVtYT4NCjx4c2Q6c2NoZW1hIHRhcmdldE5hbWVzcGFjZT0iaHR0cDovL3Nj aGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAwNi9tZXRhZGF0YS9jb3JlLXByb3Bl cnRpZXMiIGVsZW1lbnRGb3JtRGVmYXVsdD0icXVhbGlmaWVkIiBhdHRyaWJ1dGVGb3JtRGVmYXVs dD0idW5xdWFsaWZpZWQiIGJsb2NrRGVmYXVsdD0iI2FsbCIgeG1sbnM9Imh0dHA6Ly9zY2hlbWFz Lm9wZW54bWxmb3JtYXRzLm9yZy9wYWNrYWdlLzIwMDYvbWV0YWRhdGEvY29yZS1wcm9wZXJ0aWVz IiB4bWxuczp4c2Q9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hIiB4bWxuczp4c2k9 Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczpkYz0iaHR0 cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8iIHhtbG5zOmRjdGVybXM9Imh0dHA6Ly9wdXJs Lm9yZy9kYy90ZXJtcy8iIHhtbG5zOm9kb2M9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20v aW50ZXJuYWwvb2JkIj4NCjx4c2Q6aW1wb3J0IG5hbWVzcGFjZT0iaHR0cDovL3B1cmwub3JnL2Rj L2VsZW1lbnRzLzEuMS8iIHNjaGVtYUxvY2F0aW9uPSJodHRwOi8vZHVibGluY29yZS5vcmcvc2No ZW1hcy94bWxzL3FkYy8yMDAzLzA0LzAyL2RjLnhzZCIvPg0KPHhzZDppbXBvcnQgbmFtZXNwYWNl PSJodHRwOi8vcHVybC5vcmcvZGMvdGVybXMvIiBzY2hlbWFMb2NhdGlvbj0iaHR0cDovL2R1Ymxp bmNvcmUub3JnL3NjaGVtYXMveG1scy9xZGMvMjAwMy8wNC8wMi9kY3Rlcm1zLnhzZCIvPg0KPHhz ZDplbGVtZW50IG5hbWU9ImNvcmVQcm9wZXJ0aWVzIiB0eXBlPSJDVF9jb3JlUHJvcGVydGllcyIv Pg0KPHhzZDpjb21wbGV4VHlwZSBuYW1lPSJDVF9jb3JlUHJvcGVydGllcyI+DQo8eHNkOmFsbD4N Cjx4c2Q6ZWxlbWVudCByZWY9ImRjOmNyZWF0b3IiIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSIx Ii8+DQo8eHNkOmVsZW1lbnQgcmVmPSJkY3Rlcm1zOmNyZWF0ZWQiIG1pbk9jY3Vycz0iMCIgbWF4 T2NjdXJzPSIxIi8+DQo8eHNkOmVsZW1lbnQgcmVmPSJkYzppZGVudGlmaWVyIiBtaW5PY2N1cnM9 IjAiIG1heE9jY3Vycz0iMSIvPg0KPHhzZDplbGVtZW50IG5hbWU9ImNvbnRlbnRUeXBlIiBtaW5P Y2N1cnM9IjAiIG1heE9jY3Vycz0iMSIgdHlwZT0ieHNkOnN0cmluZyIgbWE6aW5kZXg9IjAiIG1h OmRpc3BsYXlOYW1lPSJDb250ZW50IFR5cGUiLz4NCjx4c2Q6ZWxlbWVudCByZWY9ImRjOnRpdGxl IiBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0iMSIgbWE6aW5kZXg9IjQiIG1hOmRpc3BsYXlOYW1l PSJUaXRsZSIvPg0KPHhzZDplbGVtZW50IHJlZj0iZGM6c3ViamVjdCIgbWluT2NjdXJzPSIwIiBt YXhPY2N1cnM9IjEiLz4NCjx4c2Q6ZWxlbWVudCByZWY9ImRjOmRlc2NyaXB0aW9uIiBtaW5PY2N1 cnM9IjAiIG1heE9jY3Vycz0iMSIvPg0KPHhzZDplbGVtZW50IG5hbWU9ImtleXdvcmRzIiBtaW5P Y2N1cnM9IjAiIG1heE9jY3Vycz0iMSIgdHlwZT0ieHNkOnN0cmluZyIvPg0KPHhzZDplbGVtZW50 IHJlZj0iZGM6bGFuZ3VhZ2UiIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSIxIi8+DQo8eHNkOmVs ZW1lbnQgbmFtZT0iY2F0ZWdvcnkiIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSIxIiB0eXBlPSJ4 c2Q6c3RyaW5nIi8+DQo8eHNkOmVsZW1lbnQgbmFtZT0idmVyc2lvbiIgbWluT2NjdXJzPSIwIiBt YXhPY2N1cnM9IjEiIHR5cGU9InhzZDpzdHJpbmciLz4NCjx4c2Q6ZWxlbWVudCBuYW1lPSJyZXZp c2lvbiIgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9IjEiIHR5cGU9InhzZDpzdHJpbmciPg0KPHhz ZDphbm5vdGF0aW9uPg0KPHhzZDpkb2N1bWVudGF0aW9uPg0KICAgICAgICAgICAgICAgICAgICAg ICAgVGhpcyB2YWx1ZSBpbmRpY2F0ZXMgdGhlIG51bWJlciBvZiBzYXZlcyBvciByZXZpc2lvbnMu IFRoZSBhcHBsaWNhdGlvbiBpcyByZXNwb25zaWJsZSBmb3IgdXBkYXRpbmcgdGhpcyB2YWx1ZSBh ZnRlciBlYWNoIHJldmlzaW9uLg0KICAgICAgICAgICAgICAgICAgICA8L3hzZDpkb2N1bWVudGF0 aW9uPg0KPC94c2Q6YW5ub3RhdGlvbj4NCjwveHNkOmVsZW1lbnQ+DQo8eHNkOmVsZW1lbnQgbmFt ZT0ibGFzdE1vZGlmaWVkQnkiIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSIxIiB0eXBlPSJ4c2Q6 c3RyaW5nIi8+DQo8eHNkOmVsZW1lbnQgcmVmPSJkY3Rlcm1zOm1vZGlmaWVkIiBtaW5PY2N1cnM9 IjAiIG1heE9jY3Vycz0iMSIvPg0KPHhzZDplbGVtZW50IG5hbWU9ImNvbnRlbnRTdGF0dXMiIG1p bk9jY3Vycz0iMCIgbWF4T2NjdXJzPSIxIiB0eXBlPSJ4c2Q6c3RyaW5nIi8+DQo8L3hzZDphbGw+ DQo8L3hzZDpjb21wbGV4VHlwZT4NCjwveHNkOnNjaGVtYT4NCjx4czpzY2hlbWEgdGFyZ2V0TmFt ZXNwYWNlPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9pbmZvcGF0aC8yMDA3 L1BhcnRuZXJDb250cm9scyIgZWxlbWVudEZvcm1EZWZhdWx0PSJxdWFsaWZpZWQiIGF0dHJpYnV0 ZUZvcm1EZWZhdWx0PSJ1bnF1YWxpZmllZCIgeG1sbnM6cGM9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jv c29mdC5jb20vb2ZmaWNlL2luZm9wYXRoLzIwMDcvUGFydG5lckNvbnRyb2xzIiB4bWxuczp4cz0i aHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiPg0KPHhzOmVsZW1lbnQgbmFtZT0iUGVy c29uIj4NCjx4czpjb21wbGV4VHlwZT4NCjx4czpzZXF1ZW5jZT4NCjx4czplbGVtZW50IHJlZj0i cGM6RGlzcGxheU5hbWUiIG1pbk9jY3Vycz0iMCI+PC94czplbGVtZW50Pg0KPHhzOmVsZW1lbnQg cmVmPSJwYzpBY2NvdW50SWQiIG1pbk9jY3Vycz0iMCI+PC94czplbGVtZW50Pg0KPHhzOmVsZW1l bnQgcmVmPSJwYzpBY2NvdW50VHlwZSIgbWluT2NjdXJzPSIwIj48L3hzOmVsZW1lbnQ+DQo8L3hz OnNlcXVlbmNlPg0KPC94czpjb21wbGV4VHlwZT4NCjwveHM6ZWxlbWVudD4NCjx4czplbGVtZW50 IG5hbWU9IkRpc3BsYXlOYW1lIiB0eXBlPSJ4czpzdHJpbmciPjwveHM6ZWxlbWVudD4NCjx4czpl bGVtZW50IG5hbWU9IkFjY291bnRJZCIgdHlwZT0ieHM6c3RyaW5nIj48L3hzOmVsZW1lbnQ+DQo8 eHM6ZWxlbWVudCBuYW1lPSJBY2NvdW50VHlwZSIgdHlwZT0ieHM6c3RyaW5nIj48L3hzOmVsZW1l bnQ+DQo8eHM6ZWxlbWVudCBuYW1lPSJCRENBc3NvY2lhdGVkRW50aXR5Ij4NCjx4czpjb21wbGV4 VHlwZT4NCjx4czpzZXF1ZW5jZT4NCjx4czplbGVtZW50IHJlZj0icGM6QkRDgQAAAIIAAAD+//// hAAAAP7///////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////9FbnRpdHkiIG1pbk9j Y3Vycz0iMCIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiPjwveHM6ZWxlbWVudD4NCjwveHM6c2VxdWVu Y2U+DQo8eHM6YXR0cmlidXRlIHJlZj0icGM6RW50aXR5TmFtZXNwYWNlIj48L3hzOmF0dHJpYnV0 ZT4NCjx4czphdHRyaWJ1dGUgcmVmPSJwYzpFbnRpdHlOYW1lIj48L3hzOmF0dHJpYnV0ZT4NCjx4 czphdHRyaWJ1dGUgcmVmPSJwYzpTeXN0ZW1JbnN0YW5jZU5hbWUiPjwveHM6YXR0cmlidXRlPg0K PHhzOmF0dHJpYnV0ZSByZWY9InBjOkFzc29jaWF0aW9uTmFtZSI+PC94czphdHRyaWJ1dGU+DQo8 L3hzOmNvbXBsZXhUeXBlPg0KPC94czplbGVtZW50Pg0KPHhzOmF0dHJpYnV0ZSBuYW1lPSJFbnRp dHlOYW1lc3BhY2UiIHR5cGU9InhzOnN0cmluZyI+PC94czphdHRyaWJ1dGU+DQo8eHM6YXR0cmli dXRlIG5hbWU9IkVudGl0eU5hbWUiIHR5cGU9InhzOnN0cmluZyI+PC94czphdHRyaWJ1dGU+DQo8 eHM6YXR0cmlidXRlIG5hbWU9IlN5c3RlbUluc3RhbmNlTmFtZSIgdHlwZT0ieHM6c3RyaW5nIj48 L3hzOmF0dHJpYnV0ZT4NCjx4czphdHRyaWJ1dGUgbmFtZT0iQXNzb2NpYXRpb25OYW1lIiB0eXBl PSJ4czpzdHJpbmciPjwveHM6YXR0cmlidXRlPg0KPHhzOmVsZW1lbnQgbmFtZT0iQkRDRW50aXR5 Ij4NCjx4czpjb21wbGV4VHlwZT4NCjx4czpzZXF1ZW5jZT4NCjx4czplbGVtZW50IHJlZj0icGM6 RW50aXR5RGlzcGxheU5hbWUiIG1pbk9jY3Vycz0iMCI+PC94czplbGVtZW50Pg0KPHhzOmVsZW1l bnQgcmVmPSJwYzpFbnRpdHlJbnN0YW5jZVJlZmVyZW5jZSIgbWluT2NjdXJzPSIwIj48L3hzOmVs ZW1lbnQ+DQo8eHM6ZWxlbWVudCByZWY9InBjOkVudGl0eUlkMSIgbWluT2NjdXJzPSIwIj48L3hz OmVsZW1lbnQ+DQo8eHM6ZWxlbWVudCByZWY9InBjOkVudGl0eUlkMiIgbWluT2NjdXJzPSIwIj48 L3hzOmVsZW1lbnQ+DQo8eHM6ZWxlbWVudCByZWY9InBjOkVudGl0eUlkMyIgbWluT2NjdXJzPSIw Ij48L3hzOmVsZW1lbnQ+DQo8eHM6ZWxlbWVudCByZWY9InBjOkVudGl0eUlkNCIgbWluT2NjdXJz PSIwIj48L3hzOmVsZW1lbnQ+DQo8eHM6ZWxlbWVudCByZWY9InBjOkVudGl0eUlkNSIgbWluT2Nj dXJzPSIwIj48L3hzOmVsZW1lbnQ+DQo8L3hzOnNlcXVlbmNlPg0KPC94czpjb21wbGV4VHlwZT4N CjwveHM6ZWxlbWVudD4NCjx4czplbGVtZW50IG5hbWU9IkVudGl0eURpc3BsYXlOYW1lIiB0eXBl PSJ4czpzdHJpbmciPjwveHM6ZWxlbWVudD4NCjx4czplbGVtZW50IG5hbWU9IkVudGl0eUluc3Rh bmNlUmVmZXJlbmNlIiB0eXBlPSJ4czpzdHJpbmciPjwveHM6ZWxlbWVudD4NCjx4czplbGVtZW50 IG5hbWU9IkVudGl0eUlkMSIgdHlwZT0ieHM6c3RyaW5nIj48L3hzOmVsZW1lbnQ+DQo8eHM6ZWxl bWVudCBuYW1lPSJFbnRpdHlJZDIiIHR5cGU9InhzOnN0cmluZyI+PC94czplbGVtZW50Pg0KPHhz OmVsZW1lbnQgbmFtZT0iRW50aXR5SWQzIiB0eXBlPSJ4czpzdHJpbmciPjwveHM6ZWxlbWVudD4N Cjx4czplbGVtZW50IG5hbWU9IkVudGl0eUlkNCIgdHlwZT0ieHM6c3RyaW5nIj48L3hzOmVsZW1l bnQ+DQo8eHM6ZWxlbWVudCBuYW1lPSJFbnRpdHlJZDUiIHR5cGU9InhzOnN0cmluZyI+PC94czpl bGVtZW50Pg0KPHhzOmVsZW1lbnQgbmFtZT0iVGVybXMiPg0KPHhzOmNvbXBsZXhUeXBlPg0KPHhz OnNlcXVlbmNlPg0KPHhzOmVsZW1lbnQgcmVmPSJwYzpUZXJtSW5mbyIgbWluT2NjdXJzPSIwIiBt YXhPY2N1cnM9InVuYm91bmRlZCI+PC94czplbGVtZW50Pg0KPC94czpzZXF1ZW5jZT4NCjwveHM6 Y29tcGxleFR5cGU+DQo8L3hzOmVsZW1lbnQ+DQo8eHM6ZWxlbWVudCBuYW1lPSJUZXJtSW5mbyI+ DQo8eHM6Y29tcGxleFR5cGU+DQo8eHM6c2VxdWVuY2U+DQo8eHM6ZWxlbWVudCByZWY9InBjOlRl cm1OYW1lIiBtaW5PY2N1cnM9IjAiPjwveHM6ZWxlbWVudD4NCjx4czplbGVtZW50IHJlZj0icGM6 VGVybUlkIiBtaW5PY2N1cnM9IjAiPjwveHM6ZWxlbWVudD4NCjwveHM6c2VxdWVuY2U+DQo8L3hz OmNvbXBsZXhUeXBlPg0KPC94czplbGVtZW50Pg0KPHhzOmVsZW1lbnQgbmFtZT0iVGVybU5hbWUi IHR5cGU9InhzOnN0cmluZyI+PC94czplbGVtZW50Pg0KPHhzOmVsZW1lbnQgbmFtZT0iVGVybUlk IiB0eXBlPSJ4czpzdHJpbmciPjwveHM6ZWxlbWVudD4NCjwveHM6c2NoZW1hPg0KPC9jdDpjb250 ZW50VHlwZVNjaGVtYT4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbWV0YUF0dHJpYnV0ZXMiLz48 ZHM6c2NoZW1hUmVmIGRzOnVyaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiLz48 ZHM6c2NoZW1hUmVmIGRzOnVyaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2Uv MjAwNi9tZXRhZGF0YS9wcm9wZXJ0aWVzIi8+PGRzOnNjaGVtYVJlZiBkczp1cmk9Imh0dHA6Ly9z Y2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC92MyIvPjxkczpzY2hlbWFSZWYgZHM6dXJp PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2RvY3VtZW50TWFuYWdl bWVudC90eXBlcyIvPjxkczpzY2hlbWFSZWYgZHM6dXJpPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS9pbmZvcGF0aC8yMDA3L1BhcnRuZXJDb250cm9scyIvPjxkczpzY2hlbWFS ZWYgZHM6dXJpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvcGFja2FnZS8yMDA2 L21ldGFkYXRhL2NvcmUtcHJvcGVydGllcyIvPjxkczpzY2hlbWFSZWYgZHM6dXJpPSJodHRwOi8v cHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLyIvPjxkczpzY2hlbWFSZWYgZHM6dXJpPSJodHRwOi8v cHVybC5vcmcvZGMvdGVybXMvIi8+PGRzOnNjaGVtYVJlZiBkczp1cmk9Imh0dHA6Ly9zY2hlbWFz Lm1pY3Jvc29mdC5jb20vaW50ZXJuYWwvb2JkIi8+PC9kczpzY2hlbWFSZWZzPjwvZHM6ZGF0YXN0 b3JlSXRlbT4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAARiAAAABNaWNyb3NvZnQgV29yZCA5 Ny0yMDAzIERvY3VtZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== --_006_EF35EE4B92789843B1DECBC0E245586439823DD6eusaamb105erics_-- From watsonbladd@gmail.com Thu Dec 12 19:36:58 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8C41AE14F; Thu, 12 Dec 2013 19:36:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hh5g-s88wsjz; Thu, 12 Dec 2013 19:36:54 -0800 (PST) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id DA9E11AE144; Thu, 12 Dec 2013 19:36:53 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id m15so1304684wgh.1 for ; Thu, 12 Dec 2013 19:36:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=AmjN9HixemacuMojngKj07AsfXx5XuNoRBpnyhLcyn4=; b=myV7MZik1vImIUQfWcvXXAfzntYzjxbiH0YhS7x9rVzfGrnWdxuwxEnxHa6bjiGHbc iiyYVIN1BFVeEpamHRdAYRcjwu61f72ZYKPvzNB6iXr9VO05l4YpTTnMcQuvbQAsqLzm 4toW7oxQsROgptxtnBPms9aOiWgsemdlEzpmgCi7wdSyBwfiaRUmmU7AxmZF6xeSPlbL i8pyzIuhSB2inDKLDoglH5NbH/NFmbQSYTI/Y7A0F52VHwipexGE1RQ/XD6NK9azVZ8/ sDU+9a88cbYUAEo9v3DD/obrDDahVBnebHnhA4JqZBXLzVvKy0sqdnxfGqsm6qIs8bGY lZfA== MIME-Version: 1.0 X-Received: by 10.194.85.75 with SMTP id f11mr298634wjz.14.1386905807294; Thu, 12 Dec 2013 19:36:47 -0800 (PST) Received: by 10.194.242.131 with HTTP; Thu, 12 Dec 2013 19:36:47 -0800 (PST) In-Reply-To: <18138981706be6221b2d05187da48394.squirrel@www.trepanning.net> References: <18138981706be6221b2d05187da48394.squirrel@www.trepanning.net> Date: Thu, 12 Dec 2013 19:36:47 -0800 Message-ID: From: Watson Ladd To: Dan Harkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 26 Dec 2013 12:00:54 -0800 Cc: cfrg@ietf.org, "tls@ietf.org" , saag@ietf.org Subject: Re: [saag] [TLS] Question regarding CFRG process X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 03:36:58 -0000 On Thu, Dec 12, 2013 at 5:58 PM, Dan Harkins wrote: > > On Thu, December 12, 2013 4:06 pm, Trevor Perrin wrote: > > ...an extremely misleading email. > > Using pejoratives like "bug", "flaw", and "attack" he attempts a > smear of people, a protocol, and process. In reality there is no > security bug or flaw or attack with dragonfly. > > There is obviously some personal animosity and taste involved > but that is not technical. Read on. This is not quite true. Dragonfly's vaunted resistance to offline attack doesn't hold in the standard model or the ROM because there are some hash functions (like hashing+exponentiation) which break it. This is a very serious issue: it means we don't know what it means for Dragonfly to be secure. > >> Dear CFRG (cc: TLS, SAAG), >> >> I'd like to understand how the CFRG decides on guidance to provide IETF >> WGs. >> >> It appears the CFRG chairs provide this guidance based on their own >> opinions, disregarding any feedback from the mailing list or IETF >> meetings. >> >> In particular, the CFRG chairs have repeatedly endorsed the >> "Dragonfly" protocol to the TLS WG. However, I find no evidence of >> *ANY* positive feedback regarding Dragonfly in the CFRG mailing list >> or meeting minutes, except from the draft's author and CFRG co-chair >> Kevin Igoe. >> >> Compared to Kevin's enthusiasm, note: >> * Respected cryptographers and security engineers like Jonathan Katz, >> Adam Back, and Rene Struik expressed skepticism on the list > > Let's look at those, read on. > >> * The single in-depth discussion at an IETF meeting was a string of >> complaints > > That's what comments are. And they get addressed. > >> * Alternative proposals were made to CFRG (J-PAKE, AugPAKE). >> >> Could the chairs please clarify how they decided to endorse Dragonfly to >> TLS WG? >> >> >> Below is a summary of all CFRG discussion of Dragonfly. >> >> =3D=3D=3D=3D=3D >> >> Feb 2008 >> - Dan Harkins proposes early Dragonfly to CFRG >> http://www.ietf.org/mail-archive/web/cfrg/current/msg02205.html >> >> - Scott Fluhrer breaks it >> http://www.ietf.org/mail-archive/web/cfrg/current/msg02206.html > > An event mentioned in the acknowledgments. Thank you Scott. > His review and comments have been most helpful. > >> >> Nov 2011 >> - David McGrew appoints Kevin Igoe as CFRG co-chair >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03026.html > > Completely and utterly irrelevant. > >> Dec 2011 >> - Dan Harkins asks CFRG to look at TLS-PWD, based on Dragonfly >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03044.html >> >> - Scott Fluhrer points out a problem >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03045.html > > A simple "sanity" check that the an ECC point is not "infinity". Again, > a good comment. > >> - Adam Back questions necessity of it, and lack of security >> analysis >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03046.html > > He does no such thing. He notices that SRP is not mentioned in the > draft. Quite true. And he asks what key exchange is being implemented > because "its harder than it looks". Which is also quite true. > >> Jan 2012 >> - Kevin Igoe's first email to CFRG: >> "I really like this idea & can find no problems." >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03047.html >> >> - Jonathan Katz questions lack of security analysis, points out >> problems >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03052.html >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03053.html > > Yes, helpful comments on the draft. The susceptibility to attack under > the random oracle model is, in fact, mentioned in my slide deck when > I presented to the CFRG in Paris at IETF 83. It is a highly contrived > scenario and completely unlikely a real world protocol but it does raise > the question of making a formal proof in that model. On the contrary: "it looks secure to me" is not an acceptable foundation fo= r cryptographic protocols. I do not want any protocol I approve to be a CRYPT= O keynote in the future. > > You should link to my slide deck in your next broadside. > >> March 2012 >> - At IETF 83 CFRG meeting, concerns are raised about: >> - SPEKE patents >> - necessity of a new scheme >> - timing attacks >> - non-augmented properties >> http://www.ietf.org/proceedings/83/minutes/minutes-83-cfrg.txt > > Wow, you make it sound as if you were there. But you weren't. And > your summary is not an accurate description of the meeting. The > sole mention in the minutes of SPEKE is from me. And the "concerns" > are a recitation of comments received. That's how it works. You get > comments and you resolve them. > >> May 2012 >> - Kevin Igoe points out a limitation due to "hunting-and-pecking" >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03099.html > > He does no such thing. He just said that if the prime defining the > curve p =3D 3 mod 4 that it's easier to compute the square root. > >> - Zhou Sujing and Dan have an exchange that's hard to follow. >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03115.html >> >> July 2012 >> - At IETF 84 TLS meeting (CFRG does not meet): >> - Kevin Igoe informs TLS WG, as the CFRG chair: >> "We approve of it, very clear and usable for general setting." >> http://www.ietf.org/proceedings/84/minutes/minutes-84-tls > > Also note the comment: "Tie Dragonfly into EST would be very useful" > Yes, it would. > >> Oct 2012 >> - Kevin Igoe calls CFRG attention to Dragonfly draft-00 >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03214.html >> >> - Jonathan Katz asks for a security proof - there is none >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03215.html >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03216.html > > Correct. There is no formal proof of security. See my slides from > IETF 83. > >> Dec 2012 >> - Kevin Igoe calls CFRG attention to Dragonfly >> - raises timing attack issue, proposes 2 fixes, including >> rediscovery of Dan's original broken method (2008) >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03258.html > > This is further discussion on addressing a side channel attack. > Your attempt to spin this as "broken" is somewhat desperate. Modern cryptographic practice demands constant time, jump-free, no variable memory access cryptography. > >> - Rene Struik points out the error in Kevin's proposal, and >> the inefficiency of Dragonfly relative to SPEKE >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03259.html > > He does no such thing. His "Suppose A and B=E2=80=A6" is a recitation o= f > a version of SPEKE that does not hash the password into a group in > the domain parameter set. It's neither here nor there with respect > to dragonfly. He further goes on to suggest on a check for "point at > infinity". Which is already part of dragonfly. > > There is no "error" noted and no "inefficiency" mentioned either. > >> - Scott Fluhrer points out the error in Kevin's proposal, and >> proposes a flawed "mostly constant time" fix. Dan and Kevin >> embrace it. >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03260.html >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03262.html >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03263.html >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03264.html >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03265.html > > As noted in the email thread, the described fix was added to the > draft at the time. Your opinion on it being "flawed" has already been > noted. > >> Feb 2013 >> - draft-01 is uploaded with flawed sidechannel fix >> - also quietly fixes security issue reported by Dylan Clarke >> and Feng Hao >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03309.html >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03529.html > > This is a small sub-group attack possible if one does not check > validity of received elements. All incarnations of dragonfly-- TLS-PWD, > EAP-PWD and 802.11 already did this. It is entirely my fault that I left = that > crucial step out of the -00 version of the CFRG draft but it is hardly > a flaw. > >> Apr 2013 >> - Kevin Igoe mentions a last call for Dragonfly >> "The design looks mature, it addresses a real need, and no one >> has raised any issues." >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03383.html > > That's correct. You are included in that "no one". > >> May 2013 >> - Feng Hao asks CFRG to consider J-PAKE (an alternative) >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03430.html > > Completely irrelevant. > I don't think so. Your repeated insistence to the contrary, there are peopl= e who will use RC4 on TLS connections, etc, etc. Our endorsing a protocol when superior alternatives exist is a bad thing, because insecure options have a nasty habit of being turned on. You've argued that because you and your employer don't see an issue, we should be happy to endorse this. >> July 2013 >> - Rene Struik points out spec bugs, raises timing attack issue >> again >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03486.html >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03489.html > > "Spec bugs", in other words typos. Yes, he brings up an issue that > had previously been addressed. > >> - IETF 87, CFRG meeting: >> - "The author is working on a new (and hopefully final) draft" >> http://www.ietf.org/proceedings/87/minutes/minutes-87-cfrg > > Sadly, it's not. I have to address the "Spec bugs" and address > Rene's other comments, none of which demonstrate security flaws. > >> Aug 2013 >> - draft-02 is uploaded with modifications to "hunting-and-pecking" >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03509.html > > Don't forget comments dealing with internationalization! > > The change is from a comment received from, if I recall, Russ Housley > to use the technique from FIPS 186-3 to hide the bias added by the > modular reduction. Again, a very nice comment, happily accepted. Knuth discusses this in detail in Volume 2. Bleichenbacher got a lot of mileage from this. > >> Sep 2013 >> - SeongHan Shin asks CFRG to consider AugPAKE (an alternative) >> http://www.ietf.org/mail-archive/web/cfrg/current/msg03523.html > > Completely irrelevant. (Again, not sure why you're have become such > a cheerleader for AugPAKE). > >> Nov/Dec 2013 >> - Joe Saloway begins TLS-PWD last call, and informs TLS WG that: >> "The underlying cryptographic protocol for TLS-PWD has been >> reviewed by the IRTF CFRG group with satisfactory results." >> http://www.ietf.org/mail-archive/web/tls/current/msg10476.html >> >> - Uproar on TLS WG: >> >> - Many object to lack of formal security analysis: >> Douglas Stebila, Uri Blumenthal, Bodo Moeller, Rene Struik, >> Watson Ladd > > Missing, of course, the caveat "-- except I believe that whenever > possible the IETF should aim to standardize cryptographic protocols > that are unencumbered by license fees and patents. If the choice > arises between a protocol that carries both (provable security and > Intellectual Property) and a protocol that has neither - I'd strongly > prefer the latter." > >> - Many point out better alternatives: >> SeongHan Shin, Robert Ransom, Watson Ladd, Trevor Perrin > > And you're all free to write up Internet Drafts on them too! Why do you want Dragonfly as opposed to J-PAKE? If you think it is going to slow, call up Feng Hao and offer to help. That would satisfy the need you identify in your usecase in the TLS WG. Or is this not about solving the problem of password authenticated key exch= ange, but putting your protocol into things? > > In fact, SeongHan Shin has been following me around EMU, IPsec, > CFRG and now TLS doing just that. After I write a dragonfly I-D he > writes an AugPAKE I-D. Nothing is stopping you from doing it too. > >> - Security flaws are pointed out by Bodo Moeller and >> CodesInChaos >> http://www.ietf.org/mail-archive/web/tls/current/msg10708.html >> http://www.ietf.org/mail-archive/web/tls/current/msg10768.html > > Bodo's comment has been addressed. I dispute the use of the term > "security flaw" to describe it but that is consistent with the rest of > your email. > > CodesInChaos suggested using PBKDF2 to hash the password. This > really provides no additional benefit,, as I noted in a subsequent > email (see coWPAtty and family attacks against a protocol that uses > PBKDF2). > >> - Rene Struik and Bodo Moeller dispute that CFRG approved this >> http://www.ietf.org/mail-archive/web/tls/current/msg10769.html >> >> http://www.ietf.org/mail-archive/web/tls/current/msg10812.html > > Actually, Rene notes that CFRG has not issued a LC. He does raise > some comments, many of which are already addressed in the draft > and he points out the "Spec bug" you allude to earlier. He suggests > relaxation of one of the restrictions on parameter generation that I > decline to accept. And he finds some additional typos and an > erroneous description of point addition. Helpful comments. > >> - Eric Rescorla (TLS WG chair) states: >> "we did have a verbal report back from the chair of the CFRG >> that they considered it satisfactory" >> http://www.ietf.org/mail-archive/web/tls/current/msg10819.html > > Indeed. > > So what you've brought up is that there has been discussion of > dragonfly on the list and it has, in fact, been reviewed. Quite a few > comments have been made and resolved, security critical issues have > been raised and properly addressed. Sorry, but review is not enough. Approval is. What standard is the chair applying here? > > There are no flaws in the key exchange. It has some aspects to it > that some may feel is a benefit and some may feel is a detriment. > Personal taste is not something that can be universally accommodated. > > Nothing you have raised here is reason to stop advancement of > this draft. I disagree. This draft is reminiscent of the worst of 90's cryptography: ad-hoc assumptions, no formal statement of security, gratuitously not a circuit, and not subject by review by anyone who is a cryptographer. It may be that this draft has exposed a fault line between those who think the current process is acceptable and those who do not. > > Dan. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From watsonbladd@gmail.com Fri Dec 13 00:00:44 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64521AE6AA; Fri, 13 Dec 2013 00:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHiLxpROKsk2; Fri, 13 Dec 2013 00:00:30 -0800 (PST) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBAC1AE203; Fri, 13 Dec 2013 00:00:29 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id q58so1507490wes.2 for ; Fri, 13 Dec 2013 00:00:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=odnGFYfUOrcEYwuGJxbwEe8rm6/XfjbZNiZoasfMGik=; b=I61fcvDDCwC2XQklslxTIB1sdQghhsooqB/RiigdZUNx7acbV7y/j0m4rExRMMIohm HMR7WKjCToqLUyYMVbv6+aTLdcNVmKSwW2xdIPMz3htf5Io4j5/cw5WqKX3IVtlB9/gN mLmSuw2wUVjPzlYlpyk/QqeDJeZ//GY5iPJHWtfY2ndLjvjlTffV45jbrsTTZ8KjwQTr lCTErv0SayXpIRuWjbnazkt8lSkBbxMgmwvQkDG5nuip0ZYU70R5uB40+nZDLzDgwO3M 9B4NCCPkbltbvqmy5DukePIHI1edvbfrD4Msj62AKGZ95kKcOCFXUwTjI40AySDRh3GW j0iw== MIME-Version: 1.0 X-Received: by 10.180.73.6 with SMTP id h6mr1314576wiv.20.1386921622139; Fri, 13 Dec 2013 00:00:22 -0800 (PST) Received: by 10.194.242.131 with HTTP; Fri, 13 Dec 2013 00:00:22 -0800 (PST) In-Reply-To: References: <18138981706be6221b2d05187da48394.squirrel@www.trepanning.net> Date: Fri, 13 Dec 2013 00:00:22 -0800 Message-ID: From: Watson Ladd To: Dan Harkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 26 Dec 2013 12:00:54 -0800 Cc: cfrg@ietf.org, "tls@ietf.org" , saag@ietf.org Subject: Re: [saag] [TLS] Question regarding CFRG process X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 08:00:44 -0000 On Thu, Dec 12, 2013 at 11:15 PM, Dan Harkins wrote: > > On Thu, December 12, 2013 7:36 pm, Watson Ladd wrote: >> On Thu, Dec 12, 2013 at 5:58 PM, Dan Harkins wrote= : >>> >>> On Thu, December 12, 2013 4:06 pm, Trevor Perrin wrote: >>> >>> ...an extremely misleading email. >>> >>> Using pejoratives like "bug", "flaw", and "attack" he attempts a >>> smear of people, a protocol, and process. In reality there is no >>> security bug or flaw or attack with dragonfly. >>> >>> There is obviously some personal animosity and taste involved >>> but that is not technical. Read on. >> This is not quite true. Dragonfly's vaunted resistance to offline >> attack doesn't hold >> in the standard model or the ROM because there are some hash functions >> (like hashing+exponentiation) >> which break it. This is a very serious issue: it means we don't know >> what it means for Dragonfly to be secure. > > "vaunted"? The fact that you have to exaggerate reveals much. > > If "it looks good to me" is not enough for you then certainly > "it doesn't have a security proof" is not evidence of flaws and > susceptibility to attack. The consequences of adopting a protocol we think is secure that isn't: dead people. The consequences of ruling out a protocol that is secure because we think it isn't: In this case nothing as the usecase is already handled. Are you seriously arguing that Dragonfly's security is independent of ZF? > > So instead of "that is not quite true", it actually is. Quite. > >>>> Dear CFRG (cc: TLS, SAAG), >>>> >>>> I'd like to understand how the CFRG decides on guidance to provide IET= F >>>> WGs. >>>> >>>> It appears the CFRG chairs provide this guidance based on their own >>>> opinions, disregarding any feedback from the mailing list or IETF >>>> meetings. >>>> >>>> In particular, the CFRG chairs have repeatedly endorsed the >>>> "Dragonfly" protocol to the TLS WG. However, I find no evidence of >>>> *ANY* positive feedback regarding Dragonfly in the CFRG mailing list >>>> or meeting minutes, except from the draft's author and CFRG co-chair >>>> Kevin Igoe. >>>> >>>> Compared to Kevin's enthusiasm, note: >>>> * Respected cryptographers and security engineers like Jonathan Katz, >>>> Adam Back, and Rene Struik expressed skepticism on the list >>> >>> Let's look at those, read on. >>> >>>> * The single in-depth discussion at an IETF meeting was a string of >>>> complaints >>> >>> That's what comments are. And they get addressed. >>> >>>> * Alternative proposals were made to CFRG (J-PAKE, AugPAKE). >>>> >>>> Could the chairs please clarify how they decided to endorse Dragonfly >>>> to >>>> TLS WG? >>>> >>>> >>>> Below is a summary of all CFRG discussion of Dragonfly. >>>> >>>> =3D=3D=3D=3D=3D >>>> >>>> Feb 2008 >>>> - Dan Harkins proposes early Dragonfly to CFRG >>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg02205.html >>>> >>>> - Scott Fluhrer breaks it >>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg02206.html >>> >>> An event mentioned in the acknowledgments. Thank you Scott. >>> His review and comments have been most helpful. >>> >>>> >>>> Nov 2011 >>>> - David McGrew appoints Kevin Igoe as CFRG co-chair >>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03026.html >>> >>> Completely and utterly irrelevant. >>> >>>> Dec 2011 >>>> - Dan Harkins asks CFRG to look at TLS-PWD, based on Dragonfly >>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03044.html >>>> >>>> - Scott Fluhrer points out a problem >>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03045.html >>> >>> A simple "sanity" check that the an ECC point is not "infinity". >>> Again, >>> a good comment. >>> >>>> - Adam Back questions necessity of it, and lack of security >>>> analysis >>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03046.html >>> >>> He does no such thing. He notices that SRP is not mentioned in the >>> draft. Quite true. And he asks what key exchange is being implemented >>> because "its harder than it looks". Which is also quite true. >>> >>>> Jan 2012 >>>> - Kevin Igoe's first email to CFRG: >>>> "I really like this idea & can find no problems." >>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03047.html >>>> >>>> - Jonathan Katz questions lack of security analysis, points out >>>> problems >>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03052.html >>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03053.html >>> >>> Yes, helpful comments on the draft. The susceptibility to attack unde= r >>> the random oracle model is, in fact, mentioned in my slide deck when >>> I presented to the CFRG in Paris at IETF 83. It is a highly contrived >>> scenario and completely unlikely a real world protocol but it does rais= e >>> the question of making a formal proof in that model. >> On the contrary: "it looks secure to me" is not an acceptable foundation >> for >> cryptographic protocols. I do not want any protocol I approve to be a >> CRYPTO >> keynote in the future. > > Cryptographic protocols that you approve? Since when are you the > gatekeeper? What cryptographic protocols have you approved of? I'm not the gatekeeper, merely someone with the training required to do cryptography. By all accounts such a person hasn't been on the TLS WG in a long time. > > Here's an idea: find an attack on dragonfly and present it to CRYPTO > in the future. Something to pad your CV. > >>> You should link to my slide deck in your next broadside. >>> >>>> March 2012 >>>> - At IETF 83 CFRG meeting, concerns are raised about: >>>> - SPEKE patents >>>> - necessity of a new scheme >>>> - timing attacks >>>> - non-augmented properties >>>> http://www.ietf.org/proceedings/83/minutes/minutes-83-cfrg.txt >>> >>> Wow, you make it sound as if you were there. But you weren't. And >>> your summary is not an accurate description of the meeting. The >>> sole mention in the minutes of SPEKE is from me. And the "concerns" >>> are a recitation of comments received. That's how it works. You get >>> comments and you resolve them. >>> >>>> May 2012 >>>> - Kevin Igoe points out a limitation due to "hunting-and-pecking" >>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03099.html >>> >>> He does no such thing. He just said that if the prime defining the >>> curve p =3D 3 mod 4 that it's easier to compute the square root. >>> >>>> - Zhou Sujing and Dan have an exchange that's hard to follow. >>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03115.html >>>> >>>> July 2012 >>>> - At IETF 84 TLS meeting (CFRG does not meet): >>>> - Kevin Igoe informs TLS WG, as the CFRG chair: >>>> "We approve of it, very clear and usable for general setting." >>>> http://www.ietf.org/proceedings/84/minutes/minutes-84-tls >>> >>> Also note the comment: "Tie Dragonfly into EST would be very useful" >>> Yes, it would. >>> >>>> Oct 2012 >>>> - Kevin Igoe calls CFRG attention to Dragonfly draft-00 >>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03214.html >>>> >>>> - Jonathan Katz asks for a security proof - there is none >>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03215.html >>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03216.html >>> >>> Correct. There is no formal proof of security. See my slides from >>> IETF 83. >>> >>>> Dec 2012 >>>> - Kevin Igoe calls CFRG attention to Dragonfly >>>> - raises timing attack issue, proposes 2 fixes, including >>>> rediscovery of Dan's original broken method (2008) >>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03258.html >>> >>> This is further discussion on addressing a side channel attack. >>> Your attempt to spin this as "broken" is somewhat desperate. >> Modern cryptographic practice demands constant time, jump-free, >> no variable memory access cryptography. >>> >>>> - Rene Struik points out the error in Kevin's proposal, and >>>> the inefficiency of Dragonfly relative to SPEKE >>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03259.html >>> >>> He does no such thing. His "Suppose A and B=E2=80=A6" is a recitation= of >>> a version of SPEKE that does not hash the password into a group in >>> the domain parameter set. It's neither here nor there with respect >>> to dragonfly. He further goes on to suggest on a check for "point at >>> infinity". Which is already part of dragonfly. >>> >>> There is no "error" noted and no "inefficiency" mentioned either. >>> >>>> - Scott Fluhrer points out the error in Kevin's proposal, and >>>> proposes a flawed "mostly constant time" fix. Dan and Kevin >>>> embrace it. >>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03260.html >>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03262.html >>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03263.html >>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03264.html >>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03265.html >>> >>> As noted in the email thread, the described fix was added to the >>> draft at the time. Your opinion on it being "flawed" has already been >>> noted. >>> >>>> Feb 2013 >>>> - draft-01 is uploaded with flawed sidechannel fix >>>> - also quietly fixes security issue reported by Dylan Clarke >>>> and Feng Hao >>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03309.html >>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03529.html >>> >>> This is a small sub-group attack possible if one does not check >>> validity of received elements. All incarnations of dragonfly-- TLS-PWD, >>> EAP-PWD and 802.11 already did this. It is entirely my fault that I lef= t >>> that >>> crucial step out of the -00 version of the CFRG draft but it is hardly >>> a flaw. >>> >>>> Apr 2013 >>>> - Kevin Igoe mentions a last call for Dragonfly >>>> "The design looks mature, it addresses a real need, and no one >>>> has raised any issues." >>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03383.html >>> >>> That's correct. You are included in that "no one". >>> >>>> May 2013 >>>> - Feng Hao asks CFRG to consider J-PAKE (an alternative) >>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03430.html >>> >>> Completely irrelevant. >>> >> I don't think so. Your repeated insistence to the contrary, there are >> people who >> will use RC4 on TLS connections, etc, etc. Our endorsing a protocol >> when superior >> alternatives exist is a bad thing, because insecure options have a >> nasty habit of being >> turned on. You've argued that because you and your employer don't see >> an issue, we should >> be happy to endorse this. > > RC4? What the hell does that have to do with anything? > > And when did I insist that people will not use RC4? And when did I > mention my employer? Never and never. > > You are obviously very confused. Your argument seems to be that even if dragonfly is later discovered insecu= re, or we don't want to use it, it will be fine because people will configure their systems appropriately. Our experience shows that is not the case. I have a much more cynical view: systems are only fixed when broken, and not even then. We are the sole line between a bunch of idiots and the NSA. > >>>> July 2013 >>>> - Rene Struik points out spec bugs, raises timing attack issue >>>> again >>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03486.html >>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03489.html >>> >>> "Spec bugs", in other words typos. Yes, he brings up an issue that >>> had previously been addressed. >>> >>>> - IETF 87, CFRG meeting: >>>> - "The author is working on a new (and hopefully final) draft" >>>> http://www.ietf.org/proceedings/87/minutes/minutes-87-cfrg >>> >>> Sadly, it's not. I have to address the "Spec bugs" and address >>> Rene's other comments, none of which demonstrate security flaws. >>> >>>> Aug 2013 >>>> - draft-02 is uploaded with modifications to "hunting-and-pecking" >>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03509.html >>> >>> Don't forget comments dealing with internationalization! >>> >>> The change is from a comment received from, if I recall, Russ Housley >>> to use the technique from FIPS 186-3 to hide the bias added by the >>> modular reduction. Again, a very nice comment, happily accepted. >> Knuth discusses this in detail in Volume 2. Bleichenbacher got a lot >> of mileage from >> this. > > So? Aside from giving you an opportunity to name drop, what does > that have to do with anything? The comment was made, it was not > asserted as being some original insight, and it was accepted. > >>>> Sep 2013 >>>> - SeongHan Shin asks CFRG to consider AugPAKE (an alternative) >>>> http://www.ietf.org/mail-archive/web/cfrg/current/msg03523.html >>> >>> Completely irrelevant. (Again, not sure why you're have become such >>> a cheerleader for AugPAKE). >>> >>>> Nov/Dec 2013 >>>> - Joe Saloway begins TLS-PWD last call, and informs TLS WG that: >>>> "The underlying cryptographic protocol for TLS-PWD has been >>>> reviewed by the IRTF CFRG group with satisfactory results." >>>> http://www.ietf.org/mail-archive/web/tls/current/msg10476.html >>>> >>>> - Uproar on TLS WG: >>>> >>>> - Many object to lack of formal security analysis: >>>> Douglas Stebila, Uri Blumenthal, Bodo Moeller, Rene Struik, >>>> Watson Ladd >>> >>> Missing, of course, the caveat "-- except I believe that whenever >>> possible the IETF should aim to standardize cryptographic protocols >>> that are unencumbered by license fees and patents. If the choice >>> arises between a protocol that carries both (provable security and >>> Intellectual Property) and a protocol that has neither - I'd strongly >>> prefer the latter." >>> >>>> - Many point out better alternatives: >>>> SeongHan Shin, Robert Ransom, Watson Ladd, Trevor Perrin >>> >>> And you're all free to write up Internet Drafts on them too! >> Why do you want Dragonfly as opposed to J-PAKE? If you think it is >> going to slow, call up Feng Hao and offer to help. That would satisfy th= e >> need you identify in your usecase in the TLS WG. >> Or is this not about solving the problem of password authenticated key >> exchange, >> but putting your protocol into things? > > Why don't you do a draft on J-PAKE? I asked you before to please write > an Internet Draft. Please. I would really appreciate the opportunity to > review such a document. Why don't you offer to help Feng Hao? He already wrote a such a draft. I'm not the right person to bri^H^H^H lobb= y the WG chairs to get this through, because I don't have thousands of dollar= s of other people's money to spend on junkets in Honolulu. I also don't have a n= eed for a PAKE: TOFU with certificates works well enough for my usecases. But f= or embedded devices I see the utility. > > What this has to do with is a desire to have a TLS cipher suite to > satisfy legitimate use cases yesterday. You come along 2+ years late > and then say that it should all be abandoned and something else pursued. > Because _you_ don't approve. Your suggestions might've been helpful > 2+ years ago, now they're just a delaying tactic. SRP satisfies this use case and was available then. J-PAKE was 3 years old then. The Socialist Millionaire's Protocol was 5 years old. > >>> In fact, SeongHan Shin has been following me around EMU, IPsec, >>> CFRG and now TLS doing just that. After I write a dragonfly I-D he >>> writes an AugPAKE I-D. Nothing is stopping you from doing it too. >>> >>>> - Security flaws are pointed out by Bodo Moeller and >>>> CodesInChaos >>>> http://www.ietf.org/mail-archive/web/tls/current/msg10708.html >>>> http://www.ietf.org/mail-archive/web/tls/current/msg10768.html >>> >>> Bodo's comment has been addressed. I dispute the use of the term >>> "security flaw" to describe it but that is consistent with the rest of >>> your email. >>> >>> CodesInChaos suggested using PBKDF2 to hash the password. This >>> really provides no additional benefit,, as I noted in a subsequent >>> email (see coWPAtty and family attacks against a protocol that uses >>> PBKDF2). >>> >>>> - Rene Struik and Bodo Moeller dispute that CFRG approved this >>>> http://www.ietf.org/mail-archive/web/tls/current/msg10769.html >>>> >>>> http://www.ietf.org/mail-archive/web/tls/current/msg10812.html >>> >>> Actually, Rene notes that CFRG has not issued a LC. He does raise >>> some comments, many of which are already addressed in the draft >>> and he points out the "Spec bug" you allude to earlier. He suggests >>> relaxation of one of the restrictions on parameter generation that I >>> decline to accept. And he finds some additional typos and an >>> erroneous description of point addition. Helpful comments. >>> >>>> - Eric Rescorla (TLS WG chair) states: >>>> "we did have a verbal report back from the chair of the CFRG >>>> that they considered it satisfactory" >>>> http://www.ietf.org/mail-archive/web/tls/current/msg10819.html >>> >>> Indeed. >>> >>> So what you've brought up is that there has been discussion of >>> dragonfly on the list and it has, in fact, been reviewed. Quite a few >>> comments have been made and resolved, security critical issues have >>> been raised and properly addressed. >> Sorry, but review is not enough. Approval is. What standard is the >> chair applying here? > > The existing standard that is in place for TLS and the IETF. I don't think you noticed that this standard produced IPSEC with encrypt only, IKE1, TLS bugs galore, and many other issues. As I mention below, this seems to b= e the real difference: you are the first person who ran into the tougher standards many of us think are warranted. > >>> There are no flaws in the key exchange. It has some aspects to it >>> that some may feel is a benefit and some may feel is a detriment. >>> Personal taste is not something that can be universally accommodated. >>> >>> Nothing you have raised here is reason to stop advancement of >>> this draft. >> I disagree. This draft is reminiscent of the worst of 90's >> cryptography: ad-hoc assumptions, >> no formal statement of security, gratuitously not a circuit, and not >> subject by review by anyone >> who is a cryptographer. It may be that this draft has exposed a fault >> line between those who think >> the current process is acceptable and those who do not. > > It lacks a formal security proof. That is all. There is no other proble= m > with it. The side channel attack issue was already addressed after a > long thread a long time ago. One might consider revisiting it if the > people harping about it really wanted a change, instead of just using > it as a box on which to stand so as to shout more loudly. Could you please define what you mean by secure? I've been trying for the past week to come up with a formal definition for the security of dragonfly, and not one of them has been any good. > > Lacking any valid issue with dragonfly I suggest you go back to > obsessing over RC4. If RC4 was the only cryptography mistake the TLS WG made, life would be nic= e. > > Dan. > > Sincerely, Watson Ladd --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From dol@cryptocom.ru Sun Dec 15 00:36:03 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5591AE1D5; Sun, 15 Dec 2013 00:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.448 X-Spam-Level: ** X-Spam-Status: No, score=2.448 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_CHARSET_FARAWAY=2.45, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cx7jWDVpVovo; Sun, 15 Dec 2013 00:35:59 -0800 (PST) Received: from mail.reedcat.net (mail.reedcat.net [85.17.92.214]) by ietfa.amsl.com (Postfix) with ESMTP id C0BF91AE1D7; Sun, 15 Dec 2013 00:35:59 -0800 (PST) Received: from [192.168.63.8] (broadband-188-255-54-202.nationalcablenetworks.ru [188.255.54.202]) by mail.reedcat.net (Postfix) with ESMTPSA id 00E7D1A4927; Sun, 15 Dec 2013 12:35:50 +0400 (MSK) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: text/plain; charset=koi8-r From: Basil Dolmatov X-Priority: 3 (Normal) In-Reply-To: <8cf8a51b9dcfd0c40b80ae2aad2cff7c.squirrel@www.trepanning.net> Date: Sun, 15 Dec 2013 12:35:49 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <18138981706be6221b2d05187da48394.squirrel@www.trepanning.net> <8cf8a51b9dcfd0c40b80ae2aad2cff7c.squirrel@www.trepanning.net> To: Dan Harkins X-Mailer: Apple Mail (2.1822) X-Mailman-Approved-At: Thu, 26 Dec 2013 12:00:54 -0800 Cc: Watson Ladd , cfrg@ietf.org, "tls@ietf.org" , saag@ietf.org Subject: Re: [saag] [Cfrg] [TLS] Question regarding CFRG process X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Dec 2013 08:36:04 -0000 Was impressed by the quality of arguments used in discussing of new = cryptographic protocols. :-/ dol@ 13 =C4=C5=CB. 2013 =C7., =D7 12:35, Dan Harkins = =CE=C1=D0=C9=D3=C1=CC(=C1): >=20 >=20 > You obviously read too much fiction and have too little practical > experience. Dragonfly is not a threat to human life. Get a grip. >=20 ... > I'm also familiar with well-respected cryptographers who participated > in the IPsec WG in the 90s. You are nobody compared to them and your > ignorant reference confirms that. >=20 >>>>>=20 >=20 > Dan. >=20 >=20 >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg >=20 From kent@bbn.com Mon Dec 30 07:36:41 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98731AE0B9; Mon, 30 Dec 2013 07:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.039 X-Spam-Level: X-Spam-Status: No, score=-2.039 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5lMCUfKz2r8; Mon, 30 Dec 2013 07:36:40 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0184B1ADF4F; Mon, 30 Dec 2013 07:36:39 -0800 (PST) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:65173) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VxetM-000CmF-D4; Mon, 30 Dec 2013 10:36:32 -0500 Message-ID: <52C19300.3050201@bbn.com> Date: Mon, 30 Dec 2013 10:36:32 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ben Laurie References: <52A8B1D0.2080304@dcrocker.net> <52A8E0E9.5020409@dcrocker.net> <52A9E61C.8030300@bbn.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: perpass , saag Subject: Re: [saag] [perpass] Draft charter for a Transparency Working Group X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 15:36:42 -0000 Ben, > How's this? > > [1] A cryptographically verifiable log is an append-only log of hashes > of more-or-less anything that can prove its own correctness > cryptographically. > > For example, from RFC 6962: “The append-only property of each log is > technically achieved using Merkle Trees, which can be used to show > that any particular version of the log is a superset of any particular > previous version. Likewise, Merkle Trees avoid the need to blindly > trust logs: if a log attempts to show different things to different > people, this can be efficiently detected by comparing tree roots and > consistency proofs. Similarly, other misbehaviours of any log (e.g., > issuing signed timestamps for certificates they then don't log) can be > efficiently detected and proved to the world at large.” > > See RFC 6962, http://www.links.org/files/CertificateTransparencyVersion2.1a.pdf > and http://www.links.org/files/RevocationTransparency.pdf for > background. > Sorry to be so late in responding; holidays ... The text describing how 6962 uses Merkle trees is good. I think the phrase "prove its own correctness" is way too broad. The example you cite shows how to demonstrate internal consistency for a log, and to enable third parties to verify certain lob properties. That is much narrower than what the term "correctness" implies. Steve