From nobody Sat Oct 1 10:28:25 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF24812B08E for ; Sat, 1 Oct 2016 10:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 lDMUkNqeV2Xf for ; Sat, 1 Oct 2016 10:28:15 -0700 (PDT) Received: from nm20-vm5.access.bullet.mail.bf1.yahoo.com (nm20-vm5.access.bullet.mail.bf1.yahoo.com [216.109.115.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1852E12B0D2 for ; Sat, 1 Oct 2016 10:28:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1475342893; bh=MgIRmy2zn3lKVqxWat1HazMiEul34A2kXe6Yen4h90E=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=aKzyk9ncuxtcJ3TRFVn5R3nLj880LSQGQYOV4WH5/XfXDIBZAYgWDG2IgyuzOvFAUtZxjKmOZw+Db9AQcTcuZz4U0LG2ii5KNw9Dwf8z2bET2Afu5LR/21hRvNU5kyFPt8ymV0+Iy1IKe3WUnO2RiwIgmnkyIHHUN/NTo54g3tmvciT9r6TI+PxJszBvmtEjucg1zaeQgmuXzdEg1fvxio95b70eD/eEMX1SfgdSi7AtZVluRS997ZjYS8xZWPszswhKcNPi2TaUaCSo2p72ToSR9udcOiyQJjfIMiO0GdAfgwJlKjKdlSfrmKMcDFm6qXJI2O4ZgKvBiVqkZfj5jA== Received: from [66.196.81.158] by nm20.access.bullet.mail.bf1.yahoo.com with NNFMP; 01 Oct 2016 17:28:13 -0000 Received: from [98.138.226.242] by tm4.access.bullet.mail.bf1.yahoo.com with NNFMP; 01 Oct 2016 17:28:13 -0000 Received: from [127.0.0.1] by smtp113.sbc.mail.ne1.yahoo.com with NNFMP; 01 Oct 2016 17:28:01 -0000 X-Yahoo-Newman-Id: 457324.4873.bm@smtp113.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: X8wlMcQVM1lYiySuTrPif.nUpwyv9M7Zc8hVkOBypH6f3QS m4AeFw_YQVEO7aR1s2ffuQGfrYVLZN5q_pgVvQGzrwzN.9rexWIvACIDkeSc .2fzpY1IwLmNv.7pnBtoKL0tF1PQSqyFk8gtTff9.1JEnsSVenwXTQxU1eFT htf84AeojLCecVH5iA7bteLDINJhEFhXYvtjcoiw1.jasrH0Ny_J0DLj0fvn HAssjfr1q.zGIAQ3MEAWK4zjLVa3VS9abqGEilQWPqp7GVUG7cm0blEQHkL2 75RYvD3vJJfSwGglkiHXDtIWPSmrIqu9AgF9HUtOlvq5Eqmt_6m.T3C.Z6AE hC.owusi14A_bqEKzpPpeV226DoZ4bW6XFrtFpXsnXZ.HW5t8WZEY93RyReY PqWLG_hP.6MrsH9v9jl_TUxPuVZvMobeWSDxAIzgj3m0t5_AAYgsomJMRwJc 04kk8_JXxnNemiVYDHkawhxPlkKAZ_TaayjKaop9d5R4luh0uh7w5NL.SkVJ ezd_XLb2eGbBJWmO3ClvRot7DfqNYgLEz8pUqB1Uwy3j9olKomg-- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from [192.168.1.153] (209-6-88-55.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com [209.6.88.55]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 35B9B1C603B; Sat, 1 Oct 2016 13:28:11 -0400 (EDT) To: Dino Farinacci References: <17032e8e-f1d0-8fb4-7294-2e2ca5c9fb06@mandelberg.org> <2290972B-B93D-496A-8AF3-16B72D19B654@gmail.com> From: David Mandelberg Message-ID: <4c2ca5d7-ce89-b107-f7fa-1f22ba19eaf5@mandelberg.org> Date: Sat, 1 Oct 2016 13:28:06 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Dwt6pnwnVhVDHhDEFwkQf4t99BkeVj9b6" Archived-At: Cc: The IESG , draft-ietf-lisp-lcaf.all@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-lisp-lcaf-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2016 17:28:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Dwt6pnwnVhVDHhDEFwkQf4t99BkeVj9b6 Content-Type: multipart/mixed; boundary="4DPJv92vbn0l4EmhQQVfCpl4IaQm330U3" From: David Mandelberg To: Dino Farinacci Cc: The IESG , secdir@ietf.org, draft-ietf-lisp-lcaf.all@ietf.org Message-ID: <4c2ca5d7-ce89-b107-f7fa-1f22ba19eaf5@mandelberg.org> Subject: Re: secdir review of draft-ietf-lisp-lcaf-15 References: <17032e8e-f1d0-8fb4-7294-2e2ca5c9fb06@mandelberg.org> <2290972B-B93D-496A-8AF3-16B72D19B654@gmail.com> In-Reply-To: --4DPJv92vbn0l4EmhQQVfCpl4IaQm330U3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 09/26/2016 12:43 PM, Dino Farinacci wrote: >> On 09/25/2016 06:15 PM, Dino Farinacci wrote: >>>> I found one issue in various parts of the document (described below)= , >>>> but I'm not sure it's relevant to security. If it is, then I think t= his >>>> document is Almost Ready. If not, then I think this document is Read= y >>>> With Nits. >>>> >>>> There are multiple places in the document where it's possible to enc= ode >>>> semantically equivalent information in multiple ways, despite the wo= rd >>>> "canonical" being in the title of the document. Is there anything th= at >>>> relies on these addresses being canonical for security purposes? >>> >>> No not for security purposes. There are multiple ways because we allo= w some nesting of information as well as allow for compatibility for olde= r implementations that can=92t parse some AFIs and LCAFs but is required = to parse the AFI-List LCAF type. >> >> Ok, then I think it needs to be made clear in the security >> considerations that this format cannot be relied on to have no more th= an >> one representation for the same information. >=20 > Sorry, I am not following your point. The nesting procuedure of LCAFs a= llow the same type of address to be expressed multiple ways. I can=92t te= ll from your commentary if this is a good thing for security or a bad thi= ng. So please provide some suggested text on what you would like to see i= n the Security Considerations section. Ok, here's what I'd like to see. (But remember that this is just a suggestion. From the SecDir boilerplate: "Document editors and WG chairs should treat these comments just like any other last call comments.") It is possible to encode the same address in multiple ways using LCAF. For example, the IPv4 address 192.0.2.1 can be encoded as "AFI=3D1, 192.0.2.1", "AFI=3DLCAF, lcaf-type=3DAFI-list, AFI=3D1, 192.0.2.1", or "AFI=3DLCAF, lcaf-type=3DAFI-list, AFI=3D1, 192.0.2.1, AFI=3D0". This mea= ns that systems that use LCAF must not assume that two distinct strings of bytes are distinct LCAF addresses. Additionally, if an LCAF address is digitally signed or MACed, the specific encoding of the address must be preserved in order for the signature or MAC to be valid on receipt. --=20 David Eric Mandelberg / dseomn http://david.mandelberg.org/ --4DPJv92vbn0l4EmhQQVfCpl4IaQm330U3-- --Dwt6pnwnVhVDHhDEFwkQf4t99BkeVj9b6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlfv8iYACgkQRKlmUHCg4sAzlACcDZDnoZUF1kNSm01tVSnp+8jk 4dkAnjLow8u5S/cSM+vj/qX0aMJ6v4AJ =Wnzr -----END PGP SIGNATURE----- --Dwt6pnwnVhVDHhDEFwkQf4t99BkeVj9b6-- From nobody Sat Oct 1 11:31:06 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3AD812B02E; Sat, 1 Oct 2016 11:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 CU_nTu2eJO6n; Sat, 1 Oct 2016 11:30:58 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E83A912B01D; Sat, 1 Oct 2016 11:30:57 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id q2so50587673pfj.3; Sat, 01 Oct 2016 11:30:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/3PKlis/vG3JYUkpggPxRnQ5sj7Fq3mR41zg2EVtMxI=; b=p2jdCLWnf0mkacT7lxlnB4vqUg+VxKIpcNJGOyCYQIs3Jj4dEyFOBTIw/QkRT4FksW GpVHiGqIw+lghIkKJPguoPk4qVgeObP4CIJi7J0yBCwcuLtst6YbQgVLRdycGvi58l9l 3vhalPsjmhi1qNwh+Yh4C4wo1eTUZ1eutnlgopDegisGIhuCb1fwlmhm6n/ytfS6wuO3 Kjw/AoPcqgDPA/2diLwyMdDixF2QqHfcuE+VC7dgFVEsCLOjqgG1vdU3Kw/XQ6hLQSBY w/7u4pW0fX7rV/MQoT+LdIPV+EKUO25LQbv/jTjS2UuPpyXXHohGPZWcQKOkgZ6UeEOJ NxdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/3PKlis/vG3JYUkpggPxRnQ5sj7Fq3mR41zg2EVtMxI=; b=HEr6SNFXIui9ziZraZDId+XP5ihDU93xZr/RxndhUYiylJFh8kYjhpmUmsyJBowUt4 sbr8lHmfPfe15bxdDN+u/OTJwbao4CAlxAyYiz3HV/Hzjsa0jhe7m8lwFt8h/QP+B2aR ZhuHEgCSqoiE9iUwPDhYdiPeAVFm+fC/MN+hgviZ+Iy6iNjKo9a7agf/tbkg/F32GV0T iy6oSBcMsiKodHfc76j2vw7LtQ0MZfGkB/rzzXgHaQ+F3S9fcbzd24sbcqx7+I8eB3qO t/LhxdvCR5QIKa7qEFCMX3tG3lb7OahH+AF+jdL/80ftGIe0mk96lUqSPz+CYmGvv0il 57hw== X-Gm-Message-State: AA6/9Rmrrusrzd2kcqjGtqzwvcetIidOs6Rdx3dnVYh04X91oAzwQsFJSipZDC6M9vrWIw== X-Received: by 10.98.155.7 with SMTP id r7mr22337459pfd.171.1475346657342; Sat, 01 Oct 2016 11:30:57 -0700 (PDT) Received: from [10.194.125.197] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id c26sm36465715pfe.20.2016.10.01.11.30.56 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 01 Oct 2016 11:30:56 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (14A456) In-Reply-To: <4c2ca5d7-ce89-b107-f7fa-1f22ba19eaf5@mandelberg.org> Date: Sat, 1 Oct 2016 11:30:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <17032e8e-f1d0-8fb4-7294-2e2ca5c9fb06@mandelberg.org> <2290972B-B93D-496A-8AF3-16B72D19B654@gmail.com> <4c2ca5d7-ce89-b107-f7fa-1f22ba19eaf5@mandelberg.org> To: David Mandelberg Archived-At: Cc: The IESG , draft-ietf-lisp-lcaf.all@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-lisp-lcaf-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2016 18:30:59 -0000 > On Oct 1, 2016, at 10:28 AM, DavidMandelberg wrote:= >=20 > are distinct LCAF addresses. Additionally, if an LCAF address is > digitally signed or MACed, the specific encoding of the address must be > preserved in order for the signature or MAC to be valid on receipt. Okay so based in this text I finally get the point of your comment.=20 But what you state is not true. These addresses are content in a message. If= a message is signed and includes an address if the signer, that address is f= rom the Io header.=20 And no matter how the address is encoded, it always shows up as AFI=3D1 and a= n IPv4 address.=20 Dino= From nobody Sat Oct 1 11:53:49 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD03B12B105 for ; Sat, 1 Oct 2016 11:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 bM3MGtlkBT83 for ; Sat, 1 Oct 2016 11:53:46 -0700 (PDT) Received: from nm14-vm8.access.bullet.mail.bf1.yahoo.com (nm14-vm8.access.bullet.mail.bf1.yahoo.com [216.109.115.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF80B12B0F8 for ; Sat, 1 Oct 2016 11:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1475348024; bh=livEWbglfg/DwsjWGHA6V/DtI8bQJ1KY7OxO4MdF0eg=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=lXixKRfETIbPNy4RTtdrnCLMQMymgOi7qRTa1uuU+ZZHF4xhRZIgyEqsdBSMEZJFLwbfyPgCrg+kzm9FnkP/ygFtxTrpxeX3miLLcxyWVQx1MuT6+O5avBPq/7kYhRfEiC0RCCrXpapPXTZ0cJJhcUMfcPw9Cfn/6VZvCCUrCaI4QyniPk6he03wQk8+2Wb/9mJm45CEC45zpmI7vDmKdv1VajjRxgWh29JgkWDGfE4/psBaDQ7CmuiOeyjPYMAZIHyz74rG6zGgfdZxsA+VOTn7IZEhgcwPIuaRlvrW8RCym8V0d6GZb3dIBQFPd7VIRxSFiFqP6A682xGDoPyiIQ== Received: from [66.196.81.160] by nm14.access.bullet.mail.bf1.yahoo.com with NNFMP; 01 Oct 2016 18:53:44 -0000 Received: from [98.138.104.96] by tm6.access.bullet.mail.bf1.yahoo.com with NNFMP; 01 Oct 2016 18:53:44 -0000 Received: from [127.0.0.1] by smtp116.sbc.mail.ne1.yahoo.com with NNFMP; 01 Oct 2016 18:53:44 -0000 X-Yahoo-Newman-Id: 436499.53093.bm@smtp116.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 9ifxSwAVM1ncyukM8cVQI1FMHfQf3rpshFPVONIRgvtWA2_ CLq0R3Am.gHcne66eQEzf.sk43oud7R.bLbDEjwGduioWcTJSnjD4V6Fq5jE O829CsQAQ8aXMhRrEVmGRYurdGUb9RYY7QRqwDxdsdWlwIzyTppRYAekQAbB seblu1UtFC.ZE2Uh8rxj_rik761m4WmeYggcKQrCEg1JV7mhlXKo2TOWypB0 e1VBE3aLcqylTDPeYn4YNWtAM4ZZoCqnF6VVZ8VX0Xa3UrPsnLevybXd.vUz tyI_lzFVHKIlqfL4nrlmfYny.zkpG9AuISbs8bVSvXuiNlKrqWsgfj.NC0R4 2PwA5FUgUYXeu5N2skRrjqObmSJvO9W59Pap5R0uhS5xLv10i5hqYm1NFO8v HDuGLCQmLE7P4ITjwBbSMntLx4rv1Bhf9ki7icbHzNEhTZLkJPHI5KzJxBur ZYMIWg_mZD_do1huIHvRru547YJ.hyzg75fpimT9rKBc4Nv9xQV79w4ZiA25 Wb_1Vm6N6EaPbTpljWulrX1CSWrBJPwASHj5TPBZ1THF9.J3H X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from [192.168.1.153] (209-6-88-55.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com [209.6.88.55]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 6DB4A1C603B; Sat, 1 Oct 2016 14:53:43 -0400 (EDT) To: Dino Farinacci References: <17032e8e-f1d0-8fb4-7294-2e2ca5c9fb06@mandelberg.org> <2290972B-B93D-496A-8AF3-16B72D19B654@gmail.com> <4c2ca5d7-ce89-b107-f7fa-1f22ba19eaf5@mandelberg.org> From: David Mandelberg Message-ID: Date: Sat, 1 Oct 2016 14:53:38 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0PuvOcO4xPgo0vNKhiuGXX4Mc1CrEcvMV" Archived-At: Cc: The IESG , draft-ietf-lisp-lcaf.all@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-lisp-lcaf-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2016 18:53:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0PuvOcO4xPgo0vNKhiuGXX4Mc1CrEcvMV Content-Type: multipart/mixed; boundary="Gp6mQSm01pVXnubllbtRenQaBPtFglS1r" From: David Mandelberg To: Dino Farinacci Cc: The IESG , secdir@ietf.org, draft-ietf-lisp-lcaf.all@ietf.org Message-ID: Subject: Re: secdir review of draft-ietf-lisp-lcaf-15 References: <17032e8e-f1d0-8fb4-7294-2e2ca5c9fb06@mandelberg.org> <2290972B-B93D-496A-8AF3-16B72D19B654@gmail.com> <4c2ca5d7-ce89-b107-f7fa-1f22ba19eaf5@mandelberg.org> In-Reply-To: --Gp6mQSm01pVXnubllbtRenQaBPtFglS1r Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 10/01/2016 02:30 PM, Dino Farinacci wrote: >=20 >> On Oct 1, 2016, at 10:28 AM, DavidMandelberg wr= ote: >> >> are distinct LCAF addresses. Additionally, if an LCAF address is >> digitally signed or MACed, the specific encoding of the address must b= e >> preserved in order for the signature or MAC to be valid on receipt. >=20 > Okay so based in this text I finally get the point of your comment.=20 >=20 > But what you state is not true. These addresses are content in a messag= e. If a message is signed and includes an address if the signer, that add= ress is from the Io header.=20 >=20 > And no matter how the address is encoded, it always shows up as AFI=3D1= and an IPv4 address.=20 Gotcha, it seems I misunderstood how LCAF will be used. Sorry for the noi= se. >=20 > Dino >=20 --=20 David Eric Mandelberg / dseomn http://david.mandelberg.org/ --Gp6mQSm01pVXnubllbtRenQaBPtFglS1r-- --0PuvOcO4xPgo0vNKhiuGXX4Mc1CrEcvMV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlfwBjIACgkQRKlmUHCg4sANeQCfQ8JCY4twCrlIYFmKatLnlZi6 ApkAniWVirh/U3OmBe3RRWg+erFLCTHq =Oja0 -----END PGP SIGNATURE----- --0PuvOcO4xPgo0vNKhiuGXX4Mc1CrEcvMV-- From nobody Sat Oct 1 12:31:54 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A289E12B113; Sat, 1 Oct 2016 12:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 J14jk0QdLrqj; Sat, 1 Oct 2016 12:31:51 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FDEB12B105; Sat, 1 Oct 2016 12:31:51 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id s13so50828028pfd.2; Sat, 01 Oct 2016 12:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LLVv7IsarbOlT9OjGFWvkEYnX9C9qXwLf7n2ayGEJ6I=; b=FpnNHulSjOkKTcwCiwrvSStWL5xKqk3Jwbnl91aZerKHnykg2ROkaY9sBk5EYblXK0 dIu2e8z/RCVCgnrxIrONMFQK7k55OuzWYOhsTKxIElJnZDZZZSnuezHhDStGwS9dhxVp Fgom7UUHVcBbcYnW2fz/+4Tn0Yo7eFY2YQhObXXCZOQTEE0zrUaEEGo/dd9CW3MZriWc 57dINlEmQIW7yrMYSZDT5KOelpsUWezdPOp8/Pq2h0dx11TX5XCgXv8V4qwgRHqdU66v yBCnwnKM+jdiSJpuRibE1Al7M/yArJoOwyuF58SH9ZuKuWTBuen+DdVpJ6kIxMEgS8X0 Y3Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LLVv7IsarbOlT9OjGFWvkEYnX9C9qXwLf7n2ayGEJ6I=; b=XsGGT28351IdDMVsKL2qygHEhRpeyi6NkspOfETOBhZVuthKOQIogSuX8/dhBU3Tcj nzbuDlcdt//uSD2tRBxO1Q7Ln+tXAL4t7vX5p9kRG99qwERGyONDHvmhGeQs13bafXpL r7Uu89wg9o8N/TOfzOBrjatsJd0eECJKbZg93XvGcI+BV/0SHUD1+5PcyqcBf2jRrpvm axZGcjt2K+n2MgaMileoSZuVqZUIHHiAJjS0qlt/Em4pQmKZSY89SswIYFA1DBU2STjs 9HxpcH0MbmU2QytETy6RAjK0L8GKiwl36NTqvshdP0JQuG20pLseaIul1qGsXisIOvJs L5PA== X-Gm-Message-State: AA6/9RlAPLSJh58w6x8YGGLSVcKO8erNUNY2TBGJHu5HUtZl1t9Jm4WE0Sh8OTKSVNsXcw== X-Received: by 10.98.15.210 with SMTP id 79mr23651792pfp.183.1475350310791; Sat, 01 Oct 2016 12:31:50 -0700 (PDT) Received: from ?IPv6:2603:3024:151c:55f0:f4f7:4750:802b:136? ([2603:3024:151c:55f0:f4f7:4750:802b:136]) by smtp.gmail.com with ESMTPSA id 77sm10849632pfx.91.2016.10.01.12.31.49 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 01 Oct 2016 12:31:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (14A456) In-Reply-To: Date: Sat, 1 Oct 2016 12:31:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <75EAB0F7-3358-43A7-A61B-275386B3787A@gmail.com> References: <17032e8e-f1d0-8fb4-7294-2e2ca5c9fb06@mandelberg.org> <2290972B-B93D-496A-8AF3-16B72D19B654@gmail.com> <4c2ca5d7-ce89-b107-f7fa-1f22ba19eaf5@mandelberg.org> To: David Mandelberg Archived-At: Cc: The IESG , draft-ietf-lisp-lcaf.all@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-lisp-lcaf-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2016 19:31:52 -0000 So are we good to go? Have a look at the last HTML diff file I sent and let me know if we are in s= ync.=20 Per Deborah's suggestion I'll post a draft on Wed after the last call deadli= ne.=20 Dino > On Oct 1, 2016, at 11:53 AM, David Mandelberg wrote= : >=20 >> On 10/01/2016 02:30 PM, Dino Farinacci wrote: >>=20 >>> On Oct 1, 2016, at 10:28 AM, DavidMandelberg wrot= e: >>>=20 >>> are distinct LCAF addresses. Additionally, if an LCAF address is >>> digitally signed or MACed, the specific encoding of the address must be >>> preserved in order for the signature or MAC to be valid on receipt. >>=20 >> Okay so based in this text I finally get the point of your comment.=20 >>=20 >> But what you state is not true. These addresses are content in a message.= If a message is signed and includes an address if the signer, that address i= s from the Io header.=20 >>=20 >> And no matter how the address is encoded, it always shows up as AFI=3D1 a= nd an IPv4 address.=20 >=20 > Gotcha, it seems I misunderstood how LCAF will be used. Sorry for the nois= e. >=20 >>=20 >> Dino >>=20 >=20 >=20 > --=20 > David Eric Mandelberg / dseomn > http://david.mandelberg.org/ >=20 From nobody Sat Oct 1 19:35:00 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA6C12B0F7 for ; Sat, 1 Oct 2016 19:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 2SVanGORGZkR for ; Sat, 1 Oct 2016 19:34:54 -0700 (PDT) Received: from nm8-vm1.access.bullet.mail.bf1.yahoo.com (nm8-vm1.access.bullet.mail.bf1.yahoo.com [216.109.114.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A9B112B043 for ; Sat, 1 Oct 2016 19:34:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1475375691; bh=1Plb1id3RLNf9De8OSnWfzpfaxGpgGuSF5mL15B/TrQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=SAN3697Z5qFThssDgwL9wGBwCbovfeEuMlYVsKKw4x6axMCuoAaxtZuJX19by0W9/cuQd1an+7XHavvkYnxOsfULoJFVcrXqFKTYkCBdSqdp9LNHCSzCB4gGELCi7ejNeKGlfbNQIlaJ846t5Td5f6be26A4sy6QplnUtRBSBAKBHOrxwwpVmWKcjU99+7qvYJ2L9PU8Th5gOqJEVis16BxwSShcVZtI+FiBBsH+RZ4xxFhvF4qHUWxk2/AYCh88dNKTmUSLGIz7I6d72De0JdxW91REi843THrJTF3RnJvN7pXo9/fYXfOKABSzVOEBmktYcSNnYvh+4EFI+roI1w== Received: from [66.196.81.156] by nm8.access.bullet.mail.bf1.yahoo.com with NNFMP; 02 Oct 2016 02:34:51 -0000 Received: from [98.138.104.98] by tm2.access.bullet.mail.bf1.yahoo.com with NNFMP; 02 Oct 2016 02:34:51 -0000 Received: from [127.0.0.1] by smtp118.sbc.mail.ne1.yahoo.com with NNFMP; 02 Oct 2016 02:34:51 -0000 X-Yahoo-Newman-Id: 377912.35598.bm@smtp118.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 98bNI78VM1kjUrIqEwmQ_qN1bcf3guYZM8tRQbMcN93XqHB 3u0X2EhD8cQH39ybtnhb4MebKQtUEAC30qD76j2selgP5cWPCWicZUXAY98r 62XVKc1K_UxImWPLW_Y3wNF1nih6pDcHlWdIG9XWa2KztbM0xbterFw5AQ7X qvYsD0UpIJyu_vZvuazQAVRCWBWBzMOiXLGm4waHZ5pXIm75zeCBUnQgwZ8G PSHkH8YklHwkkJPAUvfyjMtg4QMno8M5rc_qLo7BRHCpwvN_UwqofI0DennE 3A8u.JzzoPPvg.xUuqHJtTWMQiXqJBbkpi20oVZlp2cT7VQ6ZiCtyOdOjZbw gArrGFz6v6po8kHR4Rkv85UJ4uC2k91dTX2UcIi1f4iu8IuFE7TwFw1vq0F. K8ErD8OgcMwhNbOorE2yBOprr60svjIEcGmCzbmYW7MiLok_G9W5vD43O5X. rK66bnQn10NmSGRzkvRRSfGtqxeBmhurCDZnUCwWwQKDG2CTIAne.W3tkup7 N3MiOdfSOC3o0WT8v0Dwcwh2xrzQjY0o9lUmBDyLoRQ-- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from [192.168.1.153] (209-6-88-55.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com [209.6.88.55]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 4896A1C6040; Sat, 1 Oct 2016 22:34:50 -0400 (EDT) To: Dino Farinacci References: <17032e8e-f1d0-8fb4-7294-2e2ca5c9fb06@mandelberg.org> <2290972B-B93D-496A-8AF3-16B72D19B654@gmail.com> <4c2ca5d7-ce89-b107-f7fa-1f22ba19eaf5@mandelberg.org> <75EAB0F7-3358-43A7-A61B-275386B3787A@gmail.com> From: David Mandelberg Message-ID: Date: Sat, 1 Oct 2016 22:34:46 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <75EAB0F7-3358-43A7-A61B-275386B3787A@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gaJc6tO7Q3j2gNIUa6VRDFxmE9Aee16RS" Archived-At: Cc: The IESG , draft-ietf-lisp-lcaf.all@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-lisp-lcaf-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2016 02:34:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gaJc6tO7Q3j2gNIUa6VRDFxmE9Aee16RS Content-Type: multipart/mixed; boundary="sgbJ3KWk2FD7AuaOG6qAgoaNatWS1qO5g" From: David Mandelberg To: Dino Farinacci Cc: The IESG , draft-ietf-lisp-lcaf.all@ietf.org, secdir@ietf.org Message-ID: Subject: Re: [secdir] secdir review of draft-ietf-lisp-lcaf-15 References: <17032e8e-f1d0-8fb4-7294-2e2ca5c9fb06@mandelberg.org> <2290972B-B93D-496A-8AF3-16B72D19B654@gmail.com> <4c2ca5d7-ce89-b107-f7fa-1f22ba19eaf5@mandelberg.org> <75EAB0F7-3358-43A7-A61B-275386B3787A@gmail.com> In-Reply-To: <75EAB0F7-3358-43A7-A61B-275386B3787A@gmail.com> --sgbJ3KWk2FD7AuaOG6qAgoaNatWS1qO5g Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Looks good to me, thanks! On 10/01/2016 03:31 PM, Dino Farinacci wrote: > So are we good to go? >=20 > Have a look at the last HTML diff file I sent and let me know if we are= in sync.=20 >=20 > Per Deborah's suggestion I'll post a draft on Wed after the last call d= eadline.=20 >=20 > Dino >=20 >> On Oct 1, 2016, at 11:53 AM, David Mandelberg w= rote: >> >>> On 10/01/2016 02:30 PM, Dino Farinacci wrote: >>> >>>> On Oct 1, 2016, at 10:28 AM, DavidMandelberg = wrote: >>>> >>>> are distinct LCAF addresses. Additionally, if an LCAF address is >>>> digitally signed or MACed, the specific encoding of the address must= be >>>> preserved in order for the signature or MAC to be valid on receipt. >>> >>> Okay so based in this text I finally get the point of your comment.=20 >>> >>> But what you state is not true. These addresses are content in a mess= age. If a message is signed and includes an address if the signer, that a= ddress is from the Io header.=20 >>> >>> And no matter how the address is encoded, it always shows up as AFI=3D= 1 and an IPv4 address.=20 >> >> Gotcha, it seems I misunderstood how LCAF will be used. Sorry for the = noise. >> >>> >>> Dino >>> >> >> >> --=20 >> David Eric Mandelberg / dseomn >> http://david.mandelberg.org/ >> >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >=20 --=20 David Eric Mandelberg / dseomn http://david.mandelberg.org/ --sgbJ3KWk2FD7AuaOG6qAgoaNatWS1qO5g-- --gaJc6tO7Q3j2gNIUa6VRDFxmE9Aee16RS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlfwckYACgkQRKlmUHCg4sAoRwCdEn2UtdYE0W7W0dG8DRUQPJ8c EtgAn0fwKhb/MNqt4ndL/+G1XnJX8bwt =19Dq -----END PGP SIGNATURE----- --gaJc6tO7Q3j2gNIUa6VRDFxmE9Aee16RS-- From nobody Sat Oct 1 21:12:18 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D81112B13D; Sat, 1 Oct 2016 21:12:13 -0700 (PDT) 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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 5-hNZlDtnn84; Sat, 1 Oct 2016 21:12:12 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11B8412B01C; Sat, 1 Oct 2016 21:12:12 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id r126so170011291oib.0; Sat, 01 Oct 2016 21:12:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=9Hw3ed+60X3r3P7mxNo5RbrpFE9uUU71L/ZO45MJLwU=; b=cEIt69jPqev1eqe4GnAe0Ck6KZmEbciAl/h6CheBbHNDOJE8jaMe/HU71vpx3kMvcg uDs2vYlxt7JAujH1TOFHu4rwyvZOz5DUy0Nq/DzteNhqMO3DZ386w6N/Mh15c85NrbPg ngmbltq9BXSXnuSWovpMAtgE6EuaMSJjhk5HuhwEftH3gvvCY4X5MbShea+24aiZq+0z 4oZZjP8oWCcVv0ReSOIEE+UVQEZ67X4l5kCamZTo5wkspBrBn3xl4yfotnjCFq30taNY JgijCYRwmrIyDy4mS/nmw9YauliPFrBkDXTY9lfc0w3Ythg6xBGYUmYoGzpB7O7TdoCF 4xhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=9Hw3ed+60X3r3P7mxNo5RbrpFE9uUU71L/ZO45MJLwU=; b=m24ED0b8CzQyZrV+xdmZp2UMCH2U00gqso3Xe5v/QR2haWSu6dcCQq/NNq19Jt5Sn9 5SpFdrCSFgGxHmKkgrHkdNuqj5BVOEMuyWDB9z572wEWpnVn7rtiTxqsQhJVCgMCqomw ZOCZJ2zDIwPfc4uTuTG+fj72MwxsbV/z2g9UfLmw7sS2bfnxleeDiC2c5T4MA24Kslpb yJ4VmaSsa/Ie6QPPP/SgVySLaPns4stdjAax8cMM+EFEpKI3vzbDh20U49amFoZZszTW mIqahQmksuAqnJPw3d6ROKdJgboIjN3MFeZKxRR3u89V9gg0yXjHQ5QHN/1wIPPZjMq0 1Uow== X-Gm-Message-State: AA6/9Rnqpmm5VqIexEdy8aB4KMa0UltIlSull05PHmn9LFG59qUovkyD6gXzT/MxRX/B70rsNqqUHxpK5VizZw== X-Received: by 10.157.21.76 with SMTP id z12mr10130024otz.240.1475381531436; Sat, 01 Oct 2016 21:12:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.120.201 with HTTP; Sat, 1 Oct 2016 21:12:10 -0700 (PDT) From: Radia Perlman Date: Sat, 1 Oct 2016 21:12:10 -0700 Message-ID: To: "secdir@ietf.org" , The IESG , draft-ietf-i2rs-protocol-security-requirements.all@tools.ietf.org Content-Type: multipart/alternative; boundary=94eb2c1907aa16ed0f053dda08c3 Archived-At: Subject: [secdir] Secdir review of draft-ietf-i2rs-protocol-security-requirements X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2016 04:12:13 -0000 --94eb2c1907aa16ed0f053dda08c3 Content-Type: text/plain; charset=UTF-8 On Thu, Sep 15, 2016 at 6:43 AM, Radia Perlman wrote: I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I previously reviewed version 6 and 10, and all my comments are addressed in this version (17). The secdir assignment was for version 14, but the latest version seems to be 17, so that is the one that I reviewed. Nothing substantive, certainly no security issues, and it's ready for publication. I do have a few super-minor typos in this version (17) Apologies for the weird formatting of my comments below. Perhaps it's gmail, that when I cut-and-paste from the document, makes weird boxes, so please ignore the boxes. If gmail is just putting boxes in while I type in my comments, just to annoy me, and they don't appear in the sent email, then ignore the non-boxes I'm complaining about. Anyway, here are my comments: There seems to be a cut-and-paste error here: "The optional insecure transport can only be used restricted set of publically data available (events or information)" Perhaps it should be "The optional insecure transport can only be used when accessing publically available data (events or information)". Not exactly sure what you'd like it to be...but there does seem to be at least a missing word in the text from the document. ----- And as long as I'm noticing extremely minor editorial things during reread: "The first application is a weekly configuration application that uses the I2RS protocol to change configurations. The second application is an application that allows operators to makes emergency changes to routers in the network" In the first sentence I'd probably say "periodic" instead of "weekly". The second sentence should be "to make" instead of "to makes" ----------- Another super-minor typo "A variety of forms of managemen" is missing the letter "t" in "management" Radia --94eb2c1907aa16ed0f053dda08c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Sep 15, 2016 at 6:43 AM, Radia Perlman <radiaperlman@gmai= l.com> wrote:
I have review= ed this document as part of the security directorate's ongoing effort t= o review all IETF documents being processed by the IESG.
These comments were written primarily for the benefi= t of the security area directors.
= Document editors and WG chairs should treat these comments just like any ot= her last call comments.

<= /span>I previously reviewed version 6 and 10= , and all my comments are addressed in this version (17). The secdir assign= ment was for version 14, but the latest version seems to be 17, so that is = the one that I reviewed.

Nothing sub= stantive, certainly no security issues, and it's ready for publication.=

I do = have a few super-minor typos in this version (17) =C2=A0Apologies for the w= eird formatting of my comments below. Perhaps it's gmail, that when I c= ut-and-paste from the document, makes weird boxes, so please ignore the box= es.=C2=A0 If gmail is just putting boxes in while I type in my comments, ju= st to annoy me, and they don't appear in the sent email, then ignore th= e non-boxes I'm complaining about.=C2=A0 Anyway, here are my comments:<= /div>

There = seems to be a cut-and-paste error here:
"The optional insecure transport can only be used=C2=A0restricted s= et of publically data available (events or information)"
<= div class=3D"gmail_quote">
Perhaps it should be "The optional ins= ecure transport can only be used when accessing publically available data (= events or information)". =C2=A0

<= div class=3D"gmail_quote">Not exactly sure what you'd like it to be...but there does seem = to be at least a missing word in the text from the document.

-----
And as long as I&#= 39;m noticing extremely minor editorial things during reread:
<= div class=3D"gmail_quote">
"The first application is a weekly configuration application
   that uses the I2RS protocol to change configurations.  The second
   application is an application that allows operators to makes
   emergency changes to routers in the network"
In the first sentence I'd probably say "periodic" i=
nstead of "weekly".
The second se=
ntence should be "to make" instead of "to makes"
<= pre style=3D"box-sizing:border-box;overflow:auto;font-family:"pt mono&= quot;,monaco,monospace;font-size:14px;padding:10px;margin-top:0px;margin-bo= ttom:10.5px;line-height:1.214;color:rgb(0,0,0);word-break:break-all;word-wr= ap:break-word;background-color:rgb(255,253,245);border:1px solid rgb(204,20= 4,204);border-radius:4px">-----------
Anoth=
er super-minor typo "A variety of forms of managemen"  is missing
the letter "t" in "management"
Radia
--94eb2c1907aa16ed0f053dda08c3-- From nobody Mon Oct 3 08:23:38 2016 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2611F12B388; Mon, 3 Oct 2016 08:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1475508175; bh=LfDqy63Bwjg7QS+/rW+ZmNlnSMGvq48MlQuNIv9dcis=; h=From:Date:To:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=olQmN8kf+MrO4oFk/CQH/f9jZTzL6Z1meif/XWMnTm3yVTPA+xigN5BYfueH6JAn0 Ll9hqHs3zmUpoZ5JFoj3OoVdEauS6igP4Aw7PClm4lGVf9B0R6uiAQUkG2Yuk0R3Kj vqONtCl/a+kV5gun53L0loV3dvtGBcvipdipnpwc= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6129612B387 for ; Mon, 3 Oct 2016 08:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 sDn8nrKAnvjq for ; Mon, 3 Oct 2016 08:22:52 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7398112B330 for ; Mon, 3 Oct 2016 08:22:52 -0700 (PDT) Received: from boc06-4-78-216-15-101.fbx.proxad.net ([78.216.15.101] helo=[192.168.0.19]) by raoul.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1br54s-0006oZ-JD; Mon, 03 Oct 2016 15:22:50 +0000 From: Coralie Mercier Date: Mon, 3 Oct 2016 17:22:47 +0200 To: new-work@ietf.org Message-Id: <3C0583BE-3185-41E9-BA56-ACC6F232A767@w3.org> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Mon, 03 Oct 2016 08:23:38 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Audio Working Group (until 2016-10-31) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 15:22:55 -0000 SGVsbG8sCgpUb2RheSBXM0MgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlcyByZWNl aXZlZCBhIFByb3Bvc2FsIHRvIHJldmlldyBhIGRyYWZ0IGNoYXJ0ZXIgZm9yIHRoZSBBdWRpbyBX b3JraW5nIEdyb3VwOgogICBodHRwczovL3d3dy53My5vcmcvMjAxMS9hdWRpby9jaGFydGVyL2F1 ZGlvLTIwMTYuaHRtbAoKQXMgcGFydCBvZiBlbnN1cmluZyB0aGF0IHRoZSBjb21tdW5pdHkgaXMg YXdhcmUgb2YgcHJvcG9zZWQgd29yayBhdCBXM0MsIHRoaXMgZHJhZnQgY2hhcnRlciBpcyBwdWJs aWMgZHVyaW5nIHRoZSBBZHZpc29yeSBDb21taXR0ZWUgcmV2aWV3IHBlcmlvZC4KClczQyBpbnZp dGVzIHB1YmxpYyBjb21tZW50cyB0aHJvdWdoIDIwMTYtMTAtMzEgb24gdGhlIHByb3Bvc2VkIGNo YXJ0ZXIuIFBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvIDxwdWJsaWMtbmV3LXdvcmtAdzMub3JnPiwg d2hpY2ggaGFzIGEgcHVibGljIGFyY2hpdmU6ICAgICAKICBodHRwOi8vbGlzdHMudzMub3JnL0Fy Y2hpdmVzL1B1YmxpYy9wdWJsaWMtbmV3LXdvcmsvCgpPdGhlciB0aGFuIGNvbW1lbnRzIHNlbnQg aW4gZm9ybWFsIHJlc3BvbnNlcyBieSBXM0MgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0 aXZlcywgVzNDIGNhbm5vdCBndWFyYW50ZWUgYSByZXNwb25zZSB0byBjb21tZW50cy4gSWYgeW91 IHdvcmsgZm9yIGEgVzNDIE1lbWJlciBbMV0sIHBsZWFzZSBjb29yZGluYXRlIHlvdXIgY29tbWVu dHMgd2l0aCB5b3VyIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZS4gRm9yIGV4YW1w bGUsIHlvdSBtYXkgd2lzaCB0byBtYWtlIHB1YmxpYyBjb21tZW50cyB2aWEgdGhpcyBsaXN0IGFu ZCBoYXZlIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlIHJlZmVyIHRvIGl0 IGZyb20gaGlzIG9yIGhlciBmb3JtYWwgcmV2aWV3IGNvbW1lbnRzLgoKSWYgeW91IHNob3VsZCBo YXZlIGFueSBxdWVzdGlvbnMgb3IgbmVlZCBmdXJ0aGVyIGluZm9ybWF0aW9uLCBwbGVhc2UgY29u dGFjdCBDaHJpcyBMaWxsZXkgPGNocmlzQHczLm9yZz4sIFN0YWZmIENvbnRhY3QuCgpUaGFuayB5 b3UsCkNvcmFsaWUgTWVyY2llciwgSGVhZCBvZiBXM0MgTWFya2V0aW5nICYgQ29tbXVuaWNhdGlv bnMKClsxXSBodHRwOi8vd3d3LnczLm9yZy9Db25zb3J0aXVtL01lbWJlci9MaXN0CgrigJQKQ29y YWxpZSBNZXJjaWVyICAtICBXM0MgTWFya2V0aW5nICYgQ29tbXVuaWNhdGlvbnMgLSAgaHR0cDov L3d3dy53My5vcmcKbWFpbHRvOmNvcmFsaWVAdzMub3JnICszMzYgNDMyMiAwMDAxIGh0dHA6Ly93 d3cudzMub3JnL1Blb3BsZS9DTWVyY2llci8KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCm5ldy13b3JrIG1haWxpbmcgbGlzdApuZXctd29ya0BpZXRmLm9y ZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldy13b3JrCg== From nobody Mon Oct 3 08:40:10 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA4931295CD for ; Mon, 3 Oct 2016 08:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 wwRsb3YtwGOS for ; Mon, 3 Oct 2016 08:40:00 -0700 (PDT) Received: from nm28-vm3.bullet.mail.ne1.yahoo.com (nm28-vm3.bullet.mail.ne1.yahoo.com [98.138.91.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB6BB12962F for ; Mon, 3 Oct 2016 08:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1475509168; bh=ex8zIOOYHNCuSsVj0tRLlwVsS/dTFuR+Ei7U0NeSqcc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=KdAkIjpTAs97SjUpWkpD0P7TRTsjeNBX4eifyoX3tZpIioUbQkOWB8d0tci3kxb0VsKEeQqUIHnrv8fqZUKnziejukpZvQRvcGFpfrT/kEEsstQsWzDSu009muDO+mP7NXmZsM3oZRfcJIVlH/3/RSi5dg6ApjBnPUa6bZZTkGlr7yenoX5z2+4eHRfnOBMewMxnZA5VltfVTVrKNsGoZyHjxjhYJys0L7H1wcsRbvJqt/NUSEEKEcWADQxjSpnFwndMaB3Rt+Hvselw9lxCv4vzAUynqsQXUcVRXxbbUnyJ6QKZv+Os0R4v404LqpuX+liEjbXgjZN3ZJfqJoEYkw== Received: from [98.138.100.103] by nm28.bullet.mail.ne1.yahoo.com with NNFMP; 03 Oct 2016 15:39:28 -0000 Received: from [98.138.87.9] by tm102.bullet.mail.ne1.yahoo.com with NNFMP; 03 Oct 2016 15:39:28 -0000 Received: from [127.0.0.1] by omp1009.mail.ne1.yahoo.com with NNFMP; 03 Oct 2016 15:39:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 599896.3440.bm@omp1009.mail.ne1.yahoo.com X-YMail-OSG: dwuzoTUVM1n4Q7hBPJJfiwGWKnRS1xzH128K9OgwA4UJS9NCX4xWTarHdxP7.Kl q_u71X7fv_CCUD_S_icHMVT9r2TJy1TPj.mba9bNdasUlA6MkAQ4HwFf79EkRZli10dHGSd1eq.C kfG_HAMRD0zqN4YJkZ8UDHWtD2j7ZMNi_gHoxGjD.a8Q.GhHu51grbZ8Stmc4oyirq7F3fg_Aa53 YyTHTft6CfXwiyfaFzBbhektxOPWOxvxokDBX_gLLMzoUOV1pjFPl.0bEQj_1jl4iipQY9RTuBqi t3staSr0VlB2xvxC6EmL4GONkfoixsgDc5p8AXfAypc3dLVFxHgRwNxA6Q8bM2OEfZLH6unbBh2m v8aceArTt0UEr2DPHdl_ELqm9s8MAvfOWRbB05_KbklPmNpolRRNgRZyqxC7JbqoiDedJ3rpccCw 1jjCx4QeGMeRvQPafYQmq_flRc8eV.YigNntdYd8jY4ZJPBEPcVX7PXcs8.2J9vS8kzKVQp8vQHR jeCDGzfHhtre6559uXFX4qD91PG8B0Y4miWdI2im3DyMs3DdTM07o_hxAqf0BN2aQEYGH0h6x Received: from jws100266.mail.ne1.yahoo.com by sendmailws162.mail.ne1.yahoo.com; Mon, 03 Oct 2016 15:39:28 +0000; 1475509168.030 Date: Mon, 3 Oct 2016 15:39:07 +0000 (UTC) From: To: Tero Kivinen Message-ID: <1130739157.4563724.1475509147203@mail.yahoo.com> In-Reply-To: <22507.60901.665544.878052@fireball.acr.fi> References: <22495.62038.771947.984586@fireball.acr.fi> <1264225155.363685.1474644268281@mail.yahoo.com> <22507.60901.665544.878052@fireball.acr.fi> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4563723_1094224328.1475509147191" Archived-At: Cc: "iesg@ietf.org" , "draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 15:40:04 -0000 ------=_Part_4563723_1094224328.1475509147191 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, Tero. =C2=A0Again, my comments inline.=C2=A0Nalini Elkins Inside Products, Inc.www.insidethestack.com(831) 659-8360 From: Tero Kivinen To: nalini.elkins@insidethestack.com=20 Cc: "iesg@ietf.org" ; "secdir@ietf.org" ; "= draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" Sent: Wednesday, September 28, 2016 9:20 AM Subject: Re: Secdir review of draft-ietf-ippm-6man-pdm-option-05 =20 nalini.elkins@insidethestack.com writes: > Thanks for your comments.=C2=A0 We have posted a new draft with correctio= ns at:=20 > https://tools.ietf.org/html/draft-ietf-ippm-6man-pdm-option-06 >=20 > Our responses inline. >=C2=A0=20 > Nalini Elkins >=20 > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 >=20 >=20 >=20 > ________________________________ > From: Tero Kivinen > To: iesg@ietf.org; secdir@ietf.org; draft-ietf-ippm-6man-pdm-option.all@t= ools.ietf.org=20 > Sent: Monday, September 19, 2016 7:12 AM > Subject: Secdir review of draft-ietf-ippm-6man-pdm-option-05 >=20 > >I think this document has serious issues. >=20 > >It proposes that the new Destination option MUST be put before the ESP > >so it is sent in clear. This will leak out the traffic information > >from the ESP, allowing easy traffic analysis of encrypted packets, as > >passive attacker can see which encrypted ESP packets belong to which > >5-tuple flow. The PDM option header includes the incrementing sequence > >numbers, so checking those will allow see which packet belongs to > >which flow. >=20 >=20 > It is not clear to me how knowing which ESP packets belong to which > traffic flow helps a passive attacker.=C2=A0 The attacker still does not > know what is in the packet - the contents of the payload.=C2=A0 Indeed, > ESP would normally mask TCP or UDP ports.=C2=A0 With PDM you can tell > that there ARE multiple flows but you don't know if they are TCP, > UDP, ICMP or anything else.=C2=A0 Most importantly, you don't know what > is in the payload. >Sometimes that is only what is needed, and ESP tries to provide >protection against traffic flow confidentiality, and this option >breaks it. >For example finding out that this flow of packets is the control >traffic of the video stream, and this other flow of packets is the >actual video stream, the attacker can for example block the control >traffic, and make it so that user on the other end cannot stop the >video feed. >Or if there is 3 simultaneous video streams going out, it is much >harder to identify which video stream is what TV-program. If you can >separate them to 3 different video streams, it is much easier to >identify the actual video being watched by checking the packet >lengths. >There are most likely also other kind of attacks, and as this is >service as ESP provides, it is not for PDM to break it unless you >explictly spell it out that this is meant to break property of the >ESP.=C2=A0 OK. =C2=A0I am convinced. =C2=A0I will tell you though that some of us in I= PPM, we were quite excited (possibly naively) about being able to get some = performance metrics for ESP. I wonder if it would be acceptable to say that PDM could be put into the De= stination Option which precedes ESP if it is for an enterprise customer who= owns the infrastructure and wishes to manage the network that way. =C2=A0O= therwise, I can change to say that only the Dest Opt following ESP can be u= sed. > If one follows the thinking of your objection, isn't any encrypted > flow over TCP or UDP a problem since a passive attacker knows the > 5-tuple for such flows?=C2=A0 For example, all TLS flows can be analyzed > for traffic in your sense.=C2=A0 So, a flow over TLS (without PDM) > actually leaks more information than an ESP flow WITH PDM.=C2=A0 Because > with TLS, we even know that the flow is TCP and the port number. > Neither of which you know with PDM with ESP. >Yes. And to fix that issue, people use IPsec which will hide the >information about separate TCP and UDP flows. >And now with PDM the IPsec will not provide that service anymore. OK. =C2=A0Pls see above. > >It claims that PDM MUST be placed before the ESP header in order to > >work, which is untrue. This is destination option, thus it is meant to > >be checked on the destination host, i.e., the packet capture after the > >ESP decryption will allow seeing the PDM header values without issues. >You did not respond to this part, i.e., why is the PDM header outside >the ESP encrypted part, and why it is not inside the ESP? >It is supposed to be destination option, which is only meaningful to >the final destination of the packet, thus it can easily be inside the >ESP protection, as the final destination do know the keys etc will see >the decrypted option header. Pls see above. > >The whole section 4 seems to be wierd. It is talking about different > >encodings, and time units on different systems, and it also talks > >about the limitations on TCP Timestamp Option, but this option uses > >different encoding so I have no idea why this text is here. It would > >be more useful to count what are the limits on the encoding method > >used here (16 bit value, 7 bit signed scaling value), instead of what >=20 > >some other option use. >=20 > Thanks.=C2=A0 Should now be fixed. >What is the meaning of the section 4? >It is good background information, and might be moved to the appendix, >but I do not think it belongs here. It has text that mostly covers >other formats, not the format used here. Also it does not really >specify what does negative scaling values mean, and when are they >used. Let me review this again with one of my co-authors. >If I understand correctly the actual timevalue conversion is so that > =C2=A0 delta_time =3D delta_time_from_packet * 2^Scale >where delta_time_from_packet is between 0x0000 and 0xffff, and scale >is between -127 and 128, and the units are either milliseconds, >microseconds, nanoseconds or picoseconds. >So the smallist time we can express with this is >delta_time_from_packet =3D 0x0001 >scale =3D -127 >unit =3D 11 =3D picoseconds > =C2=A0 delta_time =3D 0.0000000000000000000000000000000000000058 picoseco= nds > =C2=A0 =3D .0000000000000000000000000058 joktoseconds =3D=3D 5.8 * 10^-51= seconds =C2=A0=20 >and the maximum value is >delta_time_from_packet =3D 0xffff >scale =3D 128 >unit =3D 00 =3D milliseconds > =C2=A0 delta_time =3D 22300404916163702203072254898040929737768960 millis= econds > =C2=A0 =3D 707141201045272139874183628172277 years... >so the range is definately enough. The question is that if the scale >is from -127 to 128, why do we even need the Time Base? The time base is so that one does not have to be committed to picoseconds /= milliseconds, etc. =C2=A0 =C2=A0Even in your example, I believe you used "= unit" or time base. =C2=A0Our thinking was that we wanted future proof so a= s to be able to handle very small values and very large (as may be needed f= or DTN, for example). =C2=A0 We can see if we can express years in picoseco= nds and see what happens. =C2=A0 Then, the unit would always be picoseconds= . > >The section 8 is wrong as it claims >=20 > >=C2=A0 =C2=A0 "PDM does not introduce any new security weakness." >=20 > >while this will leak lots of information about the traffic flows > >inside the encrypted transport mode ESP packets. >=20 > Please see above. >Leaking this information is new security weakness for the protocol, >which was designed to protect against those attacks.=C2=A0 OK. > >Also another thing the PDM leaks is exact host timings, i.e., it can > >be used to launch timing attacks against crypto protocols. In general > >those are hard as it is very hard to know how much of n ms rtt is > >network delay and how much was the actual host processing the packet. > >Now if we can see that that host used 123 nanoseconds to process the > >signature verification packet, and next time it uses 1755 nanoseconds, > >this might allow attacker to get information out from the key. The > >actual round trip times might have been 123 ms in both cases, and the > >1 microsecond difference in the processing time would have been lost > >by the network latencies. >=20 >=20 >=20 > 1. The intent of PDM is as a diagnostic feature.=C2=A0 PDM is OFF > initially at the end hosts (client and server).=C2=A0 It is turned ON for > diagnostics and then turned OFF afterwards.=C2=A0 If someone chooses to > leave PDM ON always, then that is explicitly chosen.=C2=A0 Also, PDM is > an OPTIONAL feature.=C2=A0 Either client or server operating system may > choose not to implement it or use it. >The draft disagrees with this. It says there is configuration option >for it, but does not give default value for it, and says: >3.5 Implementation Considerations > =C2=A0 The PDM destination options extension header SHOULD be turned on b= y > =C2=A0 each stack on a host node. It MAY also be turned on only in case o= f > =C2=A0 diagnostics needed for problem resolution. > so it seems it is on by default.=C2=A0 Will change to say that it MUST be turned on only by the stack and default = value should be OFF. "The PDM destination options extension header MUST be turned on only by adm= inistrative action at =C2=A0 each stack on a host node. =C2=A0The default mode for PDM is OFF." > 2. In your example above, it assumes that the signature verification > packet (please let me know which exact packet and protocol you are > referring to) is passing in the clear so that the attacker knows > that it is the signature verification packet.=C2=A0 Possibly this is also > a problem. >Key management packets are usually in clear, as they are there before >we have the actual keys we can use to protect the messages. Also it is >not very difficult to guess that 3rd and 4th message in port 500, are >the IKE AUTH packets, which will contain signatures. >Same thing with TLS. >Attackers will knows which packets contain signatures. Currently >attackers usually send those signature packets themselves, and measure >the time it takes for the device to calculate response. They can also >send garbage packets, and detect how far in checking the packets got >by checking how long it took for the other end to send error message >back. >All this kind of timing attacks are usually considered hard, as the >network delays cause big jitter on the timings, and they need to try >multiple times, and average the response times to get the information >they need. >This method will provide them easy way to bypass that issue.=C2=A0 OK. =C2=A0So, are you saying that PDM is attack vector for TLS and not just= for ESP? > 3.=C2=A0 Protocols often use blinding techniques to remove correlations > between key and encryption time.=C2=A0 Other cryptographic algorithms > can be implemented (or masked by a proxy) in a way that reduces or > eliminates data dependent timing information.=C2=A0 So if timing > information is being leaked, this is a flaw in the algorithm or the > protocol.=C2=A0 In this case, we may be "blaming the messenger".=C2=A0 PD= M is > only reporting what is done.=C2=A0 The algorithm or protocol is the > problem. >Yes. This option makes it easy for the attacker to use those broken >algorithms, protocols and implementations. >This is again new security weakness that this option opens. It was >harder before, after this it is easier.=C2=A0 OK. > >In addition to that the abstract is not very clear, it does not do > >very good job of telling that this draft tries to do, and having the > >Background section to duplicate most of that text does not still what >=20 > >this document really tries to do.=20 >=20 > If you can give me a hint as to what is not clear or what you think > this draft DOES propose, then we will be happy to rewrite the > abstract / background section.=20 >My current take is that this option proposes and attack vector against >several different protocols, and as such it does quite good job... Maybe I have missed my calling. =C2=A0 I should be designer of attack vecto= rs! =C2=A0 (Just kidding. =C2=A0HAHAHA. =C2=A0Meant only as a =C2=A0joke!) = =C2=A0 >I have a feeling that this is not for which this draft was meant to do.=C2= =A0 No, obviously not. =C2=A0 So, now I am not sure where we are. =C2=A0 Is the= re a complete objection to this draft or are there changes which can be mad= e which would make this acceptable? --=20 kivinen@iki.fi =20 ------=_Part_4563723_1094224328.1475509147191 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, Tero.  Again, my comments inline.
 
Nalini Elkins
Insid= e Products, Inc.
www.= insidethestack.com
(831) 659-8360


From: Tero Kivinen <kivinen@iki.fi>
<= span style=3D"font-weight: bold;">To: nalini.elkins@insidethesta= ck.com
Cc: "iesg@ietf.= org" <iesg@ietf.org>; "secdir@ietf.org" <secdir@ietf.org>; "dra= ft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" <draft-ietf-ippm-6man-p= dm-option.all@tools.ietf.org>
= Sent: Wednesday, September 28, 2016 9:20 AM
Subject: Re: Secdir review of draft-ietf= -ippm-6man-pdm-option-05

nalini.elkins@insidethestack.com writes:
> Thanks for your comments.  We have posted a new draft with= corrections at:
> h= ttps://tools.ietf.org/html/draft-ietf-ippm-6man-pdm-option-06
>
> Our responses inline.
> 
> Nalini Elkins
>=
> Inside Products, Inc.
> www.i= nsidethestack.com
> (831) 659-8360
&= gt;
>
>
>= ________________________________
> From: Tero Kivinen= <kivinen@iki.fi>
> To: iesg@i= etf.org; secdir@ietf.org; draft-ietf-ippm-6man-pdm-o= ption.all@tools.ietf.org
> Sent: Monday, Septembe= r 19, 2016 7:12 AM
> Subject: Secdir review of draft-i= etf-ippm-6man-pdm-option-05
>
> = >I think this document has serious issues.
>
> >It proposes that the new Destination option MUST be p= ut before the ESP
> >so it is sent in clear. This w= ill leak out the traffic information
> >from the ES= P, allowing easy traffic analysis of encrypted packets, as
> >passive attacker can see which encrypted ESP packets belong to w= hich
> >5-tuple flow. The PDM option header include= s the incrementing sequence
> >numbers, so checking= those will allow see which packet belongs to
> >wh= ich flow.
>
>
> It is not clear to me how knowing which ESP packets belong to which> traffic flow helps a passive attacker.  The att= acker still does not
> know what is in the packet - th= e contents of the payload.  Indeed,
> ESP would n= ormally mask TCP or UDP ports.  With PDM you can tell
> that there ARE multiple flows but you don't know if they are TCP,> UDP, ICMP or anything else.  Most importantly, yo= u don't know what
> is in the payload.

>Sometimes that is only what is needed, and ESP tr= ies to provide
>protection against traffic flow confid= entiality, and this option
>breaks it.

>For example finding out that this flow of packets= is the control
>traffic of the video stream, and this= other flow of packets is the
>actual video stream, th= e attacker can for example block the control
>traffic,= and make it so that user on the other end cannot stop the
>video feed.

>Or if there is 3= simultaneous video streams going out, it is much
>har= der to identify which video stream is what TV-program. If you can
>separate them to 3 different video streams, it is much easier= to
>identify the actual video being watched by checki= ng the packet
>lengths.

>There are most likely also other kind of attacks, and as this is=
>service as ESP provides, it is not for PDM to break = it unless you
>explictly spell it out that this is mea= nt to break property of the
>ESP. 


OK.  I am convinced.  I will tell you though that some= of us in IPPM, we were quite excited (possibly naively) about being able t= o get some performance metrics for ESP.

I wonder= if it would be acceptable to say that PDM could be put into the Destinatio= n Option which precedes ESP if it is for an enterprise customer who owns th= e infrastructure and wishes to manage the network that way.  Otherwise= , I can change to say that only the Dest Opt following ESP can be used.


> If one follows the thinking of= your objection, isn't any encrypted
> flow over TCP o= r UDP a problem since a passive attacker knows the
> 5= -tuple for such flows?  For example, all TLS flows can be analyzed
> for traffic in your sense.  So, a flow over TLS (w= ithout PDM)
> actually leaks more information than an = ESP flow WITH PDM.  Because
> with TLS, we even k= now that the flow is TCP and the port number.
> Neithe= r of which you know with PDM with ESP.

>Yes. And to fix that issue, people use IPsec which will hide the
>information about separate TCP and UDP flows.

>And now with PDM the IPsec will not provide th= at service anymore.

OK.  Pls see above.


> >It claims that PDM MUST be placed bef= ore the ESP header in order to
> >work, which is un= true. This is destination option, thus it is meant to
>= ; >be checked on the destination host, i.e., the packet capture after th= e
> >ESP decryption will allow seeing the PDM heade= r values without issues.

>You did n= ot respond to this part, i.e., why is the PDM header outside
>the ESP encrypted part, and why it is not inside the ESP?

>It is supposed to be destination option, w= hich is only meaningful to
>the final destination of t= he packet, thus it can easily be inside the
>ESP prote= ction, as the final destination do know the keys etc will see
>the decrypted option header.

Pls see above.

> >The whole section 4 seems to b= e wierd. It is talking about different
> >encodings= , and time units on different systems, and it also talks
= > >about the limitations on TCP Timestamp Option, but this option use= s
> >different encoding so I have no idea why this = text is here. It would
> >be more useful to count w= hat are the limits on the encoding method
> >used h= ere (16 bit value, 7 bit signed scaling value), instead of what
>
> >some other option use.
>
> Thanks.  Should now be fixed.

>What is the meaning of the section 4?
>It is good background information, = and might be moved to the appendix,
>but I do not thin= k it belongs here. It has text that mostly covers
>oth= er formats, not the format used here. Also it does not really
>specify what does negative scaling values mean, and when are they<= br clear=3D"none">>used.

Let me review this again with on= e of my co-authors.

>If I understan= d correctly the actual timevalue conversion is so that
>   delta_time =3D delta_time_from_packet * 2^Scal= e

>where delta_time_from_packet is = between 0x0000 and 0xffff, and scale
>is between -127 = and 128, and the units are either milliseconds,
>micro= seconds, nanoseconds or picoseconds.

&= gt;So the smallist time we can express with this is

>delta_time_from_packet =3D 0x0001
>s= cale =3D -127
>unit =3D 11 =3D picoseconds

>   delta_time =3D 0.00000000000000000000= 00000000000000000058 picoseconds
>   =3D .0000000= 000000000000000000058 joktoseconds =3D=3D 5.8 * 10^-51 seconds
 
>and the maximum value is

>delta_time_from_packet =3D 0xffff
>scale =3D 128
>unit =3D 00 =3D milliseconds
>   delta_time =3D 223004049161= 63702203072254898040929737768960 milliseconds
>  = =3D 707141201045272139874183628172277 years...

>so the range is definately enough. The question is that if th= e scale
>is from -127 to 128, why do we even need the = Time Base?


The time base is so that on= e does not have to be committed to picoseconds / milliseconds, etc.   =  Even in your example, I believe you used "unit" or time base.  O= ur thinking was that we wanted future proof so as to be able to handle very= small values and very large (as may be needed for DTN, for example).  = ; We can see if we can express years in picoseconds and see what happens. &= nbsp; Then, the unit would always be picoseconds.

<= br clear=3D"none">> >The section 8 is wrong as it claims
>
> >    "PDM does not introduc= e any new security weakness."
>
>= ; >while this will leak lots of information about the traffic flows
> >inside the encrypted transport mode ESP packets.
>
> Please see above.

>Leaking this information is new security weakne= ss for the protocol,
>which was designed to protect ag= ainst those attacks. 

OK.

> >Also another thing the PDM leaks is exact host timings, = i.e., it can
> >be used to launch timing attacks ag= ainst crypto protocols. In general
> >those are har= d as it is very hard to know how much of n ms rtt is
>= >network delay and how much was the actual host processing the packet.<= br clear=3D"none">> >Now if we can see that that host used 123 nanose= conds to process the
> >signature verification pack= et, and next time it uses 1755 nanoseconds,
> >this= might allow attacker to get information out from the key. The
> >actual round trip times might have been 123 ms in both cases= , and the
> >1 microsecond difference in the proces= sing time would have been lost
> >by the network la= tencies.
>
>
= >
> 1. The intent of PDM is as a diagnostic featur= e.  PDM is OFF
> initially at the end hosts (clie= nt and server).  It is turned ON for
> diagnostic= s and then turned OFF afterwards.  If someone chooses to
> leave PDM ON always, then that is explicitly chosen.  Also, = PDM is
> an OPTIONAL feature.  Either client or s= erver operating system may
> choose not to implement i= t or use it.

>The draft disagrees w= ith this. It says there is configuration option
>for i= t, but does not give default value for it, and says:


>3.5 Implementation Considerations

>   The PDM destination options e= xtension header SHOULD be turned on by
>   each s= tack on a host node. It MAY also be turned on only in case of
>   diagnostics needed for problem resolution.

> so i= t seems it is on by default. 


Will change t= o say that it MUST be turned on only by the stack and default value should = be OFF.

"The PDM destination options ex= tension header MUST be turned on only by administrative action at
  each stack on = a host node.  The default mode for PDM is OFF."

<= br clear=3D"none">> 2. In your example above, it assumes that the signat= ure verification
> packet (please let me know which ex= act packet and protocol you are
> referring to) is pas= sing in the clear so that the attacker knows
> that it= is the signature verification packet.  Possibly this is also
> a problem.

>Key mana= gement packets are usually in clear, as they are there before
>we have the actual keys we can use to protect the messages. Also i= t is
>not very difficult to guess that 3rd and 4th mes= sage in port 500, are
>the IKE AUTH packets, which wil= l contain signatures.

>Same thing w= ith TLS.

>Attackers will knows whic= h packets contain signatures. Currently
>attackers usu= ally send those signature packets themselves, and measure
>the time it takes for the device to calculate response. They can also<= br clear=3D"none">>send garbage packets, and detect how far in checking = the packets got
>by checking how long it took for the = other end to send error message
>back.

>All this kind of timing attacks are usually consi= dered hard, as the
>network delays cause big jitter on= the timings, and they need to try
>multiple times, an= d average the response times to get the information
>t= hey need.

>This method will provide them easy way = to bypass that issue. 

OK. &nbs= p;So, are you saying that PDM is attack vector for TLS and not just for ESP= ?

> 3.  Protocols often use bli= nding techniques to remove correlations
> between key = and encryption time.  Other cryptographic algorithms
> can be implemented (or masked by a proxy) in a way that reduces or> eliminates data dependent timing information.  = So if timing
> information is being leaked, this is a = flaw in the algorithm or the
> protocol.  In thi= s case, we may be "blaming the messenger".  PDM is
&= gt; only reporting what is done.  The algorithm or protocol is the
> problem.

>Yes. = This option makes it easy for the attacker to use those broken
>algorithms, protocols and implementations.

>This is again new security weakness that this option ope= ns. It was
>harder before, after this it is easier.&nb= sp;

OK.


> >In addition to that the abstract is n= ot very clear, it does not do
> >very good job of t= elling that this draft tries to do, and having the
> &= gt;Background section to duplicate most of that text does not still what>
> >this document really tries= to do.
>
> If you can give me = a hint as to what is not clear or what you think
> thi= s draft DOES propose, then we will be happy to rewrite the
> abstract / background section.

>My current take is that this option proposes and attack vector against=
>several different protocols, and as such it does qui= te good job...

Maybe I have missed m= y calling.   I should be designer of attack vectors!   (Just kidd= ing.  HAHAHA.  Meant only as a  joke!)  


>I have a feeling that this is = not for which this draft was meant to do. 

=
No, obviously not.   So, now I am not sure where we are. &= nbsp; Is there a complete objection to this draft or are there changes whic= h can be made which would make this acceptable?

= =
------=_Part_4563723_1094224328.1475509147191-- From nobody Mon Oct 3 08:48:57 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAC91293D8 for ; Mon, 3 Oct 2016 08:48:53 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 1FIoK0fwIGMi for ; Mon, 3 Oct 2016 08:48:50 -0700 (PDT) Received: from nm32-vm7.bullet.mail.ne1.yahoo.com (nm32-vm7.bullet.mail.ne1.yahoo.com [98.138.229.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70D461293D6 for ; Mon, 3 Oct 2016 08:48:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1475509729; bh=HSUbcFKmjxlK4ZXGaCNOK+uvn+6762uN7sl5xp1wygU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=m8zUIEj8cqKW+JMNcbL2ey0EntbHhFXIqe9mXyT6Vm7T0DziL5BhELhxn0ipOkygq7AN8D5gL0pOtgSdDKq7mImDnGo2anLsrnMlze9tbDO2W21RK0WCTzMdZCfauhEbhS38lbZhSGxZ+jkQcG3Fb+az/tEIDEyAbToKWmlm5cWUMPpJsokvWZ7jw0lqWe6YbBAA7c7dBrVAeg8vfnZ9WVFTBJoHGOKAoMno3I/CHmXO08MnxbZwCVVPjiwt9EE0OhS7kn9dp1rYKXsXOB/RrWWxDhSKWQEYMH9bu1o6kxDLYf6AeKTha+WGxUYYHdEDO8rmXGa9Yz6tzyAmtchOxQ== Received: from [127.0.0.1] by nm32.bullet.mail.ne1.yahoo.com with NNFMP; 03 Oct 2016 15:48:49 -0000 Received: from [98.138.100.112] by nm32.bullet.mail.ne1.yahoo.com with NNFMP; 03 Oct 2016 15:45:50 -0000 Received: from [98.138.87.11] by tm103.bullet.mail.ne1.yahoo.com with NNFMP; 03 Oct 2016 15:44:50 -0000 Received: from [127.0.0.1] by omp1011.mail.ne1.yahoo.com with NNFMP; 03 Oct 2016 15:44:50 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 198354.92671.bm@omp1011.mail.ne1.yahoo.com X-YMail-OSG: eK82bHYVRDtgfAoCqOIpFuQf7CXNzbPmvwqKAF0E6WpCYH8GW8U- Received: from jws100250.mail.ne1.yahoo.com by sendmailws129.mail.ne1.yahoo.com; Mon, 03 Oct 2016 15:44:49 +0000; 1475509489.790 Date: Mon, 3 Oct 2016 15:44:39 +0000 (UTC) From: To: Tero Kivinen Message-ID: <1255977376.4422369.1475509479701@mail.yahoo.com> In-Reply-To: <1130739157.4563724.1475509147203@mail.yahoo.com> References: <22495.62038.771947.984586@fireball.acr.fi> <1264225155.363685.1474644268281@mail.yahoo.com> <22507.60901.665544.878052@fireball.acr.fi> <1130739157.4563724.1475509147203@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "iesg@ietf.org" , "draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 15:48:53 -0000 I am resending this as the last post somehow got cut off in the middle. Thanks, Nalini Elkins Inside Products, Inc. www.insidethestack.com (831) 659-8360 ________________________________ From: "nalini.elkins@insidethestack.com" To: Tero Kivinen Cc: "iesg@ietf.org" ; "secdir@ietf.org" ; "draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" Sent: Monday, October 3, 2016 8:39 AM Subject: Re: Secdir review of draft-ietf-ippm-6man-pdm-option-05 Thanks, Tero. Again, my comments inline. Nalini Elkins Inside Products, Inc. www.insidethestack.com (831) 659-8360 ________________________________ From: Tero Kivinen To: nalini.elkins@insidethestack.com Cc: "iesg@ietf.org" ; "secdir@ietf.org" ; "draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" Sent: Wednesday, September 28, 2016 9:20 AM Subject: Re: Secdir review of draft-ietf-ippm-6man-pdm-option-05 nalini.elkins@insidethestack.com writes: > Thanks for your comments. We have posted a new draft with corrections at: > https://tools.ietf.org/html/draft-ietf-ippm-6man-pdm-option-06 > > Our responses inline. > > Nalini Elkins > > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > > > ________________________________ > From: Tero Kivinen > To: iesg@ietf.org; secdir@ietf.org; draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org > Sent: Monday, September 19, 2016 7:12 AM > Subject: Secdir review of draft-ietf-ippm-6man-pdm-option-05 > > >I think this document has serious issues. > > >It proposes that the new Destination option MUST be put before the ESP > >so it is sent in clear. This will leak out the traffic information > >from the ESP, allowing easy traffic analysis of encrypted packets, as > >passive attacker can see which encrypted ESP packets belong to which > >5-tuple flow. The PDM option header includes the incrementing sequence > >numbers, so checking those will allow see which packet belongs to > >which flow. > > > It is not clear to me how knowing which ESP packets belong to which > traffic flow helps a passive attacker. The attacker still does not > know what is in the packet - the contents of the payload. Indeed, > ESP would normally mask TCP or UDP ports. With PDM you can tell > that there ARE multiple flows but you don't know if they are TCP, > UDP, ICMP or anything else. Most importantly, you don't know what > is in the payload. >Sometimes that is only what is needed, and ESP tries to provide >protection against traffic flow confidentiality, and this option >breaks it. >For example finding out that this flow of packets is the control >traffic of the video stream, and this other flow of packets is the >actual video stream, the attacker can for example block the control >traffic, and make it so that user on the other end cannot stop the >video feed. >Or if there is 3 simultaneous video streams going out, it is much >harder to identify which video stream is what TV-program. If you can >separate them to 3 different video streams, it is much easier to >identify the actual video being watched by checking the packet >lengths. >There are most likely also other kind of attacks, and as this is >service as ESP provides, it is not for PDM to break it unless you >explictly spell it out that this is meant to break property of the >ESP. OK. I am convinced. I will tell you though that some of us in IPPM, we were quite excited (possibly naively) about being able to get some performance metrics for ESP. I wonder if it would be acceptable to say that PDM could be put into the Destination Option which precedes ESP if it is for an enterprise customer who owns the infrastructure and wishes to manage the network that way. Otherwise, I can change to say that only the Dest Opt following ESP can be used. > If one follows the thinking of your objection, isn't any encrypted > flow over TCP or UDP a problem since a passive attacker knows the > 5-tuple for such flows? For example, all TLS flows can be analyzed > for traffic in your sense. So, a flow over TLS (without PDM) > actually leaks more information than an ESP flow WITH PDM. Because > with TLS, we even know that the flow is TCP and the port number. > Neither of which you know with PDM with ESP. >Yes. And to fix that issue, people use IPsec which will hide the >information about separate TCP and UDP flows. >And now with PDM the IPsec will not provide that service anymore. OK. Pls see above. > >It claims that PDM MUST be placed before the ESP header in order to > >work, which is untrue. This is destination option, thus it is meant to > >be checked on the destination host, i.e., the packet capture after the > >ESP decryption will allow seeing the PDM header values without issues. >You did not respond to this part, i.e., why is the PDM header outside >the ESP encrypted part, and why it is not inside the ESP? >It is supposed to be destination option, which is only meaningful to >the final destination of the packet, thus it can easily be inside the >ESP protection, as the final destination do know the keys etc will see >the decrypted option header. Pls see above. > >The whole section 4 seems to be wierd. It is talking about different > >encodings, and time units on different systems, and it also talks > >about the limitations on TCP Timestamp Option, but this option uses > >different encoding so I have no idea why this text is here. It would > >be more useful to count what are the limits on the encoding method > >used here (16 bit value, 7 bit signed scaling value), instead of what > > >some other option use. > > Thanks. Should now be fixed. >What is the meaning of the section 4? >It is good background information, and might be moved to the appendix, >but I do not think it belongs here. It has text that mostly covers >other formats, not the format used here. Also it does not really >specify what does negative scaling values mean, and when are they >used. Let me review this again with one of my co-authors. >If I understand correctly the actual timevalue conversion is so that > delta_time = delta_time_from_packet * 2^Scale >where delta_time_from_packet is between 0x0000 and 0xffff, and scale >is between -127 and 128, and the units are either milliseconds, >microseconds, nanoseconds or picoseconds. >So the smallist time we can express with this is >delta_time_from_packet = 0x0001 >scale = -127 >unit = 11 = picoseconds > delta_time = 0.0000000000000000000000000000000000000058 picoseconds > = .0000000000000000000000000058 joktoseconds == 5.8 * 10^-51 seconds >and the maximum value is >delta_time_from_packet = 0xffff >scale = 128 >unit = 00 = milliseconds > delta_time = 22300404916163702203072254898040929737768960 milliseconds > = 707141201045272139874183628172277 years... >so the range is definately enough. The question is that if the scale >is from -127 to 128, why do we even need the Time Base? The time base is so that one does not have to be committed to picoseconds / milliseconds, etc. Even in your example, I believe you used "unit" or time base. Our thinking was that we wanted future proof so as to be able to handle very small values and very large (as may be needed for DTN, for example). We can see if we can express years in picoseconds and see what happens. Then, the unit would always be picoseconds. > >The section 8 is wrong as it claims > > > "PDM does not introduce any new security weakness." > > >while this will leak lots of information about the traffic flows > >inside the encrypted transport mode ESP packets. > > Please see above. >Leaking this information is new security weakness for the protocol, >which was designed to protect against those attacks. OK. > >Also another thing the PDM leaks is exact host timings, i.e., it can > >be used to launch timing attacks against crypto protocols. In general > >those are hard as it is very hard to know how much of n ms rtt is > >network delay and how much was the actual host processing the packet. > >Now if we can see that that host used 123 nanoseconds to process the > >signature verification packet, and next time it uses 1755 nanoseconds, > >this might allow attacker to get information out from the key. The > >actual round trip times might have been 123 ms in both cases, and the > >1 microsecond difference in the processing time would have been lost > >by the network latencies. > > > > 1. The intent of PDM is as a diagnostic feature. PDM is OFF > initially at the end hosts (client and server). It is turned ON for > diagnostics and then turned OFF afterwards. If someone chooses to > leave PDM ON always, then that is explicitly chosen. Also, PDM is > an OPTIONAL feature. Either client or server operating system may > choose not to implement it or use it. >The draft disagrees with this. It says there is configuration option >for it, but does not give default value for it, and says: >3.5 Implementation Considerations > The PDM destination options extension header SHOULD be turned on by > each stack on a host node. It MAY also be turned on only in case of > diagnostics needed for problem resolution. > so it seems it is on by default. Will change to say that it MUST be turned on only by the stack and default value should be OFF. "The PDM destination options extension header MUST be turned on only by administrative action at each stack on a host node. The default mode for PDM is OFF." > 2. In your example above, it assumes that the signature verification > packet (please let me know which exact packet and protocol you are > referring to) is passing in the clear so that the attacker knows > that it is the signature verification packet. Possibly this is also > a problem. >Key management packets are usually in clear, as they are there before >we have the actual keys we can use to protect the messages. Also it is >not very difficult to guess that 3rd and 4th message in port 500, are >the IKE AUTH packets, which will contain signatures. >Same thing with TLS. >Attackers will knows which packets contain signatures. Currently >attackers usually send those signature packets themselves, and measure >the time it takes for the device to calculate response. They can also >send garbage packets, and detect how far in checking the packets got >by checking how long it took for the other end to send error message >back. >All this kind of timing attacks are usually considered hard, as the >network delays cause big jitter on the timings, and they need to try >multiple times, and average the response times to get the information >they need. >This method will provide them easy way to bypass that issue. OK. So, are you saying that PDM is attack vector for TLS and not just for ESP? > 3. Protocols often use blinding techniques to remove correlations > between key and encryption time. Other cryptographic algorithms > can be implemented (or masked by a proxy) in a way that reduces or > eliminates data dependent timing information. So if timing > information is being leaked, this is a flaw in the algorithm or the > protocol. In this case, we may be "blaming the messenger". PDM is > only reporting what is done. The algorithm or protocol is the > problem. >Yes. This option makes it easy for the attacker to use those broken >algorithms, protocols and implementations. >This is again new security weakness that this option opens. It was >harder before, after this it is easier. OK. > >In addition to that the abstract is not very clear, it does not do > >very good job of telling that this draft tries to do, and having the > >Background section to duplicate most of that text does not still what > > >this document really tries to do. > > If you can give me a hint as to what is not clear or what you think > this draft DOES propose, then we will be happy to rewrite the > abstract / background section. >My current take is that this option proposes and attack vector against >several different protocols, and as such it does quite good job... Maybe I have missed my calling. I should be designer of attack vectors! (Just kidding. HAHAHA. Meant only as a joke!) >I have a feeling that this is not for which this draft was meant to do. No, obviously not. So, now I am not sure where we are. Is there a complete objection to this draft or are there changes which can be made which would make this acceptable? -- kivinen@iki.fi From nobody Mon Oct 3 09:16:19 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355481293E0 for ; Mon, 3 Oct 2016 09:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 auGF06tsAq65 for ; Mon, 3 Oct 2016 09:16:10 -0700 (PDT) Received: from nm30-vm1.bullet.mail.ne1.yahoo.com (nm30-vm1.bullet.mail.ne1.yahoo.com [98.138.90.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A43721293F0 for ; Mon, 3 Oct 2016 09:16:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1475511369; bh=CHkeyCUmqjXCI2vblXleQ6JwtQojLSA/ErECOIBkytU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=bOQK03VJ0SGVve+w7m2ZzA9hTOmWLLeDQ3dOtzpzgtT/ENtVA51f61krvjNTvLeJSGtziQa6CXs90COwHzc1fTV3xrvQ6IZS4XNYH1DXuiiEJIi6sRbbaTrCHsnN/3bI+dcXew0qE/YNAQ9Qxsq8jWuA2deIcjQbu13wLCDkVeDK9XgGtP3b+/vTlSe8X3VrEtU6axMqmnPzpD4dzpMF0MqydFypxmC88i731bYF1ofMMqKhnuGKQZCF8SbYOdcFYNcoGZ1xp8DgkwANVWgEFbVsiLB+BlhOEdeCxXK7YYdnSH/lM7Cj5aexT34ZuQk92GxLCkPGYLXyeNPl7Hq2YQ== Received: from [98.138.100.111] by nm30.bullet.mail.ne1.yahoo.com with NNFMP; 03 Oct 2016 16:16:09 -0000 Received: from [98.138.226.163] by tm100.bullet.mail.ne1.yahoo.com with NNFMP; 03 Oct 2016 16:16:09 -0000 Received: from [127.0.0.1] by omp1064.mail.ne1.yahoo.com with NNFMP; 03 Oct 2016 16:16:09 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 845767.16572.bm@omp1064.mail.ne1.yahoo.com X-YMail-OSG: 73z0RPkVM1mguoe882bYGX3tXKVV28qT74tni9t9aNL7jFzDIWaz795xisslDJk WNQk.WolQrAWkXXE.kdFnb0WKyGsCAo6V9Rr.dS._.eSI_giiXmodyvTgvPJ0F5DwtaGfC_fk1dx iD9j03Ly0uxJRT8NMfIMi9dMX9yq5iVerT.uwJsrzeBZxvMPp14nocrJhdvA9kWbfx7_hHd1QAzh pLos3ZlG8p_._UAl2EeVIEvgdEh4blz5jTgfbzc7yFViXNh7lqJzq82OnvhW3IZtjYWKh8yIgEiQ 7yADE7i6QOpZBZx82XGTKSqHxJPaszOaH8sH5Lrq_dt62VYSu9IvWXkDzeYHoZHSeHEbbyuoZNyb ilwFYh3TtJKwn7FOJaGhj1Ksgk6UmEEeQRZpyJVKT.Zbn1oigFN.Z6BD1cGdUHwgzZ0ASlcskN0h KKukGs5vg5KVRPIwJDIgIPtoWCV9i32rPnjL_avisvxNUErSnU5Ww.X4vFRLwq0tk9mlJOocmZL. vbt.Zz4GIeX_GyA2IU.lB7bA8_aE1Br8Av6lq5A8kyf1XZ4crFKWWONKbeIB.jpmQChKs48hZ Received: from jws100116.mail.ne1.yahoo.com by sendmailws114.mail.ne1.yahoo.com; Mon, 03 Oct 2016 16:16:08 +0000; 1475511368.422 Date: Mon, 3 Oct 2016 16:16:05 +0000 (UTC) From: To: Tero Kivinen Message-ID: <1186393885.4521187.1475511365569@mail.yahoo.com> In-Reply-To: <1255977376.4422369.1475509479701@mail.yahoo.com> References: <22495.62038.771947.984586@fireball.acr.fi> <1264225155.363685.1474644268281@mail.yahoo.com> <22507.60901.665544.878052@fireball.acr.fi> <1130739157.4563724.1475509147203@mail.yahoo.com> <1255977376.4422369.1475509479701@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4521186_1930130313.1475511365558" Archived-At: Cc: "iesg@ietf.org" , "draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 16:16:14 -0000 ------=_Part_4521186_1930130313.1475511365558 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am resending this as the last post somehow got cut off in the middle. =20 Thanks, Nalini Elkins Inside Products, Inc. www.insidethestack.com (831) 659-8360 ________________________________ From: "nalini.elkins@insidethestack.com" To: Tero Kivinen =20 Cc: "iesg@ietf.org" ; "secdir@ietf.org" ; "= draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" Sent: Monday, October 3, 2016 8:39 AM Subject: Re: Secdir review of draft-ietf-ippm-6man-pdm-option-05 Thanks, Tero.=C2=A0 Again, my comments inline. =20 Nalini Elkins Inside Products, Inc. www.insidethestack.com (831) 659-8360 ________________________________ From: Tero Kivinen To: nalini.elkins@insidethestack.com=20 Cc: "iesg@ietf.org" ; "secdir@ietf.org" ; "= draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" Sent: Wednesday, September 28, 2016 9:20 AM Subject: Re: Secdir review of draft-ietf-ippm-6man-pdm-option-05 nalini.elkins@insidethestack.com writes: > Thanks for your comments.=C2=A0 We have posted a new draft with correctio= ns at:=20 > https://tools.ietf.org/html/draft-ietf-ippm-6man-pdm-option-06 >=20 > Our responses inline. >=C2=A0=20 > Nalini Elkins >=20 > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 >=20 >=20 >=20 > ________________________________ > From: Tero Kivinen > To: iesg@ietf.org; secdir@ietf.org; draft-ietf-ippm-6man-pdm-option.all@t= ools.ietf.org=20 > Sent: Monday, September 19, 2016 7:12 AM > Subject: Secdir review of draft-ietf-ippm-6man-pdm-option-05 >=20 > >I think this document has serious issues. >=20 > >It proposes that the new Destination option MUST be put before the ESP > >so it is sent in clear. This will leak out the traffic information > >from the ESP, allowing easy traffic analysis of encrypted packets, as > >passive attacker can see which encrypted ESP packets belong to which > >5-tuple flow. The PDM option header includes the incrementing sequence > >numbers, so checking those will allow see which packet belongs to > >which flow. >=20 >=20 > It is not clear to me how knowing which ESP packets belong to which > traffic flow helps a passive attacker.=C2=A0 The attacker still does not > know what is in the packet - the contents of the payload.=C2=A0 Indeed, > ESP would normally mask TCP or UDP ports.=C2=A0 With PDM you can tell > that there ARE multiple flows but you don't know if they are TCP, > UDP, ICMP or anything else.=C2=A0 Most importantly, you don't know what > is in the payload. >Sometimes that is only what is needed, and ESP tries to provide >protection against traffic flow confidentiality, and this option >breaks it. >For example finding out that this flow of packets is the control >traffic of the video stream, and this other flow of packets is the >actual video stream, the attacker can for example block the control >traffic, and make it so that user on the other end cannot stop the >video feed. >Or if there is 3 simultaneous video streams going out, it is much >harder to identify which video stream is what TV-program. If you can >separate them to 3 different video streams, it is much easier to >identify the actual video being watched by checking the packet >lengths. >There are most likely also other kind of attacks, and as this is >service as ESP provides, it is not for PDM to break it unless you >explictly spell it out that this is meant to break property of the >ESP.=20 OK.=C2=A0 I am convinced.=C2=A0 I will tell you though that some of us in I= PPM, we were quite excited (possibly naively) about being able to get some = performance metrics for ESP. I wonder if it would be acceptable to say that PDM could be put into the De= stination Option which precedes ESP if it is for an enterprise customer who= owns the infrastructure and wishes to manage the network that way.=C2=A0 O= therwise, I can change to say that only the Dest Opt following ESP can be u= sed. > If one follows the thinking of your objection, isn't any encrypted > flow over TCP or UDP a problem since a passive attacker knows the > 5-tuple for such flows?=C2=A0 For example, all TLS flows can be analyzed > for traffic in your sense.=C2=A0 So, a flow over TLS (without PDM) > actually leaks more information than an ESP flow WITH PDM.=C2=A0 Because > with TLS, we even know that the flow is TCP and the port number. > Neither of which you know with PDM with ESP. >Yes. And to fix that issue, people use IPsec which will hide the >information about separate TCP and UDP flows. >And now with PDM the IPsec will not provide that service anymore. OK.=C2=A0 Pls see above. > >It claims that PDM MUST be placed before the ESP header in order to > >work, which is untrue. This is destination option, thus it is meant to > >be checked on the destination host, i.e., the packet capture after the > >ESP decryption will allow seeing the PDM header values without issues. >You did not respond to this part, i.e., why is the PDM header outside >the ESP encrypted part, and why it is not inside the ESP? >It is supposed to be destination option, which is only meaningful to >the final destination of the packet, thus it can easily be inside the >ESP protection, as the final destination do know the keys etc will see >the decrypted option header. Pls see above. > >The whole section 4 seems to be wierd. It is talking about different > >encodings, and time units on different systems, and it also talks > >about the limitations on TCP Timestamp Option, but this option uses > >different encoding so I have no idea why this text is here. It would > >be more useful to count what are the limits on the encoding method > >used here (16 bit value, 7 bit signed scaling value), instead of what >=20 > >some other option use. >=20 > Thanks.=C2=A0 Should now be fixed. >What is the meaning of the section 4? >It is good background information, and might be moved to the appendix, >but I do not think it belongs here. It has text that mostly covers >other formats, not the format used here. Also it does not really >specify what does negative scaling values mean, and when are they >used. Let me review this again with one of my co-authors. >If I understand correctly the actual timevalue conversion is so that >=C2=A0 delta_time =3D delta_time_from_packet * 2^Scale >where delta_time_from_packet is between 0x0000 and 0xffff, and scale >is between -127 and 128, and the units are either milliseconds, >microseconds, nanoseconds or picoseconds. >So the smallist time we can express with this is >delta_time_from_packet =3D 0x0001 >scale =3D -127 >unit =3D 11 =3D picoseconds >=C2=A0 delta_time =3D 0.0000000000000000000000000000000000000058 picosecon= ds >=C2=A0 =3D .0000000000000000000000000058 joktoseconds =3D=3D 5.8 * 10^-51 = seconds =C2=A0=20 >and the maximum value is >delta_time_from_packet =3D 0xffff >scale =3D 128 >unit =3D 00 =3D milliseconds >=C2=A0 delta_time =3D 22300404916163702203072254898040929737768960 millise= conds >=C2=A0 =3D 707141201045272139874183628172277 years... >so the range is definately enough. The question is that if the scale >is from -127 to 128, why do we even need the Time Base? The time base is so that one does not have to be committed to picoseconds /= milliseconds, etc.=C2=A0 =C2=A0 Even in your example, I believe you used "= unit" or time base.=C2=A0 Our thinking was that we wanted future proof so a= s to be able to handle very small values and very large (as may be needed f= or DTN, for example).=C2=A0 We can see if we can express years in picosecon= ds and see what happens.=C2=A0 Then, the unit would always be picoseconds. > >The section 8 is wrong as it claims >=20 > >=C2=A0 =C2=A0 "PDM does not introduce any new security weakness." >=20 > >while this will leak lots of information about the traffic flows > >inside the encrypted transport mode ESP packets. >=20 > Please see above. >Leaking this information is new security weakness for the protocol, >which was designed to protect against those attacks.=20 OK. > >Also another thing the PDM leaks is exact host timings, i.e., it can > >be used to launch timing attacks against crypto protocols. In general > >those are hard as it is very hard to know how much of n ms rtt is > >network delay and how much was the actual host processing the packet. > >Now if we can see that that host used 123 nanoseconds to process the > >signature verification packet, and next time it uses 1755 nanoseconds, > >this might allow attacker to get information out from the key. The > >actual round trip times might have been 123 ms in both cases, and the > >1 microsecond difference in the processing time would have been lost > >by the network latencies. >=20 >=20 >=20 > 1. The intent of PDM is as a diagnostic feature.=C2=A0 PDM is OFF > initially at the end hosts (client and server).=C2=A0 It is turned ON for > diagnostics and then turned OFF afterwards.=C2=A0 If someone chooses to > leave PDM ON always, then that is explicitly chosen.=C2=A0 Also, PDM is > an OPTIONAL feature.=C2=A0 Either client or server operating system may > choose not to implement it or use it. >The draft disagrees with this. It says there is configuration option >for it, but does not give default value for it, and says: >3.5 Implementation Considerations >=C2=A0 The PDM destination options extension header SHOULD be turned on by >=C2=A0 each stack on a host node. It MAY also be turned on only in case of >=C2=A0 diagnostics needed for problem resolution. > so it seems it is on by default.=20 Will change to say that it MUST be turned on only by the stack and default = value should be OFF. "The PDM destination options extension header MUST be turned on only by adm= inistrative action at =C2=A0 each stack on a host node.=C2=A0 The default mode for PDM is OFF." > 2. In your example above, it assumes that the signature verification > packet (please let me know which exact packet and protocol you are > referring to) is passing in the clear so that the attacker knows > that it is the signature verification packet.=C2=A0 Possibly this is also > a problem. >Key management packets are usually in clear, as they are there before >we have the actual keys we can use to protect the messages. Also it is >not very difficult to guess that 3rd and 4th message in port 500, are >the IKE AUTH packets, which will contain signatures. >Same thing with TLS. >Attackers will knows which packets contain signatures. Currently >attackers usually send those signature packets themselves, and measure >the time it takes for the device to calculate response. They can also >send garbage packets, and detect how far in checking the packets got >by checking how long it took for the other end to send error message >back. >All this kind of timing attacks are usually considered hard, as the >network delays cause big jitter on the timings, and they need to try >multiple times, and average the response times to get the information >they need. >This method will provide them easy way to bypass that issue.=20 OK.=C2=A0 So, are you saying that PDM is attack vector for TLS and not just= for ESP? > 3.=C2=A0 Protocols often use blinding techniques to remove correlations > between key and encryption time.=C2=A0 Other cryptographic algorithms > can be implemented (or masked by a proxy) in a way that reduces or > eliminates data dependent timing information.=C2=A0 So if timing > information is being leaked, this is a flaw in the algorithm or the > protocol.=C2=A0 In this case, we may be "blaming the messenger".=C2=A0 PD= M is > only reporting what is done.=C2=A0 The algorithm or protocol is the > problem. >Yes. This option makes it easy for the attacker to use those broken >algorithms, protocols and implementations. >This is again new security weakness that this option opens. It was >harder before, after this it is easier.=20 OK. > >In addition to that the abstract is not very clear, it does not do > >very good job of telling that this draft tries to do, and having the > >Background section to duplicate most of that text does not still what >=20 > >this document really tries to do.=20 >=20 > If you can give me a hint as to what is not clear or what you think > this draft DOES propose, then we will be happy to rewrite the > abstract / background section.=20 >My current take is that this option proposes and attack vector against >several different protocols, and as such it does quite good job... Maybe I have missed my calling.=C2=A0 I should be designer of attack vector= s!=C2=A0 (Just kidding.=C2=A0 HAHAHA.=C2=A0 Meant only as a=C2=A0 joke!)=C2= =A0=20 >I have a feeling that this is not for which this draft was meant to do.=20 No, obviously not.=C2=A0 So, now I am not sure where we are.=C2=A0 Is there= a complete objection to this draft or are there changes which can be made = which would make this acceptable? --=20 kivinen@iki.fi =20 ------=_Part_4521186_1930130313.1475511365558 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


I am resending this as the last post somehow got cut off in th= e middle.

Thanks,
<= br clear=3D"none">Nalini Elkins
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360



____= ____________________________
From: "nalini.e= lkins@insidethestack.com" <nalini.elkins@insidethestack.com>
To: Tero Kivi= nen <kivinen@iki.fi>
Cc: "iesg@i= etf.org" <iesg@ietf.org>; "secdir@ietf.org" <secdir@ietf.org>; "draft-ietf-ippm-6man-pdm-op= tion.all@tools.ietf.org" <draft-ietf-ippm-6man-pdm-option.all@t= ools.ietf.org>
Sent: Monday, October 3, 2016 8:39 = AM
Subject: Re: Secdir review of draft-ietf-ippm-6man-pdm= -option-05



Thanks, Tero.  Again, my comments inline.

Nalini Elkins

Ins= ide Products, Inc.
www.insidethestack.com
(831) 659-8360


<= br clear=3D"none">________________________________
From: = Tero Kivinen <kivinen@iki.fi>
To: nalini.elkins@insidethestack.com
Cc: "iesg@ietf.org" <iesg@ietf.org= >; "secdir@ietf.org" <secdir@ietf.org= >; "draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" <draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org>
Sent: Wednesday, September 28, 2016 9:20 AM
Subject: = Re: Secdir review of draft-ietf-ippm-6man-pdm-option-05
<= br clear=3D"none">
nalini.elkins@insidethestack.com writes:
> T= hanks for your comments.  We have posted a new draft with corrections = at:
> https://tools.= ietf.org/html/draft-ietf-ippm-6man-pdm-option-06
>=
> Our responses inline.
> =
> Nalini Elkins
>
> Inside Products, Inc.
> www.insidethestack.= com
> (831) 659-8360
>
>
>
> ____________= ____________________
> From: Tero Kivinen <= kivinen@iki.fi>
> To: iesg@ietf.org; = secdir@ietf.org; draft-ietf-ippm-6man-pdm-option.all@too= ls.ietf.org
> Sent: Monday, September 19, 2016 7:= 12 AM
> Subject: Secdir review of draft-ietf-ippm-6man= -pdm-option-05
>
> >I think t= his document has serious issues.
>
= > >It proposes that the new Destination option MUST be put before the= ESP
> >so it is sent in clear. This will leak out = the traffic information
> >from the ESP, allowing e= asy traffic analysis of encrypted packets, as
> >pa= ssive attacker can see which encrypted ESP packets belong to which
> >5-tuple flow. The PDM option header includes the increme= nting sequence
> >numbers, so checking those will a= llow see which packet belongs to
> >which flow.
>
>
> It is n= ot clear to me how knowing which ESP packets belong to which
> traffic flow helps a passive attacker.  The attacker still d= oes not
> know what is in the packet - the contents of= the payload.  Indeed,
> ESP would normally mask = TCP or UDP ports.  With PDM you can tell
> that t= here ARE multiple flows but you don't know if they are TCP,
> UDP, ICMP or anything else.  Most importantly, you don't know = what
> is in the payload.

>Sometimes that is only what is needed, and ESP tries to provi= de
>protection against traffic flow confidentiality, a= nd this option
>breaks it.

>For example finding out that this flow of packets is the cont= rol
>traffic of the video stream, and this other flow = of packets is the
>actual video stream, the attacker c= an for example block the control
>traffic, and make it= so that user on the other end cannot stop the
>video = feed.

>Or if there is 3 simultaneou= s video streams going out, it is much
>harder to ident= ify which video stream is what TV-program. If you can
>= ;separate them to 3 different video streams, it is much easier to
>identify the actual video being watched by checking the packe= t
>lengths.

>T= here are most likely also other kind of attacks, and as this is
>service as ESP provides, it is not for PDM to break it unless yo= u
>explictly spell it out that this is meant to break = property of the
>ESP.


OK.  I am convinced.  I will tell you th= ough that some of us in IPPM, we were quite excited (possibly naively) abou= t being able to get some performance metrics for ESP.
I wonder if it would be acceptable to say that PDM could be= put into the Destination Option which precedes ESP if it is for an enterpr= ise customer who owns the infrastructure and wishes to manage the network t= hat way.  Otherwise, I can change to say that only the Dest Opt follow= ing ESP can be used.


> If one follows the thinking of your objection, isn't any encrypted> flow over TCP or UDP a problem since a passive attack= er knows the
> 5-tuple for such flows?  For examp= le, all TLS flows can be analyzed
> for traffic in you= r sense.  So, a flow over TLS (without PDM)
> act= ually leaks more information than an ESP flow WITH PDM.  Because
> with TLS, we even know that the flow is TCP and the port = number.
> Neither of which you know with PDM with ESP.=

>Yes. And to fix that issue, peopl= e use IPsec which will hide the
>information about sep= arate TCP and UDP flows.

>And now w= ith PDM the IPsec will not provide that service anymore.
=
OK.  Pls see above.


> >It claims that PDM MUST be placed before = the ESP header in order to
> >work, which is untrue= . This is destination option, thus it is meant to
> &g= t;be checked on the destination host, i.e., the packet capture after the> >ESP decryption will allow seeing the PDM header va= lues without issues.

>You did not r= espond to this part, i.e., why is the PDM header outside
= >the ESP encrypted part, and why it is not inside the ESP?

>It is supposed to be destination option, which = is only meaningful to
>the final destination of the pa= cket, thus it can easily be inside the
>ESP protection= , as the final destination do know the keys etc will see
= >the decrypted option header.

Pls s= ee above.


> >= The whole section 4 seems to be wierd. It is talking about different
> >encodings, and time units on different systems, and it= also talks
> >about the limitations on TCP Timesta= mp Option, but this option uses
> >different encodi= ng so I have no idea why this text is here. It would
>= >be more useful to count what are the limits on the encoding method
> >used here (16 bit value, 7 bit signed scaling value= ), instead of what
>
> >some = other option use.
>
> Thanks.&nb= sp; Should now be fixed.

>What is t= he meaning of the section 4?

>It is= good background information, and might be moved to the appendix,
>but I do not think it belongs here. It has text that mostly c= overs
>other formats, not the format used here. Also i= t does not really
>specify what does negative scaling = values mean, and when are they
>used.

Let me review this again with one of my co-authors.
>If I understand correctly the actual= timevalue conversion is so that

>&= nbsp; delta_time =3D delta_time_from_packet * 2^Scale
>where delta_time_from_packet is between 0x0000 and 0xf= fff, and scale
>is between -127 and 128, and the units= are either milliseconds,
>microseconds, nanoseconds o= r picoseconds.

>So the smallist tim= e we can express with this is

>delt= a_time_from_packet =3D 0x0001
>scale =3D -127
>unit =3D 11 =3D picoseconds

>  delta_time =3D 0.0000000000000000000000000000000000000058 p= icoseconds
>  =3D .0000000000000000000000000058 = joktoseconds =3D=3D 5.8 * 10^-51 seconds
 
>and the maximum value is

>delta_time_from_packet =3D 0xffff
>scale =3D 128<= br clear=3D"none">>unit =3D 00 =3D milliseconds

>  delta_time =3D 22300404916163702203072254898040929= 737768960 milliseconds
>  =3D 707141201045272139= 874183628172277 years...

>so the ra= nge is definately enough. The question is that if the scale
>is from -127 to 128, why do we even need the Time Base?


The time base is so that one do= es not have to be committed to picoseconds / milliseconds, etc.   = ; Even in your example, I believe you used "unit" or time base.  Our t= hinking was that we wanted future proof so as to be able to handle very sma= ll values and very large (as may be needed for DTN, for example).  We= can see if we can express years in picoseconds and see what happens. = Then, the unit would always be picoseconds.


> >The section 8 is wrong as it claims>
> >    "PDM does n= ot introduce any new security weakness."
>
> >while this will leak lots of information about the traff= ic flows
> >inside the encrypted transport mode ESP= packets.
>
> Please see above.<= br clear=3D"none">
>Leaking this information is new se= curity weakness for the protocol,
>which was designed = to protect against those attacks.

OK.=

> >Also another thing the PDM l= eaks is exact host timings, i.e., it can
> >be used= to launch timing attacks against crypto protocols. In general
> >those are hard as it is very hard to know how much of n ms r= tt is
> >network delay and how much was the actual = host processing the packet.
> >Now if we can see th= at that host used 123 nanoseconds to process the
> >= ;signature verification packet, and next time it uses 1755 nanoseconds,
> >this might allow attacker to get information out fr= om the key. The
> >actual round trip times might ha= ve been 123 ms in both cases, and the
> >1 microsec= ond difference in the processing time would have been lost
> >by the network latencies.
>
>
>
> 1. The intent of P= DM is as a diagnostic feature.  PDM is OFF
> init= ially at the end hosts (client and server).  It is turned ON for
> diagnostics and then turned OFF afterwards.  If some= one chooses to
> leave PDM ON always, then that is exp= licitly chosen.  Also, PDM is
> an OPTIONAL featu= re.  Either client or server operating system may
&g= t; choose not to implement it or use it.

>The draft disagrees with this. It says there is configuration option=
>for it, but does not give default value for it, and = says:


>3.5 Imple= mentation Considerations

>  T= he PDM destination options extension header SHOULD be turned on by
>  each stack on a host node. It MAY also be turned on o= nly in case of
>  diagnostics needed for problem= resolution.

> so it seems it is on= by default.


Will = change to say that it MUST be turned on only by the stack and default value= should be OFF.

"The PDM destination o= ptions extension header MUST be turned on only by administrative action at<= br clear=3D"none">  each stack on a host node.  The default mode = for PDM is OFF."


&g= t; 2. In your example above, it assumes that the signature verification
> packet (please let me know which exact packet and proto= col you are
> referring to) is passing in the clear so= that the attacker knows
> that it is the signature ve= rification packet.  Possibly this is also
> a pro= blem.

>Key management packets are u= sually in clear, as they are there before
>we have the= actual keys we can use to protect the messages. Also it is
>not very difficult to guess that 3rd and 4th message in port 500, ar= e
>the IKE AUTH packets, which will contain signatures= .

>Same thing with TLS.

>Attackers will knows which packets contain si= gnatures. Currently
>attackers usually send those sign= ature packets themselves, and measure
>the time it tak= es for the device to calculate response. They can also
&g= t;send garbage packets, and detect how far in checking the packets got
>by checking how long it took for the other end to send er= ror message
>back.

>All this kind of timing attacks are usually considered hard, as the>network delays cause big jitter on the timings, and th= ey need to try
>multiple times, and average the respon= se times to get the information
>they need.

>This method will provide them easy way to = bypass that issue.

OK.  So, are = you saying that PDM is attack vector for TLS and not just for ESP?

> 3.  Protocols often use blinding tec= hniques to remove correlations
> between key and encry= ption time.  Other cryptographic algorithms
> ca= n be implemented (or masked by a proxy) in a way that reduces or
> eliminates data dependent timing information.  So if t= iming
> information is being leaked, this is a flaw in= the algorithm or the
> protocol.  In this case,= we may be "blaming the messenger".  PDM is
> onl= y reporting what is done.  The algorithm or protocol is the
> problem.

>Yes. This = option makes it easy for the attacker to use those broken
>algorithms, protocols and implementations.

>This is again new security weakness that this option opens. I= t was
>harder before, after this it is easier.

OK.

> >In addition to that the abstract is not very clear= , it does not do
> >very good job of telling that t= his draft tries to do, and having the
> >Background= section to duplicate most of that text does not still what
>
> >this document really tries to do.
>
> If you can give me a hint as to = what is not clear or what you think
> this draft DOES = propose, then we will be happy to rewrite the
> abstra= ct / background section.

>My curre= nt take is that this option proposes and attack vector against
>several different protocols, and as such it does quite good job..= .

Maybe I have missed my calling. = ; I should be designer of attack vectors!  (Just kidding.  HAHA= HA.  Meant only as a  joke!) 


>I have a feeling that this is not for whic= h this draft was meant to do.

No, obv= iously not.  So, now I am not sure where we are.  Is there a co= mplete objection to this draft or are there changes which can be made which= would make this acceptable?

------=_Part_4521186_1930130313.1475511365558-- From nobody Mon Oct 3 13:54:58 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62AC5129549 for ; Mon, 3 Oct 2016 13:54:55 -0700 (PDT) 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, RCVD_IN_MSPIKE_H2=-0.001] autolearn=unavailable autolearn_force=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 9oIL8AMN4WyC for ; Mon, 3 Oct 2016 13:54:54 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr [80.12.242.127]) by ietfa.amsl.com (Postfix) with ESMTP id AE27D129557 for ; Mon, 3 Oct 2016 13:54:53 -0700 (PDT) Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d09 with ME id r8nN1t00D17Lgi4038nNHv; Mon, 03 Oct 2016 22:47:22 +0200 X-ME-Helo: macbook-pro-de-julien-elie.home X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg== X-ME-Date: Mon, 03 Oct 2016 22:47:22 +0200 X-ME-IP: 92.170.5.52 To: Barry Leiba References: <20981db3190142193043f1445abadaa3@trigofacile.com> From: =?UTF-8?Q?Julien_=c3=89LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ Message-ID: <1b5edd03-675c-01b7-6d06-c2e155987929@trigofacile.com> Date: Mon, 3 Oct 2016 22:47:22 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-murchison-nntp-compress.all@ietf.org, IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-murchison-nntp-compress-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 20:54:55 -0000 Hi Barry, I'm currently reviewing the comments I need to take into account for the document. Do you believe I should add a note about a possible security issue as far as the use of DEFLATE is concerned? (see below) (An "out of memory" attack?) Thanks, -- Julien Le 22/09/2016 à 22:52, Julien ÉLIE a écrit : > Hi Barry, > > Thanks for your answer. I'll have a deeper look at it soon. > > As for the remaining "small points" of rewording (SHOULD, MUST, etc.), > I'll calmly see them when updating the draft after Last Call. In case I > have a doubt for the best wording, I'll ask Ken (co-author) and Michael > (write-up shepherd) their preference. We'll obviously manage to come up > with the "final" rewording as we'll have 3 votes for 2 choices. > > > Now that I think about it, wouldn't it be worth adding something about > possible "out of memory" attacks in the Security Considerations Section? > > According to , "a 50MB file filled with > zeros [...] a version of run-length encoding optimized for this sort of > unusual data file [...] could encode the test file in five bytes. That > would be a compression factor of 10,000,000:1". > So sending just 5 bytes may require an expansion to 50MB. > > Implementations therefore really need to check that the uncompressed > data does not exceed an upper bound limit. > > RFC 1951 (DEFLATE) does not mention it in its Security Considerations, > and I don't remember having seen that in other RFCs too. Maybe we > should say a word for it in the NNTP COMPRESS extension. > From nobody Mon Oct 3 21:40:27 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8F912940E for ; Mon, 3 Oct 2016 21:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Ql7xI0KNbush for ; Mon, 3 Oct 2016 21:40:25 -0700 (PDT) Received: from mx36.antispamcloud.com (mx36.antispamcloud.com [209.126.110.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 385621200DF for ; Mon, 3 Oct 2016 21:40:24 -0700 (PDT) Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1brHWh-0008Qe-4L for secdir@ietf.org; Tue, 04 Oct 2016 06:40:24 +0200 Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1brHWc-00010M-4S for secdir@ietf.org; Tue, 04 Oct 2016 00:40:22 -0400 Received: (qmail 9047 invoked from network); 4 Oct 2016 04:40:17 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 4 Oct 2016 04:40:17 -0000 From: "Christian Huitema" To: Date: Mon, 3 Oct 2016 21:40:13 -0700 Message-ID: <001f01d21df9$66466f80$32d34e80$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdId9wjlcw7T5rW8SrOHZbiK9XlfbQ== Content-Language: en-us X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dHEJL963yvZzofOAehTafloeD9ey9972JZ1Xcr1RWHu8UvfgoE7Tx8PYIcekOty5V8/1 7Ag8wtD2TJMLVVqjXv532s4RcMeaqgJ+knaOuDWHUV8ShebT8U8Xw9HTDfreWQUhw0NOE6GJ4h1S yx3SVxwAHipOgYHuTWrgWy9HdVyatXEhj8EK+HsAUQsUJ5UViSERbInMiTBIUBbQ/Dy6Ip65STY7 l95uSQXuDttVfirReN+nPOThvNMbaJkwAzpLvdjedJpPdGd4M3H04f+dLFn3Y80OmAux3oN13+zt UzneQStaz8oVbDEOn0N5SprgYxq5k9b3r8eYLgArMMuSf+d22E6MO50XfD46wv4v/HrW8AUy9fur wzjHps/+CPPDQ5nY6UdwTAUdOhwsK6fGLondgVgKTjt9nKq3Gw+3KmSNlHQHrP4vlFnRrJb8siOD 2YPAgTtUp75uqlx0KezvZHWZkXA2Rzv0GuvoC4ptsIakTG2DhCXROOtiZYOBMnaUKgEiRQv+PVjj wa+Z5RFCOMS3ylvKYrKemIoGlpsypPJAli8SkxIjuZViW+LZJXST85TbLDrPzkvdTIJ076hDdLsR ZMxd0ZLZrOPTv3nlZv/9 X-Report-Abuse-To: spam@mx99.antispamcloud.com X-Originating-IP: 168.144.250.245 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.61) X-Recommended-Action: accept Archived-At: Cc: 'Tim Chown' , 'Daniel Kaiser' , 'Ralph Droms' Subject: [secdir] Advice on pairing specification, TLS, etc. X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 04:40:27 -0000 Sometimes, one thing leads to another. Daniel and I are working in the DNS-SD working group on a specification for "private discovery". The idea is that you come to some open space, say a Wi-Fi hot spot, and you can find your buddies. But the process is kept private, so that third parties cannot find out who you are, and only your "friends" can discover and access the services that you are publishing. That was the first thing. It is specified in https://datatracker.ietf.org/doc/draft-huitema-dnssd-privacy/. But the specification assumes that the devices that can be discovered have gone through a "pairing" process, in order to set up some PSK that is then used to obfuscate the discovery and secure access to the services. Which is how it led to the next step, specifying a pairing system. We are giving it a shot. The first version of the pairing draft is at https://datatracker.ietf.org/doc/draft-kaiser-dnssd-pairing/. It specifies how to set up a pairing using TLS with [EC]DH anon, then exchange random numbers using a commitment before disclosure protocol, so that the verification of a Short Authentication String provides robustness against MITM. But we have plenty of questions. Should we specify the protocol as an extension to TLS, as was once proposed in https://tools.ietf.org/html/draft-miers-tls-sas-00, a draft that is now expired? Should we use TLS resume tickets instead of passwords? The DNS-SD working group is probably not well equipped to look at these issues. Would some participants to SAAG give us advice? -- Christian Huitema From nobody Tue Oct 4 06:52:24 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 267C7129872; Tue, 4 Oct 2016 06:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=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 OBDwem-BdLl9; Tue, 4 Oct 2016 06:52:19 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 300C2129855; Tue, 4 Oct 2016 06:52:19 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.175.11; From: "Susan Hares" To: "'Radia Perlman'" , , "'The IESG'" , References: In-Reply-To: Date: Tue, 4 Oct 2016 09:50:46 -0400 Message-ID: <0dbe01d21e46$4f1054a0$ed30fde0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0DBF_01D21E24.C800FE90" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHwTaRIVxyKa536AFjBbYHNIg5Xy6Bb8Rmw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-i2rs-protocol-security-requirements X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 13:52:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0DBF_01D21E24.C800FE90 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Radia:=20 =20 Thank you for the additional review. I will update this in the next = version of the draft (which is in the RFC editor=E2=80=99s queue). =20 Sue=20 =20 From: Radia Perlman [mailto:radiaperlman@gmail.com]=20 Sent: Sunday, October 2, 2016 12:12 AM To: secdir@ietf.org; The IESG; = draft-ietf-i2rs-protocol-security-requirements.all@tools.ietf.org Subject: Secdir review of draft-ietf-i2rs-protocol-security-requirements =20 =20 =20 On Thu, Sep 15, 2016 at 6:43 AM, Radia Perlman = wrote: I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these comments just like any = other last call comments. I previously reviewed version 6 and 10, and all my comments are = addressed in this version (17). The secdir assignment was for version = 14, but the latest version seems to be 17, so that is the one that I = reviewed. =20 Nothing substantive, certainly no security issues, and it's ready for = publication. =20 I do have a few super-minor typos in this version (17) Apologies for = the weird formatting of my comments below. Perhaps it's gmail, that when = I cut-and-paste from the document, makes weird boxes, so please ignore = the boxes. If gmail is just putting boxes in while I type in my = comments, just to annoy me, and they don't appear in the sent email, = then ignore the non-boxes I'm complaining about. Anyway, here are my = comments: =20 There seems to be a cut-and-paste error here: =20 "The optional insecure transport can only be used restricted set of = publically data available (events or information)" =20 Perhaps it should be "The optional insecure transport can only be used = when accessing publically available data (events or information)". =20 =20 Not exactly sure what you'd like it to be...but there does seem to be at = least a missing word in the text from the document. =20 ----- And as long as I'm noticing extremely minor editorial things during = reread: =20 "The first application is a weekly configuration application that uses the I2RS protocol to change configurations. The second application is an application that allows operators to makes emergency changes to routers in the network" In the first sentence I'd probably say "periodic" instead of "weekly". The second sentence should be "to make" instead of "to makes" ----------- Another super-minor typo "A variety of forms of managemen" is missing the letter "t" in "management" Radia ------=_NextPart_000_0DBF_01D21E24.C800FE90 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Radia:

 

Thank you for the additional review.=C2=A0 I will update this in the = next version of the draft (which is in the RFC editor=E2=80=99s = queue).

 

Sue

 

From:= = Radia Perlman [mailto:radiaperlman@gmail.com]
Sent: Sunday, = October 2, 2016 12:12 AM
To: secdir@ietf.org; The IESG; = draft-ietf-i2rs-protocol-security-requirements.all@tools.ietf.org
S= ubject: Secdir review of = draft-ietf-i2rs-protocol-security-requirements

 

 

 

On Thu, = Sep 15, 2016 at 6:43 AM, Radia Perlman <radiaperlman@gmail.com> wrote:
I have reviewed this document as part of the = security directorate's ongoing effort to review all IETF documents being = processed by the IESG.
These = comments were written primarily for the benefit of the security area = directors.
Document editors = and WG chairs should treat these comments just like any other last call = comments.

I previously = reviewed version 6 and 10, and all my comments are addressed in this = version (17). The secdir assignment was for version 14, but the latest = version seems to be 17, so that is the one that I = reviewed.

 

Nothing substantive, certainly no security issues, and = it's ready for publication.

 

I = do have a few super-minor typos in this version (17)  Apologies for = the weird formatting of my comments below. Perhaps it's gmail, that when = I cut-and-paste from the document, makes weird boxes, so please ignore = the boxes.  If gmail is just putting boxes in while I type in my = comments, just to annoy me, and they don't appear in the sent email, = then ignore the non-boxes I'm complaining about.  Anyway, here are = my comments:

 

There seems to be a cut-and-paste error = here:

 

"The optional insecure transport can = only be used restricted set of publically data available (events or = information)"

 

Perhaps it should be "The = optional insecure transport can only be used when accessing publically = available data (events or information)". =  

 

Not exactly sure what you'd like it = to be...but there does seem to be at least a missing word in the text = from the document.

 

-----

And as long as I'm noticing = extremely minor editorial things during = reread:

 

"The first application is a =
weekly configuration application
=C2=A0=C2=A0 that uses the I2RS =
protocol to change configurations.=C2=A0 The =
second
=C2=A0=C2=A0 application is an =
application that allows operators to makes
=C2=A0=C2=A0 emergency changes to =
routers in the network"
In =
the first sentence I'd probably say "periodic" instead of =
"weekly".
The =
second sentence should be "to make" instead of "to =
makes"
-----------
Another super-minor typo "A =
variety of forms of managemen"=C2=A0 is =
missing
the =
letter "t" in =
"management"
Radia
------=_NextPart_000_0DBF_01D21E24.C800FE90-- From nobody Tue Oct 4 09:38:42 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1AA01295A1; Tue, 4 Oct 2016 09:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 v8TBgGqfewyC; Tue, 4 Oct 2016 09:38:39 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03104120726; Tue, 4 Oct 2016 09:38:38 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id b201so155731100wmb.0; Tue, 04 Oct 2016 09:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=9uQFlQ9Ft7eakfMhyJfTdqghw+wFlyJXUOJr6EnGWow=; b=WoLnc1/ChJL0RQt7Eo87ytVd6sdf6yopbWymDELCsx6yCFDV1ZHCKrVLOKKHOoxlEY hHKdloX/XeUaOCkXd1fI6HAt+1hWUW0MDFCuh7itEp7nD1PbIKfUrt3Vyn8RoULMhPWy 1wdgDfr3jlRUJqpOanhx0m5p2U2PjyYE66KRjTsyO/kipjzdA/d+o8TNqCYtWs1gXwPI 6jFNkIAcyhRbTpytWyqqgmJHtca2iIMJazqEttQm4HkJqz2NReU5+Cb9rHb1s8gZdg6X lGz0QE9iLmmMGuMUN7Fn4AYxBlWWZzvQzPJlZ3l9cXlO6mgXHQmFQlpQJFrkLTuJ1HgV gunA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=9uQFlQ9Ft7eakfMhyJfTdqghw+wFlyJXUOJr6EnGWow=; b=CcuU1Y5z1bpixmRImXxtMoLRLhMdI9ulR4cVgiJEnSEjknSnQNw9I14fhFiK+J2Ppf KBNJpcj74CEj8a+xxhIjk3+91bXG4/dbNNxkFhC7/LUH/CNl9ITZMSmM8vHI6pLEYK48 1HCLTi35mSUC4uxqSmn6ZIUaff2WyAS6+HJSaBg/SMBWBi6edQMxl5youBvXu1XSJ2XA NwikeIcssAaxBh0kME3EqyEjqBsmPEOQuscPUibUbxcg9l0Get0n13I/XHH27w1X3Z+C /zmNOMnSv++dI9hRrvekhe/dxm5lK7bzCAIFMcrlNTcKYKCQXMdaUZROOdnctsdYvmY5 omAA== X-Gm-Message-State: AA6/9RlUrP8zz6DhngomW2plMOmWmL4aJKyso6Zq3zcIJMmhbbuhxQ7KccKRYb/C1UM9/A== X-Received: by 10.194.75.227 with SMTP id f3mr3840830wjw.2.1475599117468; Tue, 04 Oct 2016 09:38:37 -0700 (PDT) Received: from [192.168.1.13] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id w71sm4906718wmw.17.2016.10.04.09.38.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Oct 2016 09:38:36 -0700 (PDT) From: Yoav Nir Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Message-Id: <834C9D97-98D2-49EB-BD34-5C28C84AB10F@gmail.com> Date: Tue, 4 Oct 2016 19:38:33 +0300 To: draft-weis-gdoi-iec62351-9.all@tools.ietf.org, secdir , The IESG X-Mailer: Apple Mail (2.3226) Archived-At: Subject: [secdir] SecDir Review of draft-weis-gdoi-iec62351-9-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 16:38:41 -0000 Hi. I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these comments just like any = other last call comments. Summary: Ready with a question The draft describes using GDOI with some extensions to transport keying = material for the IEC 61850 power utility automation family of standards. I have previously reviewed version -02 of the draft three years ago = ([1]). Later versions addressed my issues about the document being too = opaque for people not versed in IEC protocols and terminology. It is = still rather hard to read without the relevant background, but that is = to be expected in a document targeted at a very specific audience (which = I am not part of). The Security Considerations section points to the section in RFC 6407 = (GDOI). Additional paragraphs point out that message authentication is = mandatory, while confidentiality is optional. And yet the same = paragraph makes confidentiality a SHOULD if the packets are expected to = traverse the public Internet. The last sentence says that 128-bit = AES-CBC is good enough for the foreseeable future, "but some security = policies may require the use of AES-CBC-256.=E2=80=9D There is no = mention of why such policies may require this. The usual reason is to = protect against future attacks by quantum computers, but I think it=E2=80=99= s fine to leave that out. My question is about the IEC-61850 SA TEK Payload described in Figure 4 = in section 2.2. It has separate fields for Auth Alg and Enc Alg. The Enc = Alg field has 4 possible values described in section 2.2.3, including = AES-GCM-128 and AES-GCM-256. AES-GCM is an AEAD algorithm. As such it = should not be used in conjunction with a MAC algorithm. Other protocols = either omit the MAC algorithm when an AEAD is used, or create a special = =E2=80=98none=E2=80=99 value for such cases. Here there are no None = value (though there are two Reserved values in the IANA considerations = section). This makes it possible to have SA TEK payloads with = AES-GCM-128 and HMAC-SHA256-128. How do you even do that? And why? Yoav [1] = https://mailarchive.ietf.org/arch/msg/secdir/-C5_XjfTk42DO013DkbA6q0tQmA= From nobody Wed Oct 5 08:20:34 2016 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B854212978C; Wed, 5 Oct 2016 08:16:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1475680590; bh=jb9zvVDD4VtH3G2tKuNridgLRM/a1H/SH4VUb2XCeos=; h=From:Date:To:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=O1RcGNXvLxmY8dHCQEYkf9eoTaRcmCPtBb2VNS5VXBkcqy1XtK5O5v2/5RGA2Vkmi PDerPTmdQDd84xqRbkldeRMGiQBMaqhHAH3rfsqvBIj9R6dFw112igE3yVAbC+vaXf vHi9p+cUf8ujddaEcZ+E7SxpTBIl+nHKybpE9apw= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 121441293E9 for ; Tue, 4 Oct 2016 10:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ieee-org.20150623.gappssmtp.com 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 ZimIvIHoCTRX for ; Tue, 4 Oct 2016 10:03:53 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37B281293E8 for ; Tue, 4 Oct 2016 10:03:53 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id j69so155860546itb.0 for ; Tue, 04 Oct 2016 10:03:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=uSnDdqY1Xt/7LkPqpfbHNt0d6Yk72As4QXGDIcVwRYo=; b=O6WIroVEWH+pR0riOqSXH+hFTD4x0zVEEhXaPGnk3/yIkEjpr+uVduOb/Dck5cEnok sy2UBVV37X1mGRO9ovoWTF0a1far1RDXmQeAC/QAgdTytYs3RR8XrB+0A0mBSY8FV+rP uW2qbojK9pQcDye5TsGRrfpbdSKwwmPVoZwVwQRysH1aiyun3uvSpZQ2O6pSW2f3rv8V P10pJeAWKxqBy+62YNMzqOTJ9JrLJ+XnZ5u8YYVZeNuzDGdFMBlkurtAdNLPGlW46cqj Yhqs/RkPs5GWYmnScs+t9Y32T7G/xvvDqn9t/CnlKrieu9iuM6NDDgfxYPU8z0d21lle 7LaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=uSnDdqY1Xt/7LkPqpfbHNt0d6Yk72As4QXGDIcVwRYo=; b=ATYNIoxOmv0TmMtcUHoD+aHwEvhPPUK1KHFiqKium953EyXBgF4gsXCC6nL3RAcQbh 6lj4wFtt1GYn733VkwH2igXDtBUhVQ0iInlXR6vBXBnViioQAqE0+U6wW7E6irHfOgJ4 i3xPocx24nOnhad6ljOdXiN/pwY74aoJZK1QLLk4aSUlLelohJp3wybGHDy5tGvzl4N7 M97CMiDcd0wyoNZ/Y2NgN/ZUgE5zPmdnOMNu4D7GxxJXa/fq2OuHQrgjCkeFExmh17Q+ us8eKceC5bFObZ1vpZ1AH1spTU6gijCx3TONbGjLp3NXhyjnNSq6LiaXJVAw7H4FDXu0 jUUA== X-Gm-Message-State: AA6/9RnC0pnG4NrNzCsW+8CuwEMOI6/Gfdwzd93yyhNYLVlZy3SnlEKZUNECgXbSvCHJwJVpMIhit23tovfILJxL X-Received: by 10.36.144.68 with SMTP id x65mr4914304itd.70.1475600631864; Tue, 04 Oct 2016 10:03:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.148.87 with HTTP; Tue, 4 Oct 2016 10:03:30 -0700 (PDT) From: Walter Pienciak Date: Tue, 4 Oct 2016 11:03:30 -0600 Message-ID: To: new-work@ietf.org Content-Type: multipart/mixed; boundary=94eb2c07e8067ea6e7053e0d0b37 Archived-At: X-Mailman-Approved-At: Wed, 05 Oct 2016 08:16:23 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Wed, 05 Oct 2016 08:20:29 -0700 Subject: [secdir] [new-work] IEEE-SA NesCom and RevCom recommendations from September 2016 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 15:16:31 -0000 --94eb2c07e8067ea6e7053e0d0b37 Content-Type: multipart/alternative; boundary=94eb2c07e8067ea6e0053e0d0b35 --94eb2c07e8067ea6e0053e0d0b35 Content-Type: text/plain; charset=UTF-8 Hi, Attached are the new work project recommendations by IEEE-SA RevCom and NesCom during their September 2016 teleconferences. All recommendations were subsequently approved by the IEEE-SA Standards Board (SASB). https://standards.ieee.org/about/sasb/revcom/index.html https://standards.ieee.org/about/sasb/nescom/index.html I'd like to highlight two new projects in particular: P7000: "Model Process for Addressing Ethical Concerns During System Design" https://standards.ieee.org/develop/project/7000.html P2675: "DevOps -- Standard for Building Reliable and Secure Systems Including Application Build, Package and Deployment" https://standards.ieee.org/develop/project/2675.html If you have any questions, I can pass them on to the correct liaisons. Walter Walter Pienciak Senior Manager, Strategic Programs, IEEE Standards Association w.pienciak@ieee.org +1 303 527 0934 --94eb2c07e8067ea6e0053e0d0b35 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Attached are the new work project rec= ommendations by IEEE-SA RevCom and NesCom during their September 2016 teleconferences.=C2=A0 All recommen= dations were subsequently approved by the IEEE-SA Standards Board (SASB).
https://standards.ieee.org/about/sasb/revcom/in= dex.html
https://standards.ieee.org/about/sasb/nesco= m/index.html

I'd like to highlight two new projects in= particular:

P7000: "Model Process for Addressing Ethical Conce= rns During System Design"
https://standards.ieee.org/= develop/project/7000.html=20

P2675: "DevOps -- Standard for Building Reliable and Secur= e Systems Including Application Build, Package and Deployment"
https://standards.ieee.org/develop/project/2675.html

If you have any questions, I can pass them on to the correct liaiso= ns.

Walter

Walter = Pienciak
Senior Manager, Strategic Programs, IEEE Standards Assoc= iation

--94eb2c07e8067ea6e0053e0d0b35-- --94eb2c07e8067ea6e7053e0d0b37 Content-Type: application/pdf; name="2016-09_IEEE-SA_NesCom-recommendations.pdf" Content-Disposition: attachment; filename="2016-09_IEEE-SA_NesCom-recommendations.pdf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_itvqd9mn0 JVBERi0xLjMKJeLjz9MKMSAwIG9iajw8L1Byb2R1Y2VyKGh0bWxkb2MgMS44LjI3IENvcHlyaWdo dCAxOTk3LTIwMDYgRWFzeSBTb2Z0d2FyZSBQcm9kdWN0cywgQWxsIFJpZ2h0cyBSZXNlcnZlZC4p L0NyZWF0aW9uRGF0ZShEOjIwMTYwOTIwMjMzNTA2KzA0MDApPj5lbmRvYmoKMiAwIG9iajw8L1R5 cGUvRW5jb2RpbmcvRGlmZmVyZW5jZXNbIDMyL3NwYWNlL2V4Y2xhbS9xdW90ZWRibC9udW1iZXJz aWduL2RvbGxhci9wZXJjZW50L2FtcGVyc2FuZC9xdW90ZXNpbmdsZS9wYXJlbmxlZnQvcGFyZW5y aWdodC9hc3Rlcmlzay9wbHVzL2NvbW1hL2h5cGhlbi9wZXJpb2Qvc2xhc2gvemVyby9vbmUvdHdv L3RocmVlL2ZvdXIvZml2ZS9zaXgvc2V2ZW4vZWlnaHQvbmluZS9jb2xvbi9zZW1pY29sb24vbGVz cy9lcXVhbC9ncmVhdGVyL3F1ZXN0aW9uL2F0L0EvQi9DL0QvRS9GL0cvSC9JL0ovSy9ML00vTi9P L1AvUS9SL1MvVC9VL1YvVy9YL1kvWi9icmFja2V0bGVmdC9iYWNrc2xhc2gvYnJhY2tldHJpZ2h0 L2FzY2lpY2lyY3VtL3VuZGVyc2NvcmUvZ3JhdmUvYS9iL2MvZC9lL2YvZy9oL2kvai9rL2wvbS9u L28vcC9xL3Ivcy90L3Uvdi93L3gveS96L2JyYWNlbGVmdC9iYXIvYnJhY2VyaWdodC9hc2NpaXRp bGRlIDE2MC9zcGFjZS9leGNsYW1kb3duL2NlbnQvc3RlcmxpbmcvY3VycmVuY3kveWVuL2Jyb2tl bmJhci9zZWN0aW9uL2RpZXJlc2lzL2NvcHlyaWdodC9vcmRmZW1pbmluZS9ndWlsbGVtb3RsZWZ0 L2xvZ2ljYWxub3QvbWludXMvcmVnaXN0ZXJlZC9tYWNyb24vZGVncmVlL3BsdXNtaW51cy90d29z dXBlcmlvci90aHJlZXN1cGVyaW9yL2FjdXRlL211L3BhcmFncmFwaC9wZXJpb2RjZW50ZXJlZC9j ZWRpbGxhL29uZXN1cGVyaW9yL29yZG1hc2N1bGluZS9ndWlsbGVtb3RyaWdodC9vbmVxdWFydGVy L29uZWhhbGYvdGhyZWVxdWFydGVycy9xdWVzdGlvbmRvd24vQWdyYXZlL0FhY3V0ZS9BY2lyY3Vt ZmxleC9BdGlsZGUvQWRpZXJlc2lzL0FyaW5nL0FFL0NjZWRpbGxhL0VncmF2ZS9FYWN1dGUvRWNp cmN1bWZsZXgvRWRpZXJlc2lzL0lncmF2ZS9JYWN1dGUvSWNpcmN1bWZsZXgvSWRpZXJlc2lzL0V0 aC9OdGlsZGUvT2dyYXZlL09hY3V0ZS9PY2lyY3VtZmxleC9PdGlsZGUvT2RpZXJlc2lzL211bHRp cGx5L09zbGFzaC9VZ3JhdmUvVWFjdXRlL1VjaXJjdW1mbGV4L1VkaWVyZXNpcy9ZYWN1dGUvVGhv cm4vZ2VybWFuZGJscy9hZ3JhdmUvYWFjdXRlL2FjaXJjdW1mbGV4L2F0aWxkZS9hZGllcmVzaXMv YXJpbmcvYWUvY2NlZGlsbGEvZWdyYXZlL2VhY3V0ZS9lY2lyY3VtZmxleC9lZGllcmVzaXMvaWdy YXZlL2lhY3V0ZS9pY2lyY3VtZmxleC9pZGllcmVzaXMvZXRoL250aWxkZS9vZ3JhdmUvb2FjdXRl L29jaXJjdW1mbGV4L290aWxkZS9vZGllcmVzaXMvZGl2aWRlL29zbGFzaC91Z3JhdmUvdWFjdXRl L3VjaXJjdW1mbGV4L3VkaWVyZXNpcy95YWN1dGUvdGhvcm4veWRpZXJlc2lzXT4+ZW5kb2JqCjMg MCBvYmo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UeXBlMS9CYXNlRm9udC9Db3VyaWVyL0VuY29kaW5n IDIgMCBSPj5lbmRvYmoKNCAwIG9iajw8L1R5cGUvRm9udC9TdWJ0eXBlL1R5cGUxL0Jhc2VGb250 L1RpbWVzLVJvbWFuL0VuY29kaW5nIDIgMCBSPj5lbmRvYmoKNSAwIG9iajw8L1R5cGUvRm9udC9T dWJ0eXBlL1R5cGUxL0Jhc2VGb250L1RpbWVzLUJvbGQvRW5jb2RpbmcgMiAwIFI+PmVuZG9iago2 IDAgb2JqPDwvVHlwZS9Gb250L1N1YnR5cGUvVHlwZTEvQmFzZUZvbnQvVGltZXMtSXRhbGljL0Vu Y29kaW5nIDIgMCBSPj5lbmRvYmoKNyAwIG9iajw8L1R5cGUvRm9udC9TdWJ0eXBlL1R5cGUxL0Jh c2VGb250L1RpbWVzLUJvbGRJdGFsaWMvRW5jb2RpbmcgMiAwIFI+PmVuZG9iago4IDAgb2JqPDwv VHlwZS9Gb250L1N1YnR5cGUvVHlwZTEvQmFzZUZvbnQvSGVsdmV0aWNhL0VuY29kaW5nIDIgMCBS Pj5lbmRvYmoKOSAwIG9iajw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdlL0NvbG9yU3BhY2Uv RGV2aWNlR3JheS9XaWR0aCAxMDAvSGVpZ2h0IDMwL0JpdHNQZXJDb21wb25lbnQgMS9JbWFnZU1h c2sgdHJ1ZS9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDE0NyAgICAgICA+PnN0cmVhbQp4AXXQ MQ7DIAwF0G9lYKmUZK9U9QbtCXKuTnA0H4UjeGRAcSED2EOYeALzbVTnEq1xSLQcd5CXcsYDxNg0 r5q4AR0cDNJiAJo4CQ2xBuUolRAHCuEYyIR1gHeElvPsoZ9EWCbeBgxzLaM/0GqWVuOedqGuHaWr 0StnUzeCG86NLfscTsvX/ptF/ZmTc+xV/mn+1fRlbmRzdHJlYW0KZW5kb2JqCjEwIDAgb2JqPDwv VHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvTWFzayA5IDAgUi9Db2xvclNwYWNlL0RldmljZUdy YXkvRmlsdGVyL0ZsYXRlRGVjb2RlL1dpZHRoIDEwMC9IZWlnaHQgMzAvQml0c1BlckNvbXBvbmVu dCA4L0xlbmd0aCA4MDYgICAgICAgPj5zdHJlYW0KeAG9Va2SpDAQbtkyNi42GodEIpE8AGbdWGws cgQPgEQiccjRa9fvQ2zu64SfwM5dXV3tXFcBodPpr//j/f+mntyrIR+GeHkxiCUi81qMmrK64PIC Mi3LMj3AnOYTTR/ev5848zxCbIHcSTTV19DbkLd3qlOmnxScYwsIWSTESJ3jhIGlmrwvhZXwdaLO UT9g6zaqU95nHGACBhZnar1vE05Qi2wWCU+W6sBodFcTQSDvbXOw/RKOPMOAKSkG5JjmiJG4QYcf jsecSC+aWM8pSDT/wNBKq0gHhmYNpvAPPwyvcnsROT0WAK98I8EfCsRhpQtGvvHD1wUnzwmMsYIB Fyq5R90y9TE02plik7hg7PywHzHS0G75OIxcFTU0lVIK/PBfRmJpBr0pu2B894PpLzBGo/oKEDZD rEod8pV3ykqxb+W052ODjtbFnD/DOMeqI/XWAKL1n2XmTfYxGnhStwqc7xgUc65Zddh04j2qBAmX DGuU1Va7gScvsGpF+g7B6WvJqfA52XqWbmuRoOoJBrYkcxSmZ+jB4HhkJhgiJiTtgaYwgtF5vAvp 0uLD4P+Wye+3WGFnJYlGzHlkAIpTjBU6tEcHmyuI1cvjfp/adhxkNGYwMcT5knNxIZ4WjEsPEkbJ FqsVYm3z2fIYhkxWus8uN6LEDlY/zXnWD32gu4zJiFEMwpMHrBWj6scgNgzCA1U85wH3TdLDGFCj QSUFuvjxb3UlmgrbS83yDZbJt8v3Pvgjxu978Fy7wVpnJ8lCG7zXfXa06QVjx47H4DMyGdbbK86S Q8HGR2TNZKRHOgRqKJJTV4z9VpJ0xXyU87yAjefIebPLSa2t5FRfkjKKbJeljXvBoHhTSUBhauxB 8SUSA/h6fxyzHfI83SBZjva24cr3ghHURZ0IeVq7gblsGDtsekd5jPWuzeqez6WzBAtRZXGxGiwf YKQ9GHYQmNAGiVhyD8Lkkq2rMUAmdz88mRVjEmVwKCzi9YQ3h/uc9n+ZVyx3VCXy8rfSfkdFnRgf BG236hStA+8nVg/DMnJcjTC8jNo4zx/vL0OAYhlCP06/AM7H8UplbmRzdHJlYW0KZW5kb2JqCjEx IDAgb2JqPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvQ29sb3JTcGFjZS9EZXZpY2VHcmF5 L1dpZHRoIDMwMS9IZWlnaHQgMjQvQml0c1BlckNvbXBvbmVudCAxL0ltYWdlTWFzayB0cnVlL0Zp bHRlci9GbGF0ZURlY29kZS9MZW5ndGggMzk0ICAgICAgID4+c3RyZWFtCngBjZNBbsJADEX/ZFDI ClhmUTU5AgeoNKgn4QioBwCjHKzZ9RocIctZoLjfTqGBTfsFE8/PG2M7QfUfyh0qtNC+cbjjmpNq f/LtuFS9MMxnmE5S0lA985sbUklNY9ShZZhlolBGs/+iigdKmICyXGB4z/VENQapdjrUySmrfgQC DuESsC2wWaq8hP4VQ1mix2GFWkJeX9JYsLwt+oANg6ioIQvszUVboJJolAaBA2YjGIUFf8NFVqZ5 YZicaVWaDxLfHfE6d2eUVWC5TCeUfhWgqrAbUfGu5+OVJj/UCUUU1nEW1BUCW6ZIRStW7tSlYI2k YFR0ikk/vCWn/GkPdri1Y3W1CVcssGOu452a5rWcUS+4YokDqfcnKs4okDKxjTvlUx1/KN7jPHtS 2+kxPFZvZ1kXRUqyBZPYIyW+skyqtYUU8tqimcTjZ2o1I35DTvW2Ya4wTFR7826zF/PbHZc3Tjw3 bGGFgx/dl4vKX0n+U9JXl3RI3aeyaZpxSOfrWstjyo3mb2LrCMVlbmRzdHJlYW0KZW5kb2JqCjEy IDAgb2JqPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvTWFzayAxMSAwIFIvQ29sb3JTcGFj ZVsvSW5kZXhlZC9EZXZpY2VSR0IgMTU4PDMwNzVBRjM0NzlCMzNBN0JCMjNEODJCQjQwODRCRTQx ODFCNzQzODhDMTQ0N0NBQjQ5OERDNTRBODNCMzRBODdCQTRCN0ZBQjRDODBBQzREOEFCQzUyOTJD ODUzODdCMzUzOENCQjU0ODNBQjU1OEFCNTU4OENCNzVBOEVCQTVCODZBQjVCOTRDMzVDOTlDQjVE ODlBRDVEOTJCRDYwOEZCNzYzOEJBQjYzOTdDMzY0OTRCQjY1OTFCNDY1OUFDNDY2ODlBNjY2OTlD QzY4OTdCRTZBQTJEMDZCOEVBQjZCOTRBRDZDOTNCNDZEOEJBNTZEOUNDNTZFOTlCRTcyOTRCMjcy QTVEMDczOURDMTc0OEVBNDc1OTNBQzc1OUJCQzc2QUFENTc3OUFCNjc5OUJCNzc5QTdDRjdCOTVB QTdCOUVCQjdDQUNEMzdEOTNBNDdFQTFCRDdGQTVDNTgyOTdBQTgzOURCMzgzQTZDMzg0QUVEMzg1 OTZBNTg1QTNCQzg1QUNDRDg3OTlBNzg3OUNBRTg3QjJENjg5OTZBMThDOURBQzhEOUFBNDhEQTJC NDhEQUNDNThEQUZDQzhEQjdEQjhFOTc5RThFQTdCRDhFQjFDRDhGQTFBRjhGQjZENjkzQTlCQjkz QjZENDk0OUNBRDk0OURBNDk0QTVCNDk1QkNERDk3QjFDNzk3QkFENjk5OTk5OTk5QUJCQTlBOUVB MjlBQTNBQTlDQTlCMzlDQjVDQjlDQkFENDlDQkZERDlEQTFBNTlGQzJERUEwQURCOEExQjNDMkEz QjBCQkEzQzZFM0E1QTVBNUE1QURCNUE1QzREREFCQUZCM0FCQjNCQUFDQkRDQ0FEQURBREFEQzdE REFFQjJCNkFFQ0RFNkFGQzRENkIxQkFDMkIyQ0NFMkIzQjdCQUI0QzlEQ0I1QjVCNUI2QzdENkI3 QkJCRkI3QzRDRkI4RDJFOEJBQkVDMkJDQzVDQ0JEQkRCREJEQ0FENUJFQzNDNkJFQ0ZEREJGRDVF NkMzQzdDQkMzQ0JEMkMzRDhFQkM1QzVDNUM1RDJEREM1RDZFNUNCRERFQkNDQ0NDQ0NERDJENUNE REFFNUQwRTJGMEQzRDdEQkQzRENFM0Q1RTJFREQ2RDZENkQ4RENFMERDRTlGNERERTFFNERFREVE RURFRTdFRUUyRTZFQUU1RTlFREU2RTZFNkU2RUZGNkU4RURGMEVFRjJGNkVGRUZFRkY0RjdGQkY1 RjZGN0ZGRkZGRj5dL0ZpbHRlci9GbGF0ZURlY29kZS9XaWR0aCAzMDEvSGVpZ2h0IDI0L0JpdHNQ ZXJDb21wb25lbnQgOC9MZW5ndGggMzE5NiAgICAgID4+c3RyZWFtCngB7Vj9XxNHGg+bmG4tIK2I lxoFDaUItT3Qqmd9o5hai2K5omDqFTjr1jsD10K3p+029nTFjbYs7NIM6TD7t973mdmXBKlt7+eb zyeZfeb5Pi/znZednSD4f/n9DCxOTcyLIEAVFkgbsTCxLIInibQOZFQ27/Tn8/2f/dLQFKleVE9N TTR62Rb6QswK0pkRfzBqFIZ69mu2L9KF9vlUqtPlAaqw7Hb5k+g5lTrtialEuuvHSS5qqll7zNG2 mM+fp/q3C6wavGyPfyHmOMWtst8V7Dn31DNnq+1oPj8PBrfVNXvobmnZZTKBKiytJnsSPbe09Np8 KpGKNgutJaRVg0p7iDZgOp9LojlQKMFi3K5tq4obX4hpo3QuOjxG/5EHSrtc3UI0+n6yyoNtdc3O uzVtV9kXVPX0UjkCsjRN26OkEZClaTt6lPRp3M0uTXt5bLr8LpAXXRHMaNprVjLtmkM0STAoViLK mzSJ8CLMCrLRtL7fcpE4a3pav/TuwHNk9WvakM1EbTtdk3VQSKdfA1moektl0zQtG8swnU6fnVWS L2aAmDagMi0n5gOIE4a1yrLp9ABGCpic420ZseZAoQTDYuU3ZpbE/MrUmUekdHrn7xuZbTIQvrt1 GRbS6ZNyXW+ja/YwmMl0gixUAwtVxlGwejOZTHHJrSlpDgjDlqp4WyLEuOUJ0Q276nyhK5PJ5rtr MD0OTdsZuYdfGyyszEDTvSJZnMPj0RVybfNgk6RM9yLttmuDg1cF7OC9CbM2qse+4qSR6A1YfiHX UiNic5Q8HlWxNkbbMpn28D0gNW1n6jJUocAwDApcWETTtUFE6eg+L1YGlS64f5AcPaGk7w8WFleQ WptyNZjN5oisbHbYiih/ls1mJ+NdYQ4IM55SKus1IC4DIXyrbLpTkKjY/JF6yOqPkRF8dktZf4ip BDcoXfgRWQellM2eR0yEK5Bsc4XRCeOINapR9B8bJtkmGkx4PQcfQYzAjrMZorPfwGOkyFOPNsNY +VVOobJYcZt7yTHKlTr1nEreX8a/jdUxSiLKlxh7JFRQ0iViANiQrNN4KapCLm/F9NxGn5/bvIHQ v6ex4h7j84PgQO/stBiS2D9ysT2bfQtMUhr6ENFzriqol3pfDv/ZcYffh3Bs5B0IX3mCwlExPRjq ffvpedwRyDI3chEc0O4bFYxGzpzIZg9b2PeOQzhFiHdd8REG4tT7CHYIkWGqD5D3D7GfQqMPDAD1 litDlV2BLumniofxb7OrBag6OvvsB8BDR9n0DVCH/lMPAIQEYLYL6yj4s64TWaj6J2bmbt+eA5/P dF0/qiQsk9u63jUxBdVtuWhU2qOA6GfkVA0Er0/By7ThPEUjqnldz+MNC5+dY4a9V9eHbX4fqgvT 5iVUIOu4rh+btnyoJh1B4UBdkewaMBBKRuVv8Nwwrz/S9SHzS2REbRJhEcLig7r+vmHdQ5PJVvA/ Vlq6ouvtNhcQRqZNoNot9gSC4VJmp0qWD+Gm49VhOjBddpeVDqn1TZcrSO0yWEXbWZU1eCSy8oos tFO5y1T2SnJq0kAJ/S6YlEX8fFA27Z1Rh1I4zWFfQzxi/lHs85jhcPRvuMKvoYMl01+H2bjNkF/R rosCCZzIQkZVPqcwdcI4HP9LLn/an+9bQJ5hQR+KlgfV37FpJYglhn587DDen88tMPjJzVoexVog ftpL5upPEMq+JMshZrEXEI0ITxQMlas8JLId3EJCvodtThOlFHKMGQtkOLNgSgWbFWUfFpqz0TOG OM6a//gX1dw+T7s+MPmyy7lfxbtmAxyEA1BcYmQ/bNPw7TccESCX8YrH3KrPxb/gIiSrtISZQrkQ BoygGf/d3/OAO1ayCazBAvwjAG1aDYg6JkTXl1wIoGl4hmgiADzpE3Mw4RMnhyKy6jL8L2F4Cjts Yjcg3z4xOIs1DmXeItrzRlWpaGNRZFH1xgCVTx3J8QElhWQp4VhCluDut+e64FhORSIrR+kFwaNr 6ELsc7yCdR+RNUQzBJnRaAYbi+geCgQMKXUnIJ3spMSwGVLvnVkX9IIOi+yCJ8DGIbyOGhE/SPTV FQHC0JlhWqaoJ12AKDXBHDucPRgOhIcSZbwiKUjIkvMLCT4DTaacozCGQGPUsMEPqHMWhpH2OHnO WrKcOu2G2I/UEYy29KjUXOuftPXl4ZowRNaafM3gbRW+NCgX6IbsGnb7IdkBbN4wuAbDbDs2dCIr NKZcYgxm33nCZLNXE64I0X9v+QmsddPltQQhOHZ9KoWfQVLiB2Rls++odYz99xkQmCmbeDWE4Yks gqv3jOEjmSzxQkjTgzH1S5o1kTUUn7NI13DOgkF4zqJTUVIEZ14/+fQFXrHkdAMvlraBT2+RJI8j RBZ0QxVJFi01ZIY3HXH1+ik6A2wlK8KA0Pp377QBl/0QZqrQKzUqN7BpNSL4d+ckutuj00BE+iSd a/bHK0L22hWjcHJgRIbfQpbbQFZb2d9KVnIopYGXRR5K4w8KOpTSrGksaMvQ4S5YxANeLxLjC0g7 8TZ8EPuUZGUyQxYrZDJ9FAAHPtq8M5k3phf8fgiYWVEAHDj3y9knMfDuWjdycBkf1x8hWlSGaeFG CFAbBH7l80PQfsWOIiKRTrHcqUxG7rVzczPquI19Cai3p00vDz2RhYM1Zhb12nDX6R8LVSblz6jU pArxcNbfjVmAir6PEBKFPneSQyk+ZTpjHhUgWATCJm4JinkNzG5gUB3AHP4BFgvSZxG5oHHAYlfR toSjCvBFh+P/Exwu8uk0kUUp0GhIDLxCO+6uFApX64z9BCH+mhvFhw59vw60wZvzNEGYDM+csbqO zN0piqhi/dXB91EHzSz4wZ6Ffyw1/M8iPCqEDwoyQSF1LjXeBFnI+vUFBk+UmlSBrH71bYjqZHwo JV1yKIVZrhqdGUKyCHF5Ff07k06/rMjqrHhEVh8op06DOvhMyLoDiwoT4DEk6wtsuhAwKHD2miSL hgAYcl6sLqfTdOamTsrdnyLr6fQ+bJ+W/SFa7ccJouyhwcXmRjGdr8EP7kfW0ukds85TaP7tiQ3w vCBpMly4TiM/NKUnQRZshpE1hUVXIF0Gt+jY2yaRRalJFchKbh125rpl4YJuHTryUrgiBG4UduSU 9DTetNrQ+FmtBp3Wi2VImFvfCLqguMfJXPtY3mRIsjQNs3wdbYd+WsFthYaZhf/DrD6I6vVvCb9L krUBORdibMLcqwd34DIiCzcO2okyfcFSiIu+RIhFIMqrcHydCUKUbIZ7iev1X+D+TzBFqoeZFHB0 gB5LDf+n2TrlcuDbWoBbh467j2WvAUfAjqoUxqw6OkSpSTMiq6WlFcswuc9qsRvvs3Y7jfdZt6LJ J76mWyVZXhnDIC3KR/+BatpBlc3hc8Sq011Xr+nzo0qH/xG7HoYj4JC/jCs1SZZoxLB+KHOd+HsT oyFn9B0IOCLSMywP2IcaEBN47ujA3z7DYZ+hpqIhNx6nekHd1BF/Sk3hJ11xnKROhjRaoKvvJBEF jqjvkiyIkIJcKvUKjpOoomJUH0SP0C24lxLpbHT5J+rXw5vS1jEcd0WtjUBl5zBV2gev4t+odqZS Z9G1iVSqBzl7u0i3p5UavcfSes8Iqh7rbirVqsjyYJJKvaowq9IAAPCjyMJ17kuzci8Xh/BYrrxM cInwvf3qed80YtVOS+GlCwaOPvXrUtCOGDanns06TIXfdwoSuiSlVkoDOs6/V173wJG4olJbVirh 2+Wy5XNUxqwshul6VTMUZg3L9Z1INbsQf9IKz57s7ek5MlbCZ4oIuHujeLa04Li3enuOlIyFm8WS 6bh2mZTMMcvYErj7cW/PiZJhGKbDmPNeb8+FUvkfxQ+MiguAfOE1Y2ruDUSARfQyRMxyKAi/grSr 1c8jBOern79N+Rj4RBLc/wrCiVKZzv7Cq7wHTcnAlUINPcMBjT1U4W8WPwGEPZwcOYusHNLh9FpF 3DfHZoFD7guUWl2awRXzvJoAxPdXqfg+QzCmhFXfq3FR9xpUcj3gDwk5lmXZ6jZccM918AXDWdXG 9aHnuy4JDL6ADCsycFwf1xRC1FeBq/oExBbEmHqBKKcRJoyQXNZRkuEkQ9pIlHuOjRwkgnsIHT6j Vy4EB59UlKoUbBcnajoaNocHBFGrjushDeiinimnhEdqyizq+v9SIwg+RNQCoZTUI32coC1pT1yT QdwuBTJL9PT0HCaxaAaGUmMOjc/o39ZgTZHC8FE6YfKRU2n8fLz/AjSC5j1lbmRzdHJlYW0KZW5k b2JqCjEzIDAgb2JqPDwvRGVzdHMgMTQgMCBSPj5lbmRvYmoKMTQgMCBvYmo8PC9LaWRzWzE1IDAg Ul0+PmVuZG9iagoxNSAwIG9iajw8L0xpbWl0c1soMjAxNjA5MjAyMzM1MDYtNDE3OTItMnl0MXdx bTIpKDIwMTYwOTIwMjMzNTA2LTQxNzkyLTJ5dDF3cW0yKV0vTmFtZXNbKDIwMTYwOTIwMjMzNTA2 LTQxNzkyLTJ5dDF3cW0yKTE2IDAgUl0+PmVuZG9iagoxNiAwIG9iajw8L0RbMTggMCBSL1hZWiAw IDc1MiAwXT4+ZW5kb2JqCjE3IDAgb2JqPDwvVHlwZS9QYWdlcy9Db3VudCAxMC9LaWRzWzE4IDAg UgoyMCAwIFIKMjIgMCBSCjI0IDAgUgoyNiAwIFIKMjggMCBSCjMwIDAgUgozMiAwIFIKMzQgMCBS CjM2IDAgUgpdPj5lbmRvYmoKMTggMCBvYmo8PC9UeXBlL1BhZ2UvUGFyZW50IDE3IDAgUi9Db250 ZW50cyAxOSAwIFIvTWVkaWFCb3hbMCAwIDYxMiA3OTJdL1Jlc291cmNlczw8L1Byb2NTZXRbL1BE Ri9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXS9Gb250PDwvRjAgMyAwIFIvRjQgNCAwIFIvRjUg NSAwIFIvRjYgNiAwIFIvRjcgNyAwIFIvRjggOCAwIFI+Pi9YT2JqZWN0PDwvSTEyIDEyIDAgUi9J MTAgMTAgMCBSPj4+Pj4+ZW5kb2JqCjE5IDAgb2JqPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0 aCA5MzUgICAgICAgPj5zdHJlYW0KeAG1Vl1zozYUffevuI/JTMGADaZ5w43TprPJsran+5Dsgxau bXUBEUm26/31vRLgj/F2SidT22CQxP0499yD3gY+ePT1wY/NLysHbxCEoWsGPQg8dwQe3Ux83/XN 7PDRD+BewCdaF4/dSbMsdMcw/tmnxRMvdqN2odcsnC4HnhuSueNJrmH4MAbfg+WKDERx5IZxDMvc +PJoNLt5RvWLKGGOmShLrHKmuajU7fJPskUrTidrKzzacoIx2bl5nM1mziKBhWb0rMwVTAX9wTPu z8bIQ8m1RoTX1uHr7Q9dgkNZk9mXRbKYAqtrKXasAIoK7yAInAXWTuD50RcT4HlqbTgvSVHATmhU sK1YxUuxNVcFKgUVDecg9Ablnit0WxtXKX3mepNLtie/c3zbotItHNfQRi0cowgcOlo8gNKttxol LETGUR+GfwjNqzUsDkpjqX4ETG/AUz8KAte/yr/BrSsDrIQE8koxzHHNlZa2rnDPNIPHisazDavW CA9Clkw31iZtNo7XleGSFXeQ2IIgpMkc9ieYXm8i4BWs2E7In4jiErOtQnj5nVX4nWdfXm8bB2dQ N2g1yQR9kpkVmBlqUj5qW2hF/7WQFtZeSf0/OZ1azV7ZHulIQR7PODGr1rxClIYHhNUT5jyjAaC2 gSkXhVgfjnQxTQW+701G76SKMUH9Enk+u8T4VOLfkBV6Q5wgxhATeKYcJ0WpREX8byfvccczNLQu txXPGio5kDKpSbnIumVG0c2kUqx4gQ58rDUv+XfqutlfLd9oTotMFCacY0kSIzx0aGh53THxuKIf Ea3Ro/j9W0Ueq3xLjXEwrO5ip95sW3aJ2cbkWpCgiW+Kkhcy5xXlTgU86lnjsYdOpiPS28saXCdH QKWSEc0JbNPAJFVwzhuxojrZoDnFZZhjAqFeNrep2BvFaSSm8dTBeKp2fxyHD123Gha3TH4SOV9x E2Yyf7cofkieh0/J8/soHnuBO8q+/gOyF3I4M8pfoYYj3e4g3RyULfIHdjDo1ZhRgg3DlUX4iVVs jZacxHdWImmnstUJ3BB+/TpsljWXlg6deH6ssVVdsSPbU5Z9qwtSxMvaXLPAttdJa8szzJtHu8LQ o62MGhT80J30gWGxIdl05lb9TYMain/mEu078qLFbYWHDx2L/nOk/cWR3F6+MLvCKUioHXZcc3qj 252FhbjPziQd0ccN3PbtQrsu3+yCQhqM4zE4QbcXurGiM1sOPg3+BvC901xlbmRzdHJlYW0KZW5k b2JqCjIwIDAgb2JqPDwvVHlwZS9QYWdlL1BhcmVudCAxNyAwIFIvQ29udGVudHMgMjEgMCBSL01l ZGlhQm94WzAgMCA2MTIgNzkyXS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYvVGV4dF0vRm9udDw8 L0Y0IDQgMCBSL0Y1IDUgMCBSL0Y2IDYgMCBSL0Y3IDcgMCBSL0Y4IDggMCBSPj4vWE9iamVjdDw8 Pj4+Pj4+ZW5kb2JqCjIxIDAgb2JqPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA4NTkgICAg ICAgPj5zdHJlYW0KeAHNll9T2kAUxd/5FPcRZwwkART7Fvlj7ShDDeXJl+3mAluTXdxsqvTT9+5C grSDhbF2qsIgySZnz/3dc/NYC8Cn3wCCrv3jWe1yUvMbPn1Zvek5NIdtCHyYzKB1BudhGyaJO4G+ 4vXYMJkwncBMaZgsNKLXFxnKXCjJUrivt/r3J3CLieD071TkBUvFD2bo8MnkW605PN9c2wcvCOnS 9TvkKqMrJO6kDxAtl1p9R8hUImYCExhHd+ulne1SUkZLxy36aYSN1vp4Kbu69HFi+8wwuGWSzZHk mPeT2/4rcmORFek7G9s5ROmlUF4v6sNQpAhDpTNmHB0lBHspGWshjZDzNzrtNzqW4PLNEXz2KyrX g8EArmVudGGL63wDQplQZXmhXcUhVlygWTUnvQvwICaqLeTIF1Klar6yOred4j65m73g0nVLfRx0 ut1DrGMw1siFbR7opYo/QLySfKGV3PQMHVdGcZU6R0donpR+oJ54qdruoqek0XRWvMoNZvk/c3Ss nlA7HwcS9XxVWThIkRstODUUXwg6doR77da+hq6ywsaCZtwIjs4ZquymGaheuYUK1AyiHvyuA56E WcBHMV/AVKWGuh3uCAdaUSzBKGj58DAFYnhKouFGPVkzvSpThhofC5Tc7WcbZ9sTKo1/yLMtse7T K9juNTkuNKm3iJDZgjKzj9/JkbxJqsvNHQ5t7yxsdC52sd1uazdLyWNi0CxUkrvqE8Yz1JrKMmVp gbkrSixSwYns8cj7VEhS6Chn2dKa3Rcqwf8A1Jhw4Is5Mn2EU63zRug3zne9qhC5KkSyxrJkcXsT yxq59MWh1gktanaSXkuD2g7QSHPrzpAVqXmrO81hmUwezUv7opk5eDbraQ13FuR8fZfXYNyudSEa oVb5klHj2eBZ9xflFS+zp4qAq5VWEHGOKa3IkDYIYyYxPdznILzYlwQVjvGSAnRGTxsOr834WVfA 6rMVsB3CMaGUd17fUBwxfQoxGZ2iFz2L/BRGSnpWcM7VkvayI/vYOriEoNvawjIJWDle0LhLqUk5 Zl/JjdAP3JR4zXyCal03531PZcvCGllOqpto1LyNRlDakdMkyDJhDOI+m+nZL7APdx16dOp22+CF XctFaM8fTGqfaz8BadcEZGVuZHN0cmVhbQplbmRvYmoKMjIgMCBvYmo8PC9UeXBlL1BhZ2UvUGFy ZW50IDE3IDAgUi9Db250ZW50cyAyMyAwIFIvTWVkaWFCb3hbMCAwIDYxMiA3OTJdL1Jlc291cmNl czw8L1Byb2NTZXRbL1BERi9UZXh0XS9Gb250PDwvRjQgNCAwIFIvRjUgNSAwIFIvRjYgNiAwIFIv RjcgNyAwIFIvRjggOCAwIFI+Pi9YT2JqZWN0PDw+Pj4+Pj5lbmRvYmoKMjMgMCBvYmo8PC9GaWx0 ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDg4OCAgICAgICA+PnN0cmVhbQp4Ae1X30/bMBB+719xjyAt JaH8qHhrIR1IlHU0Gpq0F+McqWliB9sBsr9+Z4emdBWIMQEPm1pFqXuxL/d9d/fdTSeCkD4RRH33 5UVnmHTCbkiL7UVnsDXahSiE5Ap6e7AfbUOSegNa4huTfrjdjaLN5LqzNdp5sAsh8GYbU8tkynQK V0rDiaRrwaxQEhLkM6lyldVBkGCOXBVFJQX3/xqgp1bM43s+YzJDGKK9Q5QwrY3FwsCp4ix35s6B 9tgxWq1KlQs6HgYaGZzRc0rPTRBMS+TiSnA4x5tKaCxQWgMTpi1E0QFc0FKOhnYenMEYU1EVMODc rRwqSdvm8GNjPDj8semdnMxqQ17nK8efsho1mU2Ov5PZ4sDm1ZpA7f8eqHMfAaRgufAcwKAstbpF 0OQkGuvjR++C9xalcQGspBU5HCHH4pIO2w6j/WbrBVYBRYPwStIFRGzWGLwGJAgIsdejFKzi5Fxr +PE0UHTiInCrSAXvhxXBQOxIHUPIm+qSMuXz8U84FZxAwCC+x6K08KVE7VF7N2jXkBX/kf2zLFxB dsQowU6ksIJKyamQc5iircqPg/P69XD+XZ6uVNOXZOmHl1MqE22OHkAsqUtQRfQl3bWcb6hrOBbZ DJKZVlU2KysLVlEyl6Wiin84ExINwljkuSjQUiW9YLfo4t/WqJGvwZLXMKQ+Y96OFv1m66cL+Pwv ePFvddknSTEiUiSaUQ+1PtUNNXxLJIChFmmGaSsUPhDmm/8wP0q/58TUY5gnGoOBMYoL34zhSBhO CkrX74bkb215t/uQ0GuCq9WYL9eX8GwYXKmbIBWvwR3TSEJ1RUyTEHV69e3i4JVn2N11c8Pi4ueG vaXMbaToSRzHzj0qw+TtlMBCW28tpgRDStuKW2rEaGCoaG5wPi9nEX+3MpBQyLd3vMaN9vph90Vj SCxvhVbSNQnq90QZ0vbuB6grCqI2StJy6+NEq7Ti1nwihcDzKhUygzNl8VKp+bo5mR2hmVvl1UPb Qta2JbtpzixuJewyR7f7tGB5DlMaJZDkhybiukWRSUZTD3G5zFndzEVrm8FYkXhR+q1b0xJcf/cM wrHMqK+idsGi2upozmnBT0xD4ce+FnxPiSgK93uw5IFjsLAWm07cDqNLAtDAGrmJdLfX6/b7OxDs 0DSabvQcYeKk87XzC5S5zLJlbmRzdHJlYW0KZW5kb2JqCjI0IDAgb2JqPDwvVHlwZS9QYWdlL1Bh cmVudCAxNyAwIFIvQ29udGVudHMgMjUgMCBSL01lZGlhQm94WzAgMCA2MTIgNzkyXS9SZXNvdXJj ZXM8PC9Qcm9jU2V0Wy9QREYvVGV4dF0vRm9udDw8L0Y0IDQgMCBSL0Y1IDUgMCBSL0Y2IDYgMCBS L0Y3IDcgMCBSL0Y4IDggMCBSPj4vWE9iamVjdDw8Pj4+Pj4+ZW5kb2JqCjI1IDAgb2JqPDwvRmls dGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA5NjUgICAgICAgPj5zdHJlYW0KeAG1V1Fz2jgQfudX7NNN OlPABgJc3wIl18w0DRd8uYfrPQh7AfVkiUpyWu7X366MDSFlrjDJwHgGI1m7337ft+uvjRgi+sQQ D/mb5o1R0ohaEd2sL3YJ7etLiCNIFtDtw6DTgyQLC+hWejGN42jQbcYRfd4kXxrt6952cQTNuENr L2Ze6EzYDBbGws3srr235V0ninpv4QMK5Vdwo2lJLrxMHTRhaqT2TbNojoVFuMVMpkLBe3yUKcLY 5Hmh6Y6XRtPiTyZHnSrhC4tlHIPDOO4xpU1IsfCed3C1XlvziGDxa4HOh/CEBvzuUTt+aqG95ANT zOdooRPFw/LRFR6UIkFCKW5RoBWnohC2vBgKlJLaYsKR1iWYWrOQCgmnkXAIVUVeGaiodclUqi6B Sv1dVUrobiaTCRU+K5y3G65JlYCDmUkl+k17it4ahUUOv8B4hXngQbUl5FnTNRD3CWebBELg7MW0 d9k6xtGaG5jB1IqUKIiBEBOFqbfbE50XiihG3HBA/Jit5HpumNlNYomTS/0UUD66lED9+POpNygT rcAMsJ6NaILpisWjYGTMP47UZGwmNUWnl0Fa0nsMOto5wXNod8h2oyhudcrsn+m/Tv4Zto9CFeWZ foWwB/UMbVD5PUlTWiTRekJ8UfFEUuDkKSFStCn/nJpvJNHZxnnM3WuXYeeIBMHWAQIE8QG/fsCA QxD2GM8Zjo1msiu0LqR4VXjDjkh08+a8/F+chUfS77e29vjzDLjSQm3+ZdLdo5JiLpX0G3gvvCjF R9Vfc/HhD0e4SX0eAD+owvk6HMLniz6HshCPxr6l7mnWa8Ph/fWn1M4b/ffnN6dqlbyv4DzLQjO1 b1E4amUh+coHk3Hnkqym6oS8bCSNMsug5L0dQQA/p9x40DngbE2XqkuEUtzNv5ARSmqXe+cwYUvJ yRSurEfLUhwpY9hF0XEGDNWHIhf6QJX1MbU9nF+TE72x9AqGb6LRLjd1o7nRriB/p1qSDLMi9cae AGWvd8wBfytkVraTmaGJIlkhTTmKOO+kI0yZ83uovqJ7HZ9fhoNfj9h3wkVtkgBhl8aEZyRqGEtg 4/4oF8hUKHEdi7lCx2Xn/64lquxpRi9Z+ZDQbsT4v654tPKzwi6ROGv8luXlmOnaH803eDDKi+UJ 7XDc77S63SN4PpFVwoPnLfqVyUq/n6INM7Cm+eOB2iMhScjSCqrB3Xem0YOwxBoapZ/FTDPx2mju la8HeJBa+5peGGJ+I7jsdlvDYY9GrCHPwT0+eJI0fm/8B6xbzQxlbmRzdHJlYW0KZW5kb2JqCjI2 IDAgb2JqPDwvVHlwZS9QYWdlL1BhcmVudCAxNyAwIFIvQ29udGVudHMgMjcgMCBSL01lZGlhQm94 WzAgMCA2MTIgNzkyXS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYvVGV4dF0vRm9udDw8L0Y0IDQg MCBSL0Y1IDUgMCBSL0Y2IDYgMCBSL0Y3IDcgMCBSL0Y4IDggMCBSPj4vWE9iamVjdDw8Pj4+Pj4+ ZW5kb2JqCjI3IDAgb2JqPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMDYxICAgICAgPj5z dHJlYW0KeAG9V0tz4jgQvvMr+kiqAtg8ErJzAmImqUpm2djDXrgocgPasSUiySHk129Ldnhklp1k q9hKikqELHX39+j2Uy2EgH5CCPvul+e1YVILmgEtbj/0AlrjHoQBJHPoXMBl2IYk9Rtoidcno4t2 s9M9S/6qtcbdal8ADb+tHlsmU6ZTmCsNCRoL92iXKjVA6zBBTes5kxxBzeFOrRtTlVm2QJjVw4Di mILODdCzd2jM7AziQtOXE60sciueEa7xWXA08N1gCkq6MHaXI1fu9g1cC2O1eCysUBLijbFIp87q Q7RrRAl2iZBoJo2LBumyvUAS1LmQLCsjdjvvhESIRepjdgsxahfEwd2RtHQg5RU9FWKVo7Szs7JG l+9r9EBh5rQjZS6832CwWmlFqWl8KlzFXOmYBHyxKI1LoJBWZJQ5x/yRom0H4WV59BtMVAFCKklL cLrHwPlauCTc8S4LujYT3MdwDAzCxnwSECpOBcJBef4XQGALwoRJzE4OQNDsOeW8fXjlXOzQLiG5 jaIIJmpNwDkJRBL1YgOx4gLtphUXj8Z6DIyv11aGXpAHWiSQ210Pchj02iUBftLfIcTjQpJqFLEZ 4hVyMa/wNqU8nQJyYTzHSLhWcNKK5EutpCoMjFS+IgYyS4SZ1eNkkIx+v3eaLPVURnAKdvfLo39m dzvoBM0wCH+Z/DUasZBCLoBBInKSbJWXeC0JX+bgy1Bi8w6I1vgUiXnZ7gjj//ovrNnzrk/QZtS7 bIbtZjc4LF9j55/75v2NvFLpH+eQLDViY7Jk5sA0zTm0e+TYP6YDT+w4Z1mG+gvciMUSKls/h04X 3K6p3zPETK2/OLvdbnCxbAO4eL+TUFmzjX92yorMQrJZkfnP6neCbDaFW/JRTZ3g5FLftcQ9r3X1 7FZW/C9KHHCOKyotNQfnAPdMSHL2tyb4jdlCk0AjalIabqUpMqIoMbdKUcj9VuXhPg05veo+TM5G PIiHZBFKp9QtfcDkF7mwFtG04tGocwUNSoeScl97D9puoMYNUUYdXaucLSR652FzMkRPhw+Z4Oiq 1zxmBAdTSOwPpoHiGampr4VdwgMaskMLVsFNQeMIRC8rZQqNbqUMTPBzQqqKzRv3u3jHArOURBDA zat7rBN4Xe3U9PXmtRTaKZzkqEW6snQOBb6V13bwoNFpohm1BqKkGwfukbns3dRSjj3O+ouqL7nh 4FM1gT/3anyg73+sd1zwJexXs0GlhNNX78NUh+8ZzXZGScEJ7zFqrdCTgf73ih77yU3yDemBxkBF 3bZq7775f/rxX4nAcextFOj3ro6gfSCCB8zYi9KNIbl4SsOsXGQII02d3E26jgO+p6QFr+aUAbeF 7/x7Y+IJzadyUXotCd17R6/Tafb7XWh06Z0jrfdcilFS+6P2N5Lh+q1lbmRzdHJlYW0KZW5kb2Jq CjI4IDAgb2JqPDwvVHlwZS9QYWdlL1BhcmVudCAxNyAwIFIvQ29udGVudHMgMjkgMCBSL01lZGlh Qm94WzAgMCA2MTIgNzkyXS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYvVGV4dF0vRm9udDw8L0Y0 IDQgMCBSL0Y1IDUgMCBSL0Y2IDYgMCBSL0Y3IDcgMCBSL0Y4IDggMCBSPj4vWE9iamVjdDw8Pj4+ Pj4+ZW5kb2JqCjI5IDAgb2JqPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA3NjIgICAgICAg Pj5zdHJlYW0KeAHNVk1z2jAQvfMr9tQhMzXY5rs3UyBhplAKXDqTiyIvRI1tObIMQ399VwI7oS1J kzRNB/AYWZJ339v3VrcVD1z6eOB1zZfHlf6y4tZcGiwvag31UQs8F5YrmtvxfFiG9jmN8OoUtzAL 5tnZ8hutbJmVxcWubB9WNtrg0G8ZVsfD4RA+yjjNNSpYSC5Q7+qfgml9EkxhoVkSMhVmZkostEbc b/1QUI7fNDvPuq5fa9R8s6A+apYxOzbmarE1rKSCob5GlaCGr8H0HAZMM5jIECMY4EokQguZ2Jzq o87P+8yRU2hIYZpZHyBIUyU3CMkeCsgTLcw+HOMrytB3ffcxdNyHwVnIld4yhfAOFrtMY5zBMFmL BFGJZP0yzPx2p3UCsAFuPqcZOOULLHL9XEShee0cI8GuIgRiDBbIcwqwCG+c8Ci3swidSHALFdil 72HG+A1b79cNMI3kjtDU+yAKtB2CZE/bM+G+X7SHyps1Cy4eq44iDZtZAf59yB0HAsWvhUauTd4z JTlmGf5HNVMKKeBabKiiMYO+JGnti/FP9OS1u27NZyfK41hPyUYomRgiWQSBgSIzf0CuYBwzKtY1 DG9zkdrBgK6hvfOOaX8N1m0WjRdnscQINyIzxgCvFv+de9q7Iwv9xSTiPDkoKyt9dCa35DmfyBus gd7NeALrPderHXh52EQnGIo8hpHC2xwTvoPLakS8g75mCXgtmFx8vzyDkyFZO1nETGk4VyI0RlpY xVvq6HewFrWeka9vMJL7Mn6qnHpet3Ya2guWasGJthB5ZrGhHgVLRvIlkx0n1C6pYf0DvfT800EW QOy5O1ijY5smhjBFvZXqxoj9sroYTIn9vpQ604qlqRm1PhmSY74ZwcOILFtJsiQC08Idp9SdrkQk 9K6UUZHmMd/POJJ43V7nhH+WjY2AmylDM8eS9jlmMsrNAcM4qJWQY1V9zlJnKkWG1H9TqfRfBrI+ oqOgZ856rUaj1u02wfG75nDVNlkMl5UvlR8b4AXIZW5kc3RyZWFtCmVuZG9iagozMCAwIG9iajw8 L1R5cGUvUGFnZS9QYXJlbnQgMTcgMCBSL0NvbnRlbnRzIDMxIDAgUi9NZWRpYUJveFswIDAgNjEy IDc5Ml0vUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGL1RleHRdL0ZvbnQ8PC9GNCA0IDAgUi9GNSA1 IDAgUi9GNiA2IDAgUi9GNyA3IDAgUi9GOCA4IDAgUj4+L1hPYmplY3Q8PD4+Pj4+PmVuZG9iagoz MSAwIG9iajw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggOTk0ICAgICAgID4+c3RyZWFtCngB zVbLcts4ELzrK+aU8h4kPvRMbjQtZVVlexlT2ZyxJMRglwRkELRLf58GSImyU0rsrA8pqVQ0AQM9 PT09cz8IyMcnoGBhv1k1uNwM/NEUL48/uiBvNaPAp82WxjOaByFtcmzwfbzKLtbL5ZIS9cg1MZnT UnJd7ClVmeBm73V/XvEHXqpdxaWhd93ujxxbmRFK/rH5F7fiuP7H3TrtbvVpGE5w6UUSzme+3e2t Jv2aA3TxsRE5p63S9EUAR4soKRlujFVZ8sxgKd3Xhld0xWtRSLc54bpWUvKSUrYF4vb0+fPT73im KsDPHeAPFO12Wj1wkvyRkuiOGmlEiXMzXv0DJkI/dDh7Gt3TEy4RFehEVD9m8LbJSs50F9BSFkJy roUsXsHa5Cxrh9NXLBOlMILXNKS1rI1ubLJctLSudkoby+RGdTRhV7qz2Vw1oC5Rqnz+X78dka0i OgXEyGYjReYCrF9OZfx+PJq2oX2nwBQU5Uznra5cRVwjWRQzrQVEsdFM1pUwhmsPeuLiAS+X941o 66KpeU5Gtdu2WLoSdaa54bThJYfcDDSMaqEU2mWlA+2tfiOlpo0uOCUdUBQHql5kvPau1SP9rUrD Cv4KpmfhaBKOZmfI7svdfOW2HMsumaS25JAMT5Ag3TslodeaBAg8A7Q1sGNCEojelkPCtKEZ/SmK rw4+DVvHWWl+33CZwe1cRmhdq7KtGJdqeFEFd2kDeKs8easTV2z9I4lB1ew9O8PUE1lasrrwmWYV 1KVry1gHXRad/Fro9NlqEozdcvOo9H9wnUNSn3EVWW+0jvHBohjC21qOojyHq0C0uCMuGTROk9EU JmIaeD8Oj5UGIrirLZ298257Czjv0L0tfS825GEapZdAp3QuJJIKTNYzbPVC0WkcjwNII2qMqrCa 0Y2lku44w/bitBPeMAndW2psJH2Hc09n2lww9ycvyeZnNB1h9rDevIFl79F98y5BDm3vcHSj8qZ0 5fd2ntFr0XayrpuhG9bOAa3U7uAAdZf+gw47t/3hkHHaGW3tNpbcw0xxHd16N9EtHQ/sM/Mziq0w u1Fi4Yej4NNLWL5WGStdSpFkrXYKnDNJkebsUBj1cHipRV6gfdohqH3Oj6vtLQcL6Kvj3FRhJwo7 yVgK9QmFjOpDj/nfA8d3tKZqax4ZqvFdNybVkNNx2vgVtnuyw9k0CJ9y3bPgrdO/vPUyPl7hYm8b dcvnEdopoOEQ8oJZa1dcreaizL2Ap9k0pI1tCweHk9aPW3vGk1PKwaVgc6/26V/PkbfCtB3YcXo6 Ho8Wiwk0ubCD4NyCWm4GnwbfAP6ghUllbmRzdHJlYW0KZW5kb2JqCjMyIDAgb2JqPDwvVHlwZS9Q YWdlL1BhcmVudCAxNyAwIFIvQ29udGVudHMgMzMgMCBSL01lZGlhQm94WzAgMCA2MTIgNzkyXS9S ZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYvVGV4dF0vRm9udDw8L0Y0IDQgMCBSL0Y1IDUgMCBSL0Y2 IDYgMCBSL0Y3IDcgMCBSL0Y4IDggMCBSPj4vWE9iamVjdDw8Pj4+Pj4+ZW5kb2JqCjMzIDAgb2Jq PDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA4NjggICAgICAgPj5zdHJlYW0KeAHVlk1z2jAQ hu/8ij11yEycWOYzvRHqUmZK6wamJy6KvIA6tkQlOSn99V3JfDQfZOglk04yxJGEtfto9b77s8Eg ph8GrO9/Rdm4njXii5gG9x9mCZcfO8BimC2g1YUeS2CWhwU0JJpZO4lZfDb70bj82N4uiyEKq5qX 4+nXy3E6hKnjKucmh4U2MN1Yh6UFGoKpXrh7bhBStZQK0Ui1hCiCgREr6VC4iuY+oBVGrp3Uqt6o 93ijGxS6LJH28Ivew2C9NvoOIRvchC3dCsHgnbQ0C3oBHOwuoko5WdAWAstbNJDEScgmvuh4DLuP gKF72JZIzPLmOE3TB5FLBRPMpaBUQnrXUhd6uaE0hUS3IRb0BcbiXmuPxMKQQpfOIfrkDuTD0wP8 xDVp+32z8IqIUazsCPpPyAu3grEi4iVRERYiyLRULtKLaOiRh0i5z/1OCgxhVEqKgJAWf9Alp3z2 byByE51j8WpHcKg7SrwGvk+8HXcfJh7ti+5p5lGUobFaUa7byWdTzrhxdML06vc7JtM1CskL+TtA iaJrbqWAtKDCNFpQQUu9NHy9Cie3q/p5Mx2O5mcwb7IInIZWVCDPIQy+DXjs6iG8l9jBKeyotLbw 2NUxeFRJtiqoorKqXL8NDknndA6n1dABRNI5BiIaatIcVenKwqiohLb1zd/Vz0Qr6Ugn583haDI/ exuoeqcLzT9etx47CmqsclyTqqNy8FneeW8YCEcPbuOpHMq2un01SgdPCE8vGEOm78lQvMulCs1f LrD9l0QIC70m23LwjrTZrx4hLQ1iExLc2/BLZtBO2MWxQt4bI+aQGU7wSOm9Cae/hHS11Nd+XIu7 DZN1LNtx8u5bWRBysqwql2j/K9RBqkmzJ5waCmJbF85JXFm3ewzrqJJ5zdF3Fjd4L+mUqa+YbpRY Ga3C1a6PUht7DtRGfPodSqHrn87hhjs6EQaT74MwPLilduXVwD7rrH2W1AE8aeMO2c7QknItvSeU XPnCnfClQv8n4P2vauNLJciYzfbm/dWAnn71Wq1Hbcheko5ePHJBx4siXL1z74nUYvim9TzUwQ6w v6LDglsLLK0DDGudqbxcbL/spcV7idEFpD8rGaSkPkNq6Jnv2Dut1kW/36bGse8bx76fTWeNb40/ aD6jEmVuZHN0cmVhbQplbmRvYmoKMzQgMCBvYmo8PC9UeXBlL1BhZ2UvUGFyZW50IDE3IDAgUi9D b250ZW50cyAzNSAwIFIvTWVkaWFCb3hbMCAwIDYxMiA3OTJdL1Jlc291cmNlczw8L1Byb2NTZXRb L1BERi9UZXh0XS9Gb250PDwvRjQgNCAwIFIvRjUgNSAwIFIvRjYgNiAwIFIvRjcgNyAwIFIvRjgg OCAwIFI+Pi9YT2JqZWN0PDw+Pj4+Pj5lbmRvYmoKMzUgMCBvYmo8PC9GaWx0ZXIvRmxhdGVEZWNv ZGUvTGVuZ3RoIDk2OSAgICAgICA+PnN0cmVhbQp4AdVXTXPaSBC98yv66FQhQHx7c8IYsqnCKYII ueQySA3MejRDRiNc/Pt0j0CCtV21ycFbLlwYNJ/9+vXrx89aCC16hRAO+S9Oa3fLWqvRooflm91C c9qFsAXLDXT6MGh3YZn4CfQovhEOvuSxQmFhKmKppJOYfVj+U2tOB6dVLQjCNi26WWBs0hR1Ipw0 +i8Y7ffWHBDmowVsjAW3Q7B4kBmNgtmAgMwJmm0TyLWTCu4xxnSNFtqtdosPaTV6fNnzm79svzqW 7kvHfp5MJjA3T7SOdoOJRrs9QmRiie7YLAaiY+YwhZEW6pjJrA5jk+5zJ/W2XiyKjTapjDMeSKVz iMX5z8HqVed7rG7mg367QOSMY1BCEp0DvMeN1ASe0ZnH4luGIDUscG8sXwMmCmNnZQyfkAIgBOnZ N1pBU5QUa0b+WIfRQUhVfuNw59YkeezkgcbfU14IGUZD2CPcCcLbEq/+BPwwHA6v0S/BL/mIDJMg kGL04D8IqR1qoWOswxKzigeUDyWIhKgdM3Ql1AGDBW5zJRztMkORBKNYJvDjZrWYjX58uLg8UZwv cpX8c4hUCkrGPuK3q57m9IKrRa3Mw35v8LtwzdFmRmtU8DUXSm7OgXgsP2sqYkXwcFEzIS/AZQhf yvOb8fRlBPpeWyrZKwnzKZdJwZCLfJ2C0mJb0uKlmIAqOuGSHh9jxcUboT0Q4d4s1kom/ac/0coo X1MyvUjxtasu4T/5HS8YdVK/29vX6q+C815aUjeYye3OaQ+Os+YRIdpJVAk/YKZcn/5eGszSCp2l MvNdjQvgXmYk5GvqLkb/Boyv1mUF44OhhmAs4VWnMiNGMnJ85JgatMeVYBwb7UQqtRcsqk6WLmP/ d9XpFoXwvEVW4S2m3M0cMYW1hEKphOe7sY8cLNUXu4iVjLmbHnnSd+KWwqxoHrkuxWnEEq9FBiPn RLyj4nSm7LI+L2ffUliEmdRESGepmeb2fXkcT0FqPykJ9X9n3Lg3aITtRudfmSnVkFSuMGcL/JkT yNwUC/Mypy74YMizYVI4KWEdjwoVLI976qkRqk0wNkbxhOXOIgbznSDLc1kbcHntOrmqq6Q8rEae 2lFK3QXtR/ibxCNYGeVIiOvQ6TZ68LiCL+TayNTByeCdxv3KO1Tm6SPMzFO1LHxh0dWxzzbg0UqK quZemguvl29qdoNoFN1RnRtL0knHU12UrjVrRuNx2IWAezWZarbrdW8k6R9LxQzZbBFe6dqoV9lC PxhC/kXQ63QawyFt1x6y1b5lNCbL2tfaL8RTzWFlbmRzdHJlYW0KZW5kb2JqCjM2IDAgb2JqPDwv VHlwZS9QYWdlL1BhcmVudCAxNyAwIFIvQ29udGVudHMgMzcgMCBSL01lZGlhQm94WzAgMCA2MTIg NzkyXS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYvVGV4dF0vRm9udDw8L0Y0IDQgMCBSL0Y1IDUg MCBSL0Y2IDYgMCBSL0Y3IDcgMCBSL0Y4IDggMCBSPj4vWE9iamVjdDw8Pj4+Pj4+ZW5kb2JqCjM3 IDAgb2JqPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA1NjAgICAgICAgPj5zdHJlYW0KeAHF VE1vm0AQvfMr5uhIxQbir/SGMZYsNYpjiHrJZb2M7a1gl+wuUfzvOwvBTqNWVaSqEQjB7jIz7817 8+SFENAVQjh3N6+8Re4Fw4AWzw99gNFqAmEA+R6upzALI8iL9gAt8cEmmgbD8Cr/4Y1W49djAfjt qUFmmSyYLuAbWosaslO1U6WBvdLwIIU1oPZwi8w0GiuUFh4H2brb+QJJY6yqmD7BWvKjv1GNLPo9 CgsJasuEhDt7pNBtuMerrpDZ+0K2yFVFGQpmhZJfIa5rrZ4RNvG2LYZCgMZnYWjX1cTA9KU30ooS lsix2lGeKIiCLklPCqElXvKio2L8QSockni3c8nb2jpy7htGaa1AAw8GCyCYMVdEiODmcyHOX9F/ qNe/gZOWyK0WnJWQcYGSIzgq3iyn8iAkohby8KmQw8n4r/p2gt5o3IsX6pj7WAjplHvblFbUJb5r mn92yL8XZjCcOP/2j9a/04sfOqmu0zT1szhbQKKULqhYSzTTR1UJciqaUZYk1zfgk/fIuG5bSWrV +QCQT7pekUUPEkmYkLE92pPr1WV8tG+/zBCCHo1buyQ3k+Gf7HLmhcS/0YxTfGyJXSLVUwnpynUJ YSmcVTnxvtKqgi0rhKJXfGpIVCfINZPGgXI/xARGSmbg+xElOcut9YpzdV/6sigZmc1RwmoDy8ap ENKXulRG0Ny4q1F3dv2P0qQhHbopPIlmw9l0Dv64m7Jha8k09+69nxHOzBJlbmRzdHJlYW0KZW5k b2JqCjM4IDAgb2JqPDwvQ291bnQgMS9GaXJzdCAzOSAwIFIvTGFzdCAzOSAwIFI+PmVuZG9iagoz OSAwIG9iajw8L1BhcmVudCAzOCAwIFIvVGl0bGUoMjAxNjA5MjAyMzM1MDYtNDE3OTItMnl0MXdx bTIpL0Rlc3RbMTggMCBSL1hZWiAwIDc1MiAwXT4+ZW5kb2JqCjQwIDAgb2JqPDwvVHlwZS9DYXRh bG9nL1BhZ2VzIDE3IDAgUi9OYW1lcyAxMyAwIFIvUGFnZUxheW91dC9TaW5nbGVQYWdlL091dGxp bmVzIDM4IDAgUi9QYWdlTW9kZS9Vc2VOb25lL1BhZ2VMYWJlbHM8PC9OdW1zWzA8PC9TL0QvU3Qg MS9QKCk+PjA8PC9TL0QvU3QgMS9QKCk+Pl0+Pj4+ZW5kb2JqCnhyZWYKMCA0MSAKMDAwMDAwMDAw MCA2NTUzNSBmIAowMDAwMDAwMDE1IDAwMDAwIG4gCjAwMDAwMDAxNTkgMDAwMDAgbiAKMDAwMDAw MTQ4MCAwMDAwMCBuIAowMDAwMDAxNTU0IDAwMDAwIG4gCjAwMDAwMDE2MzIgMDAwMDAgbiAKMDAw MDAwMTcwOSAwMDAwMCBuIAowMDAwMDAxNzg4IDAwMDAwIG4gCjAwMDAwMDE4NzEgMDAwMDAgbiAK MDAwMDAwMTk0NyAwMDAwMCBuIAowMDAwMDAyMjY5IDAwMDAwIG4gCjAwMDAwMDMyNDcgMDAwMDAg biAKMDAwMDAwMzgxNyAwMDAwMCBuIAowMDAwMDA4MTU1IDAwMDAwIG4gCjAwMDAwMDgxODcgMDAw MDAgbiAKMDAwMDAwODIxOSAwMDAwMCBuIAowMDAwMDA4MzU0IDAwMDAwIG4gCjAwMDAwMDgzOTUg MDAwMDAgbiAKMDAwMDAwODUxMSAwMDAwMCBuIAowMDAwMDA4NzQzIDAwMDAwIG4gCjAwMDAwMDk3 NTEgMDAwMDAgbiAKMDAwMDAwOTkzMSAwMDAwMCBuIAowMDAwMDEwODYzIDAwMDAwIG4gCjAwMDAw MTEwNDMgMDAwMDAgbiAKMDAwMDAxMjAwNCAwMDAwMCBuIAowMDAwMDEyMTg0IDAwMDAwIG4gCjAw MDAwMTMyMjIgMDAwMDAgbiAKMDAwMDAxMzQwMiAwMDAwMCBuIAowMDAwMDE0NTM2IDAwMDAwIG4g CjAwMDAwMTQ3MTYgMDAwMDAgbiAKMDAwMDAxNTU1MSAwMDAwMCBuIAowMDAwMDE1NzMxIDAwMDAw IG4gCjAwMDAwMTY3OTggMDAwMDAgbiAKMDAwMDAxNjk3OCAwMDAwMCBuIAowMDAwMDE3OTE5IDAw MDAwIG4gCjAwMDAwMTgwOTkgMDAwMDAgbiAKMDAwMDAxOTE0MSAwMDAwMCBuIAowMDAwMDE5MzIx IDAwMDAwIG4gCjAwMDAwMTk5NTQgMDAwMDAgbiAKMDAwMDAyMDAwNiAwMDAwMCBuIAowMDAwMDIw MTAxIDAwMDAwIG4gCnRyYWlsZXIKPDwvU2l6ZSA0MS9Sb290IDQwIDAgUi9JbmZvIDEgMCBSL0lE WzxjNjk3ZTkwZTc5OTZmYWM4MDM0N2QxODA0N2E1NmQ3YT48YzY5N2U5MGU3OTk2ZmFjODAzNDdk MTgwNDdhNTZkN2E+XT4+CnN0YXJ0eHJlZgoyMDI3MgolJUVPRgo= --94eb2c07e8067ea6e7053e0d0b37 Content-Type: application/pdf; name="2016-09_IEEE-SA_RevCom-recommendations.pdf" Content-Disposition: attachment; filename="2016-09_IEEE-SA_RevCom-recommendations.pdf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_itvqddzc1 JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu Zyhlbi1VUykgL1N0cnVjdFRyZWVSb290IDIwIDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4+ Pg0KZW5kb2JqDQoyIDAgb2JqDQo8PC9UeXBlL1BhZ2VzL0NvdW50IDMvS2lkc1sgMyAwIFIgMTEg MCBSIDE3IDAgUl0gPj4NCmVuZG9iag0KMyAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAg Ui9SZXNvdXJjZXM8PC9YT2JqZWN0PDwvSW1hZ2U1IDUgMCBSPj4vRm9udDw8L0YxIDcgMCBSL0Yy IDkgMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlh Qm94WyAwIDAgNjEyIDc5Ml0gL0NvbnRlbnRzIDQgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1Ry YW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyAwPj4NCmVuZG9i ag0KNCAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAzMjAxPj4NCnN0cmVhbQ0K eJy9Wtty20YSfVeV/gGPQHYJYW64uFKpkiVmo5SjaCVl/WDnAaYgiRWJkEnYjlP78dunAZAYUAPC kjZJkaLJnp6evpy+DLyDM+/77w9+OTo59qIffvBeHx95H/f3YiHDxIvof5OEifEmURjxfyaRXqJ0 KI03u9/fOzi5z28K4x2X3r/397zpL0feweGyml/nswp8D6sqn90WV967g8vy4feDy68PxcFZfjNf 5NW8XDQbvr4kTj8KLwuz2Lu83t8TvLXw4ixMY+0lOg5l6l3ShlGoFf0amkjSu46Vt7x57Nvzf+3v vfO94Hfv8uf9vSltgE16fOMsC6Vkvu/88+LzUXkfTIR0LhMiDVPZXzajNcov72mt8gv6R+QvrvhP HhifjhlMUn+xcvCUUoaxsXm69tfShKmyaUXm0S4XLHfxUBX1CT4USwcPE+nQpOP2M1ESZj01yYg2 EL6IXWtUHA4cZ9BFXpdVVd4Pe4n0ssdcRMH4unYRDx7hDTqAIXrylc6qIVoVCu2mFdhPxZ5M6OBG R56EBpbF/t71d82BP4KAIkgwUZSBLKQ/RKmZ8u133oJoO8EoNsHY8KbNsUz0V1keKtPQaE/rMEn1 EwLmJEj9KfnTNJgk/KF2Lu1XwcSQP8P0iyD2r+Dr+fJq5dFvh/RarUp8NZsHE+3nFd7nWFIGCS/w mBcx7WqOIOPbjidjEaaZdTyIT6+YjsMH6/y7PtJ/n7ehCbPk6fp8oWMnJtTm6VJomIbfDN4g1E9k sxIGKvANmTH23wQT6ecLMljRUtWvZ0iujAyF+RsNpkwcqierivOcpkwzI9N5zzt5zFj9ZJudzWGO 1SwPVBN8X8hG+dcmlk5/DmoTRbBVun4za1Pjx98uDp9zBp0qkug53m9tzlDYxTj5NIxTguQBHsfy SZq9DbLa9wFM7Ouv4P//IIWJVnMJPii8yfarbK3kNRUrn9/i9acXiRtJbkzZonvG/zfQcUJ6slJf Ct+z0CRPl+LH/E9KYK+aIs7sNKlZm279lVhHUVKbOnshJExlGKm/0aIqpaJZPVWXL4mEmQnNM1xr xdUEJ6Z12REyOhZNxd28hW1OW948D/Ui1K7PCAVr88eAT/UaHyEfq2ljk4ZxvKlpUZ7RMadB+3J0 KVHEVftm9Tt/4qSNqc+zSCllIBQuqhx/F1f5En+vKA5WCILXZQ7VL68Gqc4LAtTPcwBCQVb54h0F qAVpYd0mzauqLj40v7z3PmxcrzqqzUik7wNnTS7JPWNb8K02o6tx3dF4X82U36JNO0cizEpI0zZ0 GserK9rS2caJTIfKZjUojxmQRxIINjzeObZLqMrRNmltt4vXzt6VSufYWuFucw07UIc0f4BBHtjI bJvP+Z1rdaLDLLVWv3KSZsjko2SiUqQnPsUo2eYCBnpg8+DT/YcaGLS/9GQk4ICuTlWJOIyFxfJ3 F6lUyI4uQbesG/daVkd8Uyu+9t53TSN1h7i4Q0x8buOg4iipy3TlfwomMVUuCojYNFn3QWMV/q2h Ukx0t15LX3PJo3pMr1BIltVtXQsJ5S+/1N0bNXVF6NSIIchL7CMMqiTpQ54I0U1va8VkEfxnBMvU HUMmSdAHN5FBJzwj/Pn19ALv5x5lkrcnlz8dnwdUJ0Dpbw/fXLjmM1RtisRmOChVNiBVrAemIlb3 Hw1wIdVnDZOUhI/oJekVCjpX4oxpidFVd60zJ4iUEmSXUvIuExRHml6OZToLtb1DP5g5FLbsLgzP V7oL3/tHB29+gRu+D6igQ5yfTKdTFzhIqVE2djkgMRnM4ahnIvMvg8bRidM14mqJiv9kUX++J8Vx nzUPROyXC2SwSwb/2e2ivAsEEd18DRInOrWWUQnVBI0ENQNaLIgND0fuaUu8Pi2IP22l/FnOaZA/ U27xEL4QhOXmU/clBKA15JBy+if9MLvls94ggr0PeK++ILo5vBfw9ouviOaqgDCQgCHiTcnN5R24 Ya/OxsOnJG0L0ZySjVRUS0j5UDIvFo/UH9d7Hy6LHHBGr1OWiISjWmD5B+RwGlSFibJ3crmrlGmY JDbtxUMxYzGuGSKhaZz4vPjICMnfLLk4uYeiFlXQgCtgovWXCtILkjKh1yvvvFjN7+b0e02O87TU sz/ApeLCZw5MIVtM9E49Cqowk7XHnwOVwfGcfH4ieYPDGRVUs2LFowAPftjo+5Z98soLev6C9bdf KWRWPKprnAwnXZv5DSzzFedY8nDvgfUAdQlSV6udnme6skCiQpXZJxnGNTE2DegswSBnDE/Zz7ZO nqlGD9YZ3Eu/hAcgJgpSorZgwAV0mOzENjN3hQNIskidFQ7VTUlPxsOzxqbnv9KH/7gqfkndjErc 23D3sNaBROLOYnSaEUbS1qTaUuxWm+JULB3TZN1OZdhiA9W4NkkoW186nb51HDnLKGf0qIf3HKi4 tVaY1Y3hEg9wwQ1Bi0BnPF3QVHxq/4Bex6hI82vGCDWURY1EY2PxGptGDYppa+V7/2wKAaaMBk1C 9ZBKGcGE8Y+XgAPAJMPdv1A6AuSQLAvvmuv9JleuPt1hxWNpiDnjB/6O8BEoGUyyGpxmBXCnvMYG U+ZRzKrlmsVsB05qkYQi6+YbxtzbOTgtCmdHRi1i0ls9bNtkwLaRwjXoGC4DVanKok198Fz8sZgN 449FugN/LNpvwx/nNl38UWkapg3+mCyjSt+NP9lY/FHUD2fj8UcOVNcqVriP3USxVWIrcuEP3FpN tuManxHbIS58pUtXUYQy2dpmXIBL6rWoE7FWdgtl7yQQkc+hPUXE9kJ7VEU8RVt4W6CcWxR1meO4 iqa2KDO2MK4KTSu2zuCR17Q6AhRbtIf3jCdX60CBYK92oAYaVKU6dqzLIi7PmoqIL7361RBVQox6 81l9e1+H4qpXIOsNEC3A4QZw2daSfWM+5rgK00hlSznODRRpXprt87VGxV9WU1UsVy4lqSzl4XCX ieUFVAfabrCpdle1Ej9DabuMQJZPW/AFhDxYyaNXmW63B21JjnOVVTnjycWavvwMrbPdjkr0GH+O Ur1MBOY+lmzDcCEG4II6FTOqAJGjy1RF5bR4sTTRZbYjTXRJd6WJLu03pgnXNlaaiFLodUyZKkeX qTIjk4vxaWKgTJWpwll2pIm/DujNmSKUc5ac4Yaiu8PYDCHD1Ngr/4YMQVjxJIiW5HWR6RZ2xdW8 LTHr9nfWzi75/mCBvRkLeKzSBaUt5Psnj2tGdMQTKwnw7UUD9KNwnM5AHbB1lJE4nvDAYlsJjycV NXxcrzEkjDSsdBNjtNIO9mJyRXQqdVJD+Q+/PVi1E4hOziNFuejopxbdC2fdk+JJGmv79hQOJHPA t+b8ZzEaDmMzFngl9YFyXEoY6AOlzHDSl4Fvi9kwfFukO+Dbov02+HZu04VvDOW0GFXly4G2S4oY VdJowE5HZwLq56RwwTcG6WjeQ00fPj1W6msndAtU9xb7ke17ZjAFt1Za2A20qofgTwNuHvdSoD42 76Wvv2GQO4gvIsXfdn7zSEXn6tYN7les1c4LCow4UpvWyVdpGMSifXTIaxoo1Bj2Ng+QaFLaF1c0 kGtSNzZKYCkFjGrRnuc8JfHecsaDKM1dwWqNvWd8Rb5clQuYt3/f6shHOkFWGdSNIx8Z7ryslYOz exTn7/03565OzugwVuMUpE2GAbJF+xZmOkTBcrrCRHy35yUxTD3QM9oB8RvfcHplPfiuT1ndslFS qhdidgqHQSkHUQlr7eg0vq4dpUubEu8YR0q63eRPfzVSvIbSN6FZD9XgqCd4sLxpnvKR9YkMo97u wxiajc2Wgnr0xzBu+2mXgXELbg3XF8jPTZYWs+FkaZHuSJYWbZMsXfBPKNY705ic6pSmm1OFxr3s mJSqBhpWofDoyOiUquTYlCrwjETtYvzwmJGKnx47E6nIDo6XPA6+BqTxwxoUY64JOINAl11UP4Y2 Lo+SVyI5bJZvxuAM66dnaH+QUJ+XT883/cTqD+f9GPmDsYVx4YRK+Q7Fou1e/xZ823cEQavihr/m 1PEXF9GECvZQfhgqowxKap7t6Y61+Naas1FebWGnPcJnbVLBEFtN1daV5BStLtcTPPWHdHCFes04 DIuoqMpsoUfmtMhw4u2uZHk+1vcchCkPQFj7mHlbF5x+mtWC50tGZqJEUiq/YOhUX5YUi2K5GRTy HfwO3WdxKOP1oynV8JTx13VO4jHXKeucpTJrqbT/Yz5jld61zxVsXGHresQ9E1OJLdswLig3xKR4 1MTJ5X/a2iGDDQplbmRzdHJlYW0NCmVuZG9iag0KNSAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1 YnR5cGUvSW1hZ2UvV2lkdGggMTI0NS9IZWlnaHQgMTE4L0NvbG9yU3BhY2UvRGV2aWNlUkdCL0Jp dHNQZXJDb21wb25lbnQgOC9JbnRlcnBvbGF0ZSBmYWxzZS9TTWFzayA2IDAgUi9GaWx0ZXIvRmxh dGVEZWNvZGUvTGVuZ3RoIDEzNDgxPj4NCnN0cmVhbQ0KeJzsnQl8G1eBh1WghR6gnvSkagssy8Ii yn1PelJ2lxULvThVYNldWBbRAmmhh3qkZ5qoV9LmVK8kdpxEiePEt+XbjmNHvo/Yjnw7PuUr8ZEU 7xs9afTmzZuR5Jx2/t/v++WXyNJo5CP25/fmvdlZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgCk4AAAAA AAAAAODUYfraD+eJP4rPr8flnTF4l+kbsXi3wG9y3hOD95q+peePI36b9Sdiv/NTHX8WUuL8ucBF xF/oaA95E+d9vDdTf6njr2Rv0fpr3lup/6njb0y3Cf2vkLdz/rfK7yr+j8A7iL/V8Xem7wn934j/ wvp73n9V/D+B/0b8g44O0/eF/jHkv3Pez2tjfUDgDzj/JPA/tP6Z94da/8L7o3i8c3Ec3hWnd1Mf jNt7js175+5ZxB/H4fv0/Anv+2P2A4o/jeLZhp7D+jOVH9T3Q/qeG3JxxJ9HPE/f8/W9QOgvZD+s 70f0Net7od3Ii/S9WN9L9Lxv8aX6XmboR/W9XN8r9Pzl4iv1vUrfqw29Rt+P6fmrxddG0xKz14X8 S1Svj9kbjs2Pn1w/IfbPWj8e1V/+SesNQu97QPF6qp14v+J1xF9Q/6ho+TmrQ/Znjmsj/uHan/7h Y4o/+b9rFH9M/P3V1Hup/3sV8Z6QV97zuyvvDnvX766467ch7/zt5bL/I/sj2Y/+6L9lfxjysh/+ 12X/EfJS4g9+o3iJjfif1Iv/nfpr2e//+qKQv7ro32QvpP7rL4lm6r8Q7yN+hPg9qv3DxDsUf3HB dxlv//n5irf9/LzbfhbyVtlzb/2p7C2yH5L9yYduDvlB4k0/pp6ziHqvrHTv2SHvOfs7sh9g/fbd 1Pcrfot4F/V91G8q3kk8i/gN1h9RTd+IsxROfQedGd6/4RS5UewDBm6Kzz8lxGNixD9TNwv8S5LG LSEXK27VuM30IKcn4kPU7Rp3mP7Kmiz7N+rOiA+nMO6SfYS6O+KjqYxpso9R00M6iRmMmabHFbNC PkHMZswxPanoDfkUMTfikjzGfNmnqQURnylkLJJ9lloc8bkSxlLZ56l7Qr5ALGPca1qqWC77IrUi 5DLivojLfYyVJpdilexL1OqQLxNrIr5Sy1hnelWxPuRrxIaIKxoZm0wrWfebXldsln2D2hJyFbE1 4uoDjH7TGsU22bXU9pDriB0R13cydsm6WbtNb3L2mN7i7DW9rfGdg7zv9vFu6OfdOMC7aVBggo6J Q2I365hEHObdouNWakDgNkM9Ec8Sut3QHbLv0zPZyPcTd4r9gGJKxLNFnkPcxftBzt2yHxJ5rmJq xPNEnk9Mi3iB2g8zfiRdpVnthYwXETMiXsx4Schh6qXEzIiXMX5U7eXULNkr1F7JeJVituzVaq9h /BhrzvC1jBa11zFe71V5g9qPM36CmBvxk4z/oPZTav9RMW/402r/ifEzaj+r9p8V84c/p9bK+Hm1 NzJ+QXYoZMHQF9V+ifHLar/C+FXWwqGvqf064zfUfpPxW6xFQ99W+x2NkshFIm+SHeS8WeQtxQJv FXmbyNtj9rshB+L1jjn5PbH9nHcoFvVxfpdaeFDo7QW9nLfl94TM67k1r1s2t/sW2a5bvLI3eztv zpG9iZjdQV2U1U6VMoltshlt35H1fyfd/21i2oFvEVNbid/cTWz5xi5i89dTiPu/vnP/14jJTV8l 7mj8CnF745e3N3zZQ6z/0jbZL26tI35hS61sUu2NSTU3bq75/ObqzydWWxOrrAmyn9tUSfznjT7i ZzcQ933mXWLFZ96p+Cfi2+WfJr619x+JbxLLPuUm7vmH9bKfXFdK/MTaEtk1xR8nri6+YXXRDauK rl9VeP0bhde/Xnjd6wXXrSywrMy3rMi/lvhaHvFjr+YSr3mF6L36ZWLOVS8FdWVfSVyedQVxWdbl yzIvf5GY8dGlspe9kE689Pk04iXPEVMveTb14md3X/zM7ouIT++6kLgkhWh+irjzI08Skz/8RNDH d1xAdG4/n/gY0XMe8VHZcx/ddu4jIT/08FbqB/9G3CL71y3n/DVJ9qGks2U3n/2g7AeIixOJ7yf+ hZhAfB/xz5ybQv5p01kCN571gKwgT+R+OVUxBY+j87FMtVmKMj09yvR5lCnKNLYyTUKZokxRpihT lCnK9Ews00+iTFGmUNf5WKYnfcz0IZQpyhRlijFTlCnKFGWKMkWZokzPqDLdgTKFJ9f5WKYnfcwU ZYoyRZlizBRlijJFmaJMUaYoU5QpyhSeQOdjmWLMFGWKMp3nZYoxU5QpyhRlGk+ZfhNlijINl+ki lCnKFGW6YJ2PZYoxU5QpyhRlijJFmaJMUaYoU5SpH2WKMkWZLiDnY5lizBRlijJlRJmiTFGmKFOU KcoUZYoyRZnCeS/KFGWKMp3XZYoxU5QpyhRlijJFmaJMUabHpUx3okzhKRVlijJFmc7rMsWYKcoU ZXqyy5SLU5TpyS7TQpQpyhRlijJFmS5IUaYoU5TpvC5TjJmiTFGmKFOUKcoUZYoyRZme8qqCxy7K FGWKMp3XZYoxU5TpPC3TYZQpyhSzeVGm8ZRpxzwq00+jTFGmcC6iTFGmKNN5XaYYM0WZokxRpihT lOlpWqa3o0xPaZk+nN3w+101KFM4f0SZokxRpvO6TDFmijJFmZ6QMr0WZYoyRZmiTOdtmb5Q1DIb JFqZ7kKZwtNJlCnKFGU6r8sUY6YoU5QpyhRlijI9g8pUQpkalql9e+VsmJHJmS+8kadXphedqDLd gjKFc3XBlelfUKYo0zOqTDFmijJFmaJMz7AyxQpIKNNImbahTJUy/dKaQpKisww1faMffzkbZQrn jwuuTDFmijI9s8oUY6YoU5QpyvS0LtOvoExRpnMt05tRprGV6adW5Nb0jc1q2FTTZbACEsoUnn4u uDLFmCnK9MwqU4yZokxRpihTlCnKFGV6ast03yks09SWftqhRR3Dj+Q0Li1q3d3cR295OLsh3jLN 9w9oCzf/wIBSpnkHBHeIEaVMb349Z84HWbQiS6mSOR/E23zwVCcYFBp3mUorsjnZDuXfulKsdVma UqPM7TkivVTr8nSlTKXXc3V9g5pHtLqy4ipT29ulzswGb+uAoqugxb55n/mJXTRLLc9nSquLZNcQ i1WuVSxRZMvUsswrrdujcv0e68oiYZlaXy+R3Hsld7miXplKb+1TtK7aq5Sp+YUC6W1f0EqibXOt M68tYn6b9E6V9E51jGVqXVcpbaiVNtSxWl7fJyxTaVND2EYpQWuT+dVKYZla1tZJm5sVHbldzpLe oAeJ9vQOKanFsq4hljK1bmpx7un3tI55uyaorsohR/5By1stcytT8/oD0o4u2WRit6L5zTaDMrUk dDpKhtxN496eSap7/4Rz34jV0yssU/O73faCYVfduLd3StHpG7NlD5k39BiMmVq29jvKRt0th729 096Dsq76CcfeMcu2/tjL1Lp72FE+7m6d9B6cke2bcTUedlRMWFMDSpZakoel7BFWcotemVrTRyTv KKclJaCUqZQ7FpN5spbUUdKh1izy9/GI+ePmnSN6WWpJG3VUH3a3T3sHjlBdLVN/rD58XfqoXpl+ PmdsUcF4yEJZvTK9qXD8pqKQN+aOoUxRpihTlCnK9Mws08+eujJNrOuhnbW6op1kKf17UccQt/yR ukxTDco03z+ojTiSpcqY6TFmKS3Tm984piw9C1m6kI2vTLmPrK9rmM3SWD8fWvqULI3jIeEsjfkh /TGOmUqrCvzDhwwO5SpsIVnqCX/5x0Lg8Aw7ZurrGRXfRzRm6vUPcfe0baoUlqnq9foDypgpCdIY z9NdddDyWplBmZqX7xE+0NM0JBwzjeVJvR1j1rfquTJ1Fsf07vWPTpNKNb9eKyxT68YWb+eE0VN3 HZpDmTqK+oVHs6X1CsdMzW+1kxo1ehVjRyyJ3WyZOkoDgan39O4fmH6PFKu2TK3J/SRFjV7vwelQ nOqXqZQZ8A0fMTrbiaNyfm4adNbwXybkFuGYqXnbsPh8+maUMVODZ9TirD9s2jrs7efPk5SpNkit 2WPae7J4emYiccpkKUlX7p4/2DMhLFPVixo4gjFTlCnKNNYyLUCZokxRpsehTJeVHiDfgEamZh7N bSJ/st+VRiZnHslppBecxlWmBW2iLPUPKLN5jylLw7N5jylLV2Yps3nnfBBk6eltHGWq+cj2nbZZ 6t7bFstsXvvmiujP3jpgemgH+TPGp5YfcmBQmc1redGrd7fwgKmqTLVZ6g8cNj+bqy1T1TP6h5XZ vNJbvthPlWBPbtIrU3vKfuFDApNHhLN5Y3xG8nApoYkt0xizlELi1LphP1empEkDU0ejPlZnNm+j QZn6BqaEh3JVj2hn85rfbPcNGqUiRdrVp4yZumoFF4ZwOH1j3Gxee2Eg6qNmadIWjeiVqavB6Bcy kbPNHomepUyZ2vfoVvkcs7SOZukMd7uUN87N5rWXx/SKAjN/v6/iEFem2iwld7tw14i2TNn76GUp yhRlijJFmaJMj3eZtqNMSZnen9EwG2zS1fs6lG9G7MJH5O+rytvoLbZNZTGWqW6Whq8zPZYsVa4z PbYszVauM53zQZClp72xlqnmI6vKUm94QnuUz4f4s9Rd5o83S50ZdVGvMzU7dwYO8z/oCk54zlka LFPHrjq9uzl2N2ivM9VmKcFV0q69zlT1jKEsDZVp7KdKsSXVCcvU0yT4P4piXV+lLdPYn5GUaWhC b7BM48pS+eFTR7kxU1//4VgeqH+dqbhMzeta9Q7lH5vRXmdKWjWW01Cm8pI+jeX+TJbKZRpjk0ae LmVQW6bu1skYH04n8UbP0nCZerp0w1zyjpImtaTEd/5ylm7Rz9Kt8TWpwudzxtgy1WbpbHBoVXud KXsHgyxFmaJMz7Qy/RLKFGWKMj3BZXp/ptyktf3ja3wd7DejhNqejlHVD0IP5zTW9I2ROF3kLqZl eqlhmeplqbICUv6xZSkt05vf8M75IMEsDa2ANOeDIEvngzGVqeYja5SlgcPT5JaILSGd6TVKlvqH JviHtPRptSfs0ctScgRvS79We+LeqCsgOZKruKP5ukfsmyukVQW2t0tdBS00Wj21PaaHthtnKbmn t3VQmQzsqetVVkBiZ/ByFew9MKRdAYncKHyK4EWmqjJVHSqSpTnaLPUHJr1tAaKvVzyMJUfii8Vc mZqXlXL3Yf/pLOjUroDEP+/IlLOwy1nY7esT9II91a9cZ6rNUl/fYW/HONE/Km4cd92wcp2ptOUA /9Sj0/bMLmmbn+jc008P4uufNFwBSVCm9pxe4bNTLBva2TI1v9nG3SEw9Z6zIiCl9BIdJUPenlAJ Kisgedr494yn7bAta1BK7bcXDLubQ18gbJZakg5qz8TbO20vHJHSh1z1E4Fpfj6wf/yoOaGPLVNb bkD4inzDR1yNh53VhzydU8pxaJba8vm56IIsDZYpewLcyThrD5MsJXEqfPbICU8cJRGqPNZWNE6y lMQpd7dIlm6V5+4K3i39R0irSvnjrpapwMzf+Wc59B57nenjDeJOp1N52TJlD2WcpShTlCnKdOGV 6c0oU5RppEwrT2aZPpDVOBts0jTND6W/TK56NLeJuzGuMtXN0vDavMI1kd6uaLt9bT7xtrV5smuo ucRbV4ddlauszXvLKq/wW+1Nr2fftFLXRUEvfHiLsjav8CDuslZpRZb0GjFTT+vSXae6uWAsRi9T 7qNvnKXcW4Vr85LkVD2EGUjVW5uXOwd5VHSua/N6W1XXDJKoNDtT2LV5zY+nkDh17KzWrs3LVSpp UuHavOan0lVfLxWd3Plr1+Z1FfNpEzo9eSqvly1TX2/k53A5S5m1efn3Up7fFFqeN8+8tNC1hz8N giOjlVsByZZUrzr5avUHq31UuzYvl67yfcJr8zqy27lndNcMKmvzarNU2tysrM0rJTULB0PNK2tp mTpL+TFHi7uJW5vXkd/rrg9EW5uXL1PPgUjI+wamuAm9dm8fuzavtJN/FfbcAW5tXinloG9wWlmb l7uklDQptzavJanX037Ylj2kLM/r7eUnFbubD7Fr85o3HSQdyp8JncobLlPtHUgDSpkBbm1ee8kY uZ2uzStl8wPB8uReTZbaClR56D6gOltf4IhwbV7uyHR4lFObpebkESVLtdeTutumVYsgpY+SDuXu E5nK69HNUvIoOpVXKVN2XFXOUqzNOy/KNAtlijLFmCnKdB6X6eYG+ZfSwiYdmZq5ypX9lXVF2m9h D6uuM003KFO9LFV2jRFm6ZLs+rh2jdHL0nh3jREexJlWjV1jFpBRytQ/pBpriztLNWVqmKXiMuU/ A9O1WRrrfqZclsqTdWPeNcYoS5kytW+pZO+mvc5UWreHK1NnTovwa202MpU3VKYkRSMnIGdpZNcY /r0UyVK5TE1L8rRl6m0b4dbmdVdFRuX8I5PShhruIdpdY0iHqo4ZyVK5TPln7BhTdo1xFvFBx+0a Y15ZrR02tad30LV5naX8AOIx7BoTKVPzWtXHwlHY725UvUB34xi7a4yUzL8K69Zu411juPu7aseM d43RDpX6x49od42R0vnQ8w3NKLvG2Iv5wUrSntZdQ8a7xsSYpe4DkbjzTxy1pvOPMnuGY8pSza4x 2ixVmtSSyr8i/8R72tWQpAJ+toBv5GjULCW426fZXWMEWYoyPTFlehnKFGV6GpSpIE5FWYoyRZme uDJNCjbpyNSR5XsEgxeJdT1015iiTsGSg8p1psFdY3TLVDdLw/uZirM0pz6u/Uz1sjTe/UyFBwll Kcp04WhUpt5m1Y/E8vRsZj/TmLJUXabRslRQpvxnYHrtnPcz9bbwK6w6kqtjLFNNlg4I9zP11EWm gPp6Rk2P7PIeUH3Vu4r93H6mzpxm4dcaJTyVN1MnS0Nlyr+XVFkaGjPVHpzbz5Qd+nSVdZue5X8L Z9vayJWpYZaWcQ8PZ2m5OEs1+5na0zXjrXQeL8nSEj7W3PXD5jfqj7FM7dmqGbzWze32HNUTBaaO svuZSsnd3Gn4BqctmzoNypS7f2DqPWl3v0GZOvbwlecoGxHuZ6odDw3N433noKeDH291Vk1E3c9U yhJlqWY/U3bWrqtp0pSoWVm6cEw7YMqfD83SpFiz1FHJv8lRdVi4cYx2Ku+FKSNRs5Twg9IJpUzF WYoyPY3L9EqUKcoUZYoynZ9l+rl1JXUD8u9UR6eOrK3sEn6HWlZ64Kvri297t4xdBImFlCn9y6aa Lr0y1cnSQTlLg2Wqk6UN5z66LfYyvWVVrvAMSZbGVabCg0SyFGW6cNQtU50s3RhfljJlGkOW8mXK fwbSLDUuU50xU/dewW+c/MOH7JsruNm82jLVyVJVmZqfSlOdavZ+kqXkT/ZGuVVDWRoqUzZLyVsD k6rLUck/w1N5M3WyVC5T/r0kZ6nXpC5Tb1uAu5t1TYWSpdwMXundGtMzRd52VZi4ynqYLC0RZ2lw P1O6pSn3dK7yg6alNEvLxVmqLlPLWn7xKG/nuOmlKpKl9nTB/8OkGZ2lfeE4nUuZsjN45QWOXt9v edfPv9OSOpQytW4RzI4muJvGw3HKl6lw2V5vz5Qta0BYpu5m/lpUKW1Qs5+pXKaedj6ypIwhmqXa i0/Nif3C/UxjytJN7Axe1SeArWCMZKm3T/U57PZPxZGlScZZOkyz1N3GvxuFe8cQtXN9FxWMa7OU 1CsXsKFVebcbZinKFGV6BpTpjWyZ5qNMUaYo0xNYpvcmV5Mapd9uXGXii7wod27Zt0anSWeDa/Nu qgn95rymb/QLb+Rpy1QvSz/y5E5apnpZet6jnhjKNImW6a26WZoYV5kKD6LKUpTpwlFcpvpZujH6 kkfht1pfTFXKlMtS7ZJH9Ha2TLnPwOCSR/TO8kpHvu5A6CExjJlKb+QJP6uDZzLjLm+3PJeuV6aC LP1rMlem3Axe66v5pod3SWtLuOeyLMtly5TNUv/wYfs2fuqsp6EvWpZmcw9x5vrlFXrVZerM4/9/ k96pMj2dT7OUncErbwcTXJvXVaYaDfSPTJqeLWbLVJylz+8hTeof4UfopIRGOUuDZerI4f8vVbY0 Zct0VkMwS6vMK2sNdodx1w9LW/2xlWkkTs1rVcPWrqphujYv90SOogE5S8Nl6u3WXRDY2zMppfRy ZWrP013r2D92xLlv1PxuN1um2gtLzRt6uf1Mqc5KfsIqvbzUso2fJCDP79XsZ6otU6Ms3SSYwUsI roA06KxVvU/8E0flBXtjz9Ik4ywdFl5Yat45IsxSZz1f6/IwqGi0lNzO3VNelVezZi+fpShTlCnK dEGU6SKUKco0pjKtPnFl+lJ55EejdVXdSp9SNjf0fv2t0l+n1IwEb79zq29ZqX82eJ2pI70+sY7/ bX9N31hRR+jnRlKpv9i2jyvTgnbBDySkVUmW0jIVZmnb8KG8AwNB+wW2yrJleutqcZbmtvQpCpc/ vS+hlC1T4UH8Q+OkTQx05Tac6sKCczPeLN0Y4wYxlqeSlTFTLkv1YMdMY7n/bCRLo4yZugqMZsyS OA2udyQoU3GWqsuUncFLDkXX5jUvSeeexb61msnSVG4Sr3BtXtumSlGWZkXJUnWZOvP83N3kLF2S T8uUncHraRoML4LEj3haVlawZcplKTkId0vkmPuHTUv3BpXLlCQqd4dIljJl6uvThImripapcMCU xeUbNK9qiL1M7Vmq/9Jtu7vp2rzsECqBdGgoS4Nlat3Sabx9KolT81vtbJkqy/MKCUy9Z8saVMpU m6XcfqZMlvIr0zqrxkmWShn8p5OnY4rbz1RYplGydBM/g9fTOU1bVcrhPwcsOwNcmfKnymVpkk6W bqFZOqzNUm4/U4MsdTZMmkRZKtwyhk7ljZKlKFOUKcoUZYoyPcFletOCLtMb39pTNxj51WhJ9whR +Sfp0zsSK+jCvB2joe9cSpbOyssijRV1DidoyjShprtjJPKdNDihN1Kmhe2CnSBIlpqf2knLVJil scCOmeplaVQeT69hx0zndhDsDjOfjTdLBftWaFGtkhRHlibMNUujjJk6dlQaH8pV0KItU1GW7mDL 1PxkKnsHd0VHeB0k1ZYx8pv2dZoe2W2QpZbledzOMnQqL5+l4f1MRVl6IJSlTJkKsvTtYJYuybcl qabL2nfuF24ZI78ppVnO0nCZ6kUoB2lS8yv7wlm6VydLK7Rl6u3gRwDlLA2XqS25LUoSdk7EPmbq aVVlnbI2r6OQH200rz/AlSm3YC+Hb3CaLVPz2x2umijvN6VM9bOUL1NBllaOy6shabJUvrBUvaWp sEyjZim3g4y9dJxmqXkb/4yOfRN0h9M4sjRJJ0uDZap9j7H7mcaSpSZtlnoC16WPCqbypoxEz1KU KcoUZYoyRZmiTOdapj9JUf0Y9lK5aiWKkq6AZUU+KVP2xruYLKUk1vVwY6YjkzOr1IcKbRwTLFP9 LE2hZZrv153fZQw7m/c4ZGmwTOd2EGTpPPcEZ2lsA6zsdaa+LsGPoByBw9NxrYBkeTZVeJ2pgnY2 r06WRsrUnuRj7+DMbpLWFgctYUdRZ+lAKsnScJlqslTeNcaxmx+m9DT0CbI0XKbcnYNZmsOVqUGW sjN4Cbakeundaqo/oPrR3dM0FMrSYJlGzdLA5BHbtv3K2rxKmWqz1PxqpbZM+aNNHTW5KtkyNa+s dZYcNIhTe0aXfplG4tS8Rn0J8MCktL0jaKc2S21pPaY3mtkyNa1qtXv7/GMzszq4m8a52bxSykGD YdPA1Ht0Nq9hlqrKVDdLNYv0ulsO81kqKtOoWcrN4CVZSu5A9U+oPiKerulQliYejyzdMuwLiEZL RWVqkKVOTZYS/1jNP6mnZyamLEWZokxRpgu3TGPczBRlijKdc5lmtEW+M3KjpYQnClpJmdLleSl3 bfMt2+NX/lncOfxY7v6RKdXPIQm1qtHS3fv7LnshXVkBSS9LL1ySQstUePFpLLDXmd625liyNHKd 6dwOgiyd/84xS42WPNJbvFe85JHRnjKRJY8441+b1/JsmjOjniSt9tPYXd7OrYCkn6WhMvVqdpUy wPpagVKmoixNE07lZVdDimRpsEy5e4azVFWmoiWPyk1L8sxLi7jtRw2QLztVsvTZ4lhGS63uGnbX GL0slRKa5L1jmDI1v1bF3Ude8kjOUlWZml6qJnFqT+/QbihD8PUfNlwBKVSm3AxeY9yNo8Es5cuU xqne1aahAVP1CkiWhC73fn5EmGLPH5aztIfPUuuOPmGZarPU5h0mWWrdyX9mhvaOiVamUlaAeyCX pdqVlAyIZGnikHYTGWftYbpxTIxZ6u3nfwNgSR0Vlqk2S6WCcYMsJWqn8rJDqOStZ+llKcoUZYoy XThlyscpyvTkl+mtZ1iZLs5tUa4nXV/NX1vaOTq5rqrrgazG5WVty/dQ/Wt9nYn1vWt8ncWdAe47 18jkzOqKduXvdo/vo0szSJYqZaqfpbtomR5LliplesxZmoAsPeM9jbKUy8ZglibGXab6+5manTvd 5fzIaWRL03CZCrL0ISVLd1iez4zryyS4SO9uKp+l4f1MtVN5VScgZ2mmUqb88SNZGipT8wsF2vYk TUq0J/OFaIy0oYbJUlVfOAs6Tc+VcosdcbvG0DLVzVKmTO2p/MfFXTsUzlK+TPX2M52NbGnKlmkd V6bcDF5jgov0NuuVKdGWLhjADS5/JN41xpLYrV2hl25p6mnj08yWPaTO0lCZClbiTR+ie8doX0Jo 7xjDMpUyA/wBs0bky05FM3ijQhfppUpe/rFMlg7FkqWebs1KvHnjkSxlytTTzX8RWbPHjLP0wpQR 7bYyCjRLUaYo0wVfptYzpkxjX54XZYoyPdFl+v1tVcpFpuwKSFpIlm6uF3x/V1hdEXp4Td/Yl9YU XP5iJslStkz1svSip3fRMtXb2PRpb+PT3oanc2SXsGbXU9m1eW9bI15u9MnMWuITxAzOGuLjGTU3 rcxm1+YVf0du6SP1KptWTXRqtG8sOdVJBY+Lp0uWcp+B7rIDdD/T41impsXb/MP8IpzcfqbiLA2X qWMnv3yuMcEtTcNZqt5BRtnPlKidyhs5gVCWZupm6RM5bJk60vi1nrxtAdNTcpZ6GuO7pJ1uaWqQ pbatTdxDHNntXJkaZWm4TH19/N4o9rR20/JK4zJ11/GzvsNZqlum5tX8CUfFurnduEztXn7qbzhL xWVqfoffa8bbM0Wy1FEa4G531Y2b3N2y6jL1j2t+7RBsUqK3l484uhqScZnqZmmwTD2dgrFpA+iW pqEs1ayJFMpSarhMDbJU+yZX85QqS8Nl6p9QDekGpv8eKlb9LCVqV+VVkLM0vJ8pyhRlijJFmaJM UabHt0xvfKsswy8H4+jUkfXV/PboCte+lnf3Nt3FUlbv66ATehNqe65YnnXFskySpVyZGmQpLVNh lj7jbbzg8R0XOHec79x+/mNEz3nERz16u8boZenZD20++0HZDxAXJxLfT9TfNUZ4EBKk4R1kNp71 gKxJK3aNWSCKsvT+U5ylwYckzq1Mra5MvTL1tqgiwtc9EsnSB/WydLtSpj71JQCuwlZnVlPE7Cbv Af5L27wkQ5il5qez2DL11IuvxmWyNFMnS7OVMrWuKtMOlTrSm01P5ZqXFrI3+gOTzrw2Zz6xXZG7 vNR3cCKYpUU6WSrYz5Q8u/nlcrZMpU3aLG0MbmkaKlNnsWBWrXlFdXAppErLujrzymphmTpL+AFT Jku1cSqXqT1L9d++t+uQs2yAcdDdwE86dRT2kyw1r2+1vOsXlqmUzH8rkXbKWWrd2q1Xpv4x1cfI vX+CZKl1O/9yAtPvmTf0cGUqpfK/W/C0T9L9TIn2Qv78Z5ldTbkstWwfJBpnqXmL6vOZnJKz5hAn d3lpaJuYWLN0yDhLrZn8EUhvmpNHuDKV8vkJ0u626cj8XnWWKvuZUj094rkKoSxFmaJMUaYoU5Tp mVemXzxZa/NuaZJ//KsbnNAbM712Rf7dHv5aJ8qacJM+ltt0pStbzlJRmepm6TO7aZmKszS38cMk S2Mu09vW6mVpUlxlKjwIk6Uo04Uvt9xQKEvv18tSOpZ6UrJ0TmVKtzq1PLubK1OrK4ubKuyp7TY9 uI0tU50slcvU8nwG+yb/8CFuP1Ptlqaz8jYxlaZHdmmzVFq3h+5nSsvU/Ey2cCqvnKVOJUv5KcTh LM22vFxM/s5elEqRO/GFAtNTufYdqgFZd+VBugiSsp8pt6UpxbKinJYpl6Wush66Qq+0oY57iLxB zPN7mCzlB4LDWVouJTR5mgPalyzP4A1vHOMs7vWPTktJzdoVkLgrTMk/TS/XGJepr1+VJ5Knnd3P VHYlP5zqOTBuen2/tKMrMHXUUdSvLVOPnx9us2zsMK32y4/1H9JeZ6rdz9RRGiBZStReXupunghu HxMqU1Kp2qFSKW0weM2pnKXmTQf944JVoZxV4+xsXnNiv7NqgjQmCVLjLLWXqOY8y1vDqPcz1W5p OqtsExM1S8NxapClwstL5eRkmpRUKjdUKr+E/HG9y065LNWbyhvJUpQpyhRlijJFmaJMT1iZLs6V 57mRMk0XrYhr0cnSxPpeuonMH9Prr3opm2SpXpkWdoiytH3oYpKlwTLVzdInkmMvU70sPUfO0jjK VHgQdZaiTBe4/M9jSpbeL8hSUnbBvWv7tGvnSiuyhVkqPyS4Z67gISuzhVmqPMQ/pJl2G61MlSFR 8hdnRr3tzWLHjkr33jbtqkf2zeXBLN2ml6XyarrhRXq5Gbzu8g5uP1Oi9dV87incFZ3BLN2lk6WR MrVt3DerwesfMjkzlDLV3sEYOlRK5Gbw2pMbQ1nKlKk9mY+y4A4ygiyVLyMNb2nqrtbMYt1Yr5Sp fVdrXCcsd/RrVWyW0tt9/YedJb329A6ia1+/9opOd92wnKVUUZla3uSnN3P7mVK9XfyM4mCWhmbe +sdmXFUBR9GALa3HWT6kXZLXNzhlWn2AqNxC4tRZEZBSeh0lQ542/uAES2K3aV0HyVJpN/+elJ9x /IjTN+r0jbnqxrVLD3l7p5i9Y+QytXl1V7T2Hpwm+oYi5yxlDJNKNchST6eqlOWtYdT7mRLJjdzD lW1i5pyl5u0BJUulXMHlwKRDSWwSXc1TgWk+Kr39RwxWQ6JLIUWdyqvKUpTpqSjTS1GmKNNTUKZY mxdlenqVqWVl/j3b+SxNax2o7R8fmTpy24ayq17KCapbpsIsLSRZ+mwqLVOdLG2SszTmMr19Lf8D MOWcvybFVabCg2iyFGW6kOV/HmOzVDPF1wAlS4XL3grRGy01eki0MVNupq4evu5AuEkjZSp4unCW cjN47Un72P1MlTLltyIlYfuwcZZGytRTz7+rw1kaKtNYXpeCu7KXrs1rfqGAe5Pl1dLgOkiqMrWu 4bvY0zQoZ+kz2iwdUbLUspJ/lH9kyvxSOS1TZ2FX7CdMmtT6dgO7n6mSpVEeOHXUsr4xkqWiMnXk qw5F8pPbz5TqquSzzpbaTYzxJdjSD3JZaow8g5c0KXV9p3NfHOsLkUq1bOljtzSlZeqq171ekkMv S53VE/IM3iTNN8fkYVWWBsuU3MjdLbhNzGCsWbp5iNzIn1jumHzZabhMXft1d9jRQirVkjYaNUu5 MnW38/9l8VmKMkWZLpgyzUOZ6papdsAUZYoyPcllyl1n+pvUuj9lq0YNlu/x0ya9fePeq1/2Xv1y DtGgTIt0svQSkqXBMtVZ8miQlOkzuY2y8tpHjcIVkJQy1cvSJ7PqZDOptcIVkG54ZqdSpsKDRJY8 UlnNroAkr3qEMl0Qch99X9fw3LLU/LctNEtjvP/scclSTZmS3ox6EBLO1pey1Vm6zSBLLc+lc7eb n9jN7meqlCm3eynB+mo+KVNNlpYyWRoqU/MzWVzVMlkql2kM757gq5uccaTtV3aN4Wbw+nrH6dq8 2jLlLk2Vt4l5plDO0jZNlgb3M9UbMCW3yFn6/J7Ys9TXd8j6dj23n6m3Q7ypiuokp47adraZXq5W ZammTLkZvI78g+x+pkqZ2nbzJ+yqGnbujWntdEfRoHzBacxZ6hucNr/TGcnSYJm6amNaK5g0qXVH P7ufKVumjrKY8pZmqWOvZiNUkqUb+rkZvPJFo1yThsuUG8Yl/5QHUhMHY8xSkrH8idEsjb9M/RPv yQvwGm5pqmSpST2V139I9SoEWYoyPZllqjOhF2WKMj1dyrQIZYoyPSFlarwC0trKLhKkxO9uKr/m ldxrXvEGy9RrUKZFHYJpVHKWPpdKy7SgfY4bxBCUMVO9LI2Fm9/IUcZM53wQbr1WlOn8VfvBZbPU PxQ9DUKPCl9bGvtn0fHJUnWZuvL3Gx/BvbfN/FgyXZuXK1PB0wWz1JmpLrvuEW4/U6VMHSm13BHk bWK0Wbq2lO5nypUpN5VXnaUZs9Hw+odJkJqfz2d3jeFm8LpKO+navNoy9TTy/zVZ1/pImfLPQrM0 XKbaAVOCbWtTLFlKytfTHLB5WrhdY6jO4t7ApOBiyciZdI5b392vLM/Lx2k4Sy1u/lPCmtDK7meq lKl5DX9P/+iMLbVbO19XdZ+xGVtar7I8L8lSvV1NQ6966j1nxUhoEaR17VyZSrv7tdeZsribD8mr IWm2NGXL1LK1391idA7+8aMWzwDJUmcVP7pKs5SbwetunVR2jeHUrtYr73yaoJOliXyWevv4920k S5kyJTdqrzNlcTVPhVZDMsxSe8UhJUvZMl1UoPqPTpylKFOUKcoUZYoyPSPKtOHUlumTRQe4/UzJ P11lbaPBJr0jofxjr+YSQ2X6ilGZ6mXppc+l0TIVrokUI8ps3tvXHWOWhmbzzvkgfJaiTOet0muZ arPYLCX/lF1hYDZVyVLlFl1XhlSyVLlFYw6rdXl6LCsgmR/dbnuzyJlR597rpysgeWq7yT/tiXvD QRrZNYbNUmlVvrSqgJXuZ2p5Lp290fJ8BrufKVum5idTpTXFIdfKWpZmmx5OsSzNkdaW/H97dxfT Vh3GcbzRRL3Rqom369j0xkSrMdHExJzEC5eYGC6NV956R6LxYprYDPRiLqa+bKVgGNvcwMGATcak yNYCfQEKKWOCBWSFTmC8F7qF7M7n8G///XNegK6DndPzI98LkiXcf/ac//Ns1kvxDb1qmTo9Iel0 P8vpCdu+8XGWSrVRqXZAozODTm8fW38k7uZlMnVWRaWzMelcJrYESVOmjpN90m/Duc4P23+IEEvp F+n8LbkLcs6aIX7SlMm0tClOSRdGpLpM7DteR2VMqh+V6v8Riku/Z7L/HLOdGGAbkBRXY8SZqdQw QT51Dy74k2lyKOWKzJUFZhw1o4qrMXoytXtHpaaEXDNrSnHPVJSp1DItdznJcl6csnnGbJ5xZ8NU WXDBFV0icrLYO1NnY1JxNYbJ1FGXLPXddQ2stCTu+2c3qNqxtGtwtbRj3n4uKe7mVcuUcjTMlvWu uv9OE1H9c3Ku2Frp9aXMel7VPVO1TNkSpE+DKddQ2j/3gL0tdY/eK4uuO68u8Q1IhFOpY0Xur1UW 29DrbFuWOlelzhTLcWWZX41R5PhjhRwqZm9aJpbam+XveMX4NiSRpU5fSvKvyQWodUp+W8pZKsiU clxLlQ3dd49vEFGplpkHpM7S8D3lel6BpY72Nak7zbO3pjRZSr1xY51wyqLftVkKmUKmkKlpZaqH U8gUMjWOTCvCCeas08MzI4uZ/zceWUy7+6fZ7593xg+c7KJ2KVNdlh5vZzItiKXZd6ZHCmRp9p3p Q/8RDZZCpsVTnXaaj4sz7XA1RtlOu3m3djHXHtwzVX/Nq7hnyl+YCl3Rk6m4m5dAKtTG3pmy3by5 VDJlV2NkkPKEmam4m5fdM5U71imwVCnTTBVUQEh7Zsp388rJH/HyQmwDEr9nKso0W6/ccVZfrq33 TG0neAO7kamQ3j3TmzvOTDWvxmjKVNzNKzRuq+RNbH/PlH/Nmy2RPWaqfTVGU6bZ/pOrFVPfM51R yXSW3zPNxS7FiOnfM83FNCqm8zWvdtl7McpUX/Mq7pnqyXRLTaxVjZq3TUemmfRACpnusUxfhEwh U8gUMjWATN9+rDJlV2PoJzKTKg/dpiLZ9SZfXB9znOo+QIky/WU7meqz1MdkWghL+QakIzXKNSa7 /3nf6+cbkB76jxBLsQGpqMtXpnmyFDKFTCHTRylT3ZmpyWTaaAyZ7ohTyBQyhUwhU8h0X2Qqs9Ri Mu2d1ThE3hi/+1pN+Fhw8uPLN3cv0+rBJMlUaDmYXPYOTL30vY/J1BtNkExZPdNLPVPadSeoRUV8 N+87nhtdtxc3W9BoMlNA2Tz11o8+vps38O88z59P7q44dvMWe8afmWrhFDK1lkyHIFN9mWJmCplC ppApZFqUMs0bpyaXqbVmpm+e7Ve8LR1ZTJdUBt3R6TvrG/RPW2ammzjdfmaqvmdKLOUy5e9M+dWY F75ro57/lrpqr6BanyuXy+tqzDNfN7Ge/oq6JHf00lNy+V2NEarPpLwXg6sxFsn4MlXPTNUshUwh U8vK1JwzU8gUMoVMH4VMX4VM85GpzjFTw8rUajPT/ZTp2GOX6UfNuXOl5FBnbW+JN1gemqTfSaYO TzdkCplaMuPLFDNTyBQyxcwUMoVMIVPIFDKFTItHpj8N3mEs/aT11qGqUElVkGT6YWPs9ZrIQU9P TqanIFPI1FIZX6aYmVpTpjHIFDNTyBQyhUwhU8gUMi1KmVZEEp91xA9Xhw9Vh7hMqYOVPVymDsgU MrVcxpcpZqaQKWSKmSlkCplCppApZAqZFo9MX/41fJjaRqae4pfpk5ApUmZGmWJmCplaRqZnMDOF TCFTyBQyhUwhU6vJtAcyhUytmulkipkpZMpYagGZYmYKmUKmFpdpADKFTCHTwmU6YSaZVkKmkKll w8wUMoVMDSxTzEwhU8gUMoVMIVPItACZvguZQqbITBlcpuoNSJiZWkGmO+3mtYhMzTQz1cEpZAqZ QqaQ6b7LdJfHTCFTyBQyhUyRwYJMIVPI1KgyxcwUMjWYTJ+FTCFTyBQyLVSmc/sk02uQKWSKTBdk CplCpkaVKWamkClkCplCppBpccn0A8hUJVMZp5ApZIpM8M4UMoVMLSxTzEwhU8gUMoVMIVPINF+Z /gmZQqbIpEGmkClkalSZYmYKmUKmRSrTVyBTyBQyhUwhU8gUbQkzU8gUMjWwTDEzhUwhU8gUMoVM i0ume7sBqR0yNY1Mn4BMkUYGl2me90y/3BeZHoVMIVPMTDEztaRM2yFTyBQyhUwNKtP3IFPI1MD9 D1rKB0oNCmVuZHN0cmVhbQ0KZW5kb2JqDQo2IDAgb2JqDQo8PC9UeXBlL1hPYmplY3QvU3VidHlw ZS9JbWFnZS9XaWR0aCAxMjQ1L0hlaWdodCAxMTgvQ29sb3JTcGFjZS9EZXZpY2VHcmF5L01hdHRl WyAwIDAgMF0gL0JpdHNQZXJDb21wb25lbnQgOC9JbnRlcnBvbGF0ZSBmYWxzZS9GaWx0ZXIvRmxh dGVEZWNvZGUvTGVuZ3RoIDE3Mj4+DQpzdHJlYW0NCnic7dYBDQAACAOg6Ea/MfQbpCABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAKg0AACUuJ4jAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC8s+YN5E0NCmVuZHN0cmVhbQ0KZW5kb2JqDQo3IDAg b2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9OYW1lL0YxL0Jhc2VGb250L0FCQ0RF RStWZXJkYW5hLEJvbGQvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0ZvbnREZXNjcmlwdG9yIDgg MCBSL0ZpcnN0Q2hhciAzMi9MYXN0Q2hhciAxMjIvV2lkdGhzIDEyOCAwIFI+Pg0KZW5kb2JqDQo4 IDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FCQ0RFRStWZXJkYW5hLEJv bGQvRmxhZ3MgMzIvSXRhbGljQW5nbGUgMC9Bc2NlbnQgMTAwNS9EZXNjZW50IC0yMDcvQ2FwSGVp Z2h0IDc2NS9BdmdXaWR0aCA1NjgvTWF4V2lkdGggMjI1Ny9Gb250V2VpZ2h0IDcwMC9YSGVpZ2h0 IDI1MC9TdGVtViA1Ni9Gb250QkJveFsgLTU1MCAtMjA3IDE3MDcgNzY1XSAvRm9udEZpbGUyIDEy OSAwIFI+Pg0KZW5kb2JqDQo5IDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9O YW1lL0YyL0Jhc2VGb250L0FCQ0RFRStWZXJkYW5hL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9G b250RGVzY3JpcHRvciAxMCAwIFIvRmlyc3RDaGFyIDMyL0xhc3RDaGFyIDEyNC9XaWR0aHMgMTMw IDAgUj4+DQplbmRvYmoNCjEwIDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1l L0FCQ0RFRStWZXJkYW5hL0ZsYWdzIDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50IDEwMDUvRGVzY2Vu dCAtMjA3L0NhcEhlaWdodCA3NjUvQXZnV2lkdGggNTA4L01heFdpZHRoIDIwMDYvRm9udFdlaWdo dCA0MDAvWEhlaWdodCAyNTAvU3RlbVYgNTAvRm9udEJCb3hbIC01NjAgLTIwNyAxNDQ3IDc2NV0g L0ZvbnRGaWxlMiAxMzEgMCBSPj4NCmVuZG9iag0KMTEgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJl bnQgMiAwIFIvUmVzb3VyY2VzPDwvRm9udDw8L0YxIDcgMCBSL0YyIDkgMCBSL0YzIDE1IDAgUj4+ L0V4dEdTdGF0ZTw8L0dTMTMgMTMgMCBSL0dTMTQgMTQgMCBSPj4vUHJvY1NldFsvUERGL1RleHQv SW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNjEyIDc5Ml0gL0NvbnRlbnRz IDEyIDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4v VGFicy9TL1N0cnVjdFBhcmVudHMgMT4+DQplbmRvYmoNCjEyIDAgb2JqDQo8PC9GaWx0ZXIvRmxh dGVEZWNvZGUvTGVuZ3RoIDMxMDI+Pg0Kc3RyZWFtDQp4nLVbbU/jSBL+jsR/8Ef7tHHcb7Z7tTMS JBmGvR1NdoKY1cF+yAQH0EHMJQbE6X78VZWdpDtJO509TiMHB6qru+vlqaqunu7JvLqfjidV8Msv 3ZOqGk/uipvgqntRPv3ZvXh7KrrD8e39bFzdl7OPH4PTfi84vTg+6n5igY51GlxMj49YkMA/FqQ6 zlMZZDKNeR5cPALZ2YiJ4HZxfJTEUgBdrBIOnzIVwfy2/rt0/P3b2fHRVfgt+jO4+PX4aACT4sTL ubIsTu25rsLipVc+Rh3GwsAxirE8zrk96lsxgTEiLB9hrAgL+JKEsxv6MY5UCDuPOnk4Wzh4cs7j VNk8XfNLruJc2LRMBzDLCObjYfFUFY/09qOYO3ioRMYq95tPJVmsN6TEExIRS11jRBq3bCcYfOkF XYfVnJZVVT62Gw4P9C6rEah7SRMmwS1+nLVKUvOYmYOuwuE4kuFtrUPH1phAcVijnKJjWZykJm3Q SeIEfnUxuQr/4xzGZcztYQmN4E5xA1fevqbuJ7EhNCXExjQ7tBR0h6ifL73zfpBs6ICxGAfu8N4k Bc8yfYODa4BkH6M0LMAvJHiFAK+IWBqWM5ejpWDoqc3sZxdtlsTaJnX6bybjbGONJ0NY0hBc6NtX eLkcON00jUXmnoaMbiUDBcYF6JbEaTAvjo+mf9shUraBh06RplrEwjDtPariBt9NTjkZy8oaFRdk XEOWS93tz6OODsfTqAOoFXVkGPQT4ZRkCkI3+dVmum16u2yFwbiUm8Ovwuuwd47GMurSZy8CFLuO gvPBwKmSNIk5s7m4NM9TCdu1afvzMdjkFLReBVEWjqoIYByNE6w0pZc5PDfwBECDdOU8gL/8MRi5 phFaxlrb03RcEJQAkfBbvkxEnGc2bfFHVcwW4Ecy/BF10vABl18EA1jnC5hzMato5bsZLg0iTTEY 1AxH1RzHjR9BGO4IKGO2Mc61QcZ0zHKb1smXC9yZRfsJxS3Dk8kdbbJ4gf3c4yZnUScDpK71cj6r INaBbp4K0ucPpHqAjRBp9YbWFKB86qGo6QEGZFNGMvytvIXPRRAZFoC/H7wA/ZIMmJgy2ozou51Y IuZotxS2/Fe0+K8i2PZgIn3xOhUaU5r3wWuLWTteW6R78NqiPQyvndOYeJ2KHMVaA3aSJMwN2sob tDmmQb6YnbboHJIOlu/EbJXvwmxXpsDSPNa5xe8gzM54nJmjEbJPKRdERZyBkXR7J2cA2eiUgNoI lVsQixnxHnjt4RCyvjlmZOR2qO87sD4EuPNH+ILDb+lrO8AprdGC6vX+DuyekfvDPSbmb1FOU0Pk Qf7nv19HXh7NVBKL3Gbdqt3MrV2Vp7HcZZ9bTHJfj1agKJ2/k0dbzNo92iLd49EW7WEe7ZzG9GiV MRQreTToCUKy06O1r0crpZepn49Ls6RF61AdCbnTp/Uun+Zx4pQnI3kaDA9zagXFsjmcvPor2Mf7 OfRn3A5FX/TYOxx3WVKV+lBZrtwHIkVMCigNYXzvOaq/0+98EholOCZKy518vuyj+fdwcthID9eE rvAEnErMnVhYFVg/o/mVi6pOKBbPD7gQ8pIScwu/SI/5qBD2EtpNhLWYCCRPSnlx4d7IAMULY++F DCazPchgku5DBpP2QGRwTWMhAx5/KK9Yz4QvNOBpAuR43tAg3XqXmY5ltgsaWJI5qzGG1Zg5tAYB Z2bOOUZxY8BVyEDCCUKOhBcOTwZPF54+POD1kDJPq0C5VMA41mIWRz8I4kzFWtgjr8PBF1zKaRdX xcA6E3gyeAQ8dVWILr0Lkj4XY/Le6g451A5dYxHm7Gv7niycxRb4sdb2ipxFHKT1iWjf95pWIzBY tGjcxXxRzsa4Wirh9iBcM2M93Nhsvdc+VElQHBHaToo14KGHP8+WVdFkXOF09F7OnDUz5M6oGXNC lxy4hMI3s2mdfGUe58ymHTaBYI6rJz3WWofoJ+GF4wvq/+cAd+govmUSS23zbQThhd9CqThT7XvY bcNCkUqtkaOnYnJfnyjAlh4otP07ar5WpCRKaJ3WAtJnyk/6EqTPtJ/0JUg/EdvSL1+L+TqkVxh5 nR6yNEUFsLcE3C+oonJGpXodNdEeyynyNKx8ZeSyzgvIgKXLgH0DL6xD2MtpB2DVAsAgd+4XvlPf wIvn9lq9U+C1mLUHXot0T+C1aA8LvF7TcEGndRbtVQ67/oB1WLH4CQ0FYf4DwlT5U2NACAMf5iim yfOiCK7Df0AdeBuxDMLAn842CYtFy+7NfEByibRe+UDmnQ9ANFTMPx/I3eYooMpk+i/lA+ZQr3zA GHBFKQDlAxm91DnBVj6QtecDFseD8gFr5P+SD3iUKABchF7FDaH0BCEp3YlGdJbYiokiV+vsH/uJ 6Z7Yi7VHp65yyilNhoeXRTCFtdf10/fiB/4YFfOXKD0QGTWUh5m9qHZT1C2mCJW33BVetlsQ3u0i jJyJfidktJi1I6NFugcZLdrDkNFrmgYZLdr/LzI6l2Uio1BZrIQXMnLvXpaQCrvd3r2slmaWgDpb iB3ICEbPdDsyGkP9kHE94CpUBISdtEFCQEFQy6f+OXwbgdaYExJBKMxm5UynYZlc27S/PiNGITi8 BQ0c6waaERVd/XieC8zMLVaeSJxncbqxiOuw1x2hk3IwvMGoF9G5yvnoK6JS9xxXOOiRfHI6M1rm ehugvGzazPC3S+ceUxdrH74yjVJcdqwc2O5SpsSmv8nBrXeNfS6L1slW0ImkQRtgpx9Xi6Y1Kl3j ZEZNeHMcjSAxva4qIjwaQzmtmlKjNzyTwqsead2yGszo6sKyPVYUcwpkgAZ4eugql7D7L9rF4SiU hIpV1i4cR6GEybXeUGI5rWD5r7jFerMXBVrYolpuIm0pklJMtLxUKiXDkx8vlUqAKbGxzqGhEDJi RfXoHnNNSFQ1h78XeLvkDfi8UoF04wSpjMKZObYNoLRN2q+1Xzc4EZsu6FILyVOgPL0yh0RgiLAY t0N1S9+Sa8gGvQ4zuXfjkmd0ivA+mYPFrD1zsEj3ZA4W7WGZg3MaM0TzLEO5rkK0bAnR3p1LDiKR /oeZvKV3yaEiZ+ZRVw8tUTSHizGnvAZeWPOyLi8wqDpEC/Es5TZrV+xjkP6qjWV4Nka0Qmy2Rl6H Q7xcUce/72dN6MMghyEHPO6vNEf6xRRLqfW9hvrawvp8iAB+TX/Sw89rAB9BMRi5/ROmudwDRFzk eEZS78S64nBa0IlM+Qq7scJMv5lK4GJimGNjPrHJh+48rpj5wUyeYnZirc4zO9EJZifWyNHrSpYk wcndLd3WWJ5GnSwWBMGPzT0RWiuRe9ZTEpAZSiDncre9o6X3yzk4mtd5Ffdu/mKSqbP3QkWT2R5U NEn3oaJJeyAq+kzT1FMWrW89tbxBtKjGqyqd7gxdh4MbMyVDT16AkYN8ncUWJCe6RTQWkrMEbWHV sM5bkNy7Y810fkixJVo61iyHhMgJ5BIExLfwW1Fd4ryOklE73WTse3lQ4PULc+B1SO1kXNigO/pO PWvR9KyhHvbH5dWh/XR1Y8w6r6FpZougYYeQ7NA9FM+JsBb5mY7GqQXuGpRzvARnDnImszldLzZJ L8uHCvfpcy0Grw3k6Up6H5dHassHZXFZWze+fnpeFAs7OJxMJgSliwgwf1HO6yt6nqdSSmEVYC2i 3TJbGuVM5Rjjfbh4N8qZxAu87wOiJq92DDUp90CoSXoYgromMcGISYEi9QEj0ZL1M8HiLPeHH+mN ayzHWysbaJQ2hyIrNKK0chOSXA3sJq20WPviUYaXZ6yRNiANwVj6v10259R0TL2NSphPPuO9tBvy 3/XxL7XGiuDkCX480RFJc0pNjcTGBnFrda9t9Iw3VAkEHFtVWNNtLNiFM0uJw5DVxeNhcymnrIpJ RX5PpWbQwzWsbtfM8L5Oc6V2HUaN1QVD9KtdjDCJ6xcvdZveE1OEApvV9kJ9m7egP2aPtO8A/wtW 9bzKzXF3BAR1MKiaxiX1UOfNlh2gnaVba3QDPKPw2LafNS0odFtH1mEFazsKarSMzYLVfwc5a/J7 UiDezOLhYnKHNzLnqwtbF88/UGGL4Do8618sILvaSvvX8KMRfqwp2uGgpUeb4X1dJ5f/AnIYJbQN CmVuZHN0cmVhbQ0KZW5kb2JqDQoxMyAwIG9iag0KPDwvVHlwZS9FeHRHU3RhdGUvQk0vTm9ybWFs L2NhIDE+Pg0KZW5kb2JqDQoxNCAwIG9iag0KPDwvVHlwZS9FeHRHU3RhdGUvQk0vTm9ybWFsL0NB IDE+Pg0KZW5kb2JqDQoxNSAwIG9iag0KPDwvVHlwZS9Gb250L1N1YnR5cGUvVHJ1ZVR5cGUvTmFt ZS9GMy9CYXNlRm9udC9UaW1lcyMyME5ldyMyMFJvbWFuL0VuY29kaW5nL1dpbkFuc2lFbmNvZGlu Zy9Gb250RGVzY3JpcHRvciAxNiAwIFIvRmlyc3RDaGFyIDMyL0xhc3RDaGFyIDMyL1dpZHRocyAx MzIgMCBSPj4NCmVuZG9iag0KMTYgMCBvYmoNCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5h bWUvVGltZXMjMjBOZXcjMjBSb21hbi9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCA4OTEv RGVzY2VudCAtMjE2L0NhcEhlaWdodCA2OTMvQXZnV2lkdGggNDAxL01heFdpZHRoIDI1NjgvRm9u dFdlaWdodCA0MDAvWEhlaWdodCAyNTAvTGVhZGluZyA0Mi9TdGVtViA0MC9Gb250QkJveFsgLTU2 OCAtMjE2IDIwMDAgNjkzXSA+Pg0KZW5kb2JqDQoxNyAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVu dCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250PDwvRjEgNyAwIFIvRjIgOSAwIFIvRjMgMTUgMCBSPj4v UHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAg NjEyIDc5Ml0gL0NvbnRlbnRzIDE4IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVu Y3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgMj4+DQplbmRvYmoNCjE4IDAg b2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDIwODM+Pg0Kc3RyZWFtDQp4nK1ZbW/b NhD+HiD/gR+loaH5LmlYCySO22ZAuyA2sg9JMWiOnBazrcBWVgTYj98dZTuiIzI0EAxeHfl4PB7v efgcNThdNT9m5bQhv/02OG2acvq9uiM3g0n98G0weXqoBpfl/Y9l2fyolx8+kLPzITmbHB8NPnJS 0MKQyez4iBMG/3FiCpobRTJlqMjJZHF8xKiS8CvVTMD/lZFkdd/39OrT8dFNcpV+I5Pfj49GMAFO svWbZdS4fm+S6t9hvUhPOE+IZxTnOc2FO+qqmsIYmdQLGCuTCv5gyfLO/lOmOoFVpid5slx7fAoh qNGuT9/8SmiaS9eWFwRmGcN8Iqkemmphv/1drTw+NFNU53HzaZbRYi9LgtkUceMbIw0NLIeMvgzJ wFMhZ3XT1ItwkQhS9FWIxL1XbYUQLAjyKZjJQlDeHXSTXJapSu7bPfQsjUtMhzPKmzqeUWa6tuSE UQaPJtOb5D/vMKGocIcxO0J60w1eRTimwUe5lzQt5d40PbtEBpe4P1+GF+eE7e0B5xQH9iCVGUBW FxsCoAGZXaQmqQAXClAhARUpN0m99AHNQKEb19mvPtuM0cI19eI3UzTbi/H0EkK6BAhd/QFfrkde mBoqM/80tuh2OdBQXMBkjBqyqo6PZr/0pJTvcZ83paaQVHZK+5WtEh2/+55yWyybzRldX8BOjOFz 8Qes/6svaVLgXjhjgwHIQADGIPlEOFEBJ9oW7w5TWkgLkUsulBicr9KTIiln6Qlwb3qiEpLDk8wL IJ5JynPHaYu4lyjqK3ueGai+zuib5Da5wHlPxwMkEyyt4UUKp8FtSi5GoxHkm0Clna9KQMQMvjUk zZJP8PjRguIOvlVkBs/qFQGT8YM9YVgCv0o74AnXZv9a3tsVbkC1xHXebfyPq3kKPF1Nm9YSf7vf /IYx1T+r1bs092Jlm2xZ4JHXrmwIgAXsriCq2np/B452s99tY8GI7aQlTjr3JT7nVAh3ghOvLaAv d21xEY8YygNMXq8rTDbOPsS8/g3P5hhCN5M4omqwPFY4pM3P4+LFPvdhUSpFOXcjiKsQqTI8tJ2R m3yZNuDvGBec26bd1GmbNrKtnvkulcsG/twXEv3xKl1Qk/njfQE4HQCcwCM9woeJPSUMt6B7m1PC cRY+JRzTV04Jx/awU8I7TfeUMJAdIzbHBGOM+4+KLPao0EWBocceFbl/zzUgTok+kjVS9pDsuZdf TU6L3PF3GL8KmnVHI79eWcWN/CqS8RB4NeUqQW5FlO8RK1ZXvl9coDY94UpYP9ubEPcdGQNL0tKp TqYVqZfoflzPGnD4E+dcWeYO86mG9RTPlT/f8KQExkL8z9MNszeI96coqHMhAZ6O4+CuF7Eo1cgh fWLnpZZhgUqCVkCqN8K64yyMdcf0Faw7todh3TtNF+saTo8sb7EOGC2KgCzkgVSiFMui4c1FNG/w gmrdi3bTK6moX05xm9COw8PgrqF77w5/1lOooVrMt5rqNsXveIK20OdZNPaNB9MznKgVC+fVGt1b MKJusmjvnNthlEObAGphU08PDzBi3s5RNjvxhgQCOmy2O+hRkuEsozmagnKzMmWJyW+FwZpYkFgt h+se4c1CK3PQGJ5uBMQczQgyytZvnMjRjErtRh8pcrSytNkdOX6CENd4I2FiRQsDSSj987+s8ECv gS1+VkR5UbGMqLKCquyNuMxxFuYyx/QVLnNsD+My7zRdLlNZRgsepVu4jiUgBY0hk/HMZgL7rmHf eefoHiK+JCw/gw9lADAOXxh8BtiHwWdVzhrEIj5X3hYkQ2ZyvEdyWsGpdAfeJpcjnH+MBfQn9n5W xMg+EeMTKiynrAjHs7OFoIq9EMKsZNtRSyjIds9NFPLwEAP8/AM1FxLjd98VG1C53AvQ19+pnL1I 7nXboDWYiPsIZaWg1RHb4h3adSF/Th+RJJ81FfLm2QrPgfIfXNpqjev9QGxZGCiLE6wNYz9oe11O cb1XJfZe7dnRpqiMojRRAKVKN7i4shEFUKp2RwKlAqcj2VjCaXAdbs9okuHj5mizchRaxrYtPitx i9dgLWLZWHEEujf0l6jMAqgUmhZRTSTPo9mYC6r5W7Fx19krbNw1fY2Nu7YHsrFvGoeNOcO8RrFx EcvGEtpIXsTfOAbUv8z1VrL2sbHasHEfEzNvZm1b4niOZOJc4jWSM/I2sS9MMLTRYPznJyRi6VWU 4wbf6VgJWG4gtr1w6xWME/s+Yd2s0QK9tOIyhj0N7qsTqp89hX0H0LUF9oxmTgmto5K7fHzgG/pz aPBZbX98XFdrgs53V1in06m9f1ujRl/XK7u8Ko5mhNZUFG4Q4XILdEgSWlYWJfqEiKUZqTS+oXsb mnGchWnGMX2FZhzbw2jGO02XZvD6E/IaQzNCRtMMtLMyXvSJwDsBCQ0j64o++1rjr4DW899XtfvU dRjJLhCLzt2Rt4mVeKfjM9R6MhkOLbkZkJlm90IAsDI4tXdZCJ8JBP1le5W+Rz+nCxQhLbym5XJz +/61bLY6oF6WqBBsT2iv4vf5qvOGYEtHYW5gmuotqdiwuqoDqdLtpHdia7r/FtVzeQUtpxHuNOEq CFxUC2j5RJTIENFX1SLLaf5WIsNxFka/Y/oK+h3bw9AfNY2QjAru2t7ksOr3T2kOPP8OaxNPivdY kvW7tC1erPP3+IammsKRQW6Tz/UMG4nFphqXt+k335EmJTYP3ui63CSgIRUdCaQC3BRQqAK2SB0g evJYmhPQ1fC42i4C4cmcZt7z8X8c+EC2DQplbmRzdHJlYW0NCmVuZG9iag0KMTkgMCBvYmoNCjw8 L0F1dGhvcihzaHVhbmd5dSkgL0NyZWF0b3Io/v8ATQBpAGMAcgBvAHMAbwBmAHQArgAgAFcAbwBy AGQAIAAyADAAMQAwKSAvQ3JlYXRpb25EYXRlKEQ6MjAxNjA5MjIxMDE5NDAtMDQnMDAnKSAvTW9k RGF0ZShEOjIwMTYwOTIyMTAxOTQwLTA0JzAwJykgL1Byb2R1Y2VyKP7/AE0AaQBjAHIAbwBzAG8A ZgB0AK4AIABXAG8AcgBkACAAMgAwADEAMCkgPj4NCmVuZG9iag0KMjYgMCBvYmoNCjw8L1R5cGUv T2JqU3RtL04gMTA3L0ZpcnN0IDg2Mi9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDEzMDA+Pg0K c3RyZWFtDQp4nOWZXWsbVxCG7wP5D3PZ3nR35nxDCITGoSHEmNjQi2KKbG9tEVkyyhqSf993do5T NaQXmssGjGd3debZOTOPVsaSSCNJoZpIKnHIJI24Fgq4HCoFxvVGQSjEkUKg0BiHFCOuJIoNVzKl GCkUSi0TcnJEXqMyjoSckoQiUx2RJLhPphiojRUIahlLEvHIWJMRMxYVYmasQjmcsQz1iIyURsQi lBhlSiRgORTcOxBH1J4iYsU68BLqxY04VawDL2uN4OWKdeAV1IVbc2lCGZyKWjI4FRtACdxw84yO jNhCRktG3CwXEsYmUJIw4LkRyqrYJiJgBZ0K2AdKlIDkEkgi4/WIiBcLeAl1o2RJpRB+JKPLBbxc AxXwCuqsOg+0vGrntWOiE0iEJaJ1YUthHFknFkZsuqLnPGKCmBmjDmwxCAdapobim46NG+ncAopr OkpJpJOLuHkDL2HMuEXQfukMM4bZwMtIbuAU1MHoRShYjWlhysu4gKoNfR3VCx2QDnkcdTHc0Oow Ukx/1MUFBzoEHT06iYOGA207TiJq17njAI1l9SEKONhIjGgdM8hJFWWQE5qzOJKhIjPIuao2IOto GduNBRtkeBOXUgXk2haVYJS6IwFKoUxWl0YtDE1JWgILbGH1AG+MJMDrWtFBqzaQGbQMCTF4aKNC JGiD7WRcz4CjJ2hdoxcvhjNNHunDcD68Wd8+7qfh1Wb+6e3Jyclmmudpfzetbv68Wu1/edje/kzD xZeHaTif94/XMxbcD+/+oPGShrNbWigvXz5/9m/o2fdS+PiUcHxKPD5Fjk9Jx6fk41PK8Sn1+JTm GKVn/I75s2M07JCGHdawwwF2SMAOC9ihATs8EIcH4vBAHB6IwwPxPD0cHojDA3F4IA4PxOFBcHgQ PJ8HDg+Cw4O+HXzsHv3xdlSOOHKCIyc6cpIjJztyiiOnOnKaZ6YuETwmsEcF9rjAHhnYYwN7dGCP D+wRgj1GiMcIcT0bPEaIxwjxGCEeI8RjhHiMEI8R4jEieIwIHiOC6+PCY0TwGBE8Rjw1rzg+aY/J EUdOcORER05y5GRHTnHkVEdO88zUJYLHBPaowB4X2CMDe2xgjw7s8YE9QrDHCPEYIa5ng8cI8Rgh HiPEY4R4jBCPEeIxQv7DiPEpabWfv99AXaDfDSyhWmhLCKMFtiAWggXLC8lCtmCUYJRglGiUaJRo lGiUaJRolGiUaJRolGiUZJRklGSUZJRklGSUZJRklGSUZJRslGzp2dKzpWdLz5aeLT1berb0YunF iihGKUYpRilGKUYpRilGKUapRqlGqUapRqlGqUapRqlGqUapRmlGaUZpRmlGaUZpRmlGaUZplq7/ 57fIPUqPocfYY+ox91h6rD12Hncedx53Hncedx53Hncedx53HneedJ50nnSedF4XV/+db7HzzORL 6m+BA+Uv9tP0Ybebhw+7zfR+9UCG1rfGtF1eJbuJPY0Mc/Dq6fR5fjd9odDRb8Da7uZpONVfJ9ub f04usPRq93k4n67n4bdpdTPt7Vhzno7fbjfr7XR+t9IK9cKrLQireb3b9vP9vP5rhYPl7Pfd/uPV bvdxeL27frxHTcuVT3fTNNu7+/3qer87OP/1Dr8Pzl+vV5vd7cGF8836ZjpYa/fBstv96r5/j9H3 evp4/wl/W9JTt/U7kOVJoV+CfO33t4+T/gD55qnyv3mcXJJu+Qd+plgDfrAHy/NnfwNrnqC1DQpl bmRzdHJlYW0NCmVuZG9iag0KMTI4IDAgb2JqDQpbIDM0MiAwIDAgMCAwIDAgMCAwIDU0MyA1NDMg MCAwIDAgNDgwIDM2MSA2ODkgNzExIDcxMSA3MTEgNzExIDcxMSA3MTEgNzExIDcxMSA3MTEgNzEx IDQwMiAwIDAgMCAwIDAgMCA3NzYgNzYyIDcyNCA4MzAgNjgzIDY1MCAwIDgzNyA1NDYgNTU1IDAg NjM3IDAgODQ3IDg1MCA3MzMgMCA3ODIgNzEwIDY4MiAwIDc2NCAxMTI4IDAgMCAwIDU0MyAwIDU0 MyAwIDcxMSAwIDY2OCA2OTkgNTg4IDY5OSA2NjQgNDIyIDAgMCAzNDIgMCAwIDM0MiAxMDU4IDcx MiA2ODcgNjk5IDAgNDk3IDU5MyA0NTYgNzEyIDY1MCA5NzkgMCA2NTEgNTk3XSANCmVuZG9iag0K MTI5IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDE5MDE4L0xlbmd0aDEgNTMx MDg+Pg0Kc3RyZWFtDQp4nOx9CXhU1d33/9w7d5n9zj6TycydyWQhmYTJnpAEMiQECAETSIAECElI kEWQKLiwmagoELAWUItCW21dKLY6ERWwFNFatVqraK1L1WrdLahVXF4hM9//3JkE1PZ7n+/9Ph++ h2d+N+d3z3rP+jvLTJILBABsSCpomtBcPyn6zUMRgP1fAzjWTZpQNxEy2UPo1mEs76SmxmahzFCF 7lx0l09qnlnzTvoHmejuQfcNU1uaJy/Of2o1gAbd7G8bm0OFK1+7YiMAeRnDO2dNmNa66l/rlgMY fADcm93Lu3ovXjfwCsDyPRjn0e5LV/lm+c/PA7i8HN2fnd+7aPmauo/TAVYsw/gPL+pa2QsOUAM8 eAqfJy1atvr8aSWb8PlrsDzZ8xf3LL/cabs/DGDF4LY9ixd29byx6oIf4bPmoUfpYvQwNWnmovsG dKcvXr7q8vNc8jcADOYn5i5b0d0158qFGPbLrQBC7/Kuy3v5DL4G4x/A+L4Lu5YvPO/jg10AezF/ 7Zu9K1auil0OL2B5XqPhvRcv7H1j7etHAS7B8rBqoG3LCff0hy8xdRirvgC3CBS/Wdb8Nb0/ue2x x07eMrRDv0fcgXHVwEAcmE7URmdgO5Vj+EX6PcqTzkQH9WH3w3hgFTcDEoRhJlo47uG4j2oLcwg4 ELlbuCJ8ZEb8zt4KL7CcCIxWVLGcSsWobgM+FgbfXNqiNOG0Zp8P6PUb3httg6dELbnHB+TnNEzV zR2lNQUiJoqEeSiGLYenVfvgLvg3ULXBI2juPNOPfQkuZN6B/dwGWMtFoJeLEA3eD6LZiqYFze1o rkWzG003msWYx1v/7vkUfCk4eScc5p6CRfzteL8MTTEcVsL2wWHVfFirughyqJtzwWHhRjjMP47m GVjEvZ6IV4Np7oXl3CrIVtyp4FQLUPOdunyduD+uPCsS+1S5t8IsbifsVT0ArXifwzVBK9sFweF0 2Ea3nmHfK14Ge7l9aK5Q4u9V2uQbTP8wdLB3QBDDbsP+8gp/hTzl+SXgVT0OLf+p/kkkkUQSSSTx /x/Y/YRYrTnKqgpOJ5KBnIGceCwtyTLKBsg2ESAFJr0BDNY0yEinSfAioOMlXqdVdnfW3Gw1Dzqi yZYlZTeZRBJJ/CBANVKADr4WYyCCGIviWUWDrFFYC1pkHeiQ9aCPDQEqF9kIRmRJYROYkM1gjp0C C1iQrWBDtilsBzuyAxyxk1TqyC5IQU4BN7Jb4VRIjX0DHvAge8GLLIMP2aewH/yx/4I0SEMOQAA5 HTKQMyATORP5a8iCLORRMAo5G7KRcyCIHET+CnIhFzkP8pBHw2jkEOQj50NB7EsoULgQCpGLoAi5 GIqRS6A09gWUKlwGZcjlUI48BsYgV0Bl7ARUQhVyFYxFHqvwOBiHXA3Vsc/x1DYeebzCNVCDXAu1 yBNgQuwzqIOJyBNhEvIkhSfDZOR6qI/9C6bAFOQGmIo8FaYhT1P4PDgPTyWN0IjcBNORp8MM5BnI n0AzNCO3QAvyTJiJPAtmI8+G1tjH0KpwG7Qhz4E5yHNhHvI8aI8dg3aF58N85A7oQO6ETuQuWBD7 JyxQuBu6kXugB3khLEQ+HxbFPoJFsBh5scJLYAnyUliKfAFcEPsQlsFy5OUKXwgXIq+AFci90Bv7 AC6Ci5EvVnglrEReBauQL4FLYu/DpXAp8mVwOfLlCq+G1chrYE3sPVgLa5HXwXrk9QpfAVcg90Ff 7F3oh37kK+Eq5KvgauSrFd4AG2LvwDVwDfK1cC3yRtiEvEnhzbA59jYMwADyFtiCvBWuQ74OfoT8 I+R/wPVwPfKP4cfI22Ab8nbYgbwD+S24AW5AvhFuRL4JbkL+CexE3gk3x96EmxW+BXYh71J4N+xG /in8LPZ3+JnCP4dbkW9V+Da4DfkX8MvYG/BLuB35doXvgDuR71T4Lrgr9jrsgV8h/0rhvXA38t0K /xp+HXsNfgP3IN8D9yLfCxHkiMKDMBj7G9wH9yHvg/uR74cHkB+AB5EfRH4V9sN+5ANwEPkgPIT8 EPwW+bfIr8AhOIT8O/gd8mF4GPlhOIJ8BB6JvQyPKPwoPIr8e3gM+TH4A/IfkF/Ck/bjyE/AE8hP wpPIf4SnkJ+Cp2N/hafhT8h/UvgZeAb5z/As8rPwXOxFeE7ho3AU+Xl4HvkFeAH5L/BiDI3Cf4WX kF9S+GV4GfkVeDX2ArwKf0P+G7yG/JrCr8PryG/AG7Hn4e/wJvKbCr8F/0D+h8Jvw9uxo/AOvIv8 LryH/B68j/y+wh/AB7Hn4EP4EPkj+CfyPxU+BseQj8Px2LPwMXyM/Al8ivwp/Av5X/AZ8mfIf4bP 4XPkE3AC+Qv4EvlL+Ar5K+Rn4Gv4Gvm/4L+Qv4GTyCfhVOxPcAqGkIcgihxVOAYxZLq5AvaQWqsG llVxyozP0ZuK5U9DFV8KRIEXeB4EjMCLgiiA4tLSJHjxwPMc/gD9UIpVYzJQceihBp47W4tXEkmc 69DoNFS7vOJQtMuphNNIaFctCmpBABFVyatFtUjFDCL9YJ9qF6WM2hYS2tViMuB4ThDUKPGzVrEk kjjHodVpQaVSCYqDp1LjVeJpjGgXBSuCmq62GjXVLroU7aKY6ZEMF2ORo1/igUpHw3iBE0UNSvys VSyJJM5x6Aw61C4X15hAb6hd9QgSe160aVCRGh7XXq0Gt9lUv2oDxLWr/g/a1SW1m0QSPxj0Bj1q lz9DuwKn/p52NQi1GrRUu7ph7WpOaxedSlyqXQMmw1Mxr1brcL0+axVLIolzHAbJgMdcPq4xkd4E TnMaifOqFqFB7dJ9s16LR2StBo1Ek+ClAVyVNWo+oV1MBoLIa3BdTmo3iSR+KBglI9WuWnEMa1c7 goR2dVoUrAZ0dN9s0Om16HGGdrW4LouKzql2JUW7akGD67JGfbbqlUQS5zoks3Rau2p6E3nt97Wr Q8FqQC+qQWPU4xEZF1/QmWkSvLS4Lqu1WiGhXUwGolrQaiTU9FmrWBJJnOMwWUzA80JcYwnt6k4j 8VmTXq8z6LRgoGdeyUC1q0Njgbh2dYCrso5qF6XOmzEZiBpRpzXh1vqsVSyJJM5xmK1mql2t4lCW SbWg048goV2DQW9ERRrpKddkNOrBoNeBgf4llAYvPeCqrNeJce1a9Do9qLWiHtdlnfasVSyJJM5x WGwWEATxW9rVG0aQ+KzJaDBIqFZJgyddsyQZ0EMPRhvEtWvAdVmr12NclLpgNeipdtUGnSWp3SSS +MFgdVipdnWKQ0ulphEM39OuZDSYUK0mjKC3mExGwI0zGB00CV6oXYPOMKxdGyYDjU5t0Ftxa33W KpZEEuc4bE7bd7UrGowjGNauZDShIs1aPOVazWYjFTNI9O/TqHaNYDDqjAZ1XLt2o8FIf9XSaLDh 1vqsVSyJJM5x2F12EEV1XGM6KmGtaJRGkPiOx2SSzKhWM0Yw2CwWCUySEUwumgQvCfAIbDSq6TdG IDokoxG0eo1ksCe1m0QSPxgcKQ6qXYPi0FOpaUXpe9o1m00WVKsFIxjtFqsJ8NAL5hSaBC/UrmSQ jJq4dp2YDLQGjYR7aqPhrFUsiSTOcTjdTtSu5gzt6tSm00h8x2Mxm6yoSCvVrsNqNYPFhNp1Q1y7 JpBMBpOU0K7LJJlAZ9CacE8tJbWbRBI/ENxeN6jVyq9IAW59kfQay2kkPie22ax2sxkcGMGU4nBY wWYxg81Lk+BlAbNFspi19NteUHswGeglnQXXZbN0lqqVRBLnPDx+D2g0OpPiwKUVwKCx2kaQ+JzY Ybc5rRZw0p2y2+WygcNmBbufJsHLBriNtlp09Bsj0Mg2qxUMJr3NkorL89mqVxJJnOvwpftAq1V+ RYp+JIVk1NkdI0h81uRyOtx2G7hNZrB63W4HuBx2cNL/bGbCywE2u8VuM9BPnUGb5rDbQbIYHTYZ l+ezVrEkkjjH4c/wn9aumf6GsqRzfE+7KS6n22GDVIxgk1NTnYAbZ3Bl0CR4OcDusDjsCe0GnBgm WY1Omw9s1rNWsSSSOMeRkZMBer3RrjisVGpmfcppGOOxPKlu2eUE2WoDZ0CW3eBJcUEq/XejVrxS wJViT3FJ9JMr0GeluPCgazel4LrstJ+teiWRxLmOnFAOGAzKV7V4rKW/KWU1erwjSJxX/T5vwOOG AEZwj0pPl8Hv9YAvRJPg5YVUj8uTios2Lr2GXK/HAzaXxevOBrfrrFUsiSTOcYwuHg2SZHErDheV mt3k848gcV5ND/gzZS9k4Yrqyc3KSoN0vwyBYpoELz/IPrdPtigvHJEK/D4fONw2vzcPvO6zVK0k kjjnUVheCCaT1aM43FRqTnNa+ggS59WszPScND/kuFNxtc0JZkBWehpkltMkeKWDP+AJ+G30kysw laSnBcDldaT7C3B5PmsVSyKJcx9M4pVbVmCpjaSg4WHk1WCEYWDkDWLDoG8JS/xTZy39HkkymS1W m93hdKW4U+MTAaRnZGaNyoZgbh6E8gsKi6CktAzGVGDIOAhDDUyomzhpcj3AVIDGpukzmmHmrNmt bXNgXvv/4wqy/7NkKtiDnAk+tPGQBtlQARNhCjRBC8yGudAOHXA+LIFeuAzWwK3wm1gM6DvMRkEe jIfJWK8ZMCsRrwvjLYOLYXU8Xuzt/+bqjnV/791s/xHhipbystKS4qLCgvzQ6LzcYE72qKzMjPRA mt8nez2p7hSX02G3WS1mk2Q06HVajVoUeE7FMgRyScRZ2zroEoJu3Ga15SXcKd92R9gM6TN/BMzf iuT+TqLU77g933F7R9znRcAamRionUAfPAgT34uAJUKsEaC5EMs0zCmRqK5naaBuScRV29PZiSkm BCRfZOKnoURRlGcPajW1gdqFmrxcGNRo0apFG8btHSQTxxHFwkysqxhkQNTn5UbMwQiTUUfN0kh4 SydaAhPwSRhiOR1yIHZk65lBgMmGbZa4jUT42oig5OtbEgl3RWCLbzD3yMDWAxIs6AzqegI9XfOw 5bqwjIPAZtQtbqHtWEdN52JfRIUPV8iNPr66xb6BAG2OusWdyIEJmOrf+qO3urZ1o/+IO2LGe13E FIxMwhiT1rzjZgfqnEt81DkwsNEXuXV665mhfsptbW1OLPBAXQAfiA+rW1qDVXGG8nLjdUo0QE/n Uprn0i5azrqlvoEtC5WyblXKoEStW4wd0/XfxRoYqOsJ1PV09dTEn14bCbcoN2iZ06pUEJtuQlvC KxEBQ1RKSOeENn+8sRtmtNbSggW6Jrjj3T7i05nwQY+64UAfLUE9PiDi6/ZFYEZrAKOWU1pYDgPd 5crg8bcRTNV0OlWEy5ACvoEvIEI6A8ePfdunK+HDZ0hfALVODEzsHBiYGPBNHOgc6DoQ618Q8EmB gcGGhoHeuk7MtakVUx2IPbTFHZm4tS0idS4mFdj2dARMnNFa7fab2oadTcNOwCGFA0urVAdbAX/q EzdsZWhp9fuwoWa2trmxnVqpvQXt8TsdSDhwy7GPE81G22hh+Ujz1Casfj8dnVsOhGEBOiL901vj bh8scN8H4VAQ+6OThhwZDrHNpCH9wyEjyTsDmMv9ylRli4iZIz9GyW6pW1wRIfb/TfDCeHjEUtvK upm2uI1xs9SmCaLSqyKOINpHBQewE54LRKRghGs94q5q80kmnAFo7zUHGqbPafXVDYyMgrhPoqZ0 HOBQD3QtHkhIiQ56nApqBgNk0/TBMNnUPKf1oITz9qaW1vsYwtR21rQNpmNY60EfTq2KLzPiS10+ 6oIGOgDvY0QlyH0wDNCvhKoUD8XdfYCA4icO+xHoPsDE/STFD5EHYXXLB++ny++/Z5Kx+8I9f9VJ peFXyEvbTfIzaP6E5mk0T6H5I5pH0PxqV7q8G80tu3zyzbtGybu2u+V/7bTJd+10yT/ZmSPftDND vhHt4Z1kJ0Y3fkZu2O6Sd2wPytu245F5O6EZzduulUqNh+RDoUNs6LcEDkoHGSOW+QHi+7rva0b6 yvdV+Cu27wsinfCdYHwfN33MhI5VH2s8xua/2Psis+++UfJ9+0xyaF/1vs5Ib6T3L9y776TLb6MJ vUMz2PcoVoRmFLsfLc/3jZaPonmuzyc/22eSj6B5GM31h2OHGePvSOx3ZPBek9x7L5H2+PYwWzbn ywObQ/LmviJ50wanvBHNtRvq5Ws2mOSrN1TIG/AxK/beujey99O9qvBtRJrnmxeex36OT7yqzylf 2TdF7sf7FZjjejRNfZ19vX2sZPTLdluOLPB+2eXMkVWsX7aYc+TcPGNO0DAq25iZZUjPMKYFDD6/ 0SsbcDOjxz2NHrc2etzh6I2SSafTG3RqjVbHC6ION0E63CHpJGO/kQnz/TwTZvtZxgjV0Ah9oDJC CK1hzwp0PAzPQgxEd6UoGytEmR0jylAuyk1FJGJugIaWmoiF4L25JlIUbDggwoxIYbAhom6a2zpI yI/a0DfCbMLuaYmoNuEoasH5f87c1gPERYOvUZYDtB0g/ddcd517xNbWFvREehqaWyO9nrZIIbX8 2NMGQcTKVStXrgz+Bwyqae49M2oGP1TRxaIr8mFgwuBHHyoLR+SjwASSSHrmM9CKDx1xxX/OAAQv UfxXfS87JRFOE7yV/qIRdxTkYf7WlqwbAvQeU97XGnt92B7tiX3xP9vkfR9iwvyfgBxlsv9v8yXX k2tJP2khl5Hl5BKyhIRJN2lDvhpdK+AeJdId8CHxERehr7kLEBMR4CTJIB5iISrQoPsYxjmhxPyp widIBXzOxN9uuwXNw/AXeAeOQ5QY4DBei/DaC7fRtzMRL8kiY8hk+Bifnopxb4FBOIhxnsQ0f4P3 4FMikjnkUjJAbmD0zCRmDsZzklqymZnGnFSlg0AuY8xkEfsQOUF4YiPp8BD8CV5lI7EPyK3wJpvH 7IPLcVf8AikmYfYONoeVmaPMHZgTQxcIgf4HERZv1v08gztuNKFnXn9GoYJ8v8lvykAiGOubfg5O 0jv00yMIA08jLcfRQlNnhu0syzDCnzl4XfU8+3oj18ExXKOatIfa3xl6B0JDhaHqgnzC+lmCz2OW j44+NJrsii4jN3BHT76mSv8mRER85l3sEyodb1WeWRoO8AI+lCXwrJHtZHtZhOpZECRhhdAnqISQ OqxmMIPjRWiguihkHjOG5hFQLpWu6h9Vg2h469A+Zho19AT1SLSH3Yc52KAqnNtIGpgGvlHoIB3C CrKCWcHjk0kf08f3CQYBiFs00mXUeET1gF06QfMpgmpaj3biz2RMkrnMbzMQgWdsVrPDSxzsvujG IwcPHiGrp++ormqoH1f1k6Zoz1vkNeLG67W3PPUH110WfeP2u6Mfrbv0kUm0PHdieXYOl2cCTmRh ywRrE9tk6WQ62U5Lp7WX6WV7Lb1WgxlUbjREpdIegQcd0pffKo/ECP6ScaSs1FxSzGSNJlklfruZ 3XnwSHRj087KcfUNVdU7ppPVRw4yVdF3o+lveSYduWwdsd99O0m7bN3Bes9b0XQszYUMzy5hM7H9 U8MSeYmRoJOeQpkQ18hhU2OGEDqO+WEfskuGOOYkwxMfptuPcfLIZkznDpuYVwg8B6SRdJAVpI9w hHYPTZZNsOvzogM4nDfTuq+NHlI9ofR2adiIx2Dye4a1YofTHA/EPggb1FIZOCnR0cpgbUM4XVWH CvI3cqODG9c/piZ+onri1PvRZ1g7b/16j9CKpe2NvcWFuU/AgbNWXbigjqnTTDFMsa9iVmnWGtba RfeuCvMUM2MW/LtK+Dqe4V1OpTSQ4d0MOqLD0priI6r9OP4U5LcTKyMYSCAtMyuTKSk2l40jRYV2 h93MSZmBNN4k2YsKS7nwhMlTPth717H6KTUTpkw5dvvdH0ypr4muX7p27dJlq1cvYz48FH2po6u7 Z8ECEjj0KPF2L1iwsGdB9K1DxPDuu9FPo1999BGWguA8rDrGvQhGKAnL3K/6eMLzOt7A7ibGPQad YYDlmD3AVrMrUAyh9hOF0vExkqKvalrmeBub/CWFpVjKMrSpjp3ykoro45M35BYXq0gDKSIq1vK5 yeZqqjoZovU+iHP+FO5j8MCWcL5hnV4qY0xWk1+fYSrWF5smmWaZFthW2TTAGI3amy0Ck3oL6YTO 1F7oTVWl0o2GXemhVEbc3G8ndvtWWZKGu0v6EgtlHoP91q6UEYdsbUtr2G1ktE6ZcTtDTNBZ6Zzi nMvNdV7AXeDsc+jb22iLB7NJSWk61qGkmLaxEDCVphf5VDYrjz0h+LkpJ1dcS/TTV59/9dp5T8/2 TSK2LTgtZl63be6BLOanX3a92njJPTPPXzG1kjTI4/750nXRjS3XpdLabsXREeA+hTDcFO5Vahui pNWyhW6tuTCoHS2ljQ4UVmgrjMWjiwuLx9ZrJxbWjZ1O2rTTXTOqeshSbY+rq/xSska7qtw9bqx3 d6dM5Pz83JtldbGg15tuVrsyByoa5Q6ZkQscmwvkirEqHcvWxIcWjiyzY8zxUKg9hAMMm6PaPAYZ W4nOXVjvIK4I8VoG0tKzTEVeHGul8XZAVQeJ6UznSMvgcIwns3mJ6kBBRfOslrd/cTD6VXPWrE+6 KzaFMnKrCgoGKmfMPO/ynNzc0YGspZnzX1uUMYOkbLvuL3Uzmm65ouhi5qGc3vYlD46vrq1IJ5OK p1p8rkm14ycZJZZoNGZL9di8MsmsGz+W1PrHFmQXbJ2/7vdug5CDimuJncL5/qjyj6kuDk/LFgiv t+tDwhRhor5NaNEvE87XrxEu0Wt1TfpOfa+e1fO8wKuJfhddJ/o4luNYgWcbNR0aRiOodaotGkKM Mh9CcSpNVoStU0jnHmwtpakKcQ7aKL3erjpC2ttJgA55E05KRchcx9PRbUMh5iDZ+PTQ49FGMjt6 B5lLUtjOUzcxKUPv4Ri4HcdADpY3CL3h87RK94tuMU/M0xexlWKlrsg0nq0Xx5umOFrF5pwl4mpR 8npTdmWm3ZLJy7xGY7iZd/nStshhralMtm72yRorziB5uBfQKMXFEY9dHDweGulhuv4p3UviXYvz 83e7Nt6XWBFbfHrxEi5ndvO8T27e99V5OXOfX1y9I5gWCGWU7hw3545xuarA0ES5I33tIxPnnk++ XvXEpKn1pCyN1JdO9mTK4driBoffJhvZydG3P2fYUE7ZA3TFvhbrPZk7DhkwFpaGG/LVRZr88rC6 VjO+vCm1xdsUmJne411QsFKzyrBKWum+OHVlmdnDh3b77PaUXT7eLFTu5l2eErtdl72Zft2H83R1 ybfmTOwe8xisNdYZa0wbQpk++W9Nn/HxagrE6zxcW3JmQ1h5m5V60ol1csvU6S9ef+3rjXM755y/ gIx5uf6elEz3lTOO/NU+7e7u2TeGm3uiY+SMnIz0BcW5naOYguzUqbn+JnJy5VN1U86rb5hFpN89 RvIv6V1n5aJ/0/sP7Rk9ZlRuxWPRrWntTfXtqak2q1EzOrD25zmyx4ujYzfOh0EcHTxMC+fj5oNs wSWJniLZWzieISw0MHMZJoepZhqZDmYFs5bhGdw24fYV1+a4wnGQtuMYwPE6VNiuDNXjG48QXKyw e7ng0PxoC3NoiFVdr/rVydmq+4kHV8Du2BvcNO5zSIXRODcdCc9ks63ZRc6xBeOd0wpaSIemzdTh bsudX9AypqV6qdCtXWhaaOt2X1C4zrDKtsq1ptDJM6GS/NxwbnNuR8mC3Itz+0rEEl1Kror17bZg z7Euz4CdTteyy11mt0OJXgptduUm+rEmc7MklQ/IaqJWNlRKd+IoNo0Zg7Ygnauqj+PM1U6nb7u7 sLKwoZAtrCxRYSkrczdkq7JzfSbzmHZqlAncqvKn0d4sKS4tK6G3dH98+sYZisTndAOJd7JjHLEo PZ+l+MRFwU2L3ht99Y5j06bWX33bVWvIZCIQKxmzYdPum6Ldl3SlN8iezNqpqV11o0fJk3v9VwSD dTde7pslp+eSWx8/NaGq8mdze38znq968PLBfzxz99I7K/jKJ5lRU+eYTaayQGWNXxewl84aumLy lHxjrpS1om7xWovVMY6qZHHsbZwdPlFU0hmuHZNWlV6VPSWtPr0+e440x9xh60iZ455fcUHFKmY1 t964ZtS6CrPVV77bkbvbwfvof67exbusmWq1JxNVUl242aO05rA26E6YzgjD2mAEXkW1cXo+KIuL hTYa+OMbjRFhDLcZjVlcyuV0LlgaffzolF+7R3lXdJ53U2nlVP3sG1e03Fzd3E2mEcOWl86bOy96 ZSjbMzUna5JfzsrJCHSU5y31sGzVb6OHL7zsMrNAMgy+rJy8jR2FJdnBykd2fELyUDTRLzeu+WnQ l+r2+xZPntiR6rY7dNps2j54rmFm45mQ7tE9YSN5heH4VziBh+ca8XykTM+426tObBPpxcymez5q mFfJ5pM/pbs/hr6pkveizgRcN+4Jz+AZ+modhlyJHmoNq7qK4/gyvlxo4CcIc/kWYTm/QLiCv0jA jYjIsDt6cbIFjZqoBJ5bg5skliMMq+IFUa1RcxrgOAYOxP4eNmukMs6PBEYdAZ2sIxyVaDtuJNtx OKNC6U0pNB3Z6mkwjVsP6zlVextp3ygNHTlyRGHxCAbfX62epmagvc3vx4MMqlnL8N7oykVDLy+K rmcyyUPB/ftJXvQF7uip5Yx96CN6sjqMs8kBrKUN0qEI5oQrG6ytTIttCdNj69X16i8OiBZz7g3g lbxMp/deL+P1Cp4dIpu3Q7BfYc41GoWM9XCgxJvbJzxQLH05VIjHEGUgHVfamM40FyW2DvFZFpv7 zM0A+fa2wfJtJ3dg9tTWF34xdClTc/9dM2Y2X7x4+91Ra0YoZ/1F6VVz+zOKffPLavJ+Nqsl9Rdb K6vyyJPL9pbXlHNHndnBbe3L7hgteh4kz2ZMMUts9A+8yVE/9PykaRY9E72Ocbma6W5rEWrpQtxb FsG1ByEY27AP11rbgfjddCD2aHimWlcWGockepyeAJupyhZD6pAnEGhj2lSzNW2ps9IvYdeojSFL tWWFpc+islhStulUvrz8vM683jxVXl7mNrBY8g6UQEljSUcJ61vP7y/GRmqXvixUlt92hbCBcGsV DHK4qTpzFbLThSgTVyZlRuKVZceuTEGlpWVFJrpP4dmOO6PvL1y4YunCLiLvnf+TcO3y7NzUmaVl /fXTt4+rrG+sGntT/cTNFQUt7lHl55fX93sWdHWRtMODxLeoe5nNZAlZoz9x1vh8uUWVYw5du/VQ aVkoJ91T44zuduVKNjtqAUcJPxZHiQF34VXhnDbzTPdCZqn+Uma1nrdvF1nHdsG4XgNrMOoBWZbD cpPMOnBIePEU2C6daD+eUNzwfEJHgWpk4hjpb37s4W3Lo6fuG/qcSX2QiHNuGYyuvGBV5dp1XV2b +8cuWcC8/1x0f2tNMXd0bPn86CMv7jha6bGdmufyV/2R9iaWUvU5llILk8Ip6m35fJjv5Hv5fj5C 3ypLuG0Mq9lGRLrIGCVbmagSAfS8uo88oKNDl27kcC0ZGbhYXn9ihqCX6vOTT6tKhuqZa4bWMvu5 o9E3ozE0Px7O+UPMWQ01YSu3LZ8JM50M/cCBbBNZgWWB5mlS6/Ecog1pG7UMw2HraGiudEEOFoVQ 6cOZktNZfjjUzKwduiZ6lSqoGoz+M/rm0AbMRcmP+0KpaU04yG7LF8Nip9gr9osRkRdFTiOwhDOr mT54UA96uqllRbaPi1eznRJUF1UX/ZtKcl9E+4f+GO0n/UwZmh8P9XJHh/7O+OlpGKeLt5U8x4TT 1KodPKthdxBRe5umDw99twFLWFavk/X5+jDuoVV0qVUOgEMnCpWz1VChcvorMtFdZMBUxL59aueJ E+ziEyeI+L/Y+w7wJqt38e98I7PNarpHki7apiNpoYMCTRfQRUsLyKpQmpQG2iakaUtZHZS2ylK2 yBJUBBws2QgOcDAUFUQUBEV/gqCIiKx+/b/nS1or4L33ef733t9zn0cOOXnP+N7zvme86yQp9TYS sHcepOC5jOi8Qh2FcbyIWIPfKBK5L/akQGkt4rl5eorcGxqxK+zT0GXLcjadQ2td/4st18N+xYxR RwdmZp1cMXFXZrCufKh5ipcnj91CnkZvTtiSnJIplaBohSoxVl8zhhyKFM4VvQFUMESQQQmS+1kY dTxhxdfGfBp2DA92ttwRb0jp8mrpG/dPwqRtZ07dz3fuCt4XgMOFeHMvQcEOSAOxQhs4d85XrBVT hNBFJBXLhH4ilTiUiqRjRDHiZFGyOF+YJZombhE+LV4iXC56XqyMF40SNZANDC3CG8lPokhgGl3A EcYZQ4ooYQydQo+nrTRN4w5eUE2LCZriCym+WMjgjSAhJCBPOw/vBm+Yaea/6QoMaIsxF5whiLUM p3L0Oi3oHnBbtODjgtPCcSZEGt4XbDN7jf0DXsvQWygfDUFvUd931JNtD3xhj7iTPzk5FnDn4IAh K5808MmFZCMfDFAPkiR4Mp6aNwhl8aaCMiajEOKRfAEiaYpHUUE8HTKgIjQeWVEdCDVE8g1AKL+R 2CUWA9W7YNIIMSKdDJCNND49wIAWdrMWWCh28ICVpLeWDOYnk735OSSoZhJUMzmB30Ba+S6c6Qdd tspzCkcaxHxEks3YmOfx27h4zShQqkTxFFs44riGjCdgF3S0s+vQMVKFxlPsAxKU5xZqOAi6iZ2X eGXgqYu5OE5sLyacHy62Iiuc7AYx332RSOgjjBBSQlqziKHcqRCKotykoCxDUkKQL2iBYE4L3OoZ x5ERGjUh5/K/uBs9rCpeGVvOrmCfY8vRCjQRlaGVLJUYPyA2bs7grKb42JT+sbGt2dmt5I/sKrYY bUBG6PQCO65DnbF3ZuuBvv3ie/dLPNI8Z39ycmIS4ZDszFxYMRmhAqnpXSQrk9bQlPciPl/otQg2 lnxmXyIbi3VOgLmAANOoNAYN6c1vEL6plt1yCjAs4TkB9uch1HJz6PAUH1Lrcwemjvpqwy9sIzl1 wbs5o8ex1RlR/Wzj0qomNGhDNNR946HUkaNZ2FZ6ffKep1PGKLwYNs0rWD3KSTFvJKeLVES9odBF 5iOLlPWX5cnGyoZ7F/hUyMp8GmRiuaxJqpLGqdJV1SpK5S5YnCLPlzfIKblcyV/sTkmVVhWyShEx 00/lp5RKNWrMlEDRoASmnFIZPKSY68WwseKcohl8B85Z6gCv/iHDBc5JkLynbUOj6MRe5Zlza8fO iAgLAQtTy07axjaTLS1vFQ0rfW4BLUws8JTxWYtCrcp5EE8GdlxgTgXExq6d+tInmXCSKju/Z8qY a2CZHNhLBHY2GiRwAgSNkDEBQkmCak/nt4aBAIi9fL3iUV/fTJTtOzTOJKwV1rhN9azTu/BImCu5 j5b2p1LAFNSELPan1Xwd38qn+HzxYspNrZ3pI5+p9uGWVgioCKIPtk1+wOuJAwTO+IDDQJF3HS5a q9T2lffRZssztaPlw7WT5SbtdLldC4cLm6B8raeW5M4ZZ88gJaHh4kQedM9gQpfzQGPrJvgvzhbs ljJ2Lnt4L3t9akQd6tUeZAuOTCoqGLa/8MBLqAaFLEYqc/ho9n67blxkr8TRMwuXP7FlA/r8a/Z6 aiwyjStzkSji++gHuSmDfPufev4TxE/SspsGl7gqpP17Jaf4yNV+iW9j6QzOApPD2feRBh9EPwtS iBiDGpgxDTiGLRTIhAZhg5By6DHukoBTYV3amclhY9hGNoYJpLfdz6e3cXFm7DPQnG8+2yAmQO4R DElRDlNfClY+xZn6WIMJqBisPrRaLmjETa04lkljCpnxjJVh8Aziuig+PZJHMjTDa4anGLqJIqle KIxMR7mkDc0keYFEIJVGpFHVRDXFK3b4BPASwBYdhcPPILp5dMcltrDjElqMylE5c+peDCioq7QH IEwDQo5gDYVGGvwxvRQjEIph7/AoUiCVTCNqeBRPI5ImcBxIMEBIVBKDZLyEcoS+QFcQKU7Ju5cQ d17cAeIZTKyLWExTashAnTiZmWQX2MUkZfD0T6CGSWQJQ8hUOkuQJ0wTDRSPIwvokYKxwmEiC1lC mwWThCZRmbhe0CC0imrFc8kWeq6wRdQufp5cQj8vXCK6he4zaleSpFWkjI4h1fQAUk8nCfoLY0Xx YhfQghcNwoDYBFINmairJMQlTkMKgQYSEwJtZwz93f0ThBGQNZCIFLs0wcxYYRMI+A08BgxHIaNA /kwgimLiUD8Gpp4ZgUYxE1AlA0vAyJyOmDNHXZeXIDkgw4vArYMbZG6CI6yFfYL9nX0AuQU9+z1S 4BuIG3hRqI8exMPCdNIIv/AmucNOpZbwlLBDQwzuzAnQoCcQ2B+8QwZwZHV/3i7F9fBn3bGts6TD SK5iV6NSdip/1Y17GYDrKOCawOHSGBT0CT5BAa5DcAS6EIHpe70bTx8co9dQEzqMgGM14Jp6gzlw A2jqvMGuZw531oAdJN+FPiIBAYk3svPapY+GOXxPx3zCrv8MpM+Izm/p3fRsQkroiDLDIKkXE+nt lcVk+Y1iRvlNZszSyX61IbZwa5Qr+lWl0nr0MrhKE3r1Ctqolblu9PDQqZCuJWZfbEwskoapwsiw MH6L936942KJs2JjsdLBtp9W3qV6+khQT3XpyRXBHsRxnvjghIfC9TBXhVmbI+OTXLw8DRnxlgj/ EaF9bBnrzlaZjChs7Yoloz6K1CQh1ITikJx9HoVc5blL5Kl9giKVSrfIpz0GKLw8j66cvgrcPCGv eFCKHEml4Qc/6qCB+82dV5kBMOMy8JkSDcGZKNP/CWmZtIFp8OYpl0lkQsJ3BeUhkM8mDqh4nuIW wd4AjidsEmC2UpwmATZm+Vjk4EikwhmbkjtijwPYr756coFBym5E5UWvTTn9Azu/bHZchb7XQP3C eWQqWGvbw0ITecqOc2mF7An2p2XrVf4dxyWiV2BHjITVmUI3E72IdkOQjkoRJnvrfQ1UJp0ryBXm emf45qjGqCarZqgloWqwJ5VwULBbLMGHyR0qZNhA08mQTOa53EWWEoyCuegdVAYH+y8nPGREsCy4 IZgKjglHweHjw5HPbN7+MGz04PgGvhm8jg0HTrtoHVYn0x2Sc0RdcQzWYQJ1x93A6ZUg8rfFv40e NcH85JifG6vfGRbnnqwNn5D6zPNrF2VUBgf29ogbvjdgYFbWhaWrL+cMSosNY08odJ4e/rtXr39F 5a6MdGdPhMXACo3uvET/DCvkRqiJAYawbFG2zxQZpY5wxZILtqKC8FoukaGAZYyHXEm2EPsCfWcL 9muABcfmS7mO1wmTXhyON15QICn/k3YwH3uQTv/MriheP+nE7aLBGe+UmJoyEJhxocOCFiywzdJX 1eQORv2Qy8Lz+TlFWg26cD+Q7CWTbFv90tIQoBOv1AO6lXAn/IgqQ1EwqRXFkf1E6WQekydKl+TK RjNjRMN9zbzJwvHK8Z52sl5ol9iVSvSrn5+L90aFjBDIBEWCUkG1gBEI6BUuHkKhRwtxICAmAPmh Ful+f4dfiG+Qu1R+13nSOLwoPOtBXbapPMRhltIPHnwg2LvTdmZA2LSzs9nX2RVoOAoHkaZkV1KT rOWtAvRLy7zCGPYbfSTSIW/kgTLBiX0wfIqtog52oBY8ymZeAGhNgyEY/K0V7kgskGyUS13x3y7w kfqofEALCeQuLdJxrhZX0hV2zXUwyjjFk8S5zElJKdzVBXJE6/0RJwDlQX3iYBfhZaCafb3yIifl IA/2Nrti5cqvLhQ0xzIufEVupfDWg2cpyy3VyZNiIczyOjAu/Zx3+3qDhlnjcFgo8FWkiF5NtDCr CSRDJCoQjhdawTDosgpSuu418X0mqYBZKBexLWgGXboOybEc3wyYFRxmf4MCf7C6xYmI0/UYET7x zvtn7nno7HiOfwZOaBjxpCGV9qD83P3CvDZ6vOy722OXryB0qY9M7qkiaYlwqVImlUoCWlSbPVEL KXdtkWwmSBkJ/yLCiQhdREGENaLLIe/AV7KciOEC5g4pA1PW7Wz0uOPhcvcejfQtdplAochK62MM w3QWb55o2ayrOD5h10F2GV8hz06PGkH5PbhM6gurg4M1Wq8Hl+nSGVmFpePHlJ870RFC6otswfjr WQ7uGAVw5wHSMQi5u7n3k1vdaSRzFSx1k0mkrggOnJfOa7wXKRO3uO71dMYunJRzMUUNR5kjNsaR HY/X3J1RsMskcmVept6UjKkcv61i1wkyKqNNHRKoDuJIyin4/DPuZJ1nQuFkYR8O9KL7CqFMA0JZ CjI5xBfEVTCMx7loDr3Y0z+Lj+/T+zFxOSaUPch+DekgykSBKBSlsplBQcFq9ejevYeGaHoFatSj kvSjSD0chLdRCnJHnmgAe7jjnLZ+cmlrWHigX0Sv9olj28J7BWuwt7OZNTIDYJawjEoxaDPIDGmG ulBa6GaSGt3APPITei6Ty1ykAct5HmJfJRAeKPEVtrjs1TiUCcxXSrcyUWJSueBI12R16xMH8QOG Zw7eVT6+dSCeNlAon15h51vrQaEEF4ZhhTL3cvaQgvAQNpLprAGNcpy99uIS0CjHJIKNjhWlztIT CQWRuBu5WF3AOuCMLU8weumlUqlYiv/crTJGiVz4LcK9bl2OFlCY0qF13EAGPbIJqbNqz7LAvNoM TFPd1mw3nYJyEQiUXh0yuvSlsnT8TQREjANZPg3mSUc0G2SxMVleg2JqUL243rcmiK/CKksDBiej hixZDqfSJwz8ogIwy7ASA+doo7+Mj0l1w0EHvmQj5aEJm+0jn63x4XP+kYjzj2KtsYjvMHsVPTwk rUOTYRepmNMGztsl8Hqcu8KxVeA/vmeKdcR0HarBk+tCT2M/YH9dditb4zsoNXHB0Ell/YaFPZX4 3BKwO0Sz/pWqKjhhfqIu3pjQYFjQjoyvn04MRGFuUT6empjo8BC50F0atmnW+i/i/NnLCZm6yLAI d7G7LGQtlrGdV6mpzIuEL5FtiBQxvgwpFVvFpFjmyt8oFkl9fT2BVwm+PiT8pf5I4CprEQksfMxm XByIVi7GFucIsHHCF4eqQxwmFRazcofN2X3pE0dN7dv85KcnliwBZ2Mo+wYplQzK8BujCBBJ5ZtP kq634EAcusXakkcGBYV7iWDcFzovMUK6FOTAAEO4iOfDy3Ub41bh1sCf5sYn3RmhVL6U8UCc/nWI A2wqeXKBZRzIjOFuc7E0cOrgUBzv66YHHDUhu8L4cvW+D9EksdItLzPa2huVz8jNP3OK/Krjs+FT QkICAzWUH1ASABLJHSjhERWG4K0MqCtvchAzErwv8L/aOP+rFfwvI5pM2tF0kuacIo1QCm4dZNjV k5LgMuHPBwliBPkCkqBk0B+MVUek0EEnOAg9vTSi2OmmMe5sPlvOFqKZiEaILr2/mi598ICi8e6O Ak2wCShzIbYbpghJHu1NetDhZCidhFJIHZ0sjBNloXzSQOcI00VjyOH0WGGRqII00hXCEtFM0krP FNpEfqS41QW5YEZoAc1X8slbsM6t4OIMRU8yJjSJmQLuL69GUC3+0w+UkgKOTW84GDwN90kaCVaM MomacwN5XW6gwwvEARLMXfEU7mIKcoT5E2MWffF//ib2Rbb5+0vsTLBZpx2+gVIuH8S8kr93iIHf exQPvzDPASD5PIFnPjHfkCJgspmR1CimjGKgguEx9Ba0F1RoG/401ov8XXySY0RM8RkvKoTSMonU JGY6WUNNY+w8MYk5CII14uGFAqfc8cEqKUP7kqQwRpgv5KKT+NMcDnmEr916rFXxYS4THBY42OG8 OfIlRCBbxzPstO1sDpqG5pNn7iH0Ij0GaB8Gkq8aaBcStYbhFF/gK9AKkgWZAjpUkCCYI1gm2CDY ITgiOC34XiAUtDs+VeZH5pLp/EmkiT+NrOHz+dRyPPnLYbEIihYAm3wZX80Fb2K4Ty/hPQUzHhcT 0x1eL8afOyue0jbzPY2mD+cNIg1dff8SWdDxAfWgYy9Z+C+yBvG/65jHffZT5UxZxLQe6R0kdKYQ ZECTwcmjyGlUMDWDukPPpY8yc3m+vJS/pO18Pf+IwEswXDAf0vuC+8IBkMYLvxTli7Zzf611lkuM yyhI21wbnellSB9Buuh6UTJO8oZUJ22R3gCnAicjlxplv8j18mb5WflZhYdiveI3t0S3OW6dbp3K YuUb/6R/0j/pn/RP+if930igbwdSQ7q/vxtLdH2ZGoFBE+uESVD2DU6YImKISidMg+VX54QZgFuc MA/gVU6YTyR34xGCkfaKE3ZFucQuJywhIsBdoghEUzCWhOznhGkigIzkYAbqReRoJ0wTPmQ2B/Og nkfanTBNeJBGDuZDvYB82gnThBdYwBjG35ZwwR8F52CaCCQXcTD+mxxGcqcTRoSE8nLCgIfa7oQp 4klqgRMGnNR6J8wAfMAJ8wC+5oT5RG03HiHhR9NO2JVcQaudsIQYxtvDwSLMO9/PCQPvfBcOFkO9 gt/XCQPN/AgOdsG08cc6YaCHn8vBEqiX8Wc5YZpQ86s4WMbhGeuEMR5Hfzc8h/w1ThjmkO/gUcnR s9MJY3pe5GB3qFfyP3XCNBHMf4eDPbj+t50w7v8DB3vj/gKlE4b+Asc8+OI1FSQ6YVhTQRgH+3Nr +rQTxmvqWDsV17/QCeP+aRwcjNdUUOGEacJP4OAxiuvf7oRx/6kYFvSYZ0GPeRb0oF/Qg36XHv1d evR36TH/Ls7536SO1el16jxzqc1SbSmzq9MtNqvFVmI3W6qi1akVFepC88Rye7W60FRtstWajNEj TDZjSVWJ2lytLlHbbSVGU2WJbbLaUqa2l5t6IJpos9RYcXWppdJaUmU2VUd3N/btQpJmqTDiQjUM p+4TrYtTh3V3Cnd2isKd8krsgL5OnV5is5tsoyw16sqSenVNtQlGBUrKLFV2dUm12mqyVZrtdpNR PaGeoydzeG4qtNq4gtVmMdaU2tXmKnVdubm0vMez8G6uKq2oMcKjdovaaK62VsAAJVVGeMoMHUqh l6nKHq3uGttSVVGvDjOHq02VE/BDf6Kq6ur8WIq47kZz1US1zVRtt5lL8VT3GB0e78aVzBEQZoZR 7KZKvC42M4xqtNRVVVhKeg4KNJc4KDXZ1MCuBYaCvMZurbGrjaZac6kJ9yk3VVgfYqjcbrf2jYmp q6uLruya+mhYsxh7vdUy0VZiLa+PwUNUxxAjCBNhI4xECVEFLzUxBMoTocZE2KH8cKudqEGuAF95 pKUMysZHagdyeOwP1esJHRFPqKl26iD1HnUI8m3EJugdC/W4TU3kEWaiFJ6wENXwKgMMaiIdIBth 5fISqDEDVEVEQ0sqUQFJTRRC3USiHNqquZIJ3vG4tRxt0Y9QZ+b6OfjCOI3QXgnvNmIy1OFxcUs5 1D6eoolcuQZo6updCu+VUMYjmLnxox/zZN9HKEmDlgood7VUO7lTE30Ag46I434l41FM4Q9hiurG lMfNkYP6Om72MF92rvcojmo1x2s9vNdw8+Tg1TEnZdzodm52cNnKPVcJrXYOhxHqJnDPds1PJjGc yIWVcDxr69Fi5Sg2wiilHEYzx1cdN1Yp5I8f11HGfUuBnxpubYxcXwvkRq7dCi0ODjD3RudYZieG UicuE5fjffIw37i9goPC4KlweMfrP6F7pMdRVfUI5v/6HP2J3chhmgh1Nm6X2Dm6S7t39eN5d4z+ KF3JPWYAc+Lgxc6N13VebNzvqdRzc2eB2cecW7g9/3hOHfNc8pc5NXHranHmDq4ccA2UrFyu5qit 5bgxdePBPSu4c/IfrVA5N3NWOAUxkOq4FM3N6F93fbTznMUAXM9xOJHj0QoY6qG2i4tq4u/lm/mx 8i0X6ssBqgUMuEfNIz0GcSNVcyfGznH3qMy7ArxOJm4DlivQ8nD7CO7Jh2sHQ14BT5Q9trXAyWMN 7B/HDqn/Dzl7hCpaRQ+gk+l0Op5OpA10fzqHTnoEw7C/le45mDqkh9KjLXgHW4HfR2cilzv3ZoCd PyjUWUN89jdf5qYIbBXLCNTZ6fhVJQL/SpIH4fy1JQpb6XQPvwD/eY3eoEVQRYm9Cp4FuzJ32GA1 4VGYn6cm/GCsTm7EHnn3c4mgGx7/XECPJ1D3OyLICktpBSHhciWHBzmxgZUI1rOjJHO+h2JbjaCp p6inqbnUPAJ/2uwucQ+aVEjNlQQEouZzWOxObE58nmUEQTh//83zSV2z52ieMKJ1cOsfrohPrmv2 zIGqQSRCerFOyGO0Eor0YQhdCU+k5SEaNSeQiF5XpBuqi+xR47c+oNGP6MelfNhA1ZyKMHEHbwBO Ok0PZLTySHLj15/6vza17FvljNefeSYvyrRg8rpmhV7XTI/XNVO56ygSkaQoeov864LOsauPHe56 2h9Iseq1unAeNZwWuwWmW6z1NmxqqsNKw9X6pKSEh4zSaH2Azs/R2f2x5qpeo1PhdsrN68/2QovF rk6tsZdbbGZ7vS7A01WXoEuMhX9xel3saE9XfSwU+0Al/Butq+fmCpDw3MjhRXo3nRwXBG6iJ0qq y8Fms8MwMp0EV/Ld+IUmY6WlythFmOjvCAvSaRyE+fRsN5rUReaJVdgSLEhP1TWjQJ1r9wIixBBU M5ISUC8imxEidtfPPFO8IzPpld6v6s/dDemTVXf4vmrN+5lTfjk18MfP5707Obdwwq3nyHfzzmZV xAQPMB06GbRbPHh3Q835zIObF0oKjoRob677l2uQ6lRq8L0Jz33snfnS4mzVcyd2xAS+mx01w/Kl e0DyvCRZ0vmD4bfKkqNQbCfba/DLb1agtlX3920vbWi+O3ZdU8ucBVtv7lmy4ePElwvmePZqG3Je d5vof+vo3f5Nb7Ver0jaGN379s7oN0QzJzw7tWzVimrX1jduvvebem++Yn7pscgvYzO9f96fvSy5 oMjrZNnQ+s2vtX0wYsDa5oL2KmZbn7enBx8sLOv/3JDj2llxVS2DeKfWfJLdSla1Ei8ebvumCP8+ ANrQdE/X9IfODabTP4R20Yl4Ati6DMOnKF3TelyL6KaVuqbljbIxn1h/MdvWBA2dpdyet6Dz2Au2 //391iwl3ibm9uvXLj814HbptW8MOimm0Q2hTprRUfCm88cVEtqDVh73P1lLWMe88eu594asHJoR vSGj9IZOjJulNP41sdYeR4fCO2L6ltdnZYfePHlgiH39yF72iJodrR1bcpdMJfKufPST19fmI5L1 M34j049+1Hb8TtHxd9YeHGG5UZqxKYP4edkHK0/77RGv9XZd8sW5gNfCZ/5y/eXqVxdeSFrQf8Wk A4mVn7a/EdTxzZUzZuGz7QfZS8T+3r/9MeOuTBHN/BS+bHHa5LApuxMXXuS7flhcfuJgY+rkslf2 796/oPdHNynZjGm/f3ox7Zvp7KVLr7K3vzntusN6ZtF3+bsS18+I+rz/V73FExLItU2Tgp66PbZ0 4dbR+5O+GD9veItP3O/JK9Y1u6wfN3dH5O4XXjq25Zx61yGd9xy10jXiQOGt1ItP6r5bFGZue9v6 7W8bt5xsTLPVSkDGTAMZM8EpY0rQxwM4WSjteY4YkDP/xlONBU4SyJiE2NjeutgkLHD0urjuoq5p 9v8Iba7cxoGtS+flFxR2daf+pvt/KnsO6p66n2l7pWjymqfyiaDDb33u33/bKEPib9XPNof+sExB FH3p1yzpd9J//8E/0uYv//xBos/lvXe/u/ZZCXVo3WdnavLGDtx0/ckbn35rHuNTfXWH33z6RHjG OuOomIAVxVXvb/FKaja9t/HAlpp276tty5WhOxpCa1/8PDGp5bsdoae97mqvfPqhx+hhmpvL57e1 hrO3siJ/mHuHTpl54sSyRa2uU6hvP2Fd0vp0frEn5fyCTNHM21/kvDbmRq3Nvy5o5lN93vMr3l5A 5Qyq5G8c3r6C1/hy02vDhpxtOnPvUNph/VvDXZ87XZSl0P30/UvtM558b9poZZtgZ4J53U+xwfME P939XLnv4oMTV190d8qeO7qm3x8ve/48xYlTmeoPfGOfH7eodfgbT+07+tw2+wJu+fyl+NTDQeY3 cnLDP4j20nk0Pv7YZ+AOKrq/LlmXtC5hXZ/WOKebXmqreMhNt04249oYZ3CjOia9CDZeNFTpBndR iBDdT9dXl9hV1pGtkX/r93MITbYemOwPHShO+oRRs7e4uf7Kyi1ptWfTt+w5mnYv2NT79ZqtU3QL lu2afc92mT2R8K++1hVD1ZJ9U3Z+eOv05ad/DLNWn75+6Z3pP/86ovfoxuafZF/YqKuKIdfOu86b npHvUlLTUbWKf/6kdrSXa9LW8R3nOunN5Iaz9xZs2H/w7UnDkvXjLkdWHfs1L8LvZkDt9NY3jrad 2RZx/dXjksOX1zb8+PGPLbZhzV5VER+sWbrTJ+Bty+KvJrz8ds7k1z683n/Rd9tjtkyrS5o4iZje vJqSXShdmhWadmFp4Ntt4k+UG8Z9XR1riw/o/CD8SHBhftngD/39Nx0JTTIXDNl47R1eRbTN91fN ucrgwY1N7oYZa4/bE7PzQfqsBukzxyF9ZJPEz+UfJkK2yL/KVI2cNnH9wzLo32PrxIPwidfpdb17 J2DRkwTFf4OtM8xcaaq2l1Ra/6u2ztcJVfff+CAte4rXBycHDyg6fG+Lcl9k7H5FfuEHs68PiPsy S78obNezxouqgpZ97+ScamDu/FLz1tz3Xzn9utlaNrVX2Y+7dv8yZ++Jnzd3KF4UjwoMj/nY8OUI 2rf2zUpjZfawr87/euHQ2tnvN37TkEsmLPn98BrBiIDyQSe+PFw7NmbmrhB654gxk/xKOxtn9Pv5 NB2Sl1Rn5xe/M/Zsa0JkzYeSqwFJwhm17OqKqmkXrw1YuHzNFMm4iHyvCeNj13w6e4g2cGx55twL MS2ygu133/SZX/FzyPNud47JvpgjudVcWx1/dOm09cfH864xW1vjdt9ZMqYltWXknCVVW1WRg49b VqVfnPRjQ+iCyQ5504zCYEaCHydxBP83rB0ZT+j0LNwR94OoPQSl5cchKcv39t6S07rwwKqrryan ph/9ROfd/YCSpF0CREQR58amE6l/tYQeMaMeI6CW5Mn178wo2C9f8EIJH0nmWTPn/1I97GCKkInq 3DO0aI7f9aRnd28YIb4wb1ey76n7r278cPe2oRpfi8A8azK1PnDg9YqdlTMC9wz8rOW3+dK3+E/H v/3TrCvW4sy1iz49fvL8gsOXDkWcmHHtw9djT7ftPVb6XvwpL82h2gvJK3f4Vq/RtJ/duVMxbN6t Ve+YsleGha4a/7Q0+X0309TB+z9+bXbf/K0TRl7QXbmS5P/dUzfPJTXdddPMMzaW8uhlN1eS6THT B7bv6yS/NN3NvnCOsi/ewVS5HF/9dVjJjMG/eq6SaxJJv7ZXeUeWxe753nC0qP/BTU9d+LEsYf6t wGWrjm+tGza07xlbxvag2yCgNoOAWtRlHvGWRDnutP595tEjggDLqESwhvqAaIrVczIqzlHU46Ku acf/hnnUSxfiKAZUpZutOHCeUZSpziwa0jchNTE2Kj4xMTUqaWBSrD5EF+Tgye+vPEUVYabURSYb DrT/p+JtaZNIneY1dNqXS68/3/F126n7koVuVzcnhClq2byCLbXLIxYPurhphJn8fsmsvDlfNUz5 pYb4an96xX3Lq1NuaE/NWHRyiefqF47su/vHrPMll6J0AatCo2pTfhi4bMHrZ59KOHv8l98+HvPu g/KLN40Ln//xXcXdDW+1PDgz9yTT/yCqLehF3WnZ7dE6f/xbxeGR/T5+qWPF6D7++R6HE88GlKT0 j98xQuletzRZdo/Yuvjb4oQtvfaXRg5WNg3/ruLqJu3S+e2SWRuIl+qC+SsirNSeiOBnVl44sj4w 51DuKF7dMFv61gHG84tbBCN3sVfasoTxO3bcids0K3d9fUPsqHDJmjd/v9hvTcq1gck9zak/BULY 0vZDZPJP55bsmzlQeu/YrVmrO0/9xVJ6rMT4/7GU7NXW0pL/FkupC5P98cL6L/Yf7/DjpBXx86sP vv20veyj8O9G7z1BNM/yHHskeJRi/yt/TP6ijZ1/7M1alW/g7T8ufbRzbyrySXhtcMIy673jcRvD 5u0R77K7he3eUXMpQvjt3PxvVqQs391b0XRVdt7/633Gj4cUJOc+3eF9PuT108varua89/2Nu6me xeinJ9pn1k773sK2qV9dvGreykPjfNa564Ivrp9V8qx/ePi7Wc/0TZ/91M8XTs8+nx/ZJ/lfqalo M+Eivnkmy/dk2vzpW3+Lml8cfumt+Q3PutfuHH9f2WuzRVGaFjay79PJcw2Xdx85vugJv4EjJi88 tihvBEN8dEdnyBzyjXf7wd9lN877fBMWsHPozbqLod/tFzYpvg7o+0mmvpl+HiTWchIhXVPbv9Fl +4sj+Weoa13TUaydnMsmpPQuPeNoMO6fJbFeouvZ6g5So/tBWg9bfWrTjfgDbq6v31kxM37tvw7v dt38/xY9yyANSQuPYYRB2AKdBi3iZ7cWqjWoEDGXp4BWMrE0MTIEZj/iKupKmX1kr9TL+2t+/2dm +tqYYXTzmuGxquU/r8/jm9YlcG7yyWVO6zo148KMmnp87k7V4Hb0jdh1/ovLie/7JiW0+B61rohX SBcNq6+68Tkkwqs7X9jXZ0VL2bQz5SUx1y3enOINiT9z1KvcRbF0EffanU9+/doQcDjPdJV8pvxe 2Y3TZ0z7lNLGcSd4ynqL1RsX+assrmHvbLRytOfPFlgscHrnvD+H5p4U5G8tPmVZ8f5H06FNrLfk pz249sQ2t8ymWyl4wcZpP5+bWcT63Kx3nOj6kik8fa9tk9w9QUZrNjlGi2k+cw6HKy1n+C3tN73Z wrxWrNVg0sKo6cd+b769UFyvL1Q+0H1hE5O8QROTNCKW2AybmHiAQhx0T47oVSRKxc0OTY4LYg0k kNMiN2LglxFoJ1yG1ZAfWKMaGFgAq1dDI2NTkyiMpOiwyXzPXIEXLzwDl11/9+EF36mblU/QyidQ Eql9c+zqiVdZTN6XZfoKZZRtDjrvusSf+FUiXeaKpf93vlXmZhycD2/Z+J2R0T6mlXd1yZSJr38V Sly7ERNruPX7ui07rBbNsDhuoDFFY83HdyLtPKzFW3SWJR1f8n/DWtl83n0vfmrwzT17wMzxd2jj 2piL4UatzTyCT01KN9n8nqgnJZG853WQqj3bt4jVvz/WiJnv23D6XZPG55yvtsFTjn6ZZGlyI3tf tDRTUKV4g9KOWXVmsmnR5xZP3mz4i33BfrnpU+I4HnNz3+sUu+A0d2pe9dKNYcJ23269mdTt+/lS j9D9bWUKAV07Jy+q1j+TIbFa7ooul5NIxVzfDe68nE2NFlcq1zNz2J71r2BgAAAT14VADQplbmRz dHJlYW0NCmVuZG9iag0KMTMwIDAgb2JqDQpbIDM1MiAwIDAgMCAwIDAgMCAwIDQ1NCA0NTQgMCA4 MTggMzY0IDQ1NCAzNjQgNDU0IDYzNiA2MzYgNjM2IDYzNiA2MzYgNjM2IDYzNiA2MzYgNjM2IDYz NiA0NTQgMCAwIDgxOCA4MTggMCAwIDY4NCA2ODYgNjk4IDc3MSA2MzIgNTc1IDc3NSA3NTEgNDIx IDQ1NSA2OTMgNTU3IDg0MyA3NDggNzg3IDYwMyA3ODcgNjk1IDY4NCA2MTYgNzMyIDY4NCA5ODkg Njg1IDAgNjg1IDQ1NCAwIDQ1NCAwIDAgMCA2MDEgNjIzIDUyMSA2MjMgNTk2IDM1MiA2MjMgNjMz IDI3NCAwIDU5MiAyNzQgOTczIDYzMyA2MDcgNjIzIDYyMyA0MjcgNTIxIDM5NCA2MzMgNTkyIDgx OCA1OTIgNTkyIDUyNSAwIDQ1NF0gDQplbmRvYmoNCjEzMSAwIG9iag0KPDwvRmlsdGVyL0ZsYXRl RGVjb2RlL0xlbmd0aCAyNDIzMC9MZW5ndGgxIDY4NTgwPj4NCnN0cmVhbQ0KeJzsfXt4VNW597sv s2fP7L1nz55rZiZzTybJzCSTZGYSJiSZgSSQECBAAk2ASLgpoEgUShE4QqvIReUi3rUWL5W2Wg0X ERAr3qmXVrS1ttaKilbPEbVVWyskc961E6J8x+/74zzl4Xt45of7t9d611p71lp7/db7riESoADA hsRCT2N7y9j59loF4IsFAPbVYxubxkCIOQTw+Wqs5Rk7qa1dW22oxfydmB8xtn3q6OMFH4Yw/zvM 3zi+o71505ianQD6FQDMY23tscrLp6x6CYD6EMt7pjVO6Fz2t9WLAQwJAM2xuYtn9/7W+8brAOuP YZ0b5i5f5ht/zygaYEsU87de2HvR4vt+s3gywMZlAPTBi2Yv7QU76PDzLsHnGS+65IoLN12fuR9g 6zMA40ML5i1eEfls3F8BLBaApS8tmD973h9nduHgKFK/agEa5CIen0fdh/mCBYuXrbjiaCn2lW4G 4Msvnn/5pZ6A8ymA4zOxfzsuWTJ39ib/XR0Af/4YQNu7ePaKXi7CXIztj2B736WzF8+/fdcP9gJ8 dApAN6F3ydJl2TbA530+npT3Xj6/l+/9NANwXTl+xikgc63ReG+Pbpg2S679Elw8EPziysYScj+y 7ZnDJ6/p3y5s53H+cZw0DALb8cLAFAAxiuWXCdvVJ30bs4mFeRTqgVHzNBghBtMwocfPVS2sQm0F DfCa2zVxfGTh4J3ZASvonTzQAscyGpal2buBy2bAN4PMMGk4od3nAzTALznPQBe8wAvUQz6gfkLK 2G7NUTJSoPihLtGvDF5MiAoyD8LP4DvA3AOP4LWdpLnr4FX6I9iO+dvw3s/ck31XY4ONGhtlw/vd eO3EawJejw3a4Xa8VuJ1GXMPNf30M/E5X3LXUeLpvGYFODWr4YjmZljKhfEuwxH2NjjCJTDPwBHm AtjI3AtRzbXwMrsM7b/COqfwPh6Wsq8N3jVb0bYCrmE/wee9CbvJM7UfwUzNKmhUP2MVXIn9/nRo TA98e4zsb2ABewoOsBFYiPdL2GdgEc5LI0lrjHCAroSH1XqH4ElMP6Y9AgeInX0TFqntsB6zSG1/ KVME9Vi2C+vW4Tin4b2WpNkEdA9+NrXyu+Y5hxxyyCGHHP7/A/MoReXnlxvUDEWBgZIpShgGhhMG LKs0GB1Bq0FepjeUFhgkSTJURt2VZfmQT6kRBxokKV8S9oJhryIYJSmsKILeKOsVMJzb8eWQw3kL FB8BiPAVnwUe+OwAnlf0yHqVBRCQRRCRJZCy/ahGA7IMMrJRZQUUZBOYsqfADGZkC1iRrSrbwIZs B3v2JORBHrIDnMhOcCG7VMZdIPs1uMGN7AEPshd8yD6V/eDP/gsCEEAOQhC5AAqRCyGEHEL+Coqg CLkYipFLoAQ5DBHkCPI/IQpR5FIoRS6DMuQYlCOXQ0X2H1ChciVUIschjpyABHISqrJfQpXK1VCN PAJGIKcghVwDI7NfwEioRa6FOuQ6leuhHjkN6ezneNoahTxK5dEwGrkBGpAboTH7d2iCMchjYCzy WJWboRm5BVqyf4NxMA65FcYjj4cJyBNUnggTs59BG7QhT4LJyJNhCvIU5E+hHdqRO6ADeSpMRZ4G 30P+HnRmP4FOlbugC3k6TEeeATORZ0J39mM8gxC+AC5AngWzkHugB3k2zMn+F8xReS7MRZ4H85Dn w3zkC+Gi7H/CRbAAeYHKC2Eh8iJYhHwxXJz9CC6BxciLVb4ULkVeAkuQe6E3+yFcBpcjX67yUliK vAyWIX8fvp/9KyyH5cg/gBXIK1S+Aq5AXgkrsx/AKliFvBr+A/k/VL4SrkReA2uy78NaWIv8Q/gR 8o/gKuSrVL4ars4eh3WwDvkauAZ5PWxA3qDyRtiYfQ82wSbka+Fa5OvgeuTrYTPyZuR3YQtsQd4K W5G3wTbkG2A78nbkd+BGuBH5JrgJ+Wa4GfkWuBX5VrgtewxuU/l2uAP5DpXvhDuRfwx3Zd+Gu1T+ CexA3qHy3XA38j1wb/YvcC/ch3yfyj+F+5HvV3kn7My+haf0nyP/XOVfwAPID6j8IDyY/TP8Eh5C fggeRn4Y+pD7VN4Fu7J4KobdyHtgL/JeeAT5EdiHvA/5T/AoPIq8Hw4gH4CDyAfhMeTHkP8Ih+AQ 8uPwOPKv4AnkJ+Aw8mF4MvsGPKnyU/AU8tPwDPIz8Czys8h/gOfgOeTn4XnkI3AE+dfwAvIL8GL2 dXgRXkJ+SeWX4WXk38BvkX8Lr2R/D6+ofBSOIr8KryK/Bq8h/w5+n8VL5dfhD8h/UPkNeAP5j/Cn 7GvwJ3gT+U34M/KfVX4L3kL+C/wl+yq8DceQj6n8DryL/K7K78F72aNwHN5Hfh8+QP4A/or8V5U/ hA+zr8BH8BHyf8J/If+Xyh/Dx8gn4ET2t/AJfIL8KXyG/Bn8Dflv8HfkvyP/Bj6Hz5G/gC+Qv4R/ IP8D/on8T+SX4Sv4Cvlf8C/kr+Ek8kk4lX0JTkE/cj8MIA+onIUsMuA+CswhnU4HDKPRqDs+y4KW 0TCsdhgsgFYLwGt5XsvxvEaj5XS8TqvDIh7vgBWwCnAEDP4HHKMjaRb/cFqO04DmnPqwHHI4b6EX 9ChZdlBhKGGe1bCab7SLdp4n+uV57rR2Ubk6Hi1aAbU7KE6siDrXahnUvqBqnmO1nBbFm9NuDjmc HQiCcIZ2df9Du+iYUb86HfG4Gg0/6Hd54okFPIud1i53pnY1qF3inXPazSGHswRRElG7Gk7NnNYu P4xvaZfX6nSoXa1ep+f1qF0dLw1rF70yz7M8r2pXbafVEL+M8XZOuznkcFYgSRJKdui8iyGuDlXH faNdblC7OqJdvLBIK6jaxXOyTtKBjgMi+0Gdn6FdfIiAcTVoz+34csjhfIVBNqB2uUG/izeBaFc3 DI5E1Xgq1usFHS/oNZweWcALva9e1oN+SLskjNbodAzwjKS2I7E1NuGBO7fjyyGH8xWyLBPtDnpH DHFF1K5WPwy0iyLRriDodCIKW89LgqgTUbuCqt1Bx6ojjlnVro6RdfpB7eqIinN+N4cczg6MipH8 Dc+wdiVOy52pXQyqyTdaol4nilqMmCVR0kvoeEVBEUAY1K4ew2g9p9fjeVkjk3acDs/FOe3mkMPZ g6IoqF3t4P+EgCGuAT0m/81P4PGDP4EniiLKVZJ4XtQZJNSuKOpFURFB5IE0xYha0HOCoAG9RsGg WtDqtILegN4Z+HM7vhxyOF9hMpnO0K6s5bVnaheDatSuZEAtGlC7ehmTBkkUJNE0rF2MqAVB1a6g MantULuCjOacdnPI4ezAbDZjqKzVqRkMcY3kJy/EYaDdaFS/jZZFQTbwOkkwGmRBliTRIJklIF81 Y0OMqEVBK4ocCJyJtOP1WlEwCoIedOd0eDnkcN7CYrGQn5o6U7vSMIa0azAYZEk0yrzOICiyUTQa DKJssBjAMKhdNYTWihIHImeWiOb1PNYXRSGn3RxyODuwWq1Eu3o1o9eDwut5/Tfa1ZMTMdGubEQt Gnm9LJqMiqTIBkk2WFG7eiBNJUmQJK2kateial5A7SpEu/pzO74ccjhfYbPZyE9NDWvXRLRrGIae nIjVv0lSDJKi6FG7ZlW7ssEo22SQh7RLjsC8wcCBxFkNksGgE3QGyYSRdU67OeRwdmC324l2BTWD 2jUT7crD0JMTMYmbjSZZMqF2jZJZMRlMRqNBMdqNYBzULobQBgNvkDkwcDaZaF7UyQYzmnPazSGH s4O8vLxvtCsIYEGPKXyjXWHw39oyGhUzatGkFxTJYjIbzIpRNhnzULsCkKZ4GpYNvKxq165qXtKR 87BBAuHcji+HHM5XuFwu8lNTg/8mmiiCTS/qRWUYIomqMW42m62K0WoRRLNst1iNVrNJsZhcZjCL QJoaFXTDekXRglHrVIzYziAoRht6ZxD/35+fQw45/O/gdruJdiU1I0mQJ0iCZBqGRDyz+m20zaTY bJJkMebZ7IrdYjFZLW4LWCQgTRWTjAG1yaQDRZdP2omyYFLyFEUG6dyOL4cczlf4fD4MlSVZzcgy OEVZlC3DQLvTqX6j5bCYHHmSbDO58hxmh81msdt8NiBfV2FDs0WxmAWLRQdmndditlgMGFubnWaz AvK5HV8OOZyv8Pv95KemhrXrItq1DkMmUbX6jZbDanY6JNluync4LU673ZJn99vBPqhdi1WxWkSr VYfnZZ/VYrWidq0Wl8WS024OOZwlFBYWYqgsK2pGUcAjKZKSNwy0ezwADofTbbe6842K0+rNd9vc Tofd5Sh0gEMB0tRmN9ttkt2ux/Nygd1mtxvxXGzz2GxmUM7t+HLI4XxFOBxGd6uY1YzZDAHZLJtd w0B7IKCein2uPL/PZHbbg16/w+92O73usBvcZiBNHU6b0yE7XSI4xBKXw+k02RSXI+Bw2MB8bseX Qw7nK8rKysBoNFnVjNUKIQXDX/cw0B4KAXh9vqDbWRA0WX3OokBBfoHPmx/wlvrAZwXSNN+d53YZ 3W4RY+5Sd77bbckzuV0hlysPrOd2fDnkcL6isrISTCaLXc3Y7VBispvsvmGgvaSE+N5gkc9dFLLa g/nhwiJPUTDgLQxUBCCAR15s6PE6vR6T1yeDR67webxeq9Pi85R4PE6wn9vx5ZDD+YqqqioMla0O NeNwQNTisDgCw0B7NEpOxaFwwBsusTsKPWXFEX8kVOgvLkwWAjnyYkNfID/gMwcCMvjkZMAfCNjz rQFf1OfLB8e5HV8OOZyvqKmpAYvF7lIzTifErE6rs3AYToBYDKC4uKS00F8azXMW+yoiZcGy4uKC cHGqGIqdgFUgWOApCFoKCmU8L48oDBYUODz2wkAsEPCoxTnkkMO/HQ0NDZCX5/SqGY8HqvM8eZ7I MDwA1dXkVBxLhIsSlW5PWeGIymRxMlZWUlE2ugzKPIBVoDgcDBfnhcMmKDaNCpeEw+6gM1xcXVwc VItzyCGHfztaW1vR3XoCaiYQgDpXwBUoHwba6+oA4vFETSxSM8IbSITTI0aWjkzEy6rj4+IQxyMv NiyNFcVKnbGYFaLWllhZLOYr8sSiddFoEQTO7fhyyOF8RXt7O7jd/pCaCYWg0RPyhJLDQHtjI0Aq VZNJlGfqA6GasjH1oypH1aTidakpKUiFgDStTEQSFe5EMg8q8iYnKxOJYMSfrGisqIhC6NyOL4cc zlfMnDkTfL6CsJoJh6HVH/aHa4YRJp4ZIJ3OjK1Jjm0qCmfiE5uaq5sz6VRDekYa0mEgTatT5alq X6omD6ryumpGpFJF5QU1Va1VVeUQPrfjyyGH8xXz5s2DYLCoTM2UlsKUgtKC0swwSgGmTEHf2zRm Qjo1sTVc2jSio7Wttm1MY31L49wmaCoFrAK19Yn62mB92gUjXbPTdfX1kURReuSUkSOTanEOOeRw NkCrvygdwAIMSVFOvDgYMuKdpkmdM4GFzNAvIBNEMMhGxWS2WG32PIfTle8G8PkBCgpDRcUl4Ui0 tCxWXlEZTySrqkekakZCXT1kQN0Qxja3jGsdDxPbJk2e0t4xddr3Orumz5jZDbP+rQNk/nfNWFiB 7AQjPkCP5/YSqIF66IQZ0A0LYSWshh3wy2wW6/igGCJQB6NgOpbNhotPl2Xf+44/c7Nzhyf3O5Gx Tu2orqqMlZVGQ4Vei9mkSKKGpaO+PqawKdgUnL1gk69pgW9TsLGnsTTaOqWzqdHl93eVRn1obvT1 UT2+pr4xyxfkbWoiFfpMkT66sIlci/oy1/ZgItjo9/uxxPxNyf7s4eu+VeRb2JeZ3QfX+nZFD2+6 br8R5vRExHnBebNndvYxs/GzdgF2ZkFHJ+kTuXoW+PpYbK2SCy1DXSRlC3qQg43Y6jvtaNY1dK73 H3b1mfDe1KdE+sZijbErj7uYTU15C30ku2nTel/fjsmd3y71E+7q6so7YxrGBMf0bNo0Jugbs6ln 0+z92bVzgj5jcNOu1tZNvU09vj6Y1NlHof3gta6+Mdd19Rl7FlA1OGQyjjFTOtMuv4JP8fvJeK/d n4E5mOlbO7lzMO+DOa7dkIlFuvroHlJy+HSJdSopWXu6ZLh5T1Cd64ZOxkXjg1vbg62Tp3f6mjb1 DHV4yDJiMLeLhtG7gtSGybsy1Ib26Z0HjLjCNnR07qYpuqFndNeuAizrPODDhaJaaWIlRpLxkQy0 Ujgdu2lere86kAFYq5ayqkHNz91PgWrjT9somLufHrQZT9totLGDtoxqI8DB0A0dnd/uNV6k7wAH oCN7OOPZXVJZZdzt253ZPWl37+61u3fs7tv9yu5ju/WHd3+2m8a1lul9xJ5X5W2k5GneaXTb1FlT 6SUd1E86Hu6gJ7fb2SntNrZ9ipUd1zKFHdNSzY5tqWSb8WpJptjadCVbl65j69N+tiHtZkenp7Cj 8MrglU5WspXxeWw8mWCTiQ42kfSwrySOJT5LMPuzn+zZW9hctT97bM9eYxDvn2SkvTq5aq+zmV2+ 55o92K3P9uxRa3ydye7RFVTtsTSzGzeY2d5LelfQ8p1v30VnfmxzVGXutLmqMrfYMXWz3VV1zTqz V75aXidvlrfIW71Xezd7t8Q2r123dsOWbVvXbV2/dYOc+ZHOWCVf7r2czlymE6vkxZTvCOV7nko/ 9+lztO/ZzLM0zKFgjnEOnZm9YzYtz6BKLQobtRSyEUuKDVvMbInFynotHtbva2B9llr2184m1uka y7qctazTUslasZ4Zu2uyOFkFr14LlbGMaqiSDWEvcJT0dKtXfKrVqz/c6tXhpTnU6mUfb/UyB1q9 9MFWL7Wv1QuPtnqffirsPfxE2Pt4Ztohv/fgAb/30X1+71NPPyM9cfhJ6dDjvxIPHHxM3PfoftF4 aO0hOnNg7QFa3pfe17ZvzT5W3hfD5BJMPrHvt/uy+3i9rpoVJRr3LoamKaAnaaj9VJbqM7VCa8fo PjOF9/bRu3SVkda+eVNGr7v+enffzbhy+9a6u/bzWAd12kdt7urjW9uHkqD+FcrSZUuXRr4DfUxT H9e0YHYfF2xcSjIGkjHgbmFo6pNJWg42Rqg+S9OCPgum/sdDlp5GZOlQ4eAHqQTf/67PJH1ZhhyJ cB7OovlMc5RdzXYzb6HfgOxfs+8MrBiYN9DF3Eh+ZzbcDL9AiTwHvxne7A/BU+p9OeyGw/DiGY7g h3Aj3A8vwZ/g02HbrXAXPAB9Z9Tbqlrvg5/DQ7AHDsLTaNsA29D6U3jwW/WWwHrYAnegb3qNcg/Z nqYt1GAPPgKRPkotpTajz4tCI8yEpXAlXIP9OkKNR1sd2iah9XL0izeg9QAc+Q7nVQfT0Acugkth F9Z4UrWF0doB89BKbIO4DD3oRrgbdsJj2K+V2LNtcPt3PO+HtJ/2wzJ4H1u+QN1EP4cj2gnrOAv5 V300R8msst3q3EL2HYCBedkv0ePPob+g76G3wcP0IhgPNHG3WvIrmhi8WR7laBbIFXv5rZdVqij3 K36lEInCWl+v1cBJcoe1JMShqSASg59FWs/O5DG4mrVTNbyso6CbFUWRnspGmG7N/uxbe41Geiom Pt4ry2ri672SpCbe2CsIg0UZvU5HT5U1Xg2tiXWra+h4f+R4N6RPxGPpinKKCTLmYDJOM85f5L/+ 0kuaoyd/zVZ/HXsNd+OfMUcZlrOoPQllrDTHMVpK1mV0NBMFsoWzUW3sRLw7dgIfVxuP1Q4+jvxh 2MjVkZ/hxVn6H6cbyEXiuEcG5jEyPtEK0zINOkqndVAObTFTrGmjmplmTZt2FjVLu4Raol1DraBX cGu0Ji1FiStZii8nUYwsosCnyqI6JC+7wWb84kQkEo9112IHyGC6qWCIVoym6riV/FZ32mox2W02 OyO/v+uZZ3a9P3l7ura1pb729gkD816kjlGl+OfYi/qWJ9asGnjjvgcGjq9d9XwT6ef2gXn0CbWf izIpjuHMVsZqDlEhJmQOWcdSGSZjHmudxEwy9zA95itgOd3L9JqXW6wmihW/D5QpzVIsK+zPfrGX dJgkMjLptOAFkbwruMFu/Efk/+y7kdYGk1VV1VWmZIIuCoWKknGbiT6BHZ9wx8j6lnF16e2TcSB0 7cBrA74X9U3Pr1pL5T9wH1W8as0TLfoXB3zY81fBpTnI9oMAqUyQeZBiO/gH9bKW0mYkqlzKSDQ8 oF9LUVRY84A2g73Ezz/ej1d3N6jJ2uPYFb8SVPxJvxJX/JqD/W/f3/827b8fpVFLEjtof//b6hxt ptOobAaSmZCTClMROgkpugmacXxd9DyU0bOMSNPMNBZVQzsxdIh1x2Ng/KIyRoaro4JmOj3wwQ0P Ue7+y+gtZN5voysYHf0BPtOXsVCjZQxCZE0btGlmwSzyqxDpGE4YdvQE6WTSz+j6t9K9dMUjpG0/ 0sdqf3z76GkUD6XU/uyHGT2Z7xiVpmgK1/8JXPeov6ASpz7+9FOsTWXfHXiFmamu8qpMIUOBhrJR hdQIaIFGahp1EfUD6hpKT5loJoa9IauQdALSsW7sw/oT3esP40AoZmZ//Jf0C5zlq0PaRnKC2Zh9 h92i+RTfQxDWZwJVVEpIiCNNI/MSniaqRWgUW02teY0e0dqio/0tjF7GNbKPiFv2A4YGqqKBrBsX UTLkkSK4q1Au9BbSLnUXcPk5rJgxk5qckawuTiR1uVsLcG1FcHV1D91xzGTUZIH5fUQefp+JqqpK JkK4yIIBFApntdhQKPHKKnbLyYGvBr7459eUjhL/OfCvoMNRELxi1gWrCgIOW4H/inkXrKY/Glgy sJFaTW2irqdWDaw59cjkN2+/9djECRMnto37ZPOdr7ZPnDIRXwZlw/deq3kdZNiQSWrGcJzIGJhm ipcVr0JraK9MybJoUAdjkESRm2rw0WlmCdPLMIxI9jYMo45lBDJAxkYGyJAJcZNBMh7SiuHIfscY JYlDJk9gYqc9ZXcc5ZWqjHXH4iiw/sp0PEbePFnW/mQliqyqGpc3W3vqT1TVwAvprYVlSfYOqvxW 5oMNVotjwqivn8J3fTeOYJvmMzxzvZOZPMnb46U1DKfYGKtSoIzUjJCShrQ77Ul5WzXNUpOhzd3m afHOYrrZbs0M3TRlluMCV3f+LPcszyJmHjdfmWNd4umllylrnGvy13gKcTQf7iWdpsk6TZMUyEa5 lI/ll8sZmZMz6nrIiDg6WRbGmWnaO47ivTTvt6m7iE3dCG0smRAbmRoHaWCzkSfZbL67AnLAG6Bx Im/zG/+BM0FInZsTppQ6JegCcKIqypGobpwasveQZUHWBNmJ4iTUI8uD/Odnt50yLnxtxuHNt22c 8bv5+rEnlrxPsZFw0cLWi4/PZfxHp+/tOvjmmmVXZUa/Gqx56/Gp20fXr2hZ+GwHzuNOVMNqnMc6 2J/ZLAiamFOwxkqEUKyktlZIWioCidg4ocnSEGiITaO6NF3C1Ngi4cLYotoVwvLYsuSqWmeiprGG HlmD80uVKqV0aWnJOK+ugpYlr0RLkjJOpw/6q9WlVM2SRVHNkVmo9pTZ/EyZpwZDQ8apLhlRXSY7 0nLam6bF2+uNH3QbP4hEFHvKeCIWI/NzQvWN3WlTitxi/alUNxGPzTY4F8GAujETsVQPiwg9aOW3 BDU4eURSpI3VZmMN5fXjGlpfvGL1ZxPkqR9cnN4cLSuNl5auHTd9zK2PlJVE5tTPen0WmdPF9zc0 j3v4B+Wr6ZcjP7rowl+kxzSMDB4dMS5cEl00edJCj9d+/5qVVZOdTktj/dHgyOJo+YYZqw/kGfg4 7joTcL3uwdhBDxIcy/hZySIVSAmpUeqVODGPjFyUmvFdipxWJ7VQGnI2chCzRsNoGYZP69v0NO6Y XpnWiqzqv0i8sT/7ecZAqrE+vU7i2jgKt9bjGYEsPEpPqlCngw+KnHQqSV2Kkjkvl0bvGSJa5mh1 o8r71kalvi5O7RYXO61aNdFtSsVV/aa6Y8Q9mlKxSG1/pSmVIpuusZ89HCG+XnVTVFyJ+xWK3fPW 4f5q+uj+twbm9j9B3TvQTd37AdN86nJ6R38P8Q+P4Rpch3MThlsydXreyUf4Oj6p1Nla+UZlOt9R sohfyYtut7OFbLLoCgr94wo5Dy3rvTgnesM4Tu8L+NrclJuEVWVkBG4bGYHbQAbuVvcft8UPPrcO 1AL4SVSOeqO07o7I4CpTUmSRqQM8EftmlcW6+4lL7Kb+7+sL15Tit/qV08uKXTd+dPPzV618d6Jh yp8XjV2XiJYmY4mbZnbeO5JZ2z8qMt1/xb7xkzqpPy741agxrfGC1xItxZWRFW0TFvlC3jyRzj48 sIxlSxLVDw35qp2aExCAargpM4KTbFKqMF4Rr24pHF3RUD2LmiZN8k3yz/d/v8LgZEpa3GazfZyb kekkOi5nNGYK+sGkQ2/1yTduS10boL5hIPMlkzmCO1NyypuiY34dcXeksu7WESQSUjWIKiTzg2+Z eCxTCmclhluVOjNApiVEJxOm6qoCMgfWIJkW0J6eEe13erOdA7//46V7m6Z1T+3upGwHRk4q0edf NvIPWbB23HvxrG3jO7terE6X9dZNvWECTY9KlV2c3nY/9d57A+80NrRTpiefoyp/cNkavfSE7Br4 /P14MpisO3h998pSn6U4bCvx3vVoMlqyC9cWniXYm3BtcdCWqdRRerqAaqZa6U76CpQVBZQPwyAS 1o/TMDQv815+Fc0wQNOsTAIKlkQ1uMRNKbLW+5VUTF3lJ9YfxkWOwQX6LPam/gtep18+1cecZP9+ 0qAJPIzxysrsX9g7NZ+DA4qhmuIPQAgFK+GkFu4fShScTgRPJwLk5SwnqdJIwhoPJIoS8UbrqEBj UVN8knWGY7prurcjMCvSFZ1V0RHvqO7h5xjmmOY4eoI9RcsNy02roteY3Bz989D9MTpk08dYxj3W SCebcSH4wEyZzRDTSyV+sIV8QyL48eA79/kldV2Qly5JlX7uFnzxxAHhuz8+qAwkJR677IQar5js qe6Gjs6Mpyu6MUqXRCuZZKwkVhVsCk4LzgveFuKcviATciuknkpduE7UPURdLAXJRFV1MhRKJgqG vBjuwozq2gZXh72qyqwumSJ1vZDFcufAa8f/PvDO1qtWLKUsv3+b0l+58robT/x07ZV3T55SeO3o ueO9k5fHerunLz645YaHqZ88mYWvn17965Fc5tbLf3bs9Z/Of7qaq+2j2y5es+LC5oUlphrz6M39 S2cuGWELBSp+tmh9382otcuy76lxIdHa1ZkUzzrYEra2sDaSLBtfOD7SUNbJzrJ3501x9VKrCmXF XdliKWmxcO6hHSip6FBsOqeqsaCqNuNgaDg4y1G/Uw0FnSyxOm8m4hpSl6qtlOr4Y+quc1patJZj v9l0TNWDWxCZOlClZRqW1rCucGNit3RNnzHwyYHEzAK9e9Got05auu+bPfOm1s4uKvrGJfubps58 ITMidkl6686qTOkloyfuGEMxzOinB57qvXy1IKKgKN1HI8oLEnWHrjpOeRoa2gdO3nfHoURp0d57 Z60o9VrDxdYSPA1PR9m04JmbnEELMzZqGq3hpml4LZRyFJCRYpxJAvva/tqhMBfdQhwdQ5xu+RTB ZCj3yXvJFxA0fEkt0tzCPKQ+K5nxaTo4qoMjZ4yMjionx1pWQ8WAfA8JGfWpqixT6tEofiI2dOgg JyPNLScvYO8hF2PY0X9oB4l2RZig2cy+iHvA7L2rGSqKnvDdTLE+r1rjIeSlYhSt+W/2vjwwqurs +55z9zv7ZCaZTJbJZE8mITErgUAuEEhCwLAYIIGBIIRNkB3ZaqwbuG99XepWl/pV+1UpoGLNV6lS ilqta61asVK1ioLWWqSQuXmf89x7h4C29ev7/fH9IZMczyR3zj3nOb/zPL9nudED4+oKqVR0BZx8 OPsVpJLohMebJe8VBxtxVmX79Fm6gxfOEUWJnkMIB3YPvsS9XUwr1LIv8dqTF/LXDqwRLqZnJwZ3 k6vIVbsTgzD/MMeJc0EfycAE9u2C5YGlP45cU7I7MioC1psojZepqmoK3QazC8CHVI3fBr5hAO68 VVorU75G05kN13SmxSs1XVul8ZqqSTzZLBJR8TgJEApedHL5XAM3luvmloH3J3Pc+U74lSbGxDpx stgp9opbRFlc6ABrCGQUhJvGNF68samhgcUmmIDjsMT43r17zf8ooAFZLCwezeOjPGjCFELEua/e mNh647M0myhbjZPGCXK3MV98eWAjfTtRAHt7ANYeg7UHYTLVxKX7RWfQWeTspDOCfemS31dWk81o T4AdnuxsOatG4ctrZCU16C/zJC2XJwe5957BL/RMtmZPIfMx2E8ZF5cLghw6KHAMP7Rt3ke7LWP3 BRIh6Ly/m32I/UpHTs6trvXU6rU0uywgu9nHYQ8GMFIDnbdM1SgrDNQys6VsOOgcxuGg81ccjnUe ww1cXoP+Hf5LVMXtN0cYWWL/4IybmhTeH0HmZDMMwPBQckosDgs/ZSfbVIt4EXsrxs5pOefZ2xOf kyfuu3fitInLu2952NiVX1xx+YJPCRc/v6KiqK+upfKKc41niXTxA7XDa8hzKx+qHztcfDlUGNs2 d9l/lSuR56lQNzEtw2VMS8nOnpf4YfeygnRP4vcZ+UULGTdbO/iBOEH8FLjZSn2GSFyqFEglGWog WBCsC44LzFZmabPcs72zi3v4+YFVdINnVSAlNTVc46elpYU1kpbKrQaqRRjbqihrKltZJuYEnQEm WWcmk6dzScxUhCClRjP0Bd9MIgWSybnyv4FcnEYl6qvFCfVdraOum3Gv8dW5PcuXnDuPuO7f+NmN ni1fXLn60ZbxkzvHTXhyyXUnVriXh0rTUjJmz59HCp7eQ3IXzl80ou2TxXPbJrd/cPOdh1omtpx7 LpxRhtOdgFM3l8X163kN/jb/UrrEJaQCINMAkBs44glyGsJMQjYFCiVJsHaj7mPosFAH3h+ibV3E E6mI6OCrCmn/b2CWfQpmR06hLG6rW9OCmKASTlkL0MAmfHb+/KZFJ18wtpN1bxHSdetDv9u8adb+ K3/xi+te71q5kv7leeOx2U2Alab6eca+3z/y+fiqopOXlDa0fMRwATIS7gQZObjrH1drOckrUYkd 3nz0JSQi1lJeqyWKwClE4da6PC4iqQGCqyb2qkly1QRXTexVE3vV0PkYV806uGqy3HnG4WqMNyZP 02qMJCAhx2/hzoEY//rAX3kP+xZf3mEs2ZF4w5p/H8xf5W7fCXNlUw+yiVAqk1qFlxWO73AwKrhn 8DU9jPu30OFxgKEg6JX9Rxv4J3sDP7U2UBuylBis5ctYFXpVpmbAeB9bBpx/oS/hodsSm/bzj4tR Y86ORDVMHs/nn8V74Xzmc8/pI2WiSpI7S0pxR9217jYyxj3V3Sv1Oha417nXZXpya/U8kpfn5L3e tBonzarhtQ0qyfXmqt7onkFDT2ETjy7nBES210L2MRvZ738N2SdsNXpSz0M1ur7QU6gX0nBQ9bNP q3jEVSe7Sl1SYAa9kkCNHYlVwzorTLxWV/jgDcYP4egL1rn3cgy67NAjz+F87Ad19Wjp791svLvt YePgosWryD1keR9Rb/NHNjSMf2TlCeMdMN5Sz1Otxmo6/fzh03t65pO8Z0gvuXNU2yehs8OREuMp 46jxrvFUYTZZ8bCJB3Ek4vnQTr5WYXhIxXUrXoUqiqiBtyAqKg0AV95rm5ETuy1T8+VuS1gfmhjg FFtUej5e60eJeVBcKSiqjXAkdNcUF6/wAeAAr9gpgwE7QWDBScShRBtFoo0r7LDxWAfhJH7tZMRO veOaGpsaQcCrY2aUlYGqGtpqceT+RPr+/fQv++mbiSLx5cQe2gryuAJo2esoj149TxWqJF7jq4ji WqEpjm4twIu024oEYsSA3zN4EHHC2ziBjoETZRnXxzAauCI5vy+rvAn4/hBjXYkqBvRoLXDD2miQ 8cPXE7ufeYZOeuaZW4V7br315DyYT9ngJ/QwcofVemAZ2UqovzrIy7KjhldTUvwBVMHWbpywEXvU RuxRG7FvMV3M9gN3guJOXJDmSSNSbyqLBCShyQLJjI4fMb3/M1x/hj96+LNnK39U5yjZ2DRnRTjD Y/yaEnLJvtd8zifc2aVFxesm8b13wcxfAGStR0n+Q+9LV2eQOcDH1GJ1uDpRXaJeqf5BlT1EU7NJ Oi0lMbWBNKi1jjbSpo53zCG9jjXcJsULTup2coBQsguGUdRd1AEs71KNKNQCJqgqTfO4crhKYMnC FLjt+YAuovCIHkCY+9/BK4mqJM6+sOH1xTfAi2mrY/F4lRkTQGw1mCRx797NiZCwF9zkzYl4iPHE 1WuiUSIj4Eg1Edcbg4ldPwDIvfp5YjG95S5DBo74Fa8mmi29vAGkJXLrH6O8ABYEWZp5ZjjZIwP5 /R9ZkcOWFZGG2k5wbjEWj8aDBZ83DEzbTz8SXz7xrqUbjsGcnKRNnz1DI8PpcLFOW0l7+JVij9ZH V/F94irN0anO0Lod/EJ+Hb8etlijvCpRjgpI0AWdTU1Amg4KVmgWzhHgn+xQeQIWQ3PAiWIFBy40 QgEu29Ys+mQzXmN6lIhnjOtxYRwqhEB2mirF7XFH3FPcQPdxUzHGIwq4eSmy9//eXh227dVRy165 hgiNxcqGvvWl2UDAbOa4c2btrhGWCTTeBd2dCwUS7wKvgmFkDRdfAyqI5BFm2QiJisf2G+duMHqf IG5yDbmIpIj8wC380hMJAMYz/CiLb4jDmb0mMV13yhG5Rh4vT5Xny6tleYNEPIRKERKUaqRmabp0 HumR+sgqyeEkgkS7SafEzLoCTpGgSITKzNOyFv2lvegT5hJTUJufqdYP6eOHqHVTmRei/NG2sR1h 8geCoDsoxasoSp9isJumCCh9wZa+kJS+gBcLtvQFW/qCff4EW/rCULZwhvQTGKEbehDXrAaHFZwz U8Sg5of/PTH6CVJNL31CrDnBksm6sBe47trB98S3xM+5NC6P+6WeK3ACSM3hT+PSpHRnun8mmSlO l+c5Zrlm+ealTE/zBllmK8QWo+KSNqibgjSjJkijNaoWgvXhXENB3l4qzxwxyyAcsg3C53oNWoS1 BZ4CwoK6TQV8NgI1O+hB6uDBtJJHQmcPf+NZYmbPWPosbveQOsSZTw5sN9UfNAnv6T5DipczmUN1 FSdmz56/oGvOyXvuNAa7u+f3zJlFxB/+aLDFGHjvz0aCKAcPElksXGgc3LPHeGd+76IlCxaQnCce I9HF5y5ZmphPcslI49fGQeNtcKnqOdNXEG4GXHq5CPdHvXJEYFRWe6A9a4r7HE+vR06v4WSvTGVZ DdVovKp4opEo9QVNNb2KE4Zi7LjuQHTZkdnPbZbxkc2yDlvO6sqoJ9oUpelyQEVNqNqyVpOwUhFW qg0r1YaVag8HnQ9wq9TlOaezhi+teP8Rm4jGjwxxUDGyPzSsa3sTws3jR09+5Uf795MfXP6L1s74 i3X1lVvm7vtfG28GN1TwLHhw9OTJCWAU5ZUND22bvCY/kpH4WayichnDoHGBeBwwWMCdxf1ab2H4 E0JCFsNfMJSaNcfR5eryzQH0zUyfmbUux9sZ6Y2sz1pXLhQURGt5R0lNtqQiDoO0AlCYnSJx1WsL QShmaqQwmMGpUhbvybChmGFDMYNBsZgJJmNttaeaeKoj1U3VfNnpILTgV2XxVzMiDuquynsk9mFF BfryLBx1pMnKFsSJGan7uvsKEPVS2XJb+aHAPN64ftTDr6qh8uDp0OyaPf/dfmHhpSWrQxmfDoWp cZPH9dROgT8NovMZdI3PjCvb11yYrvF3nwFY07e91cLrSX26QrJIORlBGrLGe1oDrVndZIanK7CS LKU9Wq/jQrLe4WOkw8v+px41FK0Xa6VOnRJKxVANsg8Gaz3K+4Lg5bkYkrOY3FyZTMQu1JAuzCW5 XF5WCYFIRkyn8yom/QLcf0JQ/mrxklMArgJeUhGLNzRUJCHcaGIYoy8YvAd2spflVM1aimS0JeUM 5/hWY9BwGx/vJ/ds2906dfa9184vr4ltmPLxgblXn1Ueo1MSO8SX88qrb7/gnjfryX36gtystMSL 0fLSFcxaXT74gUjBK6uEneEqLINSbluWYcys38h6IVx1Grap2AaRVAcwuADcIMLlZSiBSIlSHMqP 5Fc0KHXe4Sm1kbrSicp4b1vK+MjEoubSWQDfzkhn+XnpizJ6I4tiPRVbUldFVuWsK11Xfrk/T9Xd 3nqFNUBHfOFiIUuKRgtqMHBdI2nR4mAYcR5mh8HJZBv2BbloWOXs88K0ke5BvbSuylO1qoqqy86y 07NW5sxKm5mOXFoDSxAEZ/lmFi/xLS7e5NtQfIXv8uJbfLcVaywdAHtjqxw7tZbP+LWQzNUW2QkC 5vzln8oNpKaKdGrblNdvvscYvMy9mhRfvOeF+QvaHzl3/1Ok8W93Ao93dxqf3HD3r3o26Z9Oe+An 5MGZD43UWxtHHp+76Mq1C+aGA+FA6fP3PflZY9nh1nmXLokvy3QXB8t2WoXuwlGMza7V04lQK/G8 4lEjaofKc7MJRW4ZAHt8TNfQRM/uEFn49rDuQOwqFnAP77YQ+8XXEDuIAV7RTql+GTMLviwXyKzt EY4mPt2f+BRmEj3xrhjdwWa2E6x0Ccwsi/utnpHnzwuN4kepk/hJ6gUpF6QpmS4+CBuZEYgM8U2P 23blsO5D7oKc0Mr8sOhpFl6oDeEvGyKeSCSiR3hPwLln8I/mspxYxOBMurZOHMfJ4gJsKKdtqJyY x4LBnGa9DHTO+8b4lJnGb2o8La0Kuw28e0gSA96KJS1TJ794xdUvtUxt2R8tKrtl2Xk3lxdF99MZ 9/51yqQJE1unffQgv2Vgy6arG8aMHTO24aYV/JUgKzvCLnFX64taSCuoKUGUpZnS5RIvBUCaoizM FC4XeCHAU14hzZgOXEu2UokT6Xqe8DxVxnMTWa0qL3D53Agrai5x5ysehcCXg4/xtXwn38tv4SV+ ocyi5swdgrPAdjOe9IUScQyXK5gujILzQ8S5iUPG8cSh18ir5FXwLyrg+5CYDfOeA+7NNczL4J7V H2rhF/ObeN5FHFQQqCgqTkcaSedDYrqS7ijhS5QSx0jawFcJNUqjWq2NcLTTZqFZmaSO09odnaQb 0NktzpS71E6tlyyjvcIycZnay3wVYa2yVV2jbXUMcwbgrnJAEgHnhEf/RMWW4zmVApxBOUtUAmmM 5Gqkdq5Z2sytlyRuDTgZTe557j63IC12eY+CGsBKgLSGONasEDMdQoB/shwpfMG64Uu+xvjeu8Zv jBffMjY8TxpIDVgkUs9kILx2sgwYaanw+5PZwiGYVbPF9h3c0/ot68lmmWqCqIWFoFYm5Gn16mRh rDaLnyfMEmeqU7SZjiX8CmGJuFjt0RY7tghrtTQHW5saUGSFD4ClEgOSJIuCTDSHRBWW6XURiabS QlpHW6ioKulKidKgtCoiVWRNYF6Di0vlCrk6roWbAju/yKWoUrpUIjVIrdI8SZIWgTMcr2LfQAQq KmD/TRFY+WH7C0QQVykKAXd/eMKg5ANjmdHzByob4vvkBvJD8eVETsJDexO304/ox4n7aBzmfiFI QMH4ZJdex8uKpKQohUqdMkGZoSxSNiiKsotSXpZ50FLgcbBIK6xLlgWqrsU45VINFTRAkrnoVjQD +QmzgUfioW17o9FaljYLggOmnNzA3zBwgzBtYBG/Y4+wdMeukzfCLD4zNtKvJJZ4Gq/niNMokaYB +DlOwnJPCVUB+F1hy8k+aLvdR03HvML0VKorkhlAKyxLv0ocp4rxAOk2Nsp3XPePi+FeP4V77cJ7 xXVVmCYTnt0LtajLLDB7DN2ICMYkLQ/tc91netSo1tyWyjvxOMKYE0lFY3WF7TAl52BmCumuxHG4 /wMwj43XSRdex9j8ksH3hCxhI2x8NVmqdzk1IS9dC+YJMT9TaGXYlmPb5Z6aPadsqbsna2X5Fm1z YFXWljKNKsWjKn26j/p8OUpHJsnMDDXlCGeNUTSieLJIlq+oFg8YtdME1HZAWcdk9zTMZTk4Cdfn T0YVTRWOJTqW48+YkqXLsRJPQr9UMmMGQVWV7HDjDbWe2khtUy0/jBkF9lnkHy72kWEK+8iwDAcL PdQj58BwnkNh1zkwfOtASuBAT8yRygZ2oFPrQNPhuGxIrstySz9Mvmep7QQSMyuujZU1ZqAXc9yM AICXWmvlegpZbUBdfv031mvxPsnK+7CSgKwn0zuLKzZPu+WVFb2LSPb95aXFq0ZNfGy+Vv9S74ZH 9KaxT874uHnqwnUXLLj/At8of1rkwO19d5aX5yhZ+jmhNG9RwVOe/KKKYTcuN7JACQVS0uZ39syf DBh4AjBwPeAwhcshfr2khtZ6RgYrc5rpeE97UM+Z6V/s71O2ZDrdqpQ21ic4SbYuaQ4lYG6l1Bmw 60UDGUPrRT+37fGXugM30G1X4OzGzbI/zrGSrhLcuetzI7lNudSdoTrNODq6cgq7XMWIjxp2skOH ZpoFKU430Edtu3xMd6Cpltgn0WCjed4z+NljaLC3R0+PJMBuJd1A8+DAxjEa3XCazZZZQI/tjt+s 3pB9ZmXP9R3jWh5aNO/a8c4d/R07V+7/4OlLb5r2k9Ypa9vu+Dmtv/pPkzo6ygtrpEDitTHTjZeM Dw/8rmV44qL8zBcY01k6+Bf+b8IFXJR7VJ/kyevIozGS6y5NzQ+NILXuEam1oTbSoTW7O1LHhLpI p3sp6XVvJmvdKV5voMkpRKPhJl715GHMLQ/LNJMO9UFb0Af1YSjfa/LSENVpGSriXVVQwHgCVKTE KooMfOXjKCn1stxkli1m9YYmLeOYtbT4jJcbkq80QYulrfzf5j44b9NzrW1TSPlXPU9M1mY8PvNH Tzx6f8OGipLWoDahvKqltfWPNxE/GV5X9PK41jdeeu7N7FCwwgfYXA7YHGdhk+oFjeHKzOE5HeGx ma05s6Ql0iqv6ifUJ4bGuAWiZI8VNV/gn+gal6lrcnULnsf0PFQ5SGI57xDGWIri0yylc1QvR13j MYtiUY43mji1ip+x2i4jQwmxkRSWV4qx0RQcTcEIpoJXKlgOqiCSFYWNpFwWPS3ENTSFgcisquJs KDaBuFFx5OVSH9MaqCZ81bxviMCFcf1Tdyw+8MnU8c2Pzp+1vb2/f9LGlrt2bL95yv3rJ5xNaojv 2oNnT5pSUETePzFIv58b/uNzv/ldC7MEywY/FHqErVwI/OQDelGhEHNVCiNdjdnjhHZXe3a3a0rq MldP2kbX5mw3aYxEPJmjguy5go/Mqk2HQ27ywCGNor6PIhDTmZRd2AtzOcnkcDPK8Looc6KbonyE oHAIUnKS4Ucx+lFsfsSnH8Xmx9/7Kfuw/7KkBwxCMs8u08TVpksWQw8YExnRUznzIEguxww++IOW shV6Bp4dXVdz3Yw1fzlLm7d/hXHYOEBiXx76++Pkpptv2eWkGYtvO6uycnbZC8V1pJwEAaNjjeN/ K/3BvTsvNVkb75eyQWa/0ReHEVlhDBkogYbAehF4g9AU5Bzu0YpPdCkcq+tRPaobMOc0DQ2aGDxy DkSFg6CJCXt8nFt3eevdqQyj7hw2shs/405qN/cwdic3QyhaQ7efjeNmuUmrgp2N5b4ifSimqqqq EmanwspENlVjRgorEMA2Wac3aGZh82qrwUAxnPF+LbKwcNMKMt3Y1d/Xt//Jpt5Sca6act7VhXcN jOGfuqvgN687FXZijS5hHOAoj6skFXr5qJTRpVVlIyqb1faUSaVjy9orZ5O42J26jCwXl6VuFVfl +HJFfzRYrGcLsu3NsY6ewRYlyw6ddw0bE5Q9EpGi+VUoZL99xP32EWcd3URImJNCeL6nfovzHf76 2a6KVDVV0RhCL4a7EssIYW44xM52ARsphMoyhPsXwsr/EF7J+tBedtZQa8KKCr+ZHhwxy96Tx7vA y0VPz7udedzrzzzuhmF82fXgNG3YgYU9F+blZXfevhFO/4Qxv5gz/5I2sEft39dv33npbdN+3Ge8 bxxLT9vrrx1WUnR+86LmceCfyde/PKmlo6i4cuD3dH5u1kv7+59uAlw/AcCdB1o3lVTrKXwwNbg+ yHtdytgUwU2IS/lGDXscjQ21fWEaxry5xVoHdB9ugzBkGxifszqGxRBybX63G7eFcbQaNGEIaMt1 vyEUCfWEqPe0M6QMOUNhl80RXMmHNlx4scvmCC7bm3dhNIPdzYVDuFjRCUbuWLQNA3nb04bmlXHz TlPTqHliLO7WZFK8aJ7vVKW0TRlSg8K8fn8ofW775J9M7u+f1b/g0V/SrZO3FZaWTBo58EsgBy+0 TXvrBaaJHwFacIn4NtYG3qenkGYK4qmnvARecZ9K1BtRoGUoqx4BF2Y9jIeaREApCGGCVe6kpw9j NgftdLslECtjZgtEtAUimtuCadBBM9y4XUkuN/6+KYH3Y+gBN2HJBgEtwbPHmC557TVnf78YeuZE gRBn3OZXgKNHAEcO7oTeXEz/QN5WeZV4XBGSRSOuclLhqnTojnMcS+lmwh7PImHM9u7GbC9L9Yoy wVxvj7aKFb6j+ShGbHCuHPYImcLjOnhcPy+wiVuPVYSHLvrQGYtOrjW5+g9NFIiCtfavzMAVdBAF 4hXOr6OAJVGB3ZtpqCb7iYC9ezf/3UwHJzAXHM07lQoWHjlu6Jv7+2nkSOIf5ON1xlVSYCBMKxID 7KkAENkF+PTX9/QiSojCdu5G67SYnA4xaiU/w32EEHuNJLmxxJlMCVtOqmUvCC6NMGqHne3CqW3F BX1oPf2Hj6Rd0N+PsSOmC+Q00OcxckBv5/P5kpT8lJLmnObCx0vlxwpIQSQrU0kbW5wrZInEm6no 5SRSXlmul08pX1Uu/vPJlzMVn8YmXI5cgWCKjShWfvswehGE7bcP11OJF2VaS/oCFQRh7nAMF4O0 gMz3FjgyrWcy8Z4evKcH7+kJe1EW7D5evA+8f8V0NL2F7Gov2gQv02VseK+t1KBzEuEAnUE9ym7l jYTxNmG8TRhvE8bbhMOZ9qZkJmOImXhxpg28THt3MpPWO1NjQ2SaTq7Z0d3sTpnzI17de5GX91bE vzwDgd7T37PI9KlLLMXE4jSNAM/GRJXPbz4/NFRBgZvpO0NfBU1TY2otOa3fFUybMbXjrg5eMLuT b2cK7JEFa+4uWtN/3p5H6NbWy4tjZR2j0kZlJ2rp1omXFcdiTKkJ8a1t03o6ezrfPcDZVgWQlEpK zrQq4n9oVdKGWBUzVW2bEMMOC/+J7fAZJoRlbIoRjaeMCZoR06T8c2OCqDzNiphnK2le/qfG5N/Z kuC3sCUodjAljNO/J6wGiTu4NNDA4ZHuGm9NYGRqu7vZ2xxoT1U8TaoQbOI1p10f4LRF72QBcxSZ MyNdt2Q6YHv0fzJPkfUo6J7Bt2x7fdT2OI/Zrv0JfZTp2qd70iPpTekr0wW/gNQNJe5HKfszpFR8 DMt8JAupl4SsX2LkIJ2Nzp4rhRZTk+x30F4W+hfVGafCX3EyJO2YfO6CsafVxkefHDE+JmlHPiGh px+65bYHH7r15p/SYcZnxj7SSHzwGmU8Y3z25quvvvnKm2+wWImxULgeJMr80Vy9oIo2BKtyxtG2 4NicGf7F/guVrZmaHScRs3VJdTgDtkyhcwxRbMVJLGG+dCq0Z5bS+c8s3v66VI/9y4CJ89sGTJIZ jWTkxNJG3ypy8vXQyb+InSTBe2bs5OyWsbsWzrymrb+//cllz7339JXXTb2/fcratjt30Mbt7509 cWphsVEm/mN9U6fxO+PT5w5MaEhsyw+/hp7GQvQ02F7IemwkPypcmTkiZxLfHp6QOTGHxQZE6hNC ulsgzuyxouoLmN7/t9Y03zZGcELvMuOP/zZGgIXgioQxAf/XIgNuNoqi/Kv4wBkm4MwAAcnz/TuP oX/m/174myPTm8fuXNB9VSu4CGdvnHDfQ1fcNO1+YyENt7cBTXFf/05725TiosqBp+jGvMx3nt73 aoulwfk1QO38XL8e4Fxe4GDAvzyg18dpHlFVhj6DYJUZcFxAD6wKUKeMgpNxuTLCS0aEymHVRqia JDEWnG2EsrIOM+6t5jN4qpodpUJ4QucfZrhqe8o3szSGSjCArOIWhfQ1Y8ev0Uo76mbe297fv+qn XWeVlfHXa+rkUQN/EeI/7m4XZbb68wc/4N8QNnLVZLo+U6JqRpCmZxSqpflVamP+WHVS/lwxnjo9 OqPinKqV4vLUnpyFFb1Vgc1in29dzqbidbEryXbXZeFtxT8gP8xwcO5QiZDNX5QLaoRhIje3cLTp AesYjgPHdzSvRt0MXDEmjBKUXAnKrCSjFnVyCKMkISyPC6HJARf12KPoibptbLsxAosRgQwuGpLR gtqp0mThl1WLE7B0T1LlHLdVznG9CHF9rRVdn1fbVyvKqLZlDJLLYdzOy2swHH4qKI758lgsmZWI JYM00ODzcmYFyWk1p7U1RcmkuI3kZGQxzUyMp6XybyTe3vq7CVrXWwu3Xl1YuLz4+7U3bWkYMfxn 5y18oVlrfXHB4mtjpXNrvh+7pKWFjL1t38i8V8d1TJkxNjc3pIbcRbecP35zZUX9WXnP1rZ1nD0+ Ly/VGdKy2ybCXo8ePEwT4l1cBrdTH+sUw2JM5B1eebTLoYkZGWlNvNqR1ZdF3dzVWYrLi2j14gZ5 kWV7cZu8YU2RWRhHZiFYH5YjYijHOgs2vOUkvOVMDHrgGOyxB9MEy2lYlbg98/RIjonvCu+xqriZ 7KquNstxzJBsLYvesNrOYPRUnrmaJmq/d9ZPd/b19ZNLja1KKHVyx7CFqZrm9u95nk67i4wxnrrL 4GctiBUXZKgM9T8HDjETznwqydADDild3izzVAyqom+sqBHlm8Otx75BmR7Vs0xl+jW2Ri01etim Ecf06iFuv9vUpyZT++dev2IXRCtJ2m2FYG05K7ZNVZho0dApOIRiEzXo/B01ibIt7Ywsz2mxWVP0 aOoaLZ5Wawl9SFLfVy3M7J/38NId+/q94YwZ09p+1t6/tX3KGy/R1xOXdm6KlRVPGsmPBRmPYs9m gIwl7hp9TKFQItUJDdIEoU2SSsQGURenij2iKIXZn7kJ85Qv5or44Vw9P5Fr4deTzVSx0vgiVShh D3Ds1fNVb72Ty+SWcZs5gbuGpfF5PoXv5dfzAp+JZYoXy3BE42BR4mYl5dAsPnyxRK6Vyhb6jMb/ YzT9lnQTQMLJ+4T4wDZ+E8xmBsfBVOOck/viCU4B4Vplj1+cquzDx/y+1LchDeaz+DJSSkv4AqFQ zFdijhoyUmwm7eJMMkvoEmc6VtBzhYXKMnWhdp5jE/keXSOsU7aoa7XNjmwnW74clkSJU70qVe30 vSZ1JjP3IAD2oH+FxHNh1HCFCKBr3V53k3ulm+ckxuGRadqVPhLWICO1NJ/+v8Qq+a1CDWYluU9P 84M5iZGYnepPARGlSHXGOw8b7xl//pnx1r4XSNrtJPtpJio+PsDEdTc/n32z89QIe30RyMzBvadf rToySIAPyBlqEV8kN3IjSQ1fI9RINfJIdZQ2iWsnzXyz0Cw1y+3qZK2bdPLdYqfcrXY6VpIefqnY I69UFznyPJRTmmil0kF15Xt0FYA6rDk0FBaGVPiwIAqEinBgJGGzsJ6JSoA+kaiLgNAcgqAhbHIB NhJM8hr2+BL7gxa6a55LkKhABNT0wsUsDBKvwuKPGKsEMP8oQvybCwGiyTqAaiJcdASo9K/eJruN KUfISNL4R6ON/MyYTstppdFNHki8xaQzCjgdOwkyd7U+RsDq5ilSj7RKklReFtP5NHECaeNncTPJ Jl6lMsOEGBZ4oY2bIFCOp4JInXQJIYTyvJBcEjsJE/EsiNw1qkclvJAijBd6hfUgl4sV7/vmenA5 nB3Jsc7BXqusI8U8CYl1z75kjPstmUm6hfgJmbwiFA3s4xvZ3OPAjv4Mc1e5GfqIoDKCr1Um8uOV Ofw5So/Sx69SNFnmRwNIqTJ6SPXCtY6Io8kxz7HS0ecQ6aVYxfD+N1UxxE+VL/B/HthMr0pcwi9O rKF3X8XX3nn5APOxyWZjIy3GGFIGUF2xA25GiIOLdOBDxEeSf5rKV02LH36Y1SKYf20sYr0WctcM eb1HRsNrLbmTPEneoJReSj/grxBGCc+Ls8R/AEjd8gPyb/F1UhmDr6fU27QU7ccO0bHU6XL+l/Md 1wjXy+4M9zueK7wl3ud93/fXpHhS5qR8ETg78FqwE163Bl8MvpjqNV9p/rSXQz3pwfRHwg0ZGRlv ZTbB6/dZ0ewJ2YORn+ScHy2KPpB7R14079X8ivxnC2YVPFZwvOB4Ycp3r+9e372+e333+u71//+L w9pr8Q5oj/AcJ9NrOS+XP/gitGWDh6AtH7wD2rrBT6GtH1wGbQP+dgS2Iwd3QDsKr2zGa7oG/wBt N/Zn4zVz8CdxaH2cZ/BCaL2DPVw+tC9CWzd4DNr6we3QDsd+w+A+VviLv505yJ6unoU/78KfdMO9 8mHMF7kCGO1TaL2cBq0P+/Xw2UIcuQh+y1oftvXYjoBrimDOx6AdBf0SzmO8Bq0P2yz4bAms/Q5o 67lsaJux3wqfLeGmQVsGIx/iyvG+5XjHcrj+GDcMfn4jtFXwk2HwqX3Qtg7+Atpp2M6Czw6D+e+A tht/Mgf6FSiHCq4QPlXBlWJbDqynAsepgDnPgLYBRq6Amd8BbRf250BbBXM4BK0PW7a6KlxXFa6r GtdVjeuqxt2shlmxthVbtpYaHKEGR6iFmdwBLZNeLVz5B2jZlbV4ZS3M/1No5ww+y9Xh2utw7XUw MmvrBg9D2wXj1OG+18GVh0CCHuMgtF7ATD3MhPWzBsFVhE9th7YQ7lIPq2ZtFdylHsb5Etp6kE89 zAHQxk0YBGTATFg7cXAYtNOw34njzBicBO0s7Hdh243tHGzjIL3hONvhONvhuFP/Xd1zgDWVNXtT ASkiRVEpEQRBMdwEEEIRkCIgva1SxJAEiIQkJgFEUSEiRRHXsiIuAqLiuoiiqCgsUsSOWFHsurqu BVQQC7oL79xDwKjs+/f73nu73yNf5s6ZM+3MmTuZE/i4DOgVA2YIA3rFAF5VATgZrJ0Bd5wBLGIw CMK5kB450IDYQVk7KGsHdGJ/nI7J2sEI20FZOyhrB2XtgJ8tAM6FENNgD2SrADQBntiDtWOQDiG2 O/ZAtgXAIAjnghjawzxxBFItAGJ54gjzxBFmiCPY63fYfwQGso5Q1hHKOoI4dACIWXQDkXkNYDjg dAOU14g73Hd3GBN3QPmEeAD9nQBiu+8JoATxAmcTBwBVQDZ6wXvWC67aC0jlAOgM6ZFA5xygvxPA cIhHAtwP5pIf8AfDgwAMgDwBkCcA8gRCSiCkBEJKEPQqCHoVBGa7AYyAeCTAg+FsMJwNhj6Hwr0I hZ6Hwn0MBXG4g3wHKB0AYr7NA1I+AGKUeUAWw90g7jnwEsAgAMMBTy2AmJ5wwIPhWB2LgOuNABmI 4bOBtggg9RRAb4gHATwSyM4CENMfCWQx3A3iHkBzJJSKhLYioVQktBiJhAA8ClqMApwYPhtCT5D/ UZAzCnBiOMaJIFQ8dfhZBXRk6KEQOHAupctwPMBXyHACoCbKcKIcDwnsZrYMJ8vRFbAclOFKiBpS IsNVcT5IpQxXQ6bi+rAnUxAJwJYK3gjiJICr4y0hToZ0V4grQLo/xBUhHg1xJaCJjRfIcByihr8q w/GIGiFRhhMQNsFLhhPleEiIDmGZDCfL0RWQ5GFcCdElVMpwVfwWwlkZroaEkJkQHyXnvzLmG/kw xFXk6GoYTj4JcXXMN3I7xDUBrkF+BHEtOX5tuMZBfKwcfTyUfQvxidDWoE49OR4DOXwyxq9AgPh0 iI/BcEU5nxXl9KvI0VVk/u+h0FEaSvHlskQCsSBWQnEViIQCEVPCFfCpFBcejxLEjYuXiClBHDFH lMxhU8M4IjaTz6RwxRQmRSJisjmJTFECRRBLkcRz5BTFiQRJQozMEiQKmXwuR0wdnrQbUhLEiUvi MUXYWAwsUqypqCXFdJjPzJcpAVpTKK5MkYQjmidIoiQyUylJYg4wBhyIFfAlFKaYIuSIErkSCYdN iUmFbriH+riAWREcCEUCdhJLQuHyKSnxXFa8nCy4cvksXhIbiEoEFDZXLOQBA0w+G0hxAQMLcHH4 EiplyLaAz0ulmHLNKJzEGEzosyr+EPOIHkF2NpcfRxFxxBIRl4VFWM46EB/WZQ8dMOUCKxJOIrYd Ii6wyhak8HkCprxR4DNz0FOOiAKWKwCmAEySCJMkFDYnmcviYDzxHJ7wqwXFSyRCOwuLlJQUauJQ uKlgqywkqUJBnIgpjE+1wEyILUBRFiAiUCKYCA/hI6lgFIOk4lQRDvyH8c/A+/N8MCIBVz4o90xA YxO2Eg4Q6gkN4H2MUEvYi+xBKKB4oAgNvCmIL8JFWIBPgIjBOxbIUhBXqE0IIRNQuADjgwaIgrgA /TxwDQK0OCQezInhiAOuHMCdDCAbcIbBERv6wQQcXMiHYRKokw3mE6F/CYCG2cVm4gF1ZI/i4DgJ +DTEzQLXRDDGLHChfeoIknbfeIL5Ggc08aD1oXmxbI0U0DJRQVws4aNpvtVnBmhYRAZ9TYGxwvRI oJZ50EcKXFkquCbBqAyubDACsdCKBMYCGwuhXCKYlUAdbECLgbJD0XAHH5I+IO6DsiK5GSH0jA2s sKBGLvQ/BdpiATiy3cExxssCMUiCO8GGvAIA2XBeCKOTCr3kw1nMFlemgSXTxYEQy4qv143N8yBm CqTMwBXb7ZhhSyN5xf9G89+P0WftbKgpDtBEMCck0G/WcA6PvPZB69/6ZS8XAWwlg2uRQHtDdwem f3CtbEBJgSsXwAwfeaWDcWZ+EVMO3FeBDA6uahBPAiMhhBTobTJcDWdYD8bJg3fFf7dD8TByQpDt FuCVAl9UGNEvs5squ6ssAJ4KVxgH1ygEGlIBdWgVYkS+ImE1hzs8fggrFOeLisX5oibBqkTUJ9KI c4iziY4AMgA3E6wNixpWyVwAhwismg+lkOEHUYFucPEIT7oY5IBdC4IbGBh8GhfonBBkLCJ7Shfh CPa7L7k+DAHnTytw6sHxmBI+kAU9g0+IJwUZG+TvS0F0ga0BaFEODsvZgiIyspy+nARu+IpD8DwB i4eoQagF9eBk2vBYXyQbqcuuJlgfgRAJuYTVhDWEPDDCI33IRzBlgKPAkSKCI6yFWiQybTJ942IR BFoAP+Pmo9Jx4WSlqVmeWe9VcQr4Uum4OYA0G4/D0ZRRJTJpmhoBP4GEoEzyqGlkHBEntcHjiKXB aCBqLkfRLdNP1wVHC+zlD+4zLFuwPcXyayb2QifJKSNqnblau2C6skJhf3HFg1+f7nRO20x9VSrV oKFS4gJUSvApJWD/CWEUtWLMnYCByG3nG4ek9YArQto01IxMCCUqaxq6CoSpIqz1oZiyzCg0BsPm qyaJStNHdQeZtUdsn2iTUANsnqCp83k+SCCQUFySJPECEVeSiuqPU0VtUFs6+LGkofTwcao0Ohha AyL4CUdTYayAErImPjSYpomOwQaKmqO+Y4rjQTMhAWbUUTWMqKCpEMRhJwr47CHHRv2VY0bopEHH JsjPszmUYG4cH2tRAlxdUCnOEFUd3kAcjoQQpLjRCKCPwktxOKQmddn1qGp3xk9We2m3+oytvVIa PxkUn3Zf9Oqyx9NreScSfIJiegvxJ3w7vHgWk2dyGtqMapQ9a1Yk3XWv/3mdWsBJ42k9pb+rGhlc dpn8Mabw4nj3XRu9DQovVFsYnvCenia4qa1vn8dQZ9ytN+uNtZ+Oow/0T/EsP8zDZRd9qj3IWiHt iyzNyFyVX9VzdNOOi7blAavGTcn2u4uCA27vqT7HjONZXTzGbqrVu0PU/aOWxaxfHFu0Rayatb+n 5Q3lmL/GWtZ585t09/Ev67w32wcE67TFBqb+XJl9JmxmiTQgh086YN20dHJ9UKxjoV/rtOWW/MzZ 5MvFl7yz8PwsZGdj9v1gPPb/qHdkfEQz3qOaIJx6xkQVdBRZEaQuiaRAIKAZZRgVR8zYimYUpKtH XBK+4oqKjQKXax30zR84v130z+ebdDTShKxxcMgZc3nmO1bnfWd0NOajJg43QCShBHBB9TCCGnEs UatVry0ZEUbs777V4rc10I26w431GlXGpkcTieA2ypK7dQhYRiyt2Lfc26Sn7Rc/SdncKZKpSdVZ f1b4bFqM+D4790LnDvekWlnaG7zrqXPZrR+CW5tL6sMEr1lue9yQl5vPbG3XPapcMl51041b+pVm y151lYv3rrvHyHfcsvAX28QrOfuN/rz/7DpXaX1Off9DpM7qzfu0PnUNKumF2eaNsxJMF9XYrnug oHo2Kv5CfbpLQuxPdTV1+VbnegjqaUveXnkw6/7S/ocP9/a/u9+uWi28vuGR/xHbsrTp1xxvWynH 2OBLMhYa5b6LZK2rCq9j3FiQF5o5wfKt/ZZSqUpZ9Jpq85rtu85X3KIcaUDHr6JoqU79JajX5cF8 9NEGU252k/DXN7sr2tJniZLVQI1ZAmpMjKzGMHEXZ8JaOFr+PiKBOvMv3tVYwWGAGmNDp1uhdAZW cGio5fAQzVj5f+KbKkwckLpEX/+AoCF2wl+w/8faU4/mfnIX/RScUJzrjxg1Hr+m53hgnrPtG/F6 qcmTzRpI8E1dqZpDm15d/ftZawuu/WE74fGxvkedV5mEhtKr15N8Iz32dM1/feVXbsQE8fNq3bXE C2Zupex5FvpbovinK3QYUk7L7l8qknLGP88u0DKpXmGSvPOaLSPzUbVJu07ftGdXzo4ND5nUU7A2 O8usv9fL/MmaD0SnZRcubN6QpbqI8OulfpVZ1gM3jjrdzXcftezdjTmVEa+TRXopRstyrVt0ow4G EObMTlTYHZqzhZxenlEZ4teRcf1jw6xG2vFQ1cL2YC8N9MVvu3LS5rcsCdfKVjxkwy19QZ+cp/ii 75pW7YM/LjzfqS2rPR/QjLcj157Pd7HtYpL4zET6j9EbskL359aeKjwgyYfbpzcau+vBjayQDuuG nhFRBx2bPvJt74YxGBAdUXuUUWpTap1lKTs/skS8r86PwgQuRrWQnbrFFq7BIPGogIR6DnmIwxEd UDvUdmiM4rPM//JAChVyRHKaJF/dULD6mBJWVmiqdvePEcxK7nCtOHpq1sfJHKt9SVWL0PzNR1Z+ FD3uv2Dzu51wSyBFrXbRobO97Y9XPzUVitu7HjYvfdkdZhWeLn2hfkNEeK7h13lXNW+pm78KM+lP fpHC3bZp4TqqjKoFf94aIP6M39HxMX9HXX3TwhB7WvRjc/75bt+puj36yUuz9p/Kvn5gatfeVrXG xyUrnl58mikKkerwp54p/uHQBP0mwcbbMeVNcxIqz3Y5bnh00KJiSQojbiGyVLqNoH6P9YOXyax7 Pxg2ZStf0toRfUdMF83QHzhjdnJykH+s51k9vT0nTRjcAL/dnc1kHlU0sXvSrcTJnukZ2s5pJa0S W29/UH22geqzarD6qC9ULvRvRIwrxtx2N5i7JK7s6xr07/Q6M0DxmYHSUCsrG6z0MMDwX+h1QriJ HLGEmSj8u73OHRv+p/1nZnkv0jnT5jkzuPFjhVatOb1Owz/ozMqumZY3vWgbTI+sZz8wCMisbZ5z eQXpw6uk42tO/9S+jyuMXTwl9umRmlerjl14+fOfGjuV5xmaWVx0vhlGnJh8OJGd6B1y+273vYaS lafT76/wwdtsettYrBimHz/7ws3G5EiLZUeMiYfCIhbqsgbS0xxethONfRkpEoWo5siOLBvzpLNq z/UZSmnJ/dt4/CUPOmeuKyhepBY91V8nZgG9+MpKv2mGkfHua+5ZZKoHHOw7PGEt76Xxj5ofzqvf WKXWK00Wzzj1w5Ky1gXkTlJVlmXNh00RmS6Zc1dt4lcZmHu2CopcHyx8usIkP2Gw3khxpiAik0eq OIr/P7oddbKS7GShjcNaGESuUAqe+jkVHLOqmJO17pei53vtXVxPXULHDwto4Ykq+qPAWTIJnEJc EZcvO6Fv2qgRCtQm3zG05rSAujH525kKOLU8ofvaV+KQeicl0vSBo4HBq3S7GOtrdoQp38s7Yj/x 8qe9u8/WHAicNFGgyF2eQCgz9OjiHUpMMzzqcTXzzdrRxxVWz2h6sfyZMMq9ZMOV1ra7+Y0PG6Ze SOs8u4/enn3sPKtlxmWdSQ3J9+y3Vk8UF0/K6Th0SCMkr7eomeO91dSkaMHq0fanNTmLPesuVq60 86+KmXsPffaMofcot+cWI6NPc1IeO51FJm7u2Yp3tVjqkVM7gL/J6fO+d4sg2VhN4qu0brtjykzz 7B5XNGaSLV43ey/55Gb60d+cTwU71u/Jvfc01mZtr+HmotaqlJBAu+sit4NG70CB+hkUqA1D7RGp DIXtkeK/1x59UwiwGmULuiFrUJpoNGusRlkODmnYEM2o/ifaoymo8eBQn+/KFWLf6LoFu1Pcg/3s bK3dLKdbotau061nuXrQjFGjwTXpfrmm6cHYoijBHBH2DfB/LG+vidMPbm6ckBFnfMAkplpzThta 26hh+0cGx0qhZcbByfHvFIiNCgW9Nd1L9WPMPW7O2RloVXOV1xVuf2jl9tmOYxSp1gnuT5od8vCx +D063BfeXVPMXzqkROy8Jiyc812m+qX90z/k6j15bnbo94vF5JjdopBm+1MXnY4+rJqrzvtt140T zUk29b2rHmY8Ne2Y2N2zr1u64/oNQlmJduYnx48VD4/Qz5Ti2W+eDEwwWaQYvFob37NySrKXdNHu V5X0xadu8Mb6G3IKYnw9LAaM9q/qLBfWE87f6qCTTk773vlIcbt5Fq/mvCZ92dpTy/eNs6D/EVun V+Ue+qHy4/S4lXFmGzOvhG83km+nPheEpwXv3r/K637CfTQv3u/9ltVL7v5I/aJTGrFi/E86JYlY yGL+r3RKQ5okIxfrL/o/cuNI1UrVKSV6vcPxXdY7b5NImQZhPa8Ky08rrrWovuC0qD0rLcXg7otx B+vTHvUV9oxy96zUquOa98yMiwnpebliypgNjM62m9l+Oe8XzDZaOkXbWbGkQZVGlHZYH1EpQq6u +Xkx8+ThHJdtM2fcmbtzyo92t+rJUVrlB0f7NOU7rOmJKfwQ29X+Rte0in77HE3pl0+G8R4+H6+K DX83yzdEPoU1kPdllGrXWvWZ5ht4x5C2577NmP1Mdb3ijbn26/QTlLh7Gj3TQqVO0YitaxG51anD osFfrOT4Z+383tOdNs1sZqnvNUdha0SVZkbTtR20CfXs65uvLHGaGuERrORwgdDnNA9pzQ1m0qTE H0HFKsDjcGhG9r94ZPviIPn5q67SjFPYp5Ns25QINBX579GA3c8jZZoaKj+rDarGsCCRBlIdr95u 2BvAZq1uIlIOeV28eFZNXx2NlRNRoc1Fw0rN06f+/V/ZbDdJn/w3fslE+aoyEaU4pJz0nsAvj6eb n860K3f48KzJOTT8/gvjnhbF8o6dB1q8OknnjZZoT7xKIhaeW6FdqPZDzpHw5eM27k46db970jmc 4TGHxzOqD+9nl9e+svREl2s+fZu5zcMSbbVeN3X+o1E9CWdCz/7Ebb326vKutUuCGmb0B2k+XFHn nha/8066bgOyomHmftRxb0XQ92tLDOLeCKOa8pBLHHXfx9vuelZo1RiUhe0puHTi2r7NuftPBxYh wUEx/RHHJxg773u/JQK/yzpa/0AlPceZm8BysbyrZr9aS/GtXcyxdf3FmR8Lu1O2b3p7Iu20T7Nx 8ZkUhe59D/cciGblMs8tc6kvul2ucf151tHkRzHbpXgDVIqf+HmXyDQpXgWQFP/xdPz6I/KLD24F WTqWRqE68rmo/PmLXxywOTxDoo0Gn6goaot9vNItra3Cv0nFDZzQfQgRF/lEJ5Iauivq3XeMCeO+ qk9YihjaLVxttGhR12G3V5L5VA1OZ+W+aDZSQDneUZF351eLzLwFW28FXcmJm2Hu+3L3Jw18G3fL s9Gs6JwToft83ipP+d5YY368e3vJxl6fmxbPdh6+mVjwBreK5NT9qefy/O87L5TsXMW51HzHgE9w sqlqGzs3PUU4iZVq+OZ0ts/rnui31Dr3M4U3vxc6fyIsf7Sn86VLS9/KYNbyKdu53v2X3vHW3N07 pS5rh3ay+Ogmj7I1qctM+q3bPDW2ut1eMLYy3Gb2AxOFwGOtrgl7xtfe7zxnwhMzN63XjnVbukx8 2caI6VK2o+veoUvvx3xIPFIauNVhQCfAif5TWOdZw4VbrtbNbvfKVOnfgSD/BavgEl0NCmVuZHN0 cmVhbQ0KZW5kb2JqDQoxMzIgMCBvYmoNClsgMjUwXSANCmVuZG9iag0KMTMzIDAgb2JqDQo8PC9U eXBlL1hSZWYvU2l6ZSAxMzMvV1sgMSA0IDJdIC9Sb290IDEgMCBSL0luZm8gMTkgMCBSL0lEWzxE RjE5Qzk0Q0E4RkJCOTQwQkI5MDM3QjMzQ0I0REI4Qj48REYxOUM5NENBOEZCQjk0MEJCOTAzN0Iz M0NCNERCOEI+XSAvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAyOTc+Pg0Kc3RyZWFtDQp4nDXT t1ZCYQzA8e+CXUFRVMSOvfdesFzKtWOhKSLYwFlHH8LJh3BEX0BHZ5/FES/5S4b8Ts5JTpZEKTPy ec3MDqUKPMOXoH0L9ldBtwq+R8HvEQIu+BSC74LxI4S98ARvQiQuRA0hpgupnFIWc61b3cId3MMN /LdkzIH0S7HSwAJWKIFSKINyqIBKqIJqqAEb2KEW6sAB9dAATmiEJmgGF7SAG1qhDdqhAzqhC7rB A1nogV7og34YgEEYgmEYgVEYg3GYgEmYgmmYgVmYg3lYgEVYgmVYgVVYg3XwwgZswhZsgw4+8MMD BCAIBuzALuzBPhzAIRxBCI7hBE7hDMIQgSjEIA7ncAEJuIQkXEEK0nBtXnLGJh+QDQm5X+EjUUBz JpX6AyO8NlUNCmVuZHN0cmVhbQ0KZW5kb2JqDQp4cmVmDQowIDEzNA0KMDAwMDAwMDAyMCA2NTUz NSBmDQowMDAwMDAwMDE3IDAwMDAwIG4NCjAwMDAwMDAxMjUgMDAwMDAgbg0KMDAwMDAwMDE5NSAw MDAwMCBuDQowMDAwMDAwNDU5IDAwMDAwIG4NCjAwMDAwMDM3MzUgMDAwMDAgbg0KMDAwMDAxNzQx MSAwMDAwMCBuDQowMDAwMDE3NzgwIDAwMDAwIG4NCjAwMDAwMTc5NTQgMDAwMDAgbg0KMDAwMDAx ODIwMCAwMDAwMCBuDQowMDAwMDE4MzcwIDAwMDAwIG4NCjAwMDAwMTg2MTIgMDAwMDAgbg0KMDAw MDAxODkwMSAwMDAwMCBuDQowMDAwMDIyMDc5IDAwMDAwIG4NCjAwMDAwMjIxMzMgMDAwMDAgbg0K MDAwMDAyMjE4NyAwMDAwMCBuDQowMDAwMDIyMzYyIDAwMDAwIG4NCjAwMDAwMjI2MDEgMDAwMDAg bg0KMDAwMDAyMjg1MiAwMDAwMCBuDQowMDAwMDI1MDExIDAwMDAwIG4NCjAwMDAwMDAwMjEgNjU1 MzUgZg0KMDAwMDAwMDAyMiA2NTUzNSBmDQowMDAwMDAwMDIzIDY1NTM1IGYNCjAwMDAwMDAwMjQg NjU1MzUgZg0KMDAwMDAwMDAyNSA2NTUzNSBmDQowMDAwMDAwMDI2IDY1NTM1IGYNCjAwMDAwMDAw MjcgNjU1MzUgZg0KMDAwMDAwMDAyOCA2NTUzNSBmDQowMDAwMDAwMDI5IDY1NTM1IGYNCjAwMDAw MDAwMzAgNjU1MzUgZg0KMDAwMDAwMDAzMSA2NTUzNSBmDQowMDAwMDAwMDMyIDY1NTM1IGYNCjAw MDAwMDAwMzMgNjU1MzUgZg0KMDAwMDAwMDAzNCA2NTUzNSBmDQowMDAwMDAwMDM1IDY1NTM1IGYN CjAwMDAwMDAwMzYgNjU1MzUgZg0KMDAwMDAwMDAzNyA2NTUzNSBmDQowMDAwMDAwMDM4IDY1NTM1 IGYNCjAwMDAwMDAwMzkgNjU1MzUgZg0KMDAwMDAwMDA0MCA2NTUzNSBmDQowMDAwMDAwMDQxIDY1 NTM1IGYNCjAwMDAwMDAwNDIgNjU1MzUgZg0KMDAwMDAwMDA0MyA2NTUzNSBmDQowMDAwMDAwMDQ0 IDY1NTM1IGYNCjAwMDAwMDAwNDUgNjU1MzUgZg0KMDAwMDAwMDA0NiA2NTUzNSBmDQowMDAwMDAw MDQ3IDY1NTM1IGYNCjAwMDAwMDAwNDggNjU1MzUgZg0KMDAwMDAwMDA0OSA2NTUzNSBmDQowMDAw MDAwMDUwIDY1NTM1IGYNCjAwMDAwMDAwNTEgNjU1MzUgZg0KMDAwMDAwMDA1MiA2NTUzNSBmDQow MDAwMDAwMDUzIDY1NTM1IGYNCjAwMDAwMDAwNTQgNjU1MzUgZg0KMDAwMDAwMDA1NSA2NTUzNSBm DQowMDAwMDAwMDU2IDY1NTM1IGYNCjAwMDAwMDAwNTcgNjU1MzUgZg0KMDAwMDAwMDA1OCA2NTUz NSBmDQowMDAwMDAwMDU5IDY1NTM1IGYNCjAwMDAwMDAwNjAgNjU1MzUgZg0KMDAwMDAwMDA2MSA2 NTUzNSBmDQowMDAwMDAwMDYyIDY1NTM1IGYNCjAwMDAwMDAwNjMgNjU1MzUgZg0KMDAwMDAwMDA2 NCA2NTUzNSBmDQowMDAwMDAwMDY1IDY1NTM1IGYNCjAwMDAwMDAwNjYgNjU1MzUgZg0KMDAwMDAw MDA2NyA2NTUzNSBmDQowMDAwMDAwMDY4IDY1NTM1IGYNCjAwMDAwMDAwNjkgNjU1MzUgZg0KMDAw MDAwMDA3MCA2NTUzNSBmDQowMDAwMDAwMDcxIDY1NTM1IGYNCjAwMDAwMDAwNzIgNjU1MzUgZg0K MDAwMDAwMDA3MyA2NTUzNSBmDQowMDAwMDAwMDc0IDY1NTM1IGYNCjAwMDAwMDAwNzUgNjU1MzUg Zg0KMDAwMDAwMDA3NiA2NTUzNSBmDQowMDAwMDAwMDc3IDY1NTM1IGYNCjAwMDAwMDAwNzggNjU1 MzUgZg0KMDAwMDAwMDA3OSA2NTUzNSBmDQowMDAwMDAwMDgwIDY1NTM1IGYNCjAwMDAwMDAwODEg NjU1MzUgZg0KMDAwMDAwMDA4MiA2NTUzNSBmDQowMDAwMDAwMDgzIDY1NTM1IGYNCjAwMDAwMDAw ODQgNjU1MzUgZg0KMDAwMDAwMDA4NSA2NTUzNSBmDQowMDAwMDAwMDg2IDY1NTM1IGYNCjAwMDAw MDAwODcgNjU1MzUgZg0KMDAwMDAwMDA4OCA2NTUzNSBmDQowMDAwMDAwMDg5IDY1NTM1IGYNCjAw MDAwMDAwOTAgNjU1MzUgZg0KMDAwMDAwMDA5MSA2NTUzNSBmDQowMDAwMDAwMDkyIDY1NTM1IGYN CjAwMDAwMDAwOTMgNjU1MzUgZg0KMDAwMDAwMDA5NCA2NTUzNSBmDQowMDAwMDAwMDk1IDY1NTM1 IGYNCjAwMDAwMDAwOTYgNjU1MzUgZg0KMDAwMDAwMDA5NyA2NTUzNSBmDQowMDAwMDAwMDk4IDY1 NTM1IGYNCjAwMDAwMDAwOTkgNjU1MzUgZg0KMDAwMDAwMDEwMCA2NTUzNSBmDQowMDAwMDAwMTAx IDY1NTM1IGYNCjAwMDAwMDAxMDIgNjU1MzUgZg0KMDAwMDAwMDEwMyA2NTUzNSBmDQowMDAwMDAw MTA0IDY1NTM1IGYNCjAwMDAwMDAxMDUgNjU1MzUgZg0KMDAwMDAwMDEwNiA2NTUzNSBmDQowMDAw MDAwMTA3IDY1NTM1IGYNCjAwMDAwMDAxMDggNjU1MzUgZg0KMDAwMDAwMDEwOSA2NTUzNSBmDQow MDAwMDAwMTEwIDY1NTM1IGYNCjAwMDAwMDAxMTEgNjU1MzUgZg0KMDAwMDAwMDExMiA2NTUzNSBm DQowMDAwMDAwMTEzIDY1NTM1IGYNCjAwMDAwMDAxMTQgNjU1MzUgZg0KMDAwMDAwMDExNSA2NTUz NSBmDQowMDAwMDAwMTE2IDY1NTM1IGYNCjAwMDAwMDAxMTcgNjU1MzUgZg0KMDAwMDAwMDExOCA2 NTUzNSBmDQowMDAwMDAwMTE5IDY1NTM1IGYNCjAwMDAwMDAxMjAgNjU1MzUgZg0KMDAwMDAwMDEy MSA2NTUzNSBmDQowMDAwMDAwMTIyIDY1NTM1IGYNCjAwMDAwMDAxMjMgNjU1MzUgZg0KMDAwMDAw MDEyNCA2NTUzNSBmDQowMDAwMDAwMTI1IDY1NTM1IGYNCjAwMDAwMDAxMjYgNjU1MzUgZg0KMDAw MDAwMDEyNyA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMjY2MzcgMDAwMDAgbg0K MDAwMDAyNjk2MSAwMDAwMCBuDQowMDAwMDQ2MDcxIDAwMDAwIG4NCjAwMDAwNDY0MjkgMDAwMDAg bg0KMDAwMDA3MDc1MSAwMDAwMCBuDQowMDAwMDcwNzc5IDAwMDAwIG4NCnRyYWlsZXINCjw8L1Np emUgMTM0L1Jvb3QgMSAwIFIvSW5mbyAxOSAwIFIvSURbPERGMTlDOTRDQThGQkI5NDBCQjkwMzdC MzNDQjREQjhCPjxERjE5Qzk0Q0E4RkJCOTQwQkI5MDM3QjMzQ0I0REI4Qj5dID4+DQpzdGFydHhy ZWYNCjcxMjc5DQolJUVPRg0KeHJlZg0KMCAwDQp0cmFpbGVyDQo8PC9TaXplIDEzNC9Sb290IDEg MCBSL0luZm8gMTkgMCBSL0lEWzxERjE5Qzk0Q0E4RkJCOTQwQkI5MDM3QjMzQ0I0REI4Qj48REYx OUM5NENBOEZCQjk0MEJCOTAzN0IzM0NCNERCOEI+XSAvUHJldiA3MTI3OS9YUmVmU3RtIDcwNzc5 Pj4NCnN0YXJ0eHJlZg0KNzQxMTgNCiUlRU9G --94eb2c07e8067ea6e7053e0d0b37 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --94eb2c07e8067ea6e7053e0d0b37-- From nobody Wed Oct 5 13:52:54 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2244F129474; Wed, 5 Oct 2016 13:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 wodiDjGVkwe6; Wed, 5 Oct 2016 13:52:45 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DF7A129470; Wed, 5 Oct 2016 13:52:45 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id n189so156488360qke.0; Wed, 05 Oct 2016 13:52:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=oih2TvV/cLfe86rrD/3HxWuMYQdrFreRvZNnZ/EXJRQ=; b=njVmRb+V0JA6B2MTMsz/mRiq9pHaChN3vkr3OgKAFQg1f0ZJxdwX/uR0vCkdykS7QD wL/WUXLgtsgqiNjfDtdVKr6wR7OkgSQqEvS38+39yqmrYjw1gQce0xyI9dbX2SOvXhIN gqEWYRs57jEM25oFQB+0rYoQrOKSuBKFA1mNtVJwKwNCXMZ7qfU2VVz0cxLkjmEU3p0M M04cUfXQwQVqFcagV4oiw84NFlW2WoykhVDbE36YPymXZZAZI7WfFPmpaNExfw8BFH8i 5a2KQ0ATTHuNlM9t664aK5eYJVvzttfk9N/6mO6zec8ZlRsQsGfWs1MnYu4RO90fYJTK F6pQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=oih2TvV/cLfe86rrD/3HxWuMYQdrFreRvZNnZ/EXJRQ=; b=EbZ80e2XKlkFfxEIuWwNFoBVK2/9B/UNfCb84u/cHm5wcasPgOfUoG5n8TRkXw/pv2 7RHOarQdRGT4V3eQgYttQbaLYJ+OYGcffHeDX0IkgWCZrrg0BYOXz/QzXW5O3nEonLqX aSMEoOK2FosX30enEqrVF1LiW9RPJCp01/9cHNhUps3Sw1e9Vdfk+/KLjrClohxPD2gY vtcwhjmzNTK1sp1TugikAhxD34qGfFy+HAOCLps5iPcBHhbdrFJIU0t3H36h5lVWhdAV 6HvxedJX85tr3aduwRpWMme5tT4EWtHm02RFUEALWS5sdAIbxqXI/W+aDGnzofsvV8Oi XAzQ== X-Gm-Message-State: AA6/9RlP5uVCDh7g2HXYQx9tEZ11uqj4qRwIxmHWk6BbyY9bTlAbgBlbNgYHiDCu8P/iC7GCrZO8E4y3ojzSag== X-Received: by 10.55.66.66 with SMTP id p63mr10619834qka.277.1475700764342; Wed, 05 Oct 2016 13:52:44 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.140.39.52 with HTTP; Wed, 5 Oct 2016 13:52:43 -0700 (PDT) In-Reply-To: <1b5edd03-675c-01b7-6d06-c2e155987929@trigofacile.com> References: <20981db3190142193043f1445abadaa3@trigofacile.com> <1b5edd03-675c-01b7-6d06-c2e155987929@trigofacile.com> From: Barry Leiba Date: Wed, 5 Oct 2016 16:52:43 -0400 X-Google-Sender-Auth: W4YZMeyGAQ834QzG-ITLQOVgCWg Message-ID: To: =?UTF-8?B?SnVsaWVuIMOJTElF?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: draft-murchison-nntp-compress.all@ietf.org, IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-murchison-nntp-compress-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 20:52:47 -0000 I've been thinking on this since you mentioned it, and I have mixed feelings. So let me spread them out here: On the one hand, it's well known that poorly implemented compression has a lot of potential for problems of various kinds, including security. You're basically considering saying that, and saying that it's therefore important to implement the algorithms correctly. Well, yes. On the other hand, there *is* this particular issue that we know can be a sticky point, so... why not mention it? Kind of saying that you have to implement the algorithms correctly, and that you should be particularly careful about buffer sizes when deflating because just a few bytes can deflate into unexpectedly huge results, and that's often used to attempt attacks. And on the third hand (I'm Martian), text is cheap, and if a few words can be helpful, that seems reasonable. On the fourth hand (and that's all that Martians have), it's not this document's job to cover security (or other) issues in the compression algorithms themselves. So, yes: in the end, I think it's worth putting in a few words about this, just to be clear that it's a common trap. Barry On Mon, Oct 3, 2016 at 4:47 PM, Julien =C3=89LIE w= rote: > Hi Barry, > > I'm currently reviewing the comments I need to take into account for the > document. > Do you believe I should add a note about a possible security issue as far= as > the use of DEFLATE is concerned? (see below) > (An "out of memory" attack?) > > Thanks, > > -- > Julien > > > Le 22/09/2016 =C3=A0 22:52, Julien =C3=89LIE a =C3=A9crit : >> >> Hi Barry, >> >> Thanks for your answer. I'll have a deeper look at it soon. >> >> As for the remaining "small points" of rewording (SHOULD, MUST, etc.), >> I'll calmly see them when updating the draft after Last Call. In case I >> have a doubt for the best wording, I'll ask Ken (co-author) and Michael >> (write-up shepherd) their preference. We'll obviously manage to come up >> with the "final" rewording as we'll have 3 votes for 2 choices. >> >> >> Now that I think about it, wouldn't it be worth adding something about >> possible "out of memory" attacks in the Security Considerations Section? >> >> According to , "a 50MB file filled with >> zeros [...] a version of run-length encoding optimized for this sort of >> unusual data file [...] could encode the test file in five bytes. That >> would be a compression factor of 10,000,000:1". >> So sending just 5 bytes may require an expansion to 50MB. >> >> Implementations therefore really need to check that the uncompressed >> data does not exceed an upper bound limit. >> >> RFC 1951 (DEFLATE) does not mention it in its Security Considerations, >> and I don't remember having seen that in other RFCs too. Maybe we >> should say a word for it in the NNTP COMPRESS extension. >> > From nobody Thu Oct 6 02:07:58 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15621298FA for ; Thu, 6 Oct 2016 02:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=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 wopiG1BDS6Bg for ; Thu, 6 Oct 2016 02:07:54 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ECA91298F9 for ; Thu, 6 Oct 2016 02:07:50 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u9697j5F004036 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 6 Oct 2016 12:07:45 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u9697iVG021978; Thu, 6 Oct 2016 12:07:44 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22518.5216.544215.935943@fireball.acr.fi> Date: Thu, 6 Oct 2016 12:07:44 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 09:07:56 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Yaron Sheffer is next in the rotation. For telechat 2016-10-13 Reviewer LC end Draft Matt Lepinski T 2016-09-29 draft-ietf-ipsecme-safecurves-04 Sandy Murphy T 2016-10-10 draft-ietf-regext-epp-rdap-status-mapping-01 Magnus Nystrom T 2016-10-11 draft-ietf-webpush-protocol-10 Takeshi Takahashi TR2016-05-31 draft-ietf-tsvwg-rfc5405bis-17 Tina TSOU T 2016-08-15 draft-ietf-ospf-two-part-metric-09 Dacheng Zhang T 2016-08-22 draft-ietf-core-http-mapping-15 For telechat 2016-10-27 Catherine Meadows T 2016-09-30 draft-ietf-opsawg-capwap-alt-tunnel-08 Eric Osterweil T 2016-10-19 draft-ietf-i2rs-ephemeral-state-19 Radia Perlman T 2016-10-17 draft-ietf-lisp-ddt-08 Vincent Roca T 2016-10-18 draft-ietf-mpls-rfc4379bis-07 Joe Salowey T 2016-10-17 draft-ietf-pce-stateful-pce-app-07 Rich Salz T 2016-10-19 draft-ietf-roll-routing-dispatch-01 Last calls and special requests: Alan DeKok 2016-04-30 draft-bradner-rfc3979bis-08 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Warren Kumari 2016-09-06 draft-sweet-rfc2911bis-11 Matthew Miller 2016-10-06 draft-ietf-stox-7248bis-12 Yoav Nir 2016-10-10 draft-ietf-straw-b2bua-rtcp-13 Hilarie Orman 2016-10-11 draft-ietf-l3sm-l3vpn-service-model-16 Hannes Tschofenig E None draft-ietf-ntp-network-time-security-15 Hannes Tschofenig E None draft-ietf-ntp-cms-for-nts-message-06 Hannes Tschofenig E None draft-ietf-ntp-using-nts-for-ntp-06 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-10 -- kivinen@iki.fi From nobody Thu Oct 6 12:27:16 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DCC5129416; Thu, 6 Oct 2016 12:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.895 X-Spam-Level: X-Spam-Status: No, score=-4.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=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 MbONwb1Eub_1; Thu, 6 Oct 2016 12:27:07 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2201012940F; Thu, 6 Oct 2016 12:27:07 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u96JR4Vu086653 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 6 Oct 2016 14:27:06 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Hilarie Orman , iesg@ietf.org References: <201608090602.u7962mQc025110@rumpleteazer.rhmr.com> From: Adam Roach Message-ID: <99f5a0b1-5617-4d2b-fa54-005929273f16@nostrum.com> Date: Thu, 6 Oct 2016 14:27:04 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <201608090602.u7962mQc025110@rumpleteazer.rhmr.com> Content-Type: multipart/alternative; boundary="------------B070C03447AD44EE989EBEE6" Archived-At: Cc: draft-ietf-avtext-rid.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Security review of draft-ietf-avtext-rid-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 19:27:09 -0000 This is a multi-part message in MIME format. --------------B070C03447AD44EE989EBEE6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Thanks for the review! Responses inline. On 8/9/16 01:02, Hilarie Orman wrote: > "Abstract > This document defines and registers two new RTCP SDES items. One, > named RtpStreamId, is used for unique identification of RTP streams. > The other, RepairedRtpStreamId, can be used to identify which stream > a redundancy RTP stream is to be used to repair. > > Security considerations: > The actual identifiers used for RtpStreamIds (and therefore > RepairedRtpStreamIds) are expected to be opaque." > > "Opaque" seems to mean "no one cares what it is." Nonetheless, a > protocol should give some guidance about this. Taking the value from > a global 64-bit counter, for example, could leak information about the > global state of the machine. Having a short counter for each session > with a starting value of 0 would probably be OK. Having a short > counter start at a random value and wraps around would probably be OK. Thanks! If you look at the -05 version (which came out back in July), you'll see that we added some more explicit text around these identifiers. That version and subsequent ones have indicated: In many cases, a one-byte identifier will be sufficient to distinguish streams in a session; implementations are strongly encouraged to use the shortest identifier that fits their purposes. Implementors are warned, in particular, not to include any information in the identifier that is derived from potentially user- identifying information, such as user ID or IP address. To avoid identification of specific implementations based on their pattern of tag generation, implementations are encouraged to use a simple scheme that starts with the ASCII digit "1", and increments by one for each subsequent identifier. In later versions, the security section was updated to call back to this recommended behavior: Although the identifiers defined in this document are limited to be strictly alphanumeric, SDES items have the potential to carry any string. As a consequence, there exists a risk that it might carry privacy-sensitive information. Implementations need to take care when generating identifiers so that they do not contain information that can identify the user or allow for long term tracking of the device. Following the generation recommendations inSection 3.3 will result in non-instance-specific labels, with only minor fingerprinting possibilities in the total number of used RtpStreamIds and RepairedRtpStreamIds. Does that seem a reasonable treatment to you, or would you like to see additional/different language? > The "terminology" section could be improved by EAFMA and RUP > (expanding a few more acronyms and removing unused phrases). MSID and > SSRC are not expanded; "encoded stream" is never used. Good catch on "encoded stream"! I have added additional text to the Terminology section: The following acronyms are also used: o CNAME: Canonical End-Point Identifier, defined in [RFC3550] o MID: Media Identification, defined in [I-D.ietf-mmusic-sdp-bundle-negotiation] o MSID: Media Stream Identifier, defined in [I-D.ietf-mmusic-msid] o RTCP: Real-time Transport Control Protocol, defined in [RFC3550] o RTP: Real-time Transport Protocol, defined in [RFC3550] o SDES: Source Description, defined in [RFC3550] o SSRC: Synchronization Source, defined in [RFC3550] /a --------------B070C03447AD44EE989EBEE6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Thanks for the review! Responses inline.

On 8/9/16 01:02, Hilarie Orman wrote:
"Abstract
   This document defines and registers two new RTCP SDES items.  One,
   named RtpStreamId, is used for unique identification of RTP streams.
   The other, RepairedRtpStreamId, can be used to identify which stream
   a redundancy RTP stream is to be used to repair.

Security considerations:
   The actual identifiers used for RtpStreamIds (and therefore
   RepairedRtpStreamIds) are expected to be opaque."

"Opaque" seems to mean "no one cares what it is."  Nonetheless, a
protocol should give some guidance about this.  Taking the value from
a global 64-bit counter, for example, could leak information about the
global state of the machine.  Having a short counter for each session
with a starting value of 0 would probably be OK.  Having a short
counter start at a random value and wraps around would probably be OK.

Thanks! If you look at the -05 version (which came out back in July), you'll see that we added some more explicit text around these identifiers. That version and subsequent ones have indicated:

   In many cases, a one-byte identifier will be sufficient to
   distinguish streams in a session; implementations are strongly
   encouraged to use the shortest identifier that fits their purposes.
   Implementors are warned, in particular, not to include any
   information in the identifier that is derived from potentially user-
   identifying information, such as user ID or IP address.  To avoid
   identification of specific implementations based on their pattern of
   tag generation, implementations are encouraged to use a simple scheme
   that starts with the ASCII digit "1", and increments by one for each
   subsequent identifier.
In later versions, the security section was updated to call back to this recommended behavior:

   Although the identifiers defined in this document are limited to be
   strictly alphanumeric, SDES items have the potential to carry any
   string.  As a consequence, there exists a risk that it might carry
   privacy-sensitive information.  Implementations need to take care
   when generating identifiers so that they do not contain information
   that can identify the user or allow for long term tracking of the
   device.  Following the generation recommendations in Section 3.3 will
   result in non-instance-specific labels, with only minor
   fingerprinting possibilities in the total number of used RtpStreamIds
   and RepairedRtpStreamIds.

Does that seem a reasonable treatment to you, or would you like to see additional/different language?

The "terminology" section could be improved by EAFMA and RUP
(expanding a few more acronyms and removing unused phrases).  MSID and
SSRC are not expanded; "encoded stream" is never used.

Good catch on "encoded stream"!

I have added additional text to the Terminology section:


   The following acronyms are also used:

   o  CNAME: Canonical End-Point Identifier, defined in [RFC3550]

   o  MID: Media Identification, defined in
      [I-D.ietf-mmusic-sdp-bundle-negotiation]

   o  MSID: Media Stream Identifier, defined in [I-D.ietf-mmusic-msid]

   o  RTCP: Real-time Transport Control Protocol, defined in [RFC3550]

   o  RTP: Real-time Transport Protocol, defined in [RFC3550]

   o  SDES: Source Description, defined in [RFC3550]

   o  SSRC: Synchronization Source, defined in [RFC3550]


/a
--------------B070C03447AD44EE989EBEE6-- From nobody Fri Oct 7 10:58:06 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AFE81296AA; Fri, 7 Oct 2016 10:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 YBj7YsPkI-2s; Fri, 7 Oct 2016 10:58:01 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A84C129694; Fri, 7 Oct 2016 10:58:01 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id b186so51718698vkb.1; Fri, 07 Oct 2016 10:58:00 -0700 (PDT) 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; bh=1tIycrKKQbeHBeQ+mJUhkMTf+u0R9P4/WxJGuOJjaCo=; b=1ATP1vFuuyuSfeVs4vuJum7kquCu6Hx6sm9ccVT9TDAxJPdGP7HMpWVR9Ivx2jX3xk mZ5Y8imtRm2arcQ58tFm0retgQgSbtbSSVcnxWsCZsB0AKk/BcnTDB86J9RgzKIQ7IAd e5jZbMpuTY+XWY5sVkZUK6cZ2h5yDMd1ZJl6SGpZMx9Vhn5bjLCr+Uu36ZMNF8lraqXE CR9nqCASQEnBaPtsMuBd90wquv2wc5+zg4D7zzBRP8ilFbB0dlYSsVLRcDHQWJNQntKn mtfAvIIXH83WfRi9pDwNZNi/hQZM8V6I2CQMoRwea/kwcVdADqr1d7Qkf+3ylLNw4AM6 ejgQ== 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; bh=1tIycrKKQbeHBeQ+mJUhkMTf+u0R9P4/WxJGuOJjaCo=; b=S0tHgVQseGBNM7efE6K1T9mknWiJ/FAB9J/bMaA+GFde1VNLIs4135WoEffWwL6bdl 9mS8ADjnAwW7z3cNrrThr5LUA5V2JE9jrTizeIv/MPvBVL2cnb2J6AOCqMiMUUOdvhGZ Knupd9eNjxMr5Z4abwlvE9FLgD3n182uMBpzSzMAK3CORe9Yw5pb3ICywQpxGlWh4GLm nK7x9v33mnL6x/JW3qwoJ/C2jIlsOaCoKqw6QkpH51oi/vbwWjUp2knGxdthBOXxcrND Ov5PsRFe/SaiueIU+vzoR2qaxz7RoqEK5hcfihRIxbYSNIrn8m7FbRHLj7uolarM9wPc QfYA== X-Gm-Message-State: AA6/9RmS87Zl626LbzMjseI4aPBaLXASB7lUIQ9aARMfPGDEryU/XEMOUnYD4iZmgl17UdRc38xqqNiNWvr2sA== X-Received: by 10.31.228.3 with SMTP id b3mr13983322vkh.49.1475863080073; Fri, 07 Oct 2016 10:58:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.68 with HTTP; Fri, 7 Oct 2016 10:57:59 -0700 (PDT) In-Reply-To: <69d90890-3c84-46e2-d1ef-0e264e28d568@lounge.org> References: <87fuosqtkh.fsf@latte.josefsson.org> <66a779c8-d87b-7c70-c7cf-7eabc48f9880@lounge.org> <20160924111622.6d1308ce@latte.josefsson.org> <69d90890-3c84-46e2-d1ef-0e264e28d568@lounge.org> From: Kathleen Moriarty Date: Fri, 7 Oct 2016 13:57:59 -0400 Message-ID: To: Dan Harkins , "secdir@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0960549ffd35053e4a265c Archived-At: Cc: draft-harkins-salted-eap-pwd.all@ietf.org Subject: Re: [secdir] secdir review of draft-harkins-salted-eap-pwd-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 17:58:04 -0000 --94eb2c0960549ffd35053e4a265c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Simon, Have you had a chance to look at this yet? I'd like to make sure a new version is posted by Dan before I put this for IESG review. I'm looking at Dan's suggestions now as well. The draft is supposed to be on next week's telechat, but I'll delay if needed. Thank you, Kathleen On Thu, Sep 29, 2016 at 4:10 PM, Dan Harkins wrote: > > Hi Simon, > > Please take a look at the attached and let me know whether it addresses > your concerns. I decided against adding support for HTTP Digest-style MD5 > because it requires a client contribution and EAP-pwd doesn't have a way > to provide that. > > regards, > > Dan. > > > > On 9/24/16 2:16 AM, Simon Josefsson wrote: > >> Den Fri, 23 Sep 2016 10:37:25 -0700 >> skrev Re: [secdir] secdir review of draft-harkins-salted-eap-pwd-06: >> >> Hi Simon, >>> >>> On 9/22/16 12:31 AM, Simon Josefsson wrote: >>> >>>> Hello, >>>> >>>> I have reviewed this document as part of the security directorate's >>>> ongoing effort to review all IETF documents being processed by the >>>> IESG. These comments were written primarily for the benefit of the >>>> security area directors. Document editors and WG chairs should >>>> treat these comments just like any other last call comments. >>>> >>> Thank you for your review and comments. >>> >> Hi Dan. Thanks for quick response. >> >> This document adds support for salted password databases to EAP-pwd >>>> (RFC5931). I believe the document is Not Ready for the following >>>> reasons: >>>> >>>> 1) The introduction and security considerations fails to >>>> acknowledge that password salting is not sufficient to protect >>>> against real-world password recovery attacks. Iterative constructs >>>> are needed. This knowledge is old, PBKDF2/RFC2898 (which is one >>>> standard technique to address the problem) was published in 2000 >>>> and has been widely deployed since then. The document should >>>> mention this aspect. There have been many successful attacks >>>> against pure-salted password databases in the real world, for >>>> example: https://en.wikipedia.org/wiki/2012_LinkedIn_hack >>>> >>> The intent is to support existing databases that RFC 5931 could >>> not. I guess it deserves to be mentioned in case someone wants to >>> create a new salted password database. I will add something regarding >>> real-world attacks to recover passwords given a salted/encrypted >>> database. >>> >> Thank you. >> >> I believe the experience and understanding in this field is that it is >> not responsible to publish a document suggesting to use only salted >> password databases today, or even 10 years ago. Anything in that >> direction should come with serious warnings that you are doing >> something that the community believe is a bad idea, combined with >> guidelines on how to do it properly (PBKDF2/scrypt). It seems we are >> on the same page here, and the detail is how to get the document to say >> that. >> >> 2) Code points for the pre-processing techniques PBKDF2 (RFC >>>> 2898) and scrypt (RFC 7914) should be added, to support use of best >>>> security practices. >>>> >>> Great suggestion, I will add these. >>> >> Thank you. Some way to encode the PBKDF2/scrypt parameters in the salt >> field is required, which require some additional specification work. I >> am happy to review text here. >> >> 3) There are interop concerns with crypt() when discussion about >>>> which crypt algorithms (DES, MD5, etc) are to be used is lacking. >>>> The page mentions a >>>> couple of algorithms, but several others exist out there. Consider >>>> if the server tells the client to use an exotic crypt() schema like >>>> BSDi or NTHASH, and the client does not support this algorithm. >>>> The document should discuss the sub-negotiation problem. The >>>> document should mention what happens when the server choses an >>>> algorithm the client doesn't support. The document should >>>> recommend that servers use widely-implemented schemas, like DES, >>>> md5, or sha256. >>>> >>> Yes, there needs to be something to deal with failure of a client >>> to support a server's crypt algorithm. Since this is not a dynamic >>> sort of thing-- oh, you don't like BSDi, how about sha256?-- so I >>> think the only option is failure, but it should be mentioned. >>> >> Agreed. Failure appears like the only option, but it should be made >> clear. It should also be made clear that servers ought to pick common >> algorithms to avoid this problem, even though the strategy isn't 100%. >> >> 4) Introducing a new pre-processing technique like >>>> OpaqueString+SHA1 or OpaqueString+crypt() add complexity. As far >>>> as I understand, there are no password databases with >>>> OpaqueString-processed passwords which are hashed with SHA-1 or >>>> crypt out there today. Thus there is no interop argument for >>>> introducing the methods. Please confirm that the intention is to >>>> introduce these methods as new ideas. Then let me suggest that you >>>> only describe OpaqueString+SHA256 and skip OpaqueString+SHA1, >>>> OpaqueString+SHA512, OpaqueString+crypt. This reduces complexity >>>> and does not cause a reduction of security. >>>> >>> Actually no, these aren't for new databases. There has to be some >>> canonical way to deal with "international" character sets. RFC 5931 >>> used to refer to SASLprep but that's been obsoleted. So I MUST now >>> refer to OpaqueString. >>> >>> I went to the OpaqueString tutorial a couple of IETFs ago and asked >>> whether passwords treated with SASLprep would map 1:1 to passwords >>> treated with OpaqueString and the answer I got was something like, >>> "uhm, well, I'm not sure. I think so." So the expectation is that a >>> passphrase of "Eu amo S=C3=A3o Paulo" (with the problematic diacritical= ) >>> in an existing database created by SASLprep could be used with salted >>> EAP-pwd and the corresponding OpaqueString pre-processing technique. >>> And that means that every non-internationalized salting technique >>> needs an OpaqueString version, including SHA1 and crypt. >>> >> I do not understand. >> >> Are you saying that you know of implemented/deployed password databases >> that uses PRECIS OpaqueString processed passwords that are salted and >> then hashed, the way described by your document? This would surprise >> me greatly, but of course it is not impossible. In my experience, >> people who are aware of PRECIS/OpaqueString for password processing >> are aware of iterated password processing algorithms like PBKDF2. >> I would say more people are aware of PBKDF2 than PRECIS/OpaqueString. >> >> Or are you saying that your intent is to support existing deployed >> SASLprep prepared databases? Do you know of any that use each of SHA1, >> SHA256, SHA512 or crypt()? Or was the addition of all algorithms for >> completness? >> >> SASLprep and OpaqueString are not the same algorithm, and they don't >> map 1:1, otherwise there wouldn't be any need to have two algorithms. >> >> If the intent is to support existing salted+hashed password databases >> with SASLprep, refering to OpaqueString won't work. >> >> This may be a similar situation as with iterated vs non-iterated >> algorithms. You could include SASLprep for legacy reasons, but >> recommend use of OpaqueString going forward. Same as including >> SHA1(salt|password) for legacy but recommend use of PBKDF2/scrypt going >> forward. >> >> Further, password databases with HTTP Digest MD5 passwords are >>>> widely used. For added legacy compatibility, consider support it >>>> too. This is not a show stopper, but failure to mentioning it in >>>> the context of deployed password databases appears to me like an >>>> elephant in the room. Where there conscious reasons for not >>>> including it? It may be worth stating those reasons in the >>>> document, if that is the case. >>>> >>> Good suggestion. I'll add MD5 too. >>> >> Refer to RFC 7616 for details, it is not as easy as MD5(salt|password), >> and the document covers SHA-256 and SHA-512/256 too. If you add this, >> you will need to discuss what the username and realm should be. I don't >> think you must add this if you have no direct use for it, but >> acknowledging this widely deployed salted password database appears >> relevant. It is more important to add PBKDF2/scrypt in my opinion. >> >> Thanks, >> /Simon >> > > --=20 Best regards, Kathleen --94eb2c0960549ffd35053e4a265c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Simon,

Have you had a chance to look at= this yet?=C2=A0 I'd like to make sure a new version is posted by Dan b= efore I put this for IESG review.=C2=A0 I'm looking at Dan's sugges= tions now as well.=C2=A0 The draft is supposed to be on next week's tel= echat, but I'll delay if needed.

Thank you,
Kathleen

On Thu, Sep 29, 2016 at 4:10 PM, Dan Harkins &= lt;dharkins@lounge= .org> wrote:

=C2=A0 Hi Simon,

=C2=A0 Please take a look at the attached and let me know whether it addres= ses
your concerns. I decided against adding support for HTTP Digest-style MD5 because it requires a client contribution and EAP-pwd doesn't have a wa= y
to provide that.

=C2=A0 regards,

=C2=A0 Dan.



On 9/24/16 2:16 AM, Simon Josefsson wrote:
Den Fri, 23 Sep 2016 10:37:25 -0700
skrev Re: [secdir] secdir review of draft-harkins-salted-eap-pwd-06:
=C2=A0 =C2=A0 Hi Simon,

On 9/22/16 12:31 AM, Simon Josefsson wrote:
Hello,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors.=C2=A0 Document editors and WG chairs should
treat these comments just like any other last call comments.
=C2=A0 =C2=A0 Thank you for your review and comments.
Hi Dan.=C2=A0 Thanks for quick response.

This document adds support for salted password databases to EAP-pwd
(RFC5931).=C2=A0 I believe the document is Not Ready for the following
reasons:

=C2=A0 =C2=A0 1) The introduction and security considerations fails to
acknowledge that password salting is not sufficient to protect
against real-world password recovery attacks.=C2=A0 Iterative constructs are needed.=C2=A0 This knowledge is old, PBKDF2/RFC2898 (which is one
standard technique to address the problem) was published in 2000
and has been widely deployed since then.=C2=A0 The document should
mention this aspect.=C2=A0 There have been many successful attacks
against pure-salted password databases in the real world, for
example: https://en.wikipedia.org/wiki/2012_L= inkedIn_hack
=C2=A0 =C2=A0 The intent is to support existing databases that RFC 5931 cou= ld
not. I guess it deserves to be mentioned in case someone wants to
create a new salted password database. I will add something regarding
real-world attacks to recover passwords given a salted/encrypted
database.
Thank you.

I believe the experience and understanding in this field is that it is
not responsible to publish a document suggesting to use only salted
password databases today, or even 10 years ago.=C2=A0 Anything in that
direction should come with serious warnings that you are doing
something that the community believe is a bad idea, combined with
guidelines on how to do it properly (PBKDF2/scrypt).=C2=A0 It seems we are<= br> on the same page here, and the detail is how to get the document to say
that.

=C2=A0 =C2=A0 2) Code points for the pre-processing techniques PBKDF2 (RFC<= br> 2898) and scrypt (RFC 7914) should be added, to support use of best
security practices.
=C2=A0 =C2=A0 Great suggestion, I will add these.
Thank you.=C2=A0 Some way to encode the PBKDF2/scrypt parameters in the sal= t
field is required, which require some additional specification work.=C2=A0 = I
am happy to review text here.

=C2=A0 =C2=A0 3) There are interop concerns with crypt() when discussion ab= out
which crypt algorithms (DES, MD5, etc) are to be used is lacking.
The page <https://en.wikipedia.org/wiki/Crypt_%28= C%29> mentions a
couple of algorithms, but several others exist out there.=C2=A0 Consider if the server tells the client to use an exotic crypt() schema like
BSDi or NTHASH, and the client does not support this algorithm.
The document should discuss the sub-negotiation problem.=C2=A0 The
document should mention what happens when the server choses an
algorithm the client doesn't support.=C2=A0 The document should
recommend that servers use widely-implemented schemas, like DES,
md5, or sha256.
=C2=A0 =C2=A0 Yes, there needs to be something to deal with failure of a cl= ient
to support a server's crypt algorithm. Since this is not a dynamic
sort of thing-- oh, you don't like BSDi, how about sha256?-- so I
think the only option is failure, but it should be mentioned.
Agreed.=C2=A0 Failure appears like the only option, but it should be made clear.=C2=A0 It should also be made clear that servers ought to pick common=
algorithms to avoid this problem, even though the strategy isn't 100%.<= br>
=C2=A0 =C2=A0 4) Introducing a new pre-processing technique like
OpaqueString+SHA1 or OpaqueString+crypt() add complexity.=C2=A0 As far
as I understand, there are no password databases with
OpaqueString-processed passwords which are hashed with SHA-1 or
crypt out there today.=C2=A0 Thus there is no interop argument for
introducing the methods.=C2=A0 Please confirm that the intention is to
introduce these methods as new ideas.=C2=A0 Then let me suggest that you only describe OpaqueString+SHA256 and skip OpaqueString+SHA1,
OpaqueString+SHA512, OpaqueString+crypt.=C2=A0 This reduces complexity
and does not cause a reduction of security.
=C2=A0 =C2=A0 Actually no, these aren't for new databases. There has to= be some
canonical way to deal with "international" character sets. RFC 59= 31
used to refer to SASLprep but that's been obsoleted. So I MUST now
refer to OpaqueString.

=C2=A0 =C2=A0 I went to the OpaqueString tutorial a couple of IETFs ago and= asked
whether passwords treated with SASLprep would map 1:1 to passwords
treated with OpaqueString and the answer I got was something like,
"uhm, well, I'm not sure. I think so." So the expectation is = that a
passphrase of "Eu amo S=C3=A3o Paulo" (with the problematic diacr= itical)
in an existing database created by SASLprep could be used with salted
EAP-pwd and the corresponding OpaqueString pre-processing technique.
And that means that every non-internationalized salting technique
needs an OpaqueString version, including SHA1 and crypt.
I do not understand.

Are you saying that you know of implemented/deployed password databases
that uses PRECIS OpaqueString processed passwords that are salted and
then hashed, the way described by your document?=C2=A0 This would surprise<= br> me greatly, but of course it is not impossible.=C2=A0 In my experience,
people who are aware of PRECIS/OpaqueString for password processing
are aware of iterated password processing algorithms like PBKDF2.
I would say more people are aware of PBKDF2 than PRECIS/OpaqueString.

Or are you saying that your intent is to support existing deployed
SASLprep prepared databases?=C2=A0 Do you know of any that use each of SHA1= ,
SHA256, SHA512 or crypt()?=C2=A0 Or was the addition of all algorithms for<= br> completness?

SASLprep and OpaqueString are not the same algorithm, and they don't map 1:1, otherwise there wouldn't be any need to have two algorithms.
If the intent is to support existing salted+hashed password databases
with SASLprep, refering to OpaqueString won't work.

This may be a similar situation as with iterated vs non-iterated
algorithms.=C2=A0 You could include SASLprep for legacy reasons, but
recommend use of OpaqueString going forward.=C2=A0 Same as including
SHA1(salt|password) for legacy but recommend use of PBKDF2/scrypt going
forward.

Further, password databases with HTTP Digest MD5 passwords are
widely used.=C2=A0 For added legacy compatibility, consider support it
too.=C2=A0 This is not a show stopper, but failure to mentioning it in
the context of deployed password databases appears to me like an
elephant in the room. Where there conscious reasons for not
including it?=C2=A0 It may be worth stating those reasons in the
document, if that is the case.
=C2=A0 =C2=A0 Good suggestion. I'll add MD5 too.
Refer to RFC 7616 for details, it is not as easy as MD5(salt|password),
and the document covers SHA-256 and SHA-512/256 too.=C2=A0 If you add this,=
you will need to discuss what the username and realm should be.=C2=A0 I don= 't
think you must add this if you have no direct use for it, but
acknowledging this widely deployed salted password database appears
relevant.=C2=A0 It is more important to add PBKDF2/scrypt in my opinion.
Thanks,
/Simon




--
=

Best regards,
Kathleen
--94eb2c0960549ffd35053e4a265c-- From nobody Sat Oct 8 23:57:36 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F881294A7; Sat, 8 Oct 2016 23:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ImDcZGPMmlz6; Sat, 8 Oct 2016 23:57:31 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24FCA12948C; Sat, 8 Oct 2016 23:57:31 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id f193so4563366wmg.1; Sat, 08 Oct 2016 23:57:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=KQn4qe/GM3jmIxOkFPgLlKpicb+bwIwcEZGeRDAFRQM=; b=XWsI4I7Hu85akyiToWXaMotgFPO2nt7Terdgr8Q3DyL1eqcQbQSmJ366Q5z+5P1hri UHmtOEYnd9p6CbUks7CsflBeXG467ReBLR3+rUiexNQYBbHJsZwBdwHn3zNw3sZbUvwX 7waPcvhRx/qmJoZ8ULowiii4pWf9tWZcmj+oISIiv8Px/1XzgmRaRC7+mzJ8e3QwuGXx RynHbORoxZ6AohLo38Eu/6MI0L8Csk/YaK/CHt/vf9ZA28kBNSlvDkdQn+IP7LiRyOFr 8Jrgl1uSHXn8cbpKgK+EXzu0dQ5ncYF3cbf59p8jtF6RgG5VPT2wM8/LcaFGMqKTSzje c/QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=KQn4qe/GM3jmIxOkFPgLlKpicb+bwIwcEZGeRDAFRQM=; b=aCzEfQvJ8HA+hdXf5kWr1e7nmoccgEZAbDqEk1hX+fPDxgWSDVFTyL1QMU5ehM6b1q 51b52k+gtrfTPnpSr7KHPyfI1SfjbvkAkNHrOqq+HDB82KEYMsa4soEBTtyLryXgQfaN 1JG13b7S8ocHL+VWrS94sLKlsYv8DHjb7CP2JFgYlZPG+VNoBUIHeEVLxSkw1+cO4cas +J+aaeWFByT6weycUkW8WEVjOp+8G42rykNjw6NhWrRxH/4B7oh2EP/ULECCVvNAKty+ oHGWUW9sLJxS0G1wEtvCNvJw2EdRXrz9+XDFL1eooO9UdkvM0w/9eslcpbNOFViPXDRH ZbRA== X-Gm-Message-State: AA6/9RnX2/n5tTcy+7Eblai0gE5l9znSgzFZXJ1AVLGhPLRoHsQnrp6JxJ1TX+U2jj+bzQ== X-Received: by 10.28.74.199 with SMTP id n68mr5546406wmi.25.1475996249734; Sat, 08 Oct 2016 23:57:29 -0700 (PDT) Received: from [172.24.251.123] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id e2sm13973922wjw.14.2016.10.08.23.57.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Oct 2016 23:57:28 -0700 (PDT) From: Yoav Nir Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Message-Id: Date: Sun, 9 Oct 2016 09:57:26 +0300 To: draft-ietf-straw-b2bua-rtcp.all@tools.ietf.org, secdir , The IESG X-Mailer: Apple Mail (2.3226) Archived-At: Subject: [secdir] SecDir review of draft-ietf-straw-b2bua-rtcp-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2016 06:57:34 -0000 Hello, I have reviewed this document as part of the security directorate=E2=80=99= s ongoing effort to review all IETF documents being processed by the = IESG. These comments were written primarily for the benefit of the = security area directors. Document editors and WG chairs should treat = these comments just like any other last call comments. Summary: Ready with nits The document defines the proper behavior for B2BUAs that, in addition to = being on-path for SIP, are also on-path for the media traffic, whether = RTP or RTCP. Section 3 describes different scenarios for B2BUAs = operating on the media, and if features considerations of the type =E2=80=9C= if you change this, you also have to change that, otherwise this bad = thing could happen.=E2=80=9D The document is easy to read and = understandable even to someone who is not well versed in SIP = terminology. The security considerations section claims that the considerations are = similar to those of the standards documents such as RFC 7667 (RTP = topologies) and RFC 7656 (A Taxonomy of Semantics and Mechanisms for = Real-Time Transport Protocol (RTP) Sources). This seems reasonable. It = also describes why encryption is not an issue (if the B2BUA can make = some changes to the media stream, then it can also make the changes = described in this document, otherwise, it can=E2=80=99t make the = original changes either), and how failing to follow this document might = be indistinguishable from an attack (that=E2=80=99s the =E2=80=9Cbad = things happen=E2=80=9D part) Two nits: - The Abstract says: =E2=80=9C[B2BUAs] are often envisaged to also be = on the media path...This means that B2BUAs often implement an RTP/RTCP = stack...=E2=80=9D. That doesn=E2=80=99t make sense with the dictionary = definition of =E2=80=9Cenvisage=E2=80=9D. Perhaps =E2=80=9Cdesigned=E2=80=9D= ? - The first paragraph of the Security Considerations is pasted below. I = don=E2=80=99t think there is much semantic difference between = "considerations" and =E2=80=9Caspects=E2=80=9D. This paragraph denies = that there are considerations, and then goes on to state some. I think = the whole first paragraph can go. Yoav From nobody Sun Oct 9 23:14:21 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C72129494; Sun, 9 Oct 2016 23:14:19 -0700 (PDT) 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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 romNyXZLic_t; Sun, 9 Oct 2016 23:14:16 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FC1B12949C; Sun, 9 Oct 2016 23:14:15 -0700 (PDT) Received: from latte.josefsson.org ([IPv6:2001:9b0:104:42::a86]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id u9A6E1uj015629 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 10 Oct 2016 08:14:03 +0200 Date: Mon, 10 Oct 2016 08:13:55 +0200 From: Simon Josefsson To: Kathleen Moriarty Message-ID: <20161010081355.2a597c69@latte.josefsson.org> In-Reply-To: References: <87fuosqtkh.fsf@latte.josefsson.org> <66a779c8-d87b-7c70-c7cf-7eabc48f9880@lounge.org> <20160924111622.6d1308ce@latte.josefsson.org> <69d90890-3c84-46e2-d1ef-0e264e28d568@lounge.org> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/0ZQ/w=J0qpBAE21VX/0SV2i"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.99.2 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: draft-harkins-salted-eap-pwd.all@ietf.org, "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-harkins-salted-eap-pwd-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 06:14:19 -0000 --Sig_/0ZQ/w=J0qpBAE21VX/0SV2i Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello. I had a look at the update, and it needs more work. First the basics. Scrypt and PBKDF2 are two different algorithms. Scrypt is described in RFC 7914 and PBKDF2 in RFC 2898. The updated draft refers to these as the same algorithm "Scrypt/PBKDF2". They are not the same thing. I still believe it is a bad idea to describe non-iterative password protection schemes at all. We have had 15+ years of bad incidents with salted password databases that suggest it is time to stop doing that. If this is included, care should be made to bring this point up early in the introduction section. Right now it leaps from salted password databases to memory-hard functions. The right balance should be to focus on iterative constructs like PBKDF2 which is the traditional state-of-the-art standard, and mention memory-hard functions as a recommended improvement. There seems to be an impedance mismatch in describing PRECIS/OpaqueString prepared password in the context of legacy databases. My perception is that we have little deployment of PRECIS/OpaqueString prepared password databases out there, questioning the need for "legacy" compatibility for these databases, especially combined with SHA1. /Simon > Simon, >=20 > Have you had a chance to look at this yet? I'd like to make sure a > new version is posted by Dan before I put this for IESG review. I'm > looking at Dan's suggestions now as well. The draft is supposed to > be on next week's telechat, but I'll delay if needed. >=20 > Thank you, > Kathleen >=20 > On Thu, Sep 29, 2016 at 4:10 PM, Dan Harkins > wrote: >=20 > > > > Hi Simon, > > > > Please take a look at the attached and let me know whether it > > addresses your concerns. I decided against adding support for HTTP > > Digest-style MD5 because it requires a client contribution and > > EAP-pwd doesn't have a way to provide that. > > > > regards, > > > > Dan. > > > > > > > > On 9/24/16 2:16 AM, Simon Josefsson wrote: > > > >> Den Fri, 23 Sep 2016 10:37:25 -0700 > >> skrev Re: [secdir] secdir review of > >> draft-harkins-salted-eap-pwd-06: > >> > >> Hi Simon, > >>> > >>> On 9/22/16 12:31 AM, Simon Josefsson wrote: > >>> > >>>> Hello, > >>>> > >>>> I have reviewed this document as part of the security > >>>> directorate's ongoing effort to review all IETF documents being > >>>> processed by the IESG. These comments were written primarily for > >>>> the benefit of the security area directors. Document editors > >>>> and WG chairs should treat these comments just like any other > >>>> last call comments. > >>>> > >>> Thank you for your review and comments. > >>> > >> Hi Dan. Thanks for quick response. > >> > >> This document adds support for salted password databases to EAP-pwd > >>>> (RFC5931). I believe the document is Not Ready for the following > >>>> reasons: > >>>> > >>>> 1) The introduction and security considerations fails to > >>>> acknowledge that password salting is not sufficient to protect > >>>> against real-world password recovery attacks. Iterative > >>>> constructs are needed. This knowledge is old, PBKDF2/RFC2898 > >>>> (which is one standard technique to address the problem) was > >>>> published in 2000 and has been widely deployed since then. The > >>>> document should mention this aspect. There have been many > >>>> successful attacks against pure-salted password databases in the > >>>> real world, for example: > >>>> https://en.wikipedia.org/wiki/2012_LinkedIn_hack > >>>> > >>> The intent is to support existing databases that RFC 5931 > >>> could not. I guess it deserves to be mentioned in case someone > >>> wants to create a new salted password database. I will add > >>> something regarding real-world attacks to recover passwords given > >>> a salted/encrypted database. > >>> > >> Thank you. > >> > >> I believe the experience and understanding in this field is that > >> it is not responsible to publish a document suggesting to use only > >> salted password databases today, or even 10 years ago. Anything > >> in that direction should come with serious warnings that you are > >> doing something that the community believe is a bad idea, combined > >> with guidelines on how to do it properly (PBKDF2/scrypt). It > >> seems we are on the same page here, and the detail is how to get > >> the document to say that. > >> > >> 2) Code points for the pre-processing techniques PBKDF2 (RFC > >>>> 2898) and scrypt (RFC 7914) should be added, to support use of > >>>> best security practices. > >>>> > >>> Great suggestion, I will add these. > >>> > >> Thank you. Some way to encode the PBKDF2/scrypt parameters in the > >> salt field is required, which require some additional > >> specification work. I am happy to review text here. > >> > >> 3) There are interop concerns with crypt() when discussion > >> about > >>>> which crypt algorithms (DES, MD5, etc) are to be used is lacking. > >>>> The page mentions a > >>>> couple of algorithms, but several others exist out there. > >>>> Consider if the server tells the client to use an exotic crypt() > >>>> schema like BSDi or NTHASH, and the client does not support this > >>>> algorithm. The document should discuss the sub-negotiation > >>>> problem. The document should mention what happens when the > >>>> server choses an algorithm the client doesn't support. The > >>>> document should recommend that servers use widely-implemented > >>>> schemas, like DES, md5, or sha256. > >>>> > >>> Yes, there needs to be something to deal with failure of a > >>> client to support a server's crypt algorithm. Since this is not a > >>> dynamic sort of thing-- oh, you don't like BSDi, how about > >>> sha256?-- so I think the only option is failure, but it should be > >>> mentioned. > >>> > >> Agreed. Failure appears like the only option, but it should be > >> made clear. It should also be made clear that servers ought to > >> pick common algorithms to avoid this problem, even though the > >> strategy isn't 100%. > >> > >> 4) Introducing a new pre-processing technique like > >>>> OpaqueString+SHA1 or OpaqueString+crypt() add complexity. As far > >>>> as I understand, there are no password databases with > >>>> OpaqueString-processed passwords which are hashed with SHA-1 or > >>>> crypt out there today. Thus there is no interop argument for > >>>> introducing the methods. Please confirm that the intention is to > >>>> introduce these methods as new ideas. Then let me suggest that > >>>> you only describe OpaqueString+SHA256 and skip OpaqueString+SHA1, > >>>> OpaqueString+SHA512, OpaqueString+crypt. This reduces complexity > >>>> and does not cause a reduction of security. > >>>> > >>> Actually no, these aren't for new databases. There has to be > >>> some canonical way to deal with "international" character sets. > >>> RFC 5931 used to refer to SASLprep but that's been obsoleted. So > >>> I MUST now refer to OpaqueString. > >>> > >>> I went to the OpaqueString tutorial a couple of IETFs ago and > >>> asked whether passwords treated with SASLprep would map 1:1 to > >>> passwords treated with OpaqueString and the answer I got was > >>> something like, "uhm, well, I'm not sure. I think so." So the > >>> expectation is that a passphrase of "Eu amo S=C3=A3o Paulo" (with the > >>> problematic diacritical) in an existing database created by > >>> SASLprep could be used with salted EAP-pwd and the corresponding > >>> OpaqueString pre-processing technique. And that means that every > >>> non-internationalized salting technique needs an OpaqueString > >>> version, including SHA1 and crypt. > >>> > >> I do not understand. > >> > >> Are you saying that you know of implemented/deployed password > >> databases that uses PRECIS OpaqueString processed passwords that > >> are salted and then hashed, the way described by your document? > >> This would surprise me greatly, but of course it is not > >> impossible. In my experience, people who are aware of > >> PRECIS/OpaqueString for password processing are aware of iterated > >> password processing algorithms like PBKDF2. I would say more > >> people are aware of PBKDF2 than PRECIS/OpaqueString. > >> > >> Or are you saying that your intent is to support existing deployed > >> SASLprep prepared databases? Do you know of any that use each of > >> SHA1, SHA256, SHA512 or crypt()? Or was the addition of all > >> algorithms for completness? > >> > >> SASLprep and OpaqueString are not the same algorithm, and they > >> don't map 1:1, otherwise there wouldn't be any need to have two > >> algorithms. > >> > >> If the intent is to support existing salted+hashed password > >> databases with SASLprep, refering to OpaqueString won't work. > >> > >> This may be a similar situation as with iterated vs non-iterated > >> algorithms. You could include SASLprep for legacy reasons, but > >> recommend use of OpaqueString going forward. Same as including > >> SHA1(salt|password) for legacy but recommend use of PBKDF2/scrypt > >> going forward. > >> > >> Further, password databases with HTTP Digest MD5 passwords are > >>>> widely used. For added legacy compatibility, consider support it > >>>> too. This is not a show stopper, but failure to mentioning it in > >>>> the context of deployed password databases appears to me like an > >>>> elephant in the room. Where there conscious reasons for not > >>>> including it? It may be worth stating those reasons in the > >>>> document, if that is the case. > >>>> > >>> Good suggestion. I'll add MD5 too. > >>> > >> Refer to RFC 7616 for details, it is not as easy as > >> MD5(salt|password), and the document covers SHA-256 and > >> SHA-512/256 too. If you add this, you will need to discuss what > >> the username and realm should be. I don't think you must add this > >> if you have no direct use for it, but acknowledging this widely > >> deployed salted password database appears relevant. It is more > >> important to add PBKDF2/scrypt in my opinion. > >> > >> Thanks, > >> /Simon > >> > > > > >=20 >=20 --Sig_/0ZQ/w=J0qpBAE21VX/0SV2i Content-Type: application/pgp-signature Content-Description: OpenPGP digital signatur -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJX+zGjAAoJEIYLf7sy+BGdw6YH/iYJDKnig9cYME7u/0K4ehMC BuLbhyjhunwi4d1f4qaRcstFZnA4inirODPGOflcM+pXW/GDWna68aTd2awlgbSQ YbxrtkzTwVqVH/vNuHUJqk6IewW9emF9Wink/Dy5GR6MnEXbzhVZM+BRdy6OXKyF wkJtXxsqCaXbmW05bNhTwvJAKfGn9IbcGdUhOkU2XKA+b08O7B6fJUX+4UF6jxIr 5+7XJXYLbsRXqOc0UtnMlzK4NovGXP8ug87kxOerfQR1IEUUo28OylOuUQPq96Fh 41U2I4mo7pj/Z2Sz4gLkd8aotk+iWK6BpAwtdycpZXFQDMVUb2IXkOk0NOhPBes= =h3vb -----END PGP SIGNATURE----- --Sig_/0ZQ/w=J0qpBAE21VX/0SV2i-- From nobody Mon Oct 10 00:03:28 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 035C3129413; Mon, 10 Oct 2016 00:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.895 X-Spam-Level: X-Spam-Status: No, score=-4.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, WEIRD_PORT=0.001] autolearn=ham autolearn_force=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 5SiE-sT2REXD; Mon, 10 Oct 2016 00:03:24 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6769A128E18; Mon, 10 Oct 2016 00:03:24 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id B678243A7A; Mon, 10 Oct 2016 09:03:22 +0200 (CEST) To: Simon Josefsson , Kathleen Moriarty References: <87fuosqtkh.fsf@latte.josefsson.org> <66a779c8-d87b-7c70-c7cf-7eabc48f9880@lounge.org> <20160924111622.6d1308ce@latte.josefsson.org> <69d90890-3c84-46e2-d1ef-0e264e28d568@lounge.org> <20161010081355.2a597c69@latte.josefsson.org> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: Date: Mon, 10 Oct 2016 09:03:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20161010081355.2a597c69@latte.josefsson.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hrKatsw4Q6t4NNH830pfUTQEgVtvQ09hv" Archived-At: Cc: draft-harkins-salted-eap-pwd.all@ietf.org, "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-harkins-salted-eap-pwd-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 07:03:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hrKatsw4Q6t4NNH830pfUTQEgVtvQ09hv Content-Type: multipart/mixed; boundary="IojGbuDJ04kED0DIUDqLV7Q2hAONTgrkB"; protected-headers="v1" From: Stefan Winter To: Simon Josefsson , Kathleen Moriarty Cc: Dan Harkins , "secdir@ietf.org" , draft-harkins-salted-eap-pwd.all@ietf.org Message-ID: Subject: Re: [secdir] secdir review of draft-harkins-salted-eap-pwd-06 References: <87fuosqtkh.fsf@latte.josefsson.org> <66a779c8-d87b-7c70-c7cf-7eabc48f9880@lounge.org> <20160924111622.6d1308ce@latte.josefsson.org> <69d90890-3c84-46e2-d1ef-0e264e28d568@lounge.org> <20161010081355.2a597c69@latte.josefsson.org> In-Reply-To: <20161010081355.2a597c69@latte.josefsson.org> --IojGbuDJ04kED0DIUDqLV7Q2hAONTgrkB Content-Type: multipart/mixed; boundary="------------79D20493164A1EEB6144DB6A" This is a multi-part message in MIME format. --------------79D20493164A1EEB6144DB6A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, > I still believe it is a bad idea to describe non-iterative password > protection schemes at all. We have had 15+ years of bad incidents with= > salted password databases that suggest it is time to stop doing that. This is not the ocean this draft attempts to boil. The draft does not make any recommendations about how to store passwords.= It attempts to make password databases usable with a new EAP type. I don't think you are actually stating that salt-hash databases don't exist in massive amounts in deployed reality? Because saying so would be quite silly; they do exist. If we were to ignore that deployed reality and spec the draft merely around PBKDF2 and some, we'd have an EAP type supporting only a tiny fraction of password databases out there. All the rest of deployed reality is left without a good zero-knowledge EAP type and is remains stranded with "traditional" PKIX-style server validations with either a cleartext password or a lousy NT-Hash inside the TLS tunnel - which, as our experience in a world-scale EAP-based roaming consortium shows, means: no protection at all for many because end users ignore all certificate warnings given half a chance to. It is actually quite easy to improve security for virtually everybody using EAP: it's these few paragraphs in the draft which describe how to use salted databases. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 2, avenue de l'Universit=C3=A9 L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------79D20493164A1EEB6144DB6A Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------79D20493164A1EEB6144DB6A-- --IojGbuDJ04kED0DIUDqLV7Q2hAONTgrkB-- --hrKatsw4Q6t4NNH830pfUTQEgVtvQ09hv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJX+z06AAoJEMDeajWKOdxmevkP/1zfKQ4sdfNR/m4p7AqxUtW9 F8XEbN74DMJeD4lRJhiKAXq17EZZed6uNDGp9GGWY+j2MHA55DRTv2lQlk1tH2fI Z4uYbG2wpWhubCA4Ooxn7DcxN4+gKc0b4CeN9m1IIkSJ4TX3IDoggyQTbTt+7DND ImVsLdkqV46IECPJdZ46Zm13jHoWHIMAgsWV7ve1YKVFPhteUSNG8DRWke6a77BK hVHHgE56QHgtmo1MjB4pYh/TZT7D2lBurTUnQywxEVI0I8lg6O461oJhGUnq7r3P uSA7cSwd6GVDLojamDE8/rkA4hMQ+/GxZs4tM8sASAV3Po8MqAN4jLwNQpU/NDD5 pRmngXk+MEE2JNq4eLUox2/52749yeWrO8B2uWHRlDoBAAgUwj8kz5Do4zeUNDvX b7owHbQyRN0aXcTAMP0ykrf1DBhkIb3PFBB0ULx6hCdK0WQyULqiRXgqqrfvRO1g sBcC0ek+UK8HMQpYVSlcL+itXg7JrTu1xpCUnjVCZ5a3SeFnyFd5Z5kv8djG6q4p MDJenHHLIlG8BiJ/C9K7MsVbEnuEaP/v/gLosdGKEK2fpltT1ostaft5ayKP17st Sunm/bFZUh35dhry1WT8qL8qfjGw1+f7IP7UmwW6cHZDjxDNfl9CLYX77FTCWRC6 SIPZaqEGJPwR+NbYv0hv =j80d -----END PGP SIGNATURE----- --hrKatsw4Q6t4NNH830pfUTQEgVtvQ09hv-- From nobody Mon Oct 10 00:18:35 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B68D1294A5; Mon, 10 Oct 2016 00:18:33 -0700 (PDT) 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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 2k694xbzlXDD; Mon, 10 Oct 2016 00:18:31 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 698E2127076; Mon, 10 Oct 2016 00:18:31 -0700 (PDT) Received: from iller (c-a0c1d954.014-1001-73746f1.cust.bredbandsbolaget.se [84.217.193.160]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id u9A7IRWu020622 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 10 Oct 2016 09:18:28 +0200 Message-ID: <1476083904.32538.17.camel@josefsson.org> From: Simon Josefsson To: Stefan Winter Date: Mon, 10 Oct 2016 09:18:24 +0200 In-Reply-To: References: <87fuosqtkh.fsf@latte.josefsson.org> <66a779c8-d87b-7c70-c7cf-7eabc48f9880@lounge.org> <20160924111622.6d1308ce@latte.josefsson.org> <69d90890-3c84-46e2-d1ef-0e264e28d568@lounge.org> <20161010081355.2a597c69@latte.josefsson.org> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-oGyocCCHUzcxfOshI7aa" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 X-Virus-Scanned: clamav-milter 0.99.2 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: draft-harkins-salted-eap-pwd.all@ietf.org, Kathleen Moriarty , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-harkins-salted-eap-pwd-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 07:18:33 -0000 --=-oGyocCCHUzcxfOshI7aa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable m=C3=A5n 2016-10-10 klockan 09:03 +0200 skrev Stefan Winter: > Hello, >=20 > > I still believe it is a bad idea to describe non-iterative password > > protection schemes at all. We have had 15+ years of bad incidents with > > salted password databases that suggest it is time to stop doing that. >=20 > This is not the ocean this draft attempts to boil. >=20 > The draft does not make any recommendations about how to store passwords. Hello Stefan. Recommendations ought to be part of the security considerations. It already is part of the document, to some extent. > It attempts to make password databases usable with a new EAP type. >=20 > I don't think you are actually stating that salt-hash databases don't > exist in massive amounts in deployed reality? Because saying so would be > quite silly; they do exist. Of course. I did not say that, and if you got that impression, I must have been terribly unclear in what I wrote. I question whether deployed PRECIS/OpaqueString databases prepared passwords salted+hashed with SHA1 exists. PRECIS/OpaqueString is fairly new. My perception is that people who are knowledgeable enough to use PRECIS/OpaqueString to prepare passwords in general also know that salting passwords is not sufficient. > If we were to ignore that deployed reality and spec the draft merely > around PBKDF2 and some, we'd have an EAP type supporting only a tiny > fraction of password databases out there. All the rest of deployed > reality is left without a good zero-knowledge EAP type and is remains > stranded with "traditional" PKIX-style server validations with either a > cleartext password or a lousy NT-Hash inside the TLS tunnel - which, as > our experience in a world-scale EAP-based roaming consortium shows, > means: no protection at all for many because end users ignore all > certificate warnings given half a chance to. >=20 > It is actually quite easy to improve security for virtually everybody > using EAP: it's these few paragraphs in the draft which describe how to > use salted databases. I'm with you on the high-level discussion. So let's discuss details. My assertions are: 1) Drafts dealing with password hashing should not ignore security practices around password hashing. Supporting PBKDF2 is a hygiene factor, scrypt gives bonus points. 2) Complexity leads to reduced security. Is there legacy justification for all variants of hashes specified in the document? Is there legacy justification for both SASLprep and PRECIS/OpaqueString? 3) I challenge that PRECIS/OpaqueString-prepared passwords are deployed in a salted+hashed way but without iterative constructs. If you have pointers to the opposite, for each of the specified hashes, I'm happy to learn something new. What do you think? I'm aware of password databases that use raw salt+hash on (unprepared) UTF-8 encoded password strings. In my experience, that is more common than salt+hash of SASLprep or PRECIS/OpaqueString passwords. The draft does not discuss how the password is encoded for TBD1-TBD10, which seems like another missing piece. /Simon --=-oGyocCCHUzcxfOshI7aa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJX+0DAAAoJEIYLf7sy+BGdHtMH+wQp87BqRVIk0lcIVMeYIZ3j y7bHm4la/n2lvU6GrmjI0X7VI0v2a/9VjqFBeWdCCv1WWdi1M7pNB66Wc7Fn245r 1EfLeCLOd6PbNhtFQt05QhXbti+Meq9212Oybo5xEljiv8lEe6jt33YYJZ2AffHe tUHECzSaAKSHgq1YFmxCacTpwEgHEuCPiBOFQZy1MGzzAFHEISvOif46IdD+Sw7l MyDLCBu5CkaTCaV8IYylJ3yLVih2B5nRUHgfDi2QRKBfP42R9Oqo5JXdBUKYr071 T5vc2do+b8P50YzClwe7Xfny+NN4Kdvz5IUNz9f10liotPXSKwFfCgo4r3rB+IE= =xAuG -----END PGP SIGNATURE----- --=-oGyocCCHUzcxfOshI7aa-- From nobody Mon Oct 10 05:56:05 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41722129655; Mon, 10 Oct 2016 05:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=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 dvdpJpawvNKP; Mon, 10 Oct 2016 05:56:01 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82018129653; Mon, 10 Oct 2016 05:56:00 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u9ACtus3028808 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 10 Oct 2016 15:55:56 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u9ACttra015165; Mon, 10 Oct 2016 15:55:55 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22523.36827.869306.70163@fireball.acr.fi> Date: Mon, 10 Oct 2016 15:55:55 +0300 From: Tero Kivinen To: In-Reply-To: <1130739157.4563724.1475509147203@mail.yahoo.com> References: <22495.62038.771947.984586@fireball.acr.fi> <1264225155.363685.1474644268281@mail.yahoo.com> <22507.60901.665544.878052@fireball.acr.fi> <1130739157.4563724.1475509147203@mail.yahoo.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 28 min X-Total-Time: 28 min Archived-At: Cc: "iesg@ietf.org" , "draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 12:56:02 -0000 nalini.elkins@insidethestack.com writes: > >There are most likely also other kind of attacks, and as this is > >service as ESP provides, it is not for PDM to break it unless you > >explictly spell it out that this is meant to break property of the > >ESP. > > OK. I am convinced. I will tell you though that some of us in IPPM, > we were quite excited (possibly naively) about being able to get > some performance metrics for ESP. Why do you think you can performance metrics for ESP in that case? > I wonder if it would be acceptable to say that PDM could be put into > the Destination Option which precedes ESP if it is for an enterprise > customer who owns the infrastructure and wishes to manage the > network that way. Otherwise, I can change to say that only the Dest > Opt following ESP can be used. I would recommend that if you use transport mode ESP (i.e., where the flow information would be leaked out from the ESP if PDM is used) then it must be put inside the ESP. If you use tunnel mode ESP, then there migth be two PDM headers in the packet, one in the inner packet inside the ESP header (which has full IP header + destination options including PDM option), and another one in the outer header, in which case it would only cover the ESP as one flow (i.e., each ESP SA identified by the SPIs would get separate PDM option). I.e. in the Tunnel mode ESP you want to defined the "5-tuple" as: SADDR, DADDR, PROTC (=ESP), SPI-IN, SPI-OUT Btw, in the ICMP etc you do not have port numbers. Are ICMP frames related to the TCP flows matching the "5-tuple" of the TCP flow or are they counted as separate? Anyways so if you define Tunnel mode ESP that way, then you can get some performance metrics from the ESP processing also. Then if the enterprice is willing to sacrifice the traffic flow confidentiality, they can turn on the sa-per-flow option of the IPsec implementation, which will create separate SA pair for each TCP/UDP etc flow, so then they will get exact measurements. In normal case the Tunnel mode ESP will just provide performance metrics for combination of all traffic inside the tunnel, not per flow. When using the Transport Mode ESP, then putting the PDM option inside still provides performance metrics for the host. > >so the range is definately enough. The question is that if the scale > >is from -127 to 128, why do we even need the Time Base? > > The time base is so that one does not have to be committed to > picoseconds / milliseconds, etc. Even in your example, I believe > you used "unit" or time base. Our thinking was that we wanted > future proof so as to be able to handle very small values and very > large (as may be needed for DTN, for example). We can see if we can > express years in picoseconds and see what happens. Then, the unit > would always be picoseconds. Having scale from -127 to 128 will provide quite good future proof, for at least for this universum. Even if you used attoseconds as base, you could express 10^13 years which is still more than 1000 times longer than the current age of the universe... > >3.5 Implementation Considerations > > > The PDM destination options extension header SHOULD be turned on by > > each stack on a host node. It MAY also be turned on only in case of > > diagnostics needed for problem resolution. > > > so it seems it is on by default. > > Will change to say that it MUST be turned on only by the stack and > default value should be OFF. > > "The PDM destination options extension header MUST be turned on only > by administrative action at each stack on a host node. The default > mode for PDM is OFF." Good. > >Key management packets are usually in clear, as they are there before > >we have the actual keys we can use to protect the messages. Also it is > >not very difficult to guess that 3rd and 4th message in port 500, are > >the IKE AUTH packets, which will contain signatures. > > >Same thing with TLS. > > >Attackers will knows which packets contain signatures. Currently > >attackers usually send those signature packets themselves, and measure > >the time it takes for the device to calculate response. They can also > >send garbage packets, and detect how far in checking the packets got > >by checking how long it took for the other end to send error message > >back. > > >All this kind of timing attacks are usually considered hard, as the > >network delays cause big jitter on the timings, and they need to try > >multiple times, and average the response times to get the information > >they need. > > >This method will provide them easy way to bypass that issue. > > OK. So, are you saying that PDM is attack vector for TLS and not > just for ESP? Yes, timing attacks are possible against any crypto protocol. If the protocol and algorithms used in the protocol are specifically written so that they are protected against timing attacks, they will not work, but lots of the implementations and protocols care more about the speed, than for the timing attacks, especially as launching them over longer distance gets harder and harder as other things add random times to measurements. If this allows easy way to get exact timing information from the node without any issues from the network latencies and so on, this might open completely new ways to attack implementations and protocols. Those attacks were not feasible before, but now they might be. > No, obviously not. So, now I am not sure where we are. Is there a > complete objection to this draft or are there changes which can be > made which would make this acceptable? Yes, I do not think there is anything that cannot be fixed, but there are things that needs fixing (from the security point of view): 1) Location of the PDM in ESP transport mode traffic. 2) Make sure this is turned off by default, and you do not want node to respond incoming PDM options unless turned on by adminstrator. 3) Add to security considerations section aclear warnings about the new possibilities for timing attacks if PDM is turned on. (not sure if I forgot something). -- kivinen@iki.fi From nobody Mon Oct 10 08:58:09 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEE612952B; Mon, 10 Oct 2016 08:58:08 -0700 (PDT) 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Pq4VNNM4cA9i; Mon, 10 Oct 2016 08:58:06 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id D95F2129488; Mon, 10 Oct 2016 08:58:06 -0700 (PDT) Received: from thinny.local (69-12-173-8.static.dsltransport.net [69.12.173.8]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by colo.trepanning.net (Postfix) with ESMTPSA id 5E6881022400A; Mon, 10 Oct 2016 08:58:06 -0700 (PDT) To: Simon Josefsson , Stefan Winter References: <87fuosqtkh.fsf@latte.josefsson.org> <66a779c8-d87b-7c70-c7cf-7eabc48f9880@lounge.org> <20160924111622.6d1308ce@latte.josefsson.org> <69d90890-3c84-46e2-d1ef-0e264e28d568@lounge.org> <20161010081355.2a597c69@latte.josefsson.org> <1476083904.32538.17.camel@josefsson.org> From: Dan Harkins Message-ID: <881e087e-c09e-7322-b700-95d1b7168a73@lounge.org> Date: Mon, 10 Oct 2016 08:58:04 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <1476083904.32538.17.camel@josefsson.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-harkins-salted-eap-pwd.all@ietf.org, Kathleen Moriarty , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-harkins-salted-eap-pwd-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 15:58:08 -0000 Hello, On 10/10/16 12:18 AM, Simon Josefsson wrote: > mån 2016-10-10 klockan 09:03 +0200 skrev Stefan Winter: >> Hello, >> >>> I still believe it is a bad idea to describe non-iterative password >>> protection schemes at all. We have had 15+ years of bad incidents with >>> salted password databases that suggest it is time to stop doing that. >> This is not the ocean this draft attempts to boil. >> >> The draft does not make any recommendations about how to store passwords. > Hello Stefan. > > Recommendations ought to be part of the security considerations. It > already is part of the document, to some extent. > >> It attempts to make password databases usable with a new EAP type. >> >> I don't think you are actually stating that salt-hash databases don't >> exist in massive amounts in deployed reality? Because saying so would be >> quite silly; they do exist. > Of course. I did not say that, and if you got that impression, I must > have been terribly unclear in what I wrote. > > I question whether deployed PRECIS/OpaqueString databases prepared > passwords salted+hashed with SHA1 exists. PRECIS/OpaqueString is fairly > new. My perception is that people who are knowledgeable enough to use > PRECIS/OpaqueString to prepare passwords in general also know that > salting passwords is not sufficient. But the draft doesn't specify OpaqueString with SHA1. >> If we were to ignore that deployed reality and spec the draft merely >> around PBKDF2 and some, we'd have an EAP type supporting only a tiny >> fraction of password databases out there. All the rest of deployed >> reality is left without a good zero-knowledge EAP type and is remains >> stranded with "traditional" PKIX-style server validations with either a >> cleartext password or a lousy NT-Hash inside the TLS tunnel - which, as >> our experience in a world-scale EAP-based roaming consortium shows, >> means: no protection at all for many because end users ignore all >> certificate warnings given half a chance to. >> >> It is actually quite easy to improve security for virtually everybody >> using EAP: it's these few paragraphs in the draft which describe how to >> use salted databases. > I'm with you on the high-level discussion. So let's discuss details. > My assertions are: > > 1) Drafts dealing with password hashing should not ignore security > practices around password hashing. Supporting PBKDF2 is a hygiene > factor, scrypt gives bonus points. It does support PBKDF2 now. Yes, it does so under the guise of scrypt because the scrypt RFC indicates that as an option. Adding support for the other scrypt options would open up this draft to ugly negotiation. I can get away with crypt() doing a myriad of stuff under the covers because it embeds the specific algorithm in the salt and all I need to do is say do crypt(). So does this draft not already pass the hygiene test and also get a single bonus point? > > 2) Complexity leads to reduced security. Is there legacy justification > for all variants of hashes specified in the document? Is there legacy > justification for both SASLprep and PRECIS/OpaqueString? I believe the answer to the first question is yes. That is the motivation for this draft. Regarding the second question, there is no legacy justification for OpaqueString but there is one for SASLprep, that's whey there's an option for SASLprep with SHA-1 but none for OpaqueString with SHA-1. > 3) I challenge that PRECIS/OpaqueString-prepared passwords are deployed > in a salted+hashed way but without iterative constructs. If you have > pointers to the opposite, for each of the specified hashes, I'm happy to > learn something new. I have no pointers but if that is your challenge that you should be happy that the draft supports OpaqueString-prepared passwords with SHA-256 and SHA-512-- i.e. no iterative constructs. It also supports OpaqueString-prepared passwords with scrypt/PBKDF2 with SHA-256 and SHA-512 so we should have all bases covered. > > What do you think? > > I'm aware of password databases that use raw salt+hash on (unprepared) > UTF-8 encoded password strings. In my experience, that is more common > than salt+hash of SASLprep or PRECIS/OpaqueString passwords. The draft > does not discuss how the password is encoded for TBD1-TBD10, which seems > like another missing piece. It says: When using SASLprep a password SHALL be considered a "stored string" per [RFC3454] and unassigned code points are therefore prohibited. The output of SASLprep SHALL be the binary representation of the processed UTF-8 character string. Prohibted output and unassigned codepoints encountered in SASLprep pre-processing SHALL cause a failure of pre-processing, and the output SHALL NOT be used with EAP-pwd. For the non-internationalized EAP-pwd already says: The input password string SHALL be treated as an ASCII string or a hexadecimal string with no treatment or normalization performed. The output SHALL be the binary representation of the input string. I'm really not sure what changes are still needed in this draft. If there are, please tell me again. regards, Dan. From nobody Mon Oct 10 12:02:36 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1391F129543; Mon, 10 Oct 2016 12:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.821 X-Spam-Level: X-Spam-Status: No, score=-0.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_SUBJECT=1.799, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=no autolearn_force=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 tZ59uH59PGck; Mon, 10 Oct 2016 12:02:30 -0700 (PDT) Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B04D8129597; Mon, 10 Oct 2016 12:02:30 -0700 (PDT) Received: from in02.mta.xmission.com ([166.70.13.52]) by out01.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1btfqH-0002JA-Ql; Mon, 10 Oct 2016 13:02:29 -0600 Received: from [72.250.219.84] (helo=rumpleteazer.rhmr.com) by in02.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1btfqG-0002QT-TB; Mon, 10 Oct 2016 13:02:29 -0600 Received: from rumpleteazer.rhmr.com (localhost [127.0.0.1]) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id u9AJ19cc032456; Mon, 10 Oct 2016 13:01:09 -0600 Received: (from hilarie@localhost) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Submit) id u9AJ18tA032453; Mon, 10 Oct 2016 13:01:08 -0600 Date: Mon, 10 Oct 2016 13:01:08 -0600 Message-Id: <201610101901.u9AJ18tA032453@rumpleteazer.rhmr.com> From: "Hilarie Orman" To: iesg@ietf.org, secdir@ietf.org X-XM-SPF: eid=1btfqG-0002QT-TB; ; ; mid=<201610101901.u9AJ18tA032453@rumpleteazer.rhmr.com>; ; ; hst=in02.mta.xmission.com; ; ; ip=72.250.219.84; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-AID: U2FsdGVkX196hdCtudTXKBGzwHPGyHhb X-SA-Exim-Connect-IP: 72.250.219.84 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa04 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ***;iesg@ietf.org, secdir@ietf.org X-Spam-Relay-Country: X-Spam-Timing: total 547 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 4.2 (0.8%), b_tie_ro: 2.9 (0.5%), parse: 1.53 (0.3%), extract_message_metadata: 5 (0.9%), get_uri_detail_list: 2.4 (0.4%), tests_pri_-1000: 2.4 (0.4%), tests_pri_-950: 1.03 (0.2%), tests_pri_-900: 0.84 (0.2%), tests_pri_-400: 31 (5.7%), check_bayes: 29 (5.4%), b_tokenize: 7 (1.3%), b_tok_get_all: 10 (1.8%), b_comp_prob: 5 (1.0%), b_tok_touch_all: 4.5 (0.8%), b_finish: 0.92 (0.2%), tests_pri_0: 490 (89.5%), check_dkim_signature: 0.81 (0.1%), check_dkim_adsp: 6 (1.1%), tests_pri_500: 7 (1.3%), rewrite_mail: 0.00 (0.0%) X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Archived-At: Cc: draft-ietf-l3sm-l3vpn-service-model.all@tools.ietf.org Subject: [secdir] (no subject) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Hilarie Orman List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 19:02:32 -0000 Security review of YANG Data Model for L3VPN service delivery draft-ietf-l3sm-l3vpn-service-model-16 Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document uses the YANG data model to describe an abstracted view of Layer 3 Provider Provisioned VPN services. The model has specific support for describing authentication and encryption requirements. Perhaps I'm not imaginative enough to understand how they would be used, but my impression is that the models are incomplete. grouping site-security-authentication { container authentication { description "Authentication parameters"; } description "This grouping defines authentication parameters for a site"; } In the data model shown above for "authentication", I'm not sure who the parties in the authentication are and where enforcement takes place. This may be evident to those who are more familiar with VPN provisioning. If so, some additional description would be helpful. grouping site-security-encryption { container encryption { if-feature encryption; leaf enabled { type boolean; description "If true, access encryption is required."; } leaf layer { type enumeration { enum layer2 { description "Encryption will occur at layer2."; } enum layer3 { description "IPSec is requested."; } Is IPSec the only layer 3 encryption method that is supported? } description "Layer on which encryption is applied."; } container encryption-profile { choice profile { case provider-profile { leaf profile-name { type string; description "Name of the SP profile to be applied."; The "SP profile" is something defined by the service provider. All the parameters and their interpretations are defined in some out-of-band way by the service provider. This seems to impose a great deal of difficulty for the customer. Should the provider arbitrarily change the definition, the customer's configuration parameters might be dangerously misinterpreted. Or, a customer trying to move to a different service provider might see a similar profile and try to use the same parameters. Subtle differences in interpretation could lead to a security vulnerability. } } case customer-profile { leaf algorithm { type string; description "Encryption algorithm to be used."; } choice key-type { case psk { leaf preshared-key { type string; description "Key coming from customer."; How does the customer submit the key? Should there be a key identifier? Perhaps the customer and the provider have a public key communication channel and the customer encrypts the keys and sends them to the provider, identifying them through the key identifiers? Is there a key update procedure? } } case pki { } description "Type of keys to be used."; Is "type of keys" supposed to imply the algorithm for key derivation? } } description "Choice of profile."; } description "Profile of encryption to be applied."; } I assume the profiles are the opaque "external identifiers"? "5.14. External ID references The service model sometimes refers to external information through identifiers. As an example, to order a cloud-access to a particular Cloud Service Provider (CSP), the model uses an identifier to refer to the targeted CSP. In case, a customer is using directly this service model as an API (through REST or NETCONF for example) to order a particular service, the service provider should provide a list of authorized identifiers. In case of cloud-access, the service provider will provide the identifiers associated of each available CSP. The same applies to other identifiers like std-qos-profile, oam profile-name, provider-profile for encryption ... How SP provides those identifiers meaning to the customer is out of scope of this document." If the request is spoofed or misunderstood in some way, then the encryption may be downgraded. How is the configuration protected? I think there should be a way to sign a model. There is an implied contract between the customer and the network owner, and the authenticity of the request seems paramount. An example of the very confusing typos that are sprinkled throughout the document: "I want my current site-network-access to be not be connected on the same PoP ..." Another confusing statement: "1. Introduction This document defines a YANG data model for communication between customers and network operators, and to provide input to automated control and configuration applications. " The introduction does not conform to the rules of English grammar. I'm not entirely sure what it means. Perhaps " This document defines a YANG data model. The model defines elements that can be used in communication protocols between customers and network operators. Those elements can be used also as input to automated control and configuration applications. " ?? The document is marred by running afoul of the two notoriously difficult aspects of English grammar: subject/verb agreement and articles. The errors are too numerous to mention. For the most part, the meaning of the afflicted sentences is clear, but not always. The document should not be published until the errors are corrected. From nobody Mon Oct 10 12:06:06 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F991295A2; Mon, 10 Oct 2016 12:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=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 eBxSbqXfYmht; Mon, 10 Oct 2016 12:06:00 -0700 (PDT) Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C02C12956C; Mon, 10 Oct 2016 12:06:00 -0700 (PDT) Received: from in02.mta.xmission.com ([166.70.13.52]) by out01.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1btftf-0002nD-U6; Mon, 10 Oct 2016 13:05:59 -0600 Received: from [72.250.219.84] (helo=rumpleteazer.rhmr.com) by in02.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1btfte-00037q-GE; Mon, 10 Oct 2016 13:05:59 -0600 Received: from rumpleteazer.rhmr.com (localhost [127.0.0.1]) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id u9AJ4d1o000608; Mon, 10 Oct 2016 13:04:39 -0600 Received: (from hilarie@localhost) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Submit) id u9AJ4dgA000607; Mon, 10 Oct 2016 13:04:39 -0600 Date: Mon, 10 Oct 2016 13:04:39 -0600 Message-Id: <201610101904.u9AJ4dgA000607@rumpleteazer.rhmr.com> From: "Hilarie Orman" To: iesg@ietf.org, secdir@ietf.org X-XM-SPF: eid=1btfte-00037q-GE; ; ; mid=<201610101904.u9AJ4dgA000607@rumpleteazer.rhmr.com>; ; ; hst=in02.mta.xmission.com; ; ; ip=72.250.219.84; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-AID: U2FsdGVkX1865e4aFKqzo01XXwOdTyvO X-SA-Exim-Connect-IP: 72.250.219.84 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa02 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ***;iesg@ietf.org, secdir@ietf.org X-Spam-Relay-Country: X-Spam-Timing: total 1074 ms - load_scoreonly_sql: 0.11 (0.0%), signal_user_changed: 10 (0.9%), b_tie_ro: 8 (0.8%), parse: 2.5 (0.2%), extract_message_metadata: 12 (1.1%), get_uri_detail_list: 6 (0.6%), tests_pri_-1000: 6 (0.5%), tests_pri_-950: 2.6 (0.2%), tests_pri_-900: 2.1 (0.2%), tests_pri_-400: 52 (4.9%), check_bayes: 49 (4.6%), b_tokenize: 19 (1.8%), b_tok_get_all: 12 (1.1%), b_comp_prob: 9 (0.8%), b_tok_touch_all: 3.9 (0.4%), b_finish: 1.01 (0.1%), tests_pri_0: 935 (87.0%), check_dkim_signature: 1.40 (0.1%), check_dkim_adsp: 6 (0.6%), tests_pri_500: 43 (4.0%), rewrite_mail: 0.00 (0.0%) X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Archived-At: Cc: draft-ietf-l3sm-l3vpn-service-model.all@tools.ietf.org Subject: [secdir] Security review of draft-ietf-l3sm-l3vpn-service-model-16 YANG Data Model for L3VPN service delivery X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Hilarie Orman List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 19:06:01 -0000 [Including subject line on resend] Security review of YANG Data Model for L3VPN service delivery draft-ietf-l3sm-l3vpn-service-model-16 Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document uses the YANG data model to describe an abstracted view of Layer 3 Provider Provisioned VPN services. The model has specific support for describing authentication and encryption requirements. Perhaps I'm not imaginative enough to understand how they would be used, but my impression is that the models are incomplete. grouping site-security-authentication { container authentication { description "Authentication parameters"; } description "This grouping defines authentication parameters for a site"; } In the data model shown above for "authentication", I'm not sure who the parties in the authentication are and where enforcement takes place. This may be evident to those who are more familiar with VPN provisioning. If so, some additional description would be helpful. grouping site-security-encryption { container encryption { if-feature encryption; leaf enabled { type boolean; description "If true, access encryption is required."; } leaf layer { type enumeration { enum layer2 { description "Encryption will occur at layer2."; } enum layer3 { description "IPSec is requested."; } Is IPSec the only layer 3 encryption method that is supported? } description "Layer on which encryption is applied."; } container encryption-profile { choice profile { case provider-profile { leaf profile-name { type string; description "Name of the SP profile to be applied."; The "SP profile" is something defined by the service provider. All the parameters and their interpretations are defined in some out-of-band way by the service provider. This seems to impose a great deal of difficulty for the customer. Should the provider arbitrarily change the definition, the customer's configuration parameters might be dangerously misinterpreted. Or, a customer trying to move to a different service provider might see a similar profile and try to use the same parameters. Subtle differences in interpretation could lead to a security vulnerability. } } case customer-profile { leaf algorithm { type string; description "Encryption algorithm to be used."; } choice key-type { case psk { leaf preshared-key { type string; description "Key coming from customer."; How does the customer submit the key? Should there be a key identifier? Perhaps the customer and the provider have a public key communication channel and the customer encrypts the keys and sends them to the provider, identifying them through the key identifiers? Is there a key update procedure? } } case pki { } description "Type of keys to be used."; Is "type of keys" supposed to imply the algorithm for key derivation? } } description "Choice of profile."; } description "Profile of encryption to be applied."; } I assume the profiles are the opaque "external identifiers"? "5.14. External ID references The service model sometimes refers to external information through identifiers. As an example, to order a cloud-access to a particular Cloud Service Provider (CSP), the model uses an identifier to refer to the targeted CSP. In case, a customer is using directly this service model as an API (through REST or NETCONF for example) to order a particular service, the service provider should provide a list of authorized identifiers. In case of cloud-access, the service provider will provide the identifiers associated of each available CSP. The same applies to other identifiers like std-qos-profile, oam profile-name, provider-profile for encryption ... How SP provides those identifiers meaning to the customer is out of scope of this document." If the request is spoofed or misunderstood in some way, then the encryption may be downgraded. How is the configuration protected? I think there should be a way to sign a model. There is an implied contract between the customer and the network owner, and the authenticity of the request seems paramount. An example of the very confusing typos that are sprinkled throughout the document: "I want my current site-network-access to be not be connected on the same PoP ..." Another confusing statement: "1. Introduction This document defines a YANG data model for communication between customers and network operators, and to provide input to automated control and configuration applications. " The introduction does not conform to the rules of English grammar. I'm not entirely sure what it means. Perhaps " This document defines a YANG data model. The model defines elements that can be used in communication protocols between customers and network operators. Those elements can be used also as input to automated control and configuration applications. " ?? The document is marred by running afoul of the two notoriously difficult aspects of English grammar: subject/verb agreement and articles. The errors are too numerous to mention. For the most part, the meaning of the afflicted sentences is clear, but not always. The document should not be published until the errors are corrected. From nobody Mon Oct 10 12:08:32 2016 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD50129597; Mon, 10 Oct 2016 12:05:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1476126349; bh=LI+KsEFW5GVqY1/z9yA/PSC1Qe+WeuiepZd80lFNO1g=; h=From:Date:To:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=JjIMD9DFlVF1iFAXC9vrr4n4HF4JfZB5ByXkplX3Va1hmhNkgARFWEyUCAP2ANAq4 Dbv1DmlK+HBXJVl9iloqfVh1cZHHy8yEVmUsRMP0GmcgouCmSquh+cLA9A+yEjv5tE KL4WDoKZrYIX1CmydX0NBGJLXrEvy0Fr+trtKwVw= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5F512956C for ; Mon, 10 Oct 2016 12:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.897 X-Spam-Level: X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 4hgBE6kRxvet for ; Mon, 10 Oct 2016 12:05:45 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3B7B129597 for ; Mon, 10 Oct 2016 12:05:45 -0700 (PDT) Received: from boc06-4-78-216-15-101.fbx.proxad.net ([78.216.15.101] helo=[192.168.0.10]) by raoul.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1btftQ-00043u-6I; Mon, 10 Oct 2016 19:05:44 +0000 From: Coralie Mercier Date: Mon, 10 Oct 2016 21:05:42 +0200 To: new-work@ietf.org Message-Id: <661718D2-856E-4D27-827E-6E7611010399@w3.org> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Mon, 10 Oct 2016 12:08:31 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Automotive Working Group (until 2016-11-07) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 19:05:49 -0000 SGVsbG8sCgpUb2RheSBXM0MgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlcyByZWNl aXZlZCBhIFByb3Bvc2FsIHRvIHJldmlldyBhIGRyYWZ0IGNoYXJ0ZXIgZm9yIHRoZSBBdXRvbW90 aXZlIFdvcmtpbmcgR3JvdXA6CiAgIGh0dHBzOi8vd3d3LnczLm9yZy8yMDE0L2F1dG9tb3RpdmUv Y2hhcnRlci0yMDE2Lmh0bWwKCkFzIHBhcnQgb2YgZW5zdXJpbmcgdGhhdCB0aGUgY29tbXVuaXR5 IGlzIGF3YXJlIG9mIHByb3Bvc2VkIHdvcmsgYXQgVzNDLCB0aGlzIGRyYWZ0IGNoYXJ0ZXIgaXMg cHVibGljIGR1cmluZyB0aGUgQWR2aXNvcnkgQ29tbWl0dGVlIHJldmlldyBwZXJpb2QuCgpXM0Mg aW52aXRlcyBwdWJsaWMgY29tbWVudHMgdGhyb3VnaCAyMDE2LTExLTA3IG9uIHRoZSBwcm9wb3Nl ZCBjaGFydGVyLiBQbGVhc2Ugc2VuZCBjb21tZW50cyB0byA8cHVibGljLW5ldy13b3JrQHczLm9y Zz4sIHdoaWNoIGhhcyBhIHB1YmxpYyBhcmNoaXZlOiAgICAgCiAgaHR0cDovL2xpc3RzLnczLm9y Zy9BcmNoaXZlcy9QdWJsaWMvcHVibGljLW5ldy13b3JrLwoKCk90aGVyIHRoYW4gY29tbWVudHMg c2VudCBpbiBmb3JtYWwgcmVzcG9uc2VzIGJ5IFczQyBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVz ZW50YXRpdmVzLCBXM0MgY2Fubm90IGd1YXJhbnRlZSBhIHJlc3BvbnNlIHRvIGNvbW1lbnRzLiBJ ZiB5b3Ugd29yayBmb3IgYSBXM0MgTWVtYmVyIFsxXSwgcGxlYXNlIGNvb3JkaW5hdGUgeW91ciBj b21tZW50cyB3aXRoIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlLiBGb3Ig ZXhhbXBsZSwgeW91IG1heSB3aXNoIHRvIG1ha2UgcHVibGljIGNvbW1lbnRzIHZpYSB0aGlzIGxp c3QgYW5kIGhhdmUgeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50YXRpdmUgcmVmZXIg dG8gaXQgZnJvbSBoaXMgb3IgaGVyIGZvcm1hbCByZXZpZXcgY29tbWVudHMuCgpJZiB5b3Ugc2hv dWxkIGhhdmUgYW55IHF1ZXN0aW9ucyBvciBuZWVkIGZ1cnRoZXIgaW5mb3JtYXRpb24sIHBsZWFz ZSBjb250YWN0IEtheiBBc2hpbXVyYSA8YXNoaW11cmFAdzMub3JnPiBvciBUZWQgR3VpbGQgPHRl ZEB3My5vcmc+LCBTdGFmZiBDb250YWN0cy4KClRoYW5rIHlvdSwKQ29yYWxpZSBNZXJjaWVyLCBI ZWFkIG9mIFczQyBNYXJrZXRpbmcgJiBDb21tdW5pY2F0aW9ucwoKWzFdIGh0dHA6Ly93d3cudzMu b3JnL0NvbnNvcnRpdW0vTWVtYmVyL0xpc3QKCuKAlApDb3JhbGllIE1lcmNpZXIgIC0gIFczQyBN YXJrZXRpbmcgJiBDb21tdW5pY2F0aW9ucyAtICBodHRwOi8vd3d3LnczLm9yZwptYWlsdG86Y29y YWxpZUB3My5vcmcgKzMzNiA0MzIyIDAwMDEgaHR0cDovL3d3dy53My5vcmcvUGVvcGxlL0NNZXJj aWVyLwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV3 LXdvcmsgbWFpbGluZyBsaXN0Cm5ldy13b3JrQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV3LXdvcmsK From nobody Mon Oct 10 13:17:39 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD9C129744; Mon, 10 Oct 2016 13:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Jjt5cbM9LUtP; Mon, 10 Oct 2016 13:17:36 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE815129503; Mon, 10 Oct 2016 13:17:36 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id o68so882431qkf.3; Mon, 10 Oct 2016 13:17:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Nqy5g+3eWK1Sl3lANAsn+IdbC2B/TAet0T8xLQanHe4=; b=b545OTwUXGkrO/YVEM5O8WQY+K4yrqcPqgD0AwXPYtX/tjSu30Y/nzg3b1S8qZ5yx2 UdAqUcMG+UuFSFVtpzd4w1XcGcYyO6TWNsksT3GiIBYIMw30RkLR0YNWquGYicJ42IJA ZDMS+UZqGIRpxaDssLpwBUaNUrjm2J+aKj8u9SzjgQSkTRXOYnwzwa+kyQgAbNZCejgJ bKJW7rbtId5fyS5KyELtpahsAOKkNg6LTW7sQc22dyXJm6wiOnFa4/tYQygUhGaMFoSz lOQbnNP/vfw7Ns+aQ5gVjKJP2Eo6YW6b2B4LAkPP5Y6y7ZWnwHjN1v/BywSRMvGmR4zx nXWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Nqy5g+3eWK1Sl3lANAsn+IdbC2B/TAet0T8xLQanHe4=; b=MTSguf4g5OnURrO1DKMxP0aRRv/L2muehuRfXrSOw/liAiasBJ1en0had9xgs4iqPA gxy9l/9qKwBNaFVNVvPfPusmPXnLGXCufzod3lstvlEvFx8t4GF55OPkdAtUEMsBQ4vh 6r2sIrRnAA4xE1O/HeFRMC8cqURvUJYLtiFGtmY2fc8GRKFYgxEA2LbKMZrzzpFCSp5k fu4NrCZoGPP/bVemwnFoHWkpb9oybpEIOoupFr+uku9OptFYNcxOeuM3mHiMQOWdgfd5 GQsFwGHVOvCpQyszPq7lpDaW+WYxFTZsQHM+OmuUiRft9KIAnbFeeU7j6alULQOxpbkz VsCw== X-Gm-Message-State: AA6/9RnMEKL/iq3oGxtuGD1tBBB5nKWCzpl4HDaGpbmqodasqMyZ8W/3Qjjg3IcI1K03Fg== X-Received: by 10.55.33.135 with SMTP id f7mr14866qki.141.1476130655640; Mon, 10 Oct 2016 13:17:35 -0700 (PDT) Received: from [192.168.1.4] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id d69sm8947562qke.45.2016.10.10.13.17.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 10 Oct 2016 13:17:35 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (13G36) In-Reply-To: <201610101901.u9AJ18tA032453@rumpleteazer.rhmr.com> Date: Mon, 10 Oct 2016 16:17:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201610101901.u9AJ18tA032453@rumpleteazer.rhmr.com> To: Hilarie Orman Archived-At: Cc: draft-ietf-l3sm-l3vpn-service-model.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-l3sm-l3vpn-service-model-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 20:17:38 -0000 Thank you for your review, Hilarie. Kathleen=20 Please excuse typos, sent from handheld device=20 > On Oct 10, 2016, at 3:01 PM, Hilarie Orman wrot= e: >=20 > draft-ietf-l3sm-l3vpn-service-model-16 From nobody Tue Oct 11 01:47:24 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F0A1295F4; Tue, 11 Oct 2016 01:47:21 -0700 (PDT) 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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 zha1VTMWXZBR; Tue, 11 Oct 2016 01:47:19 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B23C1294B6; Tue, 11 Oct 2016 01:47:18 -0700 (PDT) Received: from iller (c-a0c1d954.014-1001-73746f1.cust.bredbandsbolaget.se [84.217.193.160]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id u9B8lDcF022595 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 11 Oct 2016 10:47:15 +0200 Message-ID: <1476175630.28753.16.camel@josefsson.org> From: Simon Josefsson To: Dan Harkins Date: Tue, 11 Oct 2016 10:47:10 +0200 In-Reply-To: <881e087e-c09e-7322-b700-95d1b7168a73@lounge.org> References: <87fuosqtkh.fsf@latte.josefsson.org> <66a779c8-d87b-7c70-c7cf-7eabc48f9880@lounge.org> <20160924111622.6d1308ce@latte.josefsson.org> <69d90890-3c84-46e2-d1ef-0e264e28d568@lounge.org> <20161010081355.2a597c69@latte.josefsson.org> <1476083904.32538.17.camel@josefsson.org> <881e087e-c09e-7322-b700-95d1b7168a73@lounge.org> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-9aOvGdoGSbi2XhzA6Ex5" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 X-Virus-Scanned: clamav-milter 0.99.2 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: draft-harkins-salted-eap-pwd.all@ietf.org, Stefan Winter , Kathleen Moriarty , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-harkins-salted-eap-pwd-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 08:47:22 -0000 --=-9aOvGdoGSbi2XhzA6Ex5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable m=C3=A5n 2016-10-10 klockan 08:58 -0700 skrev Dan Harkins: > Hello, >=20 > On 10/10/16 12:18 AM, Simon Josefsson wrote: > > m=C3=A5n 2016-10-10 klockan 09:03 +0200 skrev Stefan Winter: > >> Hello, > >> > >>> I still believe it is a bad idea to describe non-iterative password > >>> protection schemes at all. We have had 15+ years of bad incidents wi= th > >>> salted password databases that suggest it is time to stop doing that. > >> This is not the ocean this draft attempts to boil. > >> > >> The draft does not make any recommendations about how to store passwor= ds. > > Hello Stefan. > > > > Recommendations ought to be part of the security considerations. It > > already is part of the document, to some extent. > > > >> It attempts to make password databases usable with a new EAP type. > >> > >> I don't think you are actually stating that salt-hash databases don't > >> exist in massive amounts in deployed reality? Because saying so would = be > >> quite silly; they do exist. > > Of course. I did not say that, and if you got that impression, I must > > have been terribly unclear in what I wrote. > > > > I question whether deployed PRECIS/OpaqueString databases prepared > > passwords salted+hashed with SHA1 exists. PRECIS/OpaqueString is fairl= y > > new. My perception is that people who are knowledgeable enough to use > > PRECIS/OpaqueString to prepare passwords in general also know that > > salting passwords is not sufficient. >=20 > But the draft doesn't specify OpaqueString with SHA1. It used to, I see now that you removed it. Thank you! There is still salt+SHA256 and salt+SHA512 though. Are they there for legacy reasons? I think the draft ought to be clear on which algorithms are for legacy reasons and which ones are recommended for security. OpaqueString +PBKDF2 and OpaqueString+scrypt reflect two reasonable choices these days. The others are for legacy reasons. > >> If we were to ignore that deployed reality and spec the draft merely > >> around PBKDF2 and some, we'd have an EAP type supporting only a tiny > >> fraction of password databases out there. All the rest of deployed > >> reality is left without a good zero-knowledge EAP type and is remains > >> stranded with "traditional" PKIX-style server validations with either = a > >> cleartext password or a lousy NT-Hash inside the TLS tunnel - which, a= s > >> our experience in a world-scale EAP-based roaming consortium shows, > >> means: no protection at all for many because end users ignore all > >> certificate warnings given half a chance to. > >> > >> It is actually quite easy to improve security for virtually everybody > >> using EAP: it's these few paragraphs in the draft which describe how t= o > >> use salted databases. > > I'm with you on the high-level discussion. So let's discuss details. > > My assertions are: > > > > 1) Drafts dealing with password hashing should not ignore security > > practices around password hashing. Supporting PBKDF2 is a hygiene > > factor, scrypt gives bonus points. >=20 > It does support PBKDF2 now. Yes, it does so under the guise of scrypt > because the scrypt RFC indicates that as an option. Adding support for > the other scrypt options would open up this draft to ugly negotiation. I don't understand. PBKDF2 and scrypt or two completely different algorithms. Yes, scrypt uses PBKDF2 internally, but that does not imply that scrypt offer a PBKDF2 fallback variant. > I can get away with crypt() doing a myriad of stuff under the covers > because it embeds the specific algorithm in the salt and all I need > to do is say do crypt(). >=20 > So does this draft not already pass the hygiene test and also get > a single bonus point? Unless I'm missing something, you need to separate scrypt from PBKDF2. They aren't compatible. > > 2) Complexity leads to reduced security. Is there legacy justification > > for all variants of hashes specified in the document? Is there legacy > > justification for both SASLprep and PRECIS/OpaqueString? >=20 > I believe the answer to the first question is yes. That is the motivat= ion > for this draft. Regarding the second question, there is no legacy > justification for OpaqueString but there is one for SASLprep, that's > whey there's an option for SASLprep with SHA-1 but none for OpaqueString > with SHA-1. Okay thanks for clarifying! Are there deployed databases that uses SASLprep and salt+SHA256 and salt+SHA512 respectively? My point here is that by having them in the draft, there is a risk that people will chose it even in new deployments "just because it works". If there is no deployed base, let's not give people rope to hang themselves. > > 3) I challenge that PRECIS/OpaqueString-prepared passwords are deployed > > in a salted+hashed way but without iterative constructs. If you have > > pointers to the opposite, for each of the specified hashes, I'm happy t= o > > learn something new. >=20 > I have no pointers but if that is your challenge that you should be > happy that the draft supports OpaqueString-prepared passwords with > SHA-256 and SHA-512-- i.e. no iterative constructs. No, I would be happy with this case: 1) PRECIS/OpaqueString is specified for PBKDF2 and/or scrypt only. I would be okay with: 2) A pointer to some existing deployed legacy database that uses OpaqueString+salt+SHA256/512. A situation where the draft specify OpaqueString+salt+SHA256/512 without any proven legacy need for it is not okay in my mind. > It also supports > OpaqueString-prepared passwords with scrypt/PBKDF2 with SHA-256 and SHA-5= 12 > so we should have all bases covered. Right now the scrypt/PBKDF2 variant looks confused to me. They are two different algorithms. Scrypt does not allow you to chose the hash. PBKDF2 allows the choice, but then you should cite RFC 2898. > > What do you think? > > > > I'm aware of password databases that use raw salt+hash on (unprepared) > > UTF-8 encoded password strings. In my experience, that is more common > > than salt+hash of SASLprep or PRECIS/OpaqueString passwords. The draft > > does not discuss how the password is encoded for TBD1-TBD10, which seem= s > > like another missing piece. >=20 > It says: > When using SASLprep a password SHALL be considered a "stored string" p= er > [RFC3454] and unassigned code points are therefore prohibited. The > output of SASLprep SHALL be the binary representation of the > processed UTF-8 character string. Prohibted output and unassigned > codepoints encountered in SASLprep pre-processing SHALL cause a > failure of pre-processing, and the output SHALL NOT be used with EAP-p= wd. >=20 > For the non-internationalized EAP-pwd already says: > The input password string SHALL be treated as an ASCII > string or a hexadecimal string with no treatment or normalization > performed. The output SHALL be the binary representation of the > input string. >=20 > I'm really not sure what changes are still needed in this draft. If > there are, please tell me again. Exactly. So if you re-read what I wrote, my point is that my perception is that salt+hash'ed UTF8 passwords is not uncommon, and the draft does not describe that variant. /Simon --=-9aOvGdoGSbi2XhzA6Ex5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJX/KcOAAoJEIYLf7sy+BGd62MIAI4bKdovSXpqe8ZPAIYCh+f7 3RS8nkG4hK5wEPOX5Gye+v3HuTN1lnND47Y0iyHGBJP/IqLKptzG22q2tTh42exY 31OUvKm/m+9Pvc5mvLBmF5Ov0Gp614oq4Q73LLpFd/V3KVIeyISwX/0BvuAeC4G6 xRqAxW75OMelq4mrPEQ0Ok4ygIwdUTd7rIIy4amQCxCYBriD3EZfpdsaiGgFQKwR mEDsauR6P/b4Msd9ep1S/ef+WvFJ2Ztv35VE2YhOfWdI3xj+DrGfptnfwMda7QxF WBnLJ7hJjkidi7sEtWhOGU4cMSNRe1r70iHdMkETRXPdAjMBKqX/XYujUpBSd98= =4GjL -----END PGP SIGNATURE----- --=-9aOvGdoGSbi2XhzA6Ex5-- From nobody Tue Oct 11 09:46:50 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED432129609 for ; Tue, 11 Oct 2016 09:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=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 v1n2y--UReW4 for ; Tue, 11 Oct 2016 09:46:35 -0700 (PDT) Received: from smtpcmd05149.aruba.it (smtpweb149.aruba.it [62.149.158.149]) by ietfa.amsl.com (Postfix) with ESMTP id CBC4C129655 for ; Tue, 11 Oct 2016 09:46:28 -0700 (PDT) Received: from lminiero ([93.44.60.74]) by smtpcmd05.ad.aruba.it with bizsmtp id uGmT1t00i1c60R101GmTXD; Tue, 11 Oct 2016 18:46:28 +0200 Date: Tue, 11 Oct 2016 18:46:27 +0200 From: Lorenzo Miniero To: Yoav Nir Message-ID: <20161011184627.19a46214@lminiero> In-Reply-To: References: Organization: Meetecho X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: secdir , The IESG , draft-ietf-straw-b2bua-rtcp.all@tools.ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-straw-b2bua-rtcp-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 16:46:37 -0000 Hello Yoav, sorry for this late reply... thanks for reviewing the document! As to the points you raised in your review, I've added a couple of comments inline. On Sun, 9 Oct 2016 09:57:26 +0300 Yoav Nir wrote: > Hello, >=20 > I have reviewed this document as part of the security directorate=E2=80= =99s > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > Summary: Ready with nits >=20 > The document defines the proper behavior for B2BUAs that, in addition > to being on-path for SIP, are also on-path for the media traffic, > whether RTP or RTCP. Section 3 describes different scenarios for > B2BUAs operating on the media, and if features considerations of the > type =E2=80=9Cif you change this, you also have to change that, otherwise > this bad thing could happen.=E2=80=9D The document is easy to read and > understandable even to someone who is not well versed in SIP > terminology. >=20 > The security considerations section claims that the considerations > are similar to those of the standards documents such as RFC 7667 (RTP > topologies) and RFC 7656 (A Taxonomy of Semantics and Mechanisms for > Real-Time Transport Protocol (RTP) Sources). This seems reasonable. > It also describes why encryption is not an issue (if the B2BUA can > make some changes to the media stream, then it can also make the > changes described in this document, otherwise, it can=E2=80=99t make the > original changes either), and how failing to follow this document > might be indistinguishable from an attack (that=E2=80=99s the =E2=80=9Cba= d things > happen=E2=80=9D part) >=20 > Two nits: >=20 > - The Abstract says: =E2=80=9C[B2BUAs] are often envisaged to also be on= the > media path...This means that B2BUAs often implement an RTP/RTCP > stack...=E2=80=9D. That doesn=E2=80=99t make sense with the dictionary de= finition of > =E2=80=9Cenvisage=E2=80=9D. Perhaps =E2=80=9Cdesigned=E2=80=9D? >=20 Fair point, we'll fix this in next version. > - The first paragraph of the Security Considerations is pasted > below. I don=E2=80=99t think there is much semantic difference between > "considerations" and =E2=80=9Caspects=E2=80=9D. This paragraph denies tha= t there are > considerations, and then goes on to state some. I think the whole > first paragraph can go. >=20 > Yoav >=20 What we wanted to stress out in this section is that we didn't have any specific behaviour to mandate in that sense, as other related documents do, but that we mostly wanted to underline some aspects to be wary of. I guess that a "Security Considerations" section can itself be even just about considerations, rather than rules, so I agree that it might be worthwhile to rephrase that first sentence to make what we meant clearer than it currently is. Do you think that something like [..] does not specify any additional rule [..] rather than [..] does not introduce any additional consideration [..] would do that? Thanks! Lorenzo From nobody Tue Oct 11 09:51:39 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6E9129609; Tue, 11 Oct 2016 09:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.976 X-Spam-Level: X-Spam-Status: No, score=-0.976 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_SBL=1.623, URIBL_SBL_A=0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 EPdpp2RzDNWc; Tue, 11 Oct 2016 09:51:36 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBC49129502; Tue, 11 Oct 2016 09:51:35 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id z190so44977586qkc.2; Tue, 11 Oct 2016 09:51:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=m9eQnJSO8v0SuozsBEgCA5n/Hr9E9QhExdZz0J+/dzA=; b=XEjFTszto1f0JXOFEEJM+ZN60i+H3bvFN3AlzyI0mo28RCJ/fE9rBO2bYFAVz8E9wS yglKrUzeUWD7xG40+9hoV6HqofWT4PRyu6PtxxFqlJ2q08JbUy7R8VPrQf677JWBux9N f8MOvLS3J1HG0E5rdgwIPAIWYJfZ02BEYFIzxnyQGV4c/ZiUfmwXG16FelgBBvy5mEX8 okJUqLgZ2e97dQFJlrp8witxvf0HJyOTbhPXukW6bqk+cyqFRrukXUe3NwEC9OOfh/q2 XcYl3MaQke4bzNB2v+/b0DquMBN26g7X/tQLtB3MK1jt4II9MJbFCMyqMcUHe5eDZkZp IXVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=m9eQnJSO8v0SuozsBEgCA5n/Hr9E9QhExdZz0J+/dzA=; b=cvt9Udha6FfPd/l9cX77XKIPTHUebQhRDBlcxR/ytQasSGxLMeApx7ijXzEu9dQ9vr APb8Wf96MU91w5BzfK+fo41c1sQHEUvuSPd/oGab9deTEijDRctkLbUuQJbhxQAdGY84 jmHiFoOqfu0UFAAWH+gcxoPwxg7f2AimUJN/L5g2fOIIrfNBu42aLcvM7ZxOEp1bEvpW dZou5AbdTyhzJwIFm1mjsqS+JWxI5vzLHv5UvblO9LLu8kfsMSU636Lw+iS4wrAyf6WL GpIIEtNpjSepsQbUTMsHji/3jKRt2qxydrFya9h04WaVfK6TcuLnKTokF0PfJFZnb+Ge osAQ== X-Gm-Message-State: AA6/9RniXZ6js41hjAQLMNvhbG4pTcQSmG84MqKki9CZcUGqjvXfLEVhMXO7AoYmSJQG8A== X-Received: by 10.194.134.161 with SMTP id pl1mr6228601wjb.81.1476204695055; Tue, 11 Oct 2016 09:51:35 -0700 (PDT) Received: from [192.168.1.13] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id hb5sm7832393wjc.5.2016.10.11.09.51.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Oct 2016 09:51:33 -0700 (PDT) From: Yoav Nir Message-Id: <08FE41B8-679D-45A7-855D-C6C51780D278@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_52A86740-5E1D-4A34-8721-45B10A60C2D4" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Tue, 11 Oct 2016 19:51:29 +0300 In-Reply-To: <20161011184627.19a46214@lminiero> To: Lorenzo Miniero References: <20161011184627.19a46214@lminiero> X-Mailer: Apple Mail (2.3226) Archived-At: Cc: secdir , The IESG , draft-ietf-straw-b2bua-rtcp.all@tools.ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-straw-b2bua-rtcp-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 16:51:38 -0000 --Apple-Mail=_52A86740-5E1D-4A34-8721-45B10A60C2D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 11 Oct 2016, at 19:46, Lorenzo Miniero = wrote: >=20 > Hello Yoav, >=20 > sorry for this late reply... thanks for reviewing the document! As to > the points you raised in your review, I've added a couple of comments > inline. >=20 >=20 > On Sun, 9 Oct 2016 09:57:26 +0300 > Yoav Nir > wrote: >=20 >> Hello, >>=20 >> I have reviewed this document as part of the security directorate=E2=80= =99s >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should treat >> these comments just like any other last call comments. >>=20 >> Summary: Ready with nits >>=20 >> The document defines the proper behavior for B2BUAs that, in addition >> to being on-path for SIP, are also on-path for the media traffic, >> whether RTP or RTCP. Section 3 describes different scenarios for >> B2BUAs operating on the media, and if features considerations of the >> type =E2=80=9Cif you change this, you also have to change that, = otherwise >> this bad thing could happen.=E2=80=9D The document is easy to read = and >> understandable even to someone who is not well versed in SIP >> terminology. >>=20 >> The security considerations section claims that the considerations >> are similar to those of the standards documents such as RFC 7667 (RTP >> topologies) and RFC 7656 (A Taxonomy of Semantics and Mechanisms for >> Real-Time Transport Protocol (RTP) Sources). This seems reasonable. >> It also describes why encryption is not an issue (if the B2BUA can >> make some changes to the media stream, then it can also make the >> changes described in this document, otherwise, it can=E2=80=99t make = the >> original changes either), and how failing to follow this document >> might be indistinguishable from an attack (that=E2=80=99s the =E2=80=9C= bad things >> happen=E2=80=9D part) >>=20 >> Two nits: >>=20 >> - The Abstract says: =E2=80=9C[B2BUAs] are often envisaged to also be = on the >> media path...This means that B2BUAs often implement an RTP/RTCP >> stack...=E2=80=9D. That doesn=E2=80=99t make sense with the = dictionary definition of >> =E2=80=9Cenvisage=E2=80=9D. Perhaps =E2=80=9Cdesigned=E2=80=9D? >>=20 >=20 >=20 > Fair point, we'll fix this in next version. >=20 >=20 >> - The first paragraph of the Security Considerations is pasted >> below. I don=E2=80=99t think there is much semantic difference = between >> "considerations" and =E2=80=9Caspects=E2=80=9D. This paragraph denies = that there are >> considerations, and then goes on to state some. I think the whole >> first paragraph can go. >>=20 >> Yoav >>=20 >=20 >=20 > What we wanted to stress out in this section is that we didn't have = any > specific behaviour to mandate in that sense, as other related = documents > do, but that we mostly wanted to underline some aspects to be wary of. > I guess that a "Security Considerations" section can itself be even > just about considerations, rather than rules, so I agree that it might > be worthwhile to rephrase that first sentence to make what we meant > clearer than it currently is. Do you think that something like >=20 > [..] does not specify any additional rule [..] >=20 > rather than >=20 > [..] does not introduce any additional consideration [..] Sure. Although dropping that paragraph would also work. Yoav --Apple-Mail=_52A86740-5E1D-4A34-8721-45B10A60C2D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 11 Oct 2016, at 19:46, Lorenzo Miniero <lorenzo@meetecho.com> wrote:

Hello Yoav,

sorry for this late reply... thanks for = reviewing the document! As to
the points you raised in your = review, I've added a couple of comments
inline.


On Sun, 9 Oct 2016 09:57:26 +0300
Yoav Nir <ynir.ietf@gmail.com> wrote:

Hello,

I have reviewed this document as part of the security = directorate=E2=80=99s
ongoing effort to review all IETF = documents being processed by the
IESG. These comments were = written primarily for the benefit of the
security area = directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Summary: Ready with nits

The document defines the proper behavior for B2BUAs that, in = addition
to being on-path for SIP, are also on-path for = the media traffic,
whether RTP or RTCP.  Section 3 = describes different scenarios for
B2BUAs operating on the = media, and if features considerations of the
type =E2=80=9Ci= f you change this, you also have to change that, otherwise
this bad thing could happen.=E2=80=9D The document is easy to = read and
understandable even to someone who is not well = versed in SIP
terminology.

The = security considerations section claims that the considerations
are similar to those of the standards documents such as RFC = 7667 (RTP
topologies) and RFC 7656 (A Taxonomy of = Semantics and Mechanisms for
Real-Time Transport Protocol = (RTP) Sources). This seems reasonable.
It also describes = why encryption is not an issue (if the B2BUA can
make some = changes to the media stream, then it can also make the
changes described in this document, otherwise, it can=E2=80=99t= make the
original changes either), and how failing to = follow this document
might be indistinguishable from an = attack (that=E2=80=99s the =E2=80=9Cbad things
happen=E2=80=9D= part)

Two nits:

- The Abstract says: =E2=80=9C[B2BUAs] are often envisaged to = also be on the
media path...This means that B2BUAs often = implement an RTP/RTCP
stack...=E2=80=9D. That doesn=E2=80=99= t make sense with the dictionary definition of
=E2=80=9Cenvisage=E2=80=9D. Perhaps =E2=80=9Cdesigned=E2=80=9D?=



Fair point, we'll fix this in next = version.


- The first paragraph of the = Security Considerations is pasted
below. I don=E2=80=99t = think there is much semantic difference between
"considerations" and =E2=80=9Caspects=E2=80=9D. This = paragraph denies that there are
considerations, and then = goes on to state some. I think the whole
first paragraph = can go.

Yoav



What we wanted to stress out in this section is = that we didn't have any
specific behaviour to mandate in that = sense, as other related documents
do, but that we mostly wanted to = underline some aspects to be wary of.
I guess that a "Security = Considerations" section can itself be even
just about considerations, = rather than rules, so I agree that it might
be worthwhile to rephrase that first sentence to = make what we meant
clearer than it currently is. Do you = think that something like

[..] does not specify any additional rule = [..]

rather than

= [..] does not introduce any additional = consideration [..]

Sure. = Although dropping that paragraph would also work.

Yoav

= --Apple-Mail=_52A86740-5E1D-4A34-8721-45B10A60C2D4-- From nobody Tue Oct 11 09:53:54 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC47612965A for ; Tue, 11 Oct 2016 09:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_SBL=1.623, URIBL_SBL_A=0.1] autolearn=unavailable autolearn_force=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 gBcDYiUPXI18 for ; Tue, 11 Oct 2016 09:53:45 -0700 (PDT) Received: from smtpcmd05149.aruba.it (smtpweb149.aruba.it [62.149.158.149]) by ietfa.amsl.com (Postfix) with ESMTP id 4291712965E for ; Tue, 11 Oct 2016 09:53:41 -0700 (PDT) Received: from lminiero ([93.44.60.74]) by smtpcmd05.ad.aruba.it with bizsmtp id uGtg1t0071c60R101GtgwA; Tue, 11 Oct 2016 18:53:40 +0200 Date: Tue, 11 Oct 2016 18:53:39 +0200 From: Lorenzo Miniero To: Yoav Nir Message-ID: <20161011185339.51bd9947@lminiero> In-Reply-To: <08FE41B8-679D-45A7-855D-C6C51780D278@gmail.com> References: <20161011184627.19a46214@lminiero> <08FE41B8-679D-45A7-855D-C6C51780D278@gmail.com> Organization: Meetecho X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: secdir , The IESG , draft-ietf-straw-b2bua-rtcp.all@tools.ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-straw-b2bua-rtcp-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 16:53:48 -0000 On Tue, 11 Oct 2016 19:51:29 +0300 Yoav Nir wrote: > > On 11 Oct 2016, at 19:46, Lorenzo Miniero > > wrote: > >=20 > > Hello Yoav, > >=20 > > sorry for this late reply... thanks for reviewing the document! As > > to the points you raised in your review, I've added a couple of > > comments inline. > >=20 > >=20 > > On Sun, 9 Oct 2016 09:57:26 +0300 > > Yoav Nir > wrote: > > =20 > >> Hello, > >>=20 > >> I have reviewed this document as part of the security directorate=E2= =80=99s > >> ongoing effort to review all IETF documents being processed by the > >> IESG. These comments were written primarily for the benefit of the > >> security area directors. Document editors and WG chairs should > >> treat these comments just like any other last call comments. > >>=20 > >> Summary: Ready with nits > >>=20 > >> The document defines the proper behavior for B2BUAs that, in > >> addition to being on-path for SIP, are also on-path for the media > >> traffic, whether RTP or RTCP. Section 3 describes different > >> scenarios for B2BUAs operating on the media, and if features > >> considerations of the type =E2=80=9Cif you change this, you also have = to > >> change that, otherwise this bad thing could happen.=E2=80=9D The docum= ent > >> is easy to read and understandable even to someone who is not well > >> versed in SIP terminology. > >>=20 > >> The security considerations section claims that the considerations > >> are similar to those of the standards documents such as RFC 7667 > >> (RTP topologies) and RFC 7656 (A Taxonomy of Semantics and > >> Mechanisms for Real-Time Transport Protocol (RTP) Sources). This > >> seems reasonable. It also describes why encryption is not an issue > >> (if the B2BUA can make some changes to the media stream, then it > >> can also make the changes described in this document, otherwise, > >> it can=E2=80=99t make the original changes either), and how failing to > >> follow this document might be indistinguishable from an attack > >> (that=E2=80=99s the =E2=80=9Cbad things happen=E2=80=9D part) > >>=20 > >> Two nits: > >>=20 > >> - The Abstract says: =E2=80=9C[B2BUAs] are often envisaged to also be = on > >> the media path...This means that B2BUAs often implement an RTP/RTCP > >> stack...=E2=80=9D. That doesn=E2=80=99t make sense with the dictionary= definition > >> of =E2=80=9Cenvisage=E2=80=9D. Perhaps =E2=80=9Cdesigned=E2=80=9D? > >> =20 > >=20 > >=20 > > Fair point, we'll fix this in next version. > >=20 > > =20 > >> - The first paragraph of the Security Considerations is pasted > >> below. I don=E2=80=99t think there is much semantic difference between > >> "considerations" and =E2=80=9Caspects=E2=80=9D. This paragraph denies = that there > >> are considerations, and then goes on to state some. I think the > >> whole first paragraph can go. > >>=20 > >> Yoav > >> =20 > >=20 > >=20 > > What we wanted to stress out in this section is that we didn't have > > any specific behaviour to mandate in that sense, as other related > > documents do, but that we mostly wanted to underline some aspects > > to be wary of. I guess that a "Security Considerations" section can > > itself be even just about considerations, rather than rules, so I > > agree that it might be worthwhile to rephrase that first sentence > > to make what we meant clearer than it currently is. Do you think > > that something like > >=20 > > [..] does not specify any additional rule [..] > >=20 > > rather than > >=20 > > [..] does not introduce any additional consideration [..] =20 >=20 > Sure. Although dropping that paragraph would also work. >=20 > Yoav >=20 Thanks! I'll do that in the next version of the document, then. Lorenzo From nobody Wed Oct 12 00:22:45 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3441296E4; Wed, 12 Oct 2016 00:22:44 -0700 (PDT) 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 vdvb0yBEAM1y; Wed, 12 Oct 2016 00:22:41 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2E51296DF; Wed, 12 Oct 2016 00:22:41 -0700 (PDT) Received: from thinny.local (69-12-173-8.static.dsltransport.net [69.12.173.8]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by colo.trepanning.net (Postfix) with ESMTPSA id A67071FE0254; Wed, 12 Oct 2016 00:22:40 -0700 (PDT) To: Simon Josefsson References: <87fuosqtkh.fsf@latte.josefsson.org> <66a779c8-d87b-7c70-c7cf-7eabc48f9880@lounge.org> <20160924111622.6d1308ce@latte.josefsson.org> <69d90890-3c84-46e2-d1ef-0e264e28d568@lounge.org> <20161010081355.2a597c69@latte.josefsson.org> <1476083904.32538.17.camel@josefsson.org> <881e087e-c09e-7322-b700-95d1b7168a73@lounge.org> <1476175630.28753.16.camel@josefsson.org> From: Dan Harkins Message-ID: Date: Wed, 12 Oct 2016 00:22:39 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <1476175630.28753.16.camel@josefsson.org> Content-Type: multipart/mixed; boundary="------------853D315AE1FED3F64773D25A" Archived-At: Cc: draft-harkins-salted-eap-pwd.all@ietf.org, Stefan Winter , Kathleen Moriarty , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-harkins-salted-eap-pwd-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 07:22:44 -0000 This is a multi-part message in MIME format. --------------853D315AE1FED3F64773D25A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello, Please see the attached and comments below. On 10/11/16 1:47 AM, Simon Josefsson wrote: > mån 2016-10-10 klockan 08:58 -0700 skrev Dan Harkins: >> Hello, >> >> On 10/10/16 12:18 AM, Simon Josefsson wrote: >>> mån 2016-10-10 klockan 09:03 +0200 skrev Stefan Winter: >>>> Hello, >>>> >>>>> I still believe it is a bad idea to describe non-iterative password >>>>> protection schemes at all. We have had 15+ years of bad incidents with >>>>> salted password databases that suggest it is time to stop doing that. >>>> This is not the ocean this draft attempts to boil. >>>> >>>> The draft does not make any recommendations about how to store passwords. >>> Hello Stefan. >>> >>> Recommendations ought to be part of the security considerations. It >>> already is part of the document, to some extent. >>> >>>> It attempts to make password databases usable with a new EAP type. >>>> >>>> I don't think you are actually stating that salt-hash databases don't >>>> exist in massive amounts in deployed reality? Because saying so would be >>>> quite silly; they do exist. >>> Of course. I did not say that, and if you got that impression, I must >>> have been terribly unclear in what I wrote. >>> >>> I question whether deployed PRECIS/OpaqueString databases prepared >>> passwords salted+hashed with SHA1 exists. PRECIS/OpaqueString is fairly >>> new. My perception is that people who are knowledgeable enough to use >>> PRECIS/OpaqueString to prepare passwords in general also know that >>> salting passwords is not sufficient. >> But the draft doesn't specify OpaqueString with SHA1. > It used to, I see now that you removed it. Thank you! There is still > salt+SHA256 and salt+SHA512 though. Are they there for legacy reasons? > I think the draft ought to be clear on which algorithms are for legacy > reasons and which ones are recommended for security. OpaqueString > +PBKDF2 and OpaqueString+scrypt reflect two reasonable choices these > days. The others are for legacy reasons. There is a note in the Security Considerations regarding the forward-looking nature of scrypt and PBKDF2 and the rest are to support deployed databases. >>>> If we were to ignore that deployed reality and spec the draft merely >>>> around PBKDF2 and some, we'd have an EAP type supporting only a tiny >>>> fraction of password databases out there. All the rest of deployed >>>> reality is left without a good zero-knowledge EAP type and is remains >>>> stranded with "traditional" PKIX-style server validations with either a >>>> cleartext password or a lousy NT-Hash inside the TLS tunnel - which, as >>>> our experience in a world-scale EAP-based roaming consortium shows, >>>> means: no protection at all for many because end users ignore all >>>> certificate warnings given half a chance to. >>>> >>>> It is actually quite easy to improve security for virtually everybody >>>> using EAP: it's these few paragraphs in the draft which describe how to >>>> use salted databases. >>> I'm with you on the high-level discussion. So let's discuss details. >>> My assertions are: >>> >>> 1) Drafts dealing with password hashing should not ignore security >>> practices around password hashing. Supporting PBKDF2 is a hygiene >>> factor, scrypt gives bonus points. >> It does support PBKDF2 now. Yes, it does so under the guise of scrypt >> because the scrypt RFC indicates that as an option. Adding support for >> the other scrypt options would open up this draft to ugly negotiation. > I don't understand. PBKDF2 and scrypt or two completely different > algorithms. Yes, scrypt uses PBKDF2 internally, but that does not imply > that scrypt offer a PBKDF2 fallback variant. Fixed. >> I can get away with crypt() doing a myriad of stuff under the covers >> because it embeds the specific algorithm in the salt and all I need >> to do is say do crypt(). >> >> So does this draft not already pass the hygiene test and also get >> a single bonus point? > Unless I'm missing something, you need to separate scrypt from PBKDF2. > They aren't compatible. Fixed. > >>> 2) Complexity leads to reduced security. Is there legacy justification >>> for all variants of hashes specified in the document? Is there legacy >>> justification for both SASLprep and PRECIS/OpaqueString? >> I believe the answer to the first question is yes. That is the motivation >> for this draft. Regarding the second question, there is no legacy >> justification for OpaqueString but there is one for SASLprep, that's >> whey there's an option for SASLprep with SHA-1 but none for OpaqueString >> with SHA-1. > Okay thanks for clarifying! Are there deployed databases that uses > SASLprep and salt+SHA256 and salt+SHA512 respectively? > > My point here is that by having them in the draft, there is a risk that > people will chose it even in new deployments "just because it works". > If there is no deployed base, let's not give people rope to hang > themselves. I am a firm disbeliever in the ability of RFCs to influence behavior. Otherwise we would have had a global PKI back in the late 90s and this whole password stuff would be a sad joke today. The more we measure the rope we want to sell the less useful our product is. > >>> 3) I challenge that PRECIS/OpaqueString-prepared passwords are deployed >>> in a salted+hashed way but without iterative constructs. If you have >>> pointers to the opposite, for each of the specified hashes, I'm happy to >>> learn something new. >> I have no pointers but if that is your challenge that you should be >> happy that the draft supports OpaqueString-prepared passwords with >> SHA-256 and SHA-512-- i.e. no iterative constructs. > No, I would be happy with this case: > > 1) PRECIS/OpaqueString is specified for PBKDF2 and/or scrypt only. Done. > I would be okay with: > > 2) A pointer to some existing deployed legacy database that uses > OpaqueString+salt+SHA256/512. > > A situation where the draft specify OpaqueString+salt+SHA256/512 without > any proven legacy need for it is not okay in my mind. I'm sorry but I'm not going to go back and query operators again for what they want. This draft was written to deal with existing, deployed salted databases. And it has to support internationalization. >> It also supports >> OpaqueString-prepared passwords with scrypt/PBKDF2 with SHA-256 and SHA-512 >> so we should have all bases covered. > Right now the scrypt/PBKDF2 variant looks confused to me. They are two > different algorithms. Scrypt does not allow you to chose the hash. > PBKDF2 allows the choice, but then you should cite RFC 2898. Fixed. > >>> What do you think? >>> >>> I'm aware of password databases that use raw salt+hash on (unprepared) >>> UTF-8 encoded password strings. In my experience, that is more common >>> than salt+hash of SASLprep or PRECIS/OpaqueString passwords. The draft >>> does not discuss how the password is encoded for TBD1-TBD10, which seems >>> like another missing piece. >> It says: >> When using SASLprep a password SHALL be considered a "stored string" per >> [RFC3454] and unassigned code points are therefore prohibited. The >> output of SASLprep SHALL be the binary representation of the >> processed UTF-8 character string. Prohibted output and unassigned >> codepoints encountered in SASLprep pre-processing SHALL cause a >> failure of pre-processing, and the output SHALL NOT be used with EAP-pwd. >> >> For the non-internationalized EAP-pwd already says: >> The input password string SHALL be treated as an ASCII >> string or a hexadecimal string with no treatment or normalization >> performed. The output SHALL be the binary representation of the >> input string. >> >> I'm really not sure what changes are still needed in this draft. If >> there are, please tell me again. > Exactly. So if you re-read what I wrote, my point is that my perception > is that salt+hash'ed UTF8 passwords is not uncommon, and the draft does > not describe that variant. Tell me exactly what you want with suggested text please. The draft, and the RFC it updates does, indeed, say how the password is encoded for TBD1-10. Perhaps you could also provide a proven legacy need for whatever it is that you feel is missing. regards, Dan. --------------853D315AE1FED3F64773D25A Content-Type: text/plain; charset=UTF-8; name="draft-harkins-salted-eap-pwd-07.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-harkins-salted-eap-pwd-07.txt" CgoKCkludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgRC4gSGFya2lucwpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEhQIEVudGVycHJpc2UKVXBkYXRlczogUkZD NTkzMSAoaWYgYXBwcm92ZWQpICAgICAgICAgICAgICAgICAgICAgICAgICBPY3RvYmVyIDEy LCAyMDE2CkludGVuZGVkIHN0YXR1czogSW5mb3JtYXRpb25hbApFeHBpcmVzOiBBcHJpbCAx NSwgMjAxNwoKCiAgICAgICAgQWRkaW5nIFN1cHBvcnQgZm9yIFNhbHRlZCBQYXNzd29yZCBE YXRhYmFzZXMgdG8gRUFQLXB3ZAogICAgICAgICAgICAgICAgICAgIGRyYWZ0LWhhcmtpbnMt c2FsdGVkLWVhcC1wd2QtMDcKCkFic3RyYWN0CgogICBFQVAtcHdkIGlzIGFuIEVBUCBtZXRo b2QgdGhhdCB1c2VzIGEgc2hhcmVkIHBhc3N3b3JkIGZvcgogICBhdXRoZW50aWNhdGlvbiB1 c2luZyBhIHRlY2huaXF1ZSB0aGF0IGlzIHJlc2lzdGFudCB0byBkaWN0aW9uYXJ5CiAgIGF0 dGFjay4gIEl0IGluY2x1ZGVkIHN1cHBvcnQgZm9yIHJhdyBrZXlzIGFuZCBbUkZDMjc1OV0t c3R5bGUgZG91YmxlCiAgIGhhc2hpbmcgb2YgYSBwYXNzd29yZCBidXQgZGlkIG5vdCBpbmNs dWRlIHN1cHBvcnQgZm9yIHNhbHRlZAogICBwYXNzd29yZHMuICBUaGVyZSBhcmUgbWFueSBl eGlzdGluZyBkYXRhYmFzZXMgb2Ygc2FsdGVkIHBhc3N3b3JkcyBhbmQKICAgaXQgaXMgZGVz aXJhYmxlIHRvIGFsbG93IHRoZWlyIHVzZSB3aXRoIEVBUC1wd2QuCgpTdGF0dXMgb2YgVGhp cyBNZW1vCgogICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBmdWxsIGNv bmZvcm1hbmNlIHdpdGggdGhlCiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzku CgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRl cm5ldCBFbmdpbmVlcmluZwogICBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhl ciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQogICB3b3JraW5nIGRvY3VtZW50cyBhcyBJ bnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LQogICBEcmFm dHMgaXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly4K CiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1h eGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBv ciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMg aW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBt YXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVz cy4iCgogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIEFwcmlsIDE1LCAy MDE3LgoKQ29weXJpZ2h0IE5vdGljZQoKICAgQ29weXJpZ2h0IChjKSAyMDE2IElFVEYgVHJ1 c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlCiAgIGRvY3VtZW50IGF1dGhv cnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLgoKICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0 IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbAogICBQcm92aXNpb25zIFJl bGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzCiAgIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9s aWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZgogICBwdWJsaWNhdGlvbiBv ZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMKICAgY2Fy ZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMg d2l0aCByZXNwZWN0CiAgIHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0 cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0CiAgIGluY2x1ZGUgU2ltcGxpZmllZCBC U0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZgoKCgpIYXJr aW5zICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAxNSwgMjAxNyAgICAgICAgICAg ICAgICAgW1BhZ2UgMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgQWJicmV2aWF0 ZWQgVGl0bGUgICAgICAgICAgICAgICBPY3RvYmVyIDIwMTYKCgogICB0aGUgVHJ1c3QgTGVn YWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMKICAg ZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLgoKVGFibGUgb2YgQ29u dGVudHMKCiAgIDEuICBJbnRyb2R1Y3Rpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMgogICAgIDEuMS4gIEJhY2tncm91bmQgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDIKICAgICAxLjIu ICBLZXl3b3JkIERlZmluaXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gICAzCiAgIDIuICBTYWx0ZWQgUGFzc3dvcmRzIGluIEVBUC1wd2QgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMwogICAgIDIuMS4gIFBhc3N3b3JkIFByZS1Q cm9jZXNzaW5nIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDMKICAgICAy LjIuICBUaGUgU2FsdGluZyBvZiBhIFBhc3N3b3JkIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gICA0CiAgICAgMi4zLiAgVXNpbmcgVU5JWCBjcnlwdCAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNQogICAgIDIuNC4gIFVzaW5nIHNjcnlw dCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUKICAg ICAyLjUuICBVc2luZyBQQktERjIgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gICA2CiAgICAgMi42LiAgUHJvdG9jb2wgTW9kaWZpY2F0aW9ucyAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNgogICAgIDIuNy4gIFBheWxvYWQg TW9kaWZpY2F0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDcK ICAgMy4gIEFja25vd2xlZGdlbWVudHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gICA4CiAgIDQuICBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgOAogICA1LiAgU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg IDgKICAgNi4gIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gICA5CiAgICAgNi4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgOQogICAgIDYuMi4gIElu Zm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgIDkKICAgQXV0aG9yJ3MgQWRkcmVzcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEwCgoxLiAgSW50cm9kdWN0aW9uCgoxLjEuICBCYWNr Z3JvdW5kCgogICBEYXRhYmFzZXMgb2Ygc3RvcmVkIHBhc3N3b3JkcyBwcmVzZW50IGFuIGF0 dHJhY3RpdmUgdGFyZ2V0IGZvcgogICBhdHRhY2stLWdldCBhY2Nlc3MgdG8gdGhlIGRhdGFi YXNlLCBsZWFybiB0aGUgcGFzc3dvcmRzLiAgVG8gY29uZm91bmQKICAgc3VjaCBhdHRhY2tz IGEgcmFuZG9tICJzYWx0IiB3YXMgaGFzaGVkIHdpdGggdGhlIHBhc3N3b3JkIGFuZCB0aGUK ICAgcmVzdWx0aW5nIGRpZ2VzdCBzdG9yZWQsIGFsb25nIHdpdGggdGhlIHNhbHQsIGluc3Rl YWQgb2YgdGhlIHJhdwogICBwYXNzd29yZC4gIFRoaXMgaGFzIHRoZSBlZmZlY3Qgb2YgcmFu ZG9taXppbmcgdGhlIHBhc3N3b3JkIHNvIGlmIHR3bwogICBkaXN0aW5jdCB1c2VycyBoYXZl IGNob3NlbiB0aGUgc2FtZSBwYXNzd29yZCB0aGUgc3RvcmVkLCBhbmQgc2FsdGVkLAogICBw YXNzd29yZCB3aWxsIGJlIGRpZmZlcmVudC4gIEl0IGFsc28gcmVxdWlyZXMgYW4gYWR2ZXJz YXJ5IHdobyBoYXMKICAgY29tcHJvbWlzZWQgdGhlIHNlY3VyaXR5IG9mIHRoZSBzdG9yZWQg ZGF0YWJhc2UgdG8gbGF1bmNoIGEKICAgZGljdGlvbmFyeSBhdHRhY2sgcGVyIGVudHJ5IHRv IHJlY292ZXIgcGFzc3dvcmRzLgoKICAgRGljdGlvbmFyeSBhdHRhY2tzLCBlc3BlY2lhbGx5 IHVzaW5nIGN1c3RvbSBoYXJkd2FyZSwgcmVwcmVzZW50IHJlYWwtCiAgIHdvcmxkIGF0dGFj a3MgYW5kIG1lcmVseSBzYWx0aW5nIGEgcGFzc3dvcmQgaXMgaW5zdWZmaWNpZW50IHRvCiAg IHByb3RlY3QgYSBwYXNzd29yZCBkYXRhYmFzZS4gIFRvIGFkZHJlc3MgdGhlc2UgYXR0YWNr cyBhbiBzZXF1ZW50aWFsCiAgIG1lbW9yeSBoYXJkIGZ1bmN0aW9uIHN1Y2ggYXMgZGVzY3Jp YmVkIGluIFtSRkM3OTE0XSBpcyB1c2VkLgoKICAgV2hpbGUgc2FsdGluZyBhIHBhc3N3b3Jk IGRhdGFiYXNlIGlzIG5vdCBzdWZmaWNpZW50IHRvIGRlYWwgd2l0aCBtYW55CiAgIHJlYWwt d29ybGQgYXR0YWNrcyB0aGUgaGlzdG9yaWMgcG9wdWxhcml0eSBvZiBwYXNzd29yZCBzYWx0 aW5nIG1lYW5zCiAgIHRoZXJlIGFyZSBhIGxhcmdlIG51bWJlciBvZiBzdWNoIGRhdGFiYXNl cyBkZXBsb3llZCBhbmQgRUFQLXB3ZCBuZWVkcwogICB0byBiZSBhYmxlIHRvIHN1cHBvcnQg dGhlbS4gIEluIGFkZGl0aW9uLCBFQVAtcHdkIG5lZWRzIHRvIGJlIGFibGUgdG8KCgoKCkhh cmtpbnMgICAgICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDE1LCAyMDE3ICAgICAgICAg ICAgICAgICBbUGFnZSAyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBBYmJyZXZp YXRlZCBUaXRsZSAgICAgICAgICAgICAgIE9jdG9iZXIgMjAxNgoKCiAgIHN1cHBvcnQgZGF0 YWJhc2VzIHVzaW5nIG1vcmUgbW9kZXJuIHNlcXVlbnRpYWwgbWVtb3J5IGhhcmQgZnVuY3Rp b25zCiAgIGZvciBwcm90ZWN0aW9uLgoKICAgRUFQLXB3ZCBpbXBvc2VzIGFuIGFkZGl0aW9u YWwgc2VjdXJpdHkgcmVxdWlyZW1lbnQgb24gYSBkYXRhYmFzZSBvZgogICBzYWx0ZWQgcGFz c3dvcmRzIHRoYXQgb3RoZXJ3aXNlIHdvdWxkIG5vdCBleGlzdCwgc2VlIFNlY3Rpb24gNS4K CjEuMi4gIEtleXdvcmQgRGVmaW5pdGlvbgoKICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJN VVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLAogICAiU0hPVUxE IiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIg aW4gdGhpcwogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVk IGluIFJGQyAyMTE5IFtSRkMyMTE5XS4KCjIuICBTYWx0ZWQgUGFzc3dvcmRzIGluIEVBUC1w d2QKCjIuMS4gIFBhc3N3b3JkIFByZS1Qcm9jZXNzaW5nCgogICBFQVAtcHdkIGlzIGJhc2Vk IG9uIHRoZSAiZHJhZ29uZmx5IiBwYXNzd29yZC1hdXRoZW50aWNhdGVkIGtleQogICBleGNo YW5nZSAoUEFLRSktLXNlZSBbUkZDNzY2NF0uICBUaGlzIGlzIGEgYmFsYW5jZWQgUEFLRSBh bmQgcmVxdWlyZXMKICAgdGhhdCBlYWNoIHBhcnR5IHRvIHRoZSBwcm90b2NvbCBvYnRhaW4g YW4gaWRlbnRpY2FsIHJlcHJlc2VudGF0aW9uIG9mCiAgIGEgcHJvY2Vzc2VkIHBhc3N3b3Jk IChzZWUgU2VjdGlvbiA1KS4gIFNhbHRpbmcgb2YgYSBwYXNzd29yZCBpcwogICB0aGVyZWZv cmUgdHJlYXRlZCBhcyBhbiBhZGRpdGlvbmFsIHBhc3N3b3JkIHByZS1wcm9jZXNzaW5nIHRl Y2huaXF1ZQogICBvZiBFQVAtcHdkLiAgVGhlIHNhbHQgYW5kIGRpZ2VzdCB0byB1c2UgaXMg Y29udmV5ZWQgdG8gdGhlIHBlZXIgYnkKICAgdGhlIHNlcnZlciBhbmQgdGhlIHBhc3N3b3Jk IGlzIHByb2Nlc3NlZCBwcmlvciB0byBmaXhpbmcgdGhlIHBhc3N3b3JkCiAgIGVsZW1lbnQg KHNlZSBTZWN0aW9uIDIuOC4zIG9mIFtSRkM1OTMxXSkuCgogICBUaGlzIG1lbW8gZGVmaW5l cyBlaWdodCAoOCkgbmV3IHBhc3N3b3JkIHByZS1wcm9jZXNzaW5nIHRlY2huaXF1ZXMKICAg Zm9yIEVBUC1wd2Q6CgogICBvICBUQkQxOiBhIHJhbmRvbSBzYWx0IHdpdGggU0hBLTEgKFtT SFNdKQoKICAgbyAgVEJEMjogYSByYW5kb20gc2FsdCB3aXRoIFNIQS0yNTYgKFtTSFNdKQoK ICAgbyAgVEJEMzogYSByYW5kb20gc2FsdCB3aXRoIFNIQS01MTIgKFtTSFNdKQoKICAgbyAg VEJENDogVU5JWCBjcnlwdCgpIChbQ1JZXSkKCiAgIG8gIFRCRDU6IHNjcnlwdCAoW1JGQzc5 MTRdKQoKICAgbyAgVEJENjogUEJLREYyIHdpdGggU0hBLTI1NiAoW1JGQzI4OThdKQoKICAg byAgVEJENzogUEJLREYyIHdpdGggU0hBLTUxMiAoW1JGQzI4OThdKQoKICAgbyAgVEJEODog U0FTTHByZXAgdGhlbiBhIHJhbmRvbSBzYWx0IHdpdGggU0hBLTEgKFtTSFNdKQoKICAgbyAg VEJEOTogU0FTTHByZXAgdGhlbiBhIHJhbmRvbSBzYWx0IHdpdGggU0hBLTI1NiAoW1NIU10p CgogICBvICBUQkQxMDogU0FTTHByZXAgdGhlbiBhIHJhbmRvbSBzYWx0IHdpdGggU0hBLTUx MiAoW1NIU10pCgoKCgpIYXJraW5zICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAx NSwgMjAxNyAgICAgICAgICAgICAgICAgW1BhZ2UgM10KDApJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgQWJicmV2aWF0ZWQgVGl0bGUgICAgICAgICAgICAgICBPY3RvYmVyIDIwMTYK CgogICBvICBUQkQxMTogU0FTTHByZXAgdGhlbiBVTklYIGNyeXB0KCkgKFtDUlldKQoKICAg byAgVEJEMTI6IE9wYXF1ZVN0cmluZyB0aGVuIHNjcnlwdCAoW1JGQzc5MTRdKQoKICAgbyAg VEJEMTM6IE9wYXF1ZVN0cmluZyB0aGVuIFBCS0RGMiB3aXRoIFNIQS0yNTYgKFtSRkMyODk4 XSkKCiAgIG8gIFRCRDE0OiBPcGFxdWVTdHJpbmcgdGhlbiBQQktERjIgd2l0aCBTSEEtNTEy IChbUkZDMjg5OF0pCgogICBXaGVuIHBhc3Npbmcgc2FsdCwgdGhlIHNpemUgb2YgdGhlIHNh bHQgU0hPVUxEIGJlIGF0IGxlYXN0IGFzIGxvbmcgYXMKICAgdGhlIG1lc3NhZ2UgZGlnZXN0 IG9mIHRoZSBoYXNoIGFsZ29yaXRobSB1c2VkLiAgVGhlcmUgaXMgbm8gZ3VhcmFudGVlCiAg IHRoYXQgZGVwbG95ZWQgc2FsdGVkIGRhdGFiYXNlcyBoYXZlIGZvbGxvd2VkIHRoaXMgcnVs ZSwgYW5kIGluIHRoZQogICBpbnRlcmVzdCBvZiBpbnRlcm9wZXJhYmlsaXR5LCBhbiBFQVAg cGVlciBTSE9VTEQgTk9UIGFib3J0IGFuIEVBUC1wd2QKICAgZXhjaGFuZ2UgaWYgdGhlIGxl bmd0aCBvZiB0aGUgc2FsdCBjb252ZXllZCBkdXJpbmcgdGhlIGV4Y2hhbmdlIGlzCiAgIGxl c3MgdGhhbiB0aGUgbWVzc2FnZSBkaWdlc3Qgb2YgdGhlIGluZGljYXRlZCBoYXNoIGFsZ29y aXRobS4KCiAgIFVOSVggY3J5cHQoKSwgc2NyeXB0LCBhbmQgUEJLREYyIGltcG9zZSBhZGRp dGlvbmFsIGZvcm1hdHRpbmcKICAgcmVxdWlyZW1lbnRzIG9uIHRoZSBwYXNzZWQgc2FsdC4g IFNlZSBiZWxvdy4KCiAgIFNBU0xwcmVwIGhhcyBiZWVuIGRlcHJlY2F0ZWQgYnV0IGRhdGFi YXNlcyB0cmVhdGVkIHdpdGggU0FTTHByZXAKICAgZXhpc3QgYW5kIGl0IGlzIG5lY2Vzc2Fy eSB0byBwcm92aWRlIGNvZGUgcG9pbnRzIGZvciB0aGVtLiAgV2hlbgogICB1c2luZyBTQVNM cHJlcCBhIHBhc3N3b3JkIFNIQUxMIGJlIGNvbnNpZGVyZWQgYSAic3RvcmVkIHN0cmluZyIg cGVyCiAgIFtSRkMzNDU0XSBhbmQgdW5hc3NpZ25lZCBjb2RlIHBvaW50cyBhcmUgdGhlcmVm b3JlIHByb2hpYml0ZWQuICBUaGUKICAgb3V0cHV0IG9mIFNBU0xwcmVwIFNIQUxMIGJlIHRo ZSBiaW5hcnkgcmVwcmVzZW50YXRpb24gb2YgdGhlCiAgIHByb2Nlc3NlZCBVVEYtOCBjaGFy YWN0ZXIgc3RyaW5nLiAgUHJvaGlidGVkIG91dHB1dCBhbmQgdW5hc3NpZ25lZAogICBjb2Rl cG9pbnRzIGVuY291bnRlcmVkIGluIFNBU0xwcmVwIHByZS1wcm9jZXNzaW5nIFNIQUxMIGNh dXNlIGEKICAgZmFpbHVyZSBvZiBwcmUtcHJvY2Vzc2luZywgYW5kIHRoZSBvdXRwdXQgU0hB TEwgTk9UIGJlIHVzZWQgd2l0aCBFQVAtCiAgIHB3ZC4KCiAgIFdoZW4gcGVyZm9ybWluZyBv bmUgb2YgVEJEMTItVEJEMTQgdGhlIHBhc3N3b3JkIFNIQUxMIGJlIGEgVVRGLTgKICAgc3Ry aW5nIGFuZCBTSEFMTCBiZSBwcmUtcHJvY2Vzc2VkIGJ5IGFwcGx5aW5nIHRoZSBQcmVwYXJh dGlvbiBhbmQKICAgRW5mb3JjZW1lbnQgc3RlcHMgb2YgdGhlIE9wYXF1ZVN0cmluZyBwcm9m aWxlIGluIFtSRkM3NjEzXSB0byB0aGUKICAgcGFzc3dvcmQuICBUaGUgb3V0cHV0IG9mIE9w YXF1ZVN0cmluZywgYWxzbyBhIFVURi04IHN0cmluZywgYmVjb21lcwogICB0aGUgRUFQLXB3 ZCBwYXNzd29yZCBhbmQgU0hBTEwgYmUgaGFzaGVkIHdpdGggdGhlIGluZGljYXRlZAogICBh bGdvcml0aG0uCgogICBUaGVyZSBpcyBhIGxhcmdlIG51bWJlciBvZiBkZXBsb3llZCBwYXNz d29yZCBkYXRhYmFzZXMgdGhhdCB1c2UKICAgW1JGQzc2MTZdLXN0eWxlIHNhbHRpbmcgYW5k IGhhc2hpbmcgYnV0IHRoZXNlIGRlcGxveW1lbnRzIHJlcXVpcmUgYQogICBub25jZSBjb250 cmlidXRpb24gYnkgdGhlIGNsaWVudCAoYXMgd2VsbCBhcyB0aGUgc2VydmVyKSBhbmQgRUFQ LXB3ZAogICBkb2VzIG5vdCBoYXZlIHRoZSBjYXBhYmlsaXR5IHRvIHByb3ZpZGUgdGhhdCBp bmZvcm1hdGlvbi4KCjIuMi4gIFRoZSBTYWx0aW5nIG9mIGEgUGFzc3dvcmQKCiAgIEZvciBi b3RoIHBhcnRpZXMgdG8gZGVyaXZlIHRoZSBzYW1lIHNhbHRlZCBwYXNzd29yZCB0aGVyZSBu ZWVkcyB0byBiZQogICBhIGNhbm9uaWNhbCBtZXRob2Qgb2Ygc2FsdGluZyBhIHBhc3N3b3Jk LiAgV2hlbiB1c2luZyBFQVAtcHdkLCBhCiAgIHBhc3N3b3JkIFNIQUxMIGJlIHNhbHRlZCBi eSBoYXNoaW5nIHRoZSBwYXNzd29yZCBmb2xsb3dlZCBieSB0aGUgc2FsdAogICB1c2luZyB0 aGUgZGVzaWduYXRlZCBoYXNoIGZ1bmN0aW9uOgoKICAgICAgc2FsdGVkLXBhc3N3b3JkID0g SGFzaChwYXNzd29yZCB8IHNhbHQpCgoKCkhhcmtpbnMgICAgICAgICAgICAgICAgICBFeHBp cmVzIEFwcmlsIDE1LCAyMDE3ICAgICAgICAgICAgICAgICBbUGFnZSA0XQoMCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICBBYmJyZXZpYXRlZCBUaXRsZSAgICAgICAgICAgICAgIE9j dG9iZXIgMjAxNgoKCiAgIFRoZSBzZXJ2ZXIgc3RvcmVzIHRoZSBzYWx0ZWQtcGFzc3dvcmQs IGFuZCB0aGUgc2FsdCwgaW4gaXRzIGRhdGFiYXNlCiAgIGFuZCB0aGUgY2xpZW50IGRlcml2 ZXMgdGhlIHNhbHRlZC1wYXNzd29yZCBvbi10aGUtZmx5LgoKMi4zLiAgVXNpbmcgVU5JWCBj cnlwdAoKICAgRGlmZmVyZW50IGFsZ29yaXRobXMgYXJlIHN1cHBvcnRlZCB3aXRoIHRoZSBV TklYIGNyeXB0KCkgZnVuY3Rpb24uCiAgIFRoZSBwYXJ0aWN1bGFyIGFsZ29yaXRobSB1c2Vk IGlzIGluZGljYXRlZCBieSBwcmVwZW5kaW5nIGFuIGVuY29kaW5nCiAgIG9mICJzZXR0aW5n IiB0byB0aGUgcGFzc2VkIHNhbHQuICBUaGUgc3BlY2lmaWMgYWxnb3JpdGhtIHVzZWQgaXMK ICAgb3BhcXVlIHRvIEVBUC1wd2QgYXMgdGhlIGVudGlyZSBzYWx0LCBpbmNsdWRpbmcgdGhl IGVuY29kZWQKICAgInNldHRpbmciLCBpcyBwYXNzZWQgYXMgYW4gb3BhcXVlIHN0cmluZyBm b3IgaW50ZXJwcmV0YXRpb24gYnkKICAgY3J5cHQoKS4gIFRoZSBzYWx0ZWQgcGFzc3dvcmQg dXNlZCBmb3IgRUFQLXB3ZCBTSEFMTCBiZSB0aGUgb3V0cHV0IG9mCiAgIGNyeXB0KCk6Cgog ICAgICBzYWx0ZWQtcGFzc3dvcmQgPSBjcnlwdChwYXNzd29yZCwgc2FsdCkKCiAgIFRoZSBz ZXJ2ZXIgc3RvcmVzIHRoZSBzYWx0ZWQtcGFzc3dvcmQsIGFuZCB0aGUgZW5jb2RlZCBhbGdv cml0aG0gcGx1cwogICBzYWx0LCBpbiBpdHMgZGF0YWJhc2UgYW5kIHRoZSBjbGllbnQgZGVy aXZlcyB0aGUgc2FsdGVkLXBhc3N3b3JkIG9uLQogICB0aGUtZmx5LgoKICAgSWYgdGhlIHNl cnZlciBpbmRpY2F0ZXMgYSBjcnlwdCgpIGFsZ29yaXRobSB0aGF0IGlzIHVuc3VwcG9ydGVk IGJ5CiAgIHRoZSBjbGllbnQsIHRoZSBleGNoYW5nZSBmYWlscyBhbmQgdGhlIGNsaWVudCBN VVNUIHRlcm1pbmF0ZSB0aGUKICAgY29ubmVjdGlvbi4KCjIuNC4gIFVzaW5nIHNjcnlwdAoK ICAgVGhlIHNjcnlwdCBmdW5jdGlvbiB0YWtlcyBzZXZlcmFsIHBhcmFtZXRlcnM6CgogICBv ICBOLCB0aGUgY29zdCBwYXJhbWV0ZXIKCiAgIG8gIHIsIHRoZSBibG9jayBzaXplCgogICBv ICBwLCB0aGUgcGFyYWxsZWxpemF0aW9uIHBhcmFtZXRlcgoKICAgbyAgZGtMZW4sIHRoZSBs ZW5ndGggb2YgdGhlIG91dHB1dAoKICAgVGhlc2UgcGFyYW1ldGVycyBhcmUgZW5jb2RlZCBp bnRvIHRoZSAic2FsdCIgZmllbGQgb2YgdGhlIG1vZGlmaWVkCiAgIEVBUC1wd2QgbWVzc2Fn ZS4gIFBhcmFtZXRlcnMgciBhbmQgZGtMZW4gU0hBTEwgYmUgMTYtYml0IGludGVnZXJzIGlu CiAgIG5ldHdvcmsgb3JkZXIuICBUaGUgb3RoZXIgcGFyYW1ldGVycyBTSEFMTCBlYWNoIGJl IDMyLWJpdCBpbnRlZ2VycyBpbgogICBuZXR3b3JrIG9yZGVyLiAgVGhlICJzYWx0IiBmaWVs ZCB0aGF0IGdldHMgdHJhbnNtaXR0ZWQgaW4gRUFQLXB3ZAogICBTSEFMTCB0aGVyZWZvcmUg YmU6CgogICAgICBOIHx8IHIgfHwgcCB8fCBka0xlbiB8fCBzYWx0CgogICB3aGVyZSB8fCBy ZXByZXNlbnRzIGNvbmNhdGVuYXRpb24uCgogICBUaGUgdmFsdWUgb2YgTiByZXByZXNlbnRz IHRoZSBleHBvbmVudCB0YWtlbiB0byB0aGUgcG93ZXIgb2YgdHdvIGluCiAgIG9yZGVyIHRv IGRldGVybWluZSB0aGUgQ1BVL01lbW9yeSBjb3N0IG9mIHNjcnlwdC0tIGkuZS4gdGhlIHZh bHVlIGlzCiAgIDJeTi4gIFBlciBbUkZDNzkxNF0gdGhlIHJlc3VsdGluZyBDUFUvTWVtb3J5 IGNvc3QgdmFsdWUgU0hBTEwgYmUgbGVzcwoKCgpIYXJraW5zICAgICAgICAgICAgICAgICAg RXhwaXJlcyBBcHJpbCAxNSwgMjAxNyAgICAgICAgICAgICAgICAgW1BhZ2UgNV0KDApJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgQWJicmV2aWF0ZWQgVGl0bGUgICAgICAgICAgICAg ICBPY3RvYmVyIDIwMTYKCgogICB0aGFuIDJeKDEyOCAqIHIgLyA4KSBhbmQgdGhlIHZhbHVl IHAgU0hBTEwgYmUgbGVzcyB0aGFuIG9yIGVxdWFsIHRvCiAgICgoMl4zMiAtIDEpICogMzIp IC8gKDEyOCAqIHIpLgoKICAgTm90ZTogRUFQLXB3ZCB1c2VzIHRoZSBzYWx0ZWQgcGFzc3dv cmQgZGlyZWN0bHkgYXMgdGhlIGF1dGhlbnRpY2F0aW9uCiAgIGNyZWRlbnRpYWwgYW5kIHdp bGwgaGFzaCBpdCB3aXRoIGEgY291bnRlciBpbiBvcmRlciB0byBvYnRhaW4gYQogICBzZWNy ZXQgZWxlbWVudCBpbiBhIGZpbml0ZSBmaWVsZC4gIFRoZXJlZm9yZSBpdCBtYWtlcyBsaXR0 bGUgc2Vuc2UgdG8KICAgdXNlIGRrTGVuIGdyZWF0ZXIgdGhhbiB0aGUgZGlnZXN0IG9mIHRo ZSB1bmRlcmx5aW5nIGhhc2ggZnVuY3Rpb24gYnV0CiAgIHRoZSBjYXBhYmlsaXR5IGlzIHBy b3ZpZGVkIHRvIGRvIHNvIGFueXdheS4KCjIuNS4gIFVzaW5nIFBCS0RGMgoKICAgVGhlIFBC S0RGMiBmdW5jdGlvbiByZXF1aXJlcyB0d28gcGFyYW1ldGVyczoKCiAgIG8gIGMsIHRoZSBp dGVyYXRpb24gY291bnQKCiAgIG8gIGRrTGVuLCB0aGUgbGVuZ3RoIG9mIHRoZSBvdXRwdXQK CiAgIFRoZXNlIHBhcmFtZXRlcnMgYXJlIGVuY29kZWQgaW50byB0aGUgInNhbHQiIGZpZWxk IG9mIHRoZSBtb2RpZmllZAogICBFQVAtcHdkIG1lc3NhZ2UuICBUaGUgcGFyYW1ldGVycyBT SEFMTCBiZSAxNi1iaXQgaW50ZWdlcnMgaW4gbmV0d29yawogICBvcmRlci4gIFRoZSAic2Fs dCIgZmllbGQgdGhhdCBnZXRzIHRyYW5zbWl0dGVkIGluIEVBUC1wd2QgU0hBTEwKICAgdGhl cmVmb3JlIGJlOgoKICAgICAgYyB8fCBka0xlbiB8fCBzYWx0CgogICB3aGVyZSB8fCByZXBy ZXNlbnRzIGNvbmNhdGVuYXRpb24uCgogICBOb3RlOiBFQVAtcHdkIHVzZXMgdGhlIHNhbHRl ZCBwYXNzd29yZCBkaXJlY3RseSBhcyB0aGUgYXV0aGVudGljYXRpb24KICAgY3JlZGVudGlh bCBhbmQgd2lsbCBoYXNoIGl0IHdpdGggYSBjb3VudGVyIGluIG9yZGVyIHRvIG9idGFpbiBh CiAgIHNlY3JldCBlbGVtZW50IGluIGEgZmluaXRlIGZpZWxkLiAgVGhlcmVmb3JlIGl0IG1h a2VzIGxpdHRsZSBzZW5zZSB0bwogICB1c2UgZGtMZW4gZ3JlYXRlciB0aGFuIHRoZSBkaWdl c3Qgb2YgdGhlIHVuZGVybHlpbmcgaGFzaCBmdW5jdGlvbiBidXQKICAgdGhlIGNhcGFiaWxp dHkgaXMgcHJvdmlkZWQgdG8gZG8gc28gYW55d2F5LgoKMi42LiAgUHJvdG9jb2wgTW9kaWZp Y2F0aW9ucwoKICAgTGlrZSBhbGwgRUFQIG1ldGhvZHMsIEVBUC1wd2QgaXMgc2VydmVyIGlu aXRpYXRlZC4gIFRoZSBzZXJ2ZXIgaXMKICAgcmVxdWlyZWQgdG8gaW5kaWNhdGUgaXRzIGlu dGVudGlvbnMsIGluY2x1ZGluZyB0aGUgcGFzc3dvcmQgcHJlLQogICBwcm9jZXNzaW5nIGl0 IHdpc2hlcyB0byB1c2UsIGJlZm9yZSBpdCBrbm93cyB0aGUgaWRlbnRpdHkgb2YgdGhlCiAg IGNsaWVudC4gIFRoaXMgbGltaXRzIHRoZSBhYmlsaXR5IG9mIHRoZSBzZXJ2ZXIgdG8gc3Vw cG9ydCBtdWx0aXBsZQogICBzYWx0IGRpZ2VzdHMgc2ltdWx0YW5lb3VzbHkgaW4gYSBzaW5n bGUgcGFzc3dvcmQgZGF0YWJhc2UuICBUbwogICBzdXBwb3J0IG11bHRpcGxlIHNhbHQgZGln ZXN0cyBzaW11bHRhbmVvdXNseSwgaXQgaXMgbmVjZXNzYXJ5IHRvCiAgIG1haW50YWluIG11 bHRpcGxlIHBhc3N3b3JkIGRhdGFiYXNlcyBhbmQgdXNlIHRoZSByb3V0YWJsZSBwb3J0aW9u IG9mCiAgIHRoZSBjbGllbnQgaWRlbnRpdHkgdG8gc2VsZWN0IG9uZSB3aGVuIGluaXRpYXRp bmcgRUFQLXB3ZC4KCiAgIFRoZSBzZXJ2ZXIgdXNlcyB0aGUgRUFQLXB3ZC1JRC9SZXF1ZXN0 IHRvIGluZGljYXRlIHRoZSBwYXNzd29yZCBwcmUtCiAgIHByb2Nlc3NpbmcgdGVjaG5pcXVl LiAgVGhlIGNsaWVudCBpbmRpY2F0ZXMgaXRzIGFjY2VwdGFuY2Ugb2YgdGhlCiAgIHBhc3N3 b3JkIHByZS1wcm9jZXNzaW5nIHRlY2huaXF1ZSBhbmQgaWRlbnRpZmllcyBpdHNlbGYgaW4g dGhlIEVBUC0KICAgcHdkLUlEL1Jlc3BvbnNlLiAgVXBvbiByZWNlaXB0IG9mIHRoZSBFQVAt cHdkLUlEL1Jlc3BvbnNlLCB0aGUgc2VydmVyCiAgIGtub3dzIHRoZSBpZGVudGl0eSBvZiB0 aGUgY2xpZW50IGFuZCBjYW4gbG9vayB1cCB0aGUgY2xpZW50J3Mgc2FsdGVkCgoKCkhhcmtp bnMgICAgICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDE1LCAyMDE3ICAgICAgICAgICAg ICAgICBbUGFnZSA2XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBBYmJyZXZpYXRl ZCBUaXRsZSAgICAgICAgICAgICAgIE9jdG9iZXIgMjAxNgoKCiAgIHBhc3N3b3JkIGFuZCB0 aGUgc2FsdCBmcm9tIHRoZSBkYXRhYmFzZS4gIFRoZSBzZXJ2ZXIgYWRkcyB0aGUgbGVuZ3Ro CiAgIG9mIHRoZSBzYWx0IGFuZCB0aGUgc2FsdCBpdHNlbGYgdG8gdGhlIEVBUC1wd2QtQ29t bWl0L1JlcXVlc3QgbWVzc2FnZQogICAoc2VlIFNlY3Rpb24gMi43KS4KCiAgIFRoZSBzZXJ2 ZXIgY2FuIGZpeCB0aGUgcGFzc3dvcmQgZWxlbWVudCAoU2VjdGlvbiAyLjguMyBvZiBbUkZD NTkzMV0pCiAgIGFzIHNvb24gYXMgdGhlIHNhbHRlZCBwYXNzd29yZCBoYXMgYmVlbiBsb29r ZWQgdXAgaW4gdGhlIGRhdGFiYXNlLgogICBUaGUgY2xpZW50LCB0aG91Z2gsIGlzIHJlcXVp cmVkIHRvIHdhaXQgdW50aWwgcmVjZWlwdCBvZiB0aGUgc2VydmVyJ3MKICAgRUFQLXB3ZC1D b21taXQvUmVxdWVzdCBiZWZvcmUgaXQgYmVnaW5zIGZpeGluZyB0aGUgcGFzc3dvcmQgZWxl bWVudC4KCjIuNy4gIFBheWxvYWQgTW9kaWZpY2F0aW9ucwoKICAgV2hlbiBhIHNhbHRlZCBw YXNzd29yZCBwcmUtcHJvY2Vzc2luZyB0ZWNobmlxdWUgaXMgYWdyZWVkIHVwb24gZHVyaW5n CiAgIHRoZSBFQVAtcHdkLUlEIGV4Y2hhbmdlIHRoZSBFQVAtcHdkLUNvbW1pdCBwYXlsb2Fk IGlzIG1vZGlmaWVkIHRvCiAgIGluY2x1ZGUgdGhlIHNhbHQgYW5kIHNhbHQgbGVuZ3RoIChz ZWUgRmlndXJlIDEpLiAgVGhlIHNlcnZlciBwYXNzZXMKICAgdGhlIHNhbHQgYW5kIHNhbHQg bGVuZ3RoIGluIHRoZSBFQVAtcHdkLUNvbW1pdC9SZXF1ZXN0OyB0aGUgY2xpZW50J3MKICAg RUFQLXB3ZC1Db21taXQvUmVzcG9uc2UgaXMgdW5jaGFuZ2VkIGFuZCBpdCBNVVNUIE5PVCBl Y2hvIHRoZSBzYWx0CiAgIGxlbmd0aCBhbmQgc2FsdCBpbiBpdHMgRUFQLXB3ZC1Db21taXQv UmVzcG9uc2UuCgogICAgICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAg ICAgIDIgICAgICAgICAgICAgICAgICAgMwogICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAw IDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxCiAgICAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rCiAgICAgIHwgICBzYWx0LWxlbiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICstKy0rLSstKy0rLSstKy0rICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB+CiAgICAgIH4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgU2FsdCAgICAgICAgICAgICArLSstKy0rLSstKy0r LSstKy0rCiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICB8CiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rICAgICAgICAgICAgICAgICB+CiAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8CiAgICAgIH4gICAgICAgICAgICAgICAgICAgICAgICAgICBFbGVtZW50ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB+CiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgIH4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rCiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB+CiAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8CiAgICAgIH4gICAgICAgICAgICAgICAgICAgICAgICAgICAgU2NhbGFyICAgICAg ICAgICAgICstKy0rLSstKy0rLSstKy0rCiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwoKICAgICAgICAgICAgICAgICAgRmlndXJl IDE6IFNhbHRlZCBFQVAtcHdkLUNvbW1pdC9SZXF1ZXN0CgogICBUaGUgInNhbHQtbGVuIiBT SEFMTCBiZSBub24temVybyBhbmQgaW5kaWNhdGVzIHRoZSBsZW5ndGgsIGluIG9jdGV0cywK ICAgb2YgdGhlIHNhbHQgdGhhdCBmb2xsb3dzLiAgVGhlIHNhbHQgU0hBTEwgYmUgYSBiaW5h cnkgc3RyaW5nLiAgVGhlCiAgIEVsZW1lbnQgYW5kIFNjYWxhciBhcmUgZW5jb2RlZCBhY2Nv cmRpbmcgdG8gU2VjdGlvbiAzLjMgb2YgW1JGQzU5MzFdLgoKICAgTm90ZTogd2hlbiBhIG5v bi1zYWx0ZWQgcGFzc3dvcmQgcHJlLXByb2Nlc3NpbmcgbWV0aG9kIGlzIHVzZWQsIGZvcgog ICBleGFtcGxlLCBhbnkgb2YgdGhlIG1ldGhvZHMgZnJvbSBbUkZDNTkzMV0sIHRoZSBFQVAt cHdkLUNvbW1pdAogICBwYXlsb2FkIE1VU1QgTk9UIGJlIG1vZGlmaWVkIHRvIGluY2x1ZGUg dGhlIHNhbHQgYW5kIHNhbHQgbGVuZ3RoLgoKCgoKCkhhcmtpbnMgICAgICAgICAgICAgICAg ICBFeHBpcmVzIEFwcmlsIDE1LCAyMDE3ICAgICAgICAgICAgICAgICBbUGFnZSA3XQoMCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICBBYmJyZXZpYXRlZCBUaXRsZSAgICAgICAgICAg ICAgIE9jdG9iZXIgMjAxNgoKCjMuICBBY2tub3dsZWRnZW1lbnRzCgogICBUaGFua3MgdG8g U3RlZmFuIFdpbnRlciBhbmQgdGhlIGVkdXJvYW0gcHJvamVjdCBmb3IgaXRzIGNvbnRpbnVl ZAogICBpbnRlcmVzdCBpbiB1c2luZyBFQVAtcHdkLiAgVGhhbmtzIHRvIFNpbW9uIEpvc2Vm c3NvbiBmb3IgaGlzIGFkdmljZQogICBvbiBzdXBwb3J0IGZvciBzY3J5cHQgYW5kIFBCS0RG Mi4KCjQuICBJQU5BIENvbnNpZGVyYXRpb25zCgogICBJQU5BIGlzIGluc3RydWN0ZWQgdG8g YWxsb2NhdGUgZm91cnRlZW4gKDE0KSB2YWx1ZXMgZnJvbSB0aGUKICAgInBhc3N3b3JkIHBy ZXByb2Nlc3NpbmcgbWV0aG9kIHJlZ2lzdHJ5IiBlc3RhYmxpc2hlZCBieSBbUkZDNTkzMV0g YW5kCiAgIHJlcGxhY2UgVEJEMSwgVEJEMiwgVEJEMywgVEJENCwgVEJENSwgVEJENiwgVEJE NywgVEJEOCwgVEJEOSwgVEJEMTAsCiAgIFRCRDExLCBUQkQxMiwgVEJEMTMsIGFuZCBUQkQx NCBhYm92ZSB3aXRoIHRoZSB2YWx1ZXMgYXNzaWduZWQuCgo1LiAgU2VjdXJpdHkgQ29uc2lk ZXJhdGlvbnMKCiAgIEVBUC1wd2QgcmVxdWlyZXMgZWFjaCBzaWRlIHRvIHByb2R1Y2UgYW4g aWRlbnRpY2FsIHJlcHJlc2VudGF0aW9uIG9mCiAgIHRoZSAocHJvY2Vzc2VkKSBwYXNzd29y ZCBiZWZvcmUgdGhlIHBhc3N3b3JkIGVsZW1lbnQgY2FuIGJlIGZpeGVkLgogICBUaGlzIHN5 bW1ldHJ5IHVuZGVyY3V0cyBvbmUgb2YgdGhlIGJlbmVmaXRzIHRvIHNhbHRpbmcgYSBwYXNz d29yZAogICBkYXRhYmFzZSBiZWNhdXNlIHRoZSBzYWx0ZWQgcGFzc3dvcmQgZnJvbSBhIGNv bXByb21pc2VkIGRhdGFiYXNlIGNhbgogICBiZSB1c2VkIGRpcmVjdGx5IHRvIGltcGVyc29u YXRlIHRoZSBFQVAtcHdkIGNsaWVudC0tc2luY2UgdGhlCiAgIHBsYWludGV4dCBwYXNzd29y ZCBuZWVkIG5vdCBiZSByZWNvdmVyZWQsIG5vIGRpY3Rpb25hcnkgYXR0YWNrIGlzCiAgIG5l ZWRlZC4gIFdoaWxlIHRoZSBpbW1lZGlhdGUgZWZmZWN0IG9mIHN1Y2ggYSBjb21wcm9taXNl IHdvdWxkIGJlCiAgIGNvbXByb21pc2Ugb2YgdGhlIHNlcnZlciwgdGhlIHBlci11c2VyIHNh bHQgd291bGQgc3RpbGwgcHJldmVudCB0aGUKICAgYWR2ZXJzYXJ5IGZyb20gcmVjb3Zlcmlu ZyB0aGUgcGFzc3dvcmQsIGJhcnJpbmcgYSBzdWNjZXNzZnVsCiAgIGRpY3Rpb25hcnkgYXR0 YWNrLCB0byB1c2UgZm9yIG90aGVyIHB1cnBvc2VzLgoKICAgU2FsdGVkIHBhc3N3b3JkIGRh dGFiYXNlcyB1c2VkIHdpdGggRUFQLXB3ZCBNVVNUIGJlIGFmZm9yZGVkIHRoZSBzYW1lCiAg IGxldmVsIG9mIHByb3RlY3Rpb24gYXMgZGF0YWJhc2VzIG9mIHBsYWludGV4dCBwYXNzd29y ZHMuCgogICBIYXNoaW5nIGEgcGFzc3dvcmQgd2l0aCBhIHNhbHQgaW5jcmVhc2VzIHRoZSB3 b3JrIGZhY3RvciBmb3IgYW4KICAgYXR0YWNrZXIgdG8gb2J0YWluIHRoZSBjbGVhcnRleHQg cGFzc3dvcmQgYnV0IGRlZGljYXRlZCBoYXJkd2FyZQogICBtYWtlcyB0aGlzIGluY3JlYXNl ZCB3b3JrIGZhY3RvciBpbmNyZWFzaW5nbHkgbmVnbGlnaWJsZSBpbiByZWFsLQogICB3b3Js ZCBzY2VuYXJpb3MuICBDbGVhcnRleHQgcGFzc3dvcmQgZGF0YWJhc2VzIFNIT1VMRCBiZSBw cm90ZWN0ZWQKICAgd2l0aCBhIHNjaGVtZSB0aGF0IHVzZXMgYSBzZXF1ZW50aWFsIG1lbW9y eSBoYXJkIGZ1bmN0aW9uIHN1Y2ggYXMKICAgW1JGQzc5MTRdLgoKICAgUGxhaW4gc2FsdGlu ZyB0ZWNobmlxdWVzIGFyZSBpbmNsdWRlZCBmb3Igc3VwcG9ydCBvZiBleGlzdGluZwogICBk YXRhYmFzZXMuIHNjcnlwdCBhbmQgUEJLREYyIHRlY2huaXF1ZXMgYXJlIFJFQ09NTUVOREVE IGZvciBuZXcKICAgcGFzc3dvcmQgZGF0YWJhc2UgZGVwbG95bWVudHMuCgogICBFQVAtcHdk IHNlbmRzIHRoZSBzYWx0IGluIHRoZSBjbGVhci4gIElmIEVBUC1wd2QgaXMgbm90IHR1bm5l bGVkIGluCiAgIGFub3RoZXIsIGVuY3J5cHRpbmcsIEVBUCBtZXRob2QsIGFuIGFkdmVyc2Fy eSB0aGF0IGNhbiBvYnNlcnZlCiAgIHRyYWZmaWMgZnJvbSBzZXJ2ZXIgdG8gYXV0aGVudGlj YXRvciBvciBmcm9tIGF1dGhlbnRpY2F0b3IgdG8gY2xpZW50CiAgIHdvdWxkIGxlYXJuIHRo ZSBzYWx0IHVzZWQgZm9yIGEgcGFydGljdWxhciB1c2VyLiAgV2hpbGUga25vd2xlZGdlIG9m CiAgIGEgc2FsdCBieSBhbiBhZHZlcnNhcnkgbWF5IGJlIG9mIGEgc29tZXdoYXQgZHViaW91 cyBuYXR1cmUgKHByZS1pbWFnZQogICByZXNpc3RhbmNlIG9mIHRoZSBoYXNoIGZ1bmN0aW9u IHVzZWQgd2lsbCBwcm90ZWN0IHRoZSBjbGllbnQncwogICBwYXNzd29yZCBhbmQsIGFzIG5v dGVkIGFib3ZlLCB0aGUgZGF0YWJhc2Ugb2Ygc2FsdGVkIHBhc3N3b3JkcyBtdXN0CgoKCgpI YXJraW5zICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAxNSwgMjAxNyAgICAgICAg ICAgICAgICAgW1BhZ2UgOF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgQWJicmV2 aWF0ZWQgVGl0bGUgICAgICAgICAgICAgICBPY3RvYmVyIDIwMTYKCgogICBzdGlsbCBiZSBw cm90ZWN0ZWQgZnJvbSBkaXNjbG9zdXJlKSwgaXQgZG9lcyByZXByZXNlbnQgcG90ZW50aWFs CiAgIGFkZGl0aW9uYWwgbWV0YS1kYXRhIGluIHRoZSBoYW5kcyBvZiBhIHVudHJ1c3RlZCB0 aGlyZCBwYXJ0eS4KCjYuICBSZWZlcmVuY2VzCgo2LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNl cwoKICAgW0NSWV0gICAgICAiY3J5cHQoMykgbWFuIHBhZ2UiLAogICAgICAgICAgICAgIDxo dHRwOi8vbWFuNy5vcmcvbGludXgvbWFuLXBhZ2VzL21hbjMvY3J5cHQuMy5odG1sPi4KCiAg IFtSRkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRv IEluZGljYXRlCiAgICAgICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBS RkMgMjExOSwgTWFyY2ggMTk5Ny4KCiAgIFtSRkMyODk4XSAgS2FsaXNraSwgQi4sICJQS0NT ICM1OiBQYXNzd29yZC1CYXNlZCBDcnlwdG9ncmFwaHkKICAgICAgICAgICAgICBTcGVjaWZp Y2F0aW9uIFZlcnNpb24gMi4wIiwgUkZDIDI4OTgsIERPSSAxMC4xNzQ4Ny8KICAgICAgICAg ICAgICBSRkMyODk4LCBTZXB0ZW1iZXIgMjAwMCwKICAgICAgICAgICAgICA8aHR0cDovL3d3 dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzI4OTg+LgoKICAgW1JGQzM0NTRdICBIb2ZmbWFu LCBQLiBhbmQgTS4gQmxhbmNoZXQsICJQcmVwYXJhdGlvbiBvZgogICAgICAgICAgICAgIElu dGVybmF0aW9uYWxpemVkIFN0cmluZ3MgKCJzdHJpbmdwcmVwIikiLCBSRkMgMzQ1NCwgRE9J CiAgICAgICAgICAgICAgMTAuMTc0ODcvUkZDMzQ1NCwgRGVjZW1iZXIgMjAwMiwKICAgICAg ICAgICAgICA8aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzM0NTQ+LgoKICAg W1JGQzU5MzFdICBIYXJraW5zLCBELiBhbmQgRy4gWm9ybiwgIkV4dGVuc2libGUgQXV0aGVu dGljYXRpb24KICAgICAgICAgICAgICBQcm90b2NvbCAoRUFQKSBBdXRoZW50aWNhdGlvbiBV c2luZyBPbmx5IGEgUGFzc3dvcmQiLCBSRkMKICAgICAgICAgICAgICA1OTMxLCBBdWd1c3Qg MjAxMC4KCiAgIFtSRkM3NjEzXSAgU2FpbnQtQW5kcmUsIFAuIGFuZCBBLiBNZWxuaWtvdiwg IlByZXBhcmF0aW9uLAogICAgICAgICAgICAgIEVuZm9yY2VtZW50LCBhbmQgQ29tcGFyaXNv biBvZiBJbnRlcm5hdGlvbmFsaXplZCBTdHJpbmdzCiAgICAgICAgICAgICAgUmVwcmVzZW50 aW5nIFVzZXJuYW1lcyBhbmQgUGFzc3dvcmRzIiwgUkZDIDc2MTMsIERPSQogICAgICAgICAg ICAgIDEwLjE3NDg3L1JGQzc2MTMsIEF1Z3VzdCAyMDE1LAogICAgICAgICAgICAgIDxodHRw Oi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzYxMz4uCgogICBbUkZDNzkxNF0gIFBl cmNpdmFsLCBDLiBhbmQgUy4gSm9zZWZzc29uLCAiVGhlIHNjcnlwdCBQYXNzd29yZC1CYXNl ZAogICAgICAgICAgICAgIEtleSBEZXJpdmF0aW9uIEZ1bmN0aW9uIiwgUkZDIDc5MTQsIERP SSAxMC4xNzQ4Ny9SRkM3OTE0LAogICAgICAgICAgICAgIEF1Z3VzdCAyMDE2LCA8aHR0cDov L3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzc5MTQ+LgoKICAgW1NIU10gICAgICBOYXRp b25hbCBJbnN0aXR1dGUgb2YgU3RhbmRhcmRzIGFuZCBUZWNobm9sb2d5LCAsICJGZWRlcmFs CiAgICAgICAgICAgICAgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBTdGFuZGFyZCBQdWJsaWNh dGlvbiAxODAtNDogU2VjdXJlCiAgICAgICAgICAgICAgSGFzaCBTdGFuZGFyZCAoU0hTKSIs IE1hcmNoIDIwMTIsCiAgICAgICAgICAgICAgPGh0dHA6Ly9jc3JjLm5pc3QuZ292L3B1Ymxp Y2F0aW9ucy9maXBzL2ZpcHMxODAtNC8KICAgICAgICAgICAgICBmaXBzLTE4MC00LnBkZj4u Cgo2LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbUkZDMjc1OV0gIFpvcm4sIEcu LCAiTWljcm9zb2Z0IFBQUCBDSEFQIEV4dGVuc2lvbnMsIFZlcnNpb24gMiIsIFJGQwogICAg ICAgICAgICAgIDI3NTksIERPSSAxMC4xNzQ4Ny9SRkMyNzU5LCBKYW51YXJ5IDIwMDAsCiAg ICAgICAgICAgICAgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmMyNzU5Pi4K CgoKSGFya2lucyAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMTUsIDIwMTcgICAg ICAgICAgICAgICAgIFtQYWdlIDldCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIEFi YnJldmlhdGVkIFRpdGxlICAgICAgICAgICAgICAgT2N0b2JlciAyMDE2CgoKICAgW1JGQzc2 MTZdICBTaGVraC1ZdXNlZiwgUi4sIEVkLiwgQWhyZW5zLCBELiwgYW5kIFMuIEJyZW1lciwg IkhUVFAKICAgICAgICAgICAgICBEaWdlc3QgQWNjZXNzIEF1dGhlbnRpY2F0aW9uIiwgUkZD IDc2MTYsIERPSSAxMC4xNzQ4Ny8KICAgICAgICAgICAgICBSRkM3NjE2LCBTZXB0ZW1iZXIg MjAxNSwKICAgICAgICAgICAgICA8aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3Jm Yzc2MTY+LgoKICAgW1JGQzc2NjRdICBIYXJraW5zLCBELiwgRWQuLCAiRHJhZ29uZmx5IEtl eSBFeGNoYW5nZSIsIFJGQyA3NjY0LCBET0kKICAgICAgICAgICAgICAxMC4xNzQ4Ny9SRkM3 NjY0LCBOb3ZlbWJlciAyMDE1LAogICAgICAgICAgICAgIDxodHRwOi8vd3d3LnJmYy1lZGl0 b3Iub3JnL2luZm8vcmZjNzY2ND4uCgpBdXRob3IncyBBZGRyZXNzCgogICBEYW4gSGFya2lu cwogICBIUCBFbnRlcnByaXNlCiAgIDEzMjIgQ3Jvc3NtYW4gQXZlbnVlCiAgIFN1bm55dmFs ZSwgQ0EgIDk0MDg5LTExMTMKICAgVW5pdGVkIFN0YXRlcyBvZiBBbWVyaWNhCgogICBFbWFp bDogZGhhcmtpbnNAYXJ1YmFuZXR3b3Jrcy5jb20KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKSGFya2lucyAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMTUsIDIw MTcgICAgICAgICAgICAgICAgW1BhZ2UgMTBdCg== --------------853D315AE1FED3F64773D25A-- From nobody Wed Oct 12 03:31:02 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEBD4126D74; Wed, 12 Oct 2016 03:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.216 X-Spam-Level: X-Spam-Status: No, score=-7.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 LxbUHERQ9BKb; Wed, 12 Oct 2016 03:30:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9392A1294CA; Wed, 12 Oct 2016 03:30:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CTA32919; Wed, 12 Oct 2016 10:30:52 +0000 (GMT) Received: from SZXEMI404-HUB.china.huawei.com (10.82.75.40) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 12 Oct 2016 11:30:51 +0100 Received: from SZXEMI502-MBX.china.huawei.com ([169.254.5.48]) by SZXEMI404-HUB.china.huawei.com ([10.82.75.40]) with mapi id 14.03.0235.001; Wed, 12 Oct 2016 18:30:48 +0800 From: zhangdacheng To: secdir , The IESG Thread-Topic: SecDir review of draft-ietf-core-http-mapping-15 Thread-Index: AdIkcJXPoDb4VkyJR6aWZmojm3TBBQ== Date: Wed, 12 Oct 2016 10:30:47 +0000 Message-ID: <879E76B64CF340468BF5E4DE504C2242C02004@szxemi502-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.167.227] Content-Type: multipart/alternative; boundary="_000_879E76B64CF340468BF5E4DE504C2242C02004szxemi502mbxchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.57FE10DD.000F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.48, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4575ace9e52abcd0b1888d4264a279ae Archived-At: Cc: "draft-ietf-core-http-mapping.all@tools.ietf.org" Subject: [secdir] SecDir review of draft-ietf-core-http-mapping-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 10:30:58 -0000 --_000_879E76B64CF340468BF5E4DE504C2242C02004szxemi502mbxchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the security area directors= . Document editors and WG chairs should treat these comments just like any= other last call comments. I think this document is nearly ready for publication. This document provides reference information for implementing a cross-proto= col network proxy that performs translation from the HTTP protocol to CoAP. The security considerations section is quite extensive. However, some conte= nts in this section have not been well organized yet. The issues caused by = lacking protection to multi-cast addresses has been discussed in sections 1= 0.1, 10.2, 10.3, and 10.4. Same recommendation that requests to multicast r= esources are access controlled with a default-deny policy has been provided= in both 10.1 and 10.4. I suggest to put the issues with multi cast into 10= .1 and remove the redundant information in other places. In addition, it is= a common method to deal with DoS attacks by limit the request rate. So, ma= ybe it is worthwhile to mention this in section 10.2. --_000_879E76B64CF340468BF5E4DE504C2242C02004szxemi502mbxchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

I have reviewed this document as part of the security directorate’s o= ngoing effort to review all IETF documents being processed by the IESG. The= se comments were written primarily for the benefit of the security area dir= ectors.  Document editors and WG chairs should treat these comments just like any other last call comments.

 

I think this document is nearly r= eady for publication.

 

This document provides reference = information for implementing a cross-protocol network proxy that performs t= ranslation from the HTTP protocol to CoAP.

 

The security considerations secti= on is quite extensive. However, some contents in this section have not been= well organized yet. The issues caused by lacking protection to multi-cast addresses has been discussed in sections 10.1, 10= .2, 10.3, and 10.4. Same recommendation that requests to multicast resource= s are access controlled with a default-deny policy has been provided in bot= h 10.1 and 10.4. I suggest to put the issues with multi cast into 10.1 and remove the redundant information = in other places. In addition, it is a common method to deal with DoS attack= s by limit the request rate. So, maybe it is worthwhile to mention this in = section 10.2.

--_000_879E76B64CF340468BF5E4DE504C2242C02004szxemi502mbxchina_-- From nobody Wed Oct 12 16:42:24 2016 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C6195129631; Wed, 12 Oct 2016 16:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1476315605; bh=FFdPlH3+xpJ5ObIzhJxq/9QeRPbS6hae8m+O1GjtB4o=; h=From:Date:To:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=GfT2N1JFCzeL3UVSFCizipHf+u2B/T9NlqfSXkXSyG9KudczG96MxIYdB3u5vC7bY hbWic1pBg/glzl6Do2q1GJT4VDww/Sp87nQoygMRBGKLfeLpMgm6wF7XIfcx+dJ/uh slOPp/MaWI02qH815oqkHwrXpRLbHTwuqWZVRGZI= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B319120726 for ; Wed, 12 Oct 2016 16:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.897 X-Spam-Level: X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 xc74fZRQzsJ8 for ; Wed, 12 Oct 2016 16:40:02 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FFB8129631 for ; Wed, 12 Oct 2016 16:40:02 -0700 (PDT) Received: from [2a01:e34:ed80:f650:45b3:e845:5028:5fa3] by raoul.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1buT7w-00011X-Nz; Wed, 12 Oct 2016 23:40:00 +0000 From: Coralie Mercier Date: Thu, 13 Oct 2016 01:39:59 +0200 To: new-work@ietf.org Message-Id: <1AF0C7DF-5B52-4DED-AE90-C2B2F5C7D625@w3.org> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Wed, 12 Oct 2016 16:42:23 -0700 Subject: [secdir] [new-work] Accessibility Guidelines Working Group Updated Charter in Development (Advance Notice) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 23:40:07 -0000 CkhlbGxvLAoKVGhlIFczQyBBZHZpc29yeSBDb21taXR0ZWUgcmVjZWl2ZWQgYW4gYWR2YW5jZSBu b3RpY2UgdG9kYXkgdGhhdCBwYXJ0aWNpcGFudHMgb2YgdGhlIFdlYiBDb250ZW50IEFjY2Vzc2li aWxpdHkgR3VpZGVsaW5lcyBXb3JraW5nIEdyb3VwIChXQ0FHIFdHKVsxXSBhcmUgd29ya2luZyBv biBhbiB1cGRhdGVkIGNoYXJ0ZXI6CiAgaHR0cHM6Ly93d3cudzMub3JnLzIwMTYvMDkvZHJhZnQt d2NhZy1jaGFydGVyCgpUaGUgV0NBRyBXRyBpcyBleHBsb3JpbmcgaG93IHRvIGJ1aWxkIG9uIGJ1 dCBub3Qgc3VwZXJzZWRlIFdDQUcgMi4wLiBSZWFkIG1vcmUgaW4gdGhlIFczQyBCbG9nIFsyXS4K CldlIHdlbGNvbWUgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSByZXByZXNlbnRhdGl2ZXMnIGdlbmVy YWwgZXhwcmVzc2lvbnMgb2YKaW50ZXJlc3QgYW5kIHN1cHBvcnQgb24gPHczYy1hYy1mb3J1bUB3 My5vcmc+LCBhbmQgcHVibGljIGNvbW1lbnRzIG9uIHRoZSBncm91cOKAmXMgcHVibGljIG1haWxp bmcgbGlzdCA8d2FpLXdjYWctZWRpdG9yQHczLm9yZz4gKEFyY2hpdmUgWzNdKS4KCgpDb3JhbGll IE1lcmNpZXIsIEhlYWQgb2YgVzNDIE1hcmtldGluZyAmIENvbW11bmljYXRpb25zCgpbMV0gaHR0 cHM6Ly93d3cudzMub3JnL1dBSS9HTC8KWzJdIGh0dHBzOi8vd3d3LnczLm9yZy9ibG9nLzIwMTYv MTAvd2NhZy0yLTEtdW5kZXItZXhwbG9yYXRpb24vClszXSBodHRwczovL2xpc3RzLnczLm9yZy9B cmNoaXZlcy9QdWJsaWMvd2FpLXdjYWctZWRpdG9yLwoK4oCUCkNvcmFsaWUgTWVyY2llciAgLSAg VzNDIE1hcmtldGluZyAmIENvbW11bmljYXRpb25zIC0gIGh0dHA6Ly93d3cudzMub3JnCm1haWx0 bzpjb3JhbGllQHczLm9yZyArMzM2IDQzMjIgMDAwMSBodHRwOi8vd3d3LnczLm9yZy9QZW9wbGUv Q01lcmNpZXIvCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XwpuZXctd29yayBtYWlsaW5nIGxpc3QKbmV3LXdvcmtAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXctd29yawo= From nobody Thu Oct 13 01:50:43 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47C61294A2; Thu, 13 Oct 2016 01:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 tfd7XAe1gmYe; Thu, 13 Oct 2016 01:50:40 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id D9A531294A5; Thu, 13 Oct 2016 01:50:39 -0700 (PDT) Received: from gw2.nict.go.jp (gw2.nict.go.jp [133.243.18.251]) by ns2.nict.go.jp with ESMTP id u9D8oa7w065435; Thu, 13 Oct 2016 17:50:36 +0900 (JST) Received: from DESKTOP2JPR8KD (ssh1.nict.go.jp [133.243.3.49]) by gw2.nict.go.jp with ESMTP id u9D8oaM3065278; Thu, 13 Oct 2016 17:50:36 +0900 (JST) From: "Takeshi Takahashi" To: Date: Thu, 13 Oct 2016 17:50:36 +0900 Message-ID: <6c5a01d2252e$de04de30$9a0e9a90$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdIlLquqn+hpOwDZRPOvlbREgSAP4Q== Content-Language: ja X-Virus-Scanned: clamav-milter 0.98.7 at zenith2 X-Virus-Status: Clean Archived-At: Cc: iesg@ietf.org, secdir@ietf.org Subject: [secdir] Secdir (re)review of draft-ietf-tsvwg-rfc5405bis-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 08:50:41 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: Ready The current revision of this document adequately addresses my prior comments. I have realized that the draft has updated some part of its content after its version 13 (that I have reviewed before), and I think the changes are good. This document is ready, and I do not have any further comments. Kind regards, Take From nobody Thu Oct 13 03:11:43 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE72129732 for ; Thu, 13 Oct 2016 03:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=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 ZxVXBA68p5LX for ; Thu, 13 Oct 2016 03:11:40 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B82DB1295D2 for ; Thu, 13 Oct 2016 03:11:39 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u9DABZTS021174 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 13 Oct 2016 13:11:35 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u9DABZLu020846; Thu, 13 Oct 2016 13:11:35 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22527.24023.58112.901028@fireball.acr.fi> Date: Thu, 13 Oct 2016 13:11:35 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 10:11:42 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Tina TSOU is next in the rotation. For telechat 2016-10-13 Reviewer LC end Draft Matt Lepinski T 2016-09-29 draft-ietf-ipsecme-safecurves-05 Sandy Murphy T 2016-10-10 draft-ietf-regext-epp-rdap-status-mapping-03 Magnus Nystrom T 2016-10-11 draft-ietf-webpush-protocol-11 Tina TSOU T 2016-08-15 draft-ietf-ospf-two-part-metric-09 For telechat 2016-10-27 Ben Laurie TR2016-10-10 draft-levine-herkula-oneclick-07 Catherine Meadows T 2016-09-30 draft-ietf-opsawg-capwap-alt-tunnel-08 Eric Osterweil T 2016-10-19 draft-ietf-i2rs-ephemeral-state-19 Radia Perlman T 2016-10-17 draft-ietf-lisp-ddt-08 Vincent Roca T 2016-10-18 draft-ietf-mpls-rfc4379bis-07 Joe Salowey T 2016-10-17 draft-ietf-pce-stateful-pce-app-07 Rich Salz T 2016-10-19 draft-ietf-roll-routing-dispatch-01 For telechat 2016-12-01 Benjamin Kaduk TR2016-09-08 draft-ietf-tsvwg-diffserv-intercon-12 Hannes Tschofenig T 2016-10-24 draft-ietf-pim-join-attributes-for-lisp-05 Last calls and special requests: Alan DeKok 2016-04-30 draft-bradner-rfc3979bis-08 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Russ Housley R2016-10-25 draft-ietf-p2psip-share-09 Warren Kumari 2016-09-06 draft-sweet-rfc2911bis-11 Matthew Miller 2016-10-06 draft-ietf-stox-7248bis-13 Yaron Sheffer 2016-11-04 draft-bbf-bbf-urn-02 Rifaat Shekh-Yusef 2016-10-24 draft-ietf-ccamp-ospf-availability-extension-07 Melinda Shore 2016-10-25 draft-ietf-httpauth-mutual-10 Takeshi Takahashi 2016-10-25 draft-ietf-httpauth-mutual-algo-06 Hannes Tschofenig E None draft-ietf-ntp-network-time-security-15 Hannes Tschofenig E None draft-ietf-ntp-cms-for-nts-message-06 Hannes Tschofenig E None draft-ietf-ntp-using-nts-for-ntp-06 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-10 -- kivinen@iki.fi From nobody Thu Oct 13 03:59:20 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8C61294B4; Thu, 13 Oct 2016 03:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 mjzgPiPIakz5; Thu, 13 Oct 2016 03:59:12 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA262129474; Thu, 13 Oct 2016 03:59:12 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id u124so50463100ywg.3; Thu, 13 Oct 2016 03:59:12 -0700 (PDT) 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; bh=pkAoNUM0V63iaura9Sr7PYZAT//f/Ieuaiyht/OspMY=; b=RlXoGQWq77hmxGQCfOmrOCbTme7laKscfNN0duf+mjsnIX5xHQpAXKsiD/2XY/zD0y RiSlALiUAJY+E0vD9++P+/l7ikYM6KBE6pUNYZpQRm9f3Dl8vmMeFgmGrYNM6boisW/w KbEMkv/DRPVYa32mgODgr9ayLY9gTVxsZKAxj0q8L6zKGMC1Pigy8qv6m/Yr1DGosKay xlTLzMBjdu0mcZhSdYHNJ5lbq6SfCn+ux5TQGVV3CPl/QRqWk+J1Jluif5qxhItur7e8 KJqk/PAc/4pwPY/jCEVbveZ1cZETwCUS9r5AqEqrlyeQmZEf3eIjOgLhavSBza0TRTdy wVCw== 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; bh=pkAoNUM0V63iaura9Sr7PYZAT//f/Ieuaiyht/OspMY=; b=TgCaLN/fz5itd4yTuDryldyFW2HxaggXgvZ3v9dYlD5NakTex3MGtNxNu/sAnKCzvj pkxs/up+6QXFEBLdncXOsgJ4hltQnrdRnDJASdTZ6J9/UdfVMg+/ZxtzXseO8NkSd7gs sgIqbTJmcT/GcikKf8m54zbwelQ75VUGKiOvepLguev9BaDHDetLJO8iW0xXNer2SOFS goDexvR+wrjH/CB7zkQPzhffW5tO61vfMNiQ4+TSkkEg//GpiFw3zkG3c/s66L3slN/n k+0wsO/ToS/uiwBDl2FLJ+PdOHYmVAMch9fmW+NC5dN51S5MiFPXv45gXFjCG1OmWIyb s6+A== X-Gm-Message-State: AA6/9RmcjHTRa7A4ijmeb86ofJYPKG+pbvfs0RRPFBajgUBg+xNyPjzhG7Cs7PVQjyPu2W8gfFmBNkQxB4pA6w== X-Received: by 10.129.77.84 with SMTP id a81mr4851857ywb.19.1476356351888; Thu, 13 Oct 2016 03:59:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.92.67 with HTTP; Thu, 13 Oct 2016 03:59:11 -0700 (PDT) Received: by 10.37.92.67 with HTTP; Thu, 13 Oct 2016 03:59:11 -0700 (PDT) In-Reply-To: <6c5a01d2252e$de04de30$9a0e9a90$@nict.go.jp> References: <6c5a01d2252e$de04de30$9a0e9a90$@nict.go.jp> From: Spencer Dawkins at IETF Date: Thu, 13 Oct 2016 05:59:11 -0500 Message-ID: To: Takeshi Takahashi Content-Type: multipart/alternative; boundary=001a1140b7acea9152053ebcfff9 Archived-At: Cc: iesg@ietf.org, draft-ietf-tsvwg-rfc5405bis.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir (re)review of draft-ietf-tsvwg-rfc5405bis-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 10:59:14 -0000 --001a1140b7acea9152053ebcfff9 Content-Type: text/plain; charset=UTF-8 Thank you for the (re)review, Take. On Oct 13, 2016 03:50, "Takeshi Takahashi" wrote: > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > Summary: Ready > > The current revision of this document adequately addresses my prior > comments. > I have realized that the draft has updated some part of its content after > its version 13 (that I have reviewed before), and I think the changes are > good. > This document is ready, and I do not have any further comments. > > Kind regards, > Take > > --001a1140b7acea9152053ebcfff9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thank you for the (re)review, Take.

On Oct 13, 2016 03:50, "Takeshi Takahashi" <takeshi_takahashi@nict.go.jp> wrote:
>
> I have reviewed this document as part of the security directorate'= s
> ongoing effort to review all IETF documents being processed by the
> IESG.=C2=A0 These comments were written primarily for the benefit of t= he
> security area directors.=C2=A0 Document editors and WG chairs should t= reat
> these comments just like any other last call comments.
>
> Summary: Ready
>
> The current revision of this document adequately addresses my prior > comments.
> I have realized that the draft has updated some part of its content af= ter
> its version 13 (that I have reviewed before), and I think the changes = are
> good.
> This document is ready, and I do not have any further comments.
>
> Kind regards,
> Take
>
>

--001a1140b7acea9152053ebcfff9-- From nobody Thu Oct 13 08:15:09 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E1F1295D8 for ; Thu, 13 Oct 2016 08:15:07 -0700 (PDT) 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 autolearn_force=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 qvp2EkNbaVNa for ; Thu, 13 Oct 2016 08:15:05 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE029129549 for ; Thu, 13 Oct 2016 08:15:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id BF63F300A58 for ; Thu, 13 Oct 2016 11:15:04 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id TNypSiNQIfP5 for ; Thu, 13 Oct 2016 11:15:03 -0400 (EDT) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 30001300579; Thu, 13 Oct 2016 11:15:03 -0400 (EDT) From: Russ Housley X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_63B53435-893D-4EC0-9026-26F9E76B6A78"; protocol="application/pgp-signature"; micalg=pgp-sha1 Date: Thu, 13 Oct 2016 11:08:10 -0400 Message-Id: <9A291382-85CD-48AD-8807-F2B3E6089138@vigilsec.com> To: draft-ietf-p2psip-share.all@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Alissa Cooper , IETF SecDir Subject: [secdir] Early review of draft-ietf-p2psip-share-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 15:15:07 -0000 --Apple-Mail=_63B53435-893D-4EC0-9026-26F9E76B6A78 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii I reviewed this document for the Security Directorate after a request by the ART AD for an early review. Version reviewed: draft-ietf-p2psip-share-09 Summary: Ready (from a Security Directorate perspective) Thank you for addressing the comments that I provided on -08. Major Concerns: None Minor Concerns: None Nits: Section 5.1 says: When defining the pattern, care must be taken to avoid conflicts arising from two user names of witch one is a substring of the other. s/witch/which/ --Apple-Mail=_63B53435-893D-4EC0-9026-26F9E76B6A78 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlf/o28ACgkQiuTu0PWcEcukPQCgsO9Jpt8y/y+mV3Wpsr4l2emN 0OcAoKfdJ1cR7nEhywN9fhKB16v0VoIk =Uplj -----END PGP SIGNATURE----- --Apple-Mail=_63B53435-893D-4EC0-9026-26F9E76B6A78-- From nobody Thu Oct 13 09:33:17 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E44F12950F; Thu, 13 Oct 2016 09:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.897 X-Spam-Level: X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 w8ENdN_Tg-5A; Thu, 13 Oct 2016 09:33:10 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB814129428; Thu, 13 Oct 2016 09:33:07 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 32E5928B0041; Thu, 13 Oct 2016 12:33:06 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 281E21F8036; Thu, 13 Oct 2016 12:33:06 -0400 (EDT) From: Sandra Murphy X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_594057DF-7220-4D31-A6BB-F1FEF5D4B6CC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 13 Oct 2016 12:32:59 -0400 Message-Id: To: secdir@ietf.org, draft-ietf-regext-epp-rdap-status-mapping@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [secdir] secdir review of draft-ietf-regext-epp-rdap-status-mapping-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 16:33:16 -0000 --Apple-Mail=_594057DF-7220-4D31-A6BB-F1FEF5D4B6CC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have reviewed this document as part of the security directorate=E2=80=99= s ongoing effort to review all IETF documents being processed by the = IESG. These comments were written primarily for the benefit of the = security area directors. Document editors and WG chairs should treat = these comments just like any other last call comments. The draft draft-ietf-regext-epp-rdap-status-mapping identifies gaps in = the mapping of EPP statuses to RDAP statuses that are registered in the = IANA RDAP JSON Values Registry. The draft provides entries in the RDAP = JSON Values Registry to fill those gaps. I see no security issues with this draft. =E2=80=94Sandy --Apple-Mail=_594057DF-7220-4D31-A6BB-F1FEF5D4B6CC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJX/7dBAAoJEHplpQeet0IZLLsP/i1W7URD1R1VoBvqJzU2prKN J+SPSHKWdmEXFnOrSBepH38gJuPiAPgQZ0RCQ1uvZmyxpi8kE8lZ4gIfZY6uBTxg 3FU6yBTBqBxNkQiOBtGAv92LTcJap6pWKF0GTiHPj46CU16qzv86WCSUDrTptN3W e2aqZlc9d71NZNGHcUfHIVEJbr/9zCkyHfwjZbyQ/ge0heX57VQ9j7SJpkiYI83N 7WGjYWlGfSefSwT/OWFrr35ebO7o8dCF+I+Bme4dGspajPA+9mo6RWYCJ170D3m9 OxVUwiMQ6NWMWFSgI372vUOSfNFmfiyf66cn6NDgX01hAYBaizWOZY9aPr/acDqN oui9WMTPj54UBxustVgtrWkGsfd9U/ZJZRxlWnINlSLWMf0JxjIufe4URGh7F1FE xmueG+8i5x4y2/AUQXVEV7UDSy7g/h+Nij9cUqNnWKybXjlSfD67k9oRim4jrG16 qx3OT/yyYtqV1hwFajlrXM4YI8YIjD1F2+DMEuO58JES3dNNgHHFWlscJXhix42E Yrx5QzJdUTeqHsJtrMMEtkDZRq6ypvDyETf6+9Lb6EZY3Eoo2bUdh3iuja+2XHLK rtUNloOUdCPORdWaPQ2sIAF3/XatPNEDVlU8d1bIYtq1HpaLKJjTq6+14o7rr0mg IoZTfPwJZncPmmXdmVGu =9Gl5 -----END PGP SIGNATURE----- --Apple-Mail=_594057DF-7220-4D31-A6BB-F1FEF5D4B6CC-- From nobody Thu Oct 13 12:27:46 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92D5129502; Thu, 13 Oct 2016 12:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.897 X-Spam-Level: X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 VvmkgF60RWP8; Thu, 13 Oct 2016 12:27:40 -0700 (PDT) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [IPv6:2001:480:20:118:118::211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08C9612955C; Thu, 13 Oct 2016 12:27:39 -0700 (PDT) Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id u9DJRc5b010390 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 13 Oct 2016 15:27:38 -0400 From: Catherine Meadows Content-Type: multipart/alternative; boundary="Apple-Mail=_5F7C8210-46FB-496C-969C-97F3193044A4" Date: Thu, 13 Oct 2016 15:27:37 -0400 Message-Id: <7AD6521F-A786-4333-B219-9031464AFD43@nrl.navy.mil> To: iesg@ietf.org, secdir@ietf.org, draft-ietf-opsawg-capwap-alt-tunnel.all@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Archived-At: Subject: [secdir] Secdir review of draft-ietf-opsawg-capwap-alt-tunnel-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 19:27:43 -0000 --Apple-Mail=_5F7C8210-46FB-496C-969C-97F3193044A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. This draft describes an extension to the Control and Provisioning of = Wireless Access Points (CAPWAP) protocol that encapsulates a station=E2=80= =99s data frames between the Wireless Transition Point (ATP) and Access = Controller (AC). In some cases, it may be desirable to encapsulate data = frames to an entity other than the AC (e.g. to an Access Router) or to = use different encapsulation models. In particular, this would allow the WTP to tunnel = non-management data frames to an endpoint different than the AC and to = tunnel using different known encapsulation types, such as IP-IP, IP-GRE, = or CAPWAP. A particular advantage of this approach that encapsulating = only the control plane to the AC, and thus separating management of the = control plane from the management of the data plane, makes scaling = easier and more efficient. As far as I can tell, there do not seem to be any serious security = issues with implementing this approach, especially since, as is noted in = RFC [RFC5415], the data plane is already handled differently from the = control plane, the control plane usually being protected by DTLS while = the data plan is not. However, I think the Security Considerations = Section needs to make a better case for this. The text of the Security Considerations section is as follows: This document introduces three new CAPWAP WTP message elements. These elements are transported within CAPWAP Control messages as the existing message elements. Therefore, this document does not introduce any new security risks compared to [RFC5415] and [RFC5416]. In CAPWAP, security for CAPWAP Data Channel is optional and security policy is determined by AC. Similarly, the AC determines the security for the Alternate Tunnel between WTP and Alternate Tunnel Encapsulation Gateway. The security considerations described in [RFC5415] and [RFC5416] apply here as well. I find it hard to agree with the first three sentences. The document = does more than simply introduce three new message elements. It also provides considerably more freedom in encapsulating data frames. So it = appears to me that what the Security Considerations section should = concentrate on is the potential risk in providing this greater freedom.=20= It=E2=80=99s also not clear to me what the purpose of the remaining part = of the section, about the AC determining the policy. Are you saying = that, because the AC determines the policy in both CAPWAP and the CAPWAP = extension, the security considerations for the first case also apply to = the second case? Some more discussion of why this is true, with = references to the relevant risks discussed in [RFC5415] and [RFC5416], = would be useful. =20 Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil = --Apple-Mail=_5F7C8210-46FB-496C-969C-97F3193044A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I have reviewed this document as part of the = security directorate's 
ongoing effort to = review all IETF documents being processed by the 
IESG.  These comments were written primarily for the = benefit of the 
security area directors. =  Document editors and WG chairs should treat 
these comments just like any other last call = comments.

This draft describes an extension to the Control and = Provisioning of Wireless Access Points (CAPWAP) protocol that = encapsulates a station=E2=80=99s data frames between the Wireless = Transition Point (ATP) and Access Controller (AC).  In some cases, = it may be desirable to encapsulate data frames to an entity other than = the AC (e.g. to an Access Router) or to use different
encapsulation models.  In particular, this would allow = the WTP to tunnel non-management data frames to an endpoint different = than the AC and to tunnel using different known encapsulation types, = such as IP-IP, IP-GRE, or CAPWAP.  A particular advantage of this = approach that  encapsulating only the control plane to the AC, and = thus separating management of the control plane from the management of = the data plane, makes scaling easier and more efficient.

As far as I can tell, = there do not seem to be any serious security issues with implementing = this approach, especially since, as is noted in RFC [RFC5415], the data = plane is already handled differently from the control plane, the control = plane usually being protected by DTLS while the data plan is not. = However, I think the Security Considerations Section needs to make a = better case for this.

The text of the Security Considerations section is as = follows:

This = document introduces three new CAPWAP WTP message elements.
   These elements are transported within CAPWAP = Control messages as the
   existing = message elements.  Therefore, this document does not
   introduce any new security risks compared to = [RFC5415] and [RFC5416].
   In CAPWAP, = security for CAPWAP Data Channel is optional and security
   policy is determined by AC.  Similarly, the = AC determines the
   security for the = Alternate Tunnel between WTP and Alternate Tunnel
   Encapsulation Gateway.  The security = considerations described in
   [RFC5415] = and [RFC5416] apply here as well.

I find it hard to agree with the first = three sentences. The document does more than simply introduce three new = message elements.  It also
provides = considerably more freedom in encapsulating data frames.  So it = appears to me that what the Security Considerations section should = concentrate on is the potential risk in providing this greater = freedom. 

It=E2=80=99s also not clear to me what the purpose of the = remaining part of the section, about the AC determining the policy. =  Are you saying that, because the AC determines the policy in both = CAPWAP and the CAPWAP extension, the security considerations for the = first case also apply to the second case?  Some more discussion of = why this is true, with references to the relevant risks discussed in = [RFC5415] and [RFC5416], would be useful.  


Catherine Meadows
Naval Research = Laboratory
Code 5543
4555 Overlook Ave., = S.W.
Washington DC, 20375
phone: = 202-767-3490
fax: 202-404-7942
email: catherine.meadows@nrl.navy.mil

= --Apple-Mail=_5F7C8210-46FB-496C-969C-97F3193044A4-- From nobody Thu Oct 13 13:47:07 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8543212965E for ; Thu, 13 Oct 2016 13:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.onmicrosoft.com 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 rMXqXckquqmU for ; Thu, 13 Oct 2016 13:47:03 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0062.outbound.protection.outlook.com [104.47.32.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0819312960A for ; Thu, 13 Oct 2016 13:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.onmicrosoft.com; s=selector1-isoc-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CpG7hAA2OCujCnInz8F/uEnNLzEvAJOlyBW5u/ZZv80=; b=Qnp4lqfM6nVqja9XZxucM1BoDO2beg3aqWf7Xy64CIrCGnLYAw8Q2unqqEmam7pewzcTDky70rkXvjY37ZWoTMc4EuGgaRn61+6sF7x8SbQSujcji6jvfmQesBkrKBr3lUMVpBJf823V2OmfH4o0Ft0TC7fGKCRTwKzA5y/besY= Received: from MWHPR06MB2846.namprd06.prod.outlook.com (10.175.138.11) by MWHPR06MB2848.namprd06.prod.outlook.com (10.175.138.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.12; Thu, 13 Oct 2016 20:47:01 +0000 Received: from MWHPR06MB2846.namprd06.prod.outlook.com ([10.175.138.11]) by MWHPR06MB2846.namprd06.prod.outlook.com ([10.175.138.11]) with mapi id 15.01.0669.011; Thu, 13 Oct 2016 20:47:01 +0000 From: Christian O'Flaherty To: "secdir@ietf.org" Thread-Topic: CodeStand Thread-Index: AQHSJZLyBCm5J8m/g0S8s5BsMH/WRw== Date: Thu, 13 Oct 2016 20:47:00 +0000 Message-ID: <1E646ECC-BEBA-41C3-B691-C2599F39A396@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=oflaherty@isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [167.61.59.63] x-ms-office365-filtering-correlation-id: 982ba52f-36d6-436c-d43d-08d3f3aa14f6 x-microsoft-exchange-diagnostics: 1; MWHPR06MB2848; 6:CtyPttfTcb7B+15u0HtdcHXvanecSuVGG2s/++kJ+87qtKr1L05zPgkk5Ai10yAOIYmXSn7qD0v6c86c1z/rRolcgMRBwPg9h7HLTp2kYO4B5BM7cAqhTJXyKoUyzUdxUArZuzYOaTCHtNGItxygtT3XWNwUJSp2AAyYlW2j7Z81ealGxiv52odhzJBmPGf4HhjW5dtxTWHX9WVCeDYz5423mFapqLfBkhNpYKXfb7k+nvbUa+vcMpou62TdEDsv/E2aanTQ6/887y3FFCdZ721n4OiVsKP/EgRSVzFcNRBSS/ujhbH42OFZmqe3lvdW; 5:XB4rfK5AcmqryalFyzRrho7Lr1IILo22aq/8uHzABoqO1IdEZgf9hlwVQryxhhpN339JyTITbDi2Yb9ej0amgUpLxG4zXhAcX2eqY6ODjhdghMb/Er0X3ra0rqF90IjylL0FCPfMOwPCvj2mbQPNNDZN/OhXcgzA/mfnBqW3AkA=; 24:hc/nkVE0Fs8zBX+yjz1I9PSpRASBcP7tvjrEkqaItAbCcJ/LCpjAA5Kurg+1tqsXLBV9ubokLVqiz9xZsQZVhX4l/2UEU5BQFmEQ/uaoi5Y=; 7:mcDPYRbMutkVIY7mJMf2MITMsZxeI3nC3IUGNSHvWXFqu3C/csEW7yKnYRhDam7IJiGfh4D0vITbjsZbBprDUlXlXVzMr+bH46SDrQsV9a6LQVq9vlPUQinGQ9Qpwi7EnmSMx8OQpGWgDSncK8hRXKKwi+JlW7fbmDyRYi8rjYvvgSqK1uXKhc5GKNm+9UpZ1SKN+PpHnsqet9Aq0TXMymUcUi6GT/dMq/bwX6s/aQ817tdQjHbIRhAUVGDVonefjxJ70lXf7a9oYSdSK6t5VrLXvSQ71zC2EM30/pXJSYiMrzK1B3YAP7gIzQwnrB7RykokezzGY2tD9RPed4viYmRemrz9mkdVgr5ZZlZ12dY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR06MB2848; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(5213294742642); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:MWHPR06MB2848; BCL:0; PCL:0; RULEID:; SRVR:MWHPR06MB2848; x-forefront-prvs: 0094E3478A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(53754006)(199003)(189002)(16236675004)(3846002)(81166006)(81156014)(1730700003)(586003)(6916009)(102836003)(6116002)(2351001)(229853001)(8676002)(66066001)(110136003)(3660700001)(11100500001)(5640700001)(106116001)(106356001)(122556002)(97736004)(221733001)(87936001)(68736007)(10400500002)(5002640100001)(82746002)(189998001)(19617315012)(2900100001)(19580395003)(83716003)(19580405001)(107886002)(86362001)(92566002)(54356999)(50986999)(101416001)(99286002)(7846002)(105586002)(2906002)(7736002)(450100001)(5660300001)(8936002)(33656002)(15975445007)(36756003)(3280700002)(7906003)(7116003)(2501003)(3480700004)(77096005)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR06MB2848; H:MWHPR06MB2846.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_1E646ECCBEBA41C3B691C2599F39A396isocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2016 20:47:00.8960 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR06MB2848 Archived-At: Subject: [secdir] CodeStand X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 20:47:05 -0000 --_000_1E646ECCBEBA41C3B691C2599F39A396isocorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJbiBCZXJsaW4gYXQgdGhlIFNlY0RpciBNZWV0aW5nIHdlIHByZXNlbnRlZCBh IHdlYiBzaXRlIGFpbWVkIHRvIGRvY3VtZW50IGNvZGluZyBwcm9qZWN0cyBiYXNlZCBvbiBJRVRG IGRvY3VtZW50cy4gVW5mb3J0dW5hdGVseSwgdGhlIG5hbWUgd2UgdXNlZCB3YXMgdGFrZW4gYW5k IHdlIGhhZCB0byB0dXJuIGl0IG9mZiBhZnRlciB0aGUgbWVldGluZy4NCg0KVGhlIG5ldyBuYW1l IGZvciB0aGUgcHJvamVjdCBpcyBDb2RlU3RhbmQgYW5kIHRoZSBuZXcgc2l0ZSBpczogaHR0cHM6 Ly9jb2Rlc3RhbmQuaWV0Zi5vcmcNCg0KV2XigJlyZSBub3cgbG9va2luZyBmb3Igdm9sdW50ZWVy cyB3aWxsaW5nIHRvIGNyZWF0ZSDigJxDb2RlIFJlcXVlc3Rz4oCdIGZvciB0aGVpciBkb2N1bWVu dHMuIFN0dWRlbnRzIHdpbGwgY3JlYXRlIOKAnFByb2plY3RzIiByZWZlcmVuY2luZyB5b3VyIOKA nENvZGUgUmVxdWVzdOKAnS4gQSBwcm9qZWN0IGNhbiBhbHNvIGJlIGNyZWF0ZWQgdG8gZG9jdW1l bnQgZXhpc3RpbmcgY29kZSB3aXRob3V0IGhhdmluZyBhIGNvZGUgcmVxdWVzdCBhbmQgaXQgY2Fu IGJlIGVpdGhlciBvcGVuIHNvdXJjZSBvciBwcm9wcmlldGFyeSBjb2RlLg0KDQpUaGUgc2l0ZSB3 aWxsIGJlIGFubm91bmNlZCB0byBzdHVkZW50cyBuZXh0IHdlZWsgYXQgdGhlIEdyYWNlIEhvcHBl ciBDZWxlYnJhdGlvbiBzbyB3ZSB3b3VsZCBsaWtlIHRvIGhhdmUgYXMgbWFueSBjb2RlIHJlcXVl c3RzIGFzIHBvc3NpYmxlIGF2YWlsYWJsZSBpbiBDb2RlU3RhbmQuDQoNCllvdSBjYW4gU2lnbiBJ biB1c2luZyB5b3VyIGN1cnJlbnQgRGF0YXRyYWNrZXIgY3JlZGVudGlhbHMuDQoNClBsZWFzZSBw cm92aWRlIGZlZWRiYWNrIHRvIGNvZGVzdGFuZC1kZXZlbG9wQGlldGYub3JnPG1haWx0bzpjb2Rl c3RhbmQtZGV2ZWxvcEBpZXRmLm9yZz4NCg0KVGhlIENvZGVTdGFuZCB0ZWFtDQoNCg== --_000_1E646ECCBEBA41C3B691C2599F39A396isocorg_ Content-Type: text/html; charset="utf-8" Content-ID: <2A5D7F9910B47D4F8932DE787C69B5CE@namprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgYWxsLA0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SW4gQmVybGluIGF0IHRoZSBT ZWNEaXIgTWVldGluZyB3ZSBwcmVzZW50ZWQgYSB3ZWIgc2l0ZSBhaW1lZCB0byBkb2N1bWVudCBj b2RpbmcgcHJvamVjdHMgYmFzZWQgb24gSUVURiBkb2N1bWVudHMuIFVuZm9ydHVuYXRlbHksIHRo ZSBuYW1lIHdlIHVzZWQgd2FzIHRha2VuIGFuZCB3ZSBoYWQgdG8gdHVybiBpdCBvZmYgYWZ0ZXIg dGhlIG1lZXRpbmcuJm5ic3A7PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlIG5ldyBu YW1lIGZvciB0aGUgcHJvamVjdCBpcyBDb2RlU3RhbmQgYW5kIHRoZSBuZXcgc2l0ZSBpczombmJz cDs8YSBocmVmPSJodHRwczovL2NvZGVzdGFuZC5pZXRmLm9yZyIgY2xhc3M9IiI+aHR0cHM6Ly9j b2Rlc3RhbmQuaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KV2XigJly ZSBub3cgbG9va2luZyBmb3Igdm9sdW50ZWVycyB3aWxsaW5nIHRvIGNyZWF0ZSDigJxDb2RlIFJl cXVlc3Rz4oCdIGZvciB0aGVpciBkb2N1bWVudHMuIFN0dWRlbnRzIHdpbGwgY3JlYXRlIOKAnFBy b2plY3RzJnF1b3Q7IHJlZmVyZW5jaW5nIHlvdXIg4oCcQ29kZSBSZXF1ZXN04oCdLiBBIHByb2pl Y3QgY2FuIGFsc28gYmUgY3JlYXRlZCB0byBkb2N1bWVudCBleGlzdGluZyBjb2RlIHdpdGhvdXQg aGF2aW5nIGEgY29kZSByZXF1ZXN0IGFuZCBpdCBjYW4gYmUgZWl0aGVyDQogb3BlbiBzb3VyY2Ug b3IgcHJvcHJpZXRhcnkgY29kZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgc2l0 ZSB3aWxsIGJlIGFubm91bmNlZCB0byBzdHVkZW50cyBuZXh0IHdlZWsgYXQgdGhlIEdyYWNlIEhv cHBlciBDZWxlYnJhdGlvbiBzbyB3ZSB3b3VsZCBsaWtlIHRvIGhhdmUgYXMgbWFueSBjb2RlIHJl cXVlc3RzIGFzIHBvc3NpYmxlIGF2YWlsYWJsZSBpbiBDb2RlU3RhbmQuJm5ic3A7PGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KWW91IGNhbiBTaWduIEluIHVzaW5nIHlvdXIgY3VycmVudCBE YXRhdHJhY2tlciBjcmVkZW50aWFscy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpQbGVh c2UgcHJvdmlkZSBmZWVkYmFjayB0byZuYnNwOzxhIGhyZWY9Im1haWx0bzpjb2Rlc3RhbmQtZGV2 ZWxvcEBpZXRmLm9yZyIgY2xhc3M9IiI+Y29kZXN0YW5kLWRldmVsb3BAaWV0Zi5vcmc8L2E+Jm5i c3A7PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlIENvZGVTdGFuZCB0ZWFtPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_1E646ECCBEBA41C3B691C2599F39A396isocorg_-- From nobody Thu Oct 13 14:55:39 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC91129686; Thu, 13 Oct 2016 14:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.996 X-Spam-Level: X-Spam-Status: No, score=-4.996 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=-2.996] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 foELHmbP2WU2; Thu, 13 Oct 2016 14:55:34 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 890941295DF; Thu, 13 Oct 2016 14:55:34 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3sw4Kb4bJHz3Fm; Thu, 13 Oct 2016 23:55:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1476395731; bh=zlUV5ynErMeMsjtLR+TTcslavw6/dihbfbPpeJUWbqs=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=R1M+TrR4coeXurq9Y1dEZw4t5GjwB1T76ro7oCWQaWmaQ0BKM9HJoTla3spwU5yoH r6g1eNbGQcxVrLhAfmWZE0ldmJQVvFQ0iIaRMoXS023wf/ncR22CKjmZF6NKLucBu1 AeRuEteZwR8MjV9cECNIaKCT+nsuFBSIPOc/xFjc= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id WwUisRgl3yXv; Thu, 13 Oct 2016 23:55:28 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 13 Oct 2016 23:55:28 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 7047E4533E8; Thu, 13 Oct 2016 17:55:27 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 7047E4533E8 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5995E40D3585; Thu, 13 Oct 2016 17:55:27 -0400 (EDT) Date: Thu, 13 Oct 2016 17:55:24 -0400 (EDT) From: Paul Wouters To: Christian O'Flaherty In-Reply-To: <1E646ECC-BEBA-41C3-B691-C2599F39A396@isoc.org> Message-ID: References: <1E646ECC-BEBA-41C3-B691-C2599F39A396@isoc.org> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: codestand-develop@ietf.org, "secdir@ietf.org" Subject: Re: [secdir] CodeStand X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 21:55:38 -0000 On Thu, 13 Oct 2016, Christian O'Flaherty wrote: > In Berlin at the SecDir Meeting we presented a web site aimed to document coding projects based on IETF documents. Unfortunately, > the name we used was taken and we had to turn it off after the meeting.  > > The new name for the project is CodeStand and the new site is: https://codestand.ietf.org > > We’re now looking for volunteers willing to create “Code Requests” for their documents. Students will create “Projects" referencing > your “Code Request”. A project can also be created to document existing code without having a code request and it can be either open > source or proprietary code. > > The site will be announced to students next week at the Grace Hopper Celebration so we would like to have as many code requests as > possible available in CodeStand.  > > You can Sign In using your current Datatracker credentials. > > Please provide feedback to codestand-develop@ietf.org  > > The CodeStand team I added two projects for testing. I found the distinction between "protocol", "project" and "implementation" very confusing. For example, the RFC's you can "add" to it, apply to the "project" and not the "implementation". But implementations differ. Also, adding all the RFCs/drafts for libreswan was very painful. It was not always clear that you needed to push the "add" button to me either, and lost a few inputs when doing "update". Paul From nobody Thu Oct 13 22:06:09 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E81129687; Thu, 13 Oct 2016 22:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 LhjjG7l9grl4; Thu, 13 Oct 2016 22:06:07 -0700 (PDT) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 430D5129674; Thu, 13 Oct 2016 22:06:07 -0700 (PDT) Received: by mail-yb0-x236.google.com with SMTP id o189so13519929yba.1; Thu, 13 Oct 2016 22:06:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=VklkxCV1TbUuJx5r3SAxUFlWImUDwXWBOLcwV++tYiI=; b=l81N7SuO1dy4hHZMnkfamA48cpZGvY14jJ3TkhcWUoBrtZWd2aIZMyFXgRSOm7Nuvp ixfSp7EPan2H4vKgWo6byYudfoOiy20p7pp3uJpTzzeWcf/xR128ulJ4Bn+qxbtVZD+O ETLZIbsxEWI7ncbmnx8Jd2VfQFKhBgaR7qG1jllZGT652njK/fWfELi3yr5ozT1OnZyU EbgBLTKpQKgkvJld6H3yLT+909Bot1ALdVQWt+WWsUZ9UR9BLrzogVaW1U2VbIWjkPIV qmLRX3Q+2uy1bVGtKMwUWS2akAzbb37euX8wLT/pAVjIYEaE/fGN6bqKU9pgSADyZhE4 rUyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=VklkxCV1TbUuJx5r3SAxUFlWImUDwXWBOLcwV++tYiI=; b=g7S0Fpy4ZS+xxe6jQE8/OvrFksUG5W5gDTMLtSt5P3fozMGywO5f8eGIuphJgtw0hR hh392ipZ9SVEBBrfATjLeIihjQFOJkIlbN0zPEEjp0uDrUtb+nF2YmMiks334oqN/pGr J109/KX9Q81arX39wjpZyRQNMyn9L7Mz6ejAVujzllN0vqT4uSgrKisUtwynDe7MsO9D /D3IB8bmIEtfLC9sJmzrYQ3yO1FB+9g6oLAvdwA94mDAAzjgOleCdIzYD5dpM96fAPG2 pJHm7hNudwohlvjfcg46/zk1ZfalvLLvr1I53Q7uozWDB9RA0FyVpsXkKN2MY9rxJG7m sO/w== X-Gm-Message-State: AA6/9Rnxj2TozLtwkQM6+1KqyHgLA9Ng+RZg7Muo5EiP3W0INQ0vFdB0XnTDCcAl40/K5jD47/v132M0K+w4aw== X-Received: by 10.37.86.87 with SMTP id k84mr9154426ybb.37.1476421566438; Thu, 13 Oct 2016 22:06:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.228.196 with HTTP; Thu, 13 Oct 2016 22:06:06 -0700 (PDT) From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= Date: Thu, 13 Oct 2016 22:06:06 -0700 Message-ID: To: "secdir@ietf.org" , draft-ietf-webpush-protocol@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [secdir] Secdir review of draft-ietf-webpush-protocol X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 05:06:08 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes how a user agent can establish a relationship with a push service (a subscription) and then share that distribution node information with various applications. As such, the document is well written and has a comprehensive security considerations section. The only slight concern I have is related to the authorization of receiving push messages. The technique used is essentially bearer tokens (knowledge of a URL). It therefore seems as if unintended sharing of such a capability URL could cause other user agents to get access to push notifications. I wonder if the work around token binding in TLS (holder-of-key tokens) could be applicable here, at least in the future. -- Magnus From nobody Thu Oct 13 23:07:55 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360C012946A; Thu, 13 Oct 2016 23:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ALTzdCOkU6oI; Thu, 13 Oct 2016 23:07:49 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01A0512945B; Thu, 13 Oct 2016 23:07:48 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id t73so125850793oie.1; Thu, 13 Oct 2016 23:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=jcDbOiagz3BkBC0WD7hz8sFJMxtXcv7RY+lvgkjBuCY=; b=Khb9NX7DCn0Il1f47PthY/J4gGkROFvxxgrbXAOeZN2vEvFs21BkZvRMpXcELitFno vCSgxrwkQmTPGPneE6LuOZvnATSgAWujJQMvQaDqMkTlIcFpbRDOpZEGOLoLp8UVVjVL fu3M2w/0AQFZ/i9OAsugumWSqJ9pxkmDV3z1XyXNuce6L+IjNT6F7l2PNlQpxiD3zCrH TG1Fn/cFNoaFoPjBfZJmqtOwPrng1SnrsbDHw7Ngw6hVa3RFC56JNsl8gjm26EPoDtD4 gzHAP+nkHGJ3o1gy/s7OvxQ+LA5qEOhtZfP9BDCf8oCETqN4QCD+vl7EBjBkRgWYGIzL 4mog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=jcDbOiagz3BkBC0WD7hz8sFJMxtXcv7RY+lvgkjBuCY=; b=a1Z7hq9Xs0m+OWjgUX41YljeYJOoTlVkD6juKwvVWlpkZazkOZi7ZFeCPikvjRHdV8 4+46d7qbnemFwAIiYc8GpE4pkQXIiWXA6wq8rU4tmxUL9PFu5faFhY5mgPzfAJCl24M9 sjllfUDZF41E2cSbOJECzUwf5D7dvOlhe1Cju+oWW19cohOQpRMlH2sr3gG+9I2PZdug hPT/hJbi8PH3wUL2qlqVKYHK6cnRaOnNdPiMEexfxeee6C3mM0zrr7q/sM9Hy6EilQMw OqiGvp9eUwvWKRvbymq95qt4zhyj5zJInCcWrRjawj+NH9D6lizB6q7d6sYppitd+0GW RuRQ== X-Gm-Message-State: AA6/9RmSj8QunYLrfMGb1IwazuOMya0LUx3lxcXObXDgVPn0Vnww9NZGt0GE/Nc5QGuLmYsk44ovNPQRPBMJ8g== X-Received: by 10.202.5.195 with SMTP id 186mr6207420oif.99.1476425268136; Thu, 13 Oct 2016 23:07:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.232.201 with HTTP; Thu, 13 Oct 2016 23:07:47 -0700 (PDT) From: Radia Perlman Date: Thu, 13 Oct 2016 23:07:47 -0700 Message-ID: To: "secdir@ietf.org" , The IESG , draft-ietf-lisp-ddt.all@tools.ietf.org Content-Type: multipart/alternative; boundary=94eb2c18d24ea50df0053ecd0b7d Archived-At: Subject: [secdir] secdir review of draft-ietf-lisp-ddt-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 06:07:51 -0000 --94eb2c18d24ea50df0053ecd0b7d Content-Type: text/plain; charset=UTF-8 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes a hierarchical distributed database that helps a router find a mapping between what LISP calls an "endpoint identifier" and "routing locator". I have not been following LISP, and am not completely convinced that it solves a problem that can't be solved in other ways, but hierarchical distributed databases do seem like the right solution for lots of problems (like DNS). I do not recommend trying to dive into LISP starting with this document. Alia Atlas helpfully pointed me at the document "An architectural Introduction to the Locator/ID Separation Protocol". It would have been nice if this document referenced it, though it's not an RFC...it's an internet draft. Anyway, from a security point of view, it seems fine, mostly because it's pretty much copied all the security mechanisms from DNSSEC. I do wonder why a whole separate infrastructure would be necessary, and why this information couldn't simply be in DNS. Radia --94eb2c18d24ea50df0053ecd0b7d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have reviewed this docu= ment as part of the security directorate's
ongoing effort to review all IETF= documents being processed by the
IESG. These comments were written primarily fo= r the benefit of the
security area directors. Document editors and WG chairs sho= uld treat
these comments just like any other last call comments.
=
This document describes a hierarchical distributed database th= at helps a router find a mapping between what LISP calls an "endpoint = identifier" and "routing locator".

I have not been following LISP, and am not completely convinced that i= t solves a problem that can't be solved in other ways, but hierarchical= distributed databases do seem like the right solution for lots of problems= (like DNS).

<= /div>
I do not recommend trying to div= e into LISP starting with this document.=C2=A0 Alia Atlas helpfully pointed= me at the document "An architectural Introduction to the Locator/ID S= eparation Protocol".=C2=A0 It would have been nice if this document re= ferenced it, though it's not an RFC...it's an internet draft.

Anyway, from a security point of view, it seems fi= ne, mostly because it's pretty much copied all the security mechanisms = from DNSSEC. I do wonder why a whole separate infrastructure would be neces= sary, and why this information couldn't simply be in DNS.
<= div>
Radia
=C2=A0
--94eb2c18d24ea50df0053ecd0b7d-- From nobody Fri Oct 14 04:10:26 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B341294AB for ; Fri, 14 Oct 2016 04:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 kTflfoz4vCfW for ; Fri, 14 Oct 2016 04:10:23 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88198129445 for ; Fri, 14 Oct 2016 04:10:23 -0700 (PDT) Received: by mail-pa0-x231.google.com with SMTP id rz1so46772919pab.1 for ; Fri, 14 Oct 2016 04:10:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=OlAD8qpDWLaYL23O3Cwh3I+lr/hYLh1+DuN9PfVe1aM=; b=zaM+cozAv27pIj9bdBBGvCvZWdQ7Zl+coJqd1RjYVvWN3g0PLSVsX0DLiVtaJp/t2O dMLkNvY7BTeSkEfjhR2mz+wSkpzySbU37/KnSDKEWacEvONY/1MJs3aDs52ruhLP9mJq yNlbTChO1JJ12RJyI9ZFRHFIhx2wfvWtv1ELMJfOybHJ13+M5AoW7CXW1Vokqs118Mbl pliCuFVXVuNy33C90sg6KvbJTPJfPu/jxhY1QIZPBiDB/o9y1WVrJuyhADHZQGmkI+Se N4abmI+wacYC8UNCh/RgkcD7x7KK6esMdVOxW3phQWwDQImvpk048Ut4J10WLVzTlL2i x7JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=OlAD8qpDWLaYL23O3Cwh3I+lr/hYLh1+DuN9PfVe1aM=; b=EflY3EK7B8/DIXuBuz4/pIvq+16s6/5doDCiJ6csI6pni3lxMoaPaAHvKTQNIgL0b4 ADiWib/MLyEFwNMwEeDkG5Uy9N4hnWGyKciE7eIRxGiD4tESPcpNDant94yhgDQ357GL RXEbrSWFDD82tbKt7SA5eD5gMr88KvZdfa0mwDdlLAl0dS7nu+4Gu6zQ7069yjJ0e8Hf cTCKEjoLaEaKdz1+INS+c10CR+kARnAlkdY/i5aqBZZkLraIWjDoAUgrMc1M8TVhl6kh kDj8khfpSI7WOf3B4qJJPZKO//VXwgnJZAa0RUfXaGjP74xEvK/n8UA/ixeUwwpFFBF4 uySg== X-Gm-Message-State: AA6/9Rl6QZpGD5ArLCaukj3vfuTi+PRrqAznKC5iVxI1dRMSOYqhxrsTrCaUHulJnpGchQ== X-Received: by 10.66.50.234 with SMTP id f10mr14404588pao.30.1476443423004; Fri, 14 Oct 2016 04:10:23 -0700 (PDT) Received: from [172.17.200.19] (meade.intuit.com. [199.16.140.27]) by smtp.gmail.com with ESMTPSA id e6sm26653223pfb.57.2016.10.14.04.10.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Oct 2016 04:10:21 -0700 (PDT) To: IETF Security Directorate , draft-bbf-bbf-urn.all@tools.ietf.org From: Yaron Sheffer Message-ID: Date: Fri, 14 Oct 2016 14:10:16 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [secdir] SecDir review of draft-bbf-bbf-urn-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 11:10:25 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary This is just a URN registration, with no relevant security considerations. Details To prevent "URN squatting", I would recommend to include an explanation why a name that's not trivially associated with "Broadband Forum" is claimed here, namely "dslforum-org". Although 2 minutes of research suffice to find the answer. Thanks, Yaron From nobody Fri Oct 14 09:09:12 2016 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B33129862; Fri, 14 Oct 2016 09:04:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1476461076; bh=4aCJiF21+mQkF9qx+y5L9LOx+gNHh0HOZq3L/cCYdV4=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=s6nzSWQRTas6af7YkzLcGI5nDFQT3wzfq9szfkLKQsjPeKjNvdsPt5JofgD7tx2UB MpGFvoKJ5o1uL2622GNirGpTjT843deMo09edj64Sys6d29knTWSX3M5kdsCkZYIxC qs9fjKM1apePtt/gUbnFBF2kMPwuviGaCzxNAMS4= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 72CD3129854 for ; Fri, 14 Oct 2016 09:04:28 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Reply_to: Message-ID: <147646106846.18628.17227237498582044071.idtracker@ietfa.amsl.com> Date: Fri, 14 Oct 2016 09:04:28 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.17 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 14 Oct 2016 09:09:10 -0700 Subject: [secdir] [new-work] WG Review: Security Events (secevent) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 16:04:37 -0000 A new IETF WG has been proposed in the Security Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2016-10-24. Security Events (secevent) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: TBD Assigned Area Director: Kathleen Moriarty Security Area Directors: Stephen Farrell Kathleen Moriarty Mailing list: Address: id-event@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/id-event Archive: https://mailarchive.ietf.org/arch/browse/id-event/ Charter: https://datatracker.ietf.org/doc/charter-ietf-secevent/ Many identity related protocols require a mechanism to convey messages between systems in order to prevent or mitigate security risks, or to provide out-of-band information as necessary. For example, an OAuth authorization server, having received a token revocation request (RFC7009) may need to inform affected resource servers; a cloud provider may wish to inform another cloud provider of suspected fraudulent use of identity information; an identity provider may wish to signal a session logout to a relying party. It is expected that several identity and security working groups and organizations will use Identity Event Tokens to describe area-specific events such as: SCIM Provisioning Events, OpenID RISC Events, and OpenID Connect Backchannel Logout, among others. The Security Events working group will produce a standards-track Event Token specification that includes: - A JWT extension for expressing security events - A syntax that enables event-specific data to be conveyed This Event Token specification will be event transport independent. The working group will also develop a simple standards-track Event Delivery specification that includes: - A method for delivering events using HTTP POST (push) - Metadata for describing event feeds - Methods for subscribing to and managing event feeds - Methods for validating event feed subscriptions Milestones: Oct 2016 - Initial adoption of event token and event delivery drafts Feb 2017 - WG last call of event token draft Apr 2017 - Event token draft to IESG as a Proposed Standard Jul 2017 - WG last call of event delivery draft Sep 2017 - Event delivery draft to IESG as a Proposed Standard Nov 2017 - Recharter or Conclude _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Oct 14 11:08:20 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB549126579; Fri, 14 Oct 2016 11:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.517 X-Spam-Level: X-Spam-Status: No, score=-17.517 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 EinUVMg4JSP5; Fri, 14 Oct 2016 11:08:17 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E455129618; Fri, 14 Oct 2016 11:08:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9706; q=dns/txt; s=iport; t=1476468496; x=1477678096; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3VnEryZPbnJnZLttZDGmrtxYQIfMfWuwb+GprBdNHsg=; b=d32cFJ3OFsrY47S8/DzaiIatedNKWaTDPYx7MzhmF1FUvAigoHKVevfn 7O6RYdZHSVrR+uu8wsKs7HVq8fDRdY8iiB1hg6PvBf+b0HuxqUZuW4XGn evxC/aHLUxqPoToltgPE924hao4eK/dSPQMb+POLeorNdARTD8FFXKfSg I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AqAQC1HgFY/4sNJK1ZAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM8AQEBAQEdV3wHjS2XBYddjFuCCB0NhS5KAhqBfTgUAQIBAQE?= =?us-ascii?q?BAQEBXieEYQEBAQMBAQEBIBE6CwULAgEIDgoCAiYCAgIfBgsVEAIEDgWIOAMPC?= =?us-ascii?q?A61fokPDYNvAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYEHhzMIglCCR4FSEQECBBY?= =?us-ascii?q?XCiaCPSyCLwWZUTUBhieGTIMMgW5Oh1CFaYhlhBSDfgEeNlKCdQUcgVNyhhWBI?= =?us-ascii?q?IEAAQEB?= X-IronPort-AV: E=Sophos;i="5.31,346,1473120000"; d="scan'208";a="335886894" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Oct 2016 18:08:15 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u9EI8Fjn031384 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 14 Oct 2016 18:08:15 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 14 Oct 2016 14:08:14 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1210.000; Fri, 14 Oct 2016 14:08:14 -0400 From: "Brian Weis (bew)" To: Yoav Nir Thread-Topic: [secdir] SecDir Review of draft-weis-gdoi-iec62351-9-08 Thread-Index: AQHSHl3IqR3ruc/h1Ue4GXf9RA8ZO6Coki6A Date: Fri, 14 Oct 2016 18:08:14 +0000 Message-ID: <29AF5DAD-3197-4650-9ED8-37FE45D6B5B5@cisco.com> References: <834C9D97-98D2-49EB-BD34-5C28C84AB10F@gmail.com> In-Reply-To: <834C9D97-98D2-49EB-BD34-5C28C84AB10F@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.191.163] Content-Type: text/plain; charset="utf-8" Content-ID: <06CD4822AE483949BD0431A01D084430@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-weis-gdoi-iec62351-9.all@tools.ietf.org" , The IESG , secdir Subject: Re: [secdir] SecDir Review of draft-weis-gdoi-iec62351-9-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 18:08:19 -0000 SGkgWW9hdiwNCg0KVGhhbmtzIGZvciB5b3VyIGNhcmVmdWwgcmV2aWV3LiBBIGxhc3QgbWludXRl IGNoYW5nZSBiZWZvcmUgcHVibGlzaGluZyAtMDggY2F1c2VkIHNvbWUgaW5jb25zaXN0ZW5jaWVz IHRoYXQgeW91IGhhdmUgbm90ZWQgYmVsb3csIGFuZCBJ4oCZdmUgYWRkZWQgc29tZSBjb21tZW50 cyBpbmxpbmUgYWRkcmVzc2luZyB0aG9zZSBpbmNvbnNpc3RlbmNpZXMuDQoNCj4gT24gT2N0IDQs IDIwMTYsIGF0IDk6MzggQU0sIFlvYXYgTmlyIDx5bmlyLmlldGZAZ21haWwuY29tPiB3cm90ZToN Cj4gDQo+IEhpLg0KPiANCj4gSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBv ZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxs IElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4NCj4gVGhlc2UgY29t bWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3Vy aXR5IGFyZWEgZGlyZWN0b3JzLg0KPiBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hv dWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNv bW1lbnRzLg0KPiANCj4gU3VtbWFyeTogUmVhZHkgd2l0aCBhIHF1ZXN0aW9uDQo+IA0KPiBUaGUg ZHJhZnQgZGVzY3JpYmVzIHVzaW5nIEdET0kgd2l0aCBzb21lIGV4dGVuc2lvbnMgdG8gdHJhbnNw b3J0IGtleWluZyBtYXRlcmlhbCBmb3IgdGhlIElFQyA2MTg1MCBwb3dlciB1dGlsaXR5IGF1dG9t YXRpb24gZmFtaWx5IG9mIHN0YW5kYXJkcy4NCj4gDQo+IEkgaGF2ZSBwcmV2aW91c2x5IHJldmll d2VkIHZlcnNpb24gLTAyIG9mIHRoZSBkcmFmdCB0aHJlZSB5ZWFycyBhZ28gKFsxXSkuIExhdGVy IHZlcnNpb25zIGFkZHJlc3NlZCBteSBpc3N1ZXMgYWJvdXQgdGhlIGRvY3VtZW50IGJlaW5nIHRv byBvcGFxdWUgZm9yIHBlb3BsZSBub3QgdmVyc2VkIGluIElFQyBwcm90b2NvbHMgYW5kIHRlcm1p bm9sb2d5LiBJdCBpcyBzdGlsbCByYXRoZXIgaGFyZCB0byByZWFkIHdpdGhvdXQgdGhlIHJlbGV2 YW50IGJhY2tncm91bmQsIGJ1dCB0aGF0IGlzIHRvIGJlIGV4cGVjdGVkIGluIGEgZG9jdW1lbnQg dGFyZ2V0ZWQgYXQgYSB2ZXJ5IHNwZWNpZmljIGF1ZGllbmNlICh3aGljaCBJIGFtIG5vdCBwYXJ0 IG9mKS4NCj4gDQo+IFRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIHBvaW50cyB0 byB0aGUgc2VjdGlvbiBpbiBSRkMgNjQwNyAoR0RPSSkuIEFkZGl0aW9uYWwgcGFyYWdyYXBocyBw b2ludCBvdXQgdGhhdCBtZXNzYWdlIGF1dGhlbnRpY2F0aW9uIGlzIG1hbmRhdG9yeSwgd2hpbGUg Y29uZmlkZW50aWFsaXR5IGlzIG9wdGlvbmFsLiAgQW5kIHlldCB0aGUgc2FtZSBwYXJhZ3JhcGgg bWFrZXMgY29uZmlkZW50aWFsaXR5IGEgU0hPVUxEIGlmIHRoZSBwYWNrZXRzIGFyZSBleHBlY3Rl ZCB0byB0cmF2ZXJzZSB0aGUgcHVibGljIEludGVybmV0Lg0KDQpUaGlzIHRleHQgd2FzIG5vdCBw cmVjaXNlbHkgbWF0Y2hpbmcgdGhlIG9wZXJhdGlvbmFsIHJlYWxpdGllcyBvZiBuZXR3b3JrcyB3 aGVyZSB0aGlzIHN0YW5kYXJkIHdpbGwgYmUgdXNlZC4gVGhpcyBiZWNhbWUgZXZlbiBtb3JlIGFw cGFyZW50IHdoZW4gYWRkcmVzc2luZyB0aGUgbGFzdCBpc3N1ZSB0aGF0IHlvdSBub3RlZCBiZWxv dy4gIEluIHJlYWxpdHksIHRoZXJlIGFyZSBhIG51bWJlciBvZiBvcGVyYXRpb25hbCBlbnZpcm9u bWVudHMgd2hlcmUgdGhlc2UgZGV2aWNlcyB3aWxsIGJlIGRlcGxveWVkOiBpbiBzb21lIGNhc2Vz IHRoZXkgYXJlIGluIGEgcHJpdmF0ZSBuZXR3b3JrIHdoZXJlIHRyYWZmaWMgZG9lcyBub3QgbmVl ZCB0byBwcm90ZWN0ZWQgb24gYSBwcml2YXRlIG5ldHdvcmssIGFuZCBhIHNpdGUgc2VjdXJpdHkg cG9saWN5IHdpbGwgcHJvdGVjdCB0aGUgdHJhZmZpYyB3aXRoIG5ldHdvcmstbGV2ZWwgZW5jcnlw dGlvbiAoc3VjaCBhcyBhbiBJUHNlYyB0dW5uZWwpIHdoZW4gaXQgbGVhdmVzIHRoZSBwcml2YXRl IG5ldHdvcmsuIEluIG90aGVyIGNhc2VzLCB0aGUgYXBwbGljYXRpb24gdHJhZmZpYyBuZWVkcyB0 byBiZSBwcm90ZWN0ZWQgYXQgdGhlIGVuZCBob3N0LiANCg0KV2hpbGUgYXV0aGVudGljYXRpb24g aXMgYSBmaXJtIHJlcXVpcmVtZW50IHdoZW4gYSBjaXBoZXIgaXMgdXNlZCwgdGhlcmUgYXJlIGNh c2VzIHdoZXJlIG5laXRoZXIgYXV0aGVudGljYXRpb24gbm9yIGNvbmZpZGVudGlhbGl0eSBpcyBh YnNvbHV0ZWx5IHJlcXVpcmVkLiBJbiBhIHNpbXBsZSB3b3JsZCB0aGlzIHdvdWxkIHJlc3VsdCBp biBhIGRpc3RyaWJ1dGVkIHBvbGljeSB3aGVyZSBhIGdyb3VwIG1lbWJlciB3ZXJlIGNvbmZpZ3Vy ZWQgd2l0aCBleGFjdGx5IHdoaWNoIGZsb3dzIGRpZCBub3QgcmVxdWlyaW5nIHByb3RlY3Rpb24g YW5kIGRvZXMgbm90IG5lZWQgdG8gYXNrIGEgY2VudHJhbCBHcm91cCBDb250cm9sbGVyL0tleSBT ZXJ2ZXIgKEdDS1MpIGhvdyB0byBwcm90ZWN0IHRoZSBmbG93LiBCdXQgYSBzeXN0ZW0gdXNpbmcg YSBjZW50cmFsaXplZCBrZXkgbWFuYWdlbWVudCBzeXN0ZW0gZ2VuZXJhbGx5IGlzIG9uZSB3aGVy ZSBjb25maWd1cmluZyBzdWNoIGdyYW51bGF0ZWQgZGlzdHJpYnV0ZWQgcG9saWN5IGlzIG5vdCBv cGVyYXRpb25hbGx5IGZlYXNpYmxlLiBUaGVyZWZvcmUsIGl0IGNhbiBtYWtlIHNlbnNlIGZvciB0 aGUgZ3JvdXAgbWVtYmVyIHRvIGFzayB0aGUgR0NLUyBvbiBhIGZsb3cgYnkgZmxvdyBiYXNpcyBo b3cgdG8gcHJvdGVjdCBpdCwgYW5kIHNvbWV0aW1lcyBnZXQgYSByZXNwb25zZSB0aGF0IGl0IGlz IG5vdCB0byBiZSBwcm90ZWN0ZWQuIFRoaXMgaXMgZXNwZWNpYWxseSB0cnVlIGR1cmluZyBhIG1p Z3JhdGlvbiBwZXJpb2QsIHdoZXJlIHRoZSBwb2xpY3kgZm9yIGVhY2ggZmxvdyBpcyBpbmRpdmlk dWFsbHkgY29udmVydGVkIGZyb20gdW5wcm90ZWN0ZWQgdG8gcHJvdGVjdGVkIGJ5IHRoZSBHQ0tT IGFkbWluaXN0cmF0b3IuDQoNCkFkZHJlc3NpbmcgdGhpcyBuZWVkIHJlcXVpcmVzIHJlLWluc3Rh dGluZyB0aGUgTk9ORSB2YWx1ZSBpbiBib3RoIEF1dGhlbnRpY2F0aW9uIEFsZ29yaXRobSBhbmQg Q29uZmlkZW50aWFsaXR5IEFsZ29yaXRobSBsaXN0cy4gKFRoZXNlIHZhbHVlcyBoYWQgYmVlbiBw cmVzZW50IGluIC0wNykuICBXZSBhbHNvIHByb3Bvc2UgdGhlIGZvbGxvd2luZyBhZGRpdGlvbnMg dG8gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gdG8gY2xhcmlmeSBob3cgdGhl c2UgYXJlIHVzZWQuIERvZXMgaXQgc2VlbSBhZGVxdWF0ZSB0byB5b3U/DQoNCiAgIElFQyA2MjM1 MSBTZWN1cml0eSBTZXJ2aWNlcyBkZXNjcmliZXMgYSB2YXJpZXR5IG9mIHBvbGljeSBjaG9pY2Vz IGZvcg0KICAgcHJvdGVjdGluZyBuZXR3b3JrIHRyYWZmaWMsIGluY2x1ZGluZyB0aGUgb3B0aW9u IG9mIHNwZWNpZnlpbmcgbm8NCiAgIHByb3RlY3Rpb24gYXQgYWxsLiAgVGhpcyBpcyBlbmFibGVk IHdpdGggdGhlIHVzZSBvZiBOT05FIGFzIGFuDQogICBBdXRoZW50aWNhdGlvbiBBbGdvcml0aG0g YW5kL29yIENvbmZpZGVudGlhbGl0eSBBbGdvcml0aG0uICBUaGUNCiAgIGZvbGxvd2luZyBndWlk YW5jZSBpcyBnaXZlbiByZWdhcmRpbmcgdGhlIHVzZSBvZiBOT05FLg0KDQogICBvICBTZXR0aW5n IGJvdGggQXV0aGVudGljYXRpb24gQWxnb3JpdGhtIGFuZCBDb25maWRlbnRpYWxpdHkNCiAgICAg IEFsZ29yaXRobSB0byBOT05FIGlzIHBvc3NpYmxlLCBidXQgTk9UIFJFQ09NTUVOREVELiAgU2V0 dGluZyBzdWNoDQogICAgICBhIHBvbGljeSBpcyBzb21ldGltZXMgbmVjZXNzYXJ5IGR1cmluZyBh IG1pZ3JhdGlvbiBwZXJpb2QsIHdoZW4NCiAgICAgIHRyYWZmaWMgaXMgYmVpbmcgcHJvdGVjdGVk IGluY3JlbWVudGFsbHkgYW5kIHNvbWUgdHJhZmZpYyBoYXMgbm90DQogICAgICB5ZXQgYmVlbiBz Y2hlZHVsZWQgZm9yIHByb3RlY3Rpb24uICBBbHRlcm5hdGl2ZWx5LCBzaXRlIHNlY3VyaXR5DQog ICAgICBwb2xpY3kgZm9yIHNvbWUgcGFja2V0IGZsb3dzIHJlcXVpcmVzIGluc3BlY3Rpb24gb2Yg cGFja2V0IGRhdGEgb24NCiAgICAgIHRoZSBwcml2YXRlIG5ldHdvcmsgZm9sbG93ZWQgYnkgbmV0 d29yay1sYXllciBlbmNyeXB0aW9uIGJlZm9yZQ0KICAgICAgZGVsaXZlcnkgdG8gYSBwdWJsaWMg bmV0d29yay4NCg0KICAgbyAgU2V0dGluZyB0aGUgQ29uZmlkZW50aWFsaXR5IEFsZ29yaXRobSB0 byBOT05FLCBidXQgc2V0dGluZyB0aGUNCiAgICAgIEF1dGhlbnRpY2F0aW9uIEFsZ29yaXRobSB0 byBhIE1BQyBjYW4gYmUgYW4gYWNjZXB0YWJsZSBwb2xpY3kgaW4NCiAgICAgIHRoZSBmb2xsb3dp bmcgY29uZGl0aW9uczogdGhlIGRpc2Nsb3NlZCBpbmZvcm1hdGlvbiBpbiB0aGUgZGF0YQ0KICAg ICAgcGFja2V0cyBpcyBjb21wcmlzZWQgb2YgcmF3IGRhdGEgdmFsdWVzLCBhbmQgdGhlIGRpc2Ns b3N1cmUgb2YgdGhlDQogICAgICBkYXRhIGZpbGVzIGlzIGJlbGlldmVkIHRvIGJlIG9mIG5vIG1v cmUgdmFsdWUgdG8gYW4gb2JzZXJ2ZXIgdGhhbg0KICAgICAgdHJhZmZpYyBhbmFseXNpcyBvbiB0 aGUgZnJlcXVlbmN5IGFuZCBzaXplIG9mIHBhY2tldHMgcHJvdGVjdGVkDQogICAgICBmb3IgY29u ZmlkZW50aWFsaXR5LiAgQWx0ZXJuYXRpdmVseSwgc2l0ZSBzZWN1cml0eSBwb2xpY3kgZm9yIHNv bWUNCiAgICAgIHBhY2tldCBmbG93cyByZXF1aXJlcyBpbnNwZWN0aW9uIG9mIHBhY2tldCBkYXRh IG9uIHRoZSBwcml2YXRlDQogICAgICBuZXR3b3JrIGZvbGxvd2VkIGJ5IG5ldHdvcmstbGF5ZXIg ZW5jcnlwdGlvbiBiZWZvcmUgZGVsaXZlcnkgdG8gYQ0KICAgICAgcHVibGljIG5ldHdvcmsuDQoN CiAgIG8gIFNldHRpbmcgdGhlIEF1dGhlbnRpY2F0aW9uIEFsZ29yaXRobSB0byBOT05FLCBidXQg c2V0dGluZyB0aGUNCiAgICAgIENvbmZpZGVudGlhbGl0eSBBbGdvcml0aG0gdG8gYW4gYWxnb3Jp dGhtIHRoYXQgZG9lcyBub3QgaW5jbHVkZXMNCiAgICAgIGF1dGhlbnRpY2F0aW9uIGlzIG5vdCBz YWZlLCBhbmQgTVVTVCBOT1QgYmUgc3BlY2lmaWVkLg0KDQoNCj4gVGhlIGxhc3Qgc2VudGVuY2Ug c2F5cyB0aGF0IDEyOC1iaXQgQUVTLUNCQyBpcyBnb29kIGVub3VnaCBmb3IgdGhlIGZvcmVzZWVh YmxlIGZ1dHVyZSwgImJ1dCBzb21lIHNlY3VyaXR5IHBvbGljaWVzIG1heSByZXF1aXJlIHRoZSB1 c2Ugb2YgQUVTLUNCQy0yNTYu4oCdIFRoZXJlIGlzIG5vIG1lbnRpb24gb2Ygd2h5IHN1Y2ggcG9s aWNpZXMgbWF5IHJlcXVpcmUgdGhpcy4gVGhlIHVzdWFsIHJlYXNvbiBpcyB0byBwcm90ZWN0IGFn YWluc3QgZnV0dXJlIGF0dGFja3MgYnkgcXVhbnR1bSBjb21wdXRlcnMsIGJ1dCBJIHRoaW5rIGl0 4oCZcyBmaW5lIHRvIGxlYXZlIHRoYXQgb3V0Lg0KPiANCj4gTXkgcXVlc3Rpb24gaXMgYWJvdXQg dGhlIElFQy02MTg1MCBTQSBURUsgUGF5bG9hZCBkZXNjcmliZWQgaW4gRmlndXJlIDQgaW4gc2Vj dGlvbiAyLjIuIEl0IGhhcyBzZXBhcmF0ZSBmaWVsZHMgZm9yIEF1dGggQWxnIGFuZCBFbmMgQWxn LiBUaGUgRW5jIEFsZyBmaWVsZCBoYXMgNCBwb3NzaWJsZSB2YWx1ZXMgZGVzY3JpYmVkIGluIHNl Y3Rpb24gMi4yLjMsIGluY2x1ZGluZyBBRVMtR0NNLTEyOCBhbmQgQUVTLUdDTS0yNTYuIEFFUy1H Q00gaXMgYW4gQUVBRCBhbGdvcml0aG0uIEFzIHN1Y2ggaXQgc2hvdWxkIG5vdCBiZSB1c2VkIGlu IGNvbmp1bmN0aW9uIHdpdGggYSBNQUMgYWxnb3JpdGhtLiBPdGhlciBwcm90b2NvbHMgZWl0aGVy IG9taXQgdGhlIE1BQyBhbGdvcml0aG0gd2hlbiBhbiBBRUFEIGlzIHVzZWQsIG9yIGNyZWF0ZSBh IHNwZWNpYWwg4oCYbm9uZeKAmSB2YWx1ZSBmb3Igc3VjaCBjYXNlcy4gSGVyZSB0aGVyZSBhcmUg bm8gTm9uZSB2YWx1ZSAodGhvdWdoIHRoZXJlIGFyZSB0d28gUmVzZXJ2ZWQgdmFsdWVzIGluIHRo ZSBJQU5BIGNvbnNpZGVyYXRpb25zIHNlY3Rpb24pLiBUaGlzIG1ha2VzIGl0IHBvc3NpYmxlIHRv IGhhdmUgU0EgVEVLIHBheWxvYWRzIHdpdGggQUVTLUdDTS0xMjggYW5kIEhNQUMtU0hBMjU2LTEy OC4gIEhvdyBkbyB5b3UgZXZlbiBkbyB0aGF0PyBBbmQgd2h5Pw0KDQpUaGUgcmVtb3ZhbCBvZiB0 aGUgTk9ORSB2YWx1ZSBmcm9tIHRoZSBBdXRoZW50aWNhdGlvbiBBbGdvcml0aG0gbGlzdCAocHJl c2VudCBpbiAtMDcpIGNhdXNlZCB0aGlzIHByb2JsZW0sIGp1c3QgYXMgeW91IGltcGx5LiBJdCB3 aWxsIGJlIHJlaW5zdGF0ZWQsIGFjY29tcGFuaWVkIGJ5IHNvbWUgcHJlY2lzZSB0ZXh0IGRlc2Ny aWJpbmcgd2l0aCB3aGljaCBDb25maWRlbnRpYWxseSBBbGdvcml0aG1zIE1VU1QgYW5kIE1VU1Qg bm90IGJlIGFjY29tcGFuaWVkIGJ5ICB0aGUgTk9ORSBBdXRoZW50aWNhdGlvbiBBbGdvcml0aG0g dmFsdWUuIEkuZS4sIHRoZSBkZWZpbmVkIEFFUy1DQkMgYWxnb3JpdGhtcyBNVVNUIE5PVCBiZSB1 c2VkIHdpdGggYSBOT05FIEF1dGhlbnRpY2F0aW9uIEFsZ29yaXRobSwgYW5kIEFFUy1HQ00gYWxn b3JpdGhtcyBNVVNUIGJlIHVzZWQgd2l0aCBhbiBBdXRoZW50aWNhdGlvbiBBbGdvcml0aG0uIFRo ZSBleGFtcGxlIHBheWxvYWRzIGluIEFwcGVuZGl4IEEgd2lsbCBhbHNvIGJlIGNvcnJlY3RlZC4N Cg0KVGhhbmtzLA0KQnJpYW4NCg0KPiANCj4gWW9hdg0KPiANCj4gWzFdIGh0dHBzOi8vbWFpbGFy Y2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc2VjZGlyLy1DNV9YamZUazQyRE8wMTNEa2JBNnEwdFFt QQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBz ZWNkaXIgbWFpbGluZyBsaXN0DQo+IHNlY2RpckBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NlY2Rpcg0KPiB3aWtpOiBodHRwOi8vdG9vbHMuaWV0Zi5v cmcvYXJlYS9zZWMvdHJhYy93aWtpL1NlY0RpclJldmlldw0KDQotLSANCkJyaWFuIFdlaXMNClNl Y3VyaXR5LCBDU0csIENpc2NvIFN5c3RlbXMNClRlbGVwaG9uZTogKzEgNDA4IDUyNiA0Nzk2DQpF bWFpbDogYmV3QGNpc2NvLmNvbQ0KDQo= From nobody Fri Oct 14 12:07:13 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF1C129793; Fri, 14 Oct 2016 12:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 AUf2Q9Sa1P_E; Fri, 14 Oct 2016 12:07:04 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE1601293F2; Fri, 14 Oct 2016 12:07:03 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id b186so125169839vkb.1; Fri, 14 Oct 2016 12:07:03 -0700 (PDT) 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; bh=IGB1CIa44EsrT58mbTNwtiqMLyMBUOWAayeSwHzEzPk=; b=WGAocgugt9M148c/hVClVKoecrZo6HuACFwywMQLRgC8d3K2AbaU143LvjQJSOHTxw uFEXjwjsEogeloeRm11k5EE8ue4W/lHxBxhoBEETN5U/0buqGX2AFFqIjfInvMOdoLGB l2c7nG9kWOEX1o2X36A+WNAnVIgJ0UGw9PTgeub50p6pLhsNmAGAKGLpvrxWmTB9Wivr PBGBvMngUKTithJHxEJ68Vs7Nh3gAvHBb5fza6HnfTfgJjA0t90exjfv9/kxA2n4pybl g3rd37+WLFwMJVRvLZakxBb3qJL1WGZu/CTfWy6et4sUp8Y5+Ys5DSQox4C0m9gLJK/r Lgfw== 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; bh=IGB1CIa44EsrT58mbTNwtiqMLyMBUOWAayeSwHzEzPk=; b=QS8d3CswvYM/U2RG3TNMA61Io0lgJ8cxmZV0VeG8I+ZZd7OqlZOl4sG1W7EzFCPVe0 MEbZ+TjBIuP9zQZq3pS8DOdV5VH9ZZ+yMvAxyZAG1EBWxZldoRmfBkcKOwnxYv+BGJtj wk9zaxlN9mGsJvnGsOt6Aksn896QM65HcrEyWge1fVwkM08Syd0UmU2RlJ6YHkhn+6gJ 5W3c5Rl9mD0cZOcIKBLdw0s9uZSF/ej+gTsQoEtjR15lieMX/9dsg1Gz/TiYlqoZrPaS rBO3DDamJgrCXMR/Ynypbz32jUwl7n1HTywXMe/F6mXHQj+croFdXzk2yBuyzuBOVVLf SD3g== X-Gm-Message-State: AA6/9RnyVYsP8MtdKAswJOu8oDr1yYcwOyHdw6EkIH5DnyGutCDmtfaAAjbEcKO1Qm0FdzRNYN7saNGhRil25A== X-Received: by 10.31.73.71 with SMTP id w68mr8199362vka.13.1476472023000; Fri, 14 Oct 2016 12:07:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.68 with HTTP; Fri, 14 Oct 2016 12:07:02 -0700 (PDT) In-Reply-To: <29AF5DAD-3197-4650-9ED8-37FE45D6B5B5@cisco.com> References: <834C9D97-98D2-49EB-BD34-5C28C84AB10F@gmail.com> <29AF5DAD-3197-4650-9ED8-37FE45D6B5B5@cisco.com> From: Kathleen Moriarty Date: Fri, 14 Oct 2016 15:07:02 -0400 Message-ID: To: "Brian Weis (bew)" Content-Type: multipart/alternative; boundary=001a1148d00a73b5b6053ed7ee5e Archived-At: Cc: "draft-weis-gdoi-iec62351-9.all@tools.ietf.org" , The IESG , secdir Subject: Re: [secdir] SecDir Review of draft-weis-gdoi-iec62351-9-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 19:07:08 -0000 --001a1148d00a73b5b6053ed7ee5e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Brian & Yoav, Thank you for your review, Yoav and for catching a problem caused by my review and a question I asked to see if the none was needed or not. This is an important change and as such, I'd like to see the updated text published now rather than after last call ends so any other reviews are able to see this change. The shepherd, Brian and I all reviewed the text. If Yoav is able to respond quickly, then I'd include any other changes if they are needed, otherwise, it owuld be good to publish this updated version and hold any other changes until after the last call period ends. Thank you, Kathleen On Fri, Oct 14, 2016 at 2:08 PM, Brian Weis (bew) wrote: > Hi Yoav, > > Thanks for your careful review. A last minute change before publishing -0= 8 > caused some inconsistencies that you have noted below, and I=E2=80=99ve a= dded some > comments inline addressing those inconsistencies. > > > On Oct 4, 2016, at 9:38 AM, Yoav Nir wrote: > > > > Hi. > > > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > > These comments were written primarily for the benefit of the security > area directors. > > Document editors and WG chairs should treat these comments just like an= y > other last call comments. > > > > Summary: Ready with a question > > > > The draft describes using GDOI with some extensions to transport keying > material for the IEC 61850 power utility automation family of standards. > > > > I have previously reviewed version -02 of the draft three years ago > ([1]). Later versions addressed my issues about the document being too > opaque for people not versed in IEC protocols and terminology. It is stil= l > rather hard to read without the relevant background, but that is to be > expected in a document targeted at a very specific audience (which I am n= ot > part of). > > > > The Security Considerations section points to the section in RFC 6407 > (GDOI). Additional paragraphs point out that message authentication is > mandatory, while confidentiality is optional. And yet the same paragraph > makes confidentiality a SHOULD if the packets are expected to traverse th= e > public Internet. > > This text was not precisely matching the operational realities of network= s > where this standard will be used. This became even more apparent when > addressing the last issue that you noted below. In reality, there are a > number of operational environments where these devices will be deployed: = in > some cases they are in a private network where traffic does not need to > protected on a private network, and a site security policy will protect t= he > traffic with network-level encryption (such as an IPsec tunnel) when it > leaves the private network. In other cases, the application traffic needs > to be protected at the end host. > > While authentication is a firm requirement when a cipher is used, there > are cases where neither authentication nor confidentiality is absolutely > required. In a simple world this would result in a distributed policy whe= re > a group member were configured with exactly which flows did not requiring > protection and does not need to ask a central Group Controller/Key Server > (GCKS) how to protect the flow. But a system using a centralized key > management system generally is one where configuring such granulated > distributed policy is not operationally feasible. Therefore, it can make > sense for the group member to ask the GCKS on a flow by flow basis how to > protect it, and sometimes get a response that it is not to be protected. > This is especially true during a migration period, where the policy for > each flow is individually converted from unprotected to protected by the > GCKS administrator. > > Addressing this need requires re-instating the NONE value in both > Authentication Algorithm and Confidentiality Algorithm lists. (These valu= es > had been present in -07). We also propose the following additions to the > Security Considerations section to clarify how these are used. Does it se= em > adequate to you? > > IEC 62351 Security Services describes a variety of policy choices for > protecting network traffic, including the option of specifying no > protection at all. This is enabled with the use of NONE as an > Authentication Algorithm and/or Confidentiality Algorithm. The > following guidance is given regarding the use of NONE. > > o Setting both Authentication Algorithm and Confidentiality > Algorithm to NONE is possible, but NOT RECOMMENDED. Setting such > a policy is sometimes necessary during a migration period, when > traffic is being protected incrementally and some traffic has not > yet been scheduled for protection. Alternatively, site security > policy for some packet flows requires inspection of packet data on > the private network followed by network-layer encryption before > delivery to a public network. > > o Setting the Confidentiality Algorithm to NONE, but setting the > Authentication Algorithm to a MAC can be an acceptable policy in > the following conditions: the disclosed information in the data > packets is comprised of raw data values, and the disclosure of the > data files is believed to be of no more value to an observer than > traffic analysis on the frequency and size of packets protected > for confidentiality. Alternatively, site security policy for some > packet flows requires inspection of packet data on the private > network followed by network-layer encryption before delivery to a > public network. > > o Setting the Authentication Algorithm to NONE, but setting the > Confidentiality Algorithm to an algorithm that does not includes > authentication is not safe, and MUST NOT be specified. > > > > The last sentence says that 128-bit AES-CBC is good enough for the > foreseeable future, "but some security policies may require the use of > AES-CBC-256.=E2=80=9D There is no mention of why such policies may requir= e this. > The usual reason is to protect against future attacks by quantum computer= s, > but I think it=E2=80=99s fine to leave that out. > > > > My question is about the IEC-61850 SA TEK Payload described in Figure 4 > in section 2.2. It has separate fields for Auth Alg and Enc Alg. The Enc > Alg field has 4 possible values described in section 2.2.3, including > AES-GCM-128 and AES-GCM-256. AES-GCM is an AEAD algorithm. As such it > should not be used in conjunction with a MAC algorithm. Other protocols > either omit the MAC algorithm when an AEAD is used, or create a special > =E2=80=98none=E2=80=99 value for such cases. Here there are no None value= (though there are > two Reserved values in the IANA considerations section). This makes it > possible to have SA TEK payloads with AES-GCM-128 and HMAC-SHA256-128. H= ow > do you even do that? And why? > > The removal of the NONE value from the Authentication Algorithm list > (present in -07) caused this problem, just as you imply. It will be > reinstated, accompanied by some precise text describing with which > Confidentially Algorithms MUST and MUST not be accompanied by the NONE > Authentication Algorithm value. I.e., the defined AES-CBC algorithms MUST > NOT be used with a NONE Authentication Algorithm, and AES-GCM algorithms > MUST be used with an Authentication Algorithm. The example payloads in > Appendix A will also be corrected. > > Thanks, > Brian > > > > > Yoav > > > > [1] https://mailarchive.ietf.org/arch/msg/secdir/-C5_ > XjfTk42DO013DkbA6q0tQmA > > _______________________________________________ > > secdir mailing list > > secdir@ietf.org > > https://www.ietf.org/mailman/listinfo/secdir > > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > -- > Brian Weis > Security, CSG, Cisco Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com > > --=20 Best regards, Kathleen --001a1148d00a73b5b6053ed7ee5e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Brian & Yoav,

Thank you for your re= view, Yoav and for catching a problem caused by my review and a question I = asked to see if the none was needed or not.=C2=A0 This is an important chan= ge and as such, I'd like to see the updated text published now rather t= han after last call ends so any other reviews are able to see this change.= =C2=A0 The shepherd, Brian and I all reviewed the text. =C2=A0
If Yoav is able to respond quickly, then I'd include any o= ther changes if they are needed, otherwise, it owuld be good to publish thi= s updated version and hold any other changes until after the last call peri= od ends.

Thank you,
Kathleen
=

On Fri, Oct 14, 2= 016 at 2:08 PM, Brian Weis (bew) <bew@cisco.com> wrote:
Hi Yoav,

Thanks for your careful review. A last minute change before publishing -08 = caused some inconsistencies that you have noted below, and I=E2=80=99ve add= ed some comments inline addressing those inconsistencies.

> On Oct 4, 2016, at 9:38 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:
>
> Hi.
>
> I have reviewed this document as part of the security directorate'= s ongoing effort to review all IETF documents being processed by the IESG.<= br> > These comments were written primarily for the benefit of the security = area directors.
> Document editors and WG chairs should treat these comments just like a= ny other last call comments.
>
> Summary: Ready with a question
>
> The draft describes using GDOI with some extensions to transport keyin= g material for the IEC 61850 power utility automation family of standards.<= br> >
> I have previously reviewed version -02 of the draft three years ago ([= 1]). Later versions addressed my issues about the document being too opaque= for people not versed in IEC protocols and terminology. It is still rather= hard to read without the relevant background, but that is to be expected i= n a document targeted at a very specific audience (which I am not part of).=
>
> The Security Considerations section points to the section in RFC 6407 = (GDOI). Additional paragraphs point out that message authentication is mand= atory, while confidentiality is optional.=C2=A0 And yet the same paragraph = makes confidentiality a SHOULD if the packets are expected to traverse the = public Internet.

This text was not precisely matching the operational realities of ne= tworks where this standard will be used. This became even more apparent whe= n addressing the last issue that you noted below.=C2=A0 In reality, there a= re a number of operational environments where these devices will be deploye= d: in some cases they are in a private network where traffic does not need = to protected on a private network, and a site security policy will protect = the traffic with network-level encryption (such as an IPsec tunnel) when it= leaves the private network. In other cases, the application traffic needs = to be protected at the end host.

While authentication is a firm requirement when a cipher is used, there are= cases where neither authentication nor confidentiality is absolutely requi= red. In a simple world this would result in a distributed policy where a gr= oup member were configured with exactly which flows did not requiring prote= ction and does not need to ask a central Group Controller/Key Server (GCKS)= how to protect the flow. But a system using a centralized key management s= ystem generally is one where configuring such granulated distributed policy= is not operationally feasible. Therefore, it can make sense for the group = member to ask the GCKS on a flow by flow basis how to protect it, and somet= imes get a response that it is not to be protected. This is especially true= during a migration period, where the policy for each flow is individually = converted from unprotected to protected by the GCKS administrator.

Addressing this need requires re-instating the NONE value in both Authentic= ation Algorithm and Confidentiality Algorithm lists. (These values had been= present in -07).=C2=A0 We also propose the following additions to the Secu= rity Considerations section to clarify how these are used. Does it seem ade= quate to you?

=C2=A0 =C2=A0IEC 62351 Security Services describes a variety of policy choi= ces for
=C2=A0 =C2=A0protecting network traffic, including the option of specifying= no
=C2=A0 =C2=A0protection at all.=C2=A0 This is enabled with the use of NONE = as an
=C2=A0 =C2=A0Authentication Algorithm and/or Confidentiality Algorithm.=C2= =A0 The
=C2=A0 =C2=A0following guidance is given regarding the use of NONE.

=C2=A0 =C2=A0o=C2=A0 Setting both Authentication Algorithm and Confidential= ity
=C2=A0 =C2=A0 =C2=A0 Algorithm to NONE is possible, but NOT RECOMMENDED.=C2= =A0 Setting such
=C2=A0 =C2=A0 =C2=A0 a policy is sometimes necessary during a migration per= iod, when
=C2=A0 =C2=A0 =C2=A0 traffic is being protected incrementally and some traf= fic has not
=C2=A0 =C2=A0 =C2=A0 yet been scheduled for protection.=C2=A0 Alternatively= , site security
=C2=A0 =C2=A0 =C2=A0 policy for some packet flows requires inspection of pa= cket data on
=C2=A0 =C2=A0 =C2=A0 the private network followed by network-layer encrypti= on before
=C2=A0 =C2=A0 =C2=A0 delivery to a public network.

=C2=A0 =C2=A0o=C2=A0 Setting the Confidentiality Algorithm to NONE, but set= ting the
=C2=A0 =C2=A0 =C2=A0 Authentication Algorithm to a MAC can be an acceptable= policy in
=C2=A0 =C2=A0 =C2=A0 the following conditions: the disclosed information in= the data
=C2=A0 =C2=A0 =C2=A0 packets is comprised of raw data values, and the discl= osure of the
=C2=A0 =C2=A0 =C2=A0 data files is believed to be of no more value to an ob= server than
=C2=A0 =C2=A0 =C2=A0 traffic analysis on the frequency and size of packets = protected
=C2=A0 =C2=A0 =C2=A0 for confidentiality.=C2=A0 Alternatively, site securit= y policy for some
=C2=A0 =C2=A0 =C2=A0 packet flows requires inspection of packet data on the= private
=C2=A0 =C2=A0 =C2=A0 network followed by network-layer encryption before de= livery to a
=C2=A0 =C2=A0 =C2=A0 public network.

=C2=A0 =C2=A0o=C2=A0 Setting the Authentication Algorithm to NONE, but sett= ing the
=C2=A0 =C2=A0 =C2=A0 Confidentiality Algorithm to an algorithm that does no= t includes
=C2=A0 =C2=A0 =C2=A0 authentication is not safe, and MUST NOT be specified.=


> The last sentence says that 128-bit AES-CBC is good enough for the for= eseeable future, "but some security policies may require the use of AE= S-CBC-256.=E2=80=9D There is no mention of why such policies may require th= is. The usual reason is to protect against future attacks by quantum comput= ers, but I think it=E2=80=99s fine to leave that out.
>
> My question is about the IEC-61850 SA TEK Payload described in Figure = 4 in section 2.2. It has separate fields for Auth Alg and Enc Alg. The Enc = Alg field has 4 possible values described in section 2.2.3, including AES-G= CM-128 and AES-GCM-256. AES-GCM is an AEAD algorithm. As such it should not= be used in conjunction with a MAC algorithm. Other protocols either omit t= he MAC algorithm when an AEAD is used, or create a special =E2=80=98none=E2= =80=99 value for such cases. Here there are no None value (though there are= two Reserved values in the IANA considerations section). This makes it pos= sible to have SA TEK payloads with AES-GCM-128 and HMAC-SHA256-128.=C2=A0 H= ow do you even do that? And why?

The removal of the NONE value from the Authentication Algorithm list= (present in -07) caused this problem, just as you imply. It will be reinst= ated, accompanied by some precise text describing with which Confidentially= Algorithms MUST and MUST not be accompanied by=C2=A0 the NONE Authenticati= on Algorithm value. I.e., the defined AES-CBC algorithms MUST NOT be used w= ith a NONE Authentication Algorithm, and AES-GCM algorithms MUST be used wi= th an Authentication Algorithm. The example payloads in Appendix A will als= o be corrected.

Thanks,
Brian

>
> Yoav
>
> [1] https://mailarchive= .ietf.org/arch/msg/secdir/-C5_XjfTk42DO013DkbA6q0tQmA
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/= trac/wiki/SecDirReview

--
Brian Weis
Security, CSG, Cisco Systems
Telephone: += 1 408 526 4796
Email: bew@cisco.com




--

Best regards,
Kathleen
--001a1148d00a73b5b6053ed7ee5e-- From nobody Sat Oct 15 03:14:35 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0B61296F9; Sat, 15 Oct 2016 03:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 sPmqAyZBXaXD; Sat, 15 Oct 2016 03:14:33 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D9DF1296F6; Sat, 15 Oct 2016 03:14:33 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id 83so112787807vkd.0; Sat, 15 Oct 2016 03:14:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=jFZsA7YAof+oWKCbYgnR9iBWZ/C0r/5HNcySQmI7OVw=; b=MiHqlgovQ9sFxKyLwS2hfDmnpjD86ZsP5YIBRNRalnT79UkNp/HOBpHmDeixdaJVaA uCBNr4bf23uivsURB1bpvJHewzLNhqE3IuXzAA8qSo0YMKuookrjINmo1fiUKPI0G2kH LpcIL8fzXcqI0Kx4O7DZAwoxHCBUFRm33mkIymyE/QaCqCjpfWClLtIfO3cr6AImGyQa UPoUQMIAMJOdaLGa9bmS5OpWmLiBU7XkO2Ld6Y/KudDoqF7FTRGGhmNuO3f66HrZJrNT wYLLwJqE7BPbdZwjXFqkLjU6bjUhzRdCSaqitqaWgC2K5y1vT42PSogbTXFKbFzsKL81 9w4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=jFZsA7YAof+oWKCbYgnR9iBWZ/C0r/5HNcySQmI7OVw=; b=OwjuGNYaJ1ABbZQF6mu85FcfA/VBuESUHWqBNUpBbqaO7nifa9x7mtJp5Z55yzljyd CAG/qoSHPKjbz7UzSPkKPI2M5BmsM+yW/vU8hKUnP2U+5k+8xUnbw2jPearGW0IYZjwr UD11I6z8ozMIIxXzkHvz/5o4ANSDy3Jg0kLcL76WIYvfmdh241/YqZyLbDQI+kN926Cm MuxkWsFhuLKOFTqvYZDSzeXOC4+c+lf0i2fY4Yk6eqKK0EfiFyKwO9AA+tu2pWFyvNWL 3JOu/0tvgek59Poj7N9WAXE3Fg0nm5HOLTvelfipdVBXX5EhqXFnznKBFnFMYsralJ9Y mwhQ== X-Gm-Message-State: AA6/9RnOsq1dLa/GH05kitNyn2dRZkRTG5ksmmR4Wi5h33Sl8WzizDvn2MOZZNnMEDFQ1UGya3OYLYUWjNoJig== X-Received: by 10.31.92.22 with SMTP id q22mr12317658vkb.88.1476526472677; Sat, 15 Oct 2016 03:14:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.3.116 with HTTP; Sat, 15 Oct 2016 03:14:32 -0700 (PDT) From: Rifaat Shekh-Yusef Date: Sat, 15 Oct 2016 06:14:32 -0400 Message-ID: To: The IESG , secdir@ietf.org, draft-ietf-ccamp-ospf-availability-extension.all@tools.ietf.org Content-Type: multipart/alternative; boundary=001a114e61a2e7cead053ee49b2b Archived-At: Subject: [secdir] SecDir review of draft-ietf-ccamp-ospf-availability-extension-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2016 10:14:35 -0000 --001a114e61a2e7cead053ee49b2b Content-Type: text/plain; charset=UTF-8 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: *Ready* This is a Standard Track document that extend the GMPLS OSPF routing protocol by introducing an optional ISCD Availability sub-TLV, which could be used for route computation in a network that contains links with variable discrete bandwidth. This document defines the distribution mechanism for this new extension. The Security Consideration section clearly describes the security and privacy issues with this new extension, and since this is only an extension to an existing mechanism, it points to other documents that cover the mechanism and the security implications and potential solutions. Regards, Rifaat --001a114e61a2e7cead053ee49b2b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have reviewed this docum= ent as part of the security directorate's=C2=A0ongoing effort to review all IETF documents being processed by the= =C2=A0IESG.=C2=A0 These comments we= re written primarily for the benefit of the=C2=A0security area directors.=C2=A0 Document editors and WG chairs= should treat=C2=A0these comments j= ust like any other last call comments.

Summary:=C2=A0Ready

This is a Standard Track document that extend the GMPLS OSPF routing = protocol by introducing an optional ISCD A= vailability sub-TLV, which could be used for route computation in a network= that contains links with variable discrete bandwidth. This document define= s the distribution mechanism for this new extension.

The Security = Consideration section clearly describes the security and privacy issues wit= h this new extension, and since this is only an extension to an existing me= chanism, it points to other documents that cover the mechanism and the secu= rity implications and potential solutions.

Regards,
=C2=A0Rifaat
--001a114e61a2e7cead053ee49b2b-- From nobody Sat Oct 15 12:14:53 2016 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D38C312988B; Fri, 14 Oct 2016 10:36:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1476466594; bh=To5SSvEXm48/ZAsotRlFhRISgGq2kU1eymVFKAk8Gv4=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=Am4b1L2vBElW4ZTsRKV1d1wyXApxMDo5nzoOsA7qjp1XanlblGArLFb6rV+GXnlvk X5s4ufLKTPYEQLyooLUSxfwRVXFilcpjGVfIJcoz1UAxmh0d0ka5j4n4ckmBfAVIZi HKHGFZBs/OPOcqgvMZL9ceR4fke1UZaAn5b+gIRQ= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A78C12987F for ; Fri, 14 Oct 2016 10:36:24 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Reply_to: Message-ID: <147646658429.18536.17903723882149582136.idtracker@ietfa.amsl.com> Date: Fri, 14 Oct 2016 10:36:24 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.17 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Sat, 15 Oct 2016 12:14:53 -0700 Subject: [secdir] [new-work] WG Review: L2VPN Service Model (l2sm) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 17:36:35 -0000 A new IETF WG has been proposed in the Operations and Management Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2016-10-24. L2VPN Service Model (l2sm) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: TBD Assigned Area Director: Benoit Claise Operations and Management Area Directors: Benoit Claise Joel Jaeggli Mailing list: Address: l2sm@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/l2sm Archive: https://mailarchive.ietf.org/arch/browse/l2sm/ Charter: https://datatracker.ietf.org/doc/charter-ietf-l2sm/ The IETF and the industry in general is currently specifying a set of YANG models for network element and protocol configuration. This is an essential first step, but the end goal is full system configuration that enable service agility to speed service creation and delivery and allows the deployment of innovative new services across networks. Services are built from a combination of network element and protocol configuration, but are specified to service users in more abstract terms. The Layer Two Virtual Private Network Service Model (L2SM) working group is a short-lived WG tasked to create a YANG data model that describes a L2VPN service (a L2VPN service model) that can be used for communication between customers and network operators, and to provide input to automated control and configuration applications. The working group will attempt to derive a single data model that includes support for point-to-point Virtual Private Wire Services (VPWS), multipoint Virtual Private LAN services (VPLS) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFC4761 and RFC6624, and Ethernet VPNs in RFC 7432. It needs to be clearly understood that this L2VPN service model is not an L2VPN configuration model. That is, it does not provide details for configuring network elements or protocols (that work is expected to be carried out in other protocol-specific working groups). Instead, the L2VPN service model contains the characteristics of the service as discussed between the operators and their customers. A separate process is responsible for mapping this service model onto the protocols and network elements depending on how the network operator chooses to realise the service. The deliverable from this working group will provide information to evaluate the set of YANG models that have already been developed or are under development, and will help identify any missing models or details. The deliverable can be viewed as driving requirements for protocol configuration model so that the service parameters can be mapped into inputs used by the protocol models. The working group will learn from the experience of the L3SM working group and it is expected that the L2SM data model will have similar structure to the L3SM data model. The working group should consider draft-wen-l2sm-l2vpn-service-model as a starting point. The working group will coordinate with other working groups responsible for L2VPN protocol work (most notably with BESS and PALS) and with the MEF. Milestones: Dec 2016 - Adopt WG draft for data model Oct 2017 - Request publication of data model as Standards Track RFC Dec 2017 - Close working group _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Mon Oct 17 16:54:35 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3CC41299C1 for ; Mon, 17 Oct 2016 16:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 RGTdgteLFqCD for ; Mon, 17 Oct 2016 16:54:32 -0700 (PDT) Received: from nm10-vm5.bullet.mail.ne1.yahoo.com (nm10-vm5.bullet.mail.ne1.yahoo.com [98.138.91.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 370141299C0 for ; Mon, 17 Oct 2016 16:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1476748471; bh=FW3VcmsXEdA3+YEUDj5+kRbZ5P6t67aRw1w5ta6i+9g=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=g+SoJajXlCU0hvYajE+k+5gElqcIK2sT+1/tBTggbHqzWdWz01Nc66/QpsF8AUwbmbvYFFmD2E4i4RrUYbdZ6pAccFD2O035qPJ6+aqOzwrcWQaYSHh60NUo+2fAgsfbHveqi/OngkfQhOyuItfeT+J3k5OvuZ6yNbvb610ZnVNbbxVNrZAfFgkmmHxI+jd1NFUg15hd/Ul2t4o3kaWMmy+yUzHaHIAKz5YmPOO96chc6DQ9YcRJ13n0ieCxsHEba/dOFUY/SjWFmtnKj5CUubmpfp9NrOUDy1P4JP9mYW2fOzG47PU09KHBPzolbm8otNO6CZTDQg2/jjrhi5WyhQ== Received: from [98.138.226.177] by nm10.bullet.mail.ne1.yahoo.com with NNFMP; 17 Oct 2016 23:54:31 -0000 Received: from [98.138.89.160] by tm12.bullet.mail.ne1.yahoo.com with NNFMP; 17 Oct 2016 23:54:31 -0000 Received: from [127.0.0.1] by omp1016.mail.ne1.yahoo.com with NNFMP; 17 Oct 2016 23:54:31 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 234225.2451.bm@omp1016.mail.ne1.yahoo.com X-YMail-OSG: _vZ_uYYVM1ks_XnI2JVulVBl3RTal3jwcLUlP4U3W1ee_e7PvbfSAla3rP14E7f yFZ5cmYey1hGsQSGhQNyZA7pJh5b1pGl7_nvO47wsKuo4ARdmqXoqKsvPmHHc5wsu82WvMIE98mD MuJiJYwH9hOIkQ7_FEqroTlor.4jhLpOWG_aNufWiaR4kIzkLpvgHHVIkX87gVDk7G3Et4El77L3 tr60V2N5MHnECBsP0XwOZNkpom_vJoR83aCbXYtTa3nAWXl0vnqy2m82VsGYz18p8etHEyl7tqtT EIRB9xav79_z6zt0JY2Ay3.S_e5Zd6Nignttj02wls29ZiwHOfN5F4oQaMbIS9gU2IVK._sv699B pOKhcSGan62KYVsAwXsGEgVR5E9tkKXdbVczGCpto9Sfzmf8QNN0XqQtVA...NRTRr9Hc4ke8zY. yCTfSvCbv8leHf1WTokyguhUUs1AKayFC1RicEnrdY6YlNmThChtpmuYPoh53jeZttrY9StG30iY 9qP2dBfyuG7ypspugZb4u0xemrIW_Rw4bCbhMQjWz5reXzB7wLck- Received: from jws200071.mail.ne1.yahoo.com by sendmailws115.mail.ne1.yahoo.com; Mon, 17 Oct 2016 23:54:30 +0000; 1476748470.857 Date: Mon, 17 Oct 2016 23:54:30 +0000 (UTC) From: To: Tero Kivinen Message-ID: <1599707928.1673367.1476748470485@mail.yahoo.com> In-Reply-To: <22523.36827.869306.70163@fireball.acr.fi> References: <22495.62038.771947.984586@fireball.acr.fi> <1264225155.363685.1474644268281@mail.yahoo.com> <22507.60901.665544.878052@fireball.acr.fi> <1130739157.4563724.1475509147203@mail.yahoo.com> <22523.36827.869306.70163@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "iesg@ietf.org" , "draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 23:54:34 -0000 Tero, Thanks again so much for your comments. I think they will really help to make the document better. I am going to do some procedural things now so that we can move towards wrapping this up. 1. I will make separate threads for each outstanding issue. That way, we clean that up & then drop it. 2. The outstanding issues that I see are: --a. Timebase issues --b. Location of PDM in ESP mode --c. Default configuration --d. Warnings about timing attacks 3. Then, we need to respond to the gen-art comments. (Quite a few! But that is another story. And, not your problem but ours!) Thanks, Nalini Elkins (for the co-authors) Inside Products, Inc. www.insidethestack.com (831) 659-8360 ----- Original Message ----- From: Tero Kivinen To: nalini.elkins@insidethestack.com Cc: "iesg@ietf.org" ; "secdir@ietf.org" ; "draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" Sent: Monday, October 10, 2016 5:55 AM Subject: Re: Secdir review of draft-ietf-ippm-6man-pdm-option-05 nalini.elkins@insidethestack.com writes: > >There are most likely also other kind of attacks, and as this is > >service as ESP provides, it is not for PDM to break it unless you > >explictly spell it out that this is meant to break property of the > >ESP. > > OK. I am convinced. I will tell you though that some of us in IPPM, > we were quite excited (possibly naively) about being able to get > some performance metrics for ESP. Why do you think you can performance metrics for ESP in that case? > I wonder if it would be acceptable to say that PDM could be put into > the Destination Option which precedes ESP if it is for an enterprise > customer who owns the infrastructure and wishes to manage the > network that way. Otherwise, I can change to say that only the Dest > Opt following ESP can be used. I would recommend that if you use transport mode ESP (i.e., where the flow information would be leaked out from the ESP if PDM is used) then it must be put inside the ESP. If you use tunnel mode ESP, then there migth be two PDM headers in the packet, one in the inner packet inside the ESP header (which has full IP header + destination options including PDM option), and another one in the outer header, in which case it would only cover the ESP as one flow (i.e., each ESP SA identified by the SPIs would get separate PDM option). I.e. in the Tunnel mode ESP you want to defined the "5-tuple" as: SADDR, DADDR, PROTC (=ESP), SPI-IN, SPI-OUT Btw, in the ICMP etc you do not have port numbers. Are ICMP frames related to the TCP flows matching the "5-tuple" of the TCP flow or are they counted as separate? Anyways so if you define Tunnel mode ESP that way, then you can get some performance metrics from the ESP processing also. Then if the enterprice is willing to sacrifice the traffic flow confidentiality, they can turn on the sa-per-flow option of the IPsec implementation, which will create separate SA pair for each TCP/UDP etc flow, so then they will get exact measurements. In normal case the Tunnel mode ESP will just provide performance metrics for combination of all traffic inside the tunnel, not per flow. When using the Transport Mode ESP, then putting the PDM option inside still provides performance metrics for the host. > >so the range is definately enough. The question is that if the scale > >is from -127 to 128, why do we even need the Time Base? > > The time base is so that one does not have to be committed to > picoseconds / milliseconds, etc. Even in your example, I believe > you used "unit" or time base. Our thinking was that we wanted > future proof so as to be able to handle very small values and very > large (as may be needed for DTN, for example). We can see if we can > express years in picoseconds and see what happens. Then, the unit > would always be picoseconds. Having scale from -127 to 128 will provide quite good future proof, for at least for this universum. Even if you used attoseconds as base, you could express 10^13 years which is still more than 1000 times longer than the current age of the universe... > >3.5 Implementation Considerations > > > The PDM destination options extension header SHOULD be turned on by > > each stack on a host node. It MAY also be turned on only in case of > > diagnostics needed for problem resolution. > > > so it seems it is on by default. > > Will change to say that it MUST be turned on only by the stack and > default value should be OFF. > > "The PDM destination options extension header MUST be turned on only > by administrative action at each stack on a host node. The default > mode for PDM is OFF." Good. > >Key management packets are usually in clear, as they are there before > >we have the actual keys we can use to protect the messages. Also it is > >not very difficult to guess that 3rd and 4th message in port 500, are > >the IKE AUTH packets, which will contain signatures. > > >Same thing with TLS. > > >Attackers will knows which packets contain signatures. Currently > >attackers usually send those signature packets themselves, and measure > >the time it takes for the device to calculate response. They can also > >send garbage packets, and detect how far in checking the packets got > >by checking how long it took for the other end to send error message > >back. > > >All this kind of timing attacks are usually considered hard, as the > >network delays cause big jitter on the timings, and they need to try > >multiple times, and average the response times to get the information > >they need. > > >This method will provide them easy way to bypass that issue. > > OK. So, are you saying that PDM is attack vector for TLS and not > just for ESP? Yes, timing attacks are possible against any crypto protocol. If the protocol and algorithms used in the protocol are specifically written so that they are protected against timing attacks, they will not work, but lots of the implementations and protocols care more about the speed, than for the timing attacks, especially as launching them over longer distance gets harder and harder as other things add random times to measurements. If this allows easy way to get exact timing information from the node without any issues from the network latencies and so on, this might open completely new ways to attack implementations and protocols. Those attacks were not feasible before, but now they might be. > No, obviously not. So, now I am not sure where we are. Is there a > complete objection to this draft or are there changes which can be > made which would make this acceptable? Yes, I do not think there is anything that cannot be fixed, but there are things that needs fixing (from the security point of view): 1) Location of the PDM in ESP transport mode traffic. 2) Make sure this is turned off by default, and you do not want node to respond incoming PDM options unless turned on by adminstrator. 3) Add to security considerations section aclear warnings about the new possibilities for timing attacks if PDM is turned on. (not sure if I forgot something). -- kivinen@iki.fi From nobody Mon Oct 17 16:58:36 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C847129495 for ; Mon, 17 Oct 2016 16:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.42 X-Spam-Level: X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 Xzqf8FN3DhVb for ; Mon, 17 Oct 2016 16:58:28 -0700 (PDT) Received: from nm22-vm0.bullet.mail.ne1.yahoo.com (nm22-vm0.bullet.mail.ne1.yahoo.com [98.138.91.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 088B21299AF for ; Mon, 17 Oct 2016 16:58:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1476748707; bh=sn1glpLY3LxY0P/rBtgF24cULdNjeRDQQcmjBz2lQ0w=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=UAKdg2nf7rx9G/ESR7wpNhTMZFl3oegdgiXkpII/OzHJRsBqlzOIuVKd20MDthsOezkcBZGCdZ9ljDF9lO15rPRY4NYnzBfvjh+dxQhdyM/5aP4mQJCOJhFFf1T7G5fovb/H47TQBCAeOcCAHQ66ZmVgIg0lQRjND3MIygieSXJ948XDtR0ell8vBsCMrtzWpylJpRCqWvlJbYZYte+/T8224uNdJ/KV6YIKb6SYBVTPgo04IGo1w7AxkIGSZXYX8cbQBqWIxZVFezv2/tCQGVojvRsyYUfvWAXWhVHXPcYdg651uucCvbrNv05etI32uUazNwUy7Vz9KBp9FWsj0w== Received: from [98.138.226.178] by nm22.bullet.mail.ne1.yahoo.com with NNFMP; 17 Oct 2016 23:58:27 -0000 Received: from [98.138.89.174] by tm13.bullet.mail.ne1.yahoo.com with NNFMP; 17 Oct 2016 23:58:27 -0000 Received: from [127.0.0.1] by omp1030.mail.ne1.yahoo.com with NNFMP; 17 Oct 2016 23:58:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 140396.17650.bm@omp1030.mail.ne1.yahoo.com X-YMail-OSG: wKj6ZCgVM1n4480jkQ87hu8xYHZwlUuB52WVKJ6Hs8y1N10OG.pLvjYuiGqNJQN n20_HZQDh7NiQpW_EMLmlFoQAzt5cza29zKITqxpH0Mo..0efqahY_ipn7Va4FNDh0izhMbE3b9Q HrkFtvAzfdSbFELnkx08Aec2RsOL5DguOvvw1Zghj3axMHxhx6H0tkr1yj5trBJ4l8QbPtlHD6.s k54FSPNnACbzQZcBS3D0ugagVyQArXKo2VUia15SCQx0F_742Q_qrlh4qIUJN1cqSfPEHz4JXOoU ndOjjy4v8TbvkxUSOs6gWvs3ySql9ACTL6nsOLNPRdT2ua0DWZyP0ivUah81n97lmfp05I18PND1 qo5r4.AYGyEsGHkzuZAgAKcL59VbW28EHkBitMcbY6pVQESCtDk.uA3QOXIskkWd65D3wHiiLS7r S_eFg0cYHWwFf49w2xdF3YJh9FrUmu.Cfyjj7G9914.nufM8r3LpJt3jv3pgNUaB3bph6cnKk3jT UjO1XSe3WN7yCGSdYQIQTMFTdkwMc.zXRFsJkK2DoNmcJgF4vufo- Received: from jws200163.mail.ne1.yahoo.com by sendmailws136.mail.ne1.yahoo.com; Mon, 17 Oct 2016 23:58:26 +0000; 1476748706.672 Date: Mon, 17 Oct 2016 23:58:26 +0000 (UTC) From: To: Tero Kivinen Message-ID: <1393336949.1646912.1476748706209@mail.yahoo.com> In-Reply-To: <22523.36827.869306.70163@fireball.acr.fi> References: <22495.62038.771947.984586@fireball.acr.fi> <1264225155.363685.1474644268281@mail.yahoo.com> <22507.60901.665544.878052@fireball.acr.fi> <1130739157.4563724.1475509147203@mail.yahoo.com> <22523.36827.869306.70163@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "iesg@ietf.org" , "draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-05 : TimeBase X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 23:58:29 -0000 Tero, This note will summarize and answer the comments on timebase. >> >The whole section 4 seems to be wierd. It is talking about different >> >encodings, and time units on different systems, and it also talks >> >about the limitations on TCP Timestamp Option, but this option uses >> >different encoding so I have no idea why this text is here. It would >> >be more useful to count what are the limits on the encoding method >> >used here (16 bit value, 7 bit signed scaling value), instead of what >> >some other option use. >> >>What is the meaning of the section 4? > >>It is good background information, and might be moved to the appendix, >>but I do not think it belongs here. It has text that mostly covers >>other formats, not the format used here. Also it does not really >>specify what does negative scaling values mean, and when are they used. >Let me review this again with one of my co-authors. > .... > >>so the range is definitely enough. The question is that if the scale is >>from -127 to 128, why do we even need the Time Base? > >The time base is so that one does not have to be committed to picoseconds / >milliseconds, etc. Even in your example, I believe you used "unit" or time >base. Our thinking was that we wanted future proof so as to be able to >handle very small values and very large (as may be needed for DTN, for >example). We can see if we can express years in picoseconds and see >what happens. Then, the unit would always be picoseconds The issue is with the hardware. When we were first researching the "proper" or "best" time unit in which the PDM time differentials should be measured, we found that different CPU hardware measure time very differently. Some CPUs are still measuring time in milliseconds and using multiple clocks to do it. Our plan was to have a CPU specify the time differential in its native time units, to reduce its processing time when communicating with another device that is at the same level. One could say that the most logical solution is to use the time signature of the slowest device, so that all the time-adjustment calculations are performed on the device most capable of handling them quickly, and similarly, requiring the slowest device to adjust to the timing used by the fastest device would be forcing those calculations onto the device least capable of handling them quickly. Further, why make two devices that use the same clock unit to change to a different time scale on both ends of the conversation? If both use microseconds, why not let them specify their time differential in microseconds? That's the reasoning that we had about the timebase. Of course, we are open to discussion. Thanks, Nalini Elkins Inside Products, Inc. www.insidethestack.com (831) 659-8360 ----- Original Message ----- From: Tero Kivinen To: nalini.elkins@insidethestack.com Cc: "iesg@ietf.org" ; "secdir@ietf.org" ; "draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" Sent: Monday, October 10, 2016 5:55 AM Subject: Re: Secdir review of draft-ietf-ippm-6man-pdm-option-05 nalini.elkins@insidethestack.com writes: > >There are most likely also other kind of attacks, and as this is > >service as ESP provides, it is not for PDM to break it unless you > >explictly spell it out that this is meant to break property of the > >ESP. > > OK. I am convinced. I will tell you though that some of us in IPPM, > we were quite excited (possibly naively) about being able to get > some performance metrics for ESP. Why do you think you can performance metrics for ESP in that case? > I wonder if it would be acceptable to say that PDM could be put into > the Destination Option which precedes ESP if it is for an enterprise > customer who owns the infrastructure and wishes to manage the > network that way. Otherwise, I can change to say that only the Dest > Opt following ESP can be used. I would recommend that if you use transport mode ESP (i.e., where the flow information would be leaked out from the ESP if PDM is used) then it must be put inside the ESP. If you use tunnel mode ESP, then there migth be two PDM headers in the packet, one in the inner packet inside the ESP header (which has full IP header + destination options including PDM option), and another one in the outer header, in which case it would only cover the ESP as one flow (i.e., each ESP SA identified by the SPIs would get separate PDM option). I.e. in the Tunnel mode ESP you want to defined the "5-tuple" as: SADDR, DADDR, PROTC (=ESP), SPI-IN, SPI-OUT Btw, in the ICMP etc you do not have port numbers. Are ICMP frames related to the TCP flows matching the "5-tuple" of the TCP flow or are they counted as separate? Anyways so if you define Tunnel mode ESP that way, then you can get some performance metrics from the ESP processing also. Then if the enterprice is willing to sacrifice the traffic flow confidentiality, they can turn on the sa-per-flow option of the IPsec implementation, which will create separate SA pair for each TCP/UDP etc flow, so then they will get exact measurements. In normal case the Tunnel mode ESP will just provide performance metrics for combination of all traffic inside the tunnel, not per flow. When using the Transport Mode ESP, then putting the PDM option inside still provides performance metrics for the host. > >so the range is definately enough. The question is that if the scale > >is from -127 to 128, why do we even need the Time Base? > > The time base is so that one does not have to be committed to > picoseconds / milliseconds, etc. Even in your example, I believe > you used "unit" or time base. Our thinking was that we wanted > future proof so as to be able to handle very small values and very > large (as may be needed for DTN, for example). We can see if we can > express years in picoseconds and see what happens. Then, the unit > would always be picoseconds. Having scale from -127 to 128 will provide quite good future proof, for at least for this universum. Even if you used attoseconds as base, you could express 10^13 years which is still more than 1000 times longer than the current age of the universe... > >3.5 Implementation Considerations > > > The PDM destination options extension header SHOULD be turned on by > > each stack on a host node. It MAY also be turned on only in case of > > diagnostics needed for problem resolution. > > > so it seems it is on by default. > > Will change to say that it MUST be turned on only by the stack and > default value should be OFF. > > "The PDM destination options extension header MUST be turned on only > by administrative action at each stack on a host node. The default > mode for PDM is OFF." Good. > >Key management packets are usually in clear, as they are there before > >we have the actual keys we can use to protect the messages. Also it is > >not very difficult to guess that 3rd and 4th message in port 500, are > >the IKE AUTH packets, which will contain signatures. > > >Same thing with TLS. > > >Attackers will knows which packets contain signatures. Currently > >attackers usually send those signature packets themselves, and measure > >the time it takes for the device to calculate response. They can also > >send garbage packets, and detect how far in checking the packets got > >by checking how long it took for the other end to send error message > >back. > > >All this kind of timing attacks are usually considered hard, as the > >network delays cause big jitter on the timings, and they need to try > >multiple times, and average the response times to get the information > >they need. > > >This method will provide them easy way to bypass that issue. > > OK. So, are you saying that PDM is attack vector for TLS and not > just for ESP? Yes, timing attacks are possible against any crypto protocol. If the protocol and algorithms used in the protocol are specifically written so that they are protected against timing attacks, they will not work, but lots of the implementations and protocols care more about the speed, than for the timing attacks, especially as launching them over longer distance gets harder and harder as other things add random times to measurements. If this allows easy way to get exact timing information from the node without any issues from the network latencies and so on, this might open completely new ways to attack implementations and protocols. Those attacks were not feasible before, but now they might be. > No, obviously not. So, now I am not sure where we are. Is there a > complete objection to this draft or are there changes which can be > made which would make this acceptable? Yes, I do not think there is anything that cannot be fixed, but there are things that needs fixing (from the security point of view): 1) Location of the PDM in ESP transport mode traffic. 2) Make sure this is turned off by default, and you do not want node to respond incoming PDM options unless turned on by adminstrator. 3) Add to security considerations section aclear warnings about the new possibilities for timing attacks if PDM is turned on. (not sure if I forgot something). -- kivinen@iki.fi From nobody Tue Oct 18 06:07:33 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA5612963A; Tue, 18 Oct 2016 06:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=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 UmE_9oL-oo7O; Tue, 18 Oct 2016 06:07:20 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CE54127076; Tue, 18 Oct 2016 06:07:20 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u9ID7HlB019333 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 18 Oct 2016 16:07:17 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u9ID7GvM020990; Tue, 18 Oct 2016 16:07:16 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <22534.7812.168714.893576@fireball.acr.fi> Date: Tue, 18 Oct 2016 16:07:16 +0300 From: Tero Kivinen To: In-Reply-To: <1393336949.1646912.1476748706209@mail.yahoo.com> References: <22495.62038.771947.984586@fireball.acr.fi> <1264225155.363685.1474644268281@mail.yahoo.com> <22507.60901.665544.878052@fireball.acr.fi> <1130739157.4563724.1475509147203@mail.yahoo.com> <22523.36827.869306.70163@fireball.acr.fi> <1393336949.1646912.1476748706209@mail.yahoo.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 27 min X-Total-Time: 108 min Archived-At: Cc: "iesg@ietf.org" , "draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-05 : TimeBase X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 13:07:26 -0000 nalini.elkins@insidethestack.com writes: > >The time base is so that one does not have to be committed to picose= conds /=20 > >milliseconds, etc. Even in your example, I believe you used "unit= " or time=20 > >base. Our thinking was that we wanted future proof so as to be able= to=20 > >handle very small values and very large (as may be needed for DTN, f= or=20 > >example). We can see if we can express years in picoseconds and se= e=20 > >what happens. Then, the unit would always be picoseconds=20 >=20 > The issue is with the hardware. When we were first researching the > "proper" or "best" time unit in which the PDM time differentials > should be measured, we found that different CPU hardware measure > time very differently. Some CPUs are still measuring time in > milliseconds and using multiple clocks to do it. Yep, but the problem is that if the implementation still need to be able to cope with other devices using different time bases, this does not help.=20 > Our plan was to have a CPU specify the time differential in its > native time units, to reduce its processing time when communicating > with another device that is at the same level. One could say that > the most logical solution is to use the time signature of the > slowest device, so that all the time-adjustment calculations are > performed on the device most capable of handling them quickly, and > similarly, requiring the slowest device to adjust to the timing used > by the fastest device would be forcing those calculations onto the > device least capable of handling them quickly. Further, why make two > devices that use the same clock unit to change to a different time > scale on both ends of the conversation=3F If both use microseconds, > why not let them specify their time differential in microseconds=3F The problem is that some implementations measure time in 0.01 seconds (10 ms), some implementations have timers which go up 60 times per second, then there are implementations which have free running counter running that full clock speed (or some fraction of clock speed or some other very fast value, but not necessarely ms, =B5s, ns or ps). So even if you have 4 time bases, there are lots of implementations which need to convert their clock to something that is suitable for the wireformat. If we do not have time base, i.e. everything uses some common timebase then you always need to do it, but on the other hand it is simple, as there is no selection whether you should be using ms, =B5s, ns or ps ar= e your time base. Having the 2^scale factor to the numbers will take care of being able to represent any time value there, having two different ways of doing scaling (both 2^scale factor and the time base) will just complicate things.=20 > That's the reasoning that we had about the timebase. >=20 > Of course, we are open to discussion.=20 I think it would be simplier to just have one fixed timebase, and it might even be better to take the timebase so it is so small, that we do not need negative exponents for scale, like attoseconds. Attoseconds (10^-18) is so short that light can travel only 0.3 nm in one attosecond, so that should be enough for PDM (until we get new way of making transistors, and start measure latencies between transistors). If your clock is running milliseconds, you need to multiply the time in ms with 0.88818 ((1000/1024)^5) to get time in attoseconds with scale of 50. For microseconds the multiplier is 0.90949 with scale of 40, nanoseconds 0.93132 with scale of 30, picoseconds 0.95367 with scale of 20, and femtoseconds 0.97656 with scale of 10. --=20 kivinen@iki.fi From nobody Tue Oct 18 10:06:38 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F98126D73 for ; Tue, 18 Oct 2016 10:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 LIo_RDnay5cx for ; Tue, 18 Oct 2016 10:06:30 -0700 (PDT) Received: from nm34-vm2.bullet.mail.ne1.yahoo.com (nm34-vm2.bullet.mail.ne1.yahoo.com [98.138.229.82]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60B751293F3 for ; Tue, 18 Oct 2016 10:06:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1476810389; bh=KWCTfElXE2rjaWy2FiK38NCT7rQyMOgbX02IklMFalU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=kpIVGqFR+bbL8QKlSPpKBvT2aBFn9/Uc3ccr8r19KjS408SyZkHQbycG/6vXhCg9SeqNh8/FdolaDXNJgBdmZ7ce4a5x1sIISBoMIi+YNXGVCWDVX13qySu8boM6fTk54DeWentk/OQfMr2GtW80bYx6RWUxQdqf0vZS9vrPhK9Qn6rUFsORgkzF8o2T+eJ++C006+c5wTf+3F2qlw0B69fLR5h6GWqxKTg67qP61jZ9ExNuYzi3/C0XOEJf+F+OOqvQfEVgBHurrHbVFVFe/MYXH6XC/wZ12V+sn9hWDLFRwRDW+s9a6wRLWQ1FkgAXWudqT/ZBZXnIV3Ra/AO8+g== Received: from [127.0.0.1] by nm34.bullet.mail.ne1.yahoo.com with NNFMP; 18 Oct 2016 17:06:29 -0000 Received: from [98.138.100.103] by nm34.bullet.mail.ne1.yahoo.com with NNFMP; 18 Oct 2016 17:03:22 -0000 Received: from [98.138.89.167] by tm102.bullet.mail.ne1.yahoo.com with NNFMP; 18 Oct 2016 17:03:18 -0000 Received: from [127.0.0.1] by omp1023.mail.ne1.yahoo.com with NNFMP; 18 Oct 2016 17:03:18 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 456836.82373.bm@omp1023.mail.ne1.yahoo.com X-YMail-OSG: eK82bHYVRDtgfAoCqOIpFuQf7CXNzbPmvwqKAF0E6WpCYH8GW8U- Received: from jws200067.mail.ne1.yahoo.com by sendmailws112.mail.ne1.yahoo.com; Tue, 18 Oct 2016 17:03:15 +0000; 1476810195.831 Date: Tue, 18 Oct 2016 17:03:13 +0000 (UTC) From: To: Tero Kivinen Message-ID: <919689005.2218143.1476810193309@mail.yahoo.com> In-Reply-To: <22523.36827.869306.70163@fireball.acr.fi> References: <22495.62038.771947.984586@fireball.acr.fi> <1264225155.363685.1474644268281@mail.yahoo.com> <22507.60901.665544.878052@fireball.acr.fi> <1130739157.4563724.1475509147203@mail.yahoo.com> <22523.36827.869306.70163@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "iesg@ietf.org" , "draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-05: Implementation Considerations X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 17:06:32 -0000 Tero, Continuing the taking of issues 1 by 1. The discussion around Implementation Considerations boils down to two issues: 1. Default value of PDM should be OFF 2. It should not be possible to turn on PDM merely by receiving a packet with PDM in it. Current words: "3.5 Implementation Considerations The PDM destination options extension header SHOULD be turned on by each stack on a host node. It MAY also be turned on only in case of diagnostics needed for problem resolution." Suggested changes: "3.5 Implementation Considerations The PDM destination options extension header MUST be explicitly turned on by each stack on a host node by administrative action. The default value of PDM is off. PDM MUST NOT be turned on merely if a packet is received with a PDM header. The received packet could be spoofed by another device." Thanks, Nalini Elkins (for the co-authors) Inside Products, Inc. www.insidethestack.com (831) 659-8360 ________________________________ From: Tero Kivinen To: nalini.elkins@insidethestack.com Cc: "iesg@ietf.org" ; "secdir@ietf.org" ; "draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" Sent: Monday, October 10, 2016 5:55 AM Subject: Re: Secdir review of draft-ietf-ippm-6man-pdm-option-05 nalini.elkins@insidethestack.com writes: > >There are most likely also other kind of attacks, and as this is > >service as ESP provides, it is not for PDM to break it unless you > >explictly spell it out that this is meant to break property of the > >ESP. > > OK. I am convinced. I will tell you though that some of us in IPPM, > we were quite excited (possibly naively) about being able to get > some performance metrics for ESP. Why do you think you can performance metrics for ESP in that case? > I wonder if it would be acceptable to say that PDM could be put into > the Destination Option which precedes ESP if it is for an enterprise > customer who owns the infrastructure and wishes to manage the > network that way. Otherwise, I can change to say that only the Dest > Opt following ESP can be used. I would recommend that if you use transport mode ESP (i.e., where the flow information would be leaked out from the ESP if PDM is used) then it must be put inside the ESP. If you use tunnel mode ESP, then there migth be two PDM headers in the packet, one in the inner packet inside the ESP header (which has full IP header + destination options including PDM option), and another one in the outer header, in which case it would only cover the ESP as one flow (i.e., each ESP SA identified by the SPIs would get separate PDM option). I.e. in the Tunnel mode ESP you want to defined the "5-tuple" as: SADDR, DADDR, PROTC (=ESP), SPI-IN, SPI-OUT Btw, in the ICMP etc you do not have port numbers. Are ICMP frames related to the TCP flows matching the "5-tuple" of the TCP flow or are they counted as separate? Anyways so if you define Tunnel mode ESP that way, then you can get some performance metrics from the ESP processing also. Then if the enterprice is willing to sacrifice the traffic flow confidentiality, they can turn on the sa-per-flow option of the IPsec implementation, which will create separate SA pair for each TCP/UDP etc flow, so then they will get exact measurements. In normal case the Tunnel mode ESP will just provide performance metrics for combination of all traffic inside the tunnel, not per flow. When using the Transport Mode ESP, then putting the PDM option inside still provides performance metrics for the host. > >so the range is definately enough. The question is that if the scale > >is from -127 to 128, why do we even need the Time Base? > > The time base is so that one does not have to be committed to > picoseconds / milliseconds, etc. Even in your example, I believe > you used "unit" or time base. Our thinking was that we wanted > future proof so as to be able to handle very small values and very > large (as may be needed for DTN, for example). We can see if we can > express years in picoseconds and see what happens. Then, the unit > would always be picoseconds. Having scale from -127 to 128 will provide quite good future proof, for at least for this universum. Even if you used attoseconds as base, you could express 10^13 years which is still more than 1000 times longer than the current age of the universe... > >3.5 Implementation Considerations > > > The PDM destination options extension header SHOULD be turned on by > > each stack on a host node. It MAY also be turned on only in case of > > diagnostics needed for problem resolution. > > > so it seems it is on by default. > > Will change to say that it MUST be turned on only by the stack and > default value should be OFF. > > "The PDM destination options extension header MUST be turned on only > by administrative action at each stack on a host node. The default > mode for PDM is OFF." Good. > >Key management packets are usually in clear, as they are there before > >we have the actual keys we can use to protect the messages. Also it is > >not very difficult to guess that 3rd and 4th message in port 500, are > >the IKE AUTH packets, which will contain signatures. > > >Same thing with TLS. > > >Attackers will knows which packets contain signatures. Currently > >attackers usually send those signature packets themselves, and measure > >the time it takes for the device to calculate response. They can also > >send garbage packets, and detect how far in checking the packets got > >by checking how long it took for the other end to send error message > >back. > > >All this kind of timing attacks are usually considered hard, as the > >network delays cause big jitter on the timings, and they need to try > >multiple times, and average the response times to get the information > >they need. > > >This method will provide them easy way to bypass that issue. > > OK. So, are you saying that PDM is attack vector for TLS and not > just for ESP? Yes, timing attacks are possible against any crypto protocol. If the protocol and algorithms used in the protocol are specifically written so that they are protected against timing attacks, they will not work, but lots of the implementations and protocols care more about the speed, than for the timing attacks, especially as launching them over longer distance gets harder and harder as other things add random times to measurements. If this allows easy way to get exact timing information from the node without any issues from the network latencies and so on, this might open completely new ways to attack implementations and protocols. Those attacks were not feasible before, but now they might be. > No, obviously not. So, now I am not sure where we are. Is there a > complete objection to this draft or are there changes which can be > made which would make this acceptable? Yes, I do not think there is anything that cannot be fixed, but there are things that needs fixing (from the security point of view): 1) Location of the PDM in ESP transport mode traffic. 2) Make sure this is turned off by default, and you do not want node to respond incoming PDM options unless turned on by adminstrator. 3) Add to security considerations section aclear warnings about the new possibilities for timing attacks if PDM is turned on. (not sure if I forgot something). -- kivinen@iki.fi From nobody Tue Oct 18 21:21:06 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C8D12946B; Tue, 18 Oct 2016 21:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 httJZR55bG4p; Tue, 18 Oct 2016 21:21:03 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52A0C129466; Tue, 18 Oct 2016 21:21:03 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id o68so17679796qkf.3; Tue, 18 Oct 2016 21:21:03 -0700 (PDT) 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-transfer-encoding; bh=gX06tHvC06M+L7wo876rLBdkQEnFUi3i7rCmjDw0/Yo=; b=F82APmze9qVQ3zFa/3vp7r2bn8YwwprUJPKKGm75T4vIAR7weowywPbhL+kW4XaT0j paqZSBg9cWFlCMBEkXvbG52UQ02UXojL8F4ifpT8MXXcXyUkE19s8afY0lBEqrPJmjGy DHHeqHiUMXcu5Q1oLeGkfsSdJ3bkQnOK+xcLVInQGX1Ny8+xmmiz/zb/7zpCz5C6uxTA mnra7IjCWJOJT8n0v9m7Rqi0GMpOZX+uAzF0+dt2kgCjtuotRbI8hGAj1seuwajDzXOp QgVuyfjWQYCBQ+Qh79uvVUWBiYMKDh0UrU4aEk47ZPE2eOh8aqxgaEhhNmFkCzqYutw3 sxUQ== 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-transfer-encoding; bh=gX06tHvC06M+L7wo876rLBdkQEnFUi3i7rCmjDw0/Yo=; b=kC+1P0inyANqSZ481aqHg+2Wi2+YqDLa7bZF7JoepeiM2YSvYenXlEtaONrKB7T0jf jQdnQF9gwbTo2gI1aSbPRNA6/Bu96qCrADZxXUcWGOqreDL4fzyEJBaK8fO6hgX9pzXa bagIMVT5ZQujB5UWDI8QmXiPAHCCbprynWfYfi8uWVXmo/9MVl9SumYMbc6PX6yTp6c4 EAnxcLvshMfCefNIzXAXBYjX3y4IeyP10WN1uw6KvhWWa+SDqbdmkB6jx7cbkd+9VvxL WTZzdHhk4FRYHc790RjObV316h9OyFke5pAdawmmBHwuJQ3FZJihhOXyK1TkAqSYnex2 1lAg== X-Gm-Message-State: AA6/9Rktkm6/JcZtKnAC43Tfq7/OEm0xsHVZ6sFMlHLP8bGriOkv6ZjFVA3vsYRYR4muN/n/u1tZR6kp8FsyMA== X-Received: by 10.55.155.15 with SMTP id d15mr3981284qke.115.1476850862412; Tue, 18 Oct 2016 21:21:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Tue, 18 Oct 2016 21:21:01 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Wed, 19 Oct 2016 15:21:01 +1100 Message-ID: To: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: draft-ietf-webpush-protocol@ietf.org, "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-webpush-protocol X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 04:21:05 -0000 Thanks for the review Magnus. On 14 October 2016 at 16:06, Magnus Nystr=C3=B6m wrote: > The only slight concern I have is related to > the authorization of receiving push messages. The technique used is > essentially bearer tokens (knowledge of a URL). It therefore seems as > if unintended sharing of such a capability URL could cause other user > agents to get access to push notifications. I wonder if the work > around token binding in TLS (holder-of-key tokens) could be applicable > here, at least in the future. You will be pleased to know then that we have additional work in the pipeline that uses JWT to strengthen things. It's not perfect in that there is a chance of replay (the token is valid for multiple requests), but that was a security/operational considerations trade-off: https://tools.ietf.org/html/draft-ietf-webpush-vapid-01 From nobody Thu Oct 20 03:32:57 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 993DF12958E for ; Thu, 20 Oct 2016 03:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=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 8MdL93arGaGK for ; Thu, 20 Oct 2016 03:32:53 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65A4E129561 for ; Thu, 20 Oct 2016 03:32:53 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u9KAWlXv001912 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 20 Oct 2016 13:32:47 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u9KAWlC7022506; Thu, 20 Oct 2016 13:32:47 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22536.40271.506256.931101@fireball.acr.fi> Date: Thu, 20 Oct 2016 13:32:47 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 10:32:55 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Dacheng Zhang is next in the rotation. For telechat 2016-10-27 Reviewer LC end Draft Ben Laurie TR2016-10-10 draft-levine-herkula-oneclick-07 Eric Osterweil T 2016-10-19 draft-ietf-i2rs-ephemeral-state-19 Vincent Roca T 2016-10-18 draft-ietf-mpls-rfc4379bis-07 Joe Salowey T 2016-10-17 draft-ietf-pce-stateful-pce-app-07 Rich Salz T 2016-10-19 draft-ietf-roll-routing-dispatch-02 For telechat 2016-11-03 Matthew Miller T 2016-10-06 draft-ietf-stox-7248bis-13 Melinda Shore T 2016-10-25 draft-ietf-httpauth-mutual-10 Takeshi Takahashi T 2016-10-25 draft-ietf-httpauth-mutual-algo-06 David Waltermire T 2016-10-28 draft-ietf-l2tpext-keyed-ipv6-tunnel-07 Klaas Wierenga T 2016-11-01 draft-ietf-stir-certificates-10 Paul Wouters T 2016-11-01 draft-ietf-stir-passport-09 Liang Xia T 2016-11-01 draft-ietf-stir-rfc4474bis-14 For telechat 2016-12-01 Brian Weis T 2016-10-24 draft-ietf-pim-join-attributes-for-lisp-05 Last calls and special requests: Alan DeKok 2016-04-30 draft-bradner-rfc3979bis-08 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Warren Kumari 2016-09-06 draft-sweet-rfc2911bis-11 Hannes Tschofenig E None draft-ietf-ntp-network-time-security-15 Hannes Tschofenig E None draft-ietf-ntp-cms-for-nts-message-06 Hannes Tschofenig E None draft-ietf-ntp-using-nts-for-ntp-06 Tina TSOU 2016-11-14 draft-ieee-urn-02 Carl Wallace 2016-11-02 draft-ietf-kitten-rfc6112bis-02 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-10 Tom Yu 2016-11-15 draft-leiba-3967upd-downref-00 -- kivinen@iki.fi From nobody Thu Oct 20 06:28:08 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9050F1295BA; Thu, 20 Oct 2016 06:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.05 X-Spam-Level: X-Spam-Status: No, score=-3.05 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 wvc1kAeX2Lof; Thu, 20 Oct 2016 06:28:04 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38D1D1295BC; Thu, 20 Oct 2016 06:28:04 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id A407240708; Thu, 20 Oct 2016 15:28:02 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.60]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 68E0E1A01BB; Thu, 20 Oct 2016 15:28:02 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM7F.corporate.adroot.infra.ftgroup ([fe80::c1d7:e278:e357:11ad%19]) with mapi id 14.03.0319.002; Thu, 20 Oct 2016 15:28:02 +0200 From: To: Hilarie Orman , "iesg@ietf.org" , "secdir@ietf.org" Thread-Topic: Security review of draft-ietf-l3sm-l3vpn-service-model-16 YANG Data Model for L3VPN service delivery Thread-Index: AQHSIylt3pEAtJd4K0qTTHQdGmYrLaCxYu8Q Date: Thu, 20 Oct 2016 13:28:01 +0000 Message-ID: <15009_1476970082_5808C662_15009_624_1_9E32478DFA9976438E7A22F69B08FF921DB26F21@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <201610101904.u9AJ4dgA000607@rumpleteazer.rhmr.com> In-Reply-To: <201610101904.u9AJ4dgA000607@rumpleteazer.rhmr.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-l3sm-l3vpn-service-model.all@tools.ietf.org" Subject: Re: [secdir] Security review of draft-ietf-l3sm-l3vpn-service-model-16 YANG Data Model for L3VPN service delivery X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 13:28:06 -0000 Hi, Please find some comments inline Thanks -----Original Message----- From: Hilarie Orman [mailto:hilarie@purplestreak.com]=20 Sent: Monday, October 10, 2016 21:05 To: iesg@ietf.org; secdir@ietf.org Cc: draft-ietf-l3sm-l3vpn-service-model.all@tools.ietf.org Subject: Security review of draft-ietf-l3sm-l3vpn-service-model-16 YANG Dat= a Model for L3VPN service delivery [Including subject line on resend] Security review of YANG Data Model for L3VPN service delivery draft-ietf-l3sm-l3vpn-service-model-16 Do not be alarmed. I have reviewed this document as part of the security d= irectorate's ongoing effort to review all IETF documents being processed by= the IESG. These comments were written primarily for the benefit of the se= curity area directors. Document editors and WG chairs should treat these c= omments just like any other last call comments. The document uses the YANG data model to describe an abstracted view of Lay= er 3 Provider Provisioned VPN services. The model has specific support for describing authentication and encryption= requirements. Perhaps I'm not imaginative enough to understand how they w= ould be used, but my impression is that the models are incomplete. grouping site-security-authentication { container authentication { description "Authentication parameters"; } description "This grouping defines authentication parameters for a site"; } In the data model shown above for "authentication", I'm not sure who the pa= rties in the authentication are and where enforcement takes place. This ma= y be evident to those who are more familiar with VPN provisioning. If so, = some additional description would be helpful. [SLI] We are not defining any authentication mechanism in the model. The co= ntainer is just there to allow easy augmentation. This is stated in section= 5.9.1. grouping site-security-encryption { container encryption { if-feature encryption; leaf enabled { type boolean; description "If true, access encryption is required."; } leaf layer { type enumeration { enum layer2 { description "Encryption will occur at layer2."; } enum layer3 { description "IPSec is requested."; } Is IPSec the only layer 3 encryption method that is supported? [SLI] I think the description is bad, it can be any layer 3 encryption mech= anism, IPSec is one. } description "Layer on which encryption is applied."; } container encryption-profile { choice profile { case provider-profile { leaf profile-name { type string; description "Name of the SP profile to be applied."; The "SP profile" is something defined by the service provider. All the par= ameters and their interpretations are defined in some out-of-band way by th= e service provider. This seems to impose a great deal of difficulty for th= e customer.=20 [SLI] Yes there is a need of out of band discussion. Operator is allowing c= ustomer to use a set of profiles. It's not really difficult as today, most = of the SPs works this way with customers. Should the provider arbitrarily change the definition, the customer's conf= iguration parameters might be dangerously misinterpreted.=20=20 [SLI] We usually do not change the definition of the profile because it is = linked to a particular service selled to a customer. We can change paramete= rs that does not affect the service. Or, a customer trying to move to a different service provider might see a s= imilar profile and try to use the same parameters. Subtle differences in i= nterpretation could lead to a security vulnerability. } } case customer-profile { leaf algorithm { type string; description "Encryption algorithm to be used."; } choice key-type { case psk { leaf preshared-key { type string; description "Key coming from customer."; How does the customer submit the key? Should there be a key identifier? P= erhaps the customer and the provider have a public key communication channe= l and the customer encrypts the keys and sends them to the provider, identi= fying them through the key identifiers? Is there a key update procedure? [SLI] The only supported method here is to submit the key through the RESTC= ONF or NETCONF over a secured channel. } } case pki { } description "Type of keys to be used."; Is "type of keys" supposed to imply the algorithm for key derivation? [SLI] The model does not support PKI, container is there just for augmentat= ion. This is not highlighted , I can add it. } } description "Choice of profile."; } description "Profile of encryption to be applied."; } I assume the profiles are the opaque "external identifiers"? [SLI] Right. "5.14. External ID references The service model sometimes refers to external information through identifiers. As an example, to order a cloud-access to a particular Cloud Service Provider (CSP), the model uses an identifier to refer to the targeted CSP. In case, a customer is using directly this service model as an API (through REST or NETCONF for example) to order a particular service, the service provider should provide a list of authorized identifiers. In case of cloud-access, the service provider will provide the identifiers associated of each available CSP. The same applies to other identifiers like std-qos-profile, oam profile-name, provider-profile for encryption ... How SP provides those identifiers meaning to the customer is out of scope of this document." If the request is spoofed or misunderstood in some way, then the encryption= may be downgraded. How is the configuration protected? [SLI] I'm not sure it does really deal with this service model itself, it's= more a global issue that the SP need to address. I think there should be a way to sign a model. There is an implied contrac= t between the customer and the network owner, and the authenticity of the r= equest seems paramount. An example of the very confusing typos that are sprinkled throughout the do= cument: "I want my current site-network-access to be not be connected on the same PoP ..." Another confusing statement: "1. Introduction This document defines a YANG data model for communication between customers and network operators, and to provide input to automated control and configuration applications. " The introduction does not conform to the rules of English grammar. I'm not entirely sure what it means. Perhaps " This document defines a YANG data model. The model defines elements that can be used in communication protocols between customers and network operators. Those elements can be used also as input to automated control and configuration applications. " ?? The document is marred by running afoul of the two notoriously difficult as= pects of English grammar: subject/verb agreement and articles. The errors = are too numerous to mention. For the most part, the meaning of the afflict= ed sentences is clear, but not always. The document should not be publishe= d until the errors are corrected. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Oct 20 14:47:01 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9AAE126D73 for ; Thu, 20 Oct 2016 14:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 8VS3w9GegGnY for ; Thu, 20 Oct 2016 14:46:26 -0700 (PDT) Received: from nm11.bullet.mail.ne1.yahoo.com (nm11.bullet.mail.ne1.yahoo.com [98.138.90.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AF691294F9 for ; Thu, 20 Oct 2016 14:46:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1476999985; bh=Z+8wAcuy8ig62o57zIS7IyojH2jgng2aYnqltj4J7OE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=VLj3AVG6jiKrbeHTob+tAt7eQ86pvRIzOs10RQWcOcoBk9HkeU6H87TvXvb+OLt+fgKUnMYZEIIfkoV2dRZ2TkY7KjmoKlbYrj+QqDwHb6IJOaXASli0R27dnwDTFogMznobs1w6zR08WLleSLBHKMvemOHFULKWRpGIxFNPDIBlgQUmEv8Ddfu5wOf9pF0LnRiz/TrxWyrlRsSuTNUN7O3hQRO/k2b2LtNTbpgE0VXMr4V1B4VTsZtX+do1hS9Ri9Sv7KNGdg+4VV9H/JPJMcKcg6dM1mUBVESWofRa3dDjX0kXrLogqFn6U+EnnPjDxYFqSoApecEcLPms576oaw== Received: from [98.138.101.129] by nm11.bullet.mail.ne1.yahoo.com with NNFMP; 20 Oct 2016 21:46:25 -0000 Received: from [98.138.89.234] by tm17.bullet.mail.ne1.yahoo.com with NNFMP; 20 Oct 2016 21:46:25 -0000 Received: from [127.0.0.1] by omp1049.mail.ne1.yahoo.com with NNFMP; 20 Oct 2016 21:46:25 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 279506.42914.bm@omp1049.mail.ne1.yahoo.com X-YMail-OSG: XEm0GlIVM1lwF4ElHGUukGA.ozXkMgKLasxkJy84SS94CbtnUQblN.gMyBrLHH. HzJq5LLNnAmTy7b.DO3V7QVHTR8C14YJ7q5MOZpEe1MPtSS004Wn.BRCFrPxehLHpX7MbPNOeHI8 s.17PBI1chNpcysJIbpgM.N8cMyzYl5dWNo0e2Nm3P5i32bD0Uk6DvkY21ZzmXRF28TdLHD7IluH A0AV0HzW8DBguzcmoGhVoYaQPJgwvviTUxHNzXqUxbAUrZMK6.snnz6tsVEOxAwWfgTt8f5f.MbF 9EmZpctDlXhO6ZyM9s6cBN00SlMWs9hiUQ7BBFK8IdSHqZ3L6nuRT6VMsOk5268Fxtigw31sgAUC bfIxHjeaUB3Hrs1p6GcGd6rCAJP7zMrJ2K9zP8qPhAw6ViHPnVSGFD6GUox_iAqek3359dQf0m3C I0Beq1R_oPX4rn2iYM494ZccMkdxw.uAUJyaLqVLUVBeyJG2Us98HN45RcmmS3tw4ixq9CnjhkAF 5NnbuIfRbSb._dyVdc4Y9NRGP9lrO87d0oeixsE63E42.y8fbDpk- Received: from jws200177.mail.ne1.yahoo.com by sendmailws158.mail.ne1.yahoo.com; Thu, 20 Oct 2016 21:46:24 +0000; 1476999984.893 Date: Thu, 20 Oct 2016 21:46:19 +0000 (UTC) From: To: Tero Kivinen Message-ID: <1103626655.678358.1476999979368@mail.yahoo.com> In-Reply-To: <22523.36827.869306.70163@fireball.acr.fi> References: <22495.62038.771947.984586@fireball.acr.fi> <1264225155.363685.1474644268281@mail.yahoo.com> <22507.60901.665544.878052@fireball.acr.fi> <1130739157.4563724.1475509147203@mail.yahoo.com> <22523.36827.869306.70163@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "iesg@ietf.org" , "draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-05: Timing Attacks X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 21:46:55 -0000 Tero, Continuing to address the changes, this thread will discuss changes for Timing Attacks which may now be possible. > >Key management packets are usually in clear, as they are there before > >we have the actual keys we can use to protect the messages. Also it is > >not very difficult to guess that 3rd and 4th message in port 500, are > >the IKE AUTH packets, which will contain signatures. > > >Same thing with TLS. > > >Attackers will knows which packets contain signatures. Currently > >attackers usually send those signature packets themselves, and measure > >the time it takes for the device to calculate response. They can also > >send garbage packets, and detect how far in checking the packets got > >by checking how long it took for the other end to send error message > >back. > > >All this kind of timing attacks are usually considered hard, as the > >network delays cause big jitter on the timings, and they need to try > >multiple times, and average the response times to get the information > >they need. > > >This method will provide them easy way to bypass that issue. > >Yes, timing attacks are possible against any crypto protocol. If the >protocol and algorithms used in the protocol are specifically written >so that they are protected against timing attacks, they will not work, >but lots of the implementations and protocols care more about the >speed, than for the timing attacks, especially as launching them over >longer distance gets harder and harder as other things add random >times to measurements. >If this allows easy way to get exact timing information from the node >without any issues from the network latencies and so on, this might >open completely new ways to attack implementations and protocols. >Those attacks were not feasible before, but now they might be. Add to Section 8: 8.4 Timing Attacks The fact that PDM can help in the separation of node processing time from network latency brings value to performance monitoring. Yet, it is this very characteristic of PDM which may be misused to make certain new type of timing attacks against protocols and implementations possible. Having said that, PDM is more likely to be used in response to an attack to find whether there are problems in the network or the node rather than its temporary use being exploited to mount an attack. The normal use of PDM is likely to be for testing and diagnostics. So, this is a short-term opportunity for an attacker. Even so, if using PDM, we introduce the concept of user "Consent to be Measured" as a pre-requisite for using PDM. Consent is common in enterprises and with some subscription services. So, if with PDM, we recommend that the user SHOULD consent to its use. Thanks, Nalini Elkins Inside Products, Inc. www.insidethestack.com (831) 659-8360 ----- Original Message ----- From: Tero Kivinen To: nalini.elkins@insidethestack.com Cc: "iesg@ietf.org" ; "secdir@ietf.org" ; "draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" Sent: Monday, October 10, 2016 5:55 AM Subject: Re: Secdir review of draft-ietf-ippm-6man-pdm-option-05 nalini.elkins@insidethestack.com writes: > >There are most likely also other kind of attacks, and as this is > >service as ESP provides, it is not for PDM to break it unless you > >explictly spell it out that this is meant to break property of the > >ESP. > > OK. I am convinced. I will tell you though that some of us in IPPM, > we were quite excited (possibly naively) about being able to get > some performance metrics for ESP. Why do you think you can performance metrics for ESP in that case? > I wonder if it would be acceptable to say that PDM could be put into > the Destination Option which precedes ESP if it is for an enterprise > customer who owns the infrastructure and wishes to manage the > network that way. Otherwise, I can change to say that only the Dest > Opt following ESP can be used. I would recommend that if you use transport mode ESP (i.e., where the flow information would be leaked out from the ESP if PDM is used) then it must be put inside the ESP. If you use tunnel mode ESP, then there migth be two PDM headers in the packet, one in the inner packet inside the ESP header (which has full IP header + destination options including PDM option), and another one in the outer header, in which case it would only cover the ESP as one flow (i.e., each ESP SA identified by the SPIs would get separate PDM option). I.e. in the Tunnel mode ESP you want to defined the "5-tuple" as: SADDR, DADDR, PROTC (=ESP), SPI-IN, SPI-OUT Btw, in the ICMP etc you do not have port numbers. Are ICMP frames related to the TCP flows matching the "5-tuple" of the TCP flow or are they counted as separate? Anyways so if you define Tunnel mode ESP that way, then you can get some performance metrics from the ESP processing also. Then if the enterprice is willing to sacrifice the traffic flow confidentiality, they can turn on the sa-per-flow option of the IPsec implementation, which will create separate SA pair for each TCP/UDP etc flow, so then they will get exact measurements. In normal case the Tunnel mode ESP will just provide performance metrics for combination of all traffic inside the tunnel, not per flow. When using the Transport Mode ESP, then putting the PDM option inside still provides performance metrics for the host. > >so the range is definately enough. The question is that if the scale > >is from -127 to 128, why do we even need the Time Base? > > The time base is so that one does not have to be committed to > picoseconds / milliseconds, etc. Even in your example, I believe > you used "unit" or time base. Our thinking was that we wanted > future proof so as to be able to handle very small values and very > large (as may be needed for DTN, for example). We can see if we can > express years in picoseconds and see what happens. Then, the unit > would always be picoseconds. Having scale from -127 to 128 will provide quite good future proof, for at least for this universum. Even if you used attoseconds as base, you could express 10^13 years which is still more than 1000 times longer than the current age of the universe... > >3.5 Implementation Considerations > > > The PDM destination options extension header SHOULD be turned on by > > each stack on a host node. It MAY also be turned on only in case of > > diagnostics needed for problem resolution. > > > so it seems it is on by default. > > Will change to say that it MUST be turned on only by the stack and > default value should be OFF. > > "The PDM destination options extension header MUST be turned on only > by administrative action at each stack on a host node. The default > mode for PDM is OFF." Good. > >Key management packets are usually in clear, as they are there before > >we have the actual keys we can use to protect the messages. Also it is > >not very difficult to guess that 3rd and 4th message in port 500, are > >the IKE AUTH packets, which will contain signatures. > > >Same thing with TLS. > > >Attackers will knows which packets contain signatures. Currently > >attackers usually send those signature packets themselves, and measure > >the time it takes for the device to calculate response. They can also > >send garbage packets, and detect how far in checking the packets got > >by checking how long it took for the other end to send error message > >back. > > >All this kind of timing attacks are usually considered hard, as the > >network delays cause big jitter on the timings, and they need to try > >multiple times, and average the response times to get the information > >they need. > > >This method will provide them easy way to bypass that issue. > > OK. So, are you saying that PDM is attack vector for TLS and not > just for ESP? Yes, timing attacks are possible against any crypto protocol. If the protocol and algorithms used in the protocol are specifically written so that they are protected against timing attacks, they will not work, but lots of the implementations and protocols care more about the speed, than for the timing attacks, especially as launching them over longer distance gets harder and harder as other things add random times to measurements. If this allows easy way to get exact timing information from the node without any issues from the network latencies and so on, this might open completely new ways to attack implementations and protocols. Those attacks were not feasible before, but now they might be. > No, obviously not. So, now I am not sure where we are. Is there a > complete objection to this draft or are there changes which can be > made which would make this acceptable? Yes, I do not think there is anything that cannot be fixed, but there are things that needs fixing (from the security point of view): 1) Location of the PDM in ESP transport mode traffic. 2) Make sure this is turned off by default, and you do not want node to respond incoming PDM options unless turned on by adminstrator. 3) Add to security considerations section aclear warnings about the new possibilities for timing attacks if PDM is turned on. (not sure if I forgot something). -- kivinen@iki.fi From nobody Fri Oct 21 01:13:20 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38A3129521; Fri, 21 Oct 2016 01:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.33 X-Spam-Level: X-Spam-Status: No, score=-7.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=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 VFN_eXnHG6-o; Fri, 21 Oct 2016 01:13:12 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E71C1294F4; Fri, 21 Oct 2016 01:13:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.31,375,1473112800"; d="asc'?scan'208,217";a="241724985" Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO [192.168.1.133]) ([82.236.155.50]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Oct 2016 10:13:09 +0200 From: Vincent Roca X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_F335C447-FDBE-4867-9730-78C6CF79696D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Fri, 21 Oct 2016 10:13:06 +0200 Message-Id: To: IESG , secdir@ietf.org, draft-ietf-mpls-rfc4379bis.all@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [secdir] Secdir review of draft-ietf-mpls-rfc4379bis-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 08:13:15 -0000 --Apple-Mail=_F335C447-FDBE-4867-9730-78C6CF79696D Content-Type: multipart/alternative; boundary="Apple-Mail=_DAE3EAF5-57A2-48A0-87C3-EB91BAF4E4B7" --Apple-Mail=_DAE3EAF5-57A2-48A0-87C3-EB91BAF4E4B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, I have reviewed this document as part of the security directorate=E2=80=99= s ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments = just like any other last call comments. IMHO, the document is Ready with issues. I have two main comments: 1- This document has an interesting security considerations section. = However it lacks some key information. First of all, there is no attacker model. Is = the threat coming from corrupted equipment? Do we assume those attackers = have full control over the equipment and flows? Are attackers on path or off path? Clarifying these points (it's not an exhaustive list) would help = structuring the discussion on a case by case basis. 2- Something else to clarify: I have the feeling (after quickly = searching integrity/ authentication/HMAC/... keywords in the doc) that is no message = integrity nor sender authentication mechanism in the echo request/response = detailed here. If the attacker model also includes a full control of LSR, nothing can = be done to prevent some attacks. Please clarify. And a few additional ones: 3- First sentence says: "Overall, the security needs for LSP ping are similar to those of = ICMP ping." Such debugging tools as ping and traceroute (not speaking of MPLS = version here) have an efficiency that heavily relies on (sometimes arbitrary) = decisions made by the system administrators whose security policies lead to total or = partial blackholes. Hence my questions: is the situation similar with MPLS or can we expect = more homogeneous and favorable security policies (e.g., because there's a = limited number of administrative domains, or because we are not relying on an = ICMP mechanism any more, or because the present document is more directive on what a system administrator should authorize/block/limit)? This could change a lot the security aspects and the potential impacts = on the debugging tools. 4- Later it is said: "To avoid potential Denial-of-Service attacks, it is RECOMMENDED = that implementations regulate the LSP ping traffic going to the control plane. A rate limiter SHOULD be applied to the well-known UDP port defined below." - Do you mean port 3503? It is mentionned but not defined below in this = section. Wording should be adjusted. - It is not clear to me by reading this sentence if it concerns the = sender (who sends traffic to the control plane) or forwarding nodes, which I = guess are the target. In other words, "going to the control plane" is = somewhat ambiguous. 5- Then: "To protect against unauthorized sources using MPLS echo request messages to obtain network information, it is RECOMMENDED that implementations provide a means of checking the source addresses of MPLS echo request messages against an access list before accepting the message." Are ACL efficient in this context? If an attacker can forge the source = address, it's not. Unless some cryptographic mechanism is used, there's little = hope to provide a secure ping service. This is a follow up of comment 1. - Typo: "...an implementation MAY also validate the TimeStamp Sent by requiring an exact match on this field." Sent =3D> sent. Cheers, Vincent --Apple-Mail=_DAE3EAF5-57A2-48A0-87C3-EB91BAF4E4B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello,

I have reviewed this = document as part of the security directorate=E2=80=99s ongoing
effort to review all IETF documents being processed by the = IESG. These
comments were written primarily for the = benefit of the security area
directors.  Document = editors and WG chairs should treat these comments just
like = any other last call comments.

IMHO, the document is Ready with = issues.

I have two main = comments:

1- This document has an interesting security considerations = section. However it
lacks some key information. = First of all, there is no attacker model. Is the
threat coming from corrupted equipment? Do we assume those = attackers have full
control over the equipment and = flows? Are attackers on path or off path?
Clarifying = these points (it's not an exhaustive list) would help structuring = the
discussion on a case by case basis.


2- Something else to clarify: I have the feeling (after = quickly searching integrity/
authentication/HMAC/... = keywords in the doc) that is no message integrity
nor= sender authentication mechanism in the echo request/response detailed = here.
If the attacker model also includes a full = control of LSR, nothing can be done to
prevent some = attacks. Please clarify.


And a few additional = ones:

3- First = sentence says:
   "Overall, the security = needs for LSP ping are similar to those of ICMP ping."
Such debugging tools as ping and traceroute (not speaking of = MPLS version here)
have an efficiency that heavily = relies on (sometimes arbitrary) decisions made
by = the system administrators whose security policies lead to total or = partial
blackholes.
Hence my = questions: is the situation similar with MPLS or can we expect = more
homogeneous and favorable security policies = (e.g., because there's a limited
number of = administrative domains, or because we are not relying on an = ICMP
mechanism any more, or because the present = document is more directive on
what a system = administrator should authorize/block/limit)?
This = could change a lot the security aspects and the potential impacts on = the
debugging tools.


4- = Later it is said:
     "To avoid = potential Denial-of-Service attacks, it is RECOMMENDED that
     implementations regulate the LSP ping = traffic going to the control
    =  plane.  A rate limiter SHOULD be applied to the well-known = UDP port
     defined = below."
- Do you mean port 3503? It is mentionned = but not defined below in this section.
  = Wording should be adjusted.
- It is not clear to me = by reading this sentence if it concerns the sender
  (who sends traffic to the control plane) or forwarding = nodes, which I guess
  are the target. In = other words, "going to the control plane" is somewhat
  ambiguous.


5- = Then:
     "To protect against = unauthorized sources using MPLS echo request
  =    messages to obtain network information, it is RECOMMENDED = that
     implementations provide a = means of checking the source addresses of
  =    MPLS echo request messages against an access list before = accepting
     the = message."
Are ACL efficient in this context? If an = attacker can forge the source address,
it's not. = Unless some cryptographic mechanism is used, there's little hope = to
provide a secure ping service. This is a follow = up of comment 1.


- Typo:
     "...an implementation MAY also validate = the TimeStamp
     Sent by requiring = an exact match on this field."
Sent =3D> = sent.

Cheers,

  Vincent
= --Apple-Mail=_DAE3EAF5-57A2-48A0-87C3-EB91BAF4E4B7-- --Apple-Mail=_F335C447-FDBE-4867-9730-78C6CF79696D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYCc4TAAoJEHBYw8t72N4rVhIQAMKgfu9JwrWd6eABy4/LliO+ WTh7xaOq98nEMEDQr5pHbH41cdU2934Gxn9kD1DW8pX85ajkHM7XIWkhuKuBroqG 8u3OYjfuTA/tZruLufoI4psZhFpqVCS3Ft/Okm0RoyPQKvm/t6+rYn+llv8Llluw psjPmeigRNbZa8NCySK9ljkRfShCcJS7eJYvAppPJ5bNIsAk1jNWrYrIbd4zP6U7 7ZkTo6urUS7LQUXczeO6uT5wMNpO/BVuV+YaWmOUpCHbkSPHQJXdkxsU4f5KIwSd xt3SLhHiyLmns8dryMnW0KEZWNnZdHFBF3toqO6uENgPILjXGOsCXIUjFUqL0Mww UXOzx0jlWBSahV5AquD9CtSoVO2FjtXXPmPOedS4NF8FfOkSzTdZhvFcxzZtoF8s eHqS3p/LHaG6ytKoWUpHd4DAZZTWT6API+cbupEf1DW7FTHpqcgc45jcHFBOZjME IR5q12FnxMdkRrOHLvXd9NsUhQf0eK4cZIC+rf35i3oHDefdOcxs6MSYsGARDrXa L2qdNQ5rWO1QO72VpVHSUxnu2tt8PQmrBsCRy03XLSVCDt9Tk8DVjYFACdvNuHLX CmX4ui8ZJIef2IfBhDh0/Hd38GznfQyfyZnan2QcxnLRlUEdlflSRO22kCHslA11 fvLr1wGiCJ0NJChk8qxC =3ItN -----END PGP SIGNATURE----- --Apple-Mail=_F335C447-FDBE-4867-9730-78C6CF79696D-- From nobody Fri Oct 21 10:51:30 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE0B1294A0; Fri, 21 Oct 2016 10:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.952 X-Spam-Level: X-Spam-Status: No, score=-14.952 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 5McPm_GvKN6W; Fri, 21 Oct 2016 10:51:27 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8418F12948A; Fri, 21 Oct 2016 10:51:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2710; q=dns/txt; s=iport; t=1477072287; x=1478281887; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=5nWk7OJfDz3O5/f0L4YjvQ4P6ojyv4N6pXm7bNcnAf8=; b=JsEmUnlht0RcZV7KFgfGgRwUQDIsUYPDfS24wYGTVdqyRqFjsMomECnl gzTYVurw03Z2juxlw8ul3RrC5JNvkppc3oUxBIT/hrgTi5aZUKsgFmf3T WL1Ei6u04YeakPhAi2IgaCPARKiDKe2b6itY78j0JauvbwOGdGULCbZrw o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BtAQA6VQpY/5BdJa1ZAxoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYM+AQEBAQEdgVQHjS2rO4IHhiEcgU4/FAECAQEBAQEBAWIohGkjEVc?= =?us-ascii?q?BIgImAgQwFRIEARKIUrYsjQIBAQEBAQEBAQEBAQEBAQEBIYEHhzOGcREBMwomg?= =?us-ascii?q?j0sgi8FmhMBkA+QAZEBAR42WYR/coYogSCBAAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,377,1473120000"; d="scan'208";a="164619835" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Oct 2016 17:51:26 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u9LHpQLk011705 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 21 Oct 2016 17:51:26 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 21 Oct 2016 13:51:25 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1210.000; Fri, 21 Oct 2016 13:51:25 -0400 From: "Brian Weis (bew)" To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-pim-join-attributes-for-lisp.all@tools.ietf.org" Thread-Topic: SecDir review of draft-ietf-pim-join-attributes-for-lisp-05 Thread-Index: AQHSK8O+yDHqFrGIdUei87jOMqaOYg== Date: Fri, 21 Oct 2016 17:51:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.191.163] Content-Type: text/plain; charset="utf-8" Content-ID: <71744C0CEEA9A743B82A88BAA828BD39@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [secdir] SecDir review of draft-ietf-pim-join-attributes-for-lisp-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 17:51:28 -0000 SSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGly ZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJl aW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHBy aW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiBE b2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRz IGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQpJIGNvbnNpZGVyIHRo aXMgZHJhZnQgdG8gYmUgUmVhZHkuDQoNCldoZW4gYSBMSVNQLWVuYWJsZWQgc2l0ZSBoYXMgYSBt dWx0aWNhc3Qgc291cmNlIGVtaXR0aW5nIG1lc3NhZ2VzIHRvIG90aGVyIExJU1AtZW5hYmxlZCBz aXRlcywgUElNIGlzIHVzZWQgdG8gcmVwb3J0IHRoYXQgdGhlcmUgYXJlIG11bHRpY2FzdCByZWNl aXZlcnMgd2l0aGluIHRob3NlIExJU1AtZW5hYmxlZCBzaXRlcy4gVGhlc2UgUElNIG1lc3NhZ2Vz IGFyZSBlbmNhcHN1bGF0ZWQgd2l0aCBMSVNQIG92ZXIgdGhlIHByb3ZpZGVyIG5ldHdvcmsgKOKA nFJMT0MgYWRkcmVzcyBzcGFjZeKAnSkgdG8gYSBMSVNQIElUUiBhdCBzaXRlIGNvbnRhaW5pbmcg dGhlIG11bHRpY2FzdCBzb3VyY2UuIFRoaXMgSW50ZXJuZXQtRHJhZnQgYWRkcyBhbiBhdHRyaWJ1 dGUgdG8gUElNIHRoYXQgZW5hYmxlcyBQSU0gYXQgdGhlIExJU1AgeFRSIGluIGZyb250IG9mIGEg bXVsdGljYXN0IHJlY2VpdmVyIHRvIGluZGljYXRlIGhvdyBpdCB3b3VsZCBsaWtlIHRvIHJlY2Vp dmUgdGhlIG11bHRpY2FzdCBkYXRhIHBhY2tldHMuIEl0IG1heSBpbmRpY2F0ZSB0aGF0IHRoZSBM SVNQIG11bHRpY2FzdCBkYXRhIG1lc3NhZ2VzIGFyZSB0byBiZSBzZW50IGFzIG5hdGl2ZSBtdWx0 aWNhc3QgTElTUCBlbmNhcHN1bGF0ZWQgcGFja2V0cyAocmVwbGljYXRlZCBpbiB0aGUgcHJvdmlk ZXIgbmV0d29yaykgb3IgYXMgdW5pY2FzdCBMSVNQIHBhY2tldHMuIFdoZW4gdW5pY2FzdCBwYWNr ZXRzIGFyZSBzZWxlY3RlZCwgYW5vdGhlciBuZXcgYXR0cmlidXRlIGNhbiBpbmRpY2F0ZSAgZXhh Y3RseSB3aGljaCB1bmljYXN0IHJlY2VpdmVyIFJMT0MgdG8gd2hpY2ggdGhlIG11bHRpY2FzdCBt ZXNzYWdlcyBzaG91bGQgYmUgYWRkcmVzc2VkLiBTZWN1cml0eSBjb25zaWRlcmF0aW9ucyBvZiB0 aGUgc2VtYW50aWNzIGZvciBwcm90ZWN0aW5nIHRoZSBtdWx0aWNhc3QgZGF0YSBwYWNrZXRzIGFy ZSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KDQpUaGVzZSBuZXcgYXR0cmli dXRlcyBhcmUgYWxsIGRlbGl2ZXJlZCBpbiBQSU0gbWVzc2FnZXMsIHdoaWNoIGFyZSBzZW50IGVu Y2Fwc3VsYXRlZCBpbiBMSVNQLCBhbmQgaWYgYSB1c2VyIGhhcyBjaG9zZW4gdG8gcHJvdGVjdCB0 aGUgTElTUCB0cmFmZmljIGFjcm9zcyB0aGUgcHJvdmlkZXIgbmV0d29yayBmb3IgY29uZmlkZW50 aWFsaXR5IG9yIHByaXZhY3kgcmVhc29ucywgYW5kL29yIGNob3NlbiB0byBwcm90ZWN0IHRoZSBQ SU0gcGFja2V0cyB3aXRoIGFuIGludGVncml0eSBtZXRob2QsIHRoZW4gdGhlIG5ldyBhdHRyaWJ1 dGVzIHdpbGwgYWxzbyBiZSBwcm90ZWN0ZWQuIFRoZSBpbmZvcm1hdGlvbiBpbiB0aGUgYXR0cmli dXRlcyByZWxhdGVkIG9ubHkgdG8gZGVsaXZlcnkgb2YgdGhlIHBhY2tldHMsIGFuZCB0aGVyZSBh cmUgbm8gcGFydGljdWxhciBwcml2YWN5IGNvbnNpZGVyYXRpb25zLiBUaGUgY3VycmVudCBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIHNlZW1zIGFkZXF1YXRlLg0KDQpCcmlhbg0KDQot LSANCkJyaWFuIFdlaXMNClNlY3VyaXR5LCBDU0csIENpc2NvIFN5c3RlbXMNClRlbGVwaG9uZTog KzEgNDA4IDUyNiA0Nzk2DQpFbWFpbDogYmV3QGNpc2NvLmNvbQ0KDQo= From nobody Fri Oct 21 11:04:09 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7566F1295A4; Fri, 21 Oct 2016 11:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 wZNTb4rXZeiD; Fri, 21 Oct 2016 11:03:59 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E126112973D; Fri, 21 Oct 2016 11:03:56 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id s8so60609590pfj.2; Fri, 21 Oct 2016 11:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FogpXFML3n4UvRm++IewcvtbCmsRJBEedkAaOhtmKF8=; b=RCv82/upga7bijxhu4BSj7ttJoTiRk4K0ImPGv9Iw935wHI27ll7rDKsDnvJa+4Hcb +PKbmYcQqJCTb9yigP3BAk9HjI2aREZyypFvywoFoujpVjK2geRg6I+gWJx8cSN0sVww Ab0C4gkVDnCi2EDTL+Cc2gARRR4NqRzQrIbcGSA+afKc+rm0g7n9ppQWZwt7TLvGl9aJ hwK1lHnBKNIC6+oAS3Sy5Xp2SWaDSn/JXL33+NGIQXfhsn/rIm+ObuILDDIoYIDX304I jo5d7O6+ROyLfXNbXa+TUWQmIYnITFbvkc4dab3hT7yNTcl8tJhuZLQ2ewxxJL3gwhKm 6lLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FogpXFML3n4UvRm++IewcvtbCmsRJBEedkAaOhtmKF8=; b=H+wqEY/w4x1jMuqS6H2VV6rN2KB7CU0q16UoQMH7LvkqM9KDvK+HEAXnwSWQP6+SpI 30XVjs5TV3TNRNIk6NJnxtx5bVDGnb+FI95LqLzoHN2CLFZnRRumfeEYsiiFvALV6rXD /S//JGj0fTmbJf6Um7/8VrNsQiHD0OrRRGIGk0bJNNHXNYC+9osrt3/WZykA0eyl24RP bES/YAo81dL+AHBjGIpZA3jm+n4M7CsP1lcrpim35KdSOP2ZBuytgJRIRKBlQ9Mmktwv wzvPqVsRmWhS/zUGwkwDGf16CsIZZtFFJeE84RdC+QxD18nCWT92ZxFUpbvl3enKCT+6 humw== X-Gm-Message-State: ABUngvcdcFeqWiUmKZC5ZYd3wvvSxgyMAf4yK4LqSoXoLF4tc0xDTUGMPGYq4yNv6U11Vw== X-Received: by 10.98.193.2 with SMTP id i2mr3786980pfg.155.1477073035322; Fri, 21 Oct 2016 11:03:55 -0700 (PDT) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id p88sm6734791pfi.51.2016.10.21.11.03.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Oct 2016 11:03:54 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Dino Farinacci In-Reply-To: Date: Fri, 21 Oct 2016 11:03:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <06024438-DD50-435C-8B44-397287BDD7EA@gmail.com> References: To: Brian Weis X-Mailer: Apple Mail (2.3226) Archived-At: Cc: "draft-ietf-pim-join-attributes-for-lisp.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SecDir review of draft-ietf-pim-join-attributes-for-lisp-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 18:04:02 -0000 > These new attributes are all delivered in PIM messages, which are sent = encapsulated in LISP, and if a user has chosen to protect the LISP = traffic across the provider network for confidentiality or privacy = reasons, and/or chosen to protect the PIM packets with an integrity = method, then the new attributes will also be protected. The information = in the attributes related only to delivery of the packets, and there are = no particular privacy considerations. The current Security = Considerations section seems adequate. Yes, using lisp-crypto. But do you think different keying should be used = for data versus control traffic? Dino From nobody Fri Oct 21 14:19:40 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113B8129644; Fri, 21 Oct 2016 14:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.952 X-Spam-Level: X-Spam-Status: No, score=-14.952 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 IcWTcax9Ubg9; Fri, 21 Oct 2016 14:19:37 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F92D129640; Fri, 21 Oct 2016 14:19:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2624; q=dns/txt; s=iport; t=1477084777; x=1478294377; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Bd/pPoA3dloVJqnUAgULNo9VFhIRFs5QC2b7752zaQ0=; b=jYsVklnoztxHjllK1UlRaR8VQO7x4SnghIljFm484aQ6MDt81wvd2iGW MrXhiYugGyrayrXbOhyH2MT5phFNWLKbFVX8oEw5PQHyt4vk88sxFP0EI qpMFWD2sq7n3AwHiJl4K5yB+mn7dlSfkpZtY5TPnzpSJfbMfx+Iyp8CR4 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CWAQCchQpY/5tdJa1ZAxoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYM+AQEBAQEdgVQHjS2WfYdejGCCB4YhAhqBUD8UAQIBAQEBAQEBYii?= =?us-ascii?q?EYgEBAQMBIxFFBQsCAQgYAgImAgICHxEVEAIEDgWIOAMPCLYbiQcNg28BAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEcgQeHMwiCUIJHgVIRATMKJoI9LIIvBZleNQGMeIM?= =?us-ascii?q?XkAGIaYQZg38BHjZZhH9yhiOBIIEAAQEB?= X-IronPort-AV: E=Sophos;i="5.31,526,1473120000"; d="scan'208";a="336892006" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Oct 2016 21:19:36 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u9LLJaJE031209 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 21 Oct 2016 21:19:36 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 21 Oct 2016 17:19:35 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1210.000; Fri, 21 Oct 2016 17:19:35 -0400 From: "Brian Weis (bew)" To: Dino Farinacci Thread-Topic: SecDir review of draft-ietf-pim-join-attributes-for-lisp-05 Thread-Index: AQHSK8O+bD4Oo8T4K0G94NzRLPhqbqCzdn2AgAA2rQA= Date: Fri, 21 Oct 2016 21:19:35 +0000 Message-ID: References: <06024438-DD50-435C-8B44-397287BDD7EA@gmail.com> In-Reply-To: <06024438-DD50-435C-8B44-397287BDD7EA@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.191.163] Content-Type: text/plain; charset="utf-8" Content-ID: <73C8222A6AF68A409C5F0CDD1B01D481@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-pim-join-attributes-for-lisp.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SecDir review of draft-ietf-pim-join-attributes-for-lisp-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 21:19:39 -0000 SGkgRGlubywNCg0KPiBPbiBPY3QgMjEsIDIwMTYsIGF0IDExOjAzIEFNLCBEaW5vIEZhcmluYWNj aSA8ZmFyaW5hY2NpQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPj4gVGhlc2UgbmV3IGF0dHJpYnV0 ZXMgYXJlIGFsbCBkZWxpdmVyZWQgaW4gUElNIG1lc3NhZ2VzLCB3aGljaCBhcmUgc2VudCBlbmNh cHN1bGF0ZWQgaW4gTElTUCwgYW5kIGlmIGEgdXNlciBoYXMgY2hvc2VuIHRvIHByb3RlY3QgdGhl IExJU1AgdHJhZmZpYyBhY3Jvc3MgdGhlIHByb3ZpZGVyIG5ldHdvcmsgZm9yIGNvbmZpZGVudGlh bGl0eSBvciBwcml2YWN5IHJlYXNvbnMsIGFuZC9vciBjaG9zZW4gdG8gcHJvdGVjdCB0aGUgUElN IHBhY2tldHMgd2l0aCBhbiBpbnRlZ3JpdHkgbWV0aG9kLCB0aGVuIHRoZSBuZXcgYXR0cmlidXRl cyB3aWxsIGFsc28gYmUgcHJvdGVjdGVkLiBUaGUgaW5mb3JtYXRpb24gaW4gdGhlIGF0dHJpYnV0 ZXMgcmVsYXRlZCBvbmx5IHRvIGRlbGl2ZXJ5IG9mIHRoZSBwYWNrZXRzLCBhbmQgdGhlcmUgYXJl IG5vIHBhcnRpY3VsYXIgcHJpdmFjeSBjb25zaWRlcmF0aW9ucy4gVGhlIGN1cnJlbnQgU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiBzZWVtcyBhZGVxdWF0ZS4NCj4gDQo+IFllcywgdXNp bmcgbGlzcC1jcnlwdG8uIEJ1dCBkbyB5b3UgdGhpbmsgZGlmZmVyZW50IGtleWluZyBzaG91bGQg YmUgdXNlZCBmb3IgZGF0YSB2ZXJzdXMgY29udHJvbCB0cmFmZmljPw0KDQpJIGRvbuKAmXQgdGhp bmsgdGhleSBuZWNlc3NhcmlseSBuZWVkIHRvIGJlIGtleWVkIGRpZmZlcmVudGx5LiBJIGV4cGVj dCB0aGF0IHRoZSB4VFJzIGFyZSB0cnVzdGVkIHRvIGFyZSBkaXN0cmlidXRlIGJvdGggZGF0YSBh bmQgY29udHJvbCB0cmFmZmljIHRvIHRoZSBzYW1lIHBlZXJzLiAgQnV0IHRoZXJlIGFyZSBzb21l IGNvbnNpZGVyYXRpb25zIHRvIHVzaW5nIGxpc3AtY3J5cHRvIGZvciB0aGlzOg0KDQooMSkgIFNp bmNlIGxpc3AtY3J5cHRvIGRvZXNu4oCZdCBhY3R1YWxseSBhdXRoZW50aWNhdGUgdGhlIHBlZXIg KGkuZS4sIGl04oCZcyBpbnRlbnQgd2FzIGZvciBwcml2YWN5IG9mIGRhdGEpIHRoZW4gdGhlcmXi gJlzIG5vIGd1YXJhbnRlZSB0aGF0IHRoZSBQSU0gcGVlciBpcyBhdXRob3JpemVkLiBJZiBhdXRo b3JpemF0aW9uIG9mIHRoZSBwZWVyIGlzIG5vdCBuZWVkZWQsIHRoZW4gbm8gcHJvYmxlbS4gQnV0 IGlmIHlvdSBleHBlY3RlZCB0byByZXN0cmljdCB0aGUgZmxvdyBvZiBMSVNQIGVuY2Fwc3VsYXRl ZCBkYXRhIHRoZW4gb25jZSBzaG91bGQgdXNlIGFuIGVuY3J5cHRpb24gbWV0aG9kIHRoYXQgaW5j bHVkZXMgYXV0aGVudGljYXRpb24gb2YgdGhlIHBlZXIuDQoNCigyKSBJZiBib3RoIGZsb3dzIGFy ZSBwdXJlbHkgdW5pY2FzdCB0aGVuIGxpc3AtY3J5cHRvIGNhbiBiZSB1c2VkLCBidXQgc2luY2Ug bGlzcC1jcnlwdG8gaXMgRGlmZmllLUhlbGxhbSBiYXNlZCBvbmx5IHR3byB4VFJzIHdpbGwga25v dyB0aGUga2V5LiBXaGVuIExJU1AgcGFja2V0cyBhcmUgc2VudCBhcyBuYXRpdmUgbXVsdGljYXN0 IHBhY2tldHMgYWNyb3NzIHRoZSBwcm92aWRlciBuZXR3b3JrIHRoZXJlIGFyZSBsaWtlbHkgbXVs dGlwbGUgcmVjZWl2ZXJzLCBhbGwgb2Ygd2hpY2ggbmVlZCB0aGUgc2FtZSBzZXNzaW9uIGtleXMg YXMgdGhlIHNlbmRlci4gT25lIHdvdWxkIG5lZWQgdG8gdXNlIHNvbWV0aGluZyBsaWtlIEdET0kg KFJGQyA2NDA3KSB0byBkaXN0cmlidXRlIGEgZ3JvdXAga2V5IHRvIHRoZSB4VFJzIHRvIHByb3Rl Y3QgdGhlIGRhdGEgdHJhZmZpYy4NCg0KQnJpYW4NCg0KPiANCj4gRGlubw0KPiANCg0KLS0gDQpC cmlhbiBXZWlzDQpTZWN1cml0eSwgQ1NHLCBDaXNjbyBTeXN0ZW1zDQpUZWxlcGhvbmU6ICsxIDQw OCA1MjYgNDc5Ng0KRW1haWw6IGJld0BjaXNjby5jb20NCg0K From nobody Sat Oct 22 11:18:03 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA3B1295E5; Sat, 22 Oct 2016 11:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 FCXEwk_LpsZm; Sat, 22 Oct 2016 11:18:01 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18EA812944D; Sat, 22 Oct 2016 11:18:01 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id s8so74725778pfj.2; Sat, 22 Oct 2016 11:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Q1fQxj5f8UEr0voo6Xm/nuX/Lb7B6yz7ZtQRRuZxGNk=; b=GZQ5bzWvO82VOq46mXQPDa0bT7Mcr1sRaVqwU/0wacVaNYnZGnHMjfYZA9JK73c4V4 L4wSNjMllAbWVdlUMCRJ/94jIsbhZwwkyiW7+GcIV0R1oDLdYg/C/sbjDQvgQsIBcyWV iHaUx6+rtFWD0gTeGxgldz0b0gMgCaFioyhxKXMMoHmll3n5Jtqlgy9HjcCVy1ArqsfD hgN3ZKc7KA8OWuubTmX4Fb8q4bolSmka4H+mR+i7bnjKa8ohROAnwhzDyguosDuN5vXo NVND1kvIi0JLMqI7ua3jdt1ME1qF5itBOVj1Qac954o0qowvNRvuPb0LAeubr5QgEn1u u/3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Q1fQxj5f8UEr0voo6Xm/nuX/Lb7B6yz7ZtQRRuZxGNk=; b=IIEfjTEPuPoC8qZNhzZiHgVMo6aJ9gqEqwSZqPw6Ps33znic9Lyu6MSRwhFjztwsbI ArJx65HUx4AXPpu27vdo4ie+RgQEZvTR8LSLO4xGx7Z612NgETHITwTj01y2Bb5Jes2n 88TbSecQQaAvYgrK3o8gqpBI/WK3IKboCPVaGRTg3UOBhYH2dlshJ7Vcih8ra1jiIbai 6GLRgmmCZwEEpOZlLfpdAcLPL755dPpEZCy9rF6+vUk5hRa7/WxmUWM70ItjkN9Op7er K52qiULpKRbo3vDM/QV29fGGWIpIJpc5eTU7Kck+l3H2UhAX7LpZ49OTpBOihOzJzzo6 rRIw== X-Gm-Message-State: ABUngve+u+xgKtztIjR0xv7b4wnRh+564i0Dw25+bXnMddAIOtrKUPsu67SnlI0/s28DGw== X-Received: by 10.99.140.12 with SMTP id m12mr11005985pgd.45.1477160280667; Sat, 22 Oct 2016 11:18:00 -0700 (PDT) Received: from [10.194.125.197] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id h8sm13892897pab.9.2016.10.22.11.17.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 22 Oct 2016 11:18:00 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (14A456) In-Reply-To: Date: Sat, 22 Oct 2016 11:17:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5F81AC85-F3C9-404D-8012-F1B189BA3A1C@gmail.com> References: <06024438-DD50-435C-8B44-397287BDD7EA@gmail.com> To: "Brian Weis (bew)" Archived-At: Cc: "draft-ietf-pim-join-attributes-for-lisp.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SecDir review of draft-ietf-pim-join-attributes-for-lisp-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2016 18:18:02 -0000 > I don=E2=80=99t think they necessarily need to be keyed differently. I exp= ect that the xTRs are trusted to are distribute both data and Okay.=20 > control traffic to the same peers. But there are some considerations to u= sing lisp-crypto for this: >=20 > (1) Since lisp-crypto doesn=E2=80=99t actually authenticate the peer (i.e= ., it=E2=80=99s intent was for privacy of data) then there=E2=80=99s no guar= antee Well as you know the lisp-crypto cipher suites use AEAD so there is mechanis= m, we'd just need more detail here.=20 > that the PIM peer is authorized. If authorization of the peer is not neede= d, then no problem. But if you expected to Well we have to start out as an open system so any ETR is allowed to join an= ITR for an (S,G). Having it authorized to do so can be done by the mapping s= ystem. If the mapping system doesn't return the RLOC of the ITR for any ETR,= they can't join.=20 > (2) If both flows are purely unicast then lisp-crypto can be used, but sin= ce lisp-crypto is Diffie-Hellam based only two xTRs will know the key. When L= ISP packets are sent as native multicast packets across the provider=20 Right I was referring to the control plane where joins would normally be uni= cast.=20 > network there are likely multiple receivers, all of which need the same se= ssion keys as the sender. One would need to use something like GDOI (RFC 640= 7) to distribute a group key to the xTRs to protect the data traffic. Not trying to solve that. Right now if you want multicast to be encrypted, y= ou do that with replicated unicast, where the ITR uses different keys and ke= y-IDs for each packet being unicast encapsulated to each ETR.=20 Dino= From nobody Sun Oct 23 14:07:42 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6C012941C for ; Sun, 23 Oct 2016 14:07:41 -0700 (PDT) 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, RCVD_IN_MSPIKE_H2=-0.001] autolearn=unavailable autolearn_force=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 G62bb9wf85Pa for ; Sun, 23 Oct 2016 14:07:40 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp12.smtpout.orange.fr [80.12.242.134]) by ietfa.amsl.com (Postfix) with ESMTP id B236E12949B for ; Sun, 23 Oct 2016 14:07:39 -0700 (PDT) Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d35 with ME id z9061t00J17Lgi4039074s; Sun, 23 Oct 2016 23:00:08 +0200 X-ME-Helo: macbook-pro-de-julien-elie.home X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg== X-ME-Date: Sun, 23 Oct 2016 23:00:08 +0200 X-ME-IP: 92.170.5.52 To: Barry Leiba References: <20981db3190142193043f1445abadaa3@trigofacile.com> From: =?UTF-8?Q?Julien_=c3=89LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ Message-ID: Date: Sun, 23 Oct 2016 23:00:06 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-murchison-nntp-compress.all@ietf.org, IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-murchison-nntp-compress-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2016 21:07:41 -0000 Hi Barry, I've just taken into account your review in a new revision of the draft. Thanks again for it! FYI, the related changes are: https://github.com/ksmurchison/drafts/commit/ea2ad20efd248fd83ec8e859cf2ab0064b3c3b64 Do not hesitate to tell me in case something is still wrong. >> Maybe you would prefer for our document: >> >> Consequently, a server MAY list the AUTHINFO capability with >> no arguments, or not advertise it at all, in response to a CAPABILITIES >> command received from an unauthenticated client after a compression >> layer is active >> >> This way, we would no longer use SHOULD, but MUST and one MAY. > > It's a small point, but I don't like "MAY" to introduce two > alternatives, because it's not clear whether there might be other > alternatives as well... or not. How does it work for you to make it > "MUST" instead of "MAY", saying, therefore, that the server MUST > either list AUTHINFO with no arguments or not advertise it at all? > Then it's clear that there are two alternatives, and either is OK. > No? OK. I've adopted your suggestion. In order to help mitigate leaking authentication credentials via for instance a CRIME attack, authentication MUST NOT be attempted when a compression layer is active. Consequently, a server MUST either list the AUTHINFO capability with no arguments or not advertise it at all, in response to a CAPABILITIES command received from an unauthenticated client after a compression layer is active [...] Hmm... I think I should now do a pass on the document and explicitly say when "compression layer" only means the one negotiated with COMPRESS. As a matter of fact, I do not think it's a good idea to say in this draft that authentication MUST NOT be attempted when TLS-level compression is active! It would otherwise be a change in how authentication works (RFC 4643 heavily mentions the preferred use of AUTHINFO along with TLS, and RFC 4642 allows TLS-level compression). This document would otherwise be an update to RFC 4643, by no longer allowing AUTHINFO when TLS-level compression is active. >> When compression is active and either the client or the server >> receives invalid or corrupted compressed data, the receiving end >> SHOULD immediately close the connection. (Then the sending end will >> in turn do the same.) > > Well (and we're now down to nit level, so do as you think best here), > as I see it, it's not a question of level of constraint -- if it were, > you could say it without 2119 key words, as "the receiving end > immediately closes the connection, in response to which the sending > end will do the same." (Now that I think about it more, I think > that's the best answer, but if you disagree that's fine.) You're right. Your suggestion is also adopted. When compression is active and either the client or the server receives invalid or corrupted compressed data, the receiving end immediately closes the connection, in response to which the sending end will do the same. >> Additionally, implementations MAY ensure that the contents of two >> distinct confidential articles are not compressed together. > > As I say, maybe just drop the key word and say it without capitals. > If it's not easy to explain or determine, maybe just say that it's > good to do it if you can: > > NEW > Additionally, it is preferable not to compress the contents of two > distinct confidential articles together if it can be avoided. > END > > But, again, it's a small point that probably doesn't need further discussion. Thanks for your suggestion of wording. Also adopted! Additionally, it is preferable not to compress the contents of two distinct confidential articles together if it can be avoided, as adversaries might be able to derive information about them (for instance if they have a few header fields or body lines in common). This can be achieved for instance with DEFLATE by clearing the compression dictionary each time a confidential article is sent. More complex implementations are of course possible, and encouraged. >> In the registry, it is indeed best to use upper case. I can mention it. Now done, for IANA's benefit: Any name that conforms to the syntax of an NNTP compression algorithm name (Section 5.3) can be used. Especially, NNTP compression algorithms are named by strings, from 1 to 20 characters in length, consisting of upper-case letters, digits, hyphens, and/or underscores. >> Just to be certain of the meaning of your remark: the algorithm name >> in the NNTP command is not required to be upper case. >> >> algorithm = "DEFLATE" / 1*20alg-char >> alg-char = UPPER / DIGIT / "-" / "_" >> >> ABNF syntax is not case-sensitive, so "COmprESs dEFlaTe" is a valid >> NNTP command, that has the same effect as "COMPRESS DEFLATE". > > Actually, that's an ABNF error that I missed: "DEFLATE" doesn't have > to be in upper case, but any *other* algorithm does (because > "alg-char" can only contain UPPER, not ALPHA or LOWER). To fix that, > I suggest using this: > > algorithm = %s"DEFLATE" / 1*20alg-char > > ...and adding a normative reference to RFC 7405... that forces DEFLATE > to be upper case. Good catch. Also done. This section describes the formal syntax of the COMPRESS extension using ABNF [RFC7405] [RFC5234]. [...] algorithm = %s"DEFLATE" / 1*20alg-char ; case-sensitive alg-char = UPPER / DIGIT / "-" / "_" > Unless, of course, you really want to allow case-insensitivity here. Case-sensitivity is better, and we'll keep that. It is also coherent with SASL mechanisms (case-sensitive), and consistent with RFC 3977: Section 3.1 Commands in NNTP MUST consist of a keyword, which MAY be followed by one or more arguments. [...] Commands may have variants; if so, they use a second keyword immediately after the first to indicate which variant is required. The only such commands in this specification are LIST and MODE. [...] Keywords are case insensitive; the case of keywords for commands MUST be ignored by the server. Command and response arguments are case or language specific only when stated, either in this document or in other relevant specifications. In the case of COMPRESS: - the command (COMPRESS) is case insensitive (like any keyword), - the command has an argument (e.g., DEFLATE), that is not a keyword, and therefore can be said to be case-sensitive. > Considering what you say in your response after that, let me suggest > an alternative: > > NEW > If the server advertises a registered NNTP compression algorithm, it > MUST implement the compression algorithm so as to fully conform with > its related specification. If it does not implement the compression > algorithm as specified, the implementation is considered a private > algorithm and MUST NOT be listed with the registered name in the > arguments list of the COMPRESS capability label. > > Private algorithms with unregistered names are allowed, but SHOULD > NOT be used because it is difficult to achieve interoperability with them. > END > > How's that? All right. I kept your second paragraph. I removed the first one because on second thoughts, we don't really need saying it. As Alexey commented in his review, "this sounds like motherhood and apple pie". Thanks again, and have a nice week, -- Julien ÉLIE « – Tu parles ? – Tu parles ! » (Astérix) From nobody Mon Oct 24 04:20:18 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEC65129567; Mon, 24 Oct 2016 04:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=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 qwvlb_fyrU-y; Mon, 24 Oct 2016 04:20:12 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 054B512965F; Mon, 24 Oct 2016 04:20:11 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u9OBK7fV008280 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 24 Oct 2016 14:20:07 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u9OBK68l024657; Mon, 24 Oct 2016 14:20:06 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22541.61030.850799.444550@fireball.acr.fi> Date: Mon, 24 Oct 2016 14:20:06 +0300 From: Tero Kivinen To: In-Reply-To: <919689005.2218143.1476810193309@mail.yahoo.com> References: <22495.62038.771947.984586@fireball.acr.fi> <1264225155.363685.1474644268281@mail.yahoo.com> <22507.60901.665544.878052@fireball.acr.fi> <1130739157.4563724.1475509147203@mail.yahoo.com> <22523.36827.869306.70163@fireball.acr.fi> <919689005.2218143.1476810193309@mail.yahoo.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: Cc: "iesg@ietf.org" , "draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-05: Implementation Considerations X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 11:20:14 -0000 nalini.elkins@insidethestack.com writes: > Continuing the taking of issues 1 by 1. > The discussion around Implementation Considerations boils down to two issues: > > 1. Default value of PDM should be OFF > > 2. It should not be possible to turn on PDM merely by receiving a > packet with PDM in it. > > Current words: > > "3.5 Implementation Considerations > > The PDM destination options extension header SHOULD be turned on by > each stack on a host node. It MAY also be turned on only in case of > diagnostics needed for problem resolution." > > > Suggested changes: > > > "3.5 Implementation Considerations > > The PDM destination options extension header MUST be explicitly > turned on by each stack on a host node by administrative action. The > default value of PDM is off. > > PDM MUST NOT be turned on merely if a packet is received with a PDM > header. The received packet could be spoofed by another device." That text looks good. -- kivinen@iki.fi From nobody Mon Oct 24 04:36:31 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8778129699; Mon, 24 Oct 2016 04:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=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 ISTrGrzqBbta; Mon, 24 Oct 2016 04:36:29 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0CC8129698; Mon, 24 Oct 2016 04:36:28 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u9OBaQxR005577 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 24 Oct 2016 14:36:26 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u9OBaQ00029234; Mon, 24 Oct 2016 14:36:26 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22541.62010.241184.539109@fireball.acr.fi> Date: Mon, 24 Oct 2016 14:36:26 +0300 From: Tero Kivinen To: In-Reply-To: <1103626655.678358.1476999979368@mail.yahoo.com> References: <22495.62038.771947.984586@fireball.acr.fi> <1264225155.363685.1474644268281@mail.yahoo.com> <22507.60901.665544.878052@fireball.acr.fi> <1130739157.4563724.1475509147203@mail.yahoo.com> <22523.36827.869306.70163@fireball.acr.fi> <1103626655.678358.1476999979368@mail.yahoo.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 6 min Archived-At: Cc: "iesg@ietf.org" , "draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-05: Timing Attacks X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 11:36:29 -0000 nalini.elkins@insidethestack.com writes: > >Yes, timing attacks are possible against any crypto protocol. If the > >protocol and algorithms used in the protocol are specifically written > >so that they are protected against timing attacks, they will not work, > >but lots of the implementations and protocols care more about the > >speed, than for the timing attacks, especially as launching them over > >longer distance gets harder and harder as other things add random > >times to measurements. > > >If this allows easy way to get exact timing information from the node > >without any issues from the network latencies and so on, this might > >open completely new ways to attack implementations and protocols. > >Those attacks were not feasible before, but now they might be. > > > > Add to Section 8: > > 8.4 Timing Attacks > > The fact that PDM can help in the separation of node processing time > from network latency brings value to performance monitoring. Yet, > it is this very characteristic of PDM which may be misused to make > certain new type of timing attacks against protocols and > implementations possible. Having said that, PDM is more likely to > be used in response to an attack to find whether there are problems > in the network or the node rather than its temporary use being > exploited to mount an attack. The normal use of PDM is likely to be > for testing and diagnostics. So, this is a short-term opportunity > for an attacker. > > Even so, if using PDM, we introduce the concept of user "Consent to > be Measured" as a pre-requisite for using PDM. Consent is common in > enterprises and with some subscription services. So, if with PDM, we > recommend that the user SHOULD consent to its use. I think this text might need bit more text about the attacks. I.e. the nature of these attacks is that they can leak out the long term credentials of the device. So if attacker is able to make attack, which causes the enterprice to turn on PDM to diagnose the attack, then the attacker might use PDM during that debugging time to do timing attack against the long term keying material used by the crypto protocol. Immediately when they get the keying material out, they stop the actual attack, which might then cause the defender to think that nothing bad happend, and just disable PDM and go on, without realizing that their long term keying material got stolen during the attack, and that the visible attack was there only to cause them to turn on PDM... -- kivinen@iki.fi From nobody Mon Oct 24 05:49:42 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D08A1296AE for ; Mon, 24 Oct 2016 05:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 yml-9x2Sqzf1 for ; Mon, 24 Oct 2016 05:49:32 -0700 (PDT) Received: from nm7-vm3.bullet.mail.ne1.yahoo.com (nm7-vm3.bullet.mail.ne1.yahoo.com [98.138.91.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 143E51296B8 for ; Mon, 24 Oct 2016 05:49:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1477313370; bh=v69KkD8q9oY6CFtRS/7sfL4zpatLPSkTRYY8LCvPjto=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=lBYlUGbm/lnI8p/2r4ARvu7rTx1qhvjz2EN/Ez+v5F36h9TjwH6k/uf0n8ojiUB2JBTrlD+arUQCQ3oYrhlF2deria2WlC4gctsorSEBLC33NNShZHCJMyNvbMN+dYx9v+Pqc9IK+R8j5s5+b9UP9cBTmj0nG2SZDhWoe2jKicfsclD36bO0wGoDdaLK2hKUP0+/BCgyaaT8L4QtCFbDPtsDnNOjFMTX/YBoBuo7Ynla4Cnrb1IbutJYcANakjkSZYFjSylsat+Ema+jZDqFJYdXk7Klc/VoeVtEdOZSmXAPHuTNrX9YXbnlJKJzXkuoZ4Zdx1sLHlMoM9dFplxUhg== Received: from [98.138.226.176] by nm7.bullet.mail.ne1.yahoo.com with NNFMP; 24 Oct 2016 12:49:30 -0000 Received: from [98.138.226.166] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 24 Oct 2016 12:49:30 -0000 Received: from [127.0.0.1] by omp1067.mail.ne1.yahoo.com with NNFMP; 24 Oct 2016 12:49:30 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 299207.60026.bm@omp1067.mail.ne1.yahoo.com X-YMail-OSG: uDP.VUwVM1lUSYNzcXGk9JViWtKgKueMlkX3o4jXaJ1UHCjlfqwdGUU2GCOZZcy TE8LI8dl2ulq_eIElzjcHwn5nFTqkK0q6tS8__YSI8q6EjiLINO.LfbI2FkN3EHwZhP5kf_oJ.AT yrIoc8s_2F79ruZJXzsgwcPWjARepziFAKasvviny7bXZFNvvGP.edce7nywmVLHrrJAdBTJxrmx GwZYiTCCkNcWs9T.p5g.BXP.9CqQ4bSqAc4bw9hNAmqKamjajLh1KuqLzEk2qEEZ2hmdwEzOSoWK dAnzEOgmJkhgD8UEjj.l_Ow1gkSrDw.OMKGLtGt2GHWSwD0pdCgcKI5eyf9l08xrVCwx5GP0A_mq 61MkiWPuKU5rCaeiwO80KGLRUSI28nwFM2KMVDaM5JPN0WVTSH9oXOPqXBXNWTae8TPmlQnMAu67 kHGvauC1N9BqU2Zhub9nM464DUFLeBlbe65xNBIy7Ur0cF2mE0vtvfKyVgHdlYAqtULR9j2w9TGe H9bblp7swcOWTs8.Qg7dFt7kWNGuf3I2m7rDPMYwy Received: from jws200040.mail.ne1.yahoo.com by sendmailws148.mail.ne1.yahoo.com; Mon, 24 Oct 2016 12:49:29 +0000; 1477313369.878 Date: Mon, 24 Oct 2016 12:49:29 +0000 (UTC) From: To: Tero Kivinen Message-ID: <1008310054.1014499.1477313369458@mail.yahoo.com> In-Reply-To: <22541.62010.241184.539109@fireball.acr.fi> References: <22495.62038.771947.984586@fireball.acr.fi> <1264225155.363685.1474644268281@mail.yahoo.com> <22507.60901.665544.878052@fireball.acr.fi> <1130739157.4563724.1475509147203@mail.yahoo.com> <22523.36827.869306.70163@fireball.acr.fi> <1103626655.678358.1476999979368@mail.yahoo.com> <22541.62010.241184.539109@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "iesg@ietf.org" , "draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-05: Timing Attacks X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 12:49:36 -0000 Tero, From: Tero Kivinen nalini.elkins@insidethestack.com writes: > >Yes, timing attacks are possible against any crypto protocol. If the > >protocol and algorithms used in the protocol are specifically written > >so that they are protected against timing attacks, they will not work, > >but lots of the implementations and protocols care more about the > >speed, than for the timing attacks, especially as launching them over > >longer distance gets harder and harder as other things add random > >times to measurements. > > >If this allows easy way to get exact timing information from the node > >without any issues from the network latencies and so on, this might > >open completely new ways to attack implementations and protocols. > >Those attacks were not feasible before, but now they might be. > > > > Add to Section 8: > > 8.4 Timing Attacks > > The fact that PDM can help in the separation of node processing time > from network latency brings value to performance monitoring. Yet, > it is this very characteristic of PDM which may be misused to make > certain new type of timing attacks against protocols and > implementations possible. Having said that, PDM is more likely to > be used in response to an attack to find whether there are problems > in the network or the node rather than its temporary use being > exploited to mount an attack. The normal use of PDM is likely to be > for testing and diagnostics. So, this is a short-term opportunity > for an attacker. > > Even so, if using PDM, we introduce the concept of user "Consent to > be Measured" as a pre-requisite for using PDM. Consent is common in > enterprises and with some subscription services. So, if with PDM, we > recommend that the user SHOULD consent to its use. [Tero's comments below] >I think this text might need bit more text about the attacks. I.e. the >nature of these attacks is that they can leak out the long term >credentials of the device. So if attacker is able to make attack, >which causes the enterprice to turn on PDM to diagnose the attack, >then the attacker might use PDM during that debugging time to do >timing attack against the long term keying material used by the crypto >protocol. Immediately when they get the keying material out, they stop >the actual attack, which might then cause the defender to think that >nothing bad happend, and just disable PDM and go on, without realizing >that their long term keying material got stolen during the attack, and >that the visible attack was there only to cause them to turn on PDM... Tero, I am a bit reluctant to be completely specific as I think that will give people ideas that they might not have had before. That is, before I say it, few people might think to launch such attacks but if I spell it out clearly that such attacks can be launched, then people who might not even have thought that this was possible, will now think that they can do it. Let me think a bit about how to phrase this. Nalini From nobody Mon Oct 24 11:45:01 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B79A9127076; Mon, 24 Oct 2016 11:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.651 X-Spam-Level: X-Spam-Status: No, score=-4.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 RbmQN4IgzxSk; Mon, 24 Oct 2016 11:44:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E952A1294E2; Mon, 24 Oct 2016 11:44:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CYY16901; Mon, 24 Oct 2016 18:44:52 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 24 Oct 2016 19:44:51 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.86]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0235.001; Tue, 25 Oct 2016 02:44:43 +0800 From: "Xialiang (Frank)" To: "draft-ietf-stir-rfc4474bis.all@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-stir-rfc4474bis-14 Thread-Index: AdIuJqzqa24rxCLVS2WDDiesiKtk9w== Date: Mon, 24 Oct 2016 18:44:42 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.201.117.67] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12B0220CCSZXEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.580E56A5.00C2, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.86, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 55e684ed2dc6a72131ec68ddb763bcfa Archived-At: Cc: "iesg@ietf.org" , "secdir@ietf.org" Subject: [secdir] Secdir review of draft-ietf-stir-rfc4474bis-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 18:45:00 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F12B0220CCSZXEMA502MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document defines a mechanism for securely identifying originators of S= IP requests. It does so by defining a SIP header field for conveying a sign= ature used for validating the identity, and for conveying a reference to th= e credentials of the signer. In general, this draft is the update of previous RFC4474 with some improvem= ents like: better support of telephone numbers as identifiers, reducing the= material scope of the Identity signature to those not changed by the inter= mediaries, replacing previous signed-identity-digest format with PASSporT (= signing algorithms now defined in a separate specification) and so on. This= draft already includes a very comprehensive and detailed consideration abo= ut privacy and security threats, I have no more security issues in addition= to them. Summary: this document appears in reasonably good shape, and is written wel= l. I think it is ready. Thanks! B.R. Frank --_000_C02846B1344F344EB4FAA6FA7AF481F12B0220CCSZXEMA502MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I have reviewed this document a= s part of the security directorate's ongoing effort to review all IETF docu= ments being processed by the IESG.  These comments were written primar= ily for the benefit of the security area directors.  Document editors and WG chairs should treat these comment= s just like any other last call comments.

 

 

This document defines a mechani= sm for securely identifying originators of SIP requests. It does so by defi= ning a SIP header field for conveying a signature used for validating the i= dentity, and for conveying a reference to the credentials of the signer.

 

 

In general, this draft is the u= pdate of previous RFC4474 with some improvements like: better support of te= lephone numbers as identifiers, reducing the material scope of the Identity= signature to those not changed by the intermediaries, replacing previous signed-identity-digest format with PASS= porT (signing algorithms now defined in a separate specification) and so on= . This draft already includes a very comprehensive and detailed considerati= on about privacy and security threats, I have no more security issues in addition to them.

 

 

Summary: this document appears = in reasonably good shape, and is written well. I think it is ready.

 

 

Thanks!

 

B.R.

Frank

 

--_000_C02846B1344F344EB4FAA6FA7AF481F12B0220CCSZXEMA502MBSchi_-- From nobody Mon Oct 24 12:26:14 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65FB112959C for ; Mon, 24 Oct 2016 12:26:12 -0700 (PDT) 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, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=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 IU78uLZfPpPe for ; Mon, 24 Oct 2016 12:26:11 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7035B12959B for ; Mon, 24 Oct 2016 12:26:11 -0700 (PDT) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id u9OJOtKw010661; Mon, 24 Oct 2016 15:26:09 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049463.ppops.net-00191d01. with ESMTP id 269r279uh3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Oct 2016 15:26:08 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u9OJQ7Dw026370; Mon, 24 Oct 2016 15:26:07 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u9OJQ1oe026280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 24 Oct 2016 15:26:04 -0400 Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (GAALPA1MSGHUBAA.itservices.sbc.com [130.8.218.150]) by alpi133.aldc.att.com (RSA Interceptor); Mon, 24 Oct 2016 19:25:49 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.216]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0319.002; Mon, 24 Oct 2016 15:25:49 -0400 From: "STARK, BARBARA H" To: Yaron Sheffer , IETF Security Directorate , "draft-bbf-bbf-urn.all@tools.ietf.org" Thread-Topic: SecDir review of draft-bbf-bbf-urn-02 Thread-Index: AQHSJguax3h44Iqp3EKwA+fzNOVabqC4Chdg Date: Mon, 24 Oct 2016 19:25:48 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DA25564@GAALPA1MSGUSRBF.ITServices.sbc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.81.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-24_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610240337 Archived-At: Subject: Re: [secdir] SecDir review of draft-bbf-bbf-urn-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 19:26:12 -0000 PiBUbyBwcmV2ZW50ICJVUk4gc3F1YXR0aW5nIiwgSSB3b3VsZCByZWNvbW1lbmQgdG8gaW5jbHVk ZSBhbiBleHBsYW5hdGlvbg0KPiB3aHkgYSBuYW1lIHRoYXQncyBub3QgdHJpdmlhbGx5IGFzc29j aWF0ZWQgd2l0aCAiQnJvYWRiYW5kIEZvcnVtIiBpcyBjbGFpbWVkDQo+IGhlcmUsIG5hbWVseSAi ZHNsZm9ydW0tb3JnIi4gQWx0aG91Z2ggMiBtaW51dGVzIG9mIHJlc2VhcmNoIHN1ZmZpY2UgdG8g ZmluZA0KPiB0aGUgYW5zd2VyLg0KDQpUaGFua3MgZm9yIHRoZSBjb21tZW50LiBBbmQgc29ycnkg Zm9yIHRoZSBkZWxheWVkIHJlc3BvbnNlLiBUbyBhZGRyZXNzIHRoaXMgY29tbWVudC4gSSBwcm9w b3NlIGFkZGluZyB0aGUgZm9sbG93aW5nIHRlc3QgYXQgdGhlIGVuZCBvZiB0aGUgaW50cm9kdWN0 aW9uOg0KIkJCRiBoYXMgdXNlZCB0aGVzZSBsYXR0ZXIgdHdvIE5JRHMgZm9yIG1hbnkgeWVhcnMg d2l0aG91dCBmb3JtYWxseSByZWdpc3RlcmluZyB0aGVtIGFuZCBoYXMgcHVibGlzaGVkIHdpZGVs eS1pbXBsZW1lbnRlZCBzcGVjaWZpY2F0aW9ucyB0aGF0IHVzZSB0aGVzZSBOSURzLiBVc2Ugb2Yg dGhlICdkc2xmb3J1bS1vcmcnIE5JRCBzdGFydGVkIHByaW9yIHRoZSBvcmdhbml6YXRpb24ncyAy MDA4IG5hbWUgY2hhbmdlIGZyb20gRFNMIEZvcnVtIHRvIEJyb2FkYmFuZCBGb3J1bS4gIg0KDQpG cm9tOg0KICAgVGhlICdiYmYnIE5JRCBpcyBmb3IgbmV3IHdvcmsgZWZmb3J0cyByZWxhdGVkIHRv IGRhdGEgbW9kZWxzIGZvcg0KICAgcHJvdG9jb2xzIG90aGVyIHRoYW4gaXRzIENQRSBXQU4gTWFu YWdlbWVudCBQcm90b2NvbCAoQ1dNUCkgW1RSLTA2OV0uDQogICBUaGUgJ2Jyb2FkYmFuZC1mb3J1 bS1vcmcnIGFuZCAnZHNsZm9ydW0tb3JnJyBOSURzIGFyZSB1c2VkIGZvciBhbGwNCiAgIGRhdGEg bW9kZWxzIHJlbGF0ZWQgdG8gQ1dNUCBbVFItMDY5XS4NCg0KVG86DQogICBUaGUgJ2JiZicgTklE IGlzIGZvciBuZXcgd29yayBlZmZvcnRzIHJlbGF0ZWQgdG8gZGF0YSBtb2RlbHMgZm9yDQogICBw cm90b2NvbHMgb3RoZXIgdGhhbiBpdHMgQ1BFIFdBTiBNYW5hZ2VtZW50IFByb3RvY29sIChDV01Q KSBbVFItMDY5XS4NCiAgIFRoZSAnYnJvYWRiYW5kLWZvcnVtLW9yZycgYW5kICdkc2xmb3J1bS1v cmcnIE5JRHMgYXJlIHVzZWQgZm9yIGFsbA0KICAgZGF0YSBtb2RlbHMgcmVsYXRlZCB0byBDV01Q IFtUUi0wNjldLiBCQkYgaGFzIHVzZWQgdGhlc2UgbGF0dGVyIHR3byBOSURzIA0KICAgZm9yIG1h bnkgeWVhcnMgd2l0aG91dCBmb3JtYWxseSByZWdpc3RlcmluZyB0aGVtIGFuZCBoYXMgcHVibGlz aGVkIHdpZGVseS0NCiAgIGltcGxlbWVudGVkIHNwZWNpZmljYXRpb25zIHRoYXQgdXNlIHRoZXNl IE5JRHMuIFVzZSBvZiB0aGUgJ2RzbGZvcnVtLW9yZycgDQogICBOSUQgc3RhcnRlZCBwcmlvciB0 aGUgb3JnYW5pemF0aW9uJ3MgMjAwOCBuYW1lIGNoYW5nZSBmcm9tIERTTCBGb3J1bSB0byANCiAg IEJyb2FkYmFuZCBGb3J1bS4gIA0KDQpBbmQgYWRkaXRpb25hbCBtZW50aW9uIHVuZGVyIE5hbWVz cGFjZSBDb25zaWRlcmF0aW9ucyB0byBhZGRyZXNzIEpvZWwncyBjb21tZW50cy4gQXQgZW5kIG9m IE5hbWVzcGFjZSBDb25zaWRlcmF0aW9ucywgSSBwcm9wb3NlIGFkZGluZzoNCg0KICAgVGhyZWUg TklEcyBhcmUgZGVmaW5lZC4gVGhlICJicm9hZGJhbmQtZm9ydW0tb3JnIiBhbmQgImRzbGZvcnVt LW9yZyIgDQogICAoQnJvYWRiYW5kIEZvcnVtIGNoYW5nZWQgaXRzIG5hbWUgZnJvbSBEU0wgRm9y dW0gaW4gMjAwOCkgTklEcyBoYXZlIA0KICAgYmVlbiB1c2VkIGZvciBtYW55IHllYXJzIGJ5IEJC RiB3aXRob3V0IGZvcm1hbCByZWdpc3RyYXRpb24uIEFzIHRoZXkgYXJlIA0KICAgcmVmZXJlbmNl ZCBieSBtdWx0aXBsZSBCQkYgc3BlY2lmaWNhdGlvbnMgY3VycmVudGx5IGluIGNvbW1vbiB1c2Us IEJCRiB0aG91Z2h0IA0KICAgaXQgYmVzdCB0byBmb3JtYWxpemUgdGhlbS4gVGhlIG5ldyAiYmJm IiBOSUQgd2lsbCBiZSB1c2VkIGZvciBuZXcgd29yayBlZmZvcnRzLg0KDQpCYXJiYXJhDQo= From nobody Mon Oct 24 13:10:22 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0725D129614 for ; Mon, 24 Oct 2016 13:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=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 vjrk8795cN6D for ; Mon, 24 Oct 2016 13:10:19 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr [80.12.242.126]) by ietfa.amsl.com (Postfix) with ESMTP id D4516128E18 for ; Mon, 24 Oct 2016 13:10:18 -0700 (PDT) Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d08 with ME id zY2m1t00317Lgi403Y2mGH; Mon, 24 Oct 2016 22:02:47 +0200 X-ME-Helo: macbook-pro-de-julien-elie.home X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg== X-ME-Date: Mon, 24 Oct 2016 22:02:47 +0200 X-ME-IP: 92.170.5.52 To: Barry Leiba References: <20981db3190142193043f1445abadaa3@trigofacile.com> <1b5edd03-675c-01b7-6d06-c2e155987929@trigofacile.com> From: =?UTF-8?Q?Julien_=c3=89LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ Message-ID: <627dc143-362b-4ac9-299c-11007bc973ae@trigofacile.com> Date: Mon, 24 Oct 2016 22:02:46 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-murchison-nntp-compress.all@ietf.org, IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-murchison-nntp-compress-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 20:10:20 -0000 Hi Barry, > I've been thinking on this since you mentioned it, and I have mixed > feelings. So let me spread them out here: [...] > And on the third hand (I'm Martian) > On the fourth hand (and that's all that Martians have) I like these two introductions of alternatives :) > So, yes: in the end, I think it's worth putting in a few words about > this, just to be clear that it's a common trap. OK. FYI, I've added the following paragraph at the end of the Security Considerations Section. The wording is inspired by the one in RFC 3749. Last but not least, careful consideration should be given to protections against implementation errors that introduce security risks with regards to compression algorithms. See for instance the part of Section 6 of [RFC3749] about compression algorithms that can occasionally expand, rather than compress, input data. -- Julien ÉLIE « Aut bibas aut abeas. » From nobody Mon Oct 24 13:28:21 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49BD712999B for ; Mon, 24 Oct 2016 13:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=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 7a_pzuF37Zsl for ; Mon, 24 Oct 2016 13:28:19 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr [80.12.242.126]) by ietfa.amsl.com (Postfix) with ESMTP id B01E0129861 for ; Mon, 24 Oct 2016 13:28:18 -0700 (PDT) Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d08 with ME id zYLm1t00C17Lgi403YLmzs; Mon, 24 Oct 2016 22:20:48 +0200 X-ME-Helo: macbook-pro-de-julien-elie.home X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg== X-ME-Date: Mon, 24 Oct 2016 22:20:48 +0200 X-ME-IP: 92.170.5.52 To: Barry Leiba , draft-murchison-nntp-compress.all@ietf.org, =?UTF-8?Q?Michael_B=c3=a4uerle?= References: <20981db3190142193043f1445abadaa3@trigofacile.com> From: =?UTF-8?Q?Julien_=c3=89LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ Message-ID: <10b4998e-67ae-abdf-c1f0-321c28bcb4fe@trigofacile.com> Date: Mon, 24 Oct 2016 22:20:46 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-murchison-nntp-compress-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 20:28:20 -0000 Hi Barry, Thanks again for your valuable comments on the document. They were very much appreciated, and permitted to fix a few issues. I've just finalized a revised draft, taking into account all the comments received during Last Call. I just want to highlight the following change in wording. Ken and Michael, as respectively co-author and document shepherd, please tell if you think the new wording is not the right thing to do. Personally, I think this document (draft-murchison-nntp-compress) should only focus on standardizing the COMPRESS command and not try to fix how authentication works in another kind of compression (TLS-level compression). It would otherwise be an update to RFC 4643. Updating TLS usage with NNTP is the aim of a second, separate document (draft-elie-nntp-tls-recommendations) that updates RFC 4643 with best current practices. That one discourages the use of TLS-level compression, thus dealing with authentication layered with a TLS-level compression method. >> In order to help mitigate leaking authentication credentials via for >> instance a CRIME attack [CRIME], authentication SHOULD NOT be >> attempted when a compression layer is active. Consequently, a server >> SHOULD NOT return any arguments with the AUTHINFO capability label >> (or SHOULD NOT advertise it at all) in response to a CAPABILITIES >> command received from an unauthenticated client after a compression >> layer is active, and such a client SHOULD NOT attempt to utilize any >> AUTHINFO [RFC4643] commands. It implies that a server SHOULD reply >> with a 502 response code if a syntactically valid AUTHINFO command is >> received while a compression layer is already active. >> >> Why are these SHOULD, and not MUST? Under what conditions would it be >> necessary or reasonable for an implementation not to abide by these, >> and what considerations need to be considered when making that >> determination? (And this is also directly referred to in Section 6.) [...] > OK. I've adopted your suggestion. [...] > Hmm... I think I should now do a pass on the document and explicitly > say when "compression layer" only means the one negotiated with COMPRESS. > As a matter of fact, I do not think it's a good idea to say in this > draft that authentication MUST NOT be attempted when TLS-level > compression is active! It would otherwise be a change in how > authentication works (RFC 4643 heavily mentions the preferred use of > AUTHINFO along with TLS, and RFC 4642 allows TLS-level compression). > This document would otherwise be an update to RFC 4643, by no longer > allowing AUTHINFO when TLS-level compression is active. Pass done. I updated the wording in a few parts of the document. The above quoted paragraph becomes: In order to help mitigate leaking authentication credentials via for instance a CRIME attack [CRIME], authentication MUST NOT be attempted after a successful use of the COMPRESS command. Consequently, a server MUST either list the AUTHINFO capability with no arguments or not advertise it at all, in response to a CAPABILITIES command received from an unauthenticated client after a successful use of the COMPRESS command, and such a client MUST NOT attempt to utilize any AUTHINFO [RFC4643] commands. It implies that a server MUST reply with a 502 response code if a syntactically valid AUTHINFO command is received after a successful use of the COMPRESS command. (Note that this specification does not change the behaviour of AUTHINFO as described in [RFC4643] independently of TLS-level compression. Authentication is therefore still allowed, even though TLS-level compression is active.) I hope you're all fine with that. Have a nice day, -- Julien ÉLIE « Aut bibas aut abeas. » From nobody Tue Oct 25 00:49:45 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF737129A6B; Tue, 25 Oct 2016 00:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.953 X-Spam-Level: X-Spam-Status: No, score=-14.953 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 foZ-SW4vXl_n; Tue, 25 Oct 2016 00:49:38 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B92F129501; Tue, 25 Oct 2016 00:49:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9366; q=dns/txt; s=iport; t=1477381778; x=1478591378; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=q50gftBW6yKXlqt1/Ma2p9Ln+dAl2cjQGfsLQQjOiiY=; b=dStJJchZH432RdPlFoUtDBZ2/lN9q/knm1BfpY5JitGPz+tH2JvQ7FNa z+OB+7YqxNlGPLMScAkmAYBqSOsVEJ92bTDYDEhNXKBejhLbs1Mi43MRd e/ZjwHwrBaXgdhV+xKOI7ysqbOaMIMcbMoTwvB9S1qLBcKcXJOW9OvynC 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALAQBTDQ9Y/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzABAQEBAXUDJ1ONNZZ9kjCCD4IHKYV4AoIxFAECAQEBAQEBAWI?= =?us-ascii?q?ohGIBAQEEOEEMBAsRBAEBJAQHRgkIBgEMBgIBAYhPDsFDAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBFwWGPYF9gliEGREBhXsBBI5KhW6FXoYqgwAGBoZdgW6EbYMXhhG?= =?us-ascii?q?HGYIag1WEAR42UAYIgxkXGIE8PDQBhTmCIAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,545,1473120000"; d="scan'208";a="689175833" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Oct 2016 07:49:35 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u9P7nZCm008890; Tue, 25 Oct 2016 07:49:35 GMT To: stephane.litkowski@orange.com, Hilarie Orman , "iesg@ietf.org" , "secdir@ietf.org" References: <201610101904.u9AJ4dgA000607@rumpleteazer.rhmr.com> <15009_1476970082_5808C662_15009_624_1_9E32478DFA9976438E7A22F69B08FF921DB26F21@OPEXCLILMA4.corporate.adroot.infra.ftgroup> From: Benoit Claise Message-ID: <39b321e5-2f14-e8d0-7a8a-547947574fdc@cisco.com> Date: Tue, 25 Oct 2016 09:49:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <15009_1476970082_5808C662_15009_624_1_9E32478DFA9976438E7A22F69B08FF921DB26F21@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-l3sm-l3vpn-service-model.all@tools.ietf.org" Subject: Re: [secdir] Security review of draft-ietf-l3sm-l3vpn-service-model-16 YANG Data Model for L3VPN service delivery X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 07:49:44 -0000 Dear all, A new version has been posted. The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-l3sm-l3vpn-service-model/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=draft-ietf-l3sm-l3vpn-service-model-18 Regards, Benoit > Hi, > > Please find some comments inline > > Thanks > > -----Original Message----- > From: Hilarie Orman [mailto:hilarie@purplestreak.com] > Sent: Monday, October 10, 2016 21:05 > To: iesg@ietf.org; secdir@ietf.org > Cc: draft-ietf-l3sm-l3vpn-service-model.all@tools.ietf.org > Subject: Security review of draft-ietf-l3sm-l3vpn-service-model-16 YANG Data Model for L3VPN service delivery > > [Including subject line on resend] > > Security review of YANG Data Model for L3VPN service delivery > draft-ietf-l3sm-l3vpn-service-model-16 > > Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. > > The document uses the YANG data model to describe an abstracted view of Layer 3 Provider Provisioned VPN services. > > The model has specific support for describing authentication and encryption requirements. Perhaps I'm not imaginative enough to understand how they would be used, but my impression is that the models are incomplete. > > grouping site-security-authentication { > container authentication { > description > "Authentication parameters"; > } > description > "This grouping defines authentication > parameters > for a site"; > } > > > > > In the data model shown above for "authentication", I'm not sure who the parties in the authentication are and where enforcement takes place. This may be evident to those who are more familiar with VPN provisioning. If so, some additional description would be helpful. > > [SLI] We are not defining any authentication mechanism in the model. The container is just there to allow easy augmentation. This is stated in section 5.9.1. > > > > grouping site-security-encryption { > container encryption { > if-feature encryption; > leaf enabled { > type boolean; > description > "If true, access encryption is required."; > } > leaf layer { > type enumeration { > enum layer2 { > description > "Encryption will occur at layer2."; > } > enum layer3 { > description > "IPSec is requested."; > } > > Is IPSec the only layer 3 encryption method that is supported? > [SLI] I think the description is bad, it can be any layer 3 encryption mechanism, IPSec is one. > > } > description > "Layer on which encryption is applied."; > } > container encryption-profile { > choice profile { > case provider-profile { > leaf profile-name { > type string; > description > "Name of the SP profile > to be applied."; > > The "SP profile" is something defined by the service provider. All the parameters and their interpretations are defined in some out-of-band way by the service provider. This seems to impose a great deal of difficulty for the customer. > [SLI] Yes there is a need of out of band discussion. Operator is allowing customer to use a set of profiles. It's not really difficult as today, most of the SPs works this way with customers. > > Should the provider arbitrarily change the definition, the customer's configuration parameters might be dangerously misinterpreted. > [SLI] We usually do not change the definition of the profile because it is linked to a particular service selled to a customer. We can change parameters that does not affect the service. > > Or, a customer trying to move to a different service provider might see a similar profile and try to use the same parameters. Subtle differences in interpretation could lead to a security vulnerability. > > } > } > case customer-profile { > leaf algorithm { > type string; > description > "Encryption algorithm to > be used."; > } > choice key-type { > case psk { > leaf preshared-key { > type string; > description > "Key coming from > customer."; > > How does the customer submit the key? Should there be a key identifier? Perhaps the customer and the provider have a public key communication channel and the customer encrypts the keys and sends them to the provider, identifying them through the key identifiers? > Is there a key update procedure? > [SLI] The only supported method here is to submit the key through the RESTCONF or NETCONF over a secured channel. > > } > } > case pki { > > } > description > "Type of keys to be used."; > > Is "type of keys" supposed to imply the algorithm for key derivation? > [SLI] The model does not support PKI, container is there just for augmentation. This is not highlighted , I can add it. > > } > } > description > "Choice of profile."; > } > description > "Profile of encryption to be applied."; > } > > I assume the profiles are the opaque "external identifiers"? > [SLI] Right. > > "5.14. External ID references > > The service model sometimes refers to external information through > identifiers. As an example, to order a cloud-access to a particular > Cloud Service Provider (CSP), the model uses an identifier to refer > to the targeted CSP. In case, a customer is using directly this > service model as an API (through REST or NETCONF for example) to > order a particular service, the service provider should provide a > list of authorized identifiers. In case of cloud-access, the service > provider will provide the identifiers associated of each available > CSP. The same applies to other identifiers like std-qos-profile, oam > profile-name, provider-profile for encryption ... > > How SP provides those identifiers meaning to the customer is out of > scope of this document." > > > If the request is spoofed or misunderstood in some way, then the encryption may be downgraded. How is the configuration protected? > > [SLI] I'm not sure it does really deal with this service model itself, it's more a global issue that the SP need to address. > > I think there should be a way to sign a model. There is an implied contract between the customer and the network owner, and the authenticity of the request seems paramount. > > An example of the very confusing typos that are sprinkled throughout the document: > "I want my current site-network-access to be not be connected on the > same PoP ..." > > Another confusing statement: > "1. Introduction > > This document defines a YANG data model for communication between > customers and network operators, and to provide input to automated > control and configuration applications. > " > > The introduction does not conform to the rules of English grammar. > I'm not entirely sure what it means. Perhaps > > " This document defines a YANG data model. The model defines elements > that can be used in communication protocols between customers and > network operators. Those elements can be used also as input to > automated control and configuration applications. " ?? > > The document is marred by running afoul of the two notoriously difficult aspects of English grammar: subject/verb agreement and articles. The errors are too numerous to mention. For the most part, the meaning of the afflicted sentences is clear, but not always. The document should not be published until the errors are corrected. > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > . > From nobody Tue Oct 25 02:23:11 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23C712962B; Tue, 25 Oct 2016 02:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=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 24mjBEDz2TkM; Tue, 25 Oct 2016 02:23:02 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B003A1295BC; Tue, 25 Oct 2016 02:23:00 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u9P9MrtZ003973 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 25 Oct 2016 12:22:53 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u9P9Mrqx019125; Tue, 25 Oct 2016 12:22:53 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22543.9325.442870.538686@fireball.acr.fi> Date: Tue, 25 Oct 2016 12:22:53 +0300 From: Tero Kivinen To: In-Reply-To: <1008310054.1014499.1477313369458@mail.yahoo.com> References: <22495.62038.771947.984586@fireball.acr.fi> <1264225155.363685.1474644268281@mail.yahoo.com> <22507.60901.665544.878052@fireball.acr.fi> <1130739157.4563724.1475509147203@mail.yahoo.com> <22523.36827.869306.70163@fireball.acr.fi> <1103626655.678358.1476999979368@mail.yahoo.com> <22541.62010.241184.539109@fireball.acr.fi> <1008310054.1014499.1477313369458@mail.yahoo.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 7 min X-Total-Time: 6 min Archived-At: Cc: "iesg@ietf.org" , "draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-05: Timing Attacks X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 09:23:04 -0000 nalini.elkins@insidethestack.com writes: > > 8.4 Timing Attacks > > > > The fact that PDM can help in the separation of node processing time > > from network latency brings value to performance monitoring. Yet, > > it is this very characteristic of PDM which may be misused to make > > certain new type of timing attacks against protocols and > > implementations possible. Having said that, PDM is more likely to > > be used in response to an attack to find whether there are problems > > in the network or the node rather than its temporary use being > > exploited to mount an attack. The normal use of PDM is likely to be > > for testing and diagnostics. So, this is a short-term opportunity > > for an attacker. > > > > Even so, if using PDM, we introduce the concept of user "Consent to > > be Measured" as a pre-requisite for using PDM. Consent is common in > > enterprises and with some subscription services. So, if with PDM, we > > recommend that the user SHOULD consent to its use. > > > [Tero's comments below] > >I think this text might need bit more text about the attacks. I.e. the > >nature of these attacks is that they can leak out the long term > >credentials of the device. So if attacker is able to make attack, > >which causes the enterprice to turn on PDM to diagnose the attack, > >then the attacker might use PDM during that debugging time to do > >timing attack against the long term keying material used by the crypto > >protocol. Immediately when they get the keying material out, they stop > >the actual attack, which might then cause the defender to think that > >nothing bad happend, and just disable PDM and go on, without realizing > >that their long term keying material got stolen during the attack, and > >that the visible attack was there only to cause them to turn on PDM... > > > > Tero, I am a bit reluctant to be completely specific as I think that > will give people ideas that they might not have had before. Security by obscurity never works. Attackers have much more time to think and plan about attacks than people who are implementing code for something unrelated. If you are too vague, people who are implementing PDM or the crypto protocols, thinks that those attacks are impossible. It is better to spell them out for those implementing those so they can make needed security measures for those. One of those security measures could for example be that PDM is enabled only for certain ip-addresses, or only for some ports. Another would be to enable it for certain timeperiod (for example for 1 hour), so it can be made sure that PDM is not accidently left on after debugging has been done etc. > That is, before I say it, few people might think to launch such > attacks but if I spell it out clearly that such attacks can be > launched, then people who might not even have thought that this was > possible, will now think that they can do it. I think it is better to explain the attacks properly to the PDM implementors, so they understand what kind of things they need to think about when implementing PDM. Same thing for the people implementing crypto protocols. They need to understand that with PDM some things that used to be hard will be easy. If you just give general warnings, that means that quite a lot of implementors think that this text is just general text, not really specific for this. So implementors might think it does not concern them, and ignore the issue. -- kivinen@iki.fi From nobody Tue Oct 25 05:05:10 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC9C129628; Tue, 25 Oct 2016 05:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.631 X-Spam-Level: X-Spam-Status: No, score=-4.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431] autolearn=unavailable autolearn_force=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 L_65DppaX1Fo; Tue, 25 Oct 2016 05:04:57 -0700 (PDT) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A832F1293D9; Tue, 25 Oct 2016 04:55:18 -0700 (PDT) Received: from [172.31.25.139] (VPN-172-31-25-139.VPN.CMU.LOCAL [172.31.25.139]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.15.2/8.15.1) with ESMTPSA id u9PBtFwk009917 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Oct 2016 07:55:15 -0400 To: =?UTF-8?Q?Julien_=c3=89LIE?= , Barry Leiba , "draft-murchison-nntp-compress.all@ietf.org" , =?UTF-8?Q?Michael_B=c3=a4uerle?= References: <20981db3190142193043f1445abadaa3@trigofacile.com> <10b4998e-67ae-abdf-c1f0-321c28bcb4fe@trigofacile.com> From: Ken Murchison Organization: Carnegie Mellon University Message-ID: <624bc524-d0d6-0b11-9af9-3d6fea66a0e5@andrew.cmu.edu> Date: Tue, 25 Oct 2016 07:55:15 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <10b4998e-67ae-abdf-c1f0-321c28bcb4fe@trigofacile.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-PMX-Version: 6.3.0.2556906, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.10.25.114817 X-SMTP-Spam-Clean: 8% ( MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, BODY_SIZE_4000_4999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, IN_REP_TO 0, LEGITIMATE_NEGATE 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, MULTIPLE_REAL_RCPTS 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, REFERENCES 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CC_NAME 0, __CC_NAME_DIFF_FROM_ACC 0, __CC_REAL_NAMES 0, __CP_NOT_1 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __MOZILLA_USER_AGENT 0, __MULTIPLE_RCPTS_CC_X2 0, __PHISH_SPEAR_STRUCTURE_1 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __USER_AGENT 0) X-SMTP-Spam-Score: 8% X-Scanned-By: MIMEDefang 2.78 on 128.2.105.203 Archived-At: Cc: IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-murchison-nntp-compress-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 12:04:58 -0000 I'm fine with the changes. On 10/24/2016 04:20 PM, Julien ÉLIE wrote: > Hi Barry, > > Thanks again for your valuable comments on the document. They were very > much appreciated, and permitted to fix a few issues. > > I've just finalized a revised draft, taking into account all the comments > received during Last Call. > I just want to highlight the following change in wording. > Ken and Michael, as respectively co-author and document shepherd, please > tell if you think the new wording is not the right thing to do. > > Personally, I think this document (draft-murchison-nntp-compress) should > only focus on standardizing the COMPRESS command and not try to fix > how authentication works in another kind of compression (TLS-level > compression). It would otherwise be an update to RFC 4643. > > Updating TLS usage with NNTP is the aim of a second, separate document > (draft-elie-nntp-tls-recommendations) that updates RFC 4643 with > best current practices. That one discourages the use of TLS-level > compression, thus dealing with authentication layered with a TLS-level > compression method. > > >>> In order to help mitigate leaking authentication credentials via for >>> instance a CRIME attack [CRIME], authentication SHOULD NOT be >>> attempted when a compression layer is active. Consequently, a server >>> SHOULD NOT return any arguments with the AUTHINFO capability label >>> (or SHOULD NOT advertise it at all) in response to a CAPABILITIES >>> command received from an unauthenticated client after a compression >>> layer is active, and such a client SHOULD NOT attempt to utilize any >>> AUTHINFO [RFC4643] commands. It implies that a server SHOULD reply >>> with a 502 response code if a syntactically valid AUTHINFO command is >>> received while a compression layer is already active. >>> >>> Why are these SHOULD, and not MUST? Under what conditions would it be >>> necessary or reasonable for an implementation not to abide by these, >>> and what considerations need to be considered when making that >>> determination? (And this is also directly referred to in Section 6.) > [...] >> OK. I've adopted your suggestion. > [...] >> Hmm... I think I should now do a pass on the document and explicitly >> say when "compression layer" only means the one negotiated with COMPRESS. >> As a matter of fact, I do not think it's a good idea to say in this >> draft that authentication MUST NOT be attempted when TLS-level >> compression is active! It would otherwise be a change in how >> authentication works (RFC 4643 heavily mentions the preferred use of >> AUTHINFO along with TLS, and RFC 4642 allows TLS-level compression). >> This document would otherwise be an update to RFC 4643, by no longer >> allowing AUTHINFO when TLS-level compression is active. > Pass done. I updated the wording in a few parts of the document. > The above quoted paragraph becomes: > > In order to help mitigate leaking authentication credentials via for > instance a CRIME attack [CRIME], authentication MUST NOT be attempted > after a successful use of the COMPRESS command. Consequently, a > server MUST either list the AUTHINFO capability with no arguments or > not advertise it at all, in response to a CAPABILITIES command > received from an unauthenticated client after a successful use of the > COMPRESS command, and such a client MUST NOT attempt to utilize any > AUTHINFO [RFC4643] commands. It implies that a server MUST reply > with a 502 response code if a syntactically valid AUTHINFO command is > received after a successful use of the COMPRESS command. (Note that > this specification does not change the behaviour of AUTHINFO as > described in [RFC4643] independently of TLS-level compression. > Authentication is therefore still allowed, even though TLS-level > compression is active.) > > > I hope you're all fine with that. > Have a nice day, > -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From nobody Tue Oct 25 07:01:42 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5155129541; Tue, 25 Oct 2016 07:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=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 KemcvfzphzJY; Tue, 25 Oct 2016 07:01:39 -0700 (PDT) Received: from out23-ams.mf.surf.net (out23-ams.mf.surf.net [145.0.1.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA10512966F; Tue, 25 Oct 2016 07:01:16 -0700 (PDT) Received: from mail.het.net.je (mail.het.net.je [192.87.110.20]) by outgoing1-ams.mf.surf.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id u9PE1EDk031617 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 25 Oct 2016 16:01:14 +0200 Received: from 52d95635.cm-11-1b.dynamic.ziggo.nl ([82.217.86.53] helo=[192.168.178.239]) by mail.het.net.je with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bz2HE-0004Df-Ns; Tue, 25 Oct 2016 16:00:28 +0200 From: Klaas Wierenga Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Message-Id: <50455A6C-3C51-408C-927C-26711D3B7370@wierenga.net> Date: Tue, 25 Oct 2016 16:01:13 +0200 To: The IESG , secdir@ietf.org, draft-ietf-stir-certificates.all@ietf.org X-Mailer: Apple Mail (2.3226) X-Antivirus: no malware found X-Bayes-Prob: 0.0001 (Score 0, tokens from: p-out:default, p:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.87.110.20; country=NL; latitude=52.3824; longitude=4.8995; http://maps.google.com/maps?q=52.3824,4.8995&z=6 X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default) X-Canit-Stats-ID: 0uRXO1ekQ - 92781f050718 - 20161025 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: Subject: [secdir] review of draft-ietf-stir-certificates-10.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 14:01:41 -0000 Hi, I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. draft-ietf-stir-certificates-10.txt describes the use of certificates to = assert authority over phone numbers.=20 The document is clear and I believe addresses the security concerns = surrounding the use of certificates in this context. I consider this = document: ready with nits I have a few questions though, probably to do with my lack of = understanding of the use case, so I hope you will indulge me: - pardon my ignorance, but would ENUM/E.146+DNSSEC be an alternative = too? It seems to me that DNS works better than lengthy certificate = chains=E2=80=A6. - section 5.2: doesn=E2=80=99t using 1 certificate with millions of = numbers defeat the purpose of this work? Could one of those million = numbers spoof another of those numbers? - section 10.2: "The requirement to consult OCSP in real time results in = a network round-trip time of day,=E2=80=9D I don=E2=80=99t understand that = sentence. Thanks, Klaas= From nobody Tue Oct 25 23:58:49 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC23312946E; Tue, 25 Oct 2016 23:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.951 X-Spam-Level: X-Spam-Status: No, score=-14.951 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 MfIu6HVYS110; Tue, 25 Oct 2016 23:58:40 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 388C7129A27; Tue, 25 Oct 2016 23:58:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21424; q=dns/txt; s=iport; t=1477465120; x=1478674720; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3FRkoRw/Y5Xr99UY4uarxM3eF+wqezPj1mWNncfNIiw=; b=ddYScS5Ocpct5943RmDYxLzkYK2WkAwCcZY0FcwM3laW9YEKDCft/KOa r4Dxu7RjmgDbd3MwYMUn6Lt7qD+hYEHYwrRTPP6fzIL9NN4NkmOq77Y9a aIK48fRS1Qw0U0sTPCLLz5KXemydA7fOCygdqCuKYa8Jy+QuB87im6zHj w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CwAQDiUhBY/5JdJa1bGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgyoBAQEBAR2BVQeNLqYnhRaCB4YiAhqBYD8UAQIBAQEBAQEBYiiEYwE?= =?us-ascii?q?BBCNWEAIBCD8DAgICMBQRAgQOBYhUsyuMcwEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RyGPYF9gliEIwFZgk4sgi8FlDiFXgGQF4FuhG2JKI0IhAABHjZegxMFHFYBe3K?= =?us-ascii?q?GLgEBJAeBAoEJAQEB?= X-IronPort-AV: E=Sophos;i="5.31,549,1473120000"; d="scan'208,217";a="340273343" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Oct 2016 06:58:39 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u9Q6wcqs030789 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Oct 2016 06:58:39 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 26 Oct 2016 02:58:38 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Wed, 26 Oct 2016 02:58:38 -0400 From: "Carlos Pignataro (cpignata)" To: Vincent Roca Thread-Topic: Secdir review of draft-ietf-mpls-rfc4379bis-07 Thread-Index: AQHSK3L7mLnNZERQ4Uy2pbturGUgUqC6mOiA Date: Wed, 26 Oct 2016 06:58:38 +0000 Message-ID: <59069EEB-D17D-4ECD-8AF6-507F9E6B3084@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.5.58] Content-Type: multipart/alternative; boundary="_000_59069EEBD17D4ECD8AF6507F9E6B3084ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-mpls-rfc4379bis.all@ietf.org" , IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-mpls-rfc4379bis-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 06:58:43 -0000 --_000_59069EEBD17D4ECD8AF6507F9E6B3084ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gVmluY2VudCwNCg0KDQpNYW55IHRoYW5rcyBmb3IgeW91ciByZXZpZXchIFBsZWFzZSBm aW5kIHNvbWUgcmVzcG9uc2VzIGlubGluZS4NCg0KT24gT2N0IDIxLCAyMDE2LCBhdCAxOjEzIEFN LCBWaW5jZW50IFJvY2EgPHZpbmNlbnQucm9jYUBpbnJpYS5mcjxtYWlsdG86dmluY2VudC5yb2Nh QGlucmlhLmZyPj4gd3JvdGU6DQoNCkhlbGxvLA0KDQpJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1 bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZeKAmXMgb25nb2luZw0KZWZm b3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJ RVNHLiBUaGVzZQ0KY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVm aXQgb2YgdGhlIHNlY3VyaXR5IGFyZWENCmRpcmVjdG9ycy4gIERvY3VtZW50IGVkaXRvcnMgYW5k IFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdA0KbGlrZSBhbnkgb3Ro ZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQpJTUhPLCB0aGUgZG9jdW1lbnQgaXMgUmVhZHkgd2l0 aCBpc3N1ZXMuDQoNCkkgaGF2ZSB0d28gbWFpbiBjb21tZW50czoNCg0KMS0gVGhpcyBkb2N1bWVu dCBoYXMgYW4gaW50ZXJlc3Rpbmcgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbi4gSG93 ZXZlciBpdA0KbGFja3Mgc29tZSBrZXkgaW5mb3JtYXRpb24uIEZpcnN0IG9mIGFsbCwgdGhlcmUg aXMgbm8gYXR0YWNrZXIgbW9kZWwuIElzIHRoZQ0KdGhyZWF0IGNvbWluZyBmcm9tIGNvcnJ1cHRl ZCBlcXVpcG1lbnQ/IERvIHdlIGFzc3VtZSB0aG9zZSBhdHRhY2tlcnMgaGF2ZSBmdWxsDQpjb250 cm9sIG92ZXIgdGhlIGVxdWlwbWVudCBhbmQgZmxvd3M/IEFyZSBhdHRhY2tlcnMgb24gcGF0aCBv ciBvZmYgcGF0aD8NCkNsYXJpZnlpbmcgdGhlc2UgcG9pbnRzIChpdCdzIG5vdCBhbiBleGhhdXN0 aXZlIGxpc3QpIHdvdWxkIGhlbHAgc3RydWN0dXJpbmcgdGhlDQpkaXNjdXNzaW9uIG9uIGEgY2Fz ZSBieSBjYXNlIGJhc2lzLg0KDQoNClRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9u IGNvdmVycyB0aGUgYXBwcm9hY2hlcyB0byBhdHRhY2tpbmcgTFNScyB1c2luZyBMU1AgUGluZy9U cmFjZXJvdXRlLiBUaGlzIGlzIGFuIGV4aGF1c3RpdmUgbGlzdCB3aGljaCBpbmNsdWRlcyBhY3Rp dmUgYW5kIHBhc3NpdmUgYXR0YWNrcy4gSXMgdGhlcmUgc29tZSBzcGVjaWZpYyBhdHRhY2sgeW91 IHNlZSB0aGF0IGlzIG5vdCBjb3ZlcmVkPw0KDQoNCjItIFNvbWV0aGluZyBlbHNlIHRvIGNsYXJp Znk6IEkgaGF2ZSB0aGUgZmVlbGluZyAoYWZ0ZXIgcXVpY2tseSBzZWFyY2hpbmcgaW50ZWdyaXR5 Lw0KYXV0aGVudGljYXRpb24vSE1BQy8uLi4ga2V5d29yZHMgaW4gdGhlIGRvYykgdGhhdCBpcyBu byBtZXNzYWdlIGludGVncml0eQ0Kbm9yIHNlbmRlciBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20g aW4gdGhlIGVjaG8gcmVxdWVzdC9yZXNwb25zZSBkZXRhaWxlZCBoZXJlLg0KDQpUaGF0IGlzIGNv cnJlY3QsIG5vIG1lc3NhZ2UgaW50ZWdyaXR5IG5vciBzZW5kZXIgYXV0aGVudGljYXRpb24gaW4g TFNQIFBpbmcuDQoNCklmIHRoZSBhdHRhY2tlciBtb2RlbCBhbHNvIGluY2x1ZGVzIGEgZnVsbCBj b250cm9sIG9mIExTUiwgbm90aGluZyBjYW4gYmUgZG9uZSB0bw0KcHJldmVudCBzb21lIGF0dGFj a3MuIFBsZWFzZSBjbGFyaWZ5Lg0KDQoNClNvcnJ5IGJ1dCBpZiBhbiBhdHRhY2tlciBoYXMgZnVs bCBjb250cm9sIG9mIGFuIExTUiwgc2hlIG9yIGhlIGlzIHByb2JhYmx5IHRvbyBidXN5IG9uIHNh aWQgTFNSIHRvIHNlbmQgTFNQIFBpbmdzIDotKQ0KDQoNCkFuZCBhIGZldyBhZGRpdGlvbmFsIG9u ZXM6DQoNCjMtIEZpcnN0IHNlbnRlbmNlIHNheXM6DQogICAiT3ZlcmFsbCwgdGhlIHNlY3VyaXR5 IG5lZWRzIGZvciBMU1AgcGluZyBhcmUgc2ltaWxhciB0byB0aG9zZSBvZiBJQ01QIHBpbmcuIg0K U3VjaCBkZWJ1Z2dpbmcgdG9vbHMgYXMgcGluZyBhbmQgdHJhY2Vyb3V0ZSAobm90IHNwZWFraW5n IG9mIE1QTFMgdmVyc2lvbiBoZXJlKQ0KaGF2ZSBhbiBlZmZpY2llbmN5IHRoYXQgaGVhdmlseSBy ZWxpZXMgb24gKHNvbWV0aW1lcyBhcmJpdHJhcnkpIGRlY2lzaW9ucyBtYWRlDQpieSB0aGUgc3lz dGVtIGFkbWluaXN0cmF0b3JzIHdob3NlIHNlY3VyaXR5IHBvbGljaWVzIGxlYWQgdG8gdG90YWwg b3IgcGFydGlhbA0KYmxhY2tob2xlcy4NCkhlbmNlIG15IHF1ZXN0aW9uczogaXMgdGhlIHNpdHVh dGlvbiBzaW1pbGFyIHdpdGggTVBMUyBvciBjYW4gd2UgZXhwZWN0IG1vcmUNCmhvbW9nZW5lb3Vz IGFuZCBmYXZvcmFibGUgc2VjdXJpdHkgcG9saWNpZXMgKGUuZy4sIGJlY2F1c2UgdGhlcmUncyBh IGxpbWl0ZWQNCm51bWJlciBvZiBhZG1pbmlzdHJhdGl2ZSBkb21haW5zLCBvciBiZWNhdXNlIHdl IGFyZSBub3QgcmVseWluZyBvbiBhbiBJQ01QDQptZWNoYW5pc20gYW55IG1vcmUsIG9yIGJlY2F1 c2UgdGhlIHByZXNlbnQgZG9jdW1lbnQgaXMgbW9yZSBkaXJlY3RpdmUgb24NCndoYXQgYSBzeXN0 ZW0gYWRtaW5pc3RyYXRvciBzaG91bGQgYXV0aG9yaXplL2Jsb2NrL2xpbWl0KT8NCg0KWWVzLiBX ZSBjYW4gZXhwZWN0IGEgbW9yZSBob21vZ2VuZW91cyBhbmQgZmF2b3JhYmxlIHNldCBvZiBzZWN1 cml0eSBwb2xpY2llcywgYmVjYXVzZSBvZiBhbGwgdGhvc2UgcmVhc29ucy4NCg0KVGhpcyBjb3Vs ZCBjaGFuZ2UgYSBsb3QgdGhlIHNlY3VyaXR5IGFzcGVjdHMgYW5kIHRoZSBwb3RlbnRpYWwgaW1w YWN0cyBvbiB0aGUNCmRlYnVnZ2luZyB0b29scy4NCg0KDQo0LSBMYXRlciBpdCBpcyBzYWlkOg0K ICAgICAiVG8gYXZvaWQgcG90ZW50aWFsIERlbmlhbC1vZi1TZXJ2aWNlIGF0dGFja3MsIGl0IGlz IFJFQ09NTUVOREVEIHRoYXQNCiAgICAgaW1wbGVtZW50YXRpb25zIHJlZ3VsYXRlIHRoZSBMU1Ag cGluZyB0cmFmZmljIGdvaW5nIHRvIHRoZSBjb250cm9sDQogICAgIHBsYW5lLiAgQSByYXRlIGxp bWl0ZXIgU0hPVUxEIGJlIGFwcGxpZWQgdG8gdGhlIHdlbGwta25vd24gVURQIHBvcnQNCiAgICAg ZGVmaW5lZCBiZWxvdy4iDQotIERvIHlvdSBtZWFuIHBvcnQgMzUwMz8gSXQgaXMgbWVudGlvbm5l ZCBidXQgbm90IGRlZmluZWQgYmVsb3cgaW4gdGhpcyBzZWN0aW9uLg0KICBXb3JkaW5nIHNob3Vs ZCBiZSBhZGp1c3RlZC4NCg0KSXQgYWN0dWFsbHkgaXMgZGVmaW5lZCBiZWxvdy4gVGhlIFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zIGlzIFNlY3Rpb24gNSwgYW5kIHRoZSBwb3J0IGRlZmluaXRpb24g aXMgaW4gU2VjdGlvbiA2Lg0KDQpJIGFkZGVkIGEgbW9yZSBwcmVjaXNlIHBvaW50ZXI6DQoNCiAg IFRvIGF2b2lkIHBvdGVudGlhbCBEZW5pYWwtb2YtU2VydmljZSBhdHRhY2tzLCBpdCBpcyBSRUNP TU1FTkRFRCB0aGF0DQogICBpbXBsZW1lbnRhdGlvbnMgcmVndWxhdGUgdGhlIExTUCBwaW5nIHRy YWZmaWMgZ29pbmcgdG8gdGhlIGNvbnRyb2wNCiAgIHBsYW5lLiAgQSByYXRlIGxpbWl0ZXIgU0hP VUxEIGJlIGFwcGxpZWQgdG8gdGhlIHdlbGwta25vd24gVURQIHBvcnQNCiAgIGRlZmluZWQgaW4g U2VjdGlvbiA2LjEuDQoNClRoYW5rcyBmb3IgdGhlIGNvbW1lbnQuDQoNCg0KLSBJdCBpcyBub3Qg Y2xlYXIgdG8gbWUgYnkgcmVhZGluZyB0aGlzIHNlbnRlbmNlIGlmIGl0IGNvbmNlcm5zIHRoZSBz ZW5kZXINCiAgKHdobyBzZW5kcyB0cmFmZmljIHRvIHRoZSBjb250cm9sIHBsYW5lKSBvciBmb3J3 YXJkaW5nIG5vZGVzLCB3aGljaCBJIGd1ZXNzDQogIGFyZSB0aGUgdGFyZ2V0LiBJbiBvdGhlciB3 b3JkcywgImdvaW5nIHRvIHRoZSBjb250cm9sIHBsYW5lIiBpcyBzb21ld2hhdA0KICBhbWJpZ3Vv dXMuDQoNCklmIHlvdSBsb29rIGF0IHRoZSBkb2N1bWVudCBsb2NraW5nIG9uICJzZW50IHRvIHRo ZSBjb250cm9sIHBsYW5l4oCdIGFuZCB2YXJpYXRpb25zIG9mIGl0LCB0aGUgbWVhbmluZyB3aWxs IGJlIGNsZWFyLg0KDQoNCg0KNS0gVGhlbjoNCiAgICAgIlRvIHByb3RlY3QgYWdhaW5zdCB1bmF1 dGhvcml6ZWQgc291cmNlcyB1c2luZyBNUExTIGVjaG8gcmVxdWVzdA0KICAgICBtZXNzYWdlcyB0 byBvYnRhaW4gbmV0d29yayBpbmZvcm1hdGlvbiwgaXQgaXMgUkVDT01NRU5ERUQgdGhhdA0KICAg ICBpbXBsZW1lbnRhdGlvbnMgcHJvdmlkZSBhIG1lYW5zIG9mIGNoZWNraW5nIHRoZSBzb3VyY2Ug YWRkcmVzc2VzIG9mDQogICAgIE1QTFMgZWNobyByZXF1ZXN0IG1lc3NhZ2VzIGFnYWluc3QgYW4g YWNjZXNzIGxpc3QgYmVmb3JlIGFjY2VwdGluZw0KICAgICB0aGUgbWVzc2FnZS4iDQpBcmUgQUNM IGVmZmljaWVudCBpbiB0aGlzIGNvbnRleHQ/IElmIGFuIGF0dGFja2VyIGNhbiBmb3JnZSB0aGUg c291cmNlIGFkZHJlc3MsDQppdCdzIG5vdC4gVW5sZXNzIHNvbWUgY3J5cHRvZ3JhcGhpYyBtZWNo YW5pc20gaXMgdXNlZCwgdGhlcmUncyBsaXR0bGUgaG9wZSB0bw0KcHJvdmlkZSBhIHNlY3VyZSBw aW5nIHNlcnZpY2UuIFRoaXMgaXMgYSBmb2xsb3cgdXAgb2YgY29tbWVudCAxLg0KDQoNClRoaXMg ZG9jdW1lbnQgZG9lcyBub3QgZ29hbCBpdHNlbGYgaW4gZGVmaW5pbmcgInNlY3VyZSBwaW5n4oCd LiBJdCBzcGVjaWZpZXMg4oCcTFNQIFBpbmfigJ0sIGFzIGEgYmlzIGRvY3VtZW50Lg0KDQpIb3dl dmVyLCBpZiB5b3UgaGF2ZSBzcGVjaWZpYyB0ZXh0dWFsIHN1Z2dlc3Rpb25zIGZvciBpbXByb3Zl bWVudCwgdGhvc2UgbWF5IGFsc28gaGVscCBjbGFyaWZ5Lg0KDQoNCi0gVHlwbzoNCiAgICAgIi4u LmFuIGltcGxlbWVudGF0aW9uIE1BWSBhbHNvIHZhbGlkYXRlIHRoZSBUaW1lU3RhbXANCiAgICAg U2VudCBieSByZXF1aXJpbmcgYW4gZXhhY3QgbWF0Y2ggb24gdGhpcyBmaWVsZC4iDQpTZW50ID0+ IHNlbnQuDQoNCk5vLiBJdOKAmXMgdGhlIOKAnFRpbWVTdGFtcCBTZW504oCdIGZpZWxkIChzZWUg cGFnZSAxMikuDQoNClRoYW5rcyBhZ2FpbiwNCg0K4oCUIENhcmxvcy4NCg0KDQpDaGVlcnMsDQoN CiAgVmluY2VudA0KDQo= --_000_59069EEBD17D4ECD8AF6507F9E6B3084ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGVsbG8gVmluY2VudCwNCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5NYW55IHRoYW5rcyBmb3IgeW91ciByZXZpZXchIFBs ZWFzZSBmaW5kIHNvbWUgcmVzcG9uc2VzIGlubGluZS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj5PbiBPY3QgMjEsIDIwMTYsIGF0IDE6MTMgQU0sIFZpbmNlbnQgUm9jYSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnZpbmNlbnQucm9jYUBpbnJpYS5mciIgY2xhc3M9IiI+dmluY2VudC5y b2NhQGlucmlhLmZyPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVy Y2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDog YnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6 IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQpIZWxsbyw8YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBz ZWN1cml0eSBkaXJlY3RvcmF0ZeKAmXMgb25nb2luZzxiciBjbGFzcz0iIj4NCmVmZm9ydCB0byBy ZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gVGhl c2U8YnIgY2xhc3M9IiI+DQpjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUg YmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYTxiciBjbGFzcz0iIj4NCmRpcmVjdG9ycy4gJm5i c3A7RG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21t ZW50cyBqdXN0PGJyIGNsYXNzPSIiPg0KbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRz Lg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SU1I TywgdGhlIGRvY3VtZW50IGlzJm5ic3A7PHN0cm9uZyBjbGFzcz0iIj5SZWFkeSB3aXRoIGlzc3Vl czwvc3Ryb25nPjxiIGNsYXNzPSIiPi48L2I+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiIGNsYXNz PSIiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDogbm9ybWFsOyIgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9zcGFuPjwvYj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGIgY2xhc3M9IiI+PHNwYW4g c3R5bGU9ImZvbnQtd2VpZ2h0OiBub3JtYWw7IiBjbGFzcz0iIj5JIGhhdmUgdDwvc3Bhbj48L2I+ d28gbWFpbiBjb21tZW50czo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4xLSBUaGlzIGRvY3VtZW50IGhhcyBh biBpbnRlcmVzdGluZyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uLiBIb3dldmVyIGl0 PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPmxhY2tzIHNvbWUga2V5IGluZm9ybWF0aW9uLiBGaXJzdCBv ZiBhbGwsIHRoZXJlIGlzIG5vIGF0dGFja2VyIG1vZGVsLiBJcyB0aGU8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+dGhyZWF0IGNvbWluZyBmcm9tIGNvcnJ1cHRlZCBlcXVpcG1lbnQ/IERvIHdlIGFzc3Vt ZSB0aG9zZSBhdHRhY2tlcnMgaGF2ZSBmdWxsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPmNvbnRyb2wg b3ZlciB0aGUgZXF1aXBtZW50IGFuZCBmbG93cz8gQXJlIGF0dGFja2VycyBvbiBwYXRoIG9yIG9m ZiBwYXRoPzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5DbGFyaWZ5aW5nIHRoZXNlIHBvaW50cyAoaXQn cyBub3QgYW4gZXhoYXVzdGl2ZSBsaXN0KSB3b3VsZCBoZWxwIHN0cnVjdHVyaW5nIHRoZTwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj5kaXNjdXNzaW9uIG9uIGEgY2FzZSBieSBjYXNlIGJhc2lzLjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlRo ZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIGNvdmVycyB0aGUgYXBwcm9hY2hlcyB0 byBhdHRhY2tpbmcgTFNScyB1c2luZyBMU1AgUGluZy9UcmFjZXJvdXRlLiBUaGlzIGlzIGFuIGV4 aGF1c3RpdmUgbGlzdCB3aGljaCBpbmNsdWRlcyBhY3RpdmUgYW5kIHBhc3NpdmUgYXR0YWNrcy4g SXMgdGhlcmUgc29tZSBzcGVjaWZpYyBhdHRhY2sgeW91IHNlZSB0aGF0IGlzIG5vdCBjb3ZlcmVk PzwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Vi a2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3Bh Y2U7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4yLSBTb21ldGhpbmcgZWxzZSB0byBjbGFyaWZ5OiBJ IGhhdmUgdGhlIGZlZWxpbmcgKGFmdGVyIHF1aWNrbHkgc2VhcmNoaW5nIGludGVncml0eS88L2Rp dj4NCjxkaXYgY2xhc3M9IiI+YXV0aGVudGljYXRpb24vSE1BQy8uLi4ga2V5d29yZHMgaW4gdGhl IGRvYykgdGhhdCBpcyBubyBtZXNzYWdlIGludGVncml0eTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5u b3Igc2VuZGVyIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSBpbiB0aGUgZWNobyByZXF1ZXN0L3Jl c3BvbnNlIGRldGFpbGVkIGhlcmUuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5UaGF0IGlzIGNvcnJl Y3QsIG5vIG1lc3NhZ2UgaW50ZWdyaXR5IG5vciBzZW5kZXIgYXV0aGVudGljYXRpb24gaW4gTFNQ IFBpbmcuPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7 IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0 ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+SWYgdGhl IGF0dGFja2VyIG1vZGVsIGFsc28gaW5jbHVkZXMgYSBmdWxsIGNvbnRyb2wgb2YgTFNSLCBub3Ro aW5nIGNhbiBiZSBkb25lIHRvPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPnByZXZlbnQgc29tZSBhdHRh Y2tzLiBQbGVhc2UgY2xhcmlmeS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5Tb3JyeSBidXQgaWYgYW4gYXR0YWNrZXIgaGFzIGZ1bGwg Y29udHJvbCBvZiBhbiBMU1IsIHNoZSBvciBoZSBpcyBwcm9iYWJseSB0b28gYnVzeSBvbiBzYWlk IExTUiB0byBzZW5kIExTUCBQaW5ncyA6LSk8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Indv cmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxp bmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QW5kIGEg ZmV3IGFkZGl0aW9uYWwgb25lczo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjMtIEZpcnN0IHNlbnRlbmNlIHNheXM6PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsmcXVvdDtPdmVyYWxsLCB0aGUgc2VjdXJpdHkgbmVlZHMg Zm9yIExTUCBwaW5nIGFyZSBzaW1pbGFyIHRvIHRob3NlIG9mIElDTVAgcGluZy4mcXVvdDs8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+U3VjaCBkZWJ1Z2dpbmcgdG9vbHMgYXMgcGluZyBhbmQgdHJhY2Vy b3V0ZSAobm90IHNwZWFraW5nIG9mIE1QTFMgdmVyc2lvbiBoZXJlKTwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5oYXZlIGFuIGVmZmljaWVuY3kgdGhhdCBoZWF2aWx5IHJlbGllcyBvbiAoc29tZXRpbWVz IGFyYml0cmFyeSkgZGVjaXNpb25zIG1hZGU8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+YnkgdGhlIHN5 c3RlbSBhZG1pbmlzdHJhdG9ycyB3aG9zZSBzZWN1cml0eSBwb2xpY2llcyBsZWFkIHRvIHRvdGFs IG9yIHBhcnRpYWw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+YmxhY2tob2xlcy48L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+SGVuY2UgbXkgcXVlc3Rpb25zOiBpcyB0aGUgc2l0dWF0aW9uIHNpbWlsYXIgd2l0 aCBNUExTIG9yIGNhbiB3ZSBleHBlY3QgbW9yZTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5ob21vZ2Vu ZW91cyBhbmQgZmF2b3JhYmxlIHNlY3VyaXR5IHBvbGljaWVzIChlLmcuLCBiZWNhdXNlIHRoZXJl J3MgYSBsaW1pdGVkPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPm51bWJlciBvZiBhZG1pbmlzdHJhdGl2 ZSBkb21haW5zLCBvciBiZWNhdXNlIHdlIGFyZSBub3QgcmVseWluZyBvbiBhbiBJQ01QPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPm1lY2hhbmlzbSBhbnkgbW9yZSwgb3IgYmVjYXVzZSB0aGUgcHJlc2Vu dCBkb2N1bWVudCBpcyBtb3JlIGRpcmVjdGl2ZSBvbjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj53aGF0 IGEgc3lzdGVtIGFkbWluaXN0cmF0b3Igc2hvdWxkIGF1dGhvcml6ZS9ibG9jay9saW1pdCk/PC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdj5ZZXMuIFdlIGNhbiBleHBlY3QgYSBtb3JlIGhvbW9nZW5lb3Vz IGFuZCBmYXZvcmFibGUgc2V0IG9mIHNlY3VyaXR5IHBvbGljaWVzLCBiZWNhdXNlIG9mIGFsbCB0 aG9zZSByZWFzb25zLjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVh ay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi PlRoaXMgY291bGQgY2hhbmdlIGEgbG90IHRoZSBzZWN1cml0eSBhc3BlY3RzIGFuZCB0aGUgcG90 ZW50aWFsIGltcGFjdHMgb24gdGhlPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPmRlYnVnZ2luZyB0b29s cy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj40LSBMYXRlciBpdCBpcyBz YWlkOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O1RvIGF2 b2lkIHBvdGVudGlhbCBEZW5pYWwtb2YtU2VydmljZSBhdHRhY2tzLCBpdCBpcyBSRUNPTU1FTkRF RCB0aGF0PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7aW1wbGVtZW50 YXRpb25zIHJlZ3VsYXRlIHRoZSBMU1AgcGluZyB0cmFmZmljIGdvaW5nIHRvIHRoZSBjb250cm9s PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7cGxhbmUuICZuYnNwO0Eg cmF0ZSBsaW1pdGVyIFNIT1VMRCBiZSBhcHBsaWVkIHRvIHRoZSB3ZWxsLWtub3duIFVEUCBwb3J0 PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ZGVmaW5lZCBiZWxvdy4m cXVvdDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LSBEbyB5b3UgbWVhbiBwb3J0IDM1MDM/IEl0IGlz IG1lbnRpb25uZWQgYnV0IG5vdCBkZWZpbmVkIGJlbG93IGluIHRoaXMgc2VjdGlvbi48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+Jm5ic3A7IFdvcmRpbmcgc2hvdWxkIGJlIGFkanVzdGVkLjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXY+SXQgYWN0dWFsbHkgaXMgZGVmaW5lZCBiZWxvdy4gVGhlIFNlY3VyaXR5 IENvbnNpZGVyYXRpb25zIGlzIFNlY3Rpb24gNSwgYW5kIHRoZSBwb3J0IGRlZmluaXRpb24gaXMg aW4gU2VjdGlvbiA2LjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+SSBh ZGRlZCBhIG1vcmUgcHJlY2lzZSBwb2ludGVyOjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwO1RvIGF2b2lkIHBvdGVudGlhbCBEZW5pYWwtb2YtU2Vy dmljZSBhdHRhY2tzLCBpdCBpcyBSRUNPTU1FTkRFRCB0aGF0PGJyIGNsYXNzPSIiPg0KJm5ic3A7 ICZuYnNwO2ltcGxlbWVudGF0aW9ucyByZWd1bGF0ZSB0aGUgTFNQIHBpbmcgdHJhZmZpYyBnb2lu ZyB0byB0aGUgY29udHJvbDxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtwbGFuZS4mbmJzcDsm bmJzcDtBIHJhdGUgbGltaXRlciBTSE9VTEQgYmUgYXBwbGllZCB0byB0aGUgd2VsbC1rbm93biBV RFAgcG9ydDxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtkZWZpbmVkIGluIFNlY3Rpb24gNi4x LjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzIGZvciB0aGUg Y29tbWVudC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFzcz0i Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNl OyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4tIEl0IGlzIG5vdCBjbGVhciB0byBtZSBieSByZWFk aW5nIHRoaXMgc2VudGVuY2UgaWYgaXQgY29uY2VybnMgdGhlIHNlbmRlcjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4mbmJzcDsgKHdobyBzZW5kcyB0cmFmZmljIHRvIHRoZSBjb250cm9sIHBsYW5lKSBv ciBmb3J3YXJkaW5nIG5vZGVzLCB3aGljaCBJIGd1ZXNzPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZu YnNwOyBhcmUgdGhlIHRhcmdldC4gSW4gb3RoZXIgd29yZHMsICZxdW90O2dvaW5nIHRvIHRoZSBj b250cm9sIHBsYW5lJnF1b3Q7IGlzIHNvbWV3aGF0PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNw OyBhbWJpZ3VvdXMuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5JZiB5b3UgbG9vayBhdCB0aGUgZG9j dW1lbnQgbG9ja2luZyBvbiAmcXVvdDtzZW50IHRvIHRoZSBjb250cm9sIHBsYW5l4oCdIGFuZCB2 YXJpYXRpb25zIG9mIGl0LCB0aGUgbWVhbmluZyB3aWxsIGJlIGNsZWFyLjwvZGl2Pg0KPGJyIGNs YXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTog c3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+NS0gVGhlbjo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtUbyBwcm90ZWN0 IGFnYWluc3QgdW5hdXRob3JpemVkIHNvdXJjZXMgdXNpbmcgTVBMUyBlY2hvIHJlcXVlc3Q8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDttZXNzYWdlcyB0byBvYnRhaW4g bmV0d29yayBpbmZvcm1hdGlvbiwgaXQgaXMgUkVDT01NRU5ERUQgdGhhdDwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwO2ltcGxlbWVudGF0aW9ucyBwcm92aWRlIGEgbWVh bnMgb2YgY2hlY2tpbmcgdGhlIHNvdXJjZSBhZGRyZXNzZXMgb2Y8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtNUExTIGVjaG8gcmVxdWVzdCBtZXNzYWdlcyBhZ2FpbnN0 IGFuIGFjY2VzcyBsaXN0IGJlZm9yZSBhY2NlcHRpbmc8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5i c3A7ICZuYnNwOyAmbmJzcDt0aGUgbWVzc2FnZS4mcXVvdDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ QXJlIEFDTCBlZmZpY2llbnQgaW4gdGhpcyBjb250ZXh0PyBJZiBhbiBhdHRhY2tlciBjYW4gZm9y Z2UgdGhlIHNvdXJjZSBhZGRyZXNzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5pdCdzIG5vdC4gVW5s ZXNzIHNvbWUgY3J5cHRvZ3JhcGhpYyBtZWNoYW5pc20gaXMgdXNlZCwgdGhlcmUncyBsaXR0bGUg aG9wZSB0bzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5wcm92aWRlIGEgc2VjdXJlIHBpbmcgc2Vydmlj ZS4gVGhpcyBpcyBhIGZvbGxvdyB1cCBvZiBjb21tZW50IDEuPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+VGhpcyBkb2N1bWVudCBkb2Vz IG5vdCBnb2FsIGl0c2VsZiBpbiBkZWZpbmluZyAmcXVvdDtzZWN1cmUgcGluZ+KAnS4gSXQgc3Bl Y2lmaWVzIOKAnExTUCBQaW5n4oCdLCBhcyBhIGJpcyBkb2N1bWVudC48L2Rpdj4NCjxkaXY+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2Pkhvd2V2ZXIsIGlmIHlvdSBoYXZlIHNwZWNpZmljIHRl eHR1YWwgc3VnZ2VzdGlvbnMgZm9yIGltcHJvdmVtZW50LCB0aG9zZSBtYXkgYWxzbyBoZWxwIGNs YXJpZnkuPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7 IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0 ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi0gVHlwbzo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDsuLi5hbiBpbXBsZW1lbnRhdGlvbiBNQVkgYWxz byB2YWxpZGF0ZSB0aGUgVGltZVN0YW1wPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJz cDsgJm5ic3A7U2VudCBieSByZXF1aXJpbmcgYW4gZXhhY3QgbWF0Y2ggb24gdGhpcyBmaWVsZC4m cXVvdDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+U2VudCA9Jmd0OyBzZW50LjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXY+Tm8uIEl04oCZcyB0aGUg4oCcVGltZVN0YW1wIFNlbnTigJ0gZmllbGQgKHNlZSBw YWdlIDEyKS48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyBh Z2Fpbiw8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PuKAlCBDYXJsb3Mu PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJr aXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFj ZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkNoZWVycyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyBWaW5jZW50PC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_59069EEBD17D4ECD8AF6507F9E6B3084ciscocom_-- From michael.baeuerle@stz-e.de Tue Oct 25 09:41:37 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1770112959E; Tue, 25 Oct 2016 09:41:37 -0700 (PDT) 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 JBhnA9wuyBq7; Tue, 25 Oct 2016 09:41:35 -0700 (PDT) Received: from hardbaer.com (mail.hardbaer.com [91.250.101.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 062B4127078; Tue, 25 Oct 2016 09:41:34 -0700 (PDT) X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from WStation3.stz-e.de (business-092-079-177-146.static.arcor-ip.net [92.79.177.146]) by hardbaer.com (Postfix) with ESMTPSA id 210B01C695CCC; Tue, 25 Oct 2016 18:41:32 +0200 (CEST) Date: Tue, 25 Oct 2016 18:41:26 +0200 From: Michael =?ISO-8859-1?B?QuR1ZXJsZQ==?= To: Julien =?ISO-8859-1?B?yUxJRQ==?= Message-ID: <20161025184126.62bab74f@WStation3.stz-e.de> In-Reply-To: <10b4998e-67ae-abdf-c1f0-321c28bcb4fe@trigofacile.com> References: <20981db3190142193043f1445abadaa3@trigofacile.com> <10b4998e-67ae-abdf-c1f0-321c28bcb4fe@trigofacile.com> User-Agent: Claws-Mail/3.13.1 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Wed, 26 Oct 2016 00:59:20 -0700 Cc: draft-murchison-nntp-compress.all@ietf.org, Barry Leiba , IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-murchison-nntp-compress-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 07:37:27 -0000 Julien =C9LIE wrote: >=20 > Hi Barry, >=20 > Thanks again for your valuable comments on the document. They were very > much appreciated, and permitted to fix a few issues. >=20 > I've just finalized a revised draft, taking into account all the comments > received during Last Call. > I just want to highlight the following change in wording. > Ken and Michael, as respectively co-author and document shepherd, please > tell if you think the new wording is not the right thing to do. >=20 > Personally, I think this document (draft-murchison-nntp-compress) should > only focus on standardizing the COMPRESS command and not try to fix > how authentication works in another kind of compression (TLS-level > compression). It would otherwise be an update to RFC 4643. >=20 > Updating TLS usage with NNTP is the aim of a second, separate document > (draft-elie-nntp-tls-recommendations) that updates RFC 4643 with > best current practices. That one discourages the use of TLS-level > compression, thus dealing with authentication layered with a TLS-level > compression method. >=20 >=20 > >> In order to help mitigate leaking authentication credentials via for > >> instance a CRIME attack [CRIME], authentication SHOULD NOT be > >> attempted when a compression layer is active. Consequently, a server > >> SHOULD NOT return any arguments with the AUTHINFO capability label > >> (or SHOULD NOT advertise it at all) in response to a CAPABILITIES > >> command received from an unauthenticated client after a compression > >> layer is active, and such a client SHOULD NOT attempt to utilize any > >> AUTHINFO [RFC4643] commands. It implies that a server SHOULD reply > >> with a 502 response code if a syntactically valid AUTHINFO command is > >> received while a compression layer is already active. > >> > >> Why are these SHOULD, and not MUST? Under what conditions would it be > >> necessary or reasonable for an implementation not to abide by these, > >> and what considerations need to be considered when making that > >> determination? (And this is also directly referred to in Section 6.) = =20 > [...] > > OK. I've adopted your suggestion. =20 > [...] > > Hmm... I think I should now do a pass on the document and explicitly > > say when "compression layer" only means the one negotiated with COMPRES= S. > > As a matter of fact, I do not think it's a good idea to say in this > > draft that authentication MUST NOT be attempted when TLS-level > > compression is active! It would otherwise be a change in how > > authentication works (RFC 4643 heavily mentions the preferred use of > > AUTHINFO along with TLS, and RFC 4642 allows TLS-level compression). > > This document would otherwise be an update to RFC 4643, by no longer > > allowing AUTHINFO when TLS-level compression is active. =20 >=20 > Pass done. I updated the wording in a few parts of the document. > The above quoted paragraph becomes: >=20 > In order to help mitigate leaking authentication credentials via for > instance a CRIME attack [CRIME], authentication MUST NOT be attempted > after a successful use of the COMPRESS command. Consequently, a > server MUST either list the AUTHINFO capability with no arguments or > not advertise it at all, in response to a CAPABILITIES command > received from an unauthenticated client after a successful use of the > COMPRESS command, and such a client MUST NOT attempt to utilize any > AUTHINFO [RFC4643] commands. It implies that a server MUST reply > with a 502 response code if a syntactically valid AUTHINFO command is > received after a successful use of the COMPRESS command. (Note that > this specification does not change the behaviour of AUTHINFO as > described in [RFC4643] independently of TLS-level compression. > Authentication is therefore still allowed, even though TLS-level > compression is active.) >=20 >=20 > I hope you're all fine with that. I'm fine with it. Regards, Michael B=E4uerle From nobody Wed Oct 26 12:34:55 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33BF5129984; Wed, 26 Oct 2016 12:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com 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 SAmMUCYPvLaL; Wed, 26 Oct 2016 12:34:49 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 48EB01296FA; Wed, 26 Oct 2016 12:24:52 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D8291433506; Wed, 26 Oct 2016 19:24:51 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id B7AD443340E; Wed, 26 Oct 2016 19:24:51 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1477509891; bh=VECYaGvMlcL6mOVgOAuOAWoVB+RgMhNpRf9DTLU7jfw=; l=3719; h=From:To:Date:From; b=kmeIcVus8oCgGHjWbqHiWMgiEzMYLJfJ8HbrDv9fS/xnZb4lFdLB3HgGrSV4Z7mkS qG2E1cwZkahZox/qPHITpKZf3EY/QEr4SAuCFCOcZOPxBAu2b/XMrCB0qDBn3mKe9j ZQ7SWoDgdFzsn8bdtoMgU63Y8LrI6/W6lsbMzlDQ= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id B3F1A1FC8E; Wed, 26 Oct 2016 19:24:51 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 26 Oct 2016 15:24:51 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Wed, 26 Oct 2016 15:24:51 -0400 From: "Salz, Rich" To: "'secdir@ietf.org'" , "'iesg@ietf.org'" , "draft-ietf-roll-routing-dispatch.all@ietf.org" Thread-Topic: Secdir review of draft-ietf-roll-routing-dispatch Thread-Index: AdIvvibioqyXhlaeRu22KY4TaHKTEQ== Date: Wed, 26 Oct 2016 19:24:50 +0000 Message-ID: <26e31afc819f4af7884e831a8964f93a@usma1ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.47.64] Content-Type: multipart/alternative; boundary="_000_26e31afc819f4af7884e831a8964f93ausma1exdag1mb1msgcorpak_" MIME-Version: 1.0 Archived-At: Subject: [secdir] Secdir review of draft-ietf-roll-routing-dispatch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 19:34:50 -0000 --_000_26e31afc819f4af7884e831a8964f93ausma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. I found the Introduction section particularly useful and informative. The = security considerations seem complete and accurate. In my view, this document is *Ready* -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz --_000_26e31afc819f4af7884e831a8964f93ausma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

I have reviewed this document as part of the securit= y directorate's ongoing effort to review all IETF documents being processed= by the IESG.  These comments were written primarily for the benefit o= f the security area directors.  Document editors and WG chairs should treat these comments just like any other last= call comments.

 

I found the Introduction section particularly useful= and informative.  The security considerations seem complete and accur= ate.

 

In my view, this document is *Ready*

 

-- 

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

IM: richsalz@jabber.at Twitter: RichSalz<= /p>

 

--_000_26e31afc819f4af7884e831a8964f93ausma1exdag1mb1msgcorpak_-- From nobody Thu Oct 27 09:24:50 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A6F129687 for ; Thu, 27 Oct 2016 09:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 1EWSDKz9gSUT for ; Thu, 27 Oct 2016 09:24:46 -0700 (PDT) Received: from nm29-vm3.bullet.mail.ne1.yahoo.com (nm29-vm3.bullet.mail.ne1.yahoo.com [98.138.91.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E50A129685 for ; Thu, 27 Oct 2016 09:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1477585484; bh=JeGdf4WMZ+2yBRgCsy3mAuNRwTfr/V9a83TWF6RdZiE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=IWZuySn2jO0gYC6X53KF2UsZbcFm92bLFMOQ2KZM8XqBNkmznaGkAuCThKX0JND6rOU5Bf5ZAdg4lo76B4FR2z1mGiuTB6Oe2Mu+OKsQjJzKGm0RTo77r++zk3ESN0iUZjuDy+DhmOdTaDUnYdQBzanxM02IvK3chsKhPKuWrEoWl7PMV+YcpUxmv9YMSi5PsyLSx5CD4u4ZAVz5P3cjCMn61KA/+RHnIXoiA1mQQcUILyKIt/CaFSL2g5w84fUxaWZdsZs9PUSsmcunpCPti6aqW7RUJU3BnhXLvryRDfNr5NvAtGKh5ajGHlLgj3BE1BXKwRqinrw5wFlHPODknQ== Received: from [98.138.100.115] by nm29.bullet.mail.ne1.yahoo.com with NNFMP; 27 Oct 2016 16:24:44 -0000 Received: from [98.138.89.164] by tm106.bullet.mail.ne1.yahoo.com with NNFMP; 27 Oct 2016 16:24:44 -0000 Received: from [127.0.0.1] by omp1020.mail.ne1.yahoo.com with NNFMP; 27 Oct 2016 16:24:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 721685.17014.bm@omp1020.mail.ne1.yahoo.com X-YMail-OSG: QQRRLskVM1k8yCd5ihVwshdtdP9DqELmEtDvISiNP3XwxnWxsLjvGn2yR05v6Us nyJw5Ws7ukNpaMpS_e1dW3.GteTO7ZA3Apt6yt4ll7DGmGJnVtao.ySXuNhqrD1Iu36QfN9kdQeq lmRDKzcYJPaBkzLUgBM8eE9zgWalXW1s1mnY6Q4aGnHQnPonxj0mbSZlJ2w1m6zJCA9QshOFWkJi xvFUikpsmv8iPyZa1LXnI6_1tEKxem2IZYIQVd8p_bNlSjvJQmguHF7l6Kv_1oTVLL9eeCRO9KWT YRxGTIWgD18DSORIS6Mhs6GZZG4FtWgu45ygGzSu48Fdfifuor1GaUHrGsRf5Js5U_FlQPqESdVk qGrt6fOlLyIFuRA3H8JodykBbjWXAPF7YlDYu9U0AbcoPy2hVVkEy.eGEQb8tpSUfZNOLGN6h3ca cO_6CYxYwj_eJaBRZD0psG4A51tQv6nRXSd1N4Se_TpOCsGV5Sepzn1CMKK9IPbv1te9964C.QR2 mdW2U59lHs7Bmzo3fdW.QhICeflJ6RO8FNpCXPJ52RrNwJpsTV2_iw2xF1g2CRIo6X038CurO1F8 tb_Q9XkcCAaoawoJN Received: from jws200147.mail.ne1.yahoo.com by sendmailws105.mail.ne1.yahoo.com; Thu, 27 Oct 2016 16:24:44 +0000; 1477585484.188 Date: Thu, 27 Oct 2016 16:24:28 +0000 (UTC) From: To: Tero Kivinen Message-ID: <926572461.2227323.1477585468286@mail.yahoo.com> In-Reply-To: <22523.36827.869306.70163@fireball.acr.fi> References: <22495.62038.771947.984586@fireball.acr.fi> <1264225155.363685.1474644268281@mail.yahoo.com> <22507.60901.665544.878052@fireball.acr.fi> <1130739157.4563724.1475509147203@mail.yahoo.com> <22523.36827.869306.70163@fireball.acr.fi> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2227319_208211538.1477585468274" Archived-At: Cc: "iesg@ietf.org" , "draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-05: ESP Processing X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 16:24:48 -0000 ------=_Part_2227319_208211538.1477585468274 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Tero, I am trying to do the wording for ESP processing: Below are your comments: >I would recommend that if you use transport mode ESP (i.e., where the>flow= information would be leaked out from the ESP if PDM is used) then >it must be put inside the ESP. If you use tunnel mode ESP, then there >migth be two PDM headers in the packet, one in the inner packet inside >the ESP header (which has full IP header + destination options >including PDM option), and another one in the outer header, in which >case it would only cover the ESP as one flow (i.e., each ESP SA >identified by the SPIs would get separate PDM option). >I.e. in the Tunnel mode ESP you want to defined the "5-tuple" as: >SADDR, DADDR, PROTC (=3DESP), SPI-IN, SPI-OUT >Btw, in the ICMP etc you do not have port numbers. Are ICMP frames >related to the TCP flows matching the "5-tuple" of the TCP flow or are >they counted as separate? >Anyways so if you define Tunnel mode ESP that way, then you can get >some performance metrics from the ESP processing also. Then if the >enterprice is willing to sacrifice the traffic flow confidentiality, >they can turn on the sa-per-flow option of the IPsec implementation, >which will create separate SA pair for each TCP/UDP etc flow, so then >they will get exact measurements. > >In normal case the Tunnel mode ESP will just provide performance >metrics for combination of all traffic inside the tunnel, not per >flow. >When using the Transport Mode ESP, then putting the PDM option inside >still provides performance metrics for the host.=C2=A0 This is the old section 3.4 3.4 Header Placement Using IPSec ESP Mode IP Encapsulating Security Payload (ESP) is defined in [RFC4303] and is widely used. Section=C2=A03.1.1 of [RFC4303] discusses placement of Destination Options Headers. Below is the diagram from [RFC4303] discussing placement. PDM MUST be placed before the ESP header in order to work. If placed before the ESP header, the PDM header will flow in the clear over the network thus allowing gathering of performance and diagnostic data without sacrificing security. BEFORE APPLYING ESP --------------------------------------- IPv6 | | ext hdrs | | | | orig IP hdr |if present| TCP | Data | --------------------------------------- AFTER APPLYING ESP --------------------------------------------------------- IPv6 | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP| |IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV| --------------------------------------------------------- |<--- encryption ---->| |<------ integrity ------>| * =3D if present, could be before ESP, after ESP, or both New Section 3.4 3.4 Header Placement Using IPSec ESP Mode IPSec Encapsulating Security Payload (ESP) is defined in [RFC4303] and is widely used. Section=C2=A03.1.1 of [RFC4303] discusses placement of Destination Options Headers. =20 The placement of PDM is different depending on if ESP is used in tunn= el or transport mode. 3.4.1 Using Transport Mode Below is the diagram from [RFC4303] discussing placement of headers. N= ote that Destination Options MAY be placed before or after ESP or both. = In transport mode, PDM MUST be placed after the ESP header so as not to = leak information.=20 BEFORE APPLYING ESP --------------------------------------- IPv6 | | ext hdrs | | | | orig IP hdr |if present| TCP | Data | --------------------------------------- AFTER APPLYING ESP --------------------------------------------------------- IPv6 | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP| |IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV| --------------------------------------------------------- |<--- encryption ---->| |<------ integrity ------>| * =3D if present, could be before ESP, after ESP, or both 3.4.2 Using Tunnel Mode Below is the diagram from [RFC4303] discussing placement of headers. N= ote that Destination Options MAY be placed before or after ESP or both in= both the outer set of IP headers and the inner set of IP headers. In tunnel mode, PDM MAY be placed before or after the ESP header or b= oth. BEFORE APPLYING ESP --------------------------------------- IPv6 | | ext hdrs | | | | orig IP hdr |if present| TCP | Data | --------------------------------------- AFTER APPLYING ESP ------------------------------------------------------------ IPv6 | new* |new ext | | orig*|orig ext | | | ESP | ESP| |IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV| ------------------------------------------------------------ |<--------- encryption ---------->| |<------------ integrity ------------>| * =3D if present, construction of outer IP hdr/extensions and modification of inner IP hdr/extensions is discussed in the Security Architecture document. =C2=A0Thanks, Nalini ElkinsInside Products, Inc.www.insidethestack.com(831) 659-8360 From: Tero Kivinen To: nalini.elkins@insidethestack.com=20 Cc: "iesg@ietf.org" ; "secdir@ietf.org" ; "= draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" Sent: Monday, October 10, 2016 5:55 AM Subject: Re: Secdir review of draft-ietf-ippm-6man-pdm-option-05 =20 nalini.elkins@insidethestack.com writes: > >There are most likely also other kind of attacks, and as this is > >service as ESP provides, it is not for PDM to break it unless you > >explictly spell it out that this is meant to break property of the > >ESP.=20 >=20 > OK. I am convinced. I will tell you though that some of us in IPPM, > we were quite excited (possibly naively) about being able to get > some performance metrics for ESP. Why do you think you can performance metrics for ESP in that case?=20 > I wonder if it would be acceptable to say that PDM could be put into > the Destination Option which precedes ESP if it is for an enterprise > customer who owns the infrastructure and wishes to manage the > network that way. Otherwise, I can change to say that only the Dest > Opt following ESP can be used. I would recommend that if you use transport mode ESP (i.e., where the flow information would be leaked out from the ESP if PDM is used) then it must be put inside the ESP. If you use tunnel mode ESP, then there migth be two PDM headers in the packet, one in the inner packet inside the ESP header (which has full IP header + destination options including PDM option), and another one in the outer header, in which case it would only cover the ESP as one flow (i.e., each ESP SA identified by the SPIs would get separate PDM option). I.e. in the Tunnel mode ESP you want to defined the "5-tuple" as: SADDR, DADDR, PROTC (=3DESP), SPI-IN, SPI-OUT Btw, in the ICMP etc you do not have port numbers. Are ICMP frames related to the TCP flows matching the "5-tuple" of the TCP flow or are they counted as separate? Anyways so if you define Tunnel mode ESP that way, then you can get some performance metrics from the ESP processing also. Then if the enterprice is willing to sacrifice the traffic flow confidentiality, they can turn on the sa-per-flow option of the IPsec implementation, which will create separate SA pair for each TCP/UDP etc flow, so then they will get exact measurements. In normal case the Tunnel mode ESP will just provide performance metrics for combination of all traffic inside the tunnel, not per flow. When using the Transport Mode ESP, then putting the PDM option inside still provides performance metrics for the host.=20 > >so the range is definately enough. The question is that if the scale > >is from -127 to 128, why do we even need the Time Base? >=20 > The time base is so that one does not have to be committed to >=C2=A0 picoseconds / milliseconds, etc. Even in your example, I believe >=C2=A0 you used "unit" or time base. Our thinking was that we wanted >=C2=A0 future proof so as to be able to handle very small values and very >=C2=A0 large (as may be needed for DTN, for example). We can see if we can >=C2=A0 express years in picoseconds and see what happens. Then, the unit >=C2=A0 would always be picoseconds. Having scale from -127 to 128 will provide quite good future proof, for at least for this universum. Even if you used attoseconds as base, you could express 10^13 years which is still more than 1000 times longer than the current age of the universe... > >3.5 Implementation Considerations >=20 > >=C2=A0 The PDM destination options extension header SHOULD be turned on = by > >=C2=A0 each stack on a host node. It MAY also be turned on only in case = of > >=C2=A0 diagnostics needed for problem resolution. >=20 > > so it seems it is on by default.=20 >=20 > Will change to say that it MUST be turned on only by the stack and > default value should be OFF. >=20 > "The PDM destination options extension header MUST be turned on only >=C2=A0 by administrative action at each stack on a host node. The default >=C2=A0 mode for PDM is OFF." Good. > >Key management packets are usually in clear, as they are there before > >we have the actual keys we can use to protect the messages. Also it is > >not very difficult to guess that 3rd and 4th message in port 500, are > >the IKE AUTH packets, which will contain signatures. >=20 > >Same thing with TLS. >=20 > >Attackers will knows which packets contain signatures. Currently > >attackers usually send those signature packets themselves, and measure > >the time it takes for the device to calculate response. They can also > >send garbage packets, and detect how far in checking the packets got > >by checking how long it took for the other end to send error message > >back. >=20 > >All this kind of timing attacks are usually considered hard, as the > >network delays cause big jitter on the timings, and they need to try > >multiple times, and average the response times to get the information > >they need. >=20 > >This method will provide them easy way to bypass that issue.=20 >=20 > OK.=C2=A0 So, are you saying that PDM is attack vector for TLS and not > just for ESP? Yes, timing attacks are possible against any crypto protocol. If the protocol and algorithms used in the protocol are specifically written so that they are protected against timing attacks, they will not work, but lots of the implementations and protocols care more about the speed, than for the timing attacks, especially as launching them over longer distance gets harder and harder as other things add random times to measurements. If this allows easy way to get exact timing information from the node without any issues from the network latencies and so on, this might open completely new ways to attack implementations and protocols. Those attacks were not feasible before, but now they might be.=20 > No, obviously not. So, now I am not sure where we are. Is there a > complete objection to this draft or are there changes which can be > made which would make this acceptable? Yes, I do not think there is anything that cannot be fixed, but there are things that needs fixing (from the security point of view): 1) Location of the PDM in ESP transport mode traffic. 2) Make sure this is turned off by default, and you do not want node =C2=A0 to respond incoming PDM options unless turned on by adminstrator. 3) Add to security considerations section aclear warnings about the =C2=A0 new possibilities for timing attacks if PDM is turned on. (not sure if I forgot something). --=20 kivinen@iki.fi =20 ------=_Part_2227319_208211538.1477585468274 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Tero,

I am trying to= do the wording for ESP processing:

Below are your comments:

>I would recommend that if you use tran= sport mode ESP (i.e., where the
>flow information would be leaked out from the ESP if PDM is used) t= hen
>it must be put inside the E= SP. If you use tunnel mode ESP, then there
>migth be two PDM headers in the packet, one in the inner pack= et inside
>the ESP header (which= has full IP header + destination options
>including PDM option), and another one in the outer header, in w= hich
>case it would only cover t= he ESP as one flow (i.e., each ESP SA
>identified by the SPIs would get separate PDM option).

>I.e. in the Tunnel mode ESP you want to defined the "5-tup= le" as:
=
>SADDR, DADDR, PROTC (=3DESP), SPI-IN,= SPI-OUT

>Btw, in the ICMP etc you do not ha= ve port numbers. Are ICMP frames
&g= t;related to the TCP flows matching the "5-tuple" of the TCP flow or are
>they counted as separate?<= br clear=3D"none" style=3D"font-family: "Helvetica Neue", "S= egoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; fon= t-size: 13px;" id=3D"yui_3_16_0_ym19_1_1477581645936_33923">
>Anyways so if you define Tunnel mode ESP that way, t= hen you can get
>some performanc= e metrics from the ESP processing also. Then if the
>enterprice is willing to sacrifice the traffic flow co= nfidentiality,
>they can turn on= the sa-per-flow option of the IPsec implementation,
>which will create separate SA pair for each TCP/UDP e= tc flow, so then
>they will get = exact measurements.
>
>In normal case the Tu= nnel mode ESP will just provide performance
>metrics for combination of all traffic inside the tunnel, not= per
>flow.

>When using the Transport Mode ESP, then putting the PDM option in= side
>still provides performance= metrics for the host. 

This is the old section 3.4
3.4 Header Placement Using IPSec ESP Mode
= 
   IP Encapsulating Security Payload (ESP) is defined in [RFC4303] and
   is widely used.  Section 3.1.1 of [=
RFC4303] discusses placement of
   Destination Options Headers.   Below is the diagram from [RFC4303]
   discussing placement.  PDM MUST be placed before the ESP header in
   order to work.  If placed before the ESP header, the PDM header will
   flow in the clear over the network thus allowing gathering of
   performance and diagnostic data without sacrificing security.

                           BEFORE APPLYING ESP

             ---------------------------------------
       IPv6  |             | ext hdrs |     |      |
             | orig IP hdr |if present| TCP | Data |
             ---------------------------------------

                            AFTER APPLYING ESP
             ---------------------------------------------------------
       IPv6  | orig |hop-by-hop,dest*,|   |dest|   |    | ESP   | ESP|
             |IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV|
             ---------------------------------------------------------
                                          |<--- encryption ---->|
                                          |<------ integrity ------>|

              * =3D if present, could be before ESP, after ESP, or both


=


<=
pre style=3D"font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; bre=
ak-before: page;" id=3D"yui_3_16_0_ym19_1_1477581645936_37596">New Section =
3.4



=

3.4 Header Placement Using IPSec ESP Mod=
e

   IPSec Encapsulating Security Payload (ESP) is defined in [RFC4303] and
   is widely used.  Section 3.1.1 of [=
RFC4303] discusses placement of
   Destination Options Headers.   

   The placem=
ent of PDM is different depending on if ESP is used in 
   tunnel or transport mo=
de.


   3.4.1 Using Transport Mode

   Below is the diagram from [RFC4303] discussing placement of headers.
   Note that Destination Options=
 MAY be placed before or after ESP or
   both.   In transport mode, PDM MUST be p=
laced after the ESP header so
   as not to leak information. 
                           BEFORE APPLYING ESP

             ---------------------------------------
       IPv6  |             | ext hdrs |     |      |
             | orig IP hdr |if present| TCP | Data |
             ---------------------------------------

                            AFTER APPLYING ESP
             ---------------------------------------------------------
       IPv6  | orig |hop-by-hop,dest*,|   |dest|   |    | ESP   | ESP|
             |IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV|
             ---------------------------------------------------------
                                          |<--- encryption ---->|
                                          |<------ integrity ------>|

              * =3D if present, could be before ESP, after ESP, or both


3.4.2=
 Using Tunnel Mode

   Below is the di=
agram from [RFC4303] discussing placement of header=
s.
   Note that D=
estination Options MAY be placed before or after ESP or
   both in both the outer=
 set of IP headers and the inner set of IP
   headers.

   In tunnel mode, PDM MAY be pl=
aced before or after the ESP header 
   or both.


                             =
BEFORE APPLYING ESP

            ---------------------------------------
      IPv6  |             | ext hdrs |     |      |
            | orig IP hdr |if present| TCP | Data |
            ---------------------------------------

                     AFTER APPLYING ESP

            ------------------------------------------------------------
      IPv6  | new* |new ext |   | orig*|orig ext |   |    | ESP   | ESP|
            |IP hdr| hdrs*  |ESP|IP hdr| hdrs *  |TCP|Data|Trailer| ICV|
            ------------------------------------------------------------
                                |<--------- encryption ---------->|
                            |<------------ integrity ------------>|

            * =3D if present, construction of outer IP hdr/extensions and
                modification of inner IP hdr/extensions is discussed in
                the Security Architecture document.

 
Thanks,
<= br>
Nalini Elkins
Inside Products, Inc.<= /div>
www.insidethestack.c= om
(831) 659-8360


From: Tero Kivinen <kivinen@iki.fi>
To: nalini.elkins@insidethestack.com Cc: "iesg@ietf.org" <i= esg@ietf.org>; "secdir@ietf.org" <secdir@ietf.org>; "draft-ietf-ip= pm-6man-pdm-option.all@tools.ietf.org" <draft-ietf-ippm-6man-pdm-option.= all@tools.ietf.org>
Sent: Monday, October 10, 2016 5:55 AM
Subject: Re: Secdir review of draft-ietf-ippm-6man-pdm-op= tion-05

nalini.elkins@insidethestack.com writes:=
> >There are most likely also other kind of attack= s, and as this is
> >service as ESP provides, it is= not for PDM to break it unless you
> >explictly sp= ell it out that this is meant to break property of the
&g= t; >ESP.
>
> OK. I am convin= ced. I will tell you though that some of us in IPPM,
>= we were quite excited (possibly naively) about being able to get
> some performance metrics for ESP.

Why do you think you can performance metrics for ESP in that cas= e?

> I wonder if it would be accep= table to say that PDM could be put into
> the Destinat= ion Option which precedes ESP if it is for an enterprise
= > customer who owns the infrastructure and wishes to manage the
> network that way. Otherwise, I can change to say that only t= he Dest
> Opt following ESP can be used.

I would recommend that if you use transport mode ES= P (i.e., where the
flow information would be leaked out f= rom the ESP if PDM is used) then
it must be put inside th= e ESP. If you use tunnel mode ESP, then there
migth be tw= o PDM headers in the packet, one in the inner packet inside
the ESP header (which has full IP header + destination options
including PDM option), and another one in the outer header, in wh= ich
case it would only cover the ESP as one flow (i.e., e= ach ESP SA
identified by the SPIs would get separate PDM = option).

I.e. in the Tunnel mode ESP y= ou want to defined the "5-tuple" as:

S= ADDR, DADDR, PROTC (=3DESP), SPI-IN, SPI-OUT

Btw, in the ICMP etc you do not have port numbers. Are ICMP framesrelated to the TCP flows matching the "5-tuple" of the TCP= flow or are
they counted as separate?
=
Anyways so if you define Tunnel mode ESP that way, then = you can get
some performance metrics from the ESP process= ing also. Then if the
enterprice is willing to sacrifice = the traffic flow confidentiality,
they can turn on the sa= -per-flow option of the IPsec implementation,
which will = create separate SA pair for each TCP/UDP etc flow, so then
they will get exact measurements.

In= normal case the Tunnel mode ESP will just provide performance
metrics for combination of all traffic inside the tunnel, not per
flow.

When using the Tr= ansport Mode ESP, then putting the PDM option inside
stil= l provides performance metrics for the host.

> >so the range is definately enough. The question is that = if the scale
> >is from -127 to 128, why do we even= need the Time Base?
>
> The tim= e base is so that one does not have to be committed to
&g= t;  picoseconds / milliseconds, etc. Even in your example, I believe>  you used "unit" or time base. Our thinking was = that we wanted
>  future proof so as to be able t= o handle very small values and very
>  large (as = may be needed for DTN, for example). We can see if we can
>  express years in picoseconds and see what happens. Then, the un= it
>  would always be picoseconds.

Having scale from -127 to 128 will provide quite goo= d future proof,
for at least for this universum.

Even if you used attoseconds as base, you coul= d express 10^13 years
which is still more than 1000 times= longer than the current age of the
universe...

> >3.5 Implementation Considerations
>
> >  The PDM destination= options extension header SHOULD be turned on by
> >= ;  each stack on a host node. It MAY also be turned on only in case o= f
> >  diagnostics needed for problem resolut= ion.
>
> > so it seems it is = on by default.
>
> Will change = to say that it MUST be turned on only by the stack and
&g= t; default value should be OFF.
>
&= gt; "The PDM destination options extension header MUST be turned on only>  by administrative action at each stack on a hos= t node. The default
>  mode for PDM is OFF."

Good.

> >Key management packets are usually in clear, as they are there b= efore
> >we have the actual keys we can use to prot= ect the messages. Also it is
> >not very difficult = to guess that 3rd and 4th message in port 500, are
> &= gt;the IKE AUTH packets, which will contain signatures.
&= gt;
> >Same thing with TLS.
>=
> >Attackers will knows which packets contain sig= natures. Currently
> >attackers usually send those = signature packets themselves, and measure
> >the ti= me it takes for the device to calculate response. They can also
> >send garbage packets, and detect how far in checking the pa= ckets got
> >by checking how long it took for the o= ther end to send error message
> >back.
>
> >All this kind of timing attacks are= usually considered hard, as the
> >network delays = cause big jitter on the timings, and they need to try
>= ; >multiple times, and average the response times to get the information=
> >they need.
>
> >This method will provide them easy way to bypass that issue.=
>
> OK.  So, are you sayi= ng that PDM is attack vector for TLS and not
> just fo= r ESP?

Yes, timing attacks are possibl= e against any crypto protocol. If the
protocol and algori= thms used in the protocol are specifically written
so tha= t they are protected against timing attacks, they will not work,
but lots of the implementations and protocols care more about the=
speed, than for the timing attacks, especially as launch= ing them over
longer distance gets harder and harder as o= ther things add random
times to measurements.

If this allows easy way to get exact timing infor= mation from the node
without any issues from the network = latencies and so on, this might
open completely new ways = to attack implementations and protocols.
Those attacks we= re not feasible before, but now they might be.

> No, obviously not. So, now I am not sure where we are. Is th= ere a
> complete objection to this draft or are there = changes which can be
> made which would make this acce= ptable?

Yes, I do not think there is a= nything that cannot be fixed, but there
are things that n= eeds fixing (from the security point of view):

1) Location of the PDM in ESP transport mode traffic.
2) Make sure this is turned off by default, and you do not want node=
  to respond incoming PDM options unless turned on= by adminstrator.
3) Add to security considerations secti= on aclear warnings about the
  new possibilities fo= r timing attacks if PDM is turned on.

= (not sure if I forgot something).

------=_Part_2227319_208211538.1477585468274-- From nobody Fri Oct 28 05:18:17 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E15129A6F; Fri, 28 Oct 2016 05:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=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 55aNkcSrAd4W; Fri, 28 Oct 2016 05:18:14 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7605129AA2; Fri, 28 Oct 2016 05:18:13 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u9SCI64F013871 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 28 Oct 2016 15:18:06 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u9SCI5Y7028140; Fri, 28 Oct 2016 15:18:05 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22547.16893.697871.116537@fireball.acr.fi> Date: Fri, 28 Oct 2016 15:18:05 +0300 From: Tero Kivinen To: In-Reply-To: <926572461.2227323.1477585468286@mail.yahoo.com> References: <22495.62038.771947.984586@fireball.acr.fi> <1264225155.363685.1474644268281@mail.yahoo.com> <22507.60901.665544.878052@fireball.acr.fi> <1130739157.4563724.1475509147203@mail.yahoo.com> <22523.36827.869306.70163@fireball.acr.fi> <926572461.2227323.1477585468286@mail.yahoo.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 11 min X-Total-Time: 127 min Archived-At: Cc: "iesg@ietf.org" , "draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-05: ESP Processing X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 12:18:16 -0000 nalini.elkins@insidethestack.com writes: > New Section 3.4 > > 3.4 Header Placement Using IPSec ESP Mode > > IPSec Encapsulating Security Payload (ESP) is defined in [RFC4303] and > is widely used. Section 3.1.1 of [RFC4303] discusses placement of > Destination Options Headers. > > The placement of PDM is different depending on if ESP is used in > tunnel or transport mode. > > 3.4.1 Using Transport Mode > > Below is the diagram from [RFC4303] discussing placement of headers. > > Note that Destination Options MAY be placed before or after ESP or > both. In transport mode, PDM MUST be placed after the ESP header so > as not to leak information. > > BEFORE APPLYING ESP > > --------------------------------------- > IPv6 | | ext hdrs | | | > | orig IP hdr |if present| TCP | Data | > --------------------------------------- > > AFTER APPLYING ESP > --------------------------------------------------------- > IPv6 | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP| > |IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV| > --------------------------------------------------------- > |<--- encryption ---->| > |<------ integrity ------>| > > * = if present, could be before ESP, after ESP, or both > > 3.4.2 Using Tunnel Mode > > Below is the diagram from [RFC4303] discussing placement of headers. > > Note that Destination Options MAY be placed before or after ESP or > both in both the outer set of IP headers and the inner set of IP > headers. > > In tunnel mode, PDM MAY be placed before or after the ESP header > or both. > > BEFORE APPLYING ESP > > --------------------------------------- > IPv6 | | ext hdrs | | | > | orig IP hdr |if present| TCP | Data | > --------------------------------------- > > AFTER APPLYING ESP > > ------------------------------------------------------------ > IPv6 | new* |new ext | | orig*|orig ext | | | ESP | ESP| > |IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV| > ------------------------------------------------------------ > |<--------- encryption ---------->| > |<------------ integrity ------------>| > > * = if present, construction of outer IP hdr/extensions and > modification of inner IP hdr/extensions is discussed in > the Security Architecture document. For tunnel mode you could add text noting, that as the sgw will make completely new IP packet, it means that PDM information for that packet does not contain any information from the inner packet, i.e. the PDM information will NOT be based on the TCP ports etc in the inner header, but will be specific to the ESP flow. If you want to see PDM information for the inner packet, the original host sending the inner packet needs to put PDM header in the tunneled packet, and then the PDM information will be specific for that TCP stream. So if the PDM header is part of "new ext hdrs*" then it specifies the ESP flow, and it will not be end to end, it will only between SGSs. If the PDM is part of the "orig ext hdrs*", then it will be end to end PDM header, and ESP processing does not modify it at all. This location is only place, where you can get end to end information about the flow. The first PDM header which is part of the ESP, will not separate TCP flows at all, as it is for the ESP packets, thus it might not be that useful, especially as there is no relation between the inbound ESP packet and outbound ESP packet. The inbound ESP packet might be TCP packet, and the tunneled packet is sent forward to the inner network, and then the next outbound ESP packet might be from some completely different host in different stream, and might be for example UDP DNS packet. Having PDM information between those packets does not really help debuggin at all. -- kivinen@iki.fi