From nobody Thu May 1 08:05:06 2014 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 8C3BB1A6F1E; Thu, 1 May 2014 07:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1398956399; bh=dYF689eGYFnCt+UaDV/aNA+pUP/7at7UzAa3XSX7vSg=; h=From:Date:To:Message-Id:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=dIAtWp4jh8qiW5tg9j9gs47geCaVEkfIwVv9G7VQN/Dnsmv7czTacEj90QFuTPrhs vT38viPmKWv3fZDNJVWAuQJDmPDXviqMdFTmYbnZBsBJgmYoPAuJXPn/V6Kz1cRvVj l8f2XKzzad//+7giIGFnw2dvZSZNPoKROfGFX2is= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6380C1A6F7C for ; Thu, 1 May 2014 07:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.153 X-Spam-Level: X-Spam-Status: No, score=-6.153 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBmEjlJXRMWB for ; Thu, 1 May 2014 07:59:55 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 592C51A6F1E for ; Thu, 1 May 2014 07:59:55 -0700 (PDT) Received: from 205-178-89-72.c3-0.nwb-ubr1.chi-nwb.il.cable.rcn.com ([205.178.89.72] helo=[192.168.1.100]) by jay.w3.org with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WfsSn-0000hg-1K; Thu, 01 May 2014 10:59:53 -0400 From: Ian Jacobs Date: Thu, 1 May 2014 09:59:54 -0500 To: new-work@ietf.org Message-Id: <65F59E4B-CADA-4EBB-8127-4E043A78030A@w3.org> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/new-work/sNC2yyjtit1H6-BgfXfrpbDQw6A X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Gv__ivS_elvMMW4GCocz42FOpJU X-Mailman-Approved-At: Thu, 01 May 2014 08:05:04 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: CSS Working Group (until 2014-05-29) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 14:59:59 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the charter of the CSS Working Group: http://www.w3.org/Style/2013/css-charter.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2014-05-29 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [1], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Bert Bos and Chris Lilley , Staff Contacts. Ian Jacobs, Head of W3C Communications [1] http://www.w3.org/Consortium/Member/List -- Ian Jacobs http://www.w3.org/People/Jacobs Tel: +1 718 260 9447 _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Thu May 1 21:25:37 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08AC71A09E9; Thu, 1 May 2014 21:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.701 X-Spam-Level: X-Spam-Status: No, score=-3.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2aPE_9I-oIB; Thu, 1 May 2014 21:25:32 -0700 (PDT) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id 216C41A09CA; Thu, 1 May 2014 21:25:32 -0700 (PDT) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s424PSbD020649; Fri, 2 May 2014 00:25:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1399004728; bh=p3I0NK6HAsQlTeRBdmGV1a6sOvlxCGPuuykeZIJR01I=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-ID:Content-Transfer-Encoding:MIME-Version: Sender:Reply-To; b=GyGJhZStVtkWo0v7bfBdKLJ/H0amu3yx3dBMcquk1lRaSGNlwrdo2sRjqqzVcgEQb 3sKQkRDO0AibZJgRPeCctBhs0qA6EjdBpEfZ+rm2s5neVyt+pdUw7sAfUL3vPC+mvR +qGjXtdHMRvH26iISKGoXh37ZkGJbeegEJQwkS78= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id s424PQSB017278; Fri, 2 May 2014 00:25:26 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0347.000; Fri, 2 May 2014 00:25:26 -0400 From: Chris Inacio To: Yoav Nir Thread-Topic: [secdir] Secdir review of draft-ietf-opsawg-large-flow-load-balancing-11 Thread-Index: AQHPYuiKVsIQX6Dr/kenvSMwEYGFopss+k8A Date: Fri, 2 May 2014 04:25:25 +0000 Message-ID: References: <0D637AC0-FD4F-4865-8D14-ADB75BAB072E@gmail.com> In-Reply-To: <0D637AC0-FD4F-4865-8D14-ADB75BAB072E@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.100.102] Content-Type: text/plain; charset="Windows-1252" Content-ID: <50A7F9D82C3B4849B44E623EA7E51842@sei.cmu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/PFtnrGyfMLlLnOceKRKKoUd-pv0 Cc: "draft-ietf-opsawg-large-flow-load-balancing.all@tools.ietf.org" , " IESG" , "" Subject: Re: [secdir] Secdir review of draft-ietf-opsawg-large-flow-load-balancing-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 04:25:34 -0000 >=20 On Apr 28, 2014, at 9:47 AM, Yoav Nir wrote: > Hi >=20 > 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. >=20 > tl;dr version: the document is ready. >=20 > I was a little surprised by the way the document is organized, and I=92m = not sure who the target audience is. On the one hand it is very verbose on = explanations (that=92s a good thing!) and I could very well understand it e= ven though I lack any background on the matter. On the other hand, the ord= er in which things are explained seems strange: >=20 > The introduction talks about large flows vs small flows, long-lived flows= vs short-lived flows, and Large flows vs Small flows (no, I=92m not repeat= ing myself, capitalize Large is different from lower-case large and in fact= means both =93large=94 and =93long-lived=94). But three things are totall= y missing: What is a flow? How large does a flow have to be to be considere= d =93large=94 (lower case), and how long must a flow continue to be conside= red =93long-lived=94. Even the terminology section (1.2) defines Large, Sma= ll and small again, but not what a flow is. These concepts are finally exp= lained in sections 4.1, 4.3.1, and 4.3.2. >=20 > The document describes how load balancing can be achieved by moving large= flows around between links and by removing loaded links from the hash tabl= e, so that Small (or actually un-classified) new flows will not go to overl= oaded links. This is an improvement over the assumed default that is static= ally assigning flows to links based on a hash. >=20 > The document has a short security considerations section that says that i= t does not impact the security of the Internet infrastructure or applicatio= ns. I tend to agree, because the parts of the network where these protocols= tends to be mostly stateless, so moving flows from one component to anothe= r should not make a difference. It would be different if there were suppose= d to be firewalls on the nodes. > The security considerations also says that load balancing might help in r= esisting DoS attacks, for example if an attacker can create traffic where t= he hash would collide with some Large flow. With load balancing either the = attacker=92s flow or the Large flow is moved, eliminating the contention. A= gain, I tend to agree, although this will allow a more powerful attacker to= overload all the links, not just the ones they can target with the hash fu= nction. Still, an attacker powerful enough to overload all the links is lik= ely to be able to create traffic that collides with all links anyway. >=20 > I don=92t think there=92s anything missing from the security consideratio= ns. >=20 > Hope this helps >=20 > Yoav >=20 >=20 > 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. After reading Yoav=92s review, I was curious about this document. I would agree, roughly, with Yoav=92s comments on flow description. The ta= ble at the beginning of the document (section 2) I feel would be much bette= r served with its Y axis labeled as bandwidth, and not flow scale. >From a technical point of view, the only issue I have with the document is = that I feel that it misses how long lived flows are identified. I understa= nd the technical challenge that this presents: how should a middle box unde= rstand/guess the intention of the end points for the duration of a flow? T= here are likely to be some heuristics that could be developed/included that= would be likely to have some indication as to the lifetime. For example, = SSH keep alives with an otherwise minimal (smallest of small) flow, or VPN = identification. (Of course with VPN, the flow can quickly switch from smal= l to large and back to small.) Devices with enhanced flow inspection can o= bviously label the traffic via inspection. I have 2 possible security considerations: Assuming the multi paths might lead to equal but diverse Internet connectio= ns (anycast), does moving flows between paths provide an attacker who has a= lready penetrated an enterprise, the possibility to further evade detection= of border monitoring devices via flow flopping? Possibly evading stateful= inspection at the border? And less likely: From a security point of view, sophisticated attackers, pe= rsistent attackers, like to map their target environment (hosts and network= ) before attempting their actual attack (DoS, exfiltration, destruction, et= c.). Does the movement of flows across otherwise redundant links expose mo= re network structure, especially with respect to traceroute for an attacker= . =20 -- Chris Inacio inacio@cert.org From nobody Fri May 2 04:08:59 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987681A6F07 for ; Fri, 2 May 2014 04:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAVbKbaa9FCG for ; Fri, 2 May 2014 04:08:56 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 30CEA1A084E for ; Fri, 2 May 2014 04:08:54 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.7) with ESMTP id s42B8nPc005962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 2 May 2014 14:08:49 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.7/Submit) id s42B8mi8019754; Fri, 2 May 2014 14:08:48 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21347.31936.650955.900700@fireball.kivinen.iki.fi> Date: Fri, 2 May 2014 14:08:48 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/azgdUyydFExOqyTgUVQoMxhHlw4 Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 02 May 2014 11:08:58 -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 2014-05-15 Reviewer LC end Draft Leif Johansson T 2014-04-15 draft-ietf-ccamp-rsvp-te-eth-oam-ext-12 Stephen Kent TR2014-04-24 draft-ietf-l2vpn-vpls-inter-domain-redundancy-06 Tero Kivinen T 2014-04-28 draft-ietf-bfd-mib-19 Warren Kumari T 2014-04-28 draft-ietf-bfd-tc-mib-07 Ben Laurie T 2014-04-25 draft-ietf-rtcweb-use-cases-and-requirements-14 Matt Lepinski T 2014-04-25 draft-ietf-salud-alert-info-urns-12 Eric Osterweil T 2014-05-12 draft-ietf-ippm-2330-update-04 Vincent Roca T 2014-04-09 draft-ietf-mpls-psc-updates-05 For telechat 2014-05-29 Magnus Nystrom T 2014-05-16 draft-pal-eidr-urn-01 Last calls and special requests: Tobias Gondrom 2014-03-27 draft-ietf-pwe3-p2mp-pw-requirements-07 Sam Hartman 2014-04-08 draft-ietf-l2vpn-vpls-ldp-mac-opt-11 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-06 Julien Laganier E 2013-11-21 draft-ietf-websec-key-pinning-12 Julien Laganier 2014-04-29 draft-ietf-dhc-dhcpv4-over-dhcpv6-07 Alexey Melnikov 2014-05-07 draft-ietf-appsawg-uri-get-off-my-lawn-04 Russ Mundy 2014-03-24 draft-mahalingam-dutt-dcops-vxlan-09 Russ Mundy 2014-05-06 draft-ietf-mpls-extended-admin-group-06 Sandy Murphy 2013-12-17 draft-ietf-netmod-iana-timezones-03 Sandy Murphy 2014-05-02 draft-ietf-ipsecme-esp-ah-reqts-07 Hilarie Orman 2014-05-14 draft-ietf-cuss-sip-uui-isdn-08 Radia Perlman 2014-05-12 draft-ietf-mpls-ldp-ip-pw-capability-07 Vincent Roca 2014-02-25 draft-ietf-sidr-policy-qualifiers-01 Joe Salowey 2014-05-29 draft-moonesamy-sshfp-ed25519-01 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-11 -- kivinen@iki.fi From nobody Fri May 2 09:19:32 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356611A6F64 for ; Fri, 2 May 2014 09:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDKw_ytOXF6K for ; Fri, 2 May 2014 09:19:29 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id C27651A084B for ; Fri, 2 May 2014 09:19:28 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id f8so2473800wiw.1 for ; Fri, 02 May 2014 09:19:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=xe7aW4XtYF6qwwLaFdUW0dXK+A1aaUY81bP/IUcp5MI=; b=RZgjbl3Mh61gWA2iUTj2hIDKxuAulxs6fwvxOrBm3rT71b9jqt9wTJJNsG1LFw1hRF Z3vEDITlPI84zPe2nvyfVBrudpaEdc4IlCeTXCVt4ETPZL0w+n36QdwLO2yE7mA38IZe LWJpP1B0kQFgPLDmSDJ8hkR46oxN+RCXaa164Er4F0bQ+GXGLQPaQAZVEk6952lfMeEp VdTBZNf/RYvB4Z+p+ucFxPRbRemgqDOTM8p/4HVszrWnSTCsrpqLb/0E7ryAWqtH1OQJ WHhH9Mm1JAMfhwqyLUErSn/7b1cIJjV17Gyipj76dD+BWeZeziyBF0XZZscJXjUb+iZp 5maA== X-Gm-Message-State: ALoCoQmSP30PD+5Wi1SWSKJ4nMBht1GLE3oZ0xwU7ruAE4GRci3pS4UYPAEmya6+4Llnz+MvBbLv MIME-Version: 1.0 X-Received: by 10.181.5.6 with SMTP id ci6mr3633396wid.39.1399047566005; Fri, 02 May 2014 09:19:26 -0700 (PDT) Received: by 10.194.54.162 with HTTP; Fri, 2 May 2014 09:19:25 -0700 (PDT) X-Originating-IP: [66.84.81.44] Date: Fri, 2 May 2014 12:19:25 -0400 Message-ID: From: Warren Kumari To: "secdir@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/mD8M2InCxnLav86Ca0QT1LuCLyc Subject: [secdir] Secdir review of draft-ietf-bfd-tc-mib-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 16:19:30 -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. tl;dr version: the document is ready. This document does not define any management objects, it simply defines a set of textual conventions which may be used by other BFD MIB modules. No realistic security issues here, move along.... W From nobody Tue May 6 08:37:08 2014 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 786301A01C1; Mon, 5 May 2014 14:32:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1399325555; bh=k9NaWW92FqPvqnUhFHnQ3Lyq/riff/62lIcBXBZM6S0=; h=From:Date:To:Message-Id:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=tssIS8iFgMpDMs4ZyXOZCDqgoGyU/OGBCsVZAwyYnh03kb1KkVdYeTv7m5IxHfB0S K+ymkCJuJzXuy5LxXyrM/W02uj+2fPP2XXgO7FGXo3K0kdjCrpMoELu8UK1jUFICWw 2npEANOfag+mQ4BqJvFdbJFHr9UDSswib2bKMCMA= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07141A01C1 for ; Mon, 5 May 2014 14:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.654 X-Spam-Level: X-Spam-Status: No, score=-5.654 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6djxKGABmuBA for ; Mon, 5 May 2014 14:32:31 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 1690F1A011A for ; Mon, 5 May 2014 14:32:30 -0700 (PDT) Received: from 205-178-89-72.c3-0.nwb-ubr1.chi-nwb.il.cable.rcn.com ([205.178.89.72] helo=[192.168.1.100]) by jay.w3.org with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WhQUt-0005w8-3V; Mon, 05 May 2014 17:32:27 -0400 From: Ian Jacobs Date: Mon, 5 May 2014 16:32:32 -0500 To: "new-work@ietf.org" Message-Id: <0F7671DB-A489-4444-B912-C03C5B5AB03B@w3.org> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/new-work/JvBS2PNDK7drV6GPPC5T3H3tT_Y X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/wcIJ0ED9idZhUh29A4hWUqM4l3I X-Mailman-Approved-At: Tue, 06 May 2014 08:36:59 -0700 Subject: [secdir] [new-work] Work in Progress on a W3C Payments Interest Group Charter (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: Mon, 05 May 2014 21:32:35 -0000 Hello, Based on the success of W3C's Web & Payment Workshop at generating interest and ideas (see report [1]), work has begun to develop a charter for a new Payments Interest Group. We expect the IG to develop use cases and requirements for interoperable Web Payments, and to identify whether those requirements might be satisfied in existing or new Working Groups. The draft charter is being developed within a Community Group: http://www.w3.org/community/webpaymentsigcharter/ Members and public are invited to join the CG to express support and share ideas. For more information, please contact Stephane Boyera or Wendy Seltzer . Ian Jacobs, Head of W3C Communications [1] http://www.w3.org/2013/10/payments/final_report.html -- Ian Jacobs http://www.w3.org/People/Jacobs Tel: +1 718 260 9447 _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Thu May 8 02:32:13 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9DE1A04C5 for ; Thu, 8 May 2014 02:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pI-d9YXFLtge for ; Thu, 8 May 2014 02:32:10 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0088A1A03B1 for ; Thu, 8 May 2014 02:32:09 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s489W21g009030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 8 May 2014 12:32:02 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s489W1bk007711; Thu, 8 May 2014 12:32:01 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21355.20241.875759.443267@fireball.kivinen.iki.fi> Date: Thu, 8 May 2014 12:32:01 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 1 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/J-H0DSJOpwmZFa9QLMpaQv0NN3A Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 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, 08 May 2014 09:32:12 -0000 Lots of people have documents to be reviewed for next weeks telechat (including me). Lets try to get those reviews done as soon as possible... Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Zach Shelby is next in the rotation. For telechat 2014-05-15 Reviewer LC end Draft Leif Johansson T 2014-04-15 draft-ietf-ccamp-rsvp-te-eth-oam-ext-12 Stephen Kent TR2014-04-24 draft-ietf-l2vpn-vpls-inter-domain-redundancy-06 Tero Kivinen T 2014-04-28 draft-ietf-bfd-mib-19 Ben Laurie T 2014-04-25 draft-ietf-rtcweb-use-cases-and-requirements-14 Matt Lepinski T 2014-04-25 draft-ietf-salud-alert-info-urns-12 Alexey Melnikov T 2014-05-07 draft-ietf-appsawg-uri-get-off-my-lawn-04 Russ Mundy T 2014-05-06 draft-ietf-mpls-extended-admin-group-06 Sandy Murphy T 2014-05-02 draft-ietf-ipsecme-esp-ah-reqts-07 Eric Osterweil T 2014-05-12 draft-ietf-ippm-2330-update-04 Vincent Roca T 2014-04-09 draft-ietf-mpls-psc-updates-05 For telechat 2014-05-29 Magnus Nystrom T 2014-05-16 draft-pal-eidr-urn-01 Last calls and special requests: Tobias Gondrom 2014-03-27 draft-ietf-pwe3-p2mp-pw-requirements-07 Sam Hartman 2014-04-08 draft-ietf-l2vpn-vpls-ldp-mac-opt-11 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-06 Julien Laganier E 2013-11-21 draft-ietf-websec-key-pinning-12 Julien Laganier 2014-04-29 draft-ietf-dhc-dhcpv4-over-dhcpv6-07 Russ Mundy 2014-03-24 draft-mahalingam-dutt-dcops-vxlan-09 Sandy Murphy 2013-12-17 draft-ietf-netmod-iana-timezones-03 Hilarie Orman 2014-05-14 draft-ietf-cuss-sip-uui-isdn-08 Radia Perlman 2014-05-12 draft-ietf-mpls-ldp-ip-pw-capability-07 Vincent Roca 2014-02-25 draft-ietf-sidr-policy-qualifiers-01 Joe Salowey 2014-05-29 draft-moonesamy-sshfp-ed25519-01 Yaron Sheffer 2014-05-21 draft-ietf-mpls-ldp-hello-crypto-auth-05 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-11 -- kivinen@iki.fi From nobody Thu May 8 10:04:33 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98F61A00D3 for ; Thu, 8 May 2014 10:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJ95ptR8Gjtc for ; Thu, 8 May 2014 10:04:29 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A7DA91A00DC for ; Thu, 8 May 2014 10:04:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B57EBBE51; Thu, 8 May 2014 18:04:24 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBctAW9qHomt; Thu, 8 May 2014 18:04:23 +0100 (IST) Received: from [190.112.52.71] (unknown [190.112.52.71]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0984DBE47; Thu, 8 May 2014 18:04:22 +0100 (IST) Message-ID: <536BB915.6090708@cs.tcd.ie> Date: Thu, 08 May 2014 18:04:21 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: secdir-secretary@mit.edu, secdir@ietf.org References: <21355.20241.875759.443267@fireball.kivinen.iki.fi> In-Reply-To: <21355.20241.875759.443267@fireball.kivinen.iki.fi> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/dpyavtdqlF5xdSU878VyMr7sxSk Subject: Re: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 17:04:31 -0000 On 08/05/14 10:32, Tero Kivinen wrote: > Lots of people have documents to be reviewed for next weeks telechat > (including me). Lets try to get those reviews done as soon as > possible... And thanks in advance to those of you who do get them done, it really does help. Cheers, S. From nobody Fri May 9 06:06:15 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0E51A02AD; Fri, 9 May 2014 06:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X25UJkwS-VEX; Fri, 9 May 2014 06:06:09 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id B5F511A02AC; Fri, 9 May 2014 06:06:08 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s49D618F020837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 9 May 2014 16:06:01 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s49D60TS013175; Fri, 9 May 2014 16:06:00 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21356.53943.876174.826843@fireball.kivinen.iki.fi> Date: Fri, 9 May 2014 16:05:59 +0300 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org, draft-ietf-bfd-mib.all@tools.ietf.org X-Edit-Time: 4 min X-Total-Time: 3 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/CEHxkWE-IpTJP3lEh4xkQ7ytljc Subject: [secdir] Secdir review of draft-ietf-bfd-mib-19.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 13:06:11 -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 is document specifies the MIB for the Bidirectional Forwarding Detection. There list of sensitive or vulnerable objects in the security considerations section and the security considerations section recommends ysing SNMPv3 including full support for the SNMPv3 cryptographic mechanisms "for authentication and privacy". I think this document is Ready. -- kivinen@iki.fi From nobody Sun May 11 11:18:13 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970C71A0337; Sun, 11 May 2014 11:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2HFu0BiXwQY; Sun, 11 May 2014 11:18:03 -0700 (PDT) Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) by ietfa.amsl.com (Postfix) with ESMTP id D5B1A1A0334; Sun, 11 May 2014 11:18:03 -0700 (PDT) Received: from in02.mta.xmission.com ([166.70.13.52]) by out03.mta.xmission.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1WjYJv-0005KU-91; Sun, 11 May 2014 12:17:55 -0600 Received: from [72.250.219.84] (helo=sylvester.rhmr.com) by in02.mta.xmission.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1WjYJs-0001gH-F9; Sun, 11 May 2014 12:17:55 -0600 Received: from sylvester.rhmr.com (localhost [127.0.0.1]) by sylvester.rhmr.com (8.14.4/8.14.4/Debian-2ubuntu1) with ESMTP id s4BIHXUf012320; Sun, 11 May 2014 12:17:33 -0600 Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id s4BIHWWk012198; Sun, 11 May 2014 12:17:32 -0600 Date: Sun, 11 May 2014 12:17:32 -0600 Message-Id: <201405111817.s4BIHWWk012198@sylvester.rhmr.com> From: "Hilarie Orman" To: iesg@ietf.org, secdir@ietf.org, draft-ietf-cuss-sip-uui-isdn@tools.ietf.org X-XM-AID: U2FsdGVkX18FEWehcIgCZdy5oEimsNW7 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, draft-ietf-cuss-sip-uui-isdn@tools.ietf.org X-Spam-Relay-Country: X-SA-Exim-Version: 4.2.1 (built Wed, 14 Nov 2012 13:58:17 -0700) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/oABRTHxf4ELBdaxmz5dQ9R5O1iA Subject: [secdir] Security review of draft-ietf-cuss-sip-uui-isdn-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 11 May 2014 18:18:05 -0000 Security review of draft-ietf-cuss-sip-uui-isdn-08 Interworking ISDN Call Control User Information with SIP 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. This document defines a usage (a new package) of the SIP User-to-User header field to enable interworking with ISDN services transporting the ITU-T DSS1 User-user information data element and is limited to the ISDN UUS1 implicit supplementary service. Because the element may contain information related to user privacy, one should consider the impact of transmitting it in this context. The document begins by noting the the User-to-User header field is defined in "A Mechanism for Transporting User to User Call Control Information in SIP" (draft-ietf-cuss-sip-uui-16). That document notes security requirements deriving from an earlier document, RFC6567 SIP UUI Reqs, which states: The next three requirements capture the UUI security requirements. REQ-13: The mechanism will allow integrity protection of the UUI. ... REQ-14: The mechanism will allow end-to-end privacy of the UUI. ... REQ-15: The mechanism will allow both end-to-end and hop-by-hop security models. ... The document under review and draft-ietf-cuss-sip-uui-16 note that because ISDN offers only hop-by-hop security, the SIP UAs must provide any necessary authenticity, integrity and privacy protection for sensitive parts of the UUI. It is not clear to me if the SIP endpoints are aware of intermediary ISDNs, nor if they might be unaware of the ISDN transit and thus misled into thinking that the SIP infrastructure provided adequate security controls for the protection of UUI data. The document gives the guidance that "data that is used to assist in selecting which SIP UA should respond to the call would not be expected to carry any higher level of security than a media feature tag". I'm not sure how to interpret that. When should the "level of security" be expected to be lower than a media feature tag? Or does it mean something else, like: (a) the data should not be more sensitive than that in a media feature tag or (b) the data should be protected (authenticity, integrity, privacy) to at least the level of a media feature tag or (c) the UUI data and the media feature tag data are so similar that they should have the same level of protection? That's my impression from reading over the security considerations. My apologies if I've missed the point. Hilarie From nobody Sun May 11 14:56:25 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5A31A0376; Sun, 11 May 2014 14:56:20 -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 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 ajaau6KdD3Jt; Sun, 11 May 2014 14:56:17 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C58CB1A0375; Sun, 11 May 2014 14:56:16 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi2so3571662wib.17 for ; Sun, 11 May 2014 14:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=OHrmio9z+vis4e9EFVf1X/JyEgltml1vq55mpMHogFs=; b=XneW+tje68pMQJxAwoJ14J322QX6S44W6KFuSfQFo9+KAKSuWLbwuR8KE7HH/IUKqq P6HHCsQvObPcc0YhW1dSAalxaM18E7eXi2fV0KpUtilOMXXPDCNbNh+FGPNC6BlEb6un 0lKjJg3CUL9O+4v0eaDSjwM9wNQGsAW56D4KDU/6L2n19jf5l3eotP900U/b3Mj8a6UD Nqw6bxAl8c86E+ynaKH2My7yJJlrl0/MeJEn1Kk7Ct2sfd7GSOyDp0eZ4ZBVshma8h03 fuun//4AOj0Ctfb3ReN+AR/AgE0ccfiM+wH8PDIVUB2eFsgtgeeKRuZdLYBAXJjllnbo OgqQ== MIME-Version: 1.0 X-Received: by 10.180.75.110 with SMTP id b14mr12822500wiw.43.1399845370549; Sun, 11 May 2014 14:56:10 -0700 (PDT) Received: by 10.216.100.197 with HTTP; Sun, 11 May 2014 14:56:10 -0700 (PDT) Date: Sun, 11 May 2014 17:56:10 -0400 Message-ID: From: Matthew Lepinski To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-radext-dtls.all@tools.ietf.org, draft-ietf-salud-alert-info-urns.all@ietf.org Content-Type: multipart/alternative; boundary=f46d043be2280d5bc404f926e6ef Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Y6R3DQpZAMgwxp82_NDO2-Dugu0 Subject: [secdir] SECDIR Review of Draft-ietf-salud-alert-info-urns-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2014 21:56:20 -0000 --f46d043be2280d5bc404f926e6ef 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. The base Sip specification (RFC 3261) includes an Alert-Info header field that may reference an audio file to be rendered to the user as a ring tone or ringback tone. Draft-ietf-salud-alert-info-urns updates RFC 3261 to allow the Alert-info feel to include a URN that indicates the type of ring tone or ringback tone that is appropriate for the current call, and then the user agent can use this URN to select an appropriate alert to render to the user (e.g., based on the capabilities of user's device and the user's preferences). >From a security point of view, the mechanism specified in this document is very desirable, since it eliminates the potential security concerns associated with a request to fetch and render an arbitrary audio file provided by a (potentially untrusted) remote system. This document is generally ready for publication. I agree with the authors that specified usage of the new alert URN namespace does not raise significant new security concerns. However, I have one minor concern about the security considerations text, which I discuss below. The authors correctly note that the use particular alert indicators (that might reasonably be provisioned within this namespace) may introduce privacy concerns. For example, the alert-info value might reasonably include information about the calling party, the calling party's location (e.g., local vs international) or the calling party's device. (Note that in many cases there will be as much or more information about the calling party in other SIP headers, but it is definitely worth noting that this is a header field where privacy-relevant information may reside.) Therefore, the security considerations text goes on to say "Such provision SHALL always be explicitly authorized by the party (caller or callee) the information in the 'alert' URN refers to." I find the above text somewhat confusing, and I would appreciate it the authors could add a bit of text to clarify what they mean. Does this sentence mean that if I am implementing a User-Agent that I MUST NOT include any URN in the alert-info field without an explicit authorization from the user? Or perhaps it means that certain categories of alert URNs (the privacy-relevant ones) MUST NOT be included in the alert-info field without an explicit authorization from the user? (If this is the case, then obviously a bit of guidance is needed with regards to which types of alert URNs require explicit user authorization). Furthermore, I believe that the above sentence means that if I am implementing a proxy that I MUST NOT add any alert URN to an outgoing (or incoming) call without explicit authorization from the user. (Or again, perhaps it only means certain privacy-relevant alert URNs). I think this paragraph would be more clear if there were separate normative statement for the behavior of proxies and user agents. That is, for these type of privacy considerations, I think it is very helpful to be very clear/explicit about what information various entities are allowed to put into this header field (without authorization from the user). As I final note, it might be reasonable to add a sentence that reminds implementers that due to the potential privacy implications of the alert-info header field that when this header is included (or perhaps when certain categories of alert URNs are placed in this header field), the SIP message SHOULD be protected via TLS. However, I understand that: (1) There are a number of practical impediments to the use of TLS to protect SIP traffic; and (2) Given the privacy-relevant information that is likely contained in other SIP headers, the recommendation to use TLS is in now ways specific to the presence of the alert-info field. Therefore, although I think a reminder to use TLS when possible might be appropriate, I can understand why the authors might reasonably chose to leave out such text. --f46d043be2280d5bc404f926e6ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security dir= ectorate's ongoing effort to review all IETF documents being processed = by the IESG. These comments were written primarily for the benefit of the s= ecurity area directors. Document editors and WG chairs should treat these c= omments just like any other last call comments.

The base Sip specification (RFC 3261) includes= an Alert-Info header field that may reference an audio file to be rendered= to the user as a ring tone or ringback tone. Draft-ietf-salud-alert-info-u= rns updates RFC 3261 to allow the Alert-info feel to include a URN that ind= icates the type of ring tone or ringback tone that is appropriate for the c= urrent call, and then the user agent can use this URN to select an appropri= ate alert to render to the user (e.g., based on the capabilities of user= 9;s device and the user's preferences).

From a security point of view, the mechanism s= pecified in this document is very desirable, since it eliminates the potent= ial security concerns associated with a request to fetch and render an arbi= trary audio file provided by a (potentially untrusted) remote system.

This document is generally ready for publicati= on. I agree with the authors that specified usage of the new alert URN name= space does not raise significant new security concerns. However, I have one= minor concern about the security considerations text, which I discuss belo= w.=C2=A0

The authors correctly note that the use partic= ular alert indicators (that might reasonably be provisioned within this nam= espace) may introduce privacy concerns. For example, the alert-info value m= ight reasonably include information about the calling party, the calling pa= rty's location (e.g., local vs international) or the calling party'= s device. (Note that in many cases there will be as much or more informatio= n about the calling party in other SIP headers, but it is definitely worth = noting that this is a header field where privacy-relevant information may r= eside.)

Therefore, the security considerations text go= es on to say "Such provision SHALL always be explicitly authorized by = the party (caller or callee) the information in the 'alert' URN ref= ers to."=C2=A0

I find the abo= ve text somewhat confusing, and I would appreciate it the authors could add= a bit of text to clarify what they mean. Does this sentence mean that if I= am implementing a User-Agent that I MUST NOT include any URN in the alert-= info field without an explicit authorization from the user? Or perhaps it m= eans that certain categories of alert URNs (the privacy-relevant ones) MUST= NOT be included in the alert-info field without an explicit authorization = from the user? (If this is the case, then obviously a bit of=C2=A0guidance= =C2=A0is needed with regards to which types of alert URNs require explicit = user authorization).

Furthermore, I believe that the above sentence means that= if I am implementing a proxy that I MUST NOT add any alert URN to an outgo= ing (or incoming) call without explicit authorization from the user. (Or ag= ain, perhaps it only means certain privacy-relevant alert URNs). I think th= is paragraph would be more clear if there were separate normative statement= for the=C2=A0behavior=C2=A0of proxies and user agents.

That is, for these type of privacy considerations, I thin= k it is very helpful to be very clear/explicit about what information vario= us entities are allowed to put into this header field (without authorizatio= n from the user).=C2=A0

As I final note, it might be reasonable to add a=C2=A0sen= tence that reminds=C2=A0implementers=C2=A0that=C2=A0due to the potential pr= ivacy implications of the alert-info header field that when this header is = included (or perhaps when certain categories of alert URNs are placed in th= is header field), the SIP message SHOULD be protected via TLS. However, I u= nderstand that: (1) There are a number of practical impediments to the use = of TLS to protect SIP traffic; and (2) Given the privacy-relevant informati= on that is likely contained in other SIP headers, the recommendation to use= TLS is in now ways specific to the presence of the alert-info field. There= fore, although I think a reminder to use TLS when possible might be appropr= iate, I can understand why the authors might reasonably chose to leave out = such text.
--f46d043be2280d5bc404f926e6ef-- From nobody Mon May 12 06:44:02 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3873B1A0716; Mon, 12 May 2014 06:43:58 -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 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 ubVayc2DDJ-1; Mon, 12 May 2014 06:43:56 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 083461A029C; Mon, 12 May 2014 06:43:55 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id n15so7393890lbi.5 for ; Mon, 12 May 2014 06:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=jdgp2QHQvRKJUh413vcI5P0wS3dsCIPzKhQQJlC3mW0=; b=dcO0dBwMb1GQPdxeHHBvw4zaQqUP3814UZ7nv7v7Gr1KtRy4J2Wiw/O9JF8znztfMz eLAYD71eP00cB1uSikWGn8U0pdgx9FuxBACkQW0hDJQVQreR6lr/QegZeHkFgot9lFkR 27F872TzkBoRcYbpJLVgsf4PIVfGRQVDokvHI2dV7WTTPnTr1BJZ3ov2JrtpYPODJg83 YWeXiO+MmWXUtq6lZEsF/jTHw4PYMz6fG66zILV/CyME52y/q3rhhw/pNm3KIckpx58i NJ2NYv3TozfyP5BJlE2tkjMzebtcIQuHDkrxKXlC2rgN03yT7tvFlJqsgRTqbQHYn8gC oxpQ== MIME-Version: 1.0 X-Received: by 10.112.85.167 with SMTP id i7mr8428739lbz.32.1399902229333; Mon, 12 May 2014 06:43:49 -0700 (PDT) Received: by 10.112.199.2 with HTTP; Mon, 12 May 2014 06:43:49 -0700 (PDT) Date: Mon, 12 May 2014 06:43:49 -0700 Message-ID: From: Radia Perlman To: The IESG , draft-ietf-mpls-ldp-ip-pw-capability.all@ietf.org, "secdir@ietf.org" Content-Type: multipart/alternative; boundary=001a11346dde198a2104f93423ed Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/sbBj9sPzgWuoD8fkZTvbjIRF4NM Subject: [secdir] secdir review of draft-ietf-mpls-ldp-ip-pw-capability-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 13:43:58 -0000 --001a11346dde198a2104f93423ed 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 is about how label switching routers (LSRs) can tell their neighbor not to advertise state about unsupported applications. This apparently was not thought of originally, and was introduced in RFC 5561. So this document introduces a way to turn off advertisement of earlier applications (before RFC 5561). As specified in the security considerations section, this certainly does not introduce any security issues. If the neighbor doesn't understand the TLV , it will continue to advertise unwanted information, and apparently what was done before this was through configuration. This document allows explicit advertisement of disinterest in applications before RFC 5561. This is an improvement over configuration.. There's a lot of awkward English here and there, but i assume it will be fixed by the RFC editor. For example, in the last line of the abstract " which would have otherwise be advertised over the established LDP session" "be" should be "been". Radia --001a11346dde198a2104f93423ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have=C2=A0reviewed=C2=A0this document as p= art of the security directorate's
ongoing effort = to=C2=A0review=C2=A0all IETF documents being p= rocessed by the
IESG. =C2=A0The= se comments were written primarily for the benefit of the
security area directors. =C2=A0Document e= ditors and WG chairs should treat
these comments = just like any other last call comments.

This document is about how= label switching routers (LSRs) can tell their neighbor not to advertise st= ate about unsupported applications. =C2=A0This apparently was not thought o= f originally, and was introduced in RFC 5561. =C2=A0So this document introd= uces a way to turn off advertisement of earlier applications (before RFC 55= 61).

As specified in the security c= onsiderations section, this certainly does not introduce any security issue= s. =C2=A0If the neighbor doesn't understand the TLV , it will continue = to advertise unwanted information, and apparently what was done before this= was through configuration. =C2=A0This document allows explicit advertiseme= nt of disinterest in applications before RFC 5561. =C2=A0This is an improve= ment over configuration..

There's a lot of awkward English here and there, but = i assume it will be fixed by the RFC editor. =C2=A0For example, in the last= line of the abstract
" which 
   would have otherwise be=
 advertised over the established LDP session"
"be" should be "been".



Radia
<= pre style=3D"color:rgb(0,0,0);word-wrap:break-word;white-space:pre-wrap">
--001a11346dde198a2104f93423ed-- From nobody Mon May 12 09:06:28 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F1C1A075A; Mon, 12 May 2014 09:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQLMLf__x5BN; Mon, 12 May 2014 09:06:07 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0C21A0755; Mon, 12 May 2014 09:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1399910755; d=isode.com; s=selector; i=@isode.com; bh=WYvY0L/PpLVma0HKtxj1/HFMzwdMX8k1ePYX0ixyYVs=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=f57/tmMTkHTi0J5SbiPaBmG4lPdylBIL1421FuUnZYgjEqAFdIB5ndJBEKjzRpU081JVWJ WzeiSQqyyQmIkvTdjtWHd/xGOHsKQPMWX1Zd6yayr51VfVQnDyDgHjSD3x/VzQMfIgnhUm YvysZydBKQEIEZ8sPe8sMeKmcbbLQUE=; Received: from [192.168.0.7] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 12 May 2014 17:05:55 +0100 Message-ID: <5370F185.7020703@isode.com> Date: Mon, 12 May 2014 17:06:29 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 To: iesg@ietf.org, secdir@ietf.org, draft-ietf-appsawg-uri-get-off-my-lawn.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/UPutJxHMypRQ65Ge105hk-ZQiVE Subject: [secdir] Secdir review of draft-ietf-appsawg-uri-get-off-my-lawn-04.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 16:06:11 -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 talks about the practice of mandating some forms of URI sub-structure in documents, which use existing URI schemes. This document is arguing that such practice is inappropriate, because that essentially usurps ownership or URI sub-structure from URI owners. This document further describes some acceptable alternatives for use in standards. I agree with the Security Considerations that this document does not introduce new protocol artifacts with security considerations. I think this document is Ready. From nobody Mon May 12 10:06:27 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541AF1A0741; Mon, 12 May 2014 10:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.2 X-Spam-Level: X-Spam-Status: No, score=-7.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tu-isbSrbJ8; Mon, 12 May 2014 10:06:20 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBB41A0740; Mon, 12 May 2014 10:06:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,1036,1389740400"; d="scan'208,217";a="61530708" Received: from unknown (HELO [192.168.43.137]) ([193.253.169.243]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 12 May 2014 19:06:10 +0200 From: Vincent Roca Content-Type: multipart/alternative; boundary=Apple-Mail-39-700189312 Date: Mon, 12 May 2014 19:03:04 +0200 Message-Id: To: IESG , draft-ietf-mpls-psc-updates@tools.ietf.org, secdir@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/3tdmM6UuCCrrtXrV5UHQ_zzl1ZY Subject: [secdir] Secdir review of draft-ietf-mpls-psc-updates-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 17:06:22 -0000 --Apple-Mail-39-700189312 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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. IMHO, the document is Almost ready. The author claims this document "raise[s] no new security concerns". I think the author is right, however I have two comments: - it's preferable to mention explicitely that RFC 6378 provides the = baseline security discussion and that it also applies to the present document. - Making sure an implementation behaves correctly in front of malformed messages is typically something that should be mentioned/discussed in = the Security Section. This is the case in section 2.3 "Error handling". Can an attacker through malformed/unexpected messages (e.g., with = fuzzing) launch a DoS? I don't suggest to move section 2.3 in the Security Discussion = section, but rather to add a sentence in the Security Section explaining that this = document in section 2.3 also clarifies how to react in front of = malformed/unexpected messages (which is essential from a security point of view). Cheers, Vincent= --Apple-Mail-39-700189312 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
IMHO, the document is Almost = ready.


The = author claims this document "raise[s] no new security = concerns".
I think the author is right, however I have two = comments:

- it's preferable to mention = explicitely that RFC 6378 provides the baseline
  = security discussion and that it also applies to the present = document.

- Making sure an implementation = behaves correctly in front of malformed
  messages is = typically something that should be mentioned/discussed in = the
  Security Section. This is the case in section 2.3 = "Error handling".
  Can an attacker through = malformed/unexpected messages (e.g., with fuzzing)
  = launch a DoS?
  I don't suggest to move section 2.3 in = the Security Discussion section, but
  rather to add a = sentence in the Security Section explaining that this = document
  in section 2.3 also clarifies how = to react in front of malformed/unexpected
  messages = (which is essential from a security point of = view).

Cheers,

&nb= sp;   Vincent
= --Apple-Mail-39-700189312-- From nobody Mon May 12 10:10:38 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA521A072A; Mon, 12 May 2014 10:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6FOuLGwQieL; Mon, 12 May 2014 10:10:33 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 0F87A1A072E; Mon, 12 May 2014 10:10:32 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s4CHAPK9006433; Mon, 12 May 2014 18:10:25 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s4CHANuw006416 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 May 2014 18:10:23 +0100 From: "Adrian Farrel" To: "'Vincent Roca'" , "'IESG'" , , References: In-Reply-To: Date: Mon, 12 May 2014 18:10:17 +0100 Message-ID: <08c801cf6e05$0d200d90$276028b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_08C9_01CF6E0D.6EE5FC30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI6M7cVzudwVfHp4TQTqZGHxKuFAppnomyQ Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.0.0.1014-20690.000 X-TM-AS-Result: No--9.994-10.0-31-10 X-imss-scan-details: No--9.994-10.0-31-10 X-TMASE-MatchedRID: DuKherWvI/ttT4GgHZSu8wbts0Qkqy42GbJMFqqIm9w4YKAM3oRt9mn7 AlTb8W2xmbgtFJbseiaV2J8ChOmkcwEPJSU5uWO/e7MO8jvmPSygBWRVHG2+kXOMCXNrYTWi8G7 V1v8bvlGXjuvNBBfmDcF0uBJI7Ez3H5chC2o3feJc/msUC5wFQalLUhyBHY5VIbxYwbCxGTTA1/ n5ffsZh4jHmnSGNeOdSaVfaxxV94/trubt8TkL4cG0UNgaZpYqtF9GMNu1bqLkOOZ1bT6psa7BV PFMOQQusrZgdv+SJ0/88SAvS2rKrnRue7aQeqLEsyw+ZJnFumQTskidPjB12hON+Q7elv5YPSaw iBLK6fcf9nvUckM1oVpzKEH0vVqvEnerDpp3+WMAGGKG8CG8Akh41hM/w6ZM+TdKNkxxkWRSUGH 6RuK0z1HpYTzKlHj/xz045WRJC2uHFo7dvDc+MOOtrJejSjcwh+w9Wz/xXDoR8rMICe0qkDnuQW M5MjklgExzV+J9XRidawge4qsoYOv1ZyR66iMp5HDr20Bhc0ZxtWYlDuRQpbXvDHySC+eUlSBIv H74wfJrar1QOTCmjzl5+IQAcYVk8lEDYmoBkrPbH8WaUL9qjB2CTNIhL2HPmCNknSXswf8SkGdm Qt+XWWXljhnB0lba2m/AaKPfqGCPmsTSpXoLhA6w00GeWBFafS0Ip2eEHnyvXSmSdlcYmi57hWH 2lkqmfeZdJ1Xsorgv/gvfppVuD46HM5rqDwqtu3nKmXKCHRqE8o/17jf/qUijqIM5sGk6vupaMm GsfZ0HaIXMY7lplmpcBpvEK1YtsZ8UxTmSOFfU9JuoFlVA3XE2ZAlSkvxqH8FerAT0dJY= Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/u0Y1NCMWh_DeNRLRMvTLhIMzAr4 Subject: Re: [secdir] Secdir review of draft-ietf-mpls-psc-updates-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 17:10:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_08C9_01CF6E0D.6EE5FC30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Vincent, Good points, but s/6378/6941/ Adrian From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Vincent Roca Sent: 12 May 2014 18:03 To: IESG; draft-ietf-mpls-psc-updates@tools.ietf.org; secdir@ietf.org Cc: Vincent Roca Subject: Secdir review of draft-ietf-mpls-psc-updates-05 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. IMHO, the document is Almost ready. The author claims this document "raise[s] no new security concerns". I think the author is right, however I have two comments: - it's preferable to mention explicitely that RFC 6378 provides the baseline security discussion and that it also applies to the present document. - Making sure an implementation behaves correctly in front of malformed messages is typically something that should be mentioned/discussed in the Security Section. This is the case in section 2.3 "Error handling". Can an attacker through malformed/unexpected messages (e.g., with fuzzing) launch a DoS? I don't suggest to move section 2.3 in the Security Discussion section, but rather to add a sentence in the Security Section explaining that this document in section 2.3 also clarifies how to react in front of malformed/unexpected messages (which is essential from a security point of view). Cheers, Vincent ------=_NextPart_000_08C9_01CF6E0D.6EE5FC30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Vincent,

 

Good points, but = s/6378/6941/

 

Adrian

 

From: iesg = [mailto:iesg-bounces@ietf.org] On Behalf Of Vincent = Roca
Sent: 12 May 2014 18:03
To: IESG; = draft-ietf-mpls-psc-updates@tools.ietf.org; = secdir@ietf.org
Cc: Vincent Roca
Subject: Secdir = review of = draft-ietf-mpls-psc-updates-05

 

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.

 

IMHO, the document = is Almost ready.

 

 

The author claims this document "raise[s] no new security = concerns".

I think the author is right, however I have two = comments:

 

- it's preferable to mention explicitely that RFC 6378 provides = the baseline

  security = discussion and that it also applies to the present = document.

 

- Making sure an implementation behaves correctly in front of = malformed

  messages is = typically something that should be mentioned/discussed in = the

  Security = Section. This is the case in section 2.3 "Error = handling".

  Can an attacker through malformed/unexpected messages = (e.g., with fuzzing)

  launch a DoS?

  I don't suggest to move section 2.3 in the Security = Discussion section, but

  rather to add a sentence in the Security Section = explaining that this document

  in section 2.3 also clarifies how to react in front = of malformed/unexpected

  messages (which is essential from a security = point of view).

 

Cheers,

 

    = Vincent

------=_NextPart_000_08C9_01CF6E0D.6EE5FC30-- From nobody Mon May 12 10:13:49 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6BA1A072E; Mon, 12 May 2014 10:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.2 X-Spam-Level: X-Spam-Status: No, score=-7.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dEc3g7ANFF0; Mon, 12 May 2014 10:13:45 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id DDFCA1A072A; Mon, 12 May 2014 10:13:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,1036,1389740400"; d="scan'208,217";a="61531399" Received: from unknown (HELO [192.168.43.137]) ([193.253.169.243]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 12 May 2014 19:13:37 +0200 From: Vincent Roca Content-Type: multipart/alternative; boundary=Apple-Mail-2-700790695 Date: Mon, 12 May 2014 19:13:05 +0200 Message-Id: <4CBC744D-7DA6-49AF-849D-66C876673246@inria.fr> To: IESG , draft-ietf-sidr-policy-qualifiers@tools.ietf.org, secdir@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/26cNiecwQjtLZK5PGOW-xGOharM Subject: [secdir] Secdir review of draft-ietf-sidr-policy-qualifiers-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 17:13:46 -0000 --Apple-Mail-2-700790695 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii 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. IMHO, the document is ready. Although the document is fairly small, there is a good security section that seems to me to address all the important aspects. I don't have any comment. Cheers, Vincent --Apple-Mail-2-700790695 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
IMHO, the document is  Subject: Re: [secdir] Secdir review of draft-ietf-mpls-psc-updates-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 12:49:29 -0000 Does 6941 go down as normative or informative? My guess is informative. eric On Mon, May 12, 2014 at 1:10 PM, Adrian Farrel wrote: > Hi Vincent, > > > > Good points, but s/6378/6941/ > > > > Adrian > > > > From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Vincent Roca > Sent: 12 May 2014 18:03 > To: IESG; draft-ietf-mpls-psc-updates@tools.ietf.org; secdir@ietf.org > Cc: Vincent Roca > Subject: Secdir review of draft-ietf-mpls-psc-updates-05 > > > > 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. > > > > IMHO, the document is Almost ready. > > > > > > The author claims this document "raise[s] no new security concerns". > > I think the author is right, however I have two comments: > > > > - it's preferable to mention explicitely that RFC 6378 provides the baseline > > security discussion and that it also applies to the present document. > > > > - Making sure an implementation behaves correctly in front of malformed > > messages is typically something that should be mentioned/discussed in the > > Security Section. This is the case in section 2.3 "Error handling". > > Can an attacker through malformed/unexpected messages (e.g., with fuzzing) > > launch a DoS? > > I don't suggest to move section 2.3 in the Security Discussion section, > but > > rather to add a sentence in the Security Section explaining that this > document > > in section 2.3 also clarifies how to react in front of > malformed/unexpected > > messages (which is essential from a security point of view). > > > > Cheers, > > > > Vincent From nobody Wed May 14 06:02:47 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26AAB1A0078; Wed, 14 May 2014 06:02:43 -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, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzBuzRgvPm6b; Wed, 14 May 2014 06:02:41 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id EE48C1A006D; Wed, 14 May 2014 06:02:40 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s4ED2WcO011176; Wed, 14 May 2014 14:02:32 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s4ED2Vsn011137 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 May 2014 14:02:31 +0100 From: "Adrian Farrel" To: "'Eric Osborne'" References: <08c801cf6e05$0d200d90$276028b0$@olddog.co.uk> In-Reply-To: Date: Wed, 14 May 2014 14:02:31 +0100 Message-ID: <007701cf6f74$c4b46580$4e1d3080$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI6M7cVzudwVfHp4TQTqZGHxKuFAgIamy5jAfT1W/GaSgRqYA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20692.007 X-TM-AS-Result: No--20.313-10.0-31-10 X-imss-scan-details: No--20.313-10.0-31-10 X-TMASE-MatchedRID: QfHZjzml1E+nykMun0J1wvHkpkyUphL9t7k6BDMlB1ghX1DXcpnJgB49 TW0ImlxY7+ykLzh4xShQph5GSAC7DQ7AfikPXgOwmlaAItiONP21k3bRIdXVNLrfxlRjqBJ3Ffu 9xZgL7lcaGJ6hc5LcchQd7vVtOefEMJN0pBC3oqcUEm127/0kJnJrB0Cu3DDn6DfA0qKLWvmLc3 vJNq/cTE5lMrwcgrvrZDtwWXYnS21GlhjnipkGEEJlJsbPxdeD0Wobj8GkNVp9Q5/gynnG1vO+m s5efpt74vM1YF6AJbZFi+KwZZttL42j49Ftap9EkGUtrowrXLg= Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/eg644vj0aX0B455JJ90_3pgwBcA Cc: draft-ietf-mpls-psc-updates@tools.ietf.org, 'IESG' , secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-mpls-psc-updates-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 13:02:43 -0000 Yes, thanks. A > -----Original Message----- > From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Eric Osborne > Sent: 14 May 2014 13:49 > To: Adrian Farrel > Cc: Vincent Roca; secdir@ietf.org; IESG; draft-ietf-mpls-psc- > updates@tools.ietf.org > Subject: Re: Secdir review of draft-ietf-mpls-psc-updates-05 > > Does 6941 go down as normative or informative? My guess is informative. > > > > > eric > > On Mon, May 12, 2014 at 1:10 PM, Adrian Farrel wrote: > > Hi Vincent, > > > > > > > > Good points, but s/6378/6941/ > > > > > > > > Adrian > > > > > > > > From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Vincent Roca > > Sent: 12 May 2014 18:03 > > To: IESG; draft-ietf-mpls-psc-updates@tools.ietf.org; secdir@ietf.org > > Cc: Vincent Roca > > Subject: Secdir review of draft-ietf-mpls-psc-updates-05 > > > > > > > > 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. > > > > > > > > IMHO, the document is Almost ready. > > > > > > > > > > > > The author claims this document "raise[s] no new security concerns". > > > > I think the author is right, however I have two comments: > > > > > > > > - it's preferable to mention explicitely that RFC 6378 provides the baseline > > > > security discussion and that it also applies to the present document. > > > > > > > > - Making sure an implementation behaves correctly in front of malformed > > > > messages is typically something that should be mentioned/discussed in the > > > > Security Section. This is the case in section 2.3 "Error handling". > > > > Can an attacker through malformed/unexpected messages (e.g., with fuzzing) > > > > launch a DoS? > > > > I don't suggest to move section 2.3 in the Security Discussion section, > > but > > > > rather to add a sentence in the Security Section explaining that this > > document > > > > in section 2.3 also clarifies how to react in front of > > malformed/unexpected > > > > messages (which is essential from a security point of view). > > > > > > > > Cheers, > > > > > > > > Vincent From nobody Wed May 14 06:03:31 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47EE21A0078 for ; Wed, 14 May 2014 06:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FmTyDImHowT for ; Wed, 14 May 2014 06:03:25 -0700 (PDT) Received: from mail-yk0-f178.google.com (mail-yk0-f178.google.com [209.85.160.178]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6971A007C for ; Wed, 14 May 2014 06:03:24 -0700 (PDT) Received: by mail-yk0-f178.google.com with SMTP id 20so1504705yks.37 for ; Wed, 14 May 2014 06:03:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Xqo3Yad8wz+6geHgWIy5SbtUCZpEKf+KNqcXio0wR5I=; b=N1kUnmEOqSUX10ueF+jeC74JtvHO+w1RG23Qezm+lcn/yW3d3fdcrg6P63hP9IAMle vOmw700XcE2l1/1Zm1wIi30lfVSu3aPbpnagbqPURNIPSz811D9wyT8GUYzMhPJf0+e8 Vb6uPnx4rds5Pb1hMujRIaclVs7Zi/OyUOK5aKq5hMZjYK5uqBFwY3enhfraPtRBUtK8 MLIZ4Gc+atho3yQPJRbiqf0jlNY9CdoJTaTSbvXH28cBefptKZhzIoZ2bkJ3v157Chdg 4GSTEvlMUoW3heWAP7g/tHu4Q9qUTCHX7lnVBpp9ZSdr7VG7yjVWk3qe3/cqojeZL1mC KLiw== X-Gm-Message-State: ALoCoQlqAgk8Q/UZ4tyK7R97VITYSJO6Q4HXMzK3Bu1pV2YdTbZeyw7+szygNt+h1Y71fijw4n45 MIME-Version: 1.0 X-Received: by 10.236.93.195 with SMTP id l43mr5426662yhf.40.1400072598277; Wed, 14 May 2014 06:03:18 -0700 (PDT) Received: by 10.170.60.20 with HTTP; Wed, 14 May 2014 06:03:18 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 May 2014 09:03:18 -0400 Message-ID: From: Eric Osborne To: Vincent Roca Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/OYB-Wua3pocKba82d371neYcD6g Cc: "draft-ietf-mpls-psc-updates@tools.ietf.org" , IESG , secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-mpls-psc-updates-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 13:03:26 -0000 ... > > - Making sure an implementation behaves correctly in front of malformed > messages is typically something that should be mentioned/discussed in the > Security Section. This is the case in section 2.3 "Error handling". > Can an attacker through malformed/unexpected messages (e.g., with fuzzing) > launch a DoS? > I don't suggest to move section 2.3 in the Security Discussion section, > but > rather to add a sentence in the Security Section explaining that this > document > in section 2.3 also clarifies how to react in front of > malformed/unexpected > messages (which is essential from a security point of view). I have added this to the security section. It now reads: --- 7. Security Considerations These changes and clarifications raise no new security concerns. RFC 6941 [RFC6941] provides the baseline security discussion for MPLS-TP, and PSC (both RFC 6378 and this document) fall under that umbrella. Additionally, Section 2.2 clarifies how to react to malformed or unexpected messages. --- Is that sufficient? eric > > Cheers, > > Vincent From nobody Wed May 14 15:03:39 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0801A0203; Wed, 14 May 2014 14:42:31 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDuvQbRc-uqu; Wed, 14 May 2014 14:42:30 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id 80FBC1A0201; Wed, 14 May 2014 14:42:29 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id s7so134599lbd.0 for ; Wed, 14 May 2014 14:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=luP5et14tjnOuujCY3oHNIDYnqloVbcTUYffCujzPT8=; b=y23FTAjhTdTa6uMIt1VYf4VDf4SCBeydZ/lrah2PoVdkLNLm5sSLmoeb6Fg4i7O7E5 QV7T4wZgbYoVrLNRI1vEuacJ6Yr8yAyW2XEVwFABs30/hTYbu8ZaiN2k6CPQmtVAbzOn ntandhTmxTZ/75SRErXX2iu9FoyGgybbTY/R8Ej2saW6aJxR2oBKtAU0Z8EcHp/xg71J uH6WzLHqVGFb4v3L/99OWiIyCvzCZ00EKjdiljJtOLAzIuGrtExTmSWbGJm5twMEHo1p dRLGpSTmIfNx1ymVhvZPQx7aa1UHmv7YRegeDA3O8qXVTH89ijVW5pgV0CpRDbekAo4k 9rHw== MIME-Version: 1.0 X-Received: by 10.152.8.7 with SMTP id n7mr4340735laa.22.1400103742017; Wed, 14 May 2014 14:42:22 -0700 (PDT) Received: by 10.112.26.142 with HTTP; Wed, 14 May 2014 14:42:21 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 May 2014 17:42:21 -0400 Message-ID: From: Kathleen Moriarty To: Eric Osborne Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/beInV-0Q7KWhFhUOOyTz1-v9sCo X-Mailman-Approved-At: Wed, 14 May 2014 15:03:38 -0700 Cc: secdir@ietf.org, "draft-ietf-mpls-psc-updates@tools.ietf.org" , IESG Subject: Re: [secdir] Secdir review of draft-ietf-mpls-psc-updates-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 21:42:31 -0000 Thanks for addressing Vincent's comments from the SecDir review. I just have one correction in-line. On Wed, May 14, 2014 at 9:03 AM, Eric Osborne wrote: > ... >> >> - Making sure an implementation behaves correctly in front of malformed >> messages is typically something that should be mentioned/discussed in the >> Security Section. This is the case in section 2.3 "Error handling". >> Can an attacker through malformed/unexpected messages (e.g., with fuzzing) >> launch a DoS? >> I don't suggest to move section 2.3 in the Security Discussion section, >> but >> rather to add a sentence in the Security Section explaining that this >> document >> in section 2.3 also clarifies how to react in front of >> malformed/unexpected >> messages (which is essential from a security point of view). > > > I have added this to the security section. It now reads: > > --- > 7. Security Considerations > > These changes and clarifications raise no new security concerns. RFC > 6941 [RFC6941] provides the baseline security discussion for MPLS-TP, > and PSC (both RFC 6378 and this document) fall under that umbrella. > Additionally, Section 2.2 clarifies how to react to malformed or > unexpected messages. > > --- > > > Is that sufficient? > It should be 2.3, not 2.2 for the error handling section. It my be helpful to note that this is a preventative security measure so it is understood, something like: Additionally, Section 2.3 clarifies how to react to malformed or unexpected messages, also an important preventative security measure. > > > eric > > >> >> Cheers, >> >> Vincent > -- Best regards, Kathleen From nobody Thu May 15 11:49:41 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF27C1A00B2 for ; Thu, 15 May 2014 11:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.653 X-Spam-Level: X-Spam-Status: No, score=-0.653 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVdPLgCto9kJ for ; Thu, 15 May 2014 11:49:34 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 C2ED61A0222 for ; Thu, 15 May 2014 11:49:33 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s4FInNvi014236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 15 May 2014 21:49:23 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s4FInNtO000876; Thu, 15 May 2014 21:49:23 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21365.3123.251839.541320@fireball.kivinen.iki.fi> Date: Thu, 15 May 2014 21:49:23 +0300 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/PPrzVtYrkwmlE94Qh3Nwkg4JV88 Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 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, 15 May 2014 18:49:37 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Brian Weis is next in the rotation. For telechat 2014-05-15 Reviewer LC end Draft Leif Johansson T 2014-04-15 draft-ietf-ccamp-rsvp-te-eth-oam-ext-12 Stephen Kent TR2014-04-24 draft-ietf-l2vpn-vpls-inter-domain-redundancy-06 Ben Laurie T 2014-04-25 draft-ietf-rtcweb-use-cases-and-requirements-14 Russ Mundy T 2014-05-06 draft-ietf-mpls-extended-admin-group-06 Sandy Murphy T 2014-05-02 draft-ietf-ipsecme-esp-ah-reqts-08 Eric Osterweil T 2014-05-12 draft-ietf-ippm-2330-update-04 For telechat 2014-05-29 Tobias Gondrom T 2014-03-27 draft-ietf-pwe3-p2mp-pw-requirements-08 Magnus Nystrom T 2014-05-16 draft-pal-eidr-urn-02 Last calls and special requests: Sam Hartman 2014-04-08 draft-ietf-l2vpn-vpls-ldp-mac-opt-11 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-06 Julien Laganier E 2013-11-21 draft-ietf-websec-key-pinning-13 Julien Laganier 2014-04-29 draft-ietf-dhc-dhcpv4-over-dhcpv6-07 Russ Mundy 2014-03-24 draft-mahalingam-dutt-dcops-vxlan-09 Sandy Murphy 2013-12-17 draft-ietf-netmod-iana-timezones-03 Joe Salowey 2014-05-29 draft-moonesamy-sshfp-ed25519-01 Yaron Sheffer 2014-05-21 draft-ietf-mpls-ldp-hello-crypto-auth-05 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Melinda Shore 2014-05-26 draft-ietf-dnsop-delegation-trust-maintainance-13 Ondrej Sury 2014-05-28 draft-ietf-ipfix-text-adt-05 Takeshi Takahashi 2014-05-28 draft-ietf-mmusic-latching-05 Tina TSOU 2014-05-26 draft-ietf-pce-pcep-inter-domain-p2mp-procedures-06 David Waltermire 2014-06-10 draft-salgueiro-dispatch-websocket-sipclf-01 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-11 -- kivinen@iki.fi From nobody Thu May 15 12:32:36 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF001A0376; Thu, 15 May 2014 12:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.422 X-Spam-Level: X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-70y_O3CFpe; Thu, 15 May 2014 12:32:31 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (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 122891A03B9; Thu, 15 May 2014 12:32:30 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s4FJWIWX000339 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 May 2014 21:32:18 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.7/8.14.7) with ESMTP id s4FJWEYT006296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 May 2014 21:32:17 +0200 (CEST) X-Footer: c3VuZXQuc2U= Received: from [10.0.0.115] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.2.4) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128 bits)); Thu, 15 May 2014 21:32:14 +0200 Message-ID: <5375163E.5080109@sunet.se> Date: Thu, 15 May 2014 21:32:14 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: iesg@ietf.org, secdir@ietf.org, draft-ietf-ccamp-rsvp-te-eth-oam-ext.all@tools.ietf.org X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09M2jwirz - be80c861716b - 20140515 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/rUwsr5Rc_6kA7lG1Ml8CrER-2b8 Subject: [secdir] review of draft-ietf-ccamp-rsvp-te-eth-oam-ext-12 (no problem) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 19:32:33 -0000 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. Even though the subject matter is outside my normal comfort zone I feel reasonably sure in saying that the draft is no worse from a security point of view than anything else in GMPLS-land. Cheers Leif From nobody Fri May 16 03:46:38 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A241A0217 for ; Fri, 16 May 2014 03:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eG_2K2UI5S0h for ; Fri, 16 May 2014 03:46:35 -0700 (PDT) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F40F31A0216 for ; Fri, 16 May 2014 03:46:33 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id lf12so5924989vcb.15 for ; Fri, 16 May 2014 03:46:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=5GMDom9RKtOeWDQHXi1z3p8V8M3fJ7mhIERBi1ukJr4=; b=bnSgQcomk5YQVtLgtaoofczRC4/oynctHleDi2DFnZ2Xz4tKU1T8jpVTQE9ZE/OWBA 2ro1S7yY7sE4CIE9uiY9gjZpP6yhGNix653YDFElGNn1w2Vyhv5xRGYuhkjoHPHsbvYe GMwU2y05jhXb3TX/fkLYMTEZG+5UztWWN+6eCFBWAW7yxrc1q3MK1afiMC7JGRop3Cvt TzjCaoCPpeJ3NN+iAMvQvdS1+8w7PJHUA8nPDl9Nodj8tbDUxJxzfYdiXkYpjC/m6rcq SYGfyTBNP8SSneqC7lc9PZ4n9gPQxa2kAtnhRoZjxsWHrnLBvvwDmaArQ/HYm0GF6uRH 5Fqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=5GMDom9RKtOeWDQHXi1z3p8V8M3fJ7mhIERBi1ukJr4=; b=Htym0Jik8maLPVsfHGh6GdHV07/iALB0CQ57+Xhbjh9EUx5yUoTbxrSsIMgERWvVsM yCoz9f7y9ZLMGtgdInZZjUE2tBu0YDNxtUbAr7LN2l181zczfzRbE3y4hulpm365Quyv 42SDzrmPh6oKIVqCdgm85AO6H5UW6krVGFRjNj5MhS0sX8DRH/VSy/DkerPmkGIH+Yiv TX2eqmCC65TQ3w50z7BzuJXxKVqCDlf+milpPIG6cPQmDrNu/mrCUS49DqkUNOmcTQaR VxfdH2tGPgPZ3F7ljjNvlKniDPUdiYPiFzhL7Fuk3on75bysDNFCcBlk0nPESi424ljT E9zg== X-Gm-Message-State: ALoCoQmp0FIkN1hXqvOwsMsa/6wN6Aj/R6Fod5d/sSAA1ZAumoVmh+vKn1P4gpxB0Z1knuVASDhm MIME-Version: 1.0 X-Received: by 10.58.96.36 with SMTP id dp4mr348489veb.21.1400237186142; Fri, 16 May 2014 03:46:26 -0700 (PDT) Received: by 10.52.252.97 with HTTP; Fri, 16 May 2014 03:46:26 -0700 (PDT) Date: Fri, 16 May 2014 11:46:26 +0100 Message-ID: From: Ben Laurie To: The IESG , "secdir@ietf.org" , draft-ietf-rtcweb-use-cases-and-requirements.all@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/HcMuY4dHCOHGh0BVM9gytAgvdJM Subject: [secdir] Security Review of draft-ietf-rtcweb-use-cases-and-requirements-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 10:46:36 -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. >From a security POV this document is mostly ready: it includes as common requirements for all use-cases: F11 It must be possible to protect streams and data from wiretapping [RFC2804]. and F13 The browser must encrypt, authenticate and integrity protect media and data on a per-packet basis, and must drop incoming media and data packets that fail the per-packet integrity check. In addition, the browser must support a mechanism for cryptographically binding media and data security keys to the user identity (see R-ID-BINDING in [RFC5479]). which are nice, _but_ it seems to me that, given that metadata interception is now the norm, that there should be an additional requirement that identity data should not be available to attackers (i.e. that a GPA or a MitM should not be able to determine who the end-points are from data transmitted in the stream). I note that RFC 5479 also does not appear to include this requirement. Also, F11 is perhaps a little weak in that it appears to only require protection from a GPA, not from a MitM. RFC 5479 is a little unclear on this point (it discusses active attackers but doesn't specifically say protocols should defend against them). -- Certificate Transparency is hiring! Let me know if you're interested. From nobody Fri May 16 07:05:39 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987531A0069; Fri, 16 May 2014 07:05:36 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itHnb9YPiwVE; Fri, 16 May 2014 07:05:35 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09CD21A0062; Fri, 16 May 2014 07:05:34 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id f8so1018265wiw.2 for ; Fri, 16 May 2014 07:05:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=afHPPkbKw9ZvT8N/1dzhmAQ5nzRqfY6zSanuYjMSVhk=; b=G4/IDteERd+Jz0sHl3aYUtKouLlmb4w0L0m7dlQVxbqP9iBWrj4MoTmyBdEFugxFk+ 7eVcalw8anfgvLo8HXbtylyu2XOHSKQJfl1D8GcPXmjbRQnLBt/q200+BSV5cK//IIIc ICz8lsziqdavQV60xv7BdWf0aR/BABgtlBFj6n9y3Th4WN9PV8DBnme9iPMMy2iTPpVe 5JT/oeawAgJWy5zKecLCFgIb7q3ovMQ4Bdnl+XQr3PRzdBPmmKgq3Cp4j4wlOGE45QPJ 5eAGu30/UCDw4jXjOB+t0gPRtkRqXZh7zT8/mhw0ENI6Gr4dn8VAYOdwXaZCilk4vh8v cd0Q== X-Received: by 10.180.96.225 with SMTP id dv1mr14017749wib.37.1400249126531; Fri, 16 May 2014 07:05:26 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-179-142-94.red.bezeqint.net. [79.179.142.94]) by mx.google.com with ESMTPSA id fs5sm3532089wic.22.2014.05.16.07.05.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 May 2014 07:05:25 -0700 (PDT) Message-ID: <53761B24.1060501@gmail.com> Date: Fri, 16 May 2014 17:05:24 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: IETF Security Directorate , The IESG , draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/k2FkFJmfQ7EYZfmaVVE8ExtQwz4 Subject: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 14:05:36 -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 proposes to add cryptographic authentication to LDP "all routers" Hello messages, which are transported as unicast UDP. Summary The document may be ready to publish, but this reviewer has major issues with the selected solution. Details • The main issue is that only a symmetric crypto option is defined. IMHO, adding a public-key based scheme would be invaluable. Public keys do not necessarily imply certificates, and can be used with little added complexity compared to the current proposal. As far as I can see, the current use is not so performance constrained to preclude public key operations. And public keys would enable much easier and more secure deployment in many cases: ∘ Different organizations can accept messages from one another, without needing to share the same keys. So even if groups keys are used (which is certainly not the best practice), public keys have an advantage. ∘ Revocation is much simpler: to be able to revoke each individual sender (e.g. when a router is decomissioned), you need N**2 SAs in the symmetric case, vs. N keys when public keys are used. • Managing the 32-bit SAID manually in a large network is extremely onerous. So in practice keys would be rarely on never changed. • 2.2: the authentication algorithm and the authentication key are not "independent", because the algorithm normally determines the key length. • 2.2: the various time values included in the SA essentially require (rough) time synchronization between the nodes. If this is the case, time values could have been used for replay protection, which would have been much simpler to implement than the 64-bit sequence number which needs to persist across reboots. • 5.1: Redefining HMAC (RFC 2104) is an extremely bad idea. This reviewer does not have the appropriate background to critique the proposed solution, but there must be an overwhelming reason to reopen cryptographic primitives. • 7: 128-bit keys are OK (or overkill) for some algorithms, but too short for others. In general, the recommended key length is not constant. It depends on the algorithm. • "The mechanism described herein is not perfect and does not need to be perfect." This is kind of vague, and would be better replaced by your security goals. Thanks, Yaron From nobody Fri May 16 07:43:22 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11561A0257 for ; Fri, 16 May 2014 07:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.353 X-Spam-Level: X-Spam-Status: No, score=-1.353 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lE0IqgJPySKv for ; Fri, 16 May 2014 07:43:18 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D1381A0060 for ; Fri, 16 May 2014 07:43:18 -0700 (PDT) X-AuditID: 12074424-f79546d000000c5e-af-537623fee373 Received: from mailhub-2.mit.edu ( [18.7.62.30]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id C1.F5.03166.EF326735; Fri, 16 May 2014 10:43:10 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-1.mit.edu [18.9.28.12]) by mailhub-2.mit.edu (8.13.8/8.9.2) with ESMTP id s4GEh8fj029494; Fri, 16 May 2014 10:43:09 -0400 Received: from webmail-9.mit.edu (webmail-9.mit.edu [18.9.23.19]) ) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s4GEh54Q006526; Fri, 16 May 2014 10:43:06 -0400 Received: from webmail-9.mit.edu (webmail-9.mit.edu [127.0.0.1]) by webmail-9.mit.edu (8.13.8) with ESMTP id s4GEh5Xu014724; Fri, 16 May 2014 10:43:05 -0400 Received: (from nobody@localhost) by webmail-9.mit.edu (8.13.8/8.13.8/Submit) id s4GEh3tK014723; Fri, 16 May 2014 10:43:03 -0400 X-Authentication-Warning: webmail-9.mit.edu: nobody set sender to uri@mit.edu using -f Received: from LLPROXY.LL.MIT.EDU (LLPROXY.LL.MIT.EDU [129.55.200.20]) (User authenticated as uri@ATHENA.MIT.EDU) by webmail.mit.edu (Horde MIME library) with HTTP; Fri, 16 May 2014 10:43:03 -0400 Message-ID: <20140516104303.5znqhmi83ockgsgg@webmail.mit.edu> X-Priority: 3 (Normal) Date: Fri, 16 May 2014 10:43:03 -0400 From: Uri Blumenthal To: Yaron Sheffer References: <53761B24.1060501@gmail.com> In-Reply-To: <53761B24.1060501@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCKsWRmVeSWpSXmKPExsUixG4np/tPuSzYoOmmmMXd8xvZLD4sfMhi ser+DHYHZo+ds+6yeyxZ8pPJ48vlz2wBzFFcNimpOZllqUX6dglcGYf3tDAWLGCrOLvyN3sD YwtrFyMnh4SAicSNdYfZIWwxiQv31rN1MXJxCAlMY5L4uHQZWJGQwHJGiZ87VSASqxklruxu ZYFw5jFKHNtwlBXCaWGUuHRiLyPErDCJvrWnoBKnGCUm9iwAW8IrYCvxcO4lVpiFE9b9Ygax WQRUJV6sngfWzCagJNHcvAWohoNDREBTYtpRqy5Gdg5mAV+JfykgBcICgRJzb+xihDhOQ+Lt untMIDYnUPGMx2eYIBYJSpyc+YQFxGYWsJE48WMr2EBmAWmJ5f84IMLaEssWvgbbLypgLvFg 7w7GCYzis5B0z0LSPQuhexaS7gWMLKsYZVNyq3RzEzNzilOTdYuTE/PyUot0zfVyM0v0UlNK NzGCI89FZQdj8yGlQ4wCHIxKPLwXtEqDhVgTy4orcw8xSnIwKYnyJsiVBQvxJeWnVGYkFmfE F5XmpBYfYpTgYFYS4ZUSAMrxpiRWVqUW5cOkpDlYlMR531pbBQsJpCeWpGanphakFsFkZTg4 lCR4VYEJRkiwKDU9tSItM6cEIc3EwQkynAdo+DklkOHFBYm5xZnpEPlTjIpS4rzKIM0CIImM 0jy4XlhifMUoDvSKMK8eSBUPMKnCdb8CGswENPjN3lKQwSWJCCmpBsbJbSZ+nef52zkWpC/w sdYz8/m+w+LYpNo3qdIm672mJfFsU9y4lXO//P+2hJqZ26unLXvy7ZWLbG9PlGK5b+PEva8n +bDIv8raMkFq9638iPk+3I01Dw5fvL328JEClW1XGufJeTmeU5t87N9hs98812Qff5n7wf7G u03Fth8v7wla0vmHu+iOEktxRqKhFnNRcSIAjA2W7GcDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/yEOhRtSEPkKr1xRfKyg9esMJbq4 Cc: draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 14:43:20 -0000 Quoting Yaron Sheffer : > ....... > This document proposes to add cryptographic authentication to LDP "all > routers" Hello messages, which are transported as unicast UDP. > > =E2=80=A2 5.1: Redefining HMAC (RFC 2104) is an extremely bad idea. This > reviewer does not have the appropriate background to critique the > proposed solution, but there must be an overwhelming reason to reopen > cryptographic primitives. They do seem to be using HMAC, even though without explicitly naming it so (5.1 and 5.2). Also, HMAC is referred to in the Normative References. > =E2=80=A2 "The mechanism described herein is not perfect and does not nee= d to be > perfect." This is kind of vague, and would be better replaced by your > security goals. Concur. :-) From nobody Fri May 16 09:36:09 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A51481A0076 for ; Fri, 16 May 2014 09:35:58 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOvxm0irnCBa for ; Fri, 16 May 2014 09:35:55 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE0091A0281 for ; Fri, 16 May 2014 09:35:49 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id t60so2789206wes.41 for ; Fri, 16 May 2014 09:35:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=BldJiCFWSq180WtSGVZytMeRCRApdWtwp3w43Wf999s=; b=qpvbPWL+21cb6pCngXnIbli0NeUDZsbUVIcnKPA+33dazvJUgTi2bMzFIMC/C0TqRR rHLLTkbsawflu9xU4OAZjjSUlVQbjL2wWNNky1DPrwFkDCyWCLD+9ffU1XZIHigwfJob 10KXH+Tv52uY0FGp3wK8VbbS4quoWciRzk5OVKzXIShdoJLRPG3y790RMdyNk8eu0dau OO0GmZaOdfbdVZ8E2/qyx/CBD21A9WU91TpZ9tK3/6+jtjZX8G9T4P6jVQIMDtHo2PNX 1fehrV5BsHMItolXG03xTQ8ZPiUeEUqTlcK9KR53U8C+QO3UNOrTl0wZgwcqrSvJq973 DnMA== X-Received: by 10.194.82.170 with SMTP id j10mr3112764wjy.63.1400258141162; Fri, 16 May 2014 09:35:41 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-179-142-94.red.bezeqint.net. [79.179.142.94]) by mx.google.com with ESMTPSA id go1sm4201228wib.7.2014.05.16.09.35.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 May 2014 09:35:40 -0700 (PDT) Message-ID: <53763E5B.3060703@gmail.com> Date: Fri, 16 May 2014 19:35:39 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Uri Blumenthal References: <53761B24.1060501@gmail.com> <20140516104303.5znqhmi83ockgsgg@webmail.mit.edu> In-Reply-To: <20140516104303.5znqhmi83ockgsgg@webmail.mit.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/ISHo2c6a3SiAegEeD9TQKPy3M2s Cc: draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 16:35:58 -0000 On 05/16/2014 05:43 PM, Uri Blumenthal wrote: > Quoting Yaron Sheffer : >> ....... >> This document proposes to add cryptographic authentication to LDP "all >> routers" Hello messages, which are transported as unicast UDP. >> >> • 5.1: Redefining HMAC (RFC 2104) is an extremely bad idea. This >> reviewer does not have the appropriate background to critique the >> proposed solution, but there must be an overwhelming reason to reopen >> cryptographic primitives. > > They do seem to be using HMAC, even though without explicitly naming it > so (5.1 > and 5.2). Also, HMAC is referred to in the Normative References. > Yes, of course. But then they argue with the standard definition, "While [RFC2104] supports a key that is up to B octets long, this application uses L as the Ks length consistent with [...]". And then instead of using it like a black box, they spell it out in 5.2, so developers are encouraged to re-implement HMAC instead of using one of dozens of existing implementations. >> • "The mechanism described herein is not perfect and does not need to be >> perfect." This is kind of vague, and would be better replaced by your >> security goals. > > Concur. :-) > From nobody Sun May 18 17:17:18 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE591A021F; Sun, 18 May 2014 17:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qROSdvYkGep; Sun, 18 May 2014 17:17:11 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 402F01A021D; Sun, 18 May 2014 17:17:10 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s4J0H85G022953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 18 May 2014 19:17:09 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s4J0H8Rx027409 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 18 May 2014 20:17:08 -0400 Received: from SG70XWXCHHUB01.zap.alcatel-lucent.com (135.253.2.46) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sun, 18 May 2014 20:17:07 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.212]) by SG70XWXCHHUB01.zap.alcatel-lucent.com ([135.253.2.46]) with mapi id 14.02.0247.003; Mon, 19 May 2014 08:17:05 +0800 From: "Bhatia, Manav (Manav)" To: Yaron Sheffer , IETF Security Directorate , The IESG , "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" Thread-Topic: SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 Thread-Index: AQHPcRACnDeFnD7gHUOXWsSAGM4MlZtGKCeA Date: Mon, 19 May 2014 00:17:04 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <53761B24.1060501@gmail.com> In-Reply-To: <53761B24.1060501@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/G82zJ4POgf9OWXWGAdzMz94YQI4 Cc: "manavbhatia@gmail.com" Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 00:17:13 -0000 SGkgWWFyb24sDQoNClRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLiBNeSBjb21tZW50cyBpbmxpbmUu DQoNCj4gDQo+IOKAoiBUaGUgbWFpbiBpc3N1ZSBpcyB0aGF0IG9ubHkgYSBzeW1tZXRyaWMgY3J5 cHRvIG9wdGlvbiBpcyBkZWZpbmVkLg0KPiBJTUhPLCBhZGRpbmcgYSBwdWJsaWMta2V5IGJhc2Vk IHNjaGVtZSB3b3VsZCBiZSBpbnZhbHVhYmxlLiBQdWJsaWMga2V5cw0KPiBkbyBub3QgbmVjZXNz YXJpbHkgaW1wbHkgY2VydGlmaWNhdGVzLCBhbmQgY2FuIGJlIHVzZWQgd2l0aCBsaXR0bGUNCj4g YWRkZWQNCj4gY29tcGxleGl0eSBjb21wYXJlZCB0byB0aGUgY3VycmVudCBwcm9wb3NhbC4gQXMg ZmFyIGFzIEkgY2FuIHNlZSwgdGhlDQo+IGN1cnJlbnQgdXNlIGlzIG5vdCBzbyBwZXJmb3JtYW5j ZSBjb25zdHJhaW5lZCB0byBwcmVjbHVkZSBwdWJsaWMga2V5DQo+IG9wZXJhdGlvbnMuIEFuZCBw dWJsaWMga2V5cyB3b3VsZCBlbmFibGUgbXVjaCBlYXNpZXIgYW5kIG1vcmUgc2VjdXJlDQo+IGRl cGxveW1lbnQgaW4gbWFueSBjYXNlczoNCj4gCeKImCBEaWZmZXJlbnQgb3JnYW5pemF0aW9ucyBj YW4gYWNjZXB0IG1lc3NhZ2VzIGZyb20gb25lIGFub3RoZXIsDQo+IHdpdGhvdXQNCj4gbmVlZGlu ZyB0byBzaGFyZSB0aGUgc2FtZSBrZXlzLiBTbyBldmVuIGlmIGdyb3VwcyBrZXlzIGFyZSB1c2Vk ICh3aGljaA0KPiBpcyBjZXJ0YWlubHkgbm90IHRoZSBiZXN0IHByYWN0aWNlKSwgcHVibGljIGtl eXMgaGF2ZSBhbiBhZHZhbnRhZ2UuDQo+IAniiJggUmV2b2NhdGlvbiBpcyBtdWNoIHNpbXBsZXI6 IHRvIGJlIGFibGUgdG8gcmV2b2tlIGVhY2gNCj4gaW5kaXZpZHVhbA0KPiBzZW5kZXIgKGUuZy4g d2hlbiBhIHJvdXRlciBpcyBkZWNvbWlzc2lvbmVkKSwgeW91IG5lZWQgTioqMiBTQXMgaW4gdGhl DQo+IHN5bW1ldHJpYyBjYXNlLCB2cy4gTiBrZXlzIHdoZW4gcHVibGljIGtleXMgYXJlIHVzZWQu DQoNClRoZSBpZGVhIGJlaGluZCB0aGlzIGRyYWZ0IGlzIHRvIGJyaW5nIExEUCBIRUxMTydzIHNl Y3VyaXR5IHRvIGF0IGxlYXN0IHRoZSBzYW1lIGxldmVsIGFzIHRoZSByb3V0aW5nIHByb3RvY29s cyBydW5uaW5nIGluIHRoZSBzYW1lIG5ldHdvcmtzIHRvZGF5LiBBbGwgSUdQcyBhcmUgY3VycmVu dGx5IHVzaW5nIGEgc3ltbWV0cmljIGNyeXB0byBvcHRpb24gYW5kIHdlIHRoaW5rIGl0IGlzIG9r IGF0IHRoaXMgcG9pbnQgaW4gdGltZSB0byBjb250aW51ZSB3aXRoIHRoZSBzYW1lIGZvciBMRFAu DQoNCldpdGggU0ROIHByaW5jaXBsZXMgaXRzIHBvc3NpYmxlIHRoYXQgdGhlIGtleSBkaXN0cmli dXRpb24gYmVjb21lcyBxdWl0ZSBzaW1wbGUgd2l0aCBhIGNlbnRyYWwgY29udHJvbGxlciBkaXN0 cmlidXRpbmcgdGhlIGtleXMgdG8gYWxsIHRoZSBub2RlcyBpbiB0aGUgbmV0d29yayBhbG9uZyB3 aXRoIHRoZSBvdGhlciBpbmZvcm1hdGlvbi4gVGhpcyBhbHNvIHNlZW1zIHRvIGJlIG9uZSBvZiB0 aGUgdGhvdWdodHMgYmVoaW5kIG5vdCBwdXJzdWluZyBhbiBhdXRvbWF0ZWQga2V5IG1hbmFnZW1l bnQgcHJvdG9jb2wgZm9yIElHUHMgKHNvbWV0aGluZyB0aGF0IHdlIHdlcmUgc3VwcG9zZWQgdG8g dGFrZSB1cCBhcyBwYXJ0IG9mIHRoZSBQaGFzZSAyIGluIHRoZSBLQVJQIFdHIC0tIHlvdSBjYW4g bG9vayBhdCBSRkMgNjUxOCBmb3IgbW9yZSBkZXRhaWxzKS4NCg0KR2l2ZW4gdGhpcyBJIHdvdWxk IGxpa2UgdG8gY29udGludWUgd2l0aCB3aGF0IHdlIGhhdmUgYW5kIGxvb2sgYXQgb3RoZXIgbWVj aGFuaXNtcyBvbmNlIHdlIGhhdmUgbW9yZSBjbGFyaXR5IG9uIHRoZSBkaXJlY3Rpb24gd2hpY2gg d2Ugc2VlbSB0byBiZSBoZWFkaW5nIHRvd2FyZHMuDQoNCkFsc28gZmluYWxseSBub3RlIHRoYXQg dGhpcyBzZWN1cml0eSBpcyBhbHdheXMgd2l0aGluIGEgcHJvdmlkZXJzIG5ldHdvcmsgLS0gdGhl cmUgaXNudCBhIG5lZWQgdG8gaW52b2x2ZSBkaWZmZXJlbnQgb3JnYW5pemF0aW9ucy4NCg0KPiDi gKIgTWFuYWdpbmcgdGhlIDMyLWJpdCBTQUlEIG1hbnVhbGx5IGluIGEgbGFyZ2UgbmV0d29yayBp cyBleHRyZW1lbHkNCj4gb25lcm91cy4gU28gaW4gcHJhY3RpY2Uga2V5cyB3b3VsZCBiZSByYXJl bHkgb24gbmV2ZXIgY2hhbmdlZC4NCg0KT2ssIHNvIHdoYXRzIHRoZSBwb2ludD8NCg0KPiANCj4g 4oCiIDIuMjogdGhlIGF1dGhlbnRpY2F0aW9uIGFsZ29yaXRobSBhbmQgdGhlIGF1dGhlbnRpY2F0 aW9uIGtleSBhcmUgbm90DQo+ICJpbmRlcGVuZGVudCIsIGJlY2F1c2UgdGhlIGFsZ29yaXRobSBu b3JtYWxseSBkZXRlcm1pbmVzIHRoZSBrZXkNCj4gbGVuZ3RoLg0KDQpUaGlzIGlzIG5pdC1waWNr aW5nIGFuZCBzdXJlIHdlIGNhbiByZW1vdmUgdGhlIHdvcmQgImluZGVwZW5kZW50Ii4gV2hlbiBk ZWZpbmluZyB0aGUgQXV0aGVudGljYXRpb24gS2V5IHdlIGRvIG1lbnRpb24gdGhhdCBpdCBkZXBl bmRzIG9uIHRoZSBhbGdvLg0KDQpBdXRoZW50aWNhdGlvbiBLZXkNCg0KICAgICAgVGhpcyB2YWx1 ZSBkZW5vdGVzIHRoZSBjcnlwdG9ncmFwaGljIGF1dGhlbnRpY2F0aW9uIGtleSBhc3NvY2lhdGVk DQogICAgICB3aXRoIHRoZSBMRFAgU0EuICBUaGUgbGVuZ3RoIG9mIHRoaXMga2V5IGlzIHZhcmlh YmxlIGFuZCBkZXBlbmRzDQogICAgICB1cG9uIHRoZSBhdXRoZW50aWNhdGlvbiBhbGdvcml0aG0g c3BlY2lmaWVkIGJ5IHRoZSBMRFAgU0EuDQoNCj4gDQo+IOKAoiAyLjI6IHRoZSB2YXJpb3VzIHRp bWUgdmFsdWVzIGluY2x1ZGVkIGluIHRoZSBTQSBlc3NlbnRpYWxseSByZXF1aXJlDQo+IChyb3Vn aCkgdGltZSBzeW5jaHJvbml6YXRpb24gYmV0d2VlbiB0aGUgbm9kZXMuIElmIHRoaXMgaXMgdGhl IGNhc2UsDQo+IHRpbWUgdmFsdWVzIGNvdWxkIGhhdmUgYmVlbiB1c2VkIGZvciByZXBsYXkgcHJv dGVjdGlvbiwgd2hpY2ggd291bGQNCj4gaGF2ZQ0KPiBiZWVuIG11Y2ggc2ltcGxlciB0byBpbXBs ZW1lbnQgdGhhbiB0aGUgNjQtYml0IHNlcXVlbmNlIG51bWJlciB3aGljaA0KPiBuZWVkcyB0byBw ZXJzaXN0IGFjcm9zcyByZWJvb3RzLg0KDQpUaGUgdmFyaW91cyB0aW1lcnMgYXJlIG9ubHkgYXNz b2NpYXRlZCBpZiBzb21lYm9keSB3YW50cyB0byByb2xsb3ZlciB0aGUga2V5cy4gVGhlIGdyYW51 bGFyaXR5IG9mIHRoZXNlIHRpbWVycyBjYW4gYmUgY29hcnNlIChpbXBsZW1lbnRhdGlvbiBzcGVj aWZpYykgYW5kIHdpbGwgbm90IGJlIHNlY3VyZSBlbm91Z2ggdG8gdXNlIGZvciBhbnRpIHJlcGxh eSBwcm90ZWN0aW9uLg0KDQpNb3Jlb3Zlciwgd2l0aG91dCB0aGUgNjQgYml0IHNlcXVlbmNlIG51 bWJlcnMsIGl0cyB2ZXJ5IGRpZmZpY3VsdCB0byBwcm90ZWN0IGFnYWluc3QgaW50ZXItc2Vzc2lv biByZXBsYXkgYXR0YWNrcyAoUkZDIDY4NjIpDQoNCj4gDQo+IOKAoiA1LjE6IFJlZGVmaW5pbmcg SE1BQyAoUkZDIDIxMDQpIGlzIGFuIGV4dHJlbWVseSBiYWQgaWRlYS4gVGhpcw0KPiByZXZpZXdl ciBkb2VzIG5vdCBoYXZlIHRoZSBhcHByb3ByaWF0ZSBiYWNrZ3JvdW5kIHRvIGNyaXRpcXVlIHRo ZQ0KPiBwcm9wb3NlZCBzb2x1dGlvbiwgYnV0IHRoZXJlIG11c3QgYmUgYW4gb3ZlcndoZWxtaW5n IHJlYXNvbiB0byByZW9wZW4NCj4gY3J5cHRvZ3JhcGhpYyBwcmltaXRpdmVzLg0KDQpUaGlzIGlz IGEgZGVjaXNpb24gdGhhdCB3YXMgdGFrZW4gYnkgU2VjIEFkcyB3aGVuIHdlIHdlcmUgZG9pbmcg dGhlIGNyeXB0byBwcm90ZWN0aW9uIGZvciB0aGUgSUdQcyBiYXNlZCBvbiBzb21lIGZlZWRiYWNr IGZyb20gTklTVC4gVGhpcyBtYXRoZW1hdGljcyBpcyBub3QgbmV3IGFuZCBoYXMgYmVlbiBkb25l IGZvciBhbGwgSUdQcyBhbmQgaGFzIGJlZW4gYXBwcm92ZWQgYW5kIHJhdGhlciBlbmNvdXJhZ2Vk IGJ5IHRoZSBTZWN1cml0eSBBRHMuDQoNCj4gDQo+IOKAoiA3OiAxMjgtYml0IGtleXMgYXJlIE9L IChvciBvdmVya2lsbCkgZm9yIHNvbWUgYWxnb3JpdGhtcywgYnV0IHRvbw0KPiBzaG9ydCBmb3Ig b3RoZXJzLiBJbiBnZW5lcmFsLCB0aGUgcmVjb21tZW5kZWQga2V5IGxlbmd0aCBpcyBub3QNCj4g Y29uc3RhbnQuIEl0IGRlcGVuZHMgb24gdGhlIGFsZ29yaXRobS4NCg0KVGhpcyBuZWVkcyB0byBi ZSBwdW5jaGVkIG9uIGVhY2ggcm91dGVyIGNvbnNvbGUuIEZvciBhbiBpbnRlcm5hbCBuZXR3b3Jr LCBkbyB5b3UgdGhpbmsgMTI4IGJpdCBpc250IGdvb2QgZW5vdWdoPw0KPiANCj4g4oCiICJUaGUg bWVjaGFuaXNtIGRlc2NyaWJlZCBoZXJlaW4gaXMgbm90IHBlcmZlY3QgYW5kIGRvZXMgbm90IG5l ZWQgdG8NCj4gYmUNCj4gcGVyZmVjdC4iIFRoaXMgaXMga2luZCBvZiB2YWd1ZSwgYW5kIHdvdWxk IGJlIGJldHRlciByZXBsYWNlZCBieSB5b3VyDQo+IHNlY3VyaXR5IGdvYWxzLg0KDQpJIHRoaW5r IHdlIGNhbiBqdXN0IGRlbGV0ZSB0aGlzISA6LSkNCg0KQ2hlZXJzLCBNYW5hdg0KDQo+IA0KPiBU aGFua3MsDQo+IAlZYXJvbg0K From nobody Mon May 19 01:56:07 2014 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 7353E1A0325; Mon, 19 May 2014 01:53:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1400489637; bh=J2B/Ix44lJWlqSZ7js81TLmyXSRYHSA7s0lfSHF3WPw=; h=To:Date:MIME-Version:From:Message-ID:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=TpzjuL77SKRR6JcMe3ViDqf73LSA+Em8schMxAhk7DVFNz/IqcEIBm0zfU6MXAizS xBQHZe91hVuNH4Z7Qr+NkgTdqpPqhZ8M+7KqeNn4S5/TVbIAKTqfvYegAf+0F6DCKv QmcwJzE9HLcbMOuaZV21Vpjdzyy0TCRMfSQzYulo= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F531A0253 for ; Mon, 19 May 2014 01:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.853 X-Spam-Level: X-Spam-Status: No, score=-4.853 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WAft6xQDYuL for ; Mon, 19 May 2014 01:53:54 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D6941A0325 for ; Mon, 19 May 2014 01:53:54 -0700 (PDT) Received: from eb.bleuazur.com ([88.173.33.195] helo=sith.local) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1WmJKR-0001IW-Tn for new-work@ietf.org; Mon, 19 May 2014 04:53:52 -0400 To: new-work@ietf.org Date: Mon, 19 May 2014 10:53:51 +0200 MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/1.0 (MacIntel) Archived-At: http://mailarchive.ietf.org/arch/msg/new-work/ikv7ktPcmfOpDomYgmAOR2NcRt8 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/GzFPRnzROknOMRO-J9VCcmDP7H4 X-Mailman-Approved-At: Mon, 19 May 2014 01:56:06 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: XML Processing Model Working Group (until 2014-06-19) 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, 19 May 2014 08:53:57 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Extensible Markup Language (XML) [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the XML Processing Model Working Group: http://www.w3.org/XML/2014/03/xproc-charter.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2014-06-19 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Liam Quin , Team Contact and XML Activity Lead. Thank you, Coralie Mercier, W3C Communications [0] http://www.w3.org/XML/ [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Communications Team - http://www.w3.org mailto:coralie@w3.org +336 4322 0001 http://www.w3.org/People/CMercier/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Mon May 19 13:28:10 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F271A0104; Mon, 19 May 2014 13:28:09 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63KeK511WTaK; Mon, 19 May 2014 13:28:03 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 712891A03A2; Mon, 19 May 2014 13:28:00 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id a1so8283668wgh.3 for ; Mon, 19 May 2014 13:27:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=EASNaWZojF9vbDuZVtpsrreUK2yabo/4PFKkeA+wKOU=; b=wNMbqOVuzoiUHPB7plTDhMLdbcCw355h1FvhJ//FaSloM0VYiMip8Qqxhi//YBhees NHaPbU5Tb+hjqMNwc1k1Apzt1whk1RD5xuuUGGK1j/ZPLp/hm44kqJ7sSnTAwVjPVdaI 9etOJxSQw5U1CkiBM4tjbTCxAl69o3XU8jboTNcTy8ibCkZCCMDJ1cuIDzmrwRM2knCg WpOGhLnnU7RJXI9f2FWOY5SOa3qr8QjXyFpTfVDzJ9q4SRkOjqRj0nIE4VWGqfTV8RpW NBqK4koyMwutitDzeVxsE3WGgkASteIKtacW0tOnom64MMhyUJr7NHCtPQb68RAGwF4F +XUw== X-Received: by 10.180.13.113 with SMTP id g17mr574283wic.48.1400531279206; Mon, 19 May 2014 13:27:59 -0700 (PDT) Received: from [10.0.0.5] ([109.66.60.226]) by mx.google.com with ESMTPSA id nb8sm16831717wic.18.2014.05.19.13.27.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 May 2014 13:27:58 -0700 (PDT) Message-ID: <537A694C.60101@gmail.com> Date: Mon, 19 May 2014 23:27:56 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" , IETF Security Directorate , The IESG , "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/1Uzsx1c1uutxF4A9Ysk28QFEq2w Cc: "manavbhatia@gmail.com" Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 20:28:09 -0000 Hi Manav, thanks for your response. Please see clarifications below. Yaron On 05/19/2014 03:17 AM, Bhatia, Manav (Manav) wrote: > Hi Yaron, > > Thanks for the comments. My comments inline. > >> >> • The main issue is that only a symmetric crypto option is defined. >> IMHO, adding a public-key based scheme would be invaluable. Public keys >> do not necessarily imply certificates, and can be used with little >> added >> complexity compared to the current proposal. As far as I can see, the >> current use is not so performance constrained to preclude public key >> operations. And public keys would enable much easier and more secure >> deployment in many cases: >> ∘ Different organizations can accept messages from one another, >> without >> needing to share the same keys. So even if groups keys are used (which >> is certainly not the best practice), public keys have an advantage. >> ∘ Revocation is much simpler: to be able to revoke each >> individual >> sender (e.g. when a router is decomissioned), you need N**2 SAs in the >> symmetric case, vs. N keys when public keys are used. > > The idea behind this draft is to bring LDP HELLO's security to at least the same level as the routing protocols running in the same networks today. All IGPs are currently using a symmetric crypto option and we think it is ok at this point in time to continue with the same for LDP. > > With SDN principles its possible that the key distribution becomes quite simple with a central controller distributing the keys to all the nodes in the network along with the other information. This also seems to be one of the thoughts behind not pursuing an automated key management protocol for IGPs (something that we were supposed to take up as part of the Phase 2 in the KARP WG -- you can look at RFC 6518 for more details). > > Given this I would like to continue with what we have and look at other mechanisms once we have more clarity on the direction which we seem to be heading towards. > > Also finally note that this security is always within a providers network -- there isnt a need to involve different organizations. > I understand the statement "we do not know where we're going, so let's not over-design now". But note that even with SDN and even with a key management protocol, public keys have an advantage over symmetric keys for this scenario. And if you have automated key management/distribution, the simplicity of symmetric keys actually becomes less important. >> • Managing the 32-bit SAID manually in a large network is extremely >> onerous. So in practice keys would be rarely on never changed. > > Ok, so whats the point? That you need automated key management, otherwise this mechanism is an overkill. > >> >> • 2.2: the authentication algorithm and the authentication key are not >> "independent", because the algorithm normally determines the key >> length. > > This is nit-picking and sure we can remove the word "independent". When defining the Authentication Key we do mention that it depends on the algo. > Sure, this is a nit. > Authentication Key > > This value denotes the cryptographic authentication key associated > with the LDP SA. The length of this key is variable and depends > upon the authentication algorithm specified by the LDP SA. Good. > >> >> • 2.2: the various time values included in the SA essentially require >> (rough) time synchronization between the nodes. If this is the case, >> time values could have been used for replay protection, which would >> have >> been much simpler to implement than the 64-bit sequence number which >> needs to persist across reboots. > > The various timers are only associated if somebody wants to rollover the keys. The granularity of these timers can be coarse (implementation specific) and will not be secure enough to use for anti replay protection. Note that the timer values are optional (the draft says they can be left "unspecified"), but the draft doesn't say what value should be in the field if the values are to be omitted. I *guess* it should be "0", please clarify it. > > Moreover, without the 64 bit sequence numbers, its very difficult to protect against inter-session replay attacks (RFC 6862) That really depends on what data is signed by the key. But I see your point. > >> >> • 5.1: Redefining HMAC (RFC 2104) is an extremely bad idea. This >> reviewer does not have the appropriate background to critique the >> proposed solution, but there must be an overwhelming reason to reopen >> cryptographic primitives. > > This is a decision that was taken by Sec Ads when we were doing the crypto protection for the IGPs based on some feedback from NIST. This mathematics is not new and has been done for all IGPs and has been approved and rather encouraged by the Security ADs. > Then I guess I disagree, but I am not familiar with the background for this decision. >> >> • 7: 128-bit keys are OK (or overkill) for some algorithms, but too >> short for others. In general, the recommended key length is not >> constant. It depends on the algorithm. > > This needs to be punched on each router console. For an internal network, do you think 128 bit isnt good enough? Personally, I think 128 bits are great :-) Seriously, if people are using HMAC-SHA-512 then 128 is not appropriate. You can argue that you don't need more than 128 bits of entropy, but then I would suggest to remove SHA-512 from the draft. The general point is that different algorithms require different key lengths. >> >> • "The mechanism described herein is not perfect and does not need to >> be >> perfect." This is kind of vague, and would be better replaced by your >> security goals. > > I think we can just delete this! :-) Please do. > > Cheers, Manav > >> >> Thanks, >> Yaron From nobody Mon May 19 14:00:10 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79211A03FC; Mon, 19 May 2014 14:00:06 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcbOLT1L5W7j; Mon, 19 May 2014 14:00:01 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0185.outbound.protection.outlook.com [207.46.163.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7E1A1A0406; Mon, 19 May 2014 14:00:00 -0700 (PDT) Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) with Microsoft SMTP Server (TLS) id 15.0.944.11; Mon, 19 May 2014 20:59:58 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.00.0944.000; Mon, 19 May 2014 20:59:58 +0000 From: Ross Callon To: Yaron Sheffer , "Bhatia, Manav (Manav)" , IETF Security Directorate , The IESG , "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" Thread-Topic: SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 Thread-Index: AQHPcRAwnFF8f91/L0WeYr0cLsFf95tHDTIAgAFSUACAAAf8gA== Date: Mon, 19 May 2014 20:59:57 +0000 Message-ID: <00ea53d8fd3e4bf9b2fb3a9c4266bdfd@CO2PR05MB636.namprd05.prod.outlook.com> References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> In-Reply-To: <537A694C.60101@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.13] x-forefront-prvs: 021670B4D2 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(377454003)(479174003)(51704005)(164054003)(13464003)(189002)(199002)(51914003)(24454002)(76482001)(80022001)(66066001)(20776003)(64706001)(85852003)(77982001)(77096999)(83072002)(81542001)(21056001)(31966008)(74502001)(50986999)(101416001)(74662001)(76176999)(54356999)(74316001)(99286001)(46102001)(87936001)(2656002)(81342001)(99396002)(76576001)(92566001)(86362001)(19580405001)(83322001)(19580395003)(4396001)(79102001)(33646001)(561944003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB636; H:CO2PR05MB636.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rcallon@juniper.net; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/CBe9wZQzewiTiN3-rA_n1q1Okx4 Cc: "manavbhatia@gmail.com" , Ross Callon Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 21:00:07 -0000 SSBoYXZlIHdoYXQgbWF5IGJlIGEgc2xpZ2h0bHkgaWdub3JhbnQgcXVlc3Rpb24sIGJ1dC4uLg0K DQpXaGVuIEkgbG9va2VkIGF0IGF1dG9tYXRlZCBrZXkgbWFuYWdlbWVudCBwcm90b2NvbHMgbWFu eSB5ZWFycyBhZ28sIHRoZXkgd29ya2VkIGJldHdlZW4gdHdvIHN5c3RlbXMgKHN5c3RlbSBBIHRh bGtzIHRvIHN5c3RlbSBCKS4gSW4gcGFydGljdWxhciwgYXQgc29tZSBwb2ludCBtdWx0aXBsZSB5 ZWFycyBhZ28gdGhlIGF1dG9tYXRlZCBrZXkgbWFuYWdlbWVudCBwcm90b2NvbHMgZGlkIG5vdCB3 b3JrIGJldHdlZW4gbWFueSByb3V0ZXJzIGFsbCB0YWxraW5nIHRvIGVhY2ggb3RoZXIgYWNyb3Nz IGEgYnJvYWRjYXN0IExBTiwgd2hpY2ggZm9yIGV4YW1wbGUgbWlnaHQgbmVlZCB0byBtdWx0aWNh c3Qgcm91dGluZyB0cmFmZmljIGFtb25nIHRoZW1zZWx2ZXMuIA0KDQpJcyB0aGlzIHN0aWxsIHRy dWU/IA0KDQpUaGFua3MsIFJvc3MNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IFlhcm9uIFNoZWZmZXIgW21haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb21dIA0KU2VudDogTW9u ZGF5LCBNYXkgMTksIDIwMTQgNDoyOCBQTQ0KVG86IEJoYXRpYSwgTWFuYXYgKE1hbmF2KTsgSUVU RiBTZWN1cml0eSBEaXJlY3RvcmF0ZTsgVGhlIElFU0c7IGRyYWZ0LWlldGYtbXBscy1sZHAtaGVs bG8tY3J5cHRvLWF1dGguYWxsQHRvb2xzLmlldGYub3JnDQpDYzogbWFuYXZiaGF0aWFAZ21haWwu Y29tDQpTdWJqZWN0OiBSZTogU2VjRGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLW1wbHMtbGRwLWhl bGxvLWNyeXB0by1hdXRoLTA1DQoNCkhpIE1hbmF2LCB0aGFua3MgZm9yIHlvdXIgcmVzcG9uc2Uu IFBsZWFzZSBzZWUgY2xhcmlmaWNhdGlvbnMgYmVsb3cuDQoNCglZYXJvbg0KDQpPbiAwNS8xOS8y MDE0IDAzOjE3IEFNLCBCaGF0aWEsIE1hbmF2IChNYW5hdikgd3JvdGU6DQo+IEhpIFlhcm9uLA0K Pg0KPiBUaGFua3MgZm9yIHRoZSBjb21tZW50cy4gTXkgY29tbWVudHMgaW5saW5lLg0KPg0KPj4N Cj4+IOKAoiBUaGUgbWFpbiBpc3N1ZSBpcyB0aGF0IG9ubHkgYSBzeW1tZXRyaWMgY3J5cHRvIG9w dGlvbiBpcyBkZWZpbmVkLg0KPj4gSU1ITywgYWRkaW5nIGEgcHVibGljLWtleSBiYXNlZCBzY2hl bWUgd291bGQgYmUgaW52YWx1YWJsZS4gUHVibGljIGtleXMNCj4+IGRvIG5vdCBuZWNlc3Nhcmls eSBpbXBseSBjZXJ0aWZpY2F0ZXMsIGFuZCBjYW4gYmUgdXNlZCB3aXRoIGxpdHRsZQ0KPj4gYWRk ZWQNCj4+IGNvbXBsZXhpdHkgY29tcGFyZWQgdG8gdGhlIGN1cnJlbnQgcHJvcG9zYWwuIEFzIGZh ciBhcyBJIGNhbiBzZWUsIHRoZQ0KPj4gY3VycmVudCB1c2UgaXMgbm90IHNvIHBlcmZvcm1hbmNl IGNvbnN0cmFpbmVkIHRvIHByZWNsdWRlIHB1YmxpYyBrZXkNCj4+IG9wZXJhdGlvbnMuIEFuZCBw dWJsaWMga2V5cyB3b3VsZCBlbmFibGUgbXVjaCBlYXNpZXIgYW5kIG1vcmUgc2VjdXJlDQo+PiBk ZXBsb3ltZW50IGluIG1hbnkgY2FzZXM6DQo+PiAJ4oiYIERpZmZlcmVudCBvcmdhbml6YXRpb25z IGNhbiBhY2NlcHQgbWVzc2FnZXMgZnJvbSBvbmUgYW5vdGhlciwNCj4+IHdpdGhvdXQNCj4+IG5l ZWRpbmcgdG8gc2hhcmUgdGhlIHNhbWUga2V5cy4gU28gZXZlbiBpZiBncm91cHMga2V5cyBhcmUg dXNlZCAod2hpY2gNCj4+IGlzIGNlcnRhaW5seSBub3QgdGhlIGJlc3QgcHJhY3RpY2UpLCBwdWJs aWMga2V5cyBoYXZlIGFuIGFkdmFudGFnZS4NCj4+IAniiJggUmV2b2NhdGlvbiBpcyBtdWNoIHNp bXBsZXI6IHRvIGJlIGFibGUgdG8gcmV2b2tlIGVhY2gNCj4+IGluZGl2aWR1YWwNCj4+IHNlbmRl ciAoZS5nLiB3aGVuIGEgcm91dGVyIGlzIGRlY29taXNzaW9uZWQpLCB5b3UgbmVlZCBOKioyIFNB cyBpbiB0aGUNCj4+IHN5bW1ldHJpYyBjYXNlLCB2cy4gTiBrZXlzIHdoZW4gcHVibGljIGtleXMg YXJlIHVzZWQuDQo+DQo+IFRoZSBpZGVhIGJlaGluZCB0aGlzIGRyYWZ0IGlzIHRvIGJyaW5nIExE UCBIRUxMTydzIHNlY3VyaXR5IHRvIGF0IGxlYXN0IHRoZSBzYW1lIGxldmVsIGFzIHRoZSByb3V0 aW5nIHByb3RvY29scyBydW5uaW5nIGluIHRoZSBzYW1lIG5ldHdvcmtzIHRvZGF5LiBBbGwgSUdQ cyBhcmUgY3VycmVudGx5IHVzaW5nIGEgc3ltbWV0cmljIGNyeXB0byBvcHRpb24gYW5kIHdlIHRo aW5rIGl0IGlzIG9rIGF0IHRoaXMgcG9pbnQgaW4gdGltZSB0byBjb250aW51ZSB3aXRoIHRoZSBz YW1lIGZvciBMRFAuDQo+DQo+IFdpdGggU0ROIHByaW5jaXBsZXMgaXRzIHBvc3NpYmxlIHRoYXQg dGhlIGtleSBkaXN0cmlidXRpb24gYmVjb21lcyBxdWl0ZSBzaW1wbGUgd2l0aCBhIGNlbnRyYWwg Y29udHJvbGxlciBkaXN0cmlidXRpbmcgdGhlIGtleXMgdG8gYWxsIHRoZSBub2RlcyBpbiB0aGUg bmV0d29yayBhbG9uZyB3aXRoIHRoZSBvdGhlciBpbmZvcm1hdGlvbi4gVGhpcyBhbHNvIHNlZW1z IHRvIGJlIG9uZSBvZiB0aGUgdGhvdWdodHMgYmVoaW5kIG5vdCBwdXJzdWluZyBhbiBhdXRvbWF0 ZWQga2V5IG1hbmFnZW1lbnQgcHJvdG9jb2wgZm9yIElHUHMgKHNvbWV0aGluZyB0aGF0IHdlIHdl cmUgc3VwcG9zZWQgdG8gdGFrZSB1cCBhcyBwYXJ0IG9mIHRoZSBQaGFzZSAyIGluIHRoZSBLQVJQ IFdHIC0tIHlvdSBjYW4gbG9vayBhdCBSRkMgNjUxOCBmb3IgbW9yZSBkZXRhaWxzKS4NCj4NCj4g R2l2ZW4gdGhpcyBJIHdvdWxkIGxpa2UgdG8gY29udGludWUgd2l0aCB3aGF0IHdlIGhhdmUgYW5k IGxvb2sgYXQgb3RoZXIgbWVjaGFuaXNtcyBvbmNlIHdlIGhhdmUgbW9yZSBjbGFyaXR5IG9uIHRo ZSBkaXJlY3Rpb24gd2hpY2ggd2Ugc2VlbSB0byBiZSBoZWFkaW5nIHRvd2FyZHMuDQo+DQo+IEFs c28gZmluYWxseSBub3RlIHRoYXQgdGhpcyBzZWN1cml0eSBpcyBhbHdheXMgd2l0aGluIGEgcHJv dmlkZXJzIG5ldHdvcmsgLS0gdGhlcmUgaXNudCBhIG5lZWQgdG8gaW52b2x2ZSBkaWZmZXJlbnQg b3JnYW5pemF0aW9ucy4NCj4NCg0KSSB1bmRlcnN0YW5kIHRoZSBzdGF0ZW1lbnQgIndlIGRvIG5v dCBrbm93IHdoZXJlIHdlJ3JlIGdvaW5nLCBzbyBsZXQncyANCm5vdCBvdmVyLWRlc2lnbiBub3ci LiBCdXQgbm90ZSB0aGF0IGV2ZW4gd2l0aCBTRE4gYW5kIGV2ZW4gd2l0aCBhIGtleSANCm1hbmFn ZW1lbnQgcHJvdG9jb2wsIHB1YmxpYyBrZXlzIGhhdmUgYW4gYWR2YW50YWdlIG92ZXIgc3ltbWV0 cmljIGtleXMgDQpmb3IgdGhpcyBzY2VuYXJpby4gQW5kIGlmIHlvdSBoYXZlIGF1dG9tYXRlZCBr ZXkgDQptYW5hZ2VtZW50L2Rpc3RyaWJ1dGlvbiwgdGhlIHNpbXBsaWNpdHkgb2Ygc3ltbWV0cmlj IGtleXMgYWN0dWFsbHkgDQpiZWNvbWVzIGxlc3MgaW1wb3J0YW50Lg0KDQo+PiDigKIgTWFuYWdp bmcgdGhlIDMyLWJpdCBTQUlEIG1hbnVhbGx5IGluIGEgbGFyZ2UgbmV0d29yayBpcyBleHRyZW1l bHkNCj4+IG9uZXJvdXMuIFNvIGluIHByYWN0aWNlIGtleXMgd291bGQgYmUgcmFyZWx5IG9uIG5l dmVyIGNoYW5nZWQuDQo+DQo+IE9rLCBzbyB3aGF0cyB0aGUgcG9pbnQ/DQoNClRoYXQgeW91IG5l ZWQgYXV0b21hdGVkIGtleSBtYW5hZ2VtZW50LCBvdGhlcndpc2UgdGhpcyBtZWNoYW5pc20gaXMg YW4gDQpvdmVya2lsbC4NCg0KPg0KPj4NCj4+IOKAoiAyLjI6IHRoZSBhdXRoZW50aWNhdGlvbiBh bGdvcml0aG0gYW5kIHRoZSBhdXRoZW50aWNhdGlvbiBrZXkgYXJlIG5vdA0KPj4gImluZGVwZW5k ZW50IiwgYmVjYXVzZSB0aGUgYWxnb3JpdGhtIG5vcm1hbGx5IGRldGVybWluZXMgdGhlIGtleQ0K Pj4gbGVuZ3RoLg0KPg0KPiBUaGlzIGlzIG5pdC1waWNraW5nIGFuZCBzdXJlIHdlIGNhbiByZW1v dmUgdGhlIHdvcmQgImluZGVwZW5kZW50Ii4gV2hlbiBkZWZpbmluZyB0aGUgQXV0aGVudGljYXRp b24gS2V5IHdlIGRvIG1lbnRpb24gdGhhdCBpdCBkZXBlbmRzIG9uIHRoZSBhbGdvLg0KPg0KDQpT dXJlLCB0aGlzIGlzIGEgbml0Lg0KDQo+IEF1dGhlbnRpY2F0aW9uIEtleQ0KPg0KPiAgICAgICAg VGhpcyB2YWx1ZSBkZW5vdGVzIHRoZSBjcnlwdG9ncmFwaGljIGF1dGhlbnRpY2F0aW9uIGtleSBh c3NvY2lhdGVkDQo+ICAgICAgICB3aXRoIHRoZSBMRFAgU0EuICBUaGUgbGVuZ3RoIG9mIHRoaXMg a2V5IGlzIHZhcmlhYmxlIGFuZCBkZXBlbmRzDQo+ICAgICAgICB1cG9uIHRoZSBhdXRoZW50aWNh dGlvbiBhbGdvcml0aG0gc3BlY2lmaWVkIGJ5IHRoZSBMRFAgU0EuDQoNCkdvb2QuDQoNCj4NCj4+ DQo+PiDigKIgMi4yOiB0aGUgdmFyaW91cyB0aW1lIHZhbHVlcyBpbmNsdWRlZCBpbiB0aGUgU0Eg ZXNzZW50aWFsbHkgcmVxdWlyZQ0KPj4gKHJvdWdoKSB0aW1lIHN5bmNocm9uaXphdGlvbiBiZXR3 ZWVuIHRoZSBub2Rlcy4gSWYgdGhpcyBpcyB0aGUgY2FzZSwNCj4+IHRpbWUgdmFsdWVzIGNvdWxk IGhhdmUgYmVlbiB1c2VkIGZvciByZXBsYXkgcHJvdGVjdGlvbiwgd2hpY2ggd291bGQNCj4+IGhh dmUNCj4+IGJlZW4gbXVjaCBzaW1wbGVyIHRvIGltcGxlbWVudCB0aGFuIHRoZSA2NC1iaXQgc2Vx dWVuY2UgbnVtYmVyIHdoaWNoDQo+PiBuZWVkcyB0byBwZXJzaXN0IGFjcm9zcyByZWJvb3RzLg0K Pg0KPiBUaGUgdmFyaW91cyB0aW1lcnMgYXJlIG9ubHkgYXNzb2NpYXRlZCBpZiBzb21lYm9keSB3 YW50cyB0byByb2xsb3ZlciB0aGUga2V5cy4gVGhlIGdyYW51bGFyaXR5IG9mIHRoZXNlIHRpbWVy cyBjYW4gYmUgY29hcnNlIChpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYykgYW5kIHdpbGwgbm90IGJl IHNlY3VyZSBlbm91Z2ggdG8gdXNlIGZvciBhbnRpIHJlcGxheSBwcm90ZWN0aW9uLg0KDQpOb3Rl IHRoYXQgdGhlIHRpbWVyIHZhbHVlcyBhcmUgb3B0aW9uYWwgKHRoZSBkcmFmdCBzYXlzIHRoZXkg Y2FuIGJlIGxlZnQgDQoidW5zcGVjaWZpZWQiKSwgYnV0IHRoZSBkcmFmdCBkb2Vzbid0IHNheSB3 aGF0IHZhbHVlIHNob3VsZCBiZSBpbiB0aGUgDQpmaWVsZCBpZiB0aGUgdmFsdWVzIGFyZSB0byBi ZSBvbWl0dGVkLiBJICpndWVzcyogaXQgc2hvdWxkIGJlICIwIiwgDQpwbGVhc2UgY2xhcmlmeSBp dC4NCg0KPg0KPiBNb3Jlb3Zlciwgd2l0aG91dCB0aGUgNjQgYml0IHNlcXVlbmNlIG51bWJlcnMs IGl0cyB2ZXJ5IGRpZmZpY3VsdCB0byBwcm90ZWN0IGFnYWluc3QgaW50ZXItc2Vzc2lvbiByZXBs YXkgYXR0YWNrcyAoUkZDIDY4NjIpDQoNClRoYXQgcmVhbGx5IGRlcGVuZHMgb24gd2hhdCBkYXRh IGlzIHNpZ25lZCBieSB0aGUga2V5LiBCdXQgSSBzZWUgeW91ciBwb2ludC4NCg0KPg0KPj4NCj4+ IOKAoiA1LjE6IFJlZGVmaW5pbmcgSE1BQyAoUkZDIDIxMDQpIGlzIGFuIGV4dHJlbWVseSBiYWQg aWRlYS4gVGhpcw0KPj4gcmV2aWV3ZXIgZG9lcyBub3QgaGF2ZSB0aGUgYXBwcm9wcmlhdGUgYmFj a2dyb3VuZCB0byBjcml0aXF1ZSB0aGUNCj4+IHByb3Bvc2VkIHNvbHV0aW9uLCBidXQgdGhlcmUg bXVzdCBiZSBhbiBvdmVyd2hlbG1pbmcgcmVhc29uIHRvIHJlb3Blbg0KPj4gY3J5cHRvZ3JhcGhp YyBwcmltaXRpdmVzLg0KPg0KPiBUaGlzIGlzIGEgZGVjaXNpb24gdGhhdCB3YXMgdGFrZW4gYnkg U2VjIEFkcyB3aGVuIHdlIHdlcmUgZG9pbmcgdGhlIGNyeXB0byBwcm90ZWN0aW9uIGZvciB0aGUg SUdQcyBiYXNlZCBvbiBzb21lIGZlZWRiYWNrIGZyb20gTklTVC4gVGhpcyBtYXRoZW1hdGljcyBp cyBub3QgbmV3IGFuZCBoYXMgYmVlbiBkb25lIGZvciBhbGwgSUdQcyBhbmQgaGFzIGJlZW4gYXBw cm92ZWQgYW5kIHJhdGhlciBlbmNvdXJhZ2VkIGJ5IHRoZSBTZWN1cml0eSBBRHMuDQo+DQoNClRo ZW4gSSBndWVzcyBJIGRpc2FncmVlLCBidXQgSSBhbSBub3QgZmFtaWxpYXIgd2l0aCB0aGUgYmFj a2dyb3VuZCBmb3IgDQp0aGlzIGRlY2lzaW9uLg0KDQo+Pg0KPj4g4oCiIDc6IDEyOC1iaXQga2V5 cyBhcmUgT0sgKG9yIG92ZXJraWxsKSBmb3Igc29tZSBhbGdvcml0aG1zLCBidXQgdG9vDQo+PiBz aG9ydCBmb3Igb3RoZXJzLiBJbiBnZW5lcmFsLCB0aGUgcmVjb21tZW5kZWQga2V5IGxlbmd0aCBp cyBub3QNCj4+IGNvbnN0YW50LiBJdCBkZXBlbmRzIG9uIHRoZSBhbGdvcml0aG0uDQo+DQo+IFRo aXMgbmVlZHMgdG8gYmUgcHVuY2hlZCBvbiBlYWNoIHJvdXRlciBjb25zb2xlLiBGb3IgYW4gaW50 ZXJuYWwgbmV0d29yaywgZG8geW91IHRoaW5rIDEyOCBiaXQgaXNudCBnb29kIGVub3VnaD8NCg0K UGVyc29uYWxseSwgSSB0aGluayAxMjggYml0cyBhcmUgZ3JlYXQgOi0pIFNlcmlvdXNseSwgaWYg cGVvcGxlIGFyZSANCnVzaW5nIEhNQUMtU0hBLTUxMiB0aGVuIDEyOCBpcyBub3QgYXBwcm9wcmlh dGUuIFlvdSBjYW4gYXJndWUgdGhhdCB5b3UgDQpkb24ndCBuZWVkIG1vcmUgdGhhbiAxMjggYml0 cyBvZiBlbnRyb3B5LCBidXQgdGhlbiBJIHdvdWxkIHN1Z2dlc3QgdG8gDQpyZW1vdmUgU0hBLTUx MiBmcm9tIHRoZSBkcmFmdC4gVGhlIGdlbmVyYWwgcG9pbnQgaXMgdGhhdCBkaWZmZXJlbnQgDQph bGdvcml0aG1zIHJlcXVpcmUgZGlmZmVyZW50IGtleSBsZW5ndGhzLg0KDQo+Pg0KPj4g4oCiICJU aGUgbWVjaGFuaXNtIGRlc2NyaWJlZCBoZXJlaW4gaXMgbm90IHBlcmZlY3QgYW5kIGRvZXMgbm90 IG5lZWQgdG8NCj4+IGJlDQo+PiBwZXJmZWN0LiIgVGhpcyBpcyBraW5kIG9mIHZhZ3VlLCBhbmQg d291bGQgYmUgYmV0dGVyIHJlcGxhY2VkIGJ5IHlvdXINCj4+IHNlY3VyaXR5IGdvYWxzLg0KPg0K PiBJIHRoaW5rIHdlIGNhbiBqdXN0IGRlbGV0ZSB0aGlzISA6LSkNCg0KUGxlYXNlIGRvLg0KDQo+ DQo+IENoZWVycywgTWFuYXYNCj4NCj4+DQo+PiBUaGFua3MsDQo+PiAJWWFyb24NCg== From nobody Mon May 19 14:16:51 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B7B1A038B; Mon, 19 May 2014 14:16:47 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hYsg1CvN6yB; Mon, 19 May 2014 14:16:45 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8440F1A0176; Mon, 19 May 2014 14:16:44 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id f8so4874885wiw.8 for ; Mon, 19 May 2014 14:16:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=qBz5p210DiQmsvWhCqMET+O5IQToN2iBw3X8rYZJacM=; b=k+gLNcbmTzWJ3SupzeL6Oi4p75U4UkjTOYpXesJgrKeEHp+w0fyR39kbpnB0CMYtqm MFQp5Gje7hCO1iUFnCswOso95xHuBGR6RFFvzR7aprQqwLqOcHhuWLQx+5ONyteqT1VC BL32NYxi31h2bvXzabqo8G7ZmiolcqXHK3e6M0egrdUiiE7O23x0Emfeo9kQwk4WW98z vTfnbech32SAPKXk8aa3u5xqBlXVoccFl8zZ/Svu5J5eLiTwgR4z/ZNM7aAtSeJXnM+J gSDrQkWQ4wKfG7mKD3n1YYI9dMemQXuUdspFtt8wFajiaXs6QXjhRhBTmCQtuPVAknUd S64Q== X-Received: by 10.180.187.111 with SMTP id fr15mr620459wic.57.1400534203106; Mon, 19 May 2014 14:16:43 -0700 (PDT) Received: from [10.0.0.5] (bzq-109-66-60-226.red.bezeqint.net. [109.66.60.226]) by mx.google.com with ESMTPSA id dk10sm8532533wib.1.2014.05.19.14.16.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 May 2014 14:16:42 -0700 (PDT) Message-ID: <537A74B9.6000107@gmail.com> Date: Tue, 20 May 2014 00:16:41 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Ross Callon , "Bhatia, Manav (Manav)" , IETF Security Directorate , The IESG , "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> <00ea53d8fd3e4bf9b2fb3a9c4266bdfd@CO2PR05MB636.namprd05.prod.outlook.com> In-Reply-To: <00ea53d8fd3e4bf9b2fb3a9c4266bdfd@CO2PR05MB636.namprd05.prod.outlook.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/btCVNQYTjBgqfgMWqoskra1DO6Y Cc: "manavbhatia@gmail.com" Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 21:16:47 -0000 It hasn't been a great success (as far as I know), but msec (http://tools.ietf.org/wg/msec/) spent a lot of energy and published a lot of documents in this area. For example, RFC 4535. Thanks, Yaron On 05/19/2014 11:59 PM, Ross Callon wrote: > I have what may be a slightly ignorant question, but... > > When I looked at automated key management protocols many years ago, they worked between two systems (system A talks to system B). In particular, at some point multiple years ago the automated key management protocols did not work between many routers all talking to each other across a broadcast LAN, which for example might need to multicast routing traffic among themselves. > > Is this still true? > > Thanks, Ross > > -----Original Message----- > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > Sent: Monday, May 19, 2014 4:28 PM > To: Bhatia, Manav (Manav); IETF Security Directorate; The IESG; draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org > Cc: manavbhatia@gmail.com > Subject: Re: SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 > > Hi Manav, thanks for your response. Please see clarifications below. > > Yaron > > On 05/19/2014 03:17 AM, Bhatia, Manav (Manav) wrote: >> Hi Yaron, >> >> Thanks for the comments. My comments inline. >> >>> >>> • The main issue is that only a symmetric crypto option is defined. >>> IMHO, adding a public-key based scheme would be invaluable. Public keys >>> do not necessarily imply certificates, and can be used with little >>> added >>> complexity compared to the current proposal. As far as I can see, the >>> current use is not so performance constrained to preclude public key >>> operations. And public keys would enable much easier and more secure >>> deployment in many cases: >>> ∘ Different organizations can accept messages from one another, >>> without >>> needing to share the same keys. So even if groups keys are used (which >>> is certainly not the best practice), public keys have an advantage. >>> ∘ Revocation is much simpler: to be able to revoke each >>> individual >>> sender (e.g. when a router is decomissioned), you need N**2 SAs in the >>> symmetric case, vs. N keys when public keys are used. >> >> The idea behind this draft is to bring LDP HELLO's security to at least the same level as the routing protocols running in the same networks today. All IGPs are currently using a symmetric crypto option and we think it is ok at this point in time to continue with the same for LDP. >> >> With SDN principles its possible that the key distribution becomes quite simple with a central controller distributing the keys to all the nodes in the network along with the other information. This also seems to be one of the thoughts behind not pursuing an automated key management protocol for IGPs (something that we were supposed to take up as part of the Phase 2 in the KARP WG -- you can look at RFC 6518 for more details). >> >> Given this I would like to continue with what we have and look at other mechanisms once we have more clarity on the direction which we seem to be heading towards. >> >> Also finally note that this security is always within a providers network -- there isnt a need to involve different organizations. >> > > I understand the statement "we do not know where we're going, so let's > not over-design now". But note that even with SDN and even with a key > management protocol, public keys have an advantage over symmetric keys > for this scenario. And if you have automated key > management/distribution, the simplicity of symmetric keys actually > becomes less important. > >>> • Managing the 32-bit SAID manually in a large network is extremely >>> onerous. So in practice keys would be rarely on never changed. >> >> Ok, so whats the point? > > That you need automated key management, otherwise this mechanism is an > overkill. > >> >>> >>> • 2.2: the authentication algorithm and the authentication key are not >>> "independent", because the algorithm normally determines the key >>> length. >> >> This is nit-picking and sure we can remove the word "independent". When defining the Authentication Key we do mention that it depends on the algo. >> > > Sure, this is a nit. > >> Authentication Key >> >> This value denotes the cryptographic authentication key associated >> with the LDP SA. The length of this key is variable and depends >> upon the authentication algorithm specified by the LDP SA. > > Good. > >> >>> >>> • 2.2: the various time values included in the SA essentially require >>> (rough) time synchronization between the nodes. If this is the case, >>> time values could have been used for replay protection, which would >>> have >>> been much simpler to implement than the 64-bit sequence number which >>> needs to persist across reboots. >> >> The various timers are only associated if somebody wants to rollover the keys. The granularity of these timers can be coarse (implementation specific) and will not be secure enough to use for anti replay protection. > > Note that the timer values are optional (the draft says they can be left > "unspecified"), but the draft doesn't say what value should be in the > field if the values are to be omitted. I *guess* it should be "0", > please clarify it. > >> >> Moreover, without the 64 bit sequence numbers, its very difficult to protect against inter-session replay attacks (RFC 6862) > > That really depends on what data is signed by the key. But I see your point. > >> >>> >>> • 5.1: Redefining HMAC (RFC 2104) is an extremely bad idea. This >>> reviewer does not have the appropriate background to critique the >>> proposed solution, but there must be an overwhelming reason to reopen >>> cryptographic primitives. >> >> This is a decision that was taken by Sec Ads when we were doing the crypto protection for the IGPs based on some feedback from NIST. This mathematics is not new and has been done for all IGPs and has been approved and rather encouraged by the Security ADs. >> > > Then I guess I disagree, but I am not familiar with the background for > this decision. > >>> >>> • 7: 128-bit keys are OK (or overkill) for some algorithms, but too >>> short for others. In general, the recommended key length is not >>> constant. It depends on the algorithm. >> >> This needs to be punched on each router console. For an internal network, do you think 128 bit isnt good enough? > > Personally, I think 128 bits are great :-) Seriously, if people are > using HMAC-SHA-512 then 128 is not appropriate. You can argue that you > don't need more than 128 bits of entropy, but then I would suggest to > remove SHA-512 from the draft. The general point is that different > algorithms require different key lengths. > >>> >>> • "The mechanism described herein is not perfect and does not need to >>> be >>> perfect." This is kind of vague, and would be better replaced by your >>> security goals. >> >> I think we can just delete this! :-) > > Please do. > >> >> Cheers, Manav >> >>> >>> Thanks, >>> Yaron From nobody Tue May 20 02:57:16 2014 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 7E5F81A0671; Tue, 20 May 2014 02:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1400579063; bh=cEa39gW+Jy87xCTmJdwgUverf3zIVTpsY/EgI5RdTYM=; h=To:Date:MIME-Version:From:Message-ID:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=RE1IR5uBR8H5XB53cb8eN4wJKCFhm0+l+9e7CwpHnPwu92hpQLblh9crPCy7UK7wo ZR7SQF0TyxgyWXBcCi5qlzcqsboxW/q5ezUk2XTdzhx7rasO3iRN5ZlNLlym7644l+ zBsgNzeGXOCBolU7CL6MWRzn+xr+7lT9ZbGyFdZA= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63AF1A0671 for ; Tue, 20 May 2014 02:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGzCOY4QuXlo for ; Tue, 20 May 2014 02:44:19 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3C631A066D for ; Tue, 20 May 2014 02:44:19 -0700 (PDT) Received: from eb.bleuazur.com ([88.173.33.195] helo=sith.local) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Wmgao-00032y-IC; Tue, 20 May 2014 05:44:18 -0400 To: new-work@ietf.org Date: Tue, 20 May 2014 11:44:17 +0200 MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/1.0 (MacIntel) Archived-At: http://mailarchive.ietf.org/arch/msg/new-work/HFdZ4Jpz5rtzTrLaismx168dXoA X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/8iIdy7CL2LvfHB_lVwAd_QKbT8c X-Mailman-Approved-At: Tue, 20 May 2014 02:57:12 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Social Activity (until 2014-06-18) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 09:44:23 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to review the Social Activity proposal [0] (see the W3C Process Document description of Activity Proposals [1]): Social Activity proposal: https://www.w3.org/2013/socialweb/social-activity-proposal.html This proposal includes draft charters for the following groups: Social Web Working Group Charter http://www.w3.org/2013/socialweb/social-wg-charter.html Social Interest Group Charter http://www.w3.org/2013/socialweb/social-ig-charter.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2014-06-18 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Harry Halpin, W3C Team Contact . Thank you, Coralie Mercier, W3C Communications [0] https://www.w3.org/2013/socialweb/social-activity-proposal.html [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Communications Team - http://www.w3.org mailto:coralie@w3.org +336 4322 0001 http://www.w3.org/People/CMercier/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Tue May 20 03:35:56 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16DD51A0683; Tue, 20 May 2014 03:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iz13C1R-9L41; Tue, 20 May 2014 03:35:48 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 185671A0682; Tue, 20 May 2014 03:35:47 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s4KAZj1a005694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 May 2014 05:35:45 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s4KAZidA020152 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 May 2014 06:35:45 -0400 Received: from SG70XWXCHHUB02.zap.alcatel-lucent.com (135.253.2.47) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 20 May 2014 06:35:44 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.212]) by SG70XWXCHHUB02.zap.alcatel-lucent.com ([135.253.2.47]) with mapi id 14.02.0247.003; Tue, 20 May 2014 18:35:39 +0800 From: "Bhatia, Manav (Manav)" To: Yaron Sheffer , IETF Security Directorate , The IESG , "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" Thread-Topic: SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 Thread-Index: AQHPcRACnDeFnD7gHUOXWsSAGM4MlZtGKCeAgAGxPwCAAWJn0A== Date: Tue, 20 May 2014 10:35:38 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E60AAFE@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> In-Reply-To: <537A694C.60101@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/lg1FYPa8vJ30qMJz9NMqm8jtlNM Cc: "manavbhatia@gmail.com" Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 10:35:50 -0000 SGkgWWFyb24sDQogDQo+IEkgdW5kZXJzdGFuZCB0aGUgc3RhdGVtZW50ICJ3ZSBkbyBub3Qga25v dyB3aGVyZSB3ZSdyZSBnb2luZywgc28gbGV0J3MNCj4gbm90IG92ZXItZGVzaWduIG5vdyIuIEJ1 dCBub3RlIHRoYXQgZXZlbiB3aXRoIFNETiBhbmQgZXZlbiB3aXRoIGEga2V5DQo+IG1hbmFnZW1l bnQgcHJvdG9jb2wsIHB1YmxpYyBrZXlzIGhhdmUgYW4gYWR2YW50YWdlIG92ZXIgc3ltbWV0cmlj IGtleXMNCj4gZm9yIHRoaXMgc2NlbmFyaW8uIEFuZCBpZiB5b3UgaGF2ZSBhdXRvbWF0ZWQga2V5 DQo+IG1hbmFnZW1lbnQvZGlzdHJpYnV0aW9uLCB0aGUgc2ltcGxpY2l0eSBvZiBzeW1tZXRyaWMg a2V5cyBhY3R1YWxseQ0KPiBiZWNvbWVzIGxlc3MgaW1wb3J0YW50Lg0KDQpBcyBwZXIgdGhlIEtB UlAgZGVzaWduIGd1aWRlIChSRkMgNjUxOCkgd2Ugd2VyZSB0YWtpbmcgdGhpcyB1cCBpbiB0aGUg c3Vic2VxdWVudCBwaGFzZXMgb2YgS0FSUCB3b3JrIGxpZmUgY3ljbGUuIFRoZSBQaGFzZSBJIGlu aXRpYWxseSB1cGRhdGVzIGFsbCBwcm90b2NvbHMgd2l0aCB0aGUgbGF0ZXN0IGFsZ29yaXRobXMg YW5kIGtleSBhZ2lsaXR5IChyb2xsb3ZlcikuIEFueXRoaW5nIGJleW9uZCB0aGF0IGlzIHRoZSBu ZXh0IHN0ZXAuDQoNCldoYXQgd2UncmUgZG9pbmcgaGVyZSBpcyB1cGRhdGluZyBMRFAgd2l0aCBz dHJvbmdlciBhbGdvcyBhbmQgZW5zdXJpbmcgdGhhdCBrZXlzIGNhbiBiZSBlYXNpbHkgcm9sbGVk IG92ZXIgd2l0aG91dCBkaXNydXB0aW5nIHRoZSBwcm90b2NvbC4NCg0KPiANCj4gPj4g4oCiIE1h bmFnaW5nIHRoZSAzMi1iaXQgU0FJRCBtYW51YWxseSBpbiBhIGxhcmdlIG5ldHdvcmsgaXMgZXh0 cmVtZWx5DQo+ID4+IG9uZXJvdXMuIFNvIGluIHByYWN0aWNlIGtleXMgd291bGQgYmUgcmFyZWx5 IG9uIG5ldmVyIGNoYW5nZWQuDQo+ID4NCj4gPiBPaywgc28gd2hhdHMgdGhlIHBvaW50Pw0KPiAN Cj4gVGhhdCB5b3UgbmVlZCBhdXRvbWF0ZWQga2V5IG1hbmFnZW1lbnQsIG90aGVyd2lzZSB0aGlz IG1lY2hhbmlzbSBpcyBhbg0KPiBvdmVya2lsbC4NCg0KQWdhaW4sIGFzIHBlciBLQVJQIGRlc2ln biBQaGFzZSBJLCB3ZSBuZWVkIHRvIGdldCBhbGwgcm91dGluZyBwcm90b2NvbHMgdG8gYSBjZXJ0 YWluIG1pbmltdW0gbGV2ZWwuIFJlZGVzaWduaW5nIHRoZSBwcm90b2NvbCBmb3IgYW4gYXV0b21h dGVkIGtleSBtYW5hZ2VtZW50IHByb3RvY29sIGlzIFBoYXNlIElJLg0KDQo+IA0KPiA+DQo+ID4+ DQo+ID4+IOKAoiAyLjI6IHRoZSB2YXJpb3VzIHRpbWUgdmFsdWVzIGluY2x1ZGVkIGluIHRoZSBT QSBlc3NlbnRpYWxseQ0KPiByZXF1aXJlDQo+ID4+IChyb3VnaCkgdGltZSBzeW5jaHJvbml6YXRp b24gYmV0d2VlbiB0aGUgbm9kZXMuIElmIHRoaXMgaXMgdGhlIGNhc2UsDQo+ID4+IHRpbWUgdmFs dWVzIGNvdWxkIGhhdmUgYmVlbiB1c2VkIGZvciByZXBsYXkgcHJvdGVjdGlvbiwgd2hpY2ggd291 bGQNCj4gPj4gaGF2ZQ0KPiA+PiBiZWVuIG11Y2ggc2ltcGxlciB0byBpbXBsZW1lbnQgdGhhbiB0 aGUgNjQtYml0IHNlcXVlbmNlIG51bWJlciB3aGljaA0KPiA+PiBuZWVkcyB0byBwZXJzaXN0IGFj cm9zcyByZWJvb3RzLg0KPiA+DQo+ID4gVGhlIHZhcmlvdXMgdGltZXJzIGFyZSBvbmx5IGFzc29j aWF0ZWQgaWYgc29tZWJvZHkgd2FudHMgdG8gcm9sbG92ZXINCj4gdGhlIGtleXMuIFRoZSBncmFu dWxhcml0eSBvZiB0aGVzZSB0aW1lcnMgY2FuIGJlIGNvYXJzZSAoaW1wbGVtZW50YXRpb24NCj4g c3BlY2lmaWMpIGFuZCB3aWxsIG5vdCBiZSBzZWN1cmUgZW5vdWdoIHRvIHVzZSBmb3IgYW50aSBy ZXBsYXkNCj4gcHJvdGVjdGlvbi4NCj4gDQo+IE5vdGUgdGhhdCB0aGUgdGltZXIgdmFsdWVzIGFy ZSBvcHRpb25hbCAodGhlIGRyYWZ0IHNheXMgdGhleSBjYW4gYmUNCj4gbGVmdA0KPiAidW5zcGVj aWZpZWQiKSwgYnV0IHRoZSBkcmFmdCBkb2Vzbid0IHNheSB3aGF0IHZhbHVlIHNob3VsZCBiZSBp biB0aGUNCj4gZmllbGQgaWYgdGhlIHZhbHVlcyBhcmUgdG8gYmUgb21pdHRlZC4gSSAqZ3Vlc3Mq IGl0IHNob3VsZCBiZSAiMCIsDQo+IHBsZWFzZSBjbGFyaWZ5IGl0Lg0KDQpXZSBoYXZlIHRoZSBm b2xsb3dpbmcgdGV4dCBpbiB0aGUgZHJhZnQ6DQoNCiAgIEluIG9yZGVyIHRvIGFjaGlldmUgc21v b3RoIGtleSB0cmFuc2l0aW9uLCBLZXlTdGFydEFjY2VwdCBTSE9VTEQgYmUNCiAgIGxlc3MgdGhh biBLZXlTdGFydEdlbmVyYXRlIGFuZCBLZXlTdG9wR2VuZXJhdGUgU0hPVUxEIGJlIGxlc3MgdGhh bg0KICAgS2V5U3RvcEFjY2VwdC4gIElmIEtleVN0YXJ0R2VuZXJhdGUgb3IgS2V5U3RhcnRBY2Nl cHQgYXJlIGxlZnQNCiAgIHVuc3BlY2lmaWVkLCB0aGUgdGltZSB3aWxsIGRlZmF1bHQgdG8gMCBh bmQgdGhlIGtleSB3aWxsIGJlIHVzZWQNCiAgIGltbWVkaWF0ZWx5LiAgSWYgS2V5U3RvcEdlbmVy YXRlIG9yIEtleVN0b3BBY2NlcHQgYXJlIGxlZnQNCiAgIHVuc3BlY2lmaWVkLCB0aGUgdGltZSB3 aWxsIGRlZmF1bHQgdG8gaW5maW5pdHkgYW5kIHRoZSBrZXkncyBsaWZldGltZQ0KICAgd2lsbCBi ZSBpbmZpbml0ZS4NCg0KQ2FuIHlvdSBzdWdnZXN0IHdoYXQgZWxzZSBuZWVkcyB0byBiZSBhZGRl ZCB0byBtYWtlIGl0IGNsZWFyZXI/DQoNCj4gDQo+ID4NCj4gPiBNb3Jlb3Zlciwgd2l0aG91dCB0 aGUgNjQgYml0IHNlcXVlbmNlIG51bWJlcnMsIGl0cyB2ZXJ5IGRpZmZpY3VsdCB0bw0KPiBwcm90 ZWN0IGFnYWluc3QgaW50ZXItc2Vzc2lvbiByZXBsYXkgYXR0YWNrcyAoUkZDIDY4NjIpDQo+IA0K PiBUaGF0IHJlYWxseSBkZXBlbmRzIG9uIHdoYXQgZGF0YSBpcyBzaWduZWQgYnkgdGhlIGtleS4g QnV0IEkgc2VlIHlvdXINCj4gcG9pbnQuDQoNCkdvb2R5Lg0KDQo+ID4NCj4gPiBUaGlzIGlzIGEg ZGVjaXNpb24gdGhhdCB3YXMgdGFrZW4gYnkgU2VjIEFkcyB3aGVuIHdlIHdlcmUgZG9pbmcgdGhl DQo+IGNyeXB0byBwcm90ZWN0aW9uIGZvciB0aGUgSUdQcyBiYXNlZCBvbiBzb21lIGZlZWRiYWNr IGZyb20gTklTVC4gVGhpcw0KPiBtYXRoZW1hdGljcyBpcyBub3QgbmV3IGFuZCBoYXMgYmVlbiBk b25lIGZvciBhbGwgSUdQcyBhbmQgaGFzIGJlZW4NCj4gYXBwcm92ZWQgYW5kIHJhdGhlciBlbmNv dXJhZ2VkIGJ5IHRoZSBTZWN1cml0eSBBRHMuDQo+ID4NCj4gDQo+IFRoZW4gSSBndWVzcyBJIGRp c2FncmVlLCBidXQgSSBhbSBub3QgZmFtaWxpYXIgd2l0aCB0aGUgYmFja2dyb3VuZCBmb3INCj4g dGhpcyBkZWNpc2lvbi4NCg0KSSBhbSBzdXJlIHRoZSBTZWN1cml0eSBhbmQgdGhlIFJvdXRpbmcg QURzIGNhbiBoZWxwIHlvdSB3aXRoIHRoZSBoaXN0b3J5LiANCg0KPiANCj4gPj4NCj4gPj4g4oCi IDc6IDEyOC1iaXQga2V5cyBhcmUgT0sgKG9yIG92ZXJraWxsKSBmb3Igc29tZSBhbGdvcml0aG1z LCBidXQgdG9vDQo+ID4+IHNob3J0IGZvciBvdGhlcnMuIEluIGdlbmVyYWwsIHRoZSByZWNvbW1l bmRlZCBrZXkgbGVuZ3RoIGlzIG5vdA0KPiA+PiBjb25zdGFudC4gSXQgZGVwZW5kcyBvbiB0aGUg YWxnb3JpdGhtLg0KPiA+DQo+ID4gVGhpcyBuZWVkcyB0byBiZSBwdW5jaGVkIG9uIGVhY2ggcm91 dGVyIGNvbnNvbGUuIEZvciBhbiBpbnRlcm5hbA0KPiBuZXR3b3JrLCBkbyB5b3UgdGhpbmsgMTI4 IGJpdCBpc250IGdvb2QgZW5vdWdoPw0KPiANCj4gUGVyc29uYWxseSwgSSB0aGluayAxMjggYml0 cyBhcmUgZ3JlYXQgOi0pIFNlcmlvdXNseSwgaWYgcGVvcGxlIGFyZQ0KPiB1c2luZyBITUFDLVNI QS01MTIgdGhlbiAxMjggaXMgbm90IGFwcHJvcHJpYXRlLiBZb3UgY2FuIGFyZ3VlIHRoYXQgeW91 DQo+IGRvbid0IG5lZWQgbW9yZSB0aGFuIDEyOCBiaXRzIG9mIGVudHJvcHksIGJ1dCB0aGVuIEkg d291bGQgc3VnZ2VzdCB0bw0KPiByZW1vdmUgU0hBLTUxMiBmcm9tIHRoZSBkcmFmdC4gVGhlIGdl bmVyYWwgcG9pbnQgaXMgdGhhdCBkaWZmZXJlbnQNCj4gYWxnb3JpdGhtcyByZXF1aXJlIGRpZmZl cmVudCBrZXkgbGVuZ3Rocy4NCg0KSSB0aGluayB5b3UgbWlzc2VkIHRoZSB0ZXh0IGluIFNlYyA1 LjEgd2hpY2ggc2F5czoNCg0KICAgVGhlIExEUCBDcnlwdG9ncmFwaGljIFByb3RvY29sIElEIGlz IGFwcGVuZGVkIHRvIHRoZSBBdXRoZW50aWNhdGlvbg0KICAgS2V5IChLKSB5aWVsZGluZyBhIFBy b3RvY29sIFNwZWNpZmljIEF1dGhlbnRpY2F0aW9uIEtleSAoS3MpLiAgSW4NCiAgIHRoaXMgYXBw bGljYXRpb24sIEtvIGlzIGFsd2F5cyBMIG9jdGV0cyBsb25nLiAgV2hpbGUgW1JGQzIxMDRdDQog ICBzdXBwb3J0cyBhIGtleSB0aGF0IGlzIHVwIHRvIEIgb2N0ZXRzIGxvbmcsIHRoaXMgYXBwbGlj YXRpb24gdXNlcyBMDQogICBhcyB0aGUgS3MgbGVuZ3RoIGNvbnNpc3RlbnQgd2l0aCBbUkZDNDgy Ml0sIFtSRkM1MzEwXSwgW1JGQzU3MDldIGFuZA0KICAgW1JGQzcxNjZdLg0KDQpJbiBjYXNlIG9m IEhNQUMtU0hBLTUxMiB0aGUga2V5IHNpemUgd291bGQgYmUgNTEyIGJpdHMuDQoNCldlIG5ldmVy IHJlc3RyaWN0IHRoZSBrZXkgc2l6ZSB0byAxMjguDQoNCj4gDQo+ID4+DQo+ID4+IOKAoiAiVGhl IG1lY2hhbmlzbSBkZXNjcmliZWQgaGVyZWluIGlzIG5vdCBwZXJmZWN0IGFuZCBkb2VzIG5vdCBu ZWVkDQo+IHRvDQo+ID4+IGJlDQo+ID4+IHBlcmZlY3QuIiBUaGlzIGlzIGtpbmQgb2YgdmFndWUs IGFuZCB3b3VsZCBiZSBiZXR0ZXIgcmVwbGFjZWQgYnkNCj4geW91cg0KPiA+PiBzZWN1cml0eSBn b2Fscy4NCj4gPg0KPiA+IEkgdGhpbmsgd2UgY2FuIGp1c3QgZGVsZXRlIHRoaXMhIDotKQ0KPiAN Cj4gUGxlYXNlIGRvLg0KDQpDb25zaWRlciBpdCBkb25lLg0KDQpDaGVlcnMsIE1hbmF2DQo= From nobody Tue May 20 09:28:02 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F261A01AB for ; Tue, 20 May 2014 09:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUoGxyP3d7MB for ; Tue, 20 May 2014 09:28:00 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 359D81A0169 for ; Tue, 20 May 2014 09:28:00 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:53439) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WmmtV-000LLB-2H; Tue, 20 May 2014 12:28:01 -0400 Message-ID: <537B8284.8030307@bbn.com> Date: Tue, 20 May 2014 12:27:48 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: secdir , zhliu@gsta.com, lizho.jin@gmail.com, chen.ran@zte.com.cn, dcai@cisco.com, ssalam@cisco.com, Adrian Farrel , giheron@cisco.com, nabil.n.bitar@verizon.com References: <534D9EF6.4060106@bbn.com> In-Reply-To: <534D9EF6.4060106@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/RKNcZtjcBGm7CKlFymIJ0hzg-k4 Subject: Re: [secdir] SECDIR review of draft-ietf-l2vpn-vpls-inter-domain-redundancy-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 16:28:01 -0000 I examined the diff of version 6 vs. version 5 (which I reviewed previously). It appears that the authors have addressed all of the concerns cited in my prior review. There are still be a few instances where lowercase "musts" and "shoulds" apear, I'll leave it to the ADs and the RFC Editor to decide how to deal with these. Steve From nobody Tue May 20 13:37:06 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 595961A0791; Tue, 20 May 2014 13:37:02 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMYiS6U6aKu7; Tue, 20 May 2014 13:37:00 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62C331A0793; Tue, 20 May 2014 13:37:00 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id f8so6590169wiw.14 for ; Tue, 20 May 2014 13:36:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=DsQWwEo12usyJGRI+zO43lk4X4nyaDtAZCecjTrf3gA=; b=cfWA67AKFHsPrfSX28tpIiCnFqI97KZz+e4vZbvuQrswkIgxAfXj/btCG3dg2pUAHY PF3c7y9g0b2vKoI72qh6R+tNo6OBL7Xuy21bvU0J2Gf4LkDBST8YgPS2D7ayjxrZk4BL zyekGwHGjwy+gRp8XF78KsZ0zlcB0re38Ch32UufKhrfX7Jk6b59hfX69IvOdRUYUM0B f9LElrKnEfBKKbHVG6sVclmW1ihHQo1BoC4PBi1qFyWFNfBKJOJQjmUP+wJ5/ohoMjTX V2mpSYEIChAiyGcE4+DSpjauGL/Krws+uxDhR2GiNR1q6lU1ZuKgqYUTS/4/vb7RX7/L vJUQ== X-Received: by 10.194.189.116 with SMTP id gh20mr39304224wjc.41.1400618218700; Tue, 20 May 2014 13:36:58 -0700 (PDT) Received: from [10.0.0.5] (bzq-109-66-60-226.red.bezeqint.net. [109.66.60.226]) by mx.google.com with ESMTPSA id nb8sm22558057wic.18.2014.05.20.13.36.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 May 2014 13:36:58 -0700 (PDT) Message-ID: <537BBCE9.3060803@gmail.com> Date: Tue, 20 May 2014 23:36:57 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" , IETF Security Directorate , The IESG , "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> <20211F91F544D247976D84C5D778A4C32E60AAFE@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: <20211F91F544D247976D84C5D778A4C32E60AAFE@SG70YWXCHMBA05.zap.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Qb_5v5pHhKwqu-s_RWFlSutLlwA Cc: "manavbhatia@gmail.com" Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 20:37:02 -0000 Hi Manav, On 05/20/2014 01:35 PM, Bhatia, Manav (Manav) wrote: > Hi Yaron, > [...] >>>> >>>> • 2.2: the various time values included in the SA essentially >> require >>>> (rough) time synchronization between the nodes. If this is the case, >>>> time values could have been used for replay protection, which would >>>> have >>>> been much simpler to implement than the 64-bit sequence number which >>>> needs to persist across reboots. >>> >>> The various timers are only associated if somebody wants to rollover >> the keys. The granularity of these timers can be coarse (implementation >> specific) and will not be secure enough to use for anti replay >> protection. >> >> Note that the timer values are optional (the draft says they can be >> left >> "unspecified"), but the draft doesn't say what value should be in the >> field if the values are to be omitted. I *guess* it should be "0", >> please clarify it. > > We have the following text in the draft: > > In order to achieve smooth key transition, KeyStartAccept SHOULD be > less than KeyStartGenerate and KeyStopGenerate SHOULD be less than > KeyStopAccept. If KeyStartGenerate or KeyStartAccept are left > unspecified, the time will default to 0 and the key will be used > immediately. If KeyStopGenerate or KeyStopAccept are left > unspecified, the time will default to infinity and the key's lifetime > will be infinite. > > Can you suggest what else needs to be added to make it clearer? I suggest to add: "Any unspecified values are encoded as zero." > >> [...] >> >>>> • 7: 128-bit keys are OK (or overkill) for some algorithms, but too >>>> short for others. In general, the recommended key length is not >>>> constant. It depends on the algorithm. >>> >>> This needs to be punched on each router console. For an internal >> network, do you think 128 bit isnt good enough? >> >> Personally, I think 128 bits are great :-) Seriously, if people are >> using HMAC-SHA-512 then 128 is not appropriate. You can argue that you >> don't need more than 128 bits of entropy, but then I would suggest to >> remove SHA-512 from the draft. The general point is that different >> algorithms require different key lengths. > > I think you missed the text in Sec 5.1 which says: > > The LDP Cryptographic Protocol ID is appended to the Authentication > Key (K) yielding a Protocol Specific Authentication Key (Ks). In > this application, Ko is always L octets long. While [RFC2104] > supports a key that is up to B octets long, this application uses L > as the Ks length consistent with [RFC4822], [RFC5310], [RFC5709] and > [RFC7166]. > > In case of HMAC-SHA-512 the key size would be 512 bits. > > We never restrict the key size to 128. > I was referring to the following text, which I still think is misguided: "Deployments SHOULD use sufficiently long and random values for the Authentication Key so that guessing and other cryptographic attacks on the key are not feasible in their environments. Furthermore, it is RECOMMENDED that Authentication Keys incorporate at least 128 pseudo-random bits to minimize the risk of such attacks." Crypto keys should have random bits amounting to their full length, rather than just a 128-bit subset of the key. >> >>>> [...] > > Cheers, Manav > From nobody Tue May 20 14:23:12 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 268521A0400; Tue, 20 May 2014 14:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WWmlXD2MKI0; Tue, 20 May 2014 14:23:05 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B95931A03D3; Tue, 20 May 2014 14:23:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 68ABBBE61; Tue, 20 May 2014 22:23:04 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCS3d7Rj5dx6; Tue, 20 May 2014 22:23:03 +0100 (IST) Received: from [10.87.48.12] (unknown [86.46.25.179]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3C189BE38; Tue, 20 May 2014 22:23:03 +0100 (IST) Message-ID: <537BC7B6.5040406@cs.tcd.ie> Date: Tue, 20 May 2014 22:23:02 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" , IETF Security Directorate , The IESG , "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> In-Reply-To: <537A694C.60101@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/YvyQaehxU8B6tnlb2MV1L8sggOk Cc: "manavbhatia@gmail.com" Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 21:23:07 -0000 On 19/05/14 21:27, Yaron Sheffer wrote: >>> >>> • 5.1: Redefining HMAC (RFC 2104) is an extremely bad idea. This >>> reviewer does not have the appropriate background to critique the >>> proposed solution, but there must be an overwhelming reason to reopen >>> cryptographic primitives. >> >> This is a decision that was taken by Sec Ads when we were doing the >> crypto protection for the IGPs based on some feedback from NIST. This >> mathematics is not new and has been done for all IGPs and has been >> approved and rather encouraged by the Security ADs. The above does not sound like something I recognise. I have repeatedly asked that documents not re-define HMAC. Perhaps this time, I'll make that a DISCUSS and not budge. I probably should have done that before TBH. If you are revising that doc, *please* get rid of the re-definition and just properly refer to HMAC. Its about time to stop repeating that error. S. From nobody Wed May 21 00:20:38 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A121A0466; Wed, 21 May 2014 00:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfDrKzAC5ROv; Wed, 21 May 2014 00:20:33 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EAF01A0245; Wed, 21 May 2014 00:20:33 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s4L7KUwd017464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 May 2014 02:20:30 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s4L7KUrx003392 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 May 2014 03:20:30 -0400 Received: from SG70YWXCHHUB04.zap.alcatel-lucent.com (135.253.2.38) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 21 May 2014 03:20:30 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.212]) by SG70YWXCHHUB04.zap.alcatel-lucent.com ([135.253.2.38]) with mapi id 14.02.0247.003; Wed, 21 May 2014 15:20:27 +0800 From: "Bhatia, Manav (Manav)" To: Yaron Sheffer , IETF Security Directorate , The IESG , "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" Thread-Topic: SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 Thread-Index: AQHPcRACnDeFnD7gHUOXWsSAGM4MlZtGKCeAgAGxPwCAAWJn0IAAMnOAgAE5o+A= Date: Wed, 21 May 2014 07:20:26 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E60B565@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> <20211F91F544D247976D84C5D778A4C32E60AAFE@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537BBCE9.3060803@gmail.com> In-Reply-To: <537BBCE9.3060803@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/yhH7BQURxJCTMDTKj-LXaPsm_A0 Cc: "manavbhatia@gmail.com" Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 07:20:35 -0000 Hi Yaron, > > > > Can you suggest what else needs to be added to make it clearer? >=20 > I suggest to add: "Any unspecified values are encoded as zero." Sure, will do. > > > >> > [...] > >> > >>>> * 7: 128-bit keys are OK (or overkill) for some algorithms, but > too > >>>> short for others. In general, the recommended key length is not > >>>> constant. It depends on the algorithm. > >>> > >>> This needs to be punched on each router console. For an internal > >> network, do you think 128 bit isnt good enough? > >> > >> Personally, I think 128 bits are great :-) Seriously, if people are > >> using HMAC-SHA-512 then 128 is not appropriate. You can argue that > you > >> don't need more than 128 bits of entropy, but then I would suggest > to > >> remove SHA-512 from the draft. The general point is that different > >> algorithms require different key lengths. > > > > I think you missed the text in Sec 5.1 which says: > > > > The LDP Cryptographic Protocol ID is appended to the > Authentication > > Key (K) yielding a Protocol Specific Authentication Key (Ks). In > > this application, Ko is always L octets long. While [RFC2104] > > supports a key that is up to B octets long, this application uses > L > > as the Ks length consistent with [RFC4822], [RFC5310], [RFC5709] > and > > [RFC7166]. > > > > In case of HMAC-SHA-512 the key size would be 512 bits. > > > > We never restrict the key size to 128. > > >=20 > I was referring to the following text, which I still think is > misguided: > "Deployments SHOULD use sufficiently long and random values for the > Authentication Key so that guessing and other cryptographic attacks on > the key are not feasible in their environments. Furthermore, it is > RECOMMENDED that Authentication Keys incorporate at least 128 > pseudo-random bits to minimize the risk of such attacks." >=20 > Crypto keys should have random bits amounting to their full length, > rather than just a 128-bit subset of the key. Thanks for the catch. I agree, it doesn't make sense to use a subset of the= key. Will remove this. Cheers, Manav >=20 > >> > >>>> > [...] >=20 > > > > Cheers, Manav > > From nobody Wed May 21 00:39:30 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354A11A082A; Wed, 21 May 2014 00:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmQptNYZzKIJ; Wed, 21 May 2014 00:39:20 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7163F1A0827; Wed, 21 May 2014 00:39:20 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s4L7dBgv001659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 May 2014 02:39:11 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s4L7d9Jo022790 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 May 2014 03:39:11 -0400 Received: from SG70XWXCHHUB02.zap.alcatel-lucent.com (135.253.2.47) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 21 May 2014 03:39:10 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.212]) by SG70XWXCHHUB02.zap.alcatel-lucent.com ([135.253.2.47]) with mapi id 14.02.0247.003; Wed, 21 May 2014 15:39:07 +0800 From: "Bhatia, Manav (Manav)" To: Stephen Farrell , IETF Security Directorate , The IESG , "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" Thread-Topic: SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 Thread-Index: AQHPcRACnDeFnD7gHUOXWsSAGM4MlZtGKCeAgAGxPwCAAaG6AIABLjlg Date: Wed, 21 May 2014 07:39:06 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E60B609@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> <537BC7B6.5040406@cs.tcd.ie> In-Reply-To: <537BC7B6.5040406@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/8lGZKP-krWReonnQx5JkMKcALcw Cc: "manavbhatia@gmail.com" Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 07:39:24 -0000 Hi Stephen, The crypto mathematics in our draft (and RFC 5310, 5709, 6506, .. and quite= a few other RFCs/drafts) is slightly different from the basic HMAC. In all= these RFCs we've introduced an additional pad (unimaginatively called the = "Apad") that's used in the hash computation. We were asked to include the A= pad when we were originally writing the IS-IS and OSPFv2 security (RFC 5310= and 5709) RFCs. Ran Atkinson along with Mathhew Fanto (from NIST) had earl= ier written the RIPv2 RFC which had first employed the Apad. I was unequivo= cally told (by the Security ADs as well) that the Apad had to be included s= ince that's what NIST wanted. I am sure Ran Atkinson can explain you more c= learly about what the actual deal was. However, ever since then, we've been= including the Apad in all our standards (at least the ones coming out of t= he Routing Area WG). This has now been extensively implemented and there are libraries available= that account for the Apad when computing the hash for the routing protocol= s. The Apad is now employed for RIP, OSPF, OSPFv3. I see no reason why LDP sho= uld be an exception. The same has been proposed for BFD btw. Cheers, Manav > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Wednesday, May 21, 2014 2:53 AM > To: Bhatia, Manav (Manav); IETF Security Directorate; The IESG; draft- > ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org > Cc: Yaron Sheffer; manavbhatia@gmail.com > Subject: Re: SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 >=20 >=20 >=20 > On 19/05/14 21:27, Yaron Sheffer wrote: > >>> > >>> * 5.1: Redefining HMAC (RFC 2104) is an extremely bad idea. This > >>> reviewer does not have the appropriate background to critique the > >>> proposed solution, but there must be an overwhelming reason to > reopen > >>> cryptographic primitives. > >> > >> This is a decision that was taken by Sec Ads when we were doing the > >> crypto protection for the IGPs based on some feedback from NIST. > This > >> mathematics is not new and has been done for all IGPs and has been > >> approved and rather encouraged by the Security ADs. >=20 > The above does not sound like something I recognise. I > have repeatedly asked that documents not re-define HMAC. > Perhaps this time, I'll make that a DISCUSS and not budge. > I probably should have done that before TBH. >=20 > If you are revising that doc, *please* get rid of the > re-definition and just properly refer to HMAC. Its about > time to stop repeating that error. >=20 > S. From nobody Wed May 21 00:55:08 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E751A0835; Wed, 21 May 2014 00:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcw-fh6UXQDE; Wed, 21 May 2014 00:55:03 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0295E1A0831; Wed, 21 May 2014 00:55:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B6592BE53; Wed, 21 May 2014 08:54:56 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcxXU7dR58EL; Wed, 21 May 2014 08:54:55 +0100 (IST) Received: from [193.1.136.127] (dhcp-c101887f.ucd.ie [193.1.136.127]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 43AC9BE51; Wed, 21 May 2014 08:54:55 +0100 (IST) Message-ID: <537C5BCE.4010801@cs.tcd.ie> Date: Wed, 21 May 2014 08:54:54 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" , IETF Security Directorate , The IESG , "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> <537BC7B6.5040406@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B609@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: <20211F91F544D247976D84C5D778A4C32E60B609@SG70YWXCHMBA05.zap.alcatel-lucent.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Z7ZMB5wr8-Vhxh7G8O2cLlB9xdY Cc: "manavbhatia@gmail.com" Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 07:55:05 -0000 Manav, On 21/05/14 08:39, Bhatia, Manav (Manav) wrote: > Hi Stephen, > > The crypto mathematics in our draft (and RFC 5310, 5709, 6506, .. and > quite a few other RFCs/drafts) is slightly different from the basic > HMAC. In all these RFCs we've introduced an additional pad > (unimaginatively called the "Apad") that's used in the hash > computation. We were asked to include the Apad when we were > originally writing the IS-IS and OSPFv2 security (RFC 5310 and 5709) > RFCs. Ran Atkinson along with Mathhew Fanto (from NIST) had earlier > written the RIPv2 RFC which had first employed the Apad. I was > unequivocally told (by the Security ADs as well) that the Apad had to > be included since that's what NIST wanted. I am sure Ran Atkinson can > explain you more clearly about what the actual deal was. However, > ever since then, we've been including the Apad in all our standards > (at least the ones coming out of the Routing Area WG). > > This has now been extensively implemented and there are libraries > available that account for the Apad when computing the hash for the > routing protocols. > > The Apad is now employed for RIP, OSPF, OSPFv3. I see no reason why > LDP should be an exception. The same has been proposed for BFD btw. Even given the above, I fail to see why you repeat this text over and over and over. Is there a real logic for that? S > > Cheers, Manav > >> -----Original Message----- From: Stephen Farrell >> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, May 21, 2014 >> 2:53 AM To: Bhatia, Manav (Manav); IETF Security Directorate; The >> IESG; draft- ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org Cc: >> Yaron Sheffer; manavbhatia@gmail.com Subject: Re: SecDir review of >> draft-ietf-mpls-ldp-hello-crypto-auth-05 >> >> >> >> On 19/05/14 21:27, Yaron Sheffer wrote: >>>>> >>>>> * 5.1: Redefining HMAC (RFC 2104) is an extremely bad idea. >>>>> This reviewer does not have the appropriate background to >>>>> critique the proposed solution, but there must be an >>>>> overwhelming reason to >> reopen >>>>> cryptographic primitives. >>>> >>>> This is a decision that was taken by Sec Ads when we were doing >>>> the crypto protection for the IGPs based on some feedback from >>>> NIST. >> This >>>> mathematics is not new and has been done for all IGPs and has >>>> been approved and rather encouraged by the Security ADs. >> >> The above does not sound like something I recognise. I have >> repeatedly asked that documents not re-define HMAC. Perhaps this >> time, I'll make that a DISCUSS and not budge. I probably should >> have done that before TBH. >> >> If you are revising that doc, *please* get rid of the re-definition >> and just properly refer to HMAC. Its about time to stop repeating >> that error. >> >> S. > > > From nobody Wed May 21 01:09:02 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8721A029E; Wed, 21 May 2014 01:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FT40AKCgFvfl; Wed, 21 May 2014 01:08:52 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 719B71A0313; Wed, 21 May 2014 01:08:51 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s4L88lYj021311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 May 2014 03:08:48 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s4L88lOP017930 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 May 2014 04:08:47 -0400 Received: from SG70XWXCHHUB02.zap.alcatel-lucent.com (135.253.2.47) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 21 May 2014 04:08:47 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.212]) by SG70XWXCHHUB02.zap.alcatel-lucent.com ([135.253.2.47]) with mapi id 14.02.0247.003; Wed, 21 May 2014 16:07:47 +0800 From: "Bhatia, Manav (Manav)" To: Stephen Farrell , IETF Security Directorate , The IESG , "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" Thread-Topic: SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 Thread-Index: AQHPcRACnDeFnD7gHUOXWsSAGM4MlZtGKCeAgAGxPwCAAaG6AIABLjlg//+CUQCAAIezIA== Date: Wed, 21 May 2014 08:07:46 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E60B6A8@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> <537BC7B6.5040406@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B609@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C5BCE.4010801@cs.tcd.ie> In-Reply-To: <537C5BCE.4010801@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/ddE3CsEp6YLUs_sS-bOjeT3IxiE Cc: "manavbhatia@gmail.com" Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 08:08:55 -0000 Stephen, > > The Apad is now employed for RIP, OSPF, OSPFv3. I see no reason why > > LDP should be an exception. The same has been proposed for BFD btw. >=20 > Even given the above, I fail to see why you repeat this text over > and over and over. Is there a real logic for that? Yes. The logic is that Apad keeps changing based on the protocol. There are= some specific attacks that can be prevented by defining Apad to mean somet= hing specific. In case of OSPFv2 it means the source address of the sender.= In case of OSPFv3, it is a value where the first 16 octets contain the IPv= 6 source address followed by the hexadecimal value 0x878FE1F3 repeated (L-1= 6)/4 times. L in this case is the length of the hash.=20 In case of RIpv2 and IS-IS it's a fixed constant. In this draft Apad is defined as: In case of IPv4, the first 4 octets contain the IPv4 source address followe= d by the hexadecimal value 0x878FE1F3 repeated (L-4)/4 times. =20 In case of IPv6, the first 16 octets contain the IPv6 source address follow= ed by the hexadecimal value 0x878FE1F3 repeated (L-16)/4 times. One way to avoid this duplication is by writing a new RFC that redefines HM= AC and includes the Apad. Other documents can only mention the Apad value, = while including a normative reference to that RFC. This however is a long drawn discussion because everyone needs to be convin= ced on the merits of updating the HMAC specification -- which I am not sure= will take how long. Cheers, Manav >=20 > S >=20 > > > > Cheers, Manav > > > >> -----Original Message----- From: Stephen Farrell > >> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, May 21, 2014 > >> 2:53 AM To: Bhatia, Manav (Manav); IETF Security Directorate; The > >> IESG; draft- ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org Cc: > >> Yaron Sheffer; manavbhatia@gmail.com Subject: Re: SecDir review of > >> draft-ietf-mpls-ldp-hello-crypto-auth-05 > >> > >> > >> > >> On 19/05/14 21:27, Yaron Sheffer wrote: > >>>>> > >>>>> * 5.1: Redefining HMAC (RFC 2104) is an extremely bad idea. > >>>>> This reviewer does not have the appropriate background to > >>>>> critique the proposed solution, but there must be an > >>>>> overwhelming reason to > >> reopen> >>>>> cryptographic primitives. > >>>> > >>>> This is a decision that was taken by Sec Ads when we were doing > >>>> the crypto protection for the IGPs based on some feedback from > >>>> NIST. > >> This > >>>> mathematics is not new and has been done for all IGPs and has > >>>> been approved and rather encouraged by the Security ADs. > >> > >> The above does not sound like something I recognise. I have > >> repeatedly asked that documents not re-define HMAC. Perhaps this > >> time, I'll make that a DISCUSS and not budge. I probably should > >> have done that before TBH. > >> > >> If you are revising that doc, *please* get rid of the re-definition > >> and just properly refer to HMAC. Its about time to stop repeating > >> that error. > >> > >> S. > > > > > > From nobody Wed May 21 03:24:38 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0E01A0332; Wed, 21 May 2014 03:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8tlvCap72X1; Wed, 21 May 2014 03:24:31 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 269701A0327; Wed, 21 May 2014 03:24:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 63C22BE6E; Wed, 21 May 2014 11:24:29 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDlbXe1nxMBA; Wed, 21 May 2014 11:24:28 +0100 (IST) Received: from [193.1.136.127] (dhcp-c101887f.ucd.ie [193.1.136.127]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id F26E2BE75; Wed, 21 May 2014 11:24:27 +0100 (IST) Message-ID: <537C7EDB.9050000@cs.tcd.ie> Date: Wed, 21 May 2014 11:24:27 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" , IETF Security Directorate , The IESG , "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> <537BC7B6.5040406@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B609@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C5BCE.4010801@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B6A8@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: <20211F91F544D247976D84C5D778A4C32E60B6A8@SG70YWXCHMBA05.zap.alcatel-lucent.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Vf-WoSpPyhGyAmPN1m9AQN28QE4 Cc: "manavbhatia@gmail.com" Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 10:24:33 -0000 On 21/05/14 09:07, Bhatia, Manav (Manav) wrote: > Stephen, > >>> The Apad is now employed for RIP, OSPF, OSPFv3. I see no reason >>> why LDP should be an exception. The same has been proposed for >>> BFD btw. >> >> Even given the above, I fail to see why you repeat this text over >> and over and over. Is there a real logic for that? > > Yes. The logic is that Apad keeps changing based on the protocol. > There are some specific attacks that can be prevented by defining > Apad to mean something specific. In case of OSPFv2 it means the > source address of the sender. In case of OSPFv3, it is a value where > the first 16 octets contain the IPv6 source address followed by the > hexadecimal value 0x878FE1F3 repeated (L-16)/4 times. L in this case > is the length of the hash. > > In case of RIpv2 and IS-IS it's a fixed constant. > > In this draft Apad is defined as: > > In case of IPv4, the first 4 octets contain the IPv4 source address > followed by the hexadecimal value 0x878FE1F3 repeated (L-4)/4 times. > In case of IPv6, the first 16 octets contain the IPv6 source address > followed by the hexadecimal value 0x878FE1F3 repeated (L-16)/4 > times. > > One way to avoid this duplication is by writing a new RFC that > redefines HMAC and includes the Apad. Other documents can only > mention the Apad value, while including a normative reference to that > RFC. > > This however is a long drawn discussion because everyone needs to be > convinced on the merits of updating the HMAC specification -- which I > am not sure will take how long. So I need to look at this draft, HMAC and the other cases but it seems to me that you're copying a page or two of crypto spec each time and changing one line. Doing that over and over is a recipe for long term pain, isn't it? (And we've had this discussion for each such draft while I've been on the IESG I think, which is also somewhat drawn out;-) S. > > Cheers, Manav > > >> >> S >> >>> >>> Cheers, Manav >>> >>>> -----Original Message----- From: Stephen Farrell >>>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, May 21, >>>> 2014 2:53 AM To: Bhatia, Manav (Manav); IETF Security >>>> Directorate; The IESG; draft- >>>> ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org Cc: Yaron >>>> Sheffer; manavbhatia@gmail.com Subject: Re: SecDir review of >>>> draft-ietf-mpls-ldp-hello-crypto-auth-05 >>>> >>>> >>>> >>>> On 19/05/14 21:27, Yaron Sheffer wrote: >>>>>>> >>>>>>> * 5.1: Redefining HMAC (RFC 2104) is an extremely bad >>>>>>> idea. This reviewer does not have the appropriate >>>>>>> background to critique the proposed solution, but there >>>>>>> must be an overwhelming reason to >>>> reopen> >>>>> cryptographic primitives. >>>>>> >>>>>> This is a decision that was taken by Sec Ads when we were >>>>>> doing the crypto protection for the IGPs based on some >>>>>> feedback from NIST. >>>> This >>>>>> mathematics is not new and has been done for all IGPs and >>>>>> has been approved and rather encouraged by the Security >>>>>> ADs. >>>> >>>> The above does not sound like something I recognise. I have >>>> repeatedly asked that documents not re-define HMAC. Perhaps >>>> this time, I'll make that a DISCUSS and not budge. I probably >>>> should have done that before TBH. >>>> >>>> If you are revising that doc, *please* get rid of the >>>> re-definition and just properly refer to HMAC. Its about time >>>> to stop repeating that error. >>>> >>>> S. >>> >>> >>> > > > From nobody Wed May 21 03:42:02 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88CA1A04B4; Wed, 21 May 2014 03:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHql56r51XrA; Wed, 21 May 2014 03:41:59 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id E35441A0327; Wed, 21 May 2014 03:41:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B0089BE75; Wed, 21 May 2014 11:41:57 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIrg4bUE+jVz; Wed, 21 May 2014 11:41:56 +0100 (IST) Received: from [193.1.136.127] (dhcp-c101887f.ucd.ie [193.1.136.127]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 98416BE5C; Wed, 21 May 2014 11:41:56 +0100 (IST) Message-ID: <537C82F4.1000506@cs.tcd.ie> Date: Wed, 21 May 2014 11:41:56 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Manav Bhatia References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> <537BC7B6.5040406@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B609@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C5BCE.4010801@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B6A8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C7EDB.9050000@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/ucqgTTFMEIdT5G7PjxdIqu9gQX4 Cc: "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" , "Bhatia, Manav \(Manav\)" , The IESG , IETF Security Directorate Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 10:42:00 -0000 On 21/05/14 11:39, Manav Bhatia wrote: > > I had volunteered to write a 1-2 page long ID that updated the HMAC to > include the Apad, but the idea was shot down. How about we make that idea fly again? I realise that might cause some short term pain with this I-D, but it could be the right thing to do. S. From nobody Wed May 21 03:58:42 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A0D1A04C2; Wed, 21 May 2014 03:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pthg0ybsP3yH; Wed, 21 May 2014 03:58:38 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBE511A0327; Wed, 21 May 2014 03:58:37 -0700 (PDT) Received: from [192.168.1.8] (unknown [112.208.14.118]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 6C7A01800905; Wed, 21 May 2014 12:58:33 +0200 (CEST) Message-ID: <537C86D6.1030703@pi.nu> Date: Wed, 21 May 2014 12:58:30 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Manav Bhatia , Stephen Farrell References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> <537BC7B6.5040406@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B609@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C5BCE.4010801@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B6A8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C7EDB.9050000@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/TgSfEcD8K3cicGxnUPiUrXcFtRM Cc: "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" , "Bhatia, Manav \(Manav\)" , The IESG , IETF Security Directorate Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 10:58:40 -0000 Folks, I'm only the document shepherd. My feeling is that we are raising the hurdle step by step for the KARP - initiated RFCs, the first was comparatively smooth, now we are trying to put an 18 months effort (individual draft to RFC) in front of approving something that is comparatively simple and seen as raising LDP to the same security as the other routing protocols. So if we get to tired to push this, we are all better off not doing the security work for this particular protocol? Someone said - "Never let the best be the enemy of the possible"! /Loa On 2014-05-21 12:39, Manav Bhatia wrote: > Stephen, > >>> This however is a long drawn discussion because everyone needs to be >>> convinced on the merits of updating the HMAC specification -- which I >>> am not sure will take how long. >> >> So I need to look at this draft, HMAC and the other cases but >> it seems to me that you're copying a page or two of crypto >> spec each time and changing one line. Doing that over and over >> is a recipe for long term pain, isn't it? > > It sure is. > > I had volunteered to write a 1-2 page long ID that updated the HMAC to > include the Apad, but the idea was shot down. The only alternative > left was to include the crypto stuff in each standard that we wrote > later. > >> >> (And we've had this discussion for each such draft while I've >> been on the IESG I think, which is also somewhat drawn out;-) > > This draft is probably the last one thats coming from the Routing WG > which will have this level of crypto mathematics spelled out. All > other IGPs are already covered. In case we need to change something in > the ones already covered we can refer to the base RFC where we have > detailed the crypto maths. For example, > draft-ietf-ospf-security-extension-manual-keying-08 amongst other > things also updates the definition of Apad. It points to the exact > mathematics in RFC 5709 and only updates the Apad definition in that > draft. This draft btw has cleared the WG LC and would be appearing > before you guys very soon. > > Given this, i think we should just pass this draft with this level of > details. Subsequently, when LDP wants to update something, it can > normatively refer to this RFC and only give the changes. > > Cheers, Manav > >> >> S. >> >> >>> >>> Cheers, Manav >>> >>> >>>> >>>> S >>>> >>>>> >>>>> Cheers, Manav >>>>> >>>>>> -----Original Message----- From: Stephen Farrell >>>>>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, May 21, >>>>>> 2014 2:53 AM To: Bhatia, Manav (Manav); IETF Security >>>>>> Directorate; The IESG; draft- >>>>>> ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org Cc: Yaron >>>>>> Sheffer; manavbhatia@gmail.com Subject: Re: SecDir review of >>>>>> draft-ietf-mpls-ldp-hello-crypto-auth-05 >>>>>> >>>>>> >>>>>> >>>>>> On 19/05/14 21:27, Yaron Sheffer wrote: >>>>>>>>> >>>>>>>>> * 5.1: Redefining HMAC (RFC 2104) is an extremely bad >>>>>>>>> idea. This reviewer does not have the appropriate >>>>>>>>> background to critique the proposed solution, but there >>>>>>>>> must be an overwhelming reason to >>>>>> reopen> >>>>> cryptographic primitives. >>>>>>>> >>>>>>>> This is a decision that was taken by Sec Ads when we were >>>>>>>> doing the crypto protection for the IGPs based on some >>>>>>>> feedback from NIST. >>>>>> This >>>>>>>> mathematics is not new and has been done for all IGPs and >>>>>>>> has been approved and rather encouraged by the Security >>>>>>>> ADs. >>>>>> >>>>>> The above does not sound like something I recognise. I have >>>>>> repeatedly asked that documents not re-define HMAC. Perhaps >>>>>> this time, I'll make that a DISCUSS and not budge. I probably >>>>>> should have done that before TBH. >>>>>> >>>>>> If you are revising that doc, *please* get rid of the >>>>>> re-definition and just properly refer to HMAC. Its about time >>>>>> to stop repeating that error. >>>>>> >>>>>> S. >>>>> >>>>> >>>>> >>> >>> >>> -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed May 21 04:14:56 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC231A04C2; Wed, 21 May 2014 04:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKPllPfm5ahU; Wed, 21 May 2014 04:14:52 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DF6D1A04B6; Wed, 21 May 2014 04:14:51 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s4LBEjbH019911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 May 2014 06:14:46 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s4LBEjNl019349 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 May 2014 07:14:45 -0400 Received: from SG70YWXCHHUB04.zap.alcatel-lucent.com (135.253.2.38) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 21 May 2014 07:14:44 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.212]) by SG70YWXCHHUB04.zap.alcatel-lucent.com ([135.253.2.38]) with mapi id 14.02.0247.003; Wed, 21 May 2014 19:14:41 +0800 From: "Bhatia, Manav (Manav)" To: Loa Andersson , Manav Bhatia , "Stephen Farrell" Thread-Topic: SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 Thread-Index: AQHPcRACnDeFnD7gHUOXWsSAGM4MlZtGKCeAgAGxPwCAAaG6AIABLjlg//+CUQCAAIezIP//ohaAgAAERwCAAAU8AIAAiYEQ Date: Wed, 21 May 2014 11:14:40 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E60BA5C@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> <537BC7B6.5040406@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B609@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C5BCE.4010801@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B6A8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C7EDB.9050000@cs.tcd.ie> <537C86D6.1030703@pi.nu> In-Reply-To: <537C86D6.1030703@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/8pU6jhzZb-7YbGk0i_DGSFCQp18 Cc: "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" , The IESG , IETF Security Directorate Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 11:14:54 -0000 SSBhZ3JlZSB3aXRoIExvYS4gDQoNCk91ciBjdXJyZW50IGRyYWZ0IGlzIHZlcnkgc2ltcGxlIGFu ZCBoYXMgZ29uZSB0aHJvdWdoIG11bHRpcGxlIGl0ZXJhdGlvbnMgb2YgcmV2aWV3cyBpbiBhdCBs ZWFzdCB0d28gV0dzLiBJdCBicmluZ3MgTERQIHRvIHRoZSBzYW1lIGxldmVsIG9mIHNlY3VyaXR5 IGFzIG90aGVyIHByb3RvY29scyBydW5uaW5nIGluIHRoZSBuZXR3b3Jrcy4gDQoNCkkgdGhpbmsg d2Ugc2hvdWxkIGp1c3QgcHVzaCBpdCBmb3J3YXJkIGFuZCBpZiB0aGVyZSBpcyBhbiBpbnRlcmVz dCBpbiB3cml0aW5nIGEgbmV3IElEIHRoYXQgdXBkYXRlcyBITUFDIHNwZWNpZmljYXRpb24sIHRo ZW4gd2Ugd3JpdGUgb25lIHRoYXQgaW5jbHVkZXMgdGhlIEFwYWQgc3R1ZmYuIEkgdGhpbmsgdGhl IGxhdHRlciBzaG91bGQgYW55d2F5cyBiZSBkb25lLCByZWdhcmRsZXNzIG9mIHdoYXQgaGFwcGVu cyB0byB0aGlzIHBhcnRpY3VsYXIgZHJhZnQuDQoNClRoZSBJRVRGIHN1Ym1pc3Npb24gc2l0ZSBp cyBkb3duIGFuZCBoZW5jZSBjb3VsZG7igJl0IHVwbG9hZCB0aGUgcmV2aXNlZCBJRCAoYWRkcmVz c2luZyBZYXJvbidzIGNvbW1lbnRzKS4gV2lsbCBkbyBpdCB0b21vcnJvdyBvbmNlIGl0cyB1cC4N Cg0KQWZ0ZXIgdGhhdCBpdHMgcmVhZHkgdG8gYmUgcGxhY2VkIGJlZm9yZSB0aGUgSUVTRy4NCg0K Q2hlZXJzLCBNYW5hdg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IExv YSBBbmRlcnNzb24gW21haWx0bzpsb2FAcGkubnVdDQo+IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDIx LCAyMDE0IDQ6MjkgUE0NCj4gVG86IE1hbmF2IEJoYXRpYTsgU3RlcGhlbiBGYXJyZWxsDQo+IENj OiBCaGF0aWEsIE1hbmF2IChNYW5hdik7IElFVEYgU2VjdXJpdHkgRGlyZWN0b3JhdGU7IFRoZSBJ RVNHOyBkcmFmdC0NCj4gaWV0Zi1tcGxzLWxkcC1oZWxsby1jcnlwdG8tYXV0aC5hbGxAdG9vbHMu aWV0Zi5vcmc7IFlhcm9uIFNoZWZmZXINCj4gU3ViamVjdDogUmU6IFNlY0RpciByZXZpZXcgb2Yg ZHJhZnQtaWV0Zi1tcGxzLWxkcC1oZWxsby1jcnlwdG8tYXV0aC0wNQ0KPiANCj4gRm9sa3MsDQo+ IA0KPiBJJ20gb25seSB0aGUgZG9jdW1lbnQgc2hlcGhlcmQuIE15IGZlZWxpbmcgaXMgdGhhdCB3 ZSBhcmUgcmFpc2luZw0KPiB0aGUgaHVyZGxlIHN0ZXAgYnkgc3RlcCBmb3IgdGhlIEtBUlAgLSBp bml0aWF0ZWQgUkZDcywgdGhlIGZpcnN0DQo+IHdhcyBjb21wYXJhdGl2ZWx5IHNtb290aCwgbm93 IHdlIGFyZSB0cnlpbmcgdG8gcHV0IGFuIDE4IG1vbnRocw0KPiBlZmZvcnQgKGluZGl2aWR1YWwg ZHJhZnQgdG8gUkZDKSBpbiBmcm9udCBvZiBhcHByb3Zpbmcgc29tZXRoaW5nDQo+IHRoYXQgaXMg Y29tcGFyYXRpdmVseSBzaW1wbGUgYW5kIHNlZW4gYXMgcmFpc2luZyBMRFAgdG8gdGhlIHNhbWUN Cj4gc2VjdXJpdHkgYXMgdGhlIG90aGVyIHJvdXRpbmcgcHJvdG9jb2xzLg0KPiANCj4gU28gaWYg d2UgZ2V0IHRvIHRpcmVkIHRvIHB1c2ggdGhpcywgd2UgYXJlIGFsbCBiZXR0ZXIgb2ZmIG5vdCBk b2luZw0KPiB0aGUgc2VjdXJpdHkgd29yayBmb3IgdGhpcyBwYXJ0aWN1bGFyIHByb3RvY29sPw0K PiANCj4gU29tZW9uZSBzYWlkIC0gIk5ldmVyIGxldCB0aGUgYmVzdCBiZSB0aGUgZW5lbXkgb2Yg dGhlIHBvc3NpYmxlIiENCj4gDQo+IC9Mb2ENCj4gDQo+IA0KPiANCj4gT24gMjAxNC0wNS0yMSAx MjozOSwgTWFuYXYgQmhhdGlhIHdyb3RlOg0KPiA+IFN0ZXBoZW4sDQo+ID4NCj4gPj4+IFRoaXMg aG93ZXZlciBpcyBhIGxvbmcgZHJhd24gZGlzY3Vzc2lvbiBiZWNhdXNlIGV2ZXJ5b25lIG5lZWRz IHRvDQo+IGJlDQo+ID4+PiBjb252aW5jZWQgb24gdGhlIG1lcml0cyBvZiB1cGRhdGluZyB0aGUg SE1BQyBzcGVjaWZpY2F0aW9uIC0tIHdoaWNoDQo+IEkNCj4gPj4+IGFtIG5vdCBzdXJlIHdpbGwg dGFrZSBob3cgbG9uZy4NCj4gPj4NCj4gPj4gU28gSSBuZWVkIHRvIGxvb2sgYXQgdGhpcyBkcmFm dCwgSE1BQyBhbmQgdGhlIG90aGVyIGNhc2VzIGJ1dA0KPiA+PiBpdCBzZWVtcyB0byBtZSB0aGF0 IHlvdSdyZSBjb3B5aW5nIGEgcGFnZSBvciB0d28gb2YgY3J5cHRvDQo+ID4+IHNwZWMgZWFjaCB0 aW1lIGFuZCBjaGFuZ2luZyBvbmUgbGluZS4gRG9pbmcgdGhhdCBvdmVyIGFuZCBvdmVyDQo+ID4+ IGlzIGEgcmVjaXBlIGZvciBsb25nIHRlcm0gcGFpbiwgaXNuJ3QgaXQ/DQo+ID4NCj4gPiBJdCBz dXJlIGlzLg0KPiA+DQo+ID4gSSBoYWQgdm9sdW50ZWVyZWQgdG8gd3JpdGUgYSAxLTIgcGFnZSBs b25nIElEIHRoYXQgdXBkYXRlZCB0aGUgSE1BQw0KPiB0bw0KPiA+IGluY2x1ZGUgdGhlIEFwYWQs IGJ1dCB0aGUgaWRlYSB3YXMgc2hvdCBkb3duLiBUaGUgb25seSBhbHRlcm5hdGl2ZQ0KPiA+IGxl ZnQgd2FzIHRvIGluY2x1ZGUgdGhlIGNyeXB0byBzdHVmZiBpbiBlYWNoIHN0YW5kYXJkIHRoYXQg d2Ugd3JvdGUNCj4gPiBsYXRlci4NCj4gPg0KPiA+Pg0KPiA+PiAoQW5kIHdlJ3ZlIGhhZCB0aGlz IGRpc2N1c3Npb24gZm9yIGVhY2ggc3VjaCBkcmFmdCB3aGlsZSBJJ3ZlDQo+ID4+IGJlZW4gb24g dGhlIElFU0cgSSB0aGluaywgd2hpY2ggaXMgYWxzbyBzb21ld2hhdCBkcmF3biBvdXQ7LSkNCj4g Pg0KPiA+IFRoaXMgZHJhZnQgaXMgcHJvYmFibHkgdGhlIGxhc3Qgb25lIHRoYXRzIGNvbWluZyBm cm9tIHRoZSBSb3V0aW5nIFdHDQo+ID4gd2hpY2ggd2lsbCBoYXZlIHRoaXMgbGV2ZWwgb2YgY3J5 cHRvIG1hdGhlbWF0aWNzIHNwZWxsZWQgb3V0LiBBbGwNCj4gPiBvdGhlciBJR1BzIGFyZSBhbHJl YWR5IGNvdmVyZWQuIEluIGNhc2Ugd2UgbmVlZCB0byBjaGFuZ2Ugc29tZXRoaW5nDQo+IGluDQo+ ID4gdGhlIG9uZXMgYWxyZWFkeSBjb3ZlcmVkIHdlIGNhbiByZWZlciB0byB0aGUgYmFzZSBSRkMg d2hlcmUgd2UgaGF2ZQ0KPiA+IGRldGFpbGVkIHRoZSBjcnlwdG8gbWF0aHMuIEZvciBleGFtcGxl LA0KPiA+IGRyYWZ0LWlldGYtb3NwZi1zZWN1cml0eS1leHRlbnNpb24tbWFudWFsLWtleWluZy0w OCBhbW9uZ3N0IG90aGVyDQo+ID4gdGhpbmdzIGFsc28gdXBkYXRlcyB0aGUgZGVmaW5pdGlvbiBv ZiBBcGFkLiBJdCBwb2ludHMgdG8gdGhlIGV4YWN0DQo+ID4gbWF0aGVtYXRpY3MgaW4gUkZDIDU3 MDkgYW5kIG9ubHkgdXBkYXRlcyB0aGUgQXBhZCBkZWZpbml0aW9uIGluIHRoYXQNCj4gPiBkcmFm dC4gVGhpcyBkcmFmdCBidHcgaGFzIGNsZWFyZWQgdGhlIFdHIExDIGFuZCB3b3VsZCBiZSBhcHBl YXJpbmcNCj4gPiBiZWZvcmUgeW91IGd1eXMgdmVyeSBzb29uLg0KPiA+DQo+ID4gR2l2ZW4gdGhp cywgaSB0aGluayB3ZSBzaG91bGQganVzdCBwYXNzIHRoaXMgZHJhZnQgd2l0aCB0aGlzIGxldmVs IG9mDQo+ID4gZGV0YWlscy4gU3Vic2VxdWVudGx5LCB3aGVuIExEUCB3YW50cyB0byB1cGRhdGUg c29tZXRoaW5nLCBpdCBjYW4NCj4gPiBub3JtYXRpdmVseSByZWZlciB0byB0aGlzIFJGQyBhbmQg b25seSBnaXZlIHRoZSBjaGFuZ2VzLg0KPiA+DQo+ID4gQ2hlZXJzLCBNYW5hdg0KPiA+DQo+ID4+ DQo+ID4+IFMuDQo+ID4+DQo+ID4+DQo+ID4+Pg0KPiA+Pj4gQ2hlZXJzLCBNYW5hdg0KPiA+Pj4N Cj4gPj4+DQo+ID4+Pj4NCj4gPj4+PiBTDQo+ID4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4gQ2hlZXJz LCBNYW5hdg0KPiA+Pj4+Pg0KPiA+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJv bTogU3RlcGhlbiBGYXJyZWxsDQo+ID4+Pj4+PiBbbWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50 Y2QuaWVdIFNlbnQ6IFdlZG5lc2RheSwgTWF5IDIxLA0KPiA+Pj4+Pj4gMjAxNCAyOjUzIEFNIFRv OiBCaGF0aWEsIE1hbmF2IChNYW5hdik7IElFVEYgU2VjdXJpdHkNCj4gPj4+Pj4+IERpcmVjdG9y YXRlOyBUaGUgSUVTRzsgZHJhZnQtDQo+ID4+Pj4+PiBpZXRmLW1wbHMtbGRwLWhlbGxvLWNyeXB0 by1hdXRoLmFsbEB0b29scy5pZXRmLm9yZyBDYzogWWFyb24NCj4gPj4+Pj4+IFNoZWZmZXI7IG1h bmF2YmhhdGlhQGdtYWlsLmNvbSBTdWJqZWN0OiBSZTogU2VjRGlyIHJldmlldyBvZg0KPiA+Pj4+ Pj4gZHJhZnQtaWV0Zi1tcGxzLWxkcC1oZWxsby1jcnlwdG8tYXV0aC0wNQ0KPiA+Pj4+Pj4NCj4g Pj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gT24gMTkvMDUvMTQgMjE6MjcsIFlhcm9uIFNoZWZm ZXIgd3JvdGU6DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gKiA1LjE6IFJlZGVmaW5pbmcgSE1B QyAoUkZDIDIxMDQpIGlzIGFuIGV4dHJlbWVseSBiYWQNCj4gPj4+Pj4+Pj4+IGlkZWEuIFRoaXMg cmV2aWV3ZXIgZG9lcyBub3QgaGF2ZSB0aGUgYXBwcm9wcmlhdGUNCj4gPj4+Pj4+Pj4+IGJhY2tn cm91bmQgdG8gY3JpdGlxdWUgdGhlIHByb3Bvc2VkIHNvbHV0aW9uLCBidXQgdGhlcmUNCj4gPj4+ Pj4+Pj4+IG11c3QgYmUgYW4gb3ZlcndoZWxtaW5nIHJlYXNvbiB0bw0KPiA+Pj4+Pj4gcmVvcGVu PiA+Pj4+PiBjcnlwdG9ncmFwaGljIHByaW1pdGl2ZXMuDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+ IFRoaXMgaXMgYSBkZWNpc2lvbiB0aGF0IHdhcyB0YWtlbiBieSBTZWMgQWRzIHdoZW4gd2Ugd2Vy ZQ0KPiA+Pj4+Pj4+PiBkb2luZyB0aGUgY3J5cHRvIHByb3RlY3Rpb24gZm9yIHRoZSBJR1BzIGJh c2VkIG9uIHNvbWUNCj4gPj4+Pj4+Pj4gZmVlZGJhY2sgZnJvbSBOSVNULg0KPiA+Pj4+Pj4gVGhp cw0KPiA+Pj4+Pj4+PiBtYXRoZW1hdGljcyBpcyBub3QgbmV3IGFuZCBoYXMgYmVlbiBkb25lIGZv ciBhbGwgSUdQcyBhbmQNCj4gPj4+Pj4+Pj4gaGFzIGJlZW4gYXBwcm92ZWQgYW5kIHJhdGhlciBl bmNvdXJhZ2VkIGJ5IHRoZSBTZWN1cml0eQ0KPiA+Pj4+Pj4+PiBBRHMuDQo+ID4+Pj4+Pg0KPiA+ Pj4+Pj4gVGhlIGFib3ZlIGRvZXMgbm90IHNvdW5kIGxpa2Ugc29tZXRoaW5nIEkgcmVjb2duaXNl LiBJIGhhdmUNCj4gPj4+Pj4+IHJlcGVhdGVkbHkgYXNrZWQgdGhhdCBkb2N1bWVudHMgbm90IHJl LWRlZmluZSBITUFDLiBQZXJoYXBzDQo+ID4+Pj4+PiB0aGlzIHRpbWUsIEknbGwgbWFrZSB0aGF0 IGEgRElTQ1VTUyBhbmQgbm90IGJ1ZGdlLiBJIHByb2JhYmx5DQo+ID4+Pj4+PiBzaG91bGQgaGF2 ZSBkb25lIHRoYXQgYmVmb3JlIFRCSC4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBJZiB5b3UgYXJlIHJl dmlzaW5nIHRoYXQgZG9jLCAqcGxlYXNlKiBnZXQgcmlkIG9mIHRoZQ0KPiA+Pj4+Pj4gcmUtZGVm aW5pdGlvbiBhbmQganVzdCBwcm9wZXJseSByZWZlciB0byBITUFDLiBJdHMgYWJvdXQgdGltZQ0K PiA+Pj4+Pj4gdG8gc3RvcCByZXBlYXRpbmcgdGhhdCBlcnJvci4NCj4gPj4+Pj4+DQo+ID4+Pj4+ PiBTLg0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiAN Cj4gLS0NCj4gDQo+IA0KPiBMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgZW1h aWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbQ0KPiBTZW5pb3IgTVBMUyBFeHBlcnQgICAgICAgICAg ICAgICAgICAgICAgICAgIGxvYUBwaS5udQ0KPiBIdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0 YW50KSAgICAgcGhvbmU6ICs0NiA3MzkgODEgMjEgNjQNCg== From nobody Wed May 21 05:58:06 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C661B1A05C3; Wed, 21 May 2014 05:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqo6LVZiV8sY; Wed, 21 May 2014 05:58:02 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A89581A067A; Wed, 21 May 2014 05:57:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 68BA5BE8A; Wed, 21 May 2014 13:57:56 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsa62k7ZrW-n; Wed, 21 May 2014 13:57:54 +0100 (IST) Received: from [193.1.136.127] (dhcp-c101887f.ucd.ie [193.1.136.127]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A9D47BE80; Wed, 21 May 2014 13:57:54 +0100 (IST) Message-ID: <537CA2D2.4070103@cs.tcd.ie> Date: Wed, 21 May 2014 13:57:54 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" , Loa Andersson , Manav Bhatia References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> <537BC7B6.5040406@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B609@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C5BCE.4010801@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B6A8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C7EDB.9050000@cs.tcd.ie> <537C86D6.1030703@pi.nu> <20211F91F544D247976D84C5D778A4C32E60BA5C@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: <20211F91F544D247976D84C5D778A4C32E60BA5C@SG70YWXCHMBA05.zap.alcatel-lucent.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/nS98_Ax3HcTbtMiIRGvGAqWC-80 Cc: "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" , The IESG , IETF Security Directorate Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 12:58:04 -0000 On 21/05/14 12:14, Bhatia, Manav (Manav) wrote: > I agree with Loa. > > Our current draft is very simple and has gone through multiple > iterations of reviews in at least two WGs. It brings LDP to the same > level of security as other protocols running in the networks. Fully agree with that goal. > > I think we should just push it forward and if there is an interest in > writing a new ID that updates HMAC specification, then we write one > that includes the Apad stuff. I think the latter should anyways be > done, regardless of what happens to this particular draft. I need to read it. But I'd be happier if that HMAC draft existed and was going to be processed - then we wouldn't have to do this discussion again. Cheers, S. > > The IETF submission site is down and hence couldn’t upload the > revised ID (addressing Yaron's comments). Will do it tomorrow once > its up. > > After that its ready to be placed before the IESG. > > Cheers, Manav > >> -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu] >> Sent: Wednesday, May 21, 2014 4:29 PM To: Manav Bhatia; Stephen >> Farrell Cc: Bhatia, Manav (Manav); IETF Security Directorate; The >> IESG; draft- ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org; >> Yaron Sheffer Subject: Re: SecDir review of >> draft-ietf-mpls-ldp-hello-crypto-auth-05 >> >> Folks, >> >> I'm only the document shepherd. My feeling is that we are raising >> the hurdle step by step for the KARP - initiated RFCs, the first >> was comparatively smooth, now we are trying to put an 18 months >> effort (individual draft to RFC) in front of approving something >> that is comparatively simple and seen as raising LDP to the same >> security as the other routing protocols. >> >> So if we get to tired to push this, we are all better off not >> doing the security work for this particular protocol? >> >> Someone said - "Never let the best be the enemy of the possible"! >> >> /Loa >> >> >> >> On 2014-05-21 12:39, Manav Bhatia wrote: >>> Stephen, >>> >>>>> This however is a long drawn discussion because everyone >>>>> needs to >> be >>>>> convinced on the merits of updating the HMAC specification -- >>>>> which >> I >>>>> am not sure will take how long. >>>> >>>> So I need to look at this draft, HMAC and the other cases but >>>> it seems to me that you're copying a page or two of crypto spec >>>> each time and changing one line. Doing that over and over is a >>>> recipe for long term pain, isn't it? >>> >>> It sure is. >>> >>> I had volunteered to write a 1-2 page long ID that updated the >>> HMAC >> to >>> include the Apad, but the idea was shot down. The only >>> alternative left was to include the crypto stuff in each standard >>> that we wrote later. >>> >>>> >>>> (And we've had this discussion for each such draft while I've >>>> been on the IESG I think, which is also somewhat drawn out;-) >>> >>> This draft is probably the last one thats coming from the Routing >>> WG which will have this level of crypto mathematics spelled out. >>> All other IGPs are already covered. In case we need to change >>> something >> in >>> the ones already covered we can refer to the base RFC where we >>> have detailed the crypto maths. For example, >>> draft-ietf-ospf-security-extension-manual-keying-08 amongst >>> other things also updates the definition of Apad. It points to >>> the exact mathematics in RFC 5709 and only updates the Apad >>> definition in that draft. This draft btw has cleared the WG LC >>> and would be appearing before you guys very soon. >>> >>> Given this, i think we should just pass this draft with this >>> level of details. Subsequently, when LDP wants to update >>> something, it can normatively refer to this RFC and only give the >>> changes. >>> >>> Cheers, Manav >>> >>>> >>>> S. >>>> >>>> >>>>> >>>>> Cheers, Manav >>>>> >>>>> >>>>>> >>>>>> S >>>>>> >>>>>>> >>>>>>> Cheers, Manav >>>>>>> >>>>>>>> -----Original Message----- From: Stephen Farrell >>>>>>>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, May >>>>>>>> 21, 2014 2:53 AM To: Bhatia, Manav (Manav); IETF >>>>>>>> Security Directorate; The IESG; draft- >>>>>>>> ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org Cc: >>>>>>>> Yaron Sheffer; manavbhatia@gmail.com Subject: Re: >>>>>>>> SecDir review of >>>>>>>> draft-ietf-mpls-ldp-hello-crypto-auth-05 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 19/05/14 21:27, Yaron Sheffer wrote: >>>>>>>>>>> >>>>>>>>>>> * 5.1: Redefining HMAC (RFC 2104) is an extremely >>>>>>>>>>> bad idea. This reviewer does not have the >>>>>>>>>>> appropriate background to critique the proposed >>>>>>>>>>> solution, but there must be an overwhelming >>>>>>>>>>> reason to >>>>>>>> reopen> >>>>> cryptographic primitives. >>>>>>>>>> >>>>>>>>>> This is a decision that was taken by Sec Ads when >>>>>>>>>> we were doing the crypto protection for the IGPs >>>>>>>>>> based on some feedback from NIST. >>>>>>>> This >>>>>>>>>> mathematics is not new and has been done for all >>>>>>>>>> IGPs and has been approved and rather encouraged by >>>>>>>>>> the Security ADs. >>>>>>>> >>>>>>>> The above does not sound like something I recognise. I >>>>>>>> have repeatedly asked that documents not re-define >>>>>>>> HMAC. Perhaps this time, I'll make that a DISCUSS and >>>>>>>> not budge. I probably should have done that before >>>>>>>> TBH. >>>>>>>> >>>>>>>> If you are revising that doc, *please* get rid of the >>>>>>>> re-definition and just properly refer to HMAC. Its >>>>>>>> about time to stop repeating that error. >>>>>>>> >>>>>>>> S. >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >> >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu Huawei >> Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed May 21 06:28:17 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E611A067C; Wed, 21 May 2014 06:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyoHHt-FY5PI; Wed, 21 May 2014 06:28:14 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id B2E1A1A0665; Wed, 21 May 2014 06:28:12 -0700 (PDT) X-AuditID: 12074422-f79376d000000c58-33-537ca9eb8997 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 93.CF.03160.BE9AC735; Wed, 21 May 2014 09:28:11 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s4LDS8aj030133; Wed, 21 May 2014 09:28:08 -0400 Received: from [192.168.1.112] (chostler.hsd1.ma.comcast.net [24.62.227.134]) (authenticated bits=0) (User authenticated as uri@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s4LDS1sQ032343 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 21 May 2014 09:28:03 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Uri Blumenthal In-Reply-To: <537CA2D2.4070103@cs.tcd.ie> Date: Wed, 21 May 2014 09:28:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <54E263B5-41C7-4523-9941-B3E39AE077CD@mit.edu> References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> <537BC7B6.5040406@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B609@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C5BCE.4010801@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B6A8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C7EDB.9050000@cs.tcd.ie> <537C86D6.1030703@pi.nu> <20211F91F544D247976D84C5D778A4C32E60BA5C@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537CA2D2.4070103@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.2) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEKsWRmVeSWpSXmKPExsUixG6novt6ZU2wwYfdMhZ3z29ks5jxZyKz xb+5c5gt5ty7x2pxeVIbu8WHhQ9ZLKbvvcbuwO7R+mwvq8fa7qtsHjtn3WX3WLLkJ5PHrOlt bB5fLn9mC2CL4rJJSc3JLEst0rdL4MrY+u4Oa8Ec84rNu0sbGB/pdDFyckgImEic7FnDBmGL SVy4tx7I5uIQEpjNJDHv/TlmCGcjo8TatrVMEM4+Jom2CXfBWpgF9CR2XP/FCmLzChhIXOtf zwhiCwv4S6za28AMYrMJKEk0N28Bq+EU0JQ4e/wgUJyDg0VAVeLlq0CQmcwC15kknh35CTVT W2LZwtfMEDOtJDZtvssCsfgmi8TK5uVgC0QE9CX2bj7HDnG3vMSM9hPsExgFZyG5aRaSm2Yh mbuAkXkVo2xKbpVubmJmTnFqsm5xcmJeXmqRrqlebmaJXmpK6SZGcHS4KO1g/HlQ6RCjAAej Eg/vgqLqYCHWxLLiytxDjJIcTEqivBOX1gQL8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuE1ngqU 401JrKxKLcqHSUlzsCiJ8761tgoWEkhPLEnNTk0tSC2CycpwcChJ8AqtAGoULEpNT61Iy8wp QUgzcXCCDOcBGq4MUsNbXJCYW5yZDpE/xajLcW7OqTYmIZa8/LxUKXHeN8uAigRAijJK8+Dm wJLaK0ZxoLeEeZ1ARvEAEyLcpFdAS5iAlvxdXAmypCQRISXVwJicw8B2SGdTYmqo5YfpVQc5 fM6sCznwqZeR7az4eh1DbVEfoaT1p9hvHZ3iY/SU49KUnkWrf1fqWlc82fL7lvoP2fW8U52U f9y2r3H5lLpfI2VC8t0ujm+hutm/hP+d5LDorXZP0T5g0rK49uvr3W61HCfPf9vVplLd+qfj w9wFioHfFxUmaCixFGckGmoxFxUnAgDWxjQARQMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/fuFVaUbdv3EISbdmGUCx47Jf8xE Cc: "Bhatia, Manav \(Manav\)" , IETF Security Directorate , "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" , The IESG , Manav Bhatia , Loa Andersson Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 13:28:16 -0000 Once again, please. 1. Who specifically, at NIST and at IESG, says that HMAC needs Apad for = security reasons (and therefore is not secure as-is)? 2. What are those security reasons, and what are the attacks that are = foiled by Apad? 3. What published papers/references/whatever is this documented? As HMAC = came with security proofs, I=92d like to see where and how they are = invalidated (if they indeed are). On May 21, 2014, at 8:57 , Stephen Farrell = wrote: >=20 >=20 > On 21/05/14 12:14, Bhatia, Manav (Manav) wrote: >> I agree with Loa. >>=20 >> Our current draft is very simple and has gone through multiple >> iterations of reviews in at least two WGs. It brings LDP to the same >> level of security as other protocols running in the networks. >=20 > Fully agree with that goal. >=20 >>=20 >> I think we should just push it forward and if there is an interest in >> writing a new ID that updates HMAC specification, then we write one >> that includes the Apad stuff. I think the latter should anyways be >> done, regardless of what happens to this particular draft. >=20 > I need to read it. But I'd be happier if that HMAC draft existed > and was going to be processed - then we wouldn't have to do this > discussion again. >=20 > Cheers, > S. >=20 >>=20 >> The IETF submission site is down and hence couldn=92t upload the >> revised ID (addressing Yaron's comments). Will do it tomorrow once >> its up. >>=20 >> After that its ready to be placed before the IESG. >>=20 >> Cheers, Manav >>=20 >>> -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu]=20 >>> Sent: Wednesday, May 21, 2014 4:29 PM To: Manav Bhatia; Stephen >>> Farrell Cc: Bhatia, Manav (Manav); IETF Security Directorate; The >>> IESG; draft- ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org; >>> Yaron Sheffer Subject: Re: SecDir review of >>> draft-ietf-mpls-ldp-hello-crypto-auth-05 >>>=20 >>> Folks, >>>=20 >>> I'm only the document shepherd. My feeling is that we are raising=20 >>> the hurdle step by step for the KARP - initiated RFCs, the first=20 >>> was comparatively smooth, now we are trying to put an 18 months=20 >>> effort (individual draft to RFC) in front of approving something=20 >>> that is comparatively simple and seen as raising LDP to the same=20 >>> security as the other routing protocols. >>>=20 >>> So if we get to tired to push this, we are all better off not >>> doing the security work for this particular protocol? >>>=20 >>> Someone said - "Never let the best be the enemy of the possible"! >>>=20 >>> /Loa >>>=20 >>>=20 >>>=20 >>> On 2014-05-21 12:39, Manav Bhatia wrote: >>>> Stephen, >>>>=20 >>>>>> This however is a long drawn discussion because everyone >>>>>> needs to >>> be >>>>>> convinced on the merits of updating the HMAC specification -- >>>>>> which >>> I >>>>>> am not sure will take how long. >>>>>=20 >>>>> So I need to look at this draft, HMAC and the other cases but=20 >>>>> it seems to me that you're copying a page or two of crypto spec >>>>> each time and changing one line. Doing that over and over is a >>>>> recipe for long term pain, isn't it? >>>>=20 >>>> It sure is. >>>>=20 >>>> I had volunteered to write a 1-2 page long ID that updated the >>>> HMAC >>> to >>>> include the Apad, but the idea was shot down. The only >>>> alternative left was to include the crypto stuff in each standard >>>> that we wrote later. >>>>=20 >>>>>=20 >>>>> (And we've had this discussion for each such draft while I've=20 >>>>> been on the IESG I think, which is also somewhat drawn out;-) >>>>=20 >>>> This draft is probably the last one thats coming from the Routing >>>> WG which will have this level of crypto mathematics spelled out. >>>> All other IGPs are already covered. In case we need to change >>>> something >>> in >>>> the ones already covered we can refer to the base RFC where we >>>> have detailed the crypto maths. For example,=20 >>>> draft-ietf-ospf-security-extension-manual-keying-08 amongst >>>> other things also updates the definition of Apad. It points to >>>> the exact mathematics in RFC 5709 and only updates the Apad >>>> definition in that draft. This draft btw has cleared the WG LC >>>> and would be appearing before you guys very soon. >>>>=20 >>>> Given this, i think we should just pass this draft with this >>>> level of details. Subsequently, when LDP wants to update >>>> something, it can normatively refer to this RFC and only give the >>>> changes. >>>>=20 >>>> Cheers, Manav >>>>=20 >>>>>=20 >>>>> S. >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Cheers, Manav >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> S >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Cheers, Manav >>>>>>>>=20 >>>>>>>>> -----Original Message----- From: Stephen Farrell=20 >>>>>>>>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, May >>>>>>>>> 21, 2014 2:53 AM To: Bhatia, Manav (Manav); IETF >>>>>>>>> Security Directorate; The IESG; draft-=20 >>>>>>>>> ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org Cc: >>>>>>>>> Yaron Sheffer; manavbhatia@gmail.com Subject: Re: >>>>>>>>> SecDir review of=20 >>>>>>>>> draft-ietf-mpls-ldp-hello-crypto-auth-05 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 19/05/14 21:27, Yaron Sheffer wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> * 5.1: Redefining HMAC (RFC 2104) is an extremely >>>>>>>>>>>> bad idea. This reviewer does not have the >>>>>>>>>>>> appropriate background to critique the proposed >>>>>>>>>>>> solution, but there must be an overwhelming >>>>>>>>>>>> reason to >>>>>>>>> reopen> >>>>> cryptographic primitives. >>>>>>>>>>>=20 >>>>>>>>>>> This is a decision that was taken by Sec Ads when >>>>>>>>>>> we were doing the crypto protection for the IGPs >>>>>>>>>>> based on some feedback from NIST. >>>>>>>>> This >>>>>>>>>>> mathematics is not new and has been done for all >>>>>>>>>>> IGPs and has been approved and rather encouraged by >>>>>>>>>>> the Security ADs. >>>>>>>>>=20 >>>>>>>>> The above does not sound like something I recognise. I >>>>>>>>> have repeatedly asked that documents not re-define >>>>>>>>> HMAC. Perhaps this time, I'll make that a DISCUSS and >>>>>>>>> not budge. I probably should have done that before >>>>>>>>> TBH. >>>>>>>>>=20 >>>>>>>>> If you are revising that doc, *please* get rid of the=20 >>>>>>>>> re-definition and just properly refer to HMAC. Its >>>>>>>>> about time to stop repeating that error. >>>>>>>>>=20 >>>>>>>>> S. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>=20 >>> -- >>>=20 >>>=20 >>> Loa Andersson email: loa@mail01.huawei.com=20 >>> Senior MPLS Expert loa@pi.nu Huawei >>> Technologies (consultant) phone: +46 739 81 21 64 >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Wed May 21 06:42:38 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F2B1A06A0; Wed, 21 May 2014 06:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVTYn-9wWf_e; Wed, 21 May 2014 06:42:34 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 889431A069D; Wed, 21 May 2014 06:42:34 -0700 (PDT) Received: by mail-qg0-f54.google.com with SMTP id q108so3188104qgd.13 for ; Wed, 21 May 2014 06:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=x02iJHw0F+EwNuGrjqtYMdGn3tWEYkMPEEaFNN7iRq0=; b=p7P96w+qm7BBoB5CPYXYV51PLwkwZBKFZCsZtduXByZU5ZaWbboA3dTA2BnvFH9u1r kvTYjUpkxGJzsOGZf6cgq6/rNAAXKZNNxm22ddC9FSEBF0yts2+hElnZAjQcD9YX0LUn PlrvWV2vX+yn7sKqQzPP954h8iqMKud/DNlr5ta8cDm5Gmn5+zmlGbmBsZ8KoiCOuPuE cfaEuTeSxQs8oGw4gJr90Mgur1RyUoifTGqmzXO839P9+SDklscmbDexAQhGOP/6mjMA PasUdCHuOkQFAbNPMixNT3Oi3q57S9UuCZD/2yQowP4HlFr/xqdJ7eMHuDVZat9FVBQj UJZw== MIME-Version: 1.0 X-Received: by 10.224.80.195 with SMTP id u3mr68512131qak.37.1400679753220; Wed, 21 May 2014 06:42:33 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.99.1 with HTTP; Wed, 21 May 2014 06:42:33 -0700 (PDT) In-Reply-To: <537C86D6.1030703@pi.nu> References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> <537BC7B6.5040406@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B609@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C5BCE.4010801@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B6A8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C7EDB.9050000@cs.tcd.ie> <537C86D6.1030703@pi.nu> Date: Wed, 21 May 2014 09:42:33 -0400 X-Google-Sender-Auth: 8gILpbe_8QrFGuOT1ZPoXMNTfNM Message-ID: From: Barry Leiba To: Loa Andersson Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/T9ax0VKX_9xTsulVnc1NzSkVnv4 Cc: "Bhatia, Manav \(Manav\)" , IETF Security Directorate , "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" , The IESG , Manav Bhatia Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 13:42:36 -0000 > I'm only the document shepherd. My feeling is that we are raising > the hurdle step by step for the KARP - initiated RFCs, the first > was comparatively smooth, now we are trying to put an 18 months > effort (individual draft to RFC) in front of approving something > that is comparatively simple and seen as raising LDP to the same > security as the other routing protocols. Well, 18 months is an extremely pessimistic time frame, so let's step back: This isn't the first time we've come here, so it's well known what needs to be documented. Stephen and Manav: how long do you really think it would take to write this document up and have it ready for last call? How much real iteration on the document is likely to be needed? It seems to me that if Manav should write something up and pass it by Stephen, you could have something that's pretty much ready by the time Manav posts it as -00. Post to a few appropriate lists for comments, post a -01, maybe a -02, then last call it. That can't be more than a few weeks. Then we have a four-week last call, another week in IESG Evaluation. We ought to be able to get this from inception to the RFC Editor queue in 2 months, maybe 3 tops. Is that really a serious problem? And that will close this issue for good, so we don't have to keep having the discussion. I understand the response that we often have, that we don't want to hold *this* document hostage for something broader that needs to be done. And that's valid as far as it goes... but when we see ourselves saying it continually about the same topic, something needs to be done or we'll never get to fixing the broader issue. Barry Barry From nobody Wed May 21 06:48:30 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E93121A069D; Wed, 21 May 2014 06:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id we7neuXmW0ir; Wed, 21 May 2014 06:48:25 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10BFB1A035E; Wed, 21 May 2014 06:48:24 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s4LDltfu002590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 May 2014 08:47:55 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s4LDlsAv002324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 May 2014 09:47:54 -0400 Received: from SG70XWXCHHUB01.zap.alcatel-lucent.com (135.253.2.46) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 21 May 2014 09:47:54 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.212]) by SG70XWXCHHUB01.zap.alcatel-lucent.com ([135.253.2.46]) with mapi id 14.02.0247.003; Wed, 21 May 2014 21:47:51 +0800 From: "Bhatia, Manav (Manav)" To: Uri Blumenthal , Stephen Farrell Thread-Topic: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 Thread-Index: AQHPcRACnDeFnD7gHUOXWsSAGM4MlZtGKCeAgAGxPwCAAaG6AIABLjlg//+CUQCAAIezIP//ohaAgAAERwCAAAU8AIAAiYEQ//+X3AAAAQ0dAAAQ3+wA Date: Wed, 21 May 2014 13:47:50 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E60BBC1@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> <537BC7B6.5040406@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B609@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C5BCE.4010801@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B6A8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C7EDB.9050000@cs.tcd.ie> <537C86D6.1030703@pi.nu> <20211F91F544D247976D84C5D778A4C32E60BA5C@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537CA2D2.4070103@cs.tcd.ie> <54E263B5-41C7-4523-9941-B3E39AE077CD@mit.edu> In-Reply-To: <54E263B5-41C7-4523-9941-B3E39AE077CD@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/niYTtXPc5VMICsHtSeMN96WzyuY Cc: Manav Bhatia , "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" , IETF Security Directorate , The IESG , Loa Andersson Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 13:48:28 -0000 When we were doing the OSPFv2 crypto authentication we had used the base HM= AC (http://tools.ietf.org/html/draft-ietf-ospf-hmac-sha-03). Ran Atkinson a= nd a few others had written another draft that did exactly what we did and = had additionally introduced the Apad (that we're discussing here) in their = crypto maths. The following presentation was made at the 73rd IETF. http://www.ietf.org/proceedings/73/slides/ospf-5.pdf We were instructed by the Security ADs back then that this was the construc= t (one with Apad) that folks wanted to use and based on that a decision was= taken to merge the two drafts (http://tools.ietf.org/html/draft-ietf-ospf-= hmac-sha-04) which finally resulted in RFC 5709. You can look at http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ospf-hmac-s= ha-04.txt to see the exact version where we introduced this crypto maths.=20 I wasn't a big fan of Apad to start with. However I am ok now, as it seems = to help us in some clever ways (protects us against attacks on the IP heade= r). I think we should live with it irrespective of whether it helps in impr= oving the HMAC or not. (BTW, it doesn't - I spoke to Hugo Krawczyk and othe= rs who clearly understand this more than me) Cheers, Manav > -----Original Message----- > From: Uri Blumenthal [mailto:uri@mit.edu] > Sent: Wednesday, May 21, 2014 6:58 PM > To: Stephen Farrell > Cc: Bhatia, Manav (Manav); Loa Andersson; Manav Bhatia; draft-ietf- > mpls-ldp-hello-crypto-auth.all@tools.ietf.org; The IESG; IETF Security > Directorate > Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello- > crypto-auth-05 >=20 > Once again, please. >=20 > 1. Who specifically, at NIST and at IESG, says that HMAC needs Apad for > security reasons (and therefore is not secure as-is)? >=20 > 2. What are those security reasons, and what are the attacks that are > foiled by Apad? >=20 > 3. What published papers/references/whatever is this documented? As > HMAC came with security proofs, I'd like to see where and how they are > invalidated (if they indeed are). >=20 >=20 >=20 > On May 21, 2014, at 8:57 , Stephen Farrell > wrote: >=20 > > > > > > On 21/05/14 12:14, Bhatia, Manav (Manav) wrote: > >> I agree with Loa. > >> > >> Our current draft is very simple and has gone through multiple > >> iterations of reviews in at least two WGs. It brings LDP to the same > >> level of security as other protocols running in the networks. > > > > Fully agree with that goal. > > > >> > >> I think we should just push it forward and if there is an interest > in > >> writing a new ID that updates HMAC specification, then we write one > >> that includes the Apad stuff. I think the latter should anyways be > >> done, regardless of what happens to this particular draft. > > > > I need to read it. But I'd be happier if that HMAC draft existed > > and was going to be processed - then we wouldn't have to do this > > discussion again. > > > > Cheers, > > S. > > > >> > >> The IETF submission site is down and hence couldn't upload the > >> revised ID (addressing Yaron's comments). Will do it tomorrow once > >> its up. > >> > >> After that its ready to be placed before the IESG. > >> > >> Cheers, Manav > >> > >>> -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu] > >>> Sent: Wednesday, May 21, 2014 4:29 PM To: Manav Bhatia; Stephen > >>> Farrell Cc: Bhatia, Manav (Manav); IETF Security Directorate; The > >>> IESG; draft- ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org; > >>> Yaron Sheffer Subject: Re: SecDir review of > >>> draft-ietf-mpls-ldp-hello-crypto-auth-05 > >>> > >>> Folks, > >>> > >>> I'm only the document shepherd. My feeling is that we are raising > >>> the hurdle step by step for the KARP - initiated RFCs, the first > >>> was comparatively smooth, now we are trying to put an 18 months > >>> effort (individual draft to RFC) in front of approving something > >>> that is comparatively simple and seen as raising LDP to the same > >>> security as the other routing protocols. > >>> > >>> So if we get to tired to push this, we are all better off not > >>> doing the security work for this particular protocol? > >>> > >>> Someone said - "Never let the best be the enemy of the possible"! > >>> > >>> /Loa > >>> > >>> > >>> > >>> On 2014-05-21 12:39, Manav Bhatia wrote: > >>>> Stephen, > >>>> > >>>>>> This however is a long drawn discussion because everyone > >>>>>> needs to > >>> be > >>>>>> convinced on the merits of updating the HMAC specification -- > >>>>>> which > >>> I > >>>>>> am not sure will take how long. > >>>>> > >>>>> So I need to look at this draft, HMAC and the other cases but > >>>>> it seems to me that you're copying a page or two of crypto spec > >>>>> each time and changing one line. Doing that over and over is a > >>>>> recipe for long term pain, isn't it? > >>>> > >>>> It sure is. > >>>> > >>>> I had volunteered to write a 1-2 page long ID that updated the > >>>> HMAC > >>> to > >>>> include the Apad, but the idea was shot down. The only > >>>> alternative left was to include the crypto stuff in each standard > >>>> that we wrote later. > >>>> > >>>>> > >>>>> (And we've had this discussion for each such draft while I've > >>>>> been on the IESG I think, which is also somewhat drawn out;-) > >>>> > >>>> This draft is probably the last one thats coming from the Routing > >>>> WG which will have this level of crypto mathematics spelled out. > >>>> All other IGPs are already covered. In case we need to change > >>>> something > >>> in > >>>> the ones already covered we can refer to the base RFC where we > >>>> have detailed the crypto maths. For example, > >>>> draft-ietf-ospf-security-extension-manual-keying-08 amongst > >>>> other things also updates the definition of Apad. It points to > >>>> the exact mathematics in RFC 5709 and only updates the Apad > >>>> definition in that draft. This draft btw has cleared the WG LC > >>>> and would be appearing before you guys very soon. > >>>> > >>>> Given this, i think we should just pass this draft with this > >>>> level of details. Subsequently, when LDP wants to update > >>>> something, it can normatively refer to this RFC and only give the > >>>> changes. > >>>> > >>>> Cheers, Manav > >>>> > >>>>> > >>>>> S. > >>>>> > >>>>> > >>>>>> > >>>>>> Cheers, Manav > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> S > >>>>>>> > >>>>>>>> > >>>>>>>> Cheers, Manav > >>>>>>>> > >>>>>>>>> -----Original Message----- From: Stephen Farrell > >>>>>>>>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, May > >>>>>>>>> 21, 2014 2:53 AM To: Bhatia, Manav (Manav); IETF > >>>>>>>>> Security Directorate; The IESG; draft- > >>>>>>>>> ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org Cc: > >>>>>>>>> Yaron Sheffer; manavbhatia@gmail.com Subject: Re: > >>>>>>>>> SecDir review of > >>>>>>>>> draft-ietf-mpls-ldp-hello-crypto-auth-05 > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On 19/05/14 21:27, Yaron Sheffer wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> * 5.1: Redefining HMAC (RFC 2104) is an extremely > >>>>>>>>>>>> bad idea. This reviewer does not have the > >>>>>>>>>>>> appropriate background to critique the proposed > >>>>>>>>>>>> solution, but there must be an overwhelming > >>>>>>>>>>>> reason to > >>>>>>>>> reopen> >>>>> cryptographic primitives. > >>>>>>>>>>> > >>>>>>>>>>> This is a decision that was taken by Sec Ads when > >>>>>>>>>>> we were doing the crypto protection for the IGPs > >>>>>>>>>>> based on some feedback from NIST. > >>>>>>>>> This > >>>>>>>>>>> mathematics is not new and has been done for all > >>>>>>>>>>> IGPs and has been approved and rather encouraged by > >>>>>>>>>>> the Security ADs. > >>>>>>>>> > >>>>>>>>> The above does not sound like something I recognise. I > >>>>>>>>> have repeatedly asked that documents not re-define > >>>>>>>>> HMAC. Perhaps this time, I'll make that a DISCUSS and > >>>>>>>>> not budge. I probably should have done that before > >>>>>>>>> TBH. > >>>>>>>>> > >>>>>>>>> If you are revising that doc, *please* get rid of the > >>>>>>>>> re-definition and just properly refer to HMAC. Its > >>>>>>>>> about time to stop repeating that error. > >>>>>>>>> > >>>>>>>>> S. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>> > >>> -- > >>> > >>> > >>> Loa Andersson email: loa@mail01.huawei.com > >>> Senior MPLS Expert loa@pi.nu Huawei > >>> Technologies (consultant) phone: +46 739 81 21 64 > > > > _______________________________________________ > > secdir mailing list > > secdir@ietf.org > > https://www.ietf.org/mailman/listinfo/secdir > > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Wed May 21 06:52:15 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3FD1A06B2; Wed, 21 May 2014 06:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arJH3wXEKbd9; Wed, 21 May 2014 06:52:10 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BD691A067C; Wed, 21 May 2014 06:52:10 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s4LDpxs9006575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 May 2014 08:51:59 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s4LDpvei014440 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 May 2014 09:51:58 -0400 Received: from SG70YWXCHHUB03.zap.alcatel-lucent.com (135.253.2.37) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 21 May 2014 09:51:57 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.212]) by SG70YWXCHHUB03.zap.alcatel-lucent.com ([135.253.2.37]) with mapi id 14.02.0328.009; Wed, 21 May 2014 21:52:10 +0800 From: "Bhatia, Manav (Manav)" To: Barry Leiba , Loa Andersson Thread-Topic: SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 Thread-Index: AQHPcRACnDeFnD7gHUOXWsSAGM4MlZtGKCeAgAGxPwCAAaG6AIABLjlg//+CUQCAAIezIP//ohaAgAAERwCAAAU8AIAALdaAgACHpfA= Date: Wed, 21 May 2014 13:51:53 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E60BBDE@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> <537BC7B6.5040406@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B609@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C5BCE.4010801@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B6A8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C7EDB.9050000@cs.tcd.ie> <537C86D6.1030703@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Fnp6lgxTXWD4L1HUW69SDJ-XI0w Cc: IETF Security Directorate , "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" , The IESG , Manav Bhatia Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 13:52:11 -0000 Hi Barry, > It seems to me that if Manav should write something up and pass it by > Stephen, you could have something that's pretty much ready by the time > Manav posts it as -00. Post to a few appropriate lists for comments, > post a -01, maybe a -02, then last call it. That can't be more than a > few weeks. Then we have a four-week last call, another week in IESG This isnt correct. One we don't know the correct home for such a draft. Eve= n if we do find a home (which am sure is possible) its going to be a very c= ontentious debate on whether HMAC needs Apad or not. Till date, I have not = heard of a very convincing reason. People would like to know the reason of = why we want this. If we don't have a very convincing reason then it's a lon= g drawn battle which aint finishin' in a few weeks time! :-) Cheers, Manav > Evaluation. We ought to be able to get this from inception to the RFC > Editor queue in 2 months, maybe 3 tops. >=20 > Is that really a serious problem? And that will close this issue for > good, so we don't have to keep having the discussion. >=20 > I understand the response that we often have, that we don't want to > hold *this* document hostage for something broader that needs to be > done. And that's valid as far as it goes... but when we see ourselves > saying it continually about the same topic, something needs to be done > or we'll never get to fixing the broader issue. >=20 > Barry >=20 >=20 > Barry From nobody Wed May 21 07:04:54 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A201A0742; Wed, 21 May 2014 07:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaJGuYcGW-7y; Wed, 21 May 2014 07:04:45 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B83D1A06AC; Wed, 21 May 2014 07:04:36 -0700 (PDT) Received: by mail-qg0-f53.google.com with SMTP id f51so3234746qge.40 for ; Wed, 21 May 2014 07:04:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=GuFH6TPDIgxTJofVxQ8eaG0RWKYPYZ9oMSeob1ew0nw=; b=c3G41TdLyVRSrtP/7dtaNpAMqBj9l8DOHQElz10Lw3/DW3NR1zJG8729fC9GPYtYw/ ApLqxwPWFXRiCrUN6LdLBJc9jhH+Uy30rTvUR8tCR5JGf50XE2ybtLz6dJw9Q0hYZeNC uRYmCDk3BywJ5lUl7V1vLMpg2tD+tYUMlEyxnmVxOfNLgKyJcUsa9t/gQqC2xNT46z8u o6VQUZBFLsWy63KXNNgVEQOSbQbi9u7FDd4zZ8euZs+5/f11VAS5wznyt/D4KRXJYNdX 4WTjC/Vbf7+9PnCRppJKEYEaYNIropEc7iQXRW6z3fFz0tF3hdVl/sA1n635k+l84gG+ owng== MIME-Version: 1.0 X-Received: by 10.224.35.209 with SMTP id q17mr68782291qad.9.1400681075311; Wed, 21 May 2014 07:04:35 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.99.1 with HTTP; Wed, 21 May 2014 07:04:35 -0700 (PDT) In-Reply-To: <20211F91F544D247976D84C5D778A4C32E60BBDE@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> <537BC7B6.5040406@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B609@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C5BCE.4010801@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B6A8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C7EDB.9050000@cs.tcd.ie> <537C86D6.1030703@pi.nu> <20211F91F544D247976D84C5D778A4C32E60BBDE@SG70YWXCHMBA05.zap.alcatel-lucent.com> Date: Wed, 21 May 2014 10:04:35 -0400 X-Google-Sender-Auth: 5P4Zm8M1uyW9R1X9H_IpZDnFunc Message-ID: From: Barry Leiba To: "Bhatia, Manav (Manav)" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/2DQl8uu1YO7moSMDXp0SUzN467M Cc: IETF Security Directorate , "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" , The IESG , Manav Bhatia , Loa Andersson Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 14:04:46 -0000 >> It seems to me that if Manav should write something up and pass it by >> Stephen, you could have something that's pretty much ready by the time >> Manav posts it as -00. Post to a few appropriate lists for comments, >> post a -01, maybe a -02, then last call it. That can't be more than a >> few weeks. Then we have a four-week last call, another week in IESG > > This isnt correct. One we don't know the correct home for such a > draft. Even if we do find a home (which am sure is possible) its going > to be a very contentious debate on whether HMAC needs Apad or not. > Till date, I have not heard of a very convincing reason. People would > like to know the reason of why we want this. If we don't have a very > convincing reason then it's a long drawn battle which aint finishin' > in a few weeks time! :-) Ack. But, then, why is it better to stick Apad in piecemeal, document by document, and have the argument all over again every time? Barry From nobody Wed May 21 07:19:55 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E22D1A04B1; Wed, 21 May 2014 07:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjaiKYDgn9YD; Wed, 21 May 2014 07:19:49 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 234261A03DD; Wed, 21 May 2014 07:19:48 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s4LEJd9a008746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 May 2014 09:19:39 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s4LEJbGm022750 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 May 2014 10:19:38 -0400 Received: from SG70YWXCHHUB03.zap.alcatel-lucent.com (135.253.2.37) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 21 May 2014 10:19:38 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.212]) by SG70YWXCHHUB03.zap.alcatel-lucent.com ([135.253.2.37]) with mapi id 14.02.0328.009; Wed, 21 May 2014 22:19:36 +0800 From: "Bhatia, Manav (Manav)" To: Barry Leiba Thread-Topic: SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 Thread-Index: AQHPcRACnDeFnD7gHUOXWsSAGM4MlZtGKCeAgAGxPwCAAaG6AIABLjlg//+CUQCAAIezIP//ohaAgAAERwCAAAU8AIAALdaAgACHpfD//36DgAARQmaQ Date: Wed, 21 May 2014 14:19:34 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E60BC4B@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> <537BC7B6.5040406@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B609@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C5BCE.4010801@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B6A8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C7EDB.9050000@cs.tcd.ie> <537C86D6.1030703@pi.nu> <20211F91F544D247976D84C5D778A4C32E60BBDE@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/59NBeMliW9MOZOSfC4Q_LZsrLD0 Cc: IETF Security Directorate , "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" , The IESG , Manav Bhatia , Loa Andersson Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 14:19:50 -0000 > > This isnt correct. One we don't know the correct home for such a > > draft. Even if we do find a home (which am sure is possible) its > going > > to be a very contentious debate on whether HMAC needs Apad or not. > > Till date, I have not heard of a very convincing reason. People would > > like to know the reason of why we want this. If we don't have a very > > convincing reason then it's a long drawn battle which aint finishin' > > in a few weeks time! :-) >=20 > Ack. > But, then, why is it better to stick Apad in piecemeal, document by > document, and have the argument all over again every time? Because this is perhaps the last document that will use the Apad. All others are already out! ;-) Cheers, Manav >=20 > Barry From nobody Wed May 21 07:25:32 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B651A06C3; Wed, 21 May 2014 07:25:21 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ec_2qZpfX5nP; Wed, 21 May 2014 07:25:08 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9198F1A03DD; Wed, 21 May 2014 07:25:03 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id u57so2127452wes.18 for ; Wed, 21 May 2014 07:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=552yAWSThcixWNvFk1W12hNUyyvwSmKXrSVhMGABYpM=; b=VjopG9U3ZN4UwVKJM9xGFw2hHuG0VRqwrqa0BG78SL7RXEq1ay6lzlFUQ/e/C2CDwE qYy57nhUhova284s9TBJnWOGG/CFPFaokqdGSoi5N5QmUCru00pWy/Ux5X6WZIpDxa3+ txGZlMhBOd9VQrKtZp6iOU7YQyTpcn1wXqcD/wyrAJR78lhHQxKOLSzmucoE/XuaoO0v Ok5fKbquJWl9dWwY9rv8puPG6mTF2cpD3qZnMcWwLPdvj5yYaLS3GEuxU6oDDdPJ599e HD9/+cpLivIjSxrwtDx2ZstzFPHLGniUB+RKQFR0TufbchO8jDtCW/gmvoz65g0M/HJa inOQ== X-Received: by 10.180.90.145 with SMTP id bw17mr668976wib.43.1400682301585; Wed, 21 May 2014 07:25:01 -0700 (PDT) Received: from [10.2.0.49] (93-173-250-199.bb.netvision.net.il. [93.173.250.199]) by mx.google.com with ESMTPSA id iy13sm2586263wic.1.2014.05.21.07.24.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 May 2014 07:25:00 -0700 (PDT) Message-ID: <537CB73B.7040408@gmail.com> Date: Wed, 21 May 2014 17:24:59 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Uri Blumenthal , Stephen Farrell References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> <537BC7B6.5040406@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B609@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C5BCE.4010801@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B6A8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C7EDB.9050000@cs.tcd.ie> <537C86D6.1030703@pi.nu> <20211F91F544D247976D84C5D778A4C32E60BA5C@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537CA2D2.4070103@cs.tcd.ie> <54E263B5-41C7-4523-9941-B3E39AE077CD@mit.edu> In-Reply-To: <54E263B5-41C7-4523-9941-B3E39AE077CD@mit.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/vd0ONtKAVqAmCyZPmeQYLA_Q8d4 Cc: "Bhatia, Manav \(Manav\)" , IETF Security Directorate , "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" , The IESG , Manav Bhatia , Loa Andersson Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 14:25:23 -0000 IMHO, this is purely a naming problem. Apad does NOT modify the base HMAC, please see http://tools.ietf.org/html/draft-ietf-mpls-ldp-hello-crypto-auth-05#section-5. It is just one more thing that's signed by HMAC. My problem with this draft is that they have different ideas about the key length, compared to RFC 2104 (top of Sec. 5.1). Also, I am unhappy that they spell out the HMAC construction instead of leaving it as a black box. But I think Apad is just fine, if it weren't for the unfortunate name that leads people to think it's modifying HMAC. Thanks, Yaron On 05/21/2014 04:28 PM, Uri Blumenthal wrote: > Once again, please. > > 1. Who specifically, at NIST and at IESG, says that HMAC needs Apad for security reasons (and therefore is not secure as-is)? > > 2. What are those security reasons, and what are the attacks that are foiled by Apad? > > 3. What published papers/references/whatever is this documented? As HMAC came with security proofs, I’d like to see where and how they are invalidated (if they indeed are). > > > > On May 21, 2014, at 8:57 , Stephen Farrell wrote: > >> >> >> On 21/05/14 12:14, Bhatia, Manav (Manav) wrote: >>> I agree with Loa. >>> >>> Our current draft is very simple and has gone through multiple >>> iterations of reviews in at least two WGs. It brings LDP to the same >>> level of security as other protocols running in the networks. >> >> Fully agree with that goal. >> >>> >>> I think we should just push it forward and if there is an interest in >>> writing a new ID that updates HMAC specification, then we write one >>> that includes the Apad stuff. I think the latter should anyways be >>> done, regardless of what happens to this particular draft. >> >> I need to read it. But I'd be happier if that HMAC draft existed >> and was going to be processed - then we wouldn't have to do this >> discussion again. >> >> Cheers, >> S. >> >>> >>> The IETF submission site is down and hence couldn’t upload the >>> revised ID (addressing Yaron's comments). Will do it tomorrow once >>> its up. >>> >>> After that its ready to be placed before the IESG. >>> >>> Cheers, Manav >>> >>>> -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu] >>>> Sent: Wednesday, May 21, 2014 4:29 PM To: Manav Bhatia; Stephen >>>> Farrell Cc: Bhatia, Manav (Manav); IETF Security Directorate; The >>>> IESG; draft- ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org; >>>> Yaron Sheffer Subject: Re: SecDir review of >>>> draft-ietf-mpls-ldp-hello-crypto-auth-05 >>>> >>>> Folks, >>>> >>>> I'm only the document shepherd. My feeling is that we are raising >>>> the hurdle step by step for the KARP - initiated RFCs, the first >>>> was comparatively smooth, now we are trying to put an 18 months >>>> effort (individual draft to RFC) in front of approving something >>>> that is comparatively simple and seen as raising LDP to the same >>>> security as the other routing protocols. >>>> >>>> So if we get to tired to push this, we are all better off not >>>> doing the security work for this particular protocol? >>>> >>>> Someone said - "Never let the best be the enemy of the possible"! >>>> >>>> /Loa >>>> >>>> >>>> >>>> On 2014-05-21 12:39, Manav Bhatia wrote: >>>>> Stephen, >>>>> >>>>>>> This however is a long drawn discussion because everyone >>>>>>> needs to >>>> be >>>>>>> convinced on the merits of updating the HMAC specification -- >>>>>>> which >>>> I >>>>>>> am not sure will take how long. >>>>>> >>>>>> So I need to look at this draft, HMAC and the other cases but >>>>>> it seems to me that you're copying a page or two of crypto spec >>>>>> each time and changing one line. Doing that over and over is a >>>>>> recipe for long term pain, isn't it? >>>>> >>>>> It sure is. >>>>> >>>>> I had volunteered to write a 1-2 page long ID that updated the >>>>> HMAC >>>> to >>>>> include the Apad, but the idea was shot down. The only >>>>> alternative left was to include the crypto stuff in each standard >>>>> that we wrote later. >>>>> >>>>>> >>>>>> (And we've had this discussion for each such draft while I've >>>>>> been on the IESG I think, which is also somewhat drawn out;-) >>>>> >>>>> This draft is probably the last one thats coming from the Routing >>>>> WG which will have this level of crypto mathematics spelled out. >>>>> All other IGPs are already covered. In case we need to change >>>>> something >>>> in >>>>> the ones already covered we can refer to the base RFC where we >>>>> have detailed the crypto maths. For example, >>>>> draft-ietf-ospf-security-extension-manual-keying-08 amongst >>>>> other things also updates the definition of Apad. It points to >>>>> the exact mathematics in RFC 5709 and only updates the Apad >>>>> definition in that draft. This draft btw has cleared the WG LC >>>>> and would be appearing before you guys very soon. >>>>> >>>>> Given this, i think we should just pass this draft with this >>>>> level of details. Subsequently, when LDP wants to update >>>>> something, it can normatively refer to this RFC and only give the >>>>> changes. >>>>> >>>>> Cheers, Manav >>>>> >>>>>> >>>>>> S. >>>>>> >>>>>> >>>>>>> >>>>>>> Cheers, Manav >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> S >>>>>>>> >>>>>>>>> >>>>>>>>> Cheers, Manav >>>>>>>>> >>>>>>>>>> -----Original Message----- From: Stephen Farrell >>>>>>>>>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, May >>>>>>>>>> 21, 2014 2:53 AM To: Bhatia, Manav (Manav); IETF >>>>>>>>>> Security Directorate; The IESG; draft- >>>>>>>>>> ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org Cc: >>>>>>>>>> Yaron Sheffer; manavbhatia@gmail.com Subject: Re: >>>>>>>>>> SecDir review of >>>>>>>>>> draft-ietf-mpls-ldp-hello-crypto-auth-05 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 19/05/14 21:27, Yaron Sheffer wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> * 5.1: Redefining HMAC (RFC 2104) is an extremely >>>>>>>>>>>>> bad idea. This reviewer does not have the >>>>>>>>>>>>> appropriate background to critique the proposed >>>>>>>>>>>>> solution, but there must be an overwhelming >>>>>>>>>>>>> reason to >>>>>>>>>> reopen> >>>>> cryptographic primitives. >>>>>>>>>>>> >>>>>>>>>>>> This is a decision that was taken by Sec Ads when >>>>>>>>>>>> we were doing the crypto protection for the IGPs >>>>>>>>>>>> based on some feedback from NIST. >>>>>>>>>> This >>>>>>>>>>>> mathematics is not new and has been done for all >>>>>>>>>>>> IGPs and has been approved and rather encouraged by >>>>>>>>>>>> the Security ADs. >>>>>>>>>> >>>>>>>>>> The above does not sound like something I recognise. I >>>>>>>>>> have repeatedly asked that documents not re-define >>>>>>>>>> HMAC. Perhaps this time, I'll make that a DISCUSS and >>>>>>>>>> not budge. I probably should have done that before >>>>>>>>>> TBH. >>>>>>>>>> >>>>>>>>>> If you are revising that doc, *please* get rid of the >>>>>>>>>> re-definition and just properly refer to HMAC. Its >>>>>>>>>> about time to stop repeating that error. >>>>>>>>>> >>>>>>>>>> S. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>> >>>> -- >>>> >>>> >>>> Loa Andersson email: loa@mail01.huawei.com >>>> Senior MPLS Expert loa@pi.nu Huawei >>>> Technologies (consultant) phone: +46 739 81 21 64 >> >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > From nobody Wed May 21 08:12:51 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6861A0327; Wed, 21 May 2014 03:39:50 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N324a6b5JW73; Wed, 21 May 2014 03:39:48 -0700 (PDT) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 202DA1A04B0; Wed, 21 May 2014 03:39:48 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id m1so1976091oag.26 for ; Wed, 21 May 2014 03:39:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5pRq24jYsQ9oMBs/dusrVV+ZnmcNV0daHhUy+npd8HM=; b=M5TohfC2JhqnpZfUuiv2NM8uRF8H56IuFbzCmwJdgPWI8O4eSi3Yd6Hem1sNzpJf6i ZmbxkkSYMQ5tvC7Ci/myrPU7LkMlYuWFrb2iykxt7inW1Y2NH18e/5WdtWlrYx0+XY1A n4rIJCgvxKKGiRYAqSXQimo+yr7zcBNoBCmrOjCsg1pESr77bzQdb38jdXTL2OgGTwQH NY3OYX86LcJLvrJMSCYlKdWQYwLzSA/yL4HbgbM2AZHMHu9FUobgu0X1Q609+sSVUAGj nXm8W55gCsHMffERWSSZ1aPiDaLaLPJQa549s5rHfyUQHYyjBIE/J+rdnQNSbt2pICOi j+vA== MIME-Version: 1.0 X-Received: by 10.182.99.198 with SMTP id es6mr17963518obb.69.1400668787034; Wed, 21 May 2014 03:39:47 -0700 (PDT) Received: by 10.76.77.97 with HTTP; Wed, 21 May 2014 03:39:46 -0700 (PDT) In-Reply-To: <537C7EDB.9050000@cs.tcd.ie> References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> <537BC7B6.5040406@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B609@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C5BCE.4010801@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B6A8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C7EDB.9050000@cs.tcd.ie> Date: Wed, 21 May 2014 16:09:46 +0530 Message-ID: From: Manav Bhatia To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/YYWZPgSNtDGChHDlFpSdTpZgCmU X-Mailman-Approved-At: Wed, 21 May 2014 08:12:45 -0700 Cc: "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" , "Bhatia, Manav \(Manav\)" , The IESG , IETF Security Directorate Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 10:39:50 -0000 Stephen, >> This however is a long drawn discussion because everyone needs to be >> convinced on the merits of updating the HMAC specification -- which I >> am not sure will take how long. > > So I need to look at this draft, HMAC and the other cases but > it seems to me that you're copying a page or two of crypto > spec each time and changing one line. Doing that over and over > is a recipe for long term pain, isn't it? It sure is. I had volunteered to write a 1-2 page long ID that updated the HMAC to include the Apad, but the idea was shot down. The only alternative left was to include the crypto stuff in each standard that we wrote later. > > (And we've had this discussion for each such draft while I've > been on the IESG I think, which is also somewhat drawn out;-) This draft is probably the last one thats coming from the Routing WG which will have this level of crypto mathematics spelled out. All other IGPs are already covered. In case we need to change something in the ones already covered we can refer to the base RFC where we have detailed the crypto maths. For example, draft-ietf-ospf-security-extension-manual-keying-08 amongst other things also updates the definition of Apad. It points to the exact mathematics in RFC 5709 and only updates the Apad definition in that draft. This draft btw has cleared the WG LC and would be appearing before you guys very soon. Given this, i think we should just pass this draft with this level of details. Subsequently, when LDP wants to update something, it can normatively refer to this RFC and only give the changes. Cheers, Manav > > S. > > >> >> Cheers, Manav >> >> >>> >>> S >>> >>>> >>>> Cheers, Manav >>>> >>>>> -----Original Message----- From: Stephen Farrell >>>>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, May 21, >>>>> 2014 2:53 AM To: Bhatia, Manav (Manav); IETF Security >>>>> Directorate; The IESG; draft- >>>>> ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org Cc: Yaron >>>>> Sheffer; manavbhatia@gmail.com Subject: Re: SecDir review of >>>>> draft-ietf-mpls-ldp-hello-crypto-auth-05 >>>>> >>>>> >>>>> >>>>> On 19/05/14 21:27, Yaron Sheffer wrote: >>>>>>>> >>>>>>>> * 5.1: Redefining HMAC (RFC 2104) is an extremely bad >>>>>>>> idea. This reviewer does not have the appropriate >>>>>>>> background to critique the proposed solution, but there >>>>>>>> must be an overwhelming reason to >>>>> reopen> >>>>> cryptographic primitives. >>>>>>> >>>>>>> This is a decision that was taken by Sec Ads when we were >>>>>>> doing the crypto protection for the IGPs based on some >>>>>>> feedback from NIST. >>>>> This >>>>>>> mathematics is not new and has been done for all IGPs and >>>>>>> has been approved and rather encouraged by the Security >>>>>>> ADs. >>>>> >>>>> The above does not sound like something I recognise. I have >>>>> repeatedly asked that documents not re-define HMAC. Perhaps >>>>> this time, I'll make that a DISCUSS and not budge. I probably >>>>> should have done that before TBH. >>>>> >>>>> If you are revising that doc, *please* get rid of the >>>>> re-definition and just properly refer to HMAC. Its about time >>>>> to stop repeating that error. >>>>> >>>>> S. >>>> >>>> >>>> >> >> >> From nobody Wed May 21 08:50:26 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8AC1A086E; Wed, 21 May 2014 08:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Q7wb6WouR2a; Wed, 21 May 2014 08:50:11 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CCF21A0886; Wed, 21 May 2014 08:50:09 -0700 (PDT) Received: from [192.168.1.8] (unknown [112.208.14.118]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 85FD31802AFE; Wed, 21 May 2014 17:50:05 +0200 (CEST) Message-ID: <537CCB2A.1060603@pi.nu> Date: Wed, 21 May 2014 17:50:02 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Barry Leiba , "Bhatia, Manav (Manav)" References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> <537BC7B6.5040406@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B609@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C5BCE.4010801@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B6A8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C7EDB.9050000@cs.tcd.ie> <537C86D6.1030703@pi.nu> <20211F91F544D247976D84C5D778A4C32E60BBDE@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/9-7gsggPie13I5jWgTX0IXdrycI Cc: IETF Security Directorate , "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" , The IESG , Manav Bhatia Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 15:50:13 -0000 Bary, On 2014-05-21 16:04, Barry Leiba wrote: >>> It seems to me that if Manav should write something up and pass it by >>> Stephen, you could have something that's pretty much ready by the time >>> Manav posts it as -00. Post to a few appropriate lists for comments, >>> post a -01, maybe a -02, then last call it. That can't be more than a >>> few weeks. Then we have a four-week last call, another week in IESG >> >> This isnt correct. One we don't know the correct home for such a >> draft. Even if we do find a home (which am sure is possible) its going >> to be a very contentious debate on whether HMAC needs Apad or not. >> Till date, I have not heard of a very convincing reason. People would >> like to know the reason of why we want this. If we don't have a very >> convincing reason then it's a long drawn battle which aint finishin' >> in a few weeks time! :-) > > Ack. > But, then, why is it better to stick Apad in piecemeal, document by > document, and have the argument all over again every time? > > Barry Are you requesting that we are revising the document that already have been approved using the "piecemeal" approach? If you are not why can't we wrp up the last one and move ahead? /Loa > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed May 21 08:58:34 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA34A1A073F; Wed, 21 May 2014 08:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nK64awR3_s8W; Wed, 21 May 2014 08:58:26 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D5F01A06F9; Wed, 21 May 2014 08:58:22 -0700 (PDT) X-AuditID: 12074423-f79916d000000c54-3d-537ccd1cfab9 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 77.42.03156.C1DCC735; Wed, 21 May 2014 11:58:20 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s4LFwGHH031442; Wed, 21 May 2014 11:58:17 -0400 Received: from [192.168.1.112] (chostler.hsd1.ma.comcast.net [24.62.227.134]) (authenticated bits=0) (User authenticated as uri@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s4LFwAhk024544 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 21 May 2014 11:58:11 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_C163AF87-0188-46A4-B184-FDFA7E675C56" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Uri Blumenthal In-Reply-To: <537CB73B.7040408@gmail.com> Date: Wed, 21 May 2014 11:58:09 -0400 Message-Id: <2D72A0EF-C4DD-4695-95D4-0744AA1AB02B@mit.edu> References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> <537BC7B6.5040406@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B609@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C5BCE.4010801@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B6A8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C7EDB.9050000@cs.tcd.ie> <537C86D6.1030703@pi.nu> <20211F91F544D247976D84C5D778A4C32E60BA5C@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537CA2D2.4070103@cs.tcd.ie> <54E263B5-41C7-4523-9941-B3E39AE077CD@mit.edu> <537CB73B.7040408@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.1878.2) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGKsWRmVeSWpSXmKPExsUixCmqrCtztibY4PN9EYu75zeyWcz4M5HZ 4t/cOcwWc+7dY7W4PKmN3eLDwocsFtP3XmO3WHV/BrsDh0frs72sHmu7r7J57Jx1l91jyZKf TB6zprexeXy5/JktgC2KyyYlNSezLLVI3y6BK+P2jgmsBc1zGSvePg9tYNzfytjFyMkhIWAi cevrWShbTOLCvfVsXYxcHEICs5kk/nf0MIEkhAQ2MkrsPSUHkdjHJDGxpZMdJMEskCCx6Gsj M4jNK2Agca1/PdgkYQF/iVV7G8DibAJKEs3NW1hBbE4BTYnpH4+B1bAIqEo8uv2ZFWQos8A0 ZokNc/4zQgyykng+7xcrxLalrBKTTlwEOoODQwSoe9pRK4hT5SVmtJ9gn8AoMAvJHbOQ3AER 15ZYtvA1M4RtIPG08xUrpri+xJt3c5gWMLKtYpRNya3SzU3MzClOTdYtTk7My0st0jXTy80s 0UtNKd3ECIosdhflHYx/DiodYhTgYFTi4V1QVB0sxJpYVlyZe4hRkoNJSZQ3ZUdNsBBfUn5K ZUZicUZ8UWlOavEhRgkOZiUR3oP7gHK8KYmVValF+TApaQ4WJXHet9ZWwUIC6YklqdmpqQWp RTBZGQ4OJQnebaeBGgWLUtNTK9Iyc0oQ0kwcnCDDeYCGzwSp4S0uSMwtzkyHyJ9iNOY4N+dU GxNHy78zbUxCLHn5ealS4rxtIKUCIKUZpXlw02DJ8RWjONBzwrx1IFU8wMQKN+8V0ComoFV/ F1eCrCpJREhJNTA6zZbU+r3zC4/Mpd6+l7c1lgiXNTpwH0yItNR/yfF7nee0jq1q904Zypqs 9n+WXBWRm7t9zya2k2+fse87PrF/gvoxbXbBktlzHINfHzBvzXfKl5APt/4e5pJaFP5QV7dB rWvR4+2eBYmPxbweOXz5ePbzqdviUa13cnweffz7/ckqV7tDuolKLMUZiYZazEXFiQAQgWVD aQMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/rW_HYQCON8htep7Y5yEm6kHLziw Cc: "Bhatia, Manav \(Manav\)" , IETF Security Directorate , "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" , The IESG , Manav Bhatia , Loa Andersson Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 15:58:29 -0000 --Apple-Mail=_C163AF87-0188-46A4-B184-FDFA7E675C56 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 1. Leave the HMAC construct alone. Do not redefine it in the draft, do = not spell it out in the draft, just use it/refer to it. Could you please = make the text reflect this? Stephen suggested =93for someone here to = re-factor their text to just do their Apad thing but to not repeat text = from 2104=94, which makes perfect sense to me. 2. You can use HMAC to sign (hmm, authenticate :) anything you wish, = including Apad. It should not be a concern from security point of view. Thanks! On May 21, 2014, at 10:24 , Yaron Sheffer wrote: > IMHO, this is purely a naming problem. Apad does NOT modify the base = HMAC, please see = http://tools.ietf.org/html/draft-ietf-mpls-ldp-hello-crypto-auth-05#sectio= n-5. It is just one more thing that's signed by HMAC. >=20 > My problem with this draft is that they have different ideas about the = key length, compared to RFC 2104 (top of Sec. 5.1). Also, I am unhappy = that they spell out the HMAC construction instead of leaving it as a = black box. >=20 > But I think Apad is just fine, if it weren't for the unfortunate name = that leads people to think it's modifying HMAC. >=20 > Thanks, > Yaron >=20 >=20 > On 05/21/2014 04:28 PM, Uri Blumenthal wrote: >> Once again, please. >>=20 >> 1. Who specifically, at NIST and at IESG, says that HMAC needs Apad = for security reasons (and therefore is not secure as-is)? >>=20 >> 2. What are those security reasons, and what are the attacks that are = foiled by Apad? >>=20 >> 3. What published papers/references/whatever is this documented? As = HMAC came with security proofs, I=92d like to see where and how they are = invalidated (if they indeed are). >>=20 >>=20 >>=20 >> On May 21, 2014, at 8:57 , Stephen Farrell = wrote: >>=20 >>>=20 >>>=20 >>> On 21/05/14 12:14, Bhatia, Manav (Manav) wrote: >>>> I agree with Loa. >>>>=20 >>>> Our current draft is very simple and has gone through multiple >>>> iterations of reviews in at least two WGs. It brings LDP to the = same >>>> level of security as other protocols running in the networks. >>>=20 >>> Fully agree with that goal. >>>=20 >>>>=20 >>>> I think we should just push it forward and if there is an interest = in >>>> writing a new ID that updates HMAC specification, then we write one >>>> that includes the Apad stuff. I think the latter should anyways be >>>> done, regardless of what happens to this particular draft. >>>=20 >>> I need to read it. But I'd be happier if that HMAC draft existed >>> and was going to be processed - then we wouldn't have to do this >>> discussion again. >>>=20 >>> Cheers, >>> S. >>>=20 >>>>=20 >>>> The IETF submission site is down and hence couldn=92t upload the >>>> revised ID (addressing Yaron's comments). Will do it tomorrow once >>>> its up. >>>>=20 >>>> After that its ready to be placed before the IESG. >>>>=20 >>>> Cheers, Manav >>>>=20 >>>>> -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu] >>>>> Sent: Wednesday, May 21, 2014 4:29 PM To: Manav Bhatia; Stephen >>>>> Farrell Cc: Bhatia, Manav (Manav); IETF Security Directorate; The >>>>> IESG; draft- ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org; >>>>> Yaron Sheffer Subject: Re: SecDir review of >>>>> draft-ietf-mpls-ldp-hello-crypto-auth-05 >>>>>=20 >>>>> Folks, >>>>>=20 >>>>> I'm only the document shepherd. My feeling is that we are raising >>>>> the hurdle step by step for the KARP - initiated RFCs, the first >>>>> was comparatively smooth, now we are trying to put an 18 months >>>>> effort (individual draft to RFC) in front of approving something >>>>> that is comparatively simple and seen as raising LDP to the same >>>>> security as the other routing protocols. >>>>>=20 >>>>> So if we get to tired to push this, we are all better off not >>>>> doing the security work for this particular protocol? >>>>>=20 >>>>> Someone said - "Never let the best be the enemy of the possible"! >>>>>=20 >>>>> /Loa >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2014-05-21 12:39, Manav Bhatia wrote: >>>>>> Stephen, >>>>>>=20 >>>>>>>> This however is a long drawn discussion because everyone >>>>>>>> needs to >>>>> be >>>>>>>> convinced on the merits of updating the HMAC specification -- >>>>>>>> which >>>>> I >>>>>>>> am not sure will take how long. >>>>>>>=20 >>>>>>> So I need to look at this draft, HMAC and the other cases but >>>>>>> it seems to me that you're copying a page or two of crypto spec >>>>>>> each time and changing one line. Doing that over and over is a >>>>>>> recipe for long term pain, isn't it? >>>>>>=20 >>>>>> It sure is. >>>>>>=20 >>>>>> I had volunteered to write a 1-2 page long ID that updated the >>>>>> HMAC >>>>> to >>>>>> include the Apad, but the idea was shot down. The only >>>>>> alternative left was to include the crypto stuff in each standard >>>>>> that we wrote later. >>>>>>=20 >>>>>>>=20 >>>>>>> (And we've had this discussion for each such draft while I've >>>>>>> been on the IESG I think, which is also somewhat drawn out;-) >>>>>>=20 >>>>>> This draft is probably the last one thats coming from the Routing >>>>>> WG which will have this level of crypto mathematics spelled out. >>>>>> All other IGPs are already covered. In case we need to change >>>>>> something >>>>> in >>>>>> the ones already covered we can refer to the base RFC where we >>>>>> have detailed the crypto maths. For example, >>>>>> draft-ietf-ospf-security-extension-manual-keying-08 amongst >>>>>> other things also updates the definition of Apad. It points to >>>>>> the exact mathematics in RFC 5709 and only updates the Apad >>>>>> definition in that draft. This draft btw has cleared the WG LC >>>>>> and would be appearing before you guys very soon. >>>>>>=20 >>>>>> Given this, i think we should just pass this draft with this >>>>>> level of details. Subsequently, when LDP wants to update >>>>>> something, it can normatively refer to this RFC and only give the >>>>>> changes. >>>>>>=20 >>>>>> Cheers, Manav >>>>>>=20 >>>>>>>=20 >>>>>>> S. >>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Cheers, Manav >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> S >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Cheers, Manav >>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- From: Stephen Farrell >>>>>>>>>>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, May >>>>>>>>>>> 21, 2014 2:53 AM To: Bhatia, Manav (Manav); IETF >>>>>>>>>>> Security Directorate; The IESG; draft- >>>>>>>>>>> ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org Cc: >>>>>>>>>>> Yaron Sheffer; manavbhatia@gmail.com Subject: Re: >>>>>>>>>>> SecDir review of >>>>>>>>>>> draft-ietf-mpls-ldp-hello-crypto-auth-05 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On 19/05/14 21:27, Yaron Sheffer wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> * 5.1: Redefining HMAC (RFC 2104) is an extremely >>>>>>>>>>>>>> bad idea. This reviewer does not have the >>>>>>>>>>>>>> appropriate background to critique the proposed >>>>>>>>>>>>>> solution, but there must be an overwhelming >>>>>>>>>>>>>> reason to >>>>>>>>>>> reopen> >>>>> cryptographic primitives. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> This is a decision that was taken by Sec Ads when >>>>>>>>>>>>> we were doing the crypto protection for the IGPs >>>>>>>>>>>>> based on some feedback from NIST. >>>>>>>>>>> This >>>>>>>>>>>>> mathematics is not new and has been done for all >>>>>>>>>>>>> IGPs and has been approved and rather encouraged by >>>>>>>>>>>>> the Security ADs. >>>>>>>>>>>=20 >>>>>>>>>>> The above does not sound like something I recognise. I >>>>>>>>>>> have repeatedly asked that documents not re-define >>>>>>>>>>> HMAC. Perhaps this time, I'll make that a DISCUSS and >>>>>>>>>>> not budge. I probably should have done that before >>>>>>>>>>> TBH. >>>>>>>>>>>=20 >>>>>>>>>>> If you are revising that doc, *please* get rid of the >>>>>>>>>>> re-definition and just properly refer to HMAC. Its >>>>>>>>>>> about time to stop repeating that error. >>>>>>>>>>>=20 >>>>>>>>>>> S. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>> -- >>>>>=20 >>>>>=20 >>>>> Loa Andersson email: loa@mail01.huawei.com >>>>> Senior MPLS Expert loa@pi.nu Huawei >>>>> Technologies (consultant) phone: +46 739 81 21 64 >>>=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 >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >>=20 --Apple-Mail=_C163AF87-0188-46A4-B184-FDFA7E675C56 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 1. = Leave the HMAC construct alone. Do not redefine it in the draft, = do not spell it out in the draft, just use it/refer to it. Could = you please make the text reflect this? Stephen suggested =93for someone here to re-factor = their text to just do their = Apad thing but to not repeat text from = 2104=94, which makes perfect sense to = me.

2. You can use HMAC to sign (hmm, = authenticate :) anything you wish, including Apad. It should not be a = concern from security point of = view.

Thanks!

On May 21, = 2014, at 10:24 , Yaron Sheffer <yaronf.ietf@gmail.com> = wrote:

IMHO, this is purely a naming problem. Apad does NOT = modify the base HMAC, please see http://tools.ietf.org/html/draft-ietf-mpls-ldp-hello-crypto-a= uth-05#section-5. It is just one more thing that's signed by = HMAC.

My problem with this draft is that they have different = ideas about the key length, compared to RFC 2104 (top of Sec. 5.1). = Also, I am unhappy that they spell out the HMAC construction instead of = leaving it as a black box.

But I think Apad is just fine, if it = weren't for the unfortunate name that leads people to think it's = modifying HMAC.

Thanks,
Yaron


On 05/21/2014 = 04:28 PM, Uri Blumenthal wrote:
Once again, = please.

1. Who specifically, at NIST and at IESG, says that HMAC = needs Apad for security reasons (and therefore is not secure = as-is)?

2. What are those security reasons, and what are the = attacks that are foiled by Apad?

3. What published = papers/references/whatever is this documented? As HMAC came with = security proofs, I=92d like to see where and how they are invalidated = (if they indeed are).



On May 21, 2014, at 8:57 , Stephen = Farrell <stephen.farrell@cs.tcd.ie>= ; wrote:



On 21/05/14 12:14, = Bhatia, Manav (Manav) wrote:
I agree with = Loa.

Our current draft is very simple and has gone through = multiple
iterations of reviews in at least two WGs. It brings LDP to = the same
level of security as other protocols running in the = networks.

Fully agree with that = goal.


I think we should just push = it forward and if there is an interest in
writing a new ID that = updates HMAC specification, then we write one
that includes the Apad = stuff. I think the latter should anyways be
done, regardless of what = happens to this particular draft.

I need to read it. = But I'd be happier if that HMAC draft existed
and was going to be = processed - then we wouldn't have to do this
discussion = again.

Cheers,
S.


The = IETF submission site is down and hence couldn=92t upload the
revised = ID (addressing Yaron's comments). Will do it tomorrow once
its = up.

After that its ready to be placed before the = IESG.

Cheers, Manav

-----Original = Message----- From: Loa Andersson [mailto:loa@pi.nu]
Sent: Wednesday, May = 21, 2014 4:29 PM To: Manav Bhatia; Stephen
Farrell Cc: Bhatia, Manav = (Manav); IETF Security Directorate; The
IESG; draft- ietf-mp= ls-ldp-hello-crypto-auth.all@tools.ietf.org;
Yaron Sheffer = Subject: Re: SecDir review = of
draft-ietf-mpls-ldp-hello-crypto-auth-05

Folks,

I'm = only the document shepherd. My feeling is that we are raising
the = hurdle step by step for the KARP - initiated RFCs, the first
was = comparatively smooth, now we are trying to put an 18 months
effort = (individual draft to RFC) in front of approving something
that is = comparatively simple and seen as raising LDP to the same
security as = the other routing protocols.

So if we get to tired to push this, = we are all better off not
doing the security work for this particular = protocol?

Someone said - "Never let the best be the enemy of the = possible"!

/Loa



On 2014-05-21 12:39, Manav Bhatia = wrote:
Stephen,

This however is a long drawn = discussion because everyone
needs = to
be
convinced on the merits of updating the HMAC specification = --
which
I
am not = sure will take how long.

So I need to look at this = draft, HMAC and the other cases but
it seems to me that you're = copying a page or two of crypto spec
each time and changing one line. = Doing that over and over is a
recipe for long term pain, isn't = it?

It sure is.

I had volunteered to write a = 1-2 page long ID that updated = the
HMAC
to
include the = Apad, but the idea was shot down. The only
alternative left was to = include the crypto stuff in each standard
that we wrote = later.


(And we've had this = discussion for each such draft while I've
been on the IESG I think, = which is also somewhat drawn out;-)

This draft is = probably the last one thats coming from the Routing
WG which will = have this level of crypto mathematics spelled out.
All other IGPs are = already covered. In case we need to = change
something
in
the = ones already covered we can refer to the base RFC where we
have = detailed the crypto maths. For = example,
draft-ietf-ospf-security-extension-manual-keying-08 = amongst
other things also updates the definition of Apad. It points = to
the exact mathematics in RFC 5709 and only updates the = Apad
definition in that draft. This draft btw has cleared the WG = LC
and would be appearing before you guys very soon.

Given = this, i think we should just pass this draft with this
level of = details. Subsequently, when LDP wants to update
something, it can = normatively refer to this RFC and only give = the
changes.

Cheers, Manav


S.



Cheers, = Manav



S


Cheers, Manav

-----Original Message----- From: Stephen Farrell
[mailto:stephen.farrell@cs.tcd.ie= ] Sent: Wednesday, May
21, 2014 2:53 AM To: Bhatia, Manav = (Manav); IETF
Security Directorate; The IESG; draft-
ietf-mp= ls-ldp-hello-crypto-auth.all@tools.ietf.org Cc:
Yaron Sheffer; manavbhatia@gmail.com Subject: = Re:
SecDir review = of
draft-ietf-mpls-ldp-hello-crypto-auth-05



On = 19/05/14 21:27, Yaron Sheffer wrote:

* = 5.1: Redefining HMAC (RFC 2104) is an extremely
bad idea. This = reviewer does not have the
appropriate background to critique the = proposed
solution, but there must be an overwhelming
reason = to
reopen> = >>>>> cryptographic primitives.

This is a decision that was = taken by Sec Ads when
we were doing the crypto protection for the = IGPs
based on some feedback from = NIST.
This
mathematics is not new and has = been done for all
IGPs and has been approved and rather encouraged = by
the Security ADs.

The above does = not sound like something I recognise. I
have repeatedly asked that = documents not re-define
HMAC. Perhaps this time, I'll make that a = DISCUSS and
not budge. I probably should have done that = before
TBH.

If you are revising that doc, *please* get rid of = the
re-definition and just properly refer to HMAC. Its
about time = to stop repeating that = error.

S.






--


Loa = Andersson =             &n= bsp;          email: = loa@mail01.huawei.com
Senior = MPLS Expert =             &n= bsp;           &nbs= p;loa@pi.nu Huawei
Technologies = (consultant)     phone: +46 739 81 21 = 64

______________________________________= _________
secdir mailing list
secdir@ietf.org
https://www.ietf.or= g/mailman/listinfo/secdir
wiki: = http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

= _______________________________________________
secdir mailing = list
secdir@ietf.org
https://www.ietf.or= g/mailman/listinfo/secdir
wiki: = http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

=

= --Apple-Mail=_C163AF87-0188-46A4-B184-FDFA7E675C56-- From nobody Wed May 21 09:12:12 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E85C31A0861; Wed, 21 May 2014 09:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8wiHsDvoaho; Wed, 21 May 2014 09:12:10 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C3E21A0874; Wed, 21 May 2014 09:12:06 -0700 (PDT) Received: from [192.168.1.8] (unknown [112.208.14.118]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id E5DC01802AFE; Wed, 21 May 2014 18:12:01 +0200 (CEST) Message-ID: <537CD04D.4030104@pi.nu> Date: Wed, 21 May 2014 18:11:57 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Barry Leiba References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> <537BC7B6.5040406@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B609@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C5BCE.4010801@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B6A8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C7EDB.9050000@cs.tcd.ie> <537C86D6.1030703@pi.nu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/8pwwO0YfXYooKcrysX98v6ucOEc Cc: "Bhatia, Manav \(Manav\)" , IETF Security Directorate , "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" , The IESG , Manav Bhatia Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 16:12:11 -0000 Barry, On 2014-05-21 15:42, Barry Leiba wrote: > Well, 18 months is an extremely pessimistic time frame, so let's step back: > This isn't the first time we've come here, so it's well known what > needs to be documented. Stephen and Manav: how long do you really > think it would take to write this document up and have it ready for > last call? How much real iteration on the document is likely to be > needed? Wish you were right, but even looking at non-contetious and simple drafts 18 months is optimistic. For example draft-ietf-mpls-special-purpose-labels dates back to 2012-03 (27 months) And the draft we are talking about here woudl be much more contentious, I actually put in 18 months as a quite optimistic estimate. /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed May 21 10:24:54 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94FEF1A0861; Wed, 21 May 2014 10:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTnsoKpNx0TI; Wed, 21 May 2014 10:24:50 -0700 (PDT) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A39A11A0879; Wed, 21 May 2014 10:24:49 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id r5so3703983qcx.21 for ; Wed, 21 May 2014 10:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=clo0j2z8Ctbh58Cr0HpdLNEc/3LPUigDNSj3Vzn+X2g=; b=OKiXEu6f8H4Z1cGVwW2igzzt1+oK8xItHImTxPUy/a3QimTFrZIK7JjGeI1Z0DVX+O gFGZb4Cp1iWlPhUGg6XxxWLwNYkgv4LyIDUDiRX049Cht3MsLu2lgdqo4Picm3oojcww GFEKThLBBI+zYoX7fLLJarLB+0rFfDUBEFjKOstrCM74Y3Yis4sgcNte8AtOjGnPaeMZ 7YC4W5WYRQl+3rpNYRfUCTT226gctLgaSTTHlV8DyCJ/XImKYLaIsaZmpfCzQyUl3vKP FJttjAcYdxj7MnkNjanLtGkvqOGbt79wzzUM/tG1AaSm//iIQbJtIMGFo0UrKaHtfMBR Vptw== MIME-Version: 1.0 X-Received: by 10.140.42.12 with SMTP id b12mr5327502qga.109.1400693088297; Wed, 21 May 2014 10:24:48 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.99.1 with HTTP; Wed, 21 May 2014 10:24:48 -0700 (PDT) In-Reply-To: <20211F91F544D247976D84C5D778A4C32E60BC4B@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> <537BC7B6.5040406@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B609@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C5BCE.4010801@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B6A8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C7EDB.9050000@cs.tcd.ie> <537C86D6.1030703@pi.nu> <20211F91F544D247976D84C5D778A4C32E60BBDE@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20211F91F544D247976D84C5D778A4C32E60BC4B@SG70YWXCHMBA05.zap.alcatel-lucent.com> Date: Wed, 21 May 2014 13:24:48 -0400 X-Google-Sender-Auth: 2DeysNWpFSOrAEtBqyuvjn42BGQ Message-ID: From: Barry Leiba To: "Bhatia, Manav (Manav)" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/pt_SyaD9iU-V3YjrMRGGRsdAvz8 Cc: IETF Security Directorate , "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" , The IESG , Manav Bhatia , Loa Andersson Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 17:24:50 -0000 >> But, then, why is it better to stick Apad in piecemeal, document by >> document, and have the argument all over again every time? > > Because this is perhaps the last document that will use the Apad. > All others are already out! ;-) OK... I didn't realize we were at the end of the trip. Barry From nobody Thu May 22 01:57:26 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62EC21A015E; Thu, 22 May 2014 01:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.043 X-Spam-Level: X-Spam-Status: No, score=-0.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbuocYpX-5Wg; Thu, 22 May 2014 01:57:17 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CF921A0060; Thu, 22 May 2014 01:57:16 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id s4M8vB4K027671; Thu, 22 May 2014 17:57:11 +0900 (JST) Received: from VAIO (ssh.nict.go.jp [133.243.3.49]) by gw2.nict.go.jp with ESMTP id s4M8vAxA026048; Thu, 22 May 2014 17:57:10 +0900 (JST) From: "Takeshi Takahashi" To: , , , Date: Thu, 22 May 2014 17:57:09 +0900 Message-ID: <000001cf759b$d1250a40$736f1ec0$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac91myTSon1TjPO7TGaWOLcNF+OSxA== Content-Language: ja X-Virus-Scanned: clamav-milter 0.97.8 at zenith2 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/UtUys3sEjaPNGrF0q_n5_Pc_0K8 Subject: [secdir] Secdir review of draft-ietf-mmusic-latching-05.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 08:57:21 -0000 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. This document describes the behavior of signaling intermediaries in RTC deployments when performing hosted NAT traversal (HNT). The document begins with summarizing the problems with NAT traversal for protocols such as SIP, and then outlines HNT and the latching mechanism that approach the problems. Nevertheless, this document is not recommending the use of latching. Instead, the document alerts its use and elaborates its security concerns in Section 5 "Security considerations" by showing several examples. The security consideration covers issues such as DoS-resistance/resource exhaustion, impersonation and addresses the use of encryption mechanism. It is an interesting, tutorial-like document, and I think this document is ready. According to the mmusic mailing list, the security consideration section has been discussed from the early stage of this draft, so the section also seems to be mature, IMHO. A bit of editorial review would be helpful. 1. It could be helpful if you could spell out the abbreviations when they appear at the first time (e.g., UAC, UAS, SIP, SDP, and SBC), not at the second time. 2. In section 1: " and described in [RFC3424]" should be "as described in [RFC3424]"? 3. In section 4: "from from" -> "from" ? The review was based on the document uploaded at https://datatracker.ietf.org/doc/draft-ietf-mmusic-latching/ . By the way, if RTC and SBC are used as the identical terms in this document, why do we use the term RTC (Real Time Communication) in the document tile while we use the term SBC in the main body texts? In any case, it is a very minor comment, and I think the draft is ready to move forward. Take From nobody Thu May 22 03:03:15 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB291A007E for ; Thu, 22 May 2014 03:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.152 X-Spam-Level: X-Spam-Status: No, score=-1.152 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkSElg0iqpsS for ; Thu, 22 May 2014 03:03:12 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 E4C621A007C for ; Thu, 22 May 2014 03:03:10 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s4MA35JM002931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 22 May 2014 13:03:05 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s4MA349H002741; Thu, 22 May 2014 13:03:04 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21373.52056.387572.824198@fireball.kivinen.iki.fi> Date: Thu, 22 May 2014 13:03:04 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/yXI76MrUCqxQ_L0-6sJkAgS0vws Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 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, 22 May 2014 10:03:14 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Shaun Cooley is next in the rotation. For telechat 2014-05-29 Reviewer LC end Draft Tobias Gondrom T 2014-03-27 draft-ietf-pwe3-p2mp-pw-requirements-09 Magnus Nystrom T 2014-05-16 draft-pal-eidr-urn-02 For telechat 2014-06-12 Derek Atkins T 2014-06-03 draft-ietf-isis-fs-lsp-01 Rob Austein T 2014-06-04 draft-ietf-nvo3-framework-06 Dacheng Zhang T 2014-06-03 draft-ietf-idr-bgp-enhanced-route-refresh-06 For telechat 2014-06-26 Brian Weis T 2014-06-16 draft-adolf-dvb-urn-upd-00 Last calls and special requests: Sam Hartman 2014-04-08 draft-ietf-l2vpn-vpls-ldp-mac-opt-11 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-06 Julien Laganier E 2013-11-21 draft-ietf-websec-key-pinning-13 Julien Laganier 2014-04-29 draft-ietf-dhc-dhcpv4-over-dhcpv6-07 Russ Mundy 2014-03-24 draft-mahalingam-dutt-dcops-vxlan-09 Sandy Murphy 2013-12-17 draft-ietf-netmod-iana-timezones-03 Joe Salowey 2014-05-29 draft-moonesamy-sshfp-ed25519-01 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Melinda Shore 2014-05-26 draft-ietf-dnsop-delegation-trust-maintainance-13 Ondrej Sury 2014-05-28 draft-ietf-ipfix-text-adt-05 Tina TSOU 2014-05-26 draft-ietf-pce-pcep-inter-domain-p2mp-procedures-06 David Waltermire 2014-06-10 draft-salgueiro-dispatch-websocket-sipclf-01 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-11 Klaas Wierenga 2014-06-20 draft-iab-2870bis-01 Tom Yu 2014-05-30 draft-ietf-6man-multicast-scopes-05 -- kivinen@iki.fi From nobody Sat May 24 22:50:24 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D26B81A024D; Sat, 24 May 2014 22:50:11 -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_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_64=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4iC4yDmAXmy; Sat, 24 May 2014 22:50:05 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 572341A0246; Sat, 24 May 2014 22:50:05 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id wn1so6988190obc.16 for ; Sat, 24 May 2014 22:50:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rU090q2IeXFomkr0AZX/CCEQQ4pYunzIfxrVvDIFYuY=; b=pbIhVq2G3rX2NvsC+KO4XoDdp6OUcPFsRFxx3XQDWmDY9r3H24LPrrxB6LtAIuyVw3 zlWevf6XeBpdS5ob/QFYkuAUYh/U+z0SKt5S2mH9GgNrnVOYvlhfKTegG8YRUuYFChBY ytjaGZcTyFniLxopull3DI8wzML1pibGN7Rqv9UYyXMm0F4TMpaMy2nzC/ulwJZUd9F7 FggElySsWr/1uqEPnhPWvYfxpT/RQAbQrjDzcaldQrNH67wx7tMNSU9aU6W943odhnvq bOFhcvtWrFhWnsj/slO6hjTMebZ9gkliQY40x1fOtKa4iFg7jCkiIEoiJ94F3cGGvYE0 XeeQ== MIME-Version: 1.0 X-Received: by 10.60.146.210 with SMTP id te18mr16653308oeb.44.1400997002543; Sat, 24 May 2014 22:50:02 -0700 (PDT) Received: by 10.76.77.97 with HTTP; Sat, 24 May 2014 22:50:02 -0700 (PDT) In-Reply-To: <57ee448f94f94cd7ba040903e604aa3c@SG70XWXCHHUB01.zap.alcatel-lucent.com> References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> <537BC7B6.5040406@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B609@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C5BCE.4010801@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B6A8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C7EDB.9050000@cs.tcd.ie> <537C86D6.1030703@pi.nu> <20211F91F544D247976D84C5D778A4C32E60BA5C@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537CA2D2.4070103@cs.tcd.ie> <54E263B5-41C7-4523-9941-B3E39AE077CD@mit.edu> <57ee448f94f94cd7ba040903e604aa3c@SG70XWXCHHUB01.zap.alcatel-lucent.com> Date: Sun, 25 May 2014 11:20:02 +0530 Message-ID: From: Manav Bhatia To: Yaron Sheffer Content-Type: multipart/mixed; boundary=047d7b5d42f8ae28c704fa330813 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/7TVn-wnBF2SOSAiT4uqd5nB7plU Cc: "Bhatia, Manav \(Manav\)" , IETF Security Directorate , "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" , The IESG , Loa Andersson Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2014 05:50:12 -0000 --047d7b5d42f8ae28c704fa330813 Content-Type: multipart/alternative; boundary=047d7b5d42f8ae28c404fa330811 --047d7b5d42f8ae28c404fa330811 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Yaron, I and few of us exchanged quite a few emails offline and we have come up with a version that addresses Yaron's and Stephen's concerns about repeating the HMAC stuff thats already present in RFC 2104. We've cleaned it up pretty nicely with very minimal changes. I am unable to submit this latest and the greatest version since i have updated my email ID in this version. The tracker requires one of the co-authors to authenticate/approve the submission. I am attaching the latest version with this email in case folks want to go through this till it becomes available formally. The draft is all set to fly now! :-) Cheers, Manav On Wed, May 21, 2014 at 7:54 PM, Yaron Sheffer wrote= : > IMHO, this is purely a naming problem. Apad does NOT modify the base > HMAC, please see > > http://tools.ietf.org/html/draft-ietf-mpls-ldp-hello-crypto-auth-05#secti= on-5 > . > It is just one more thing that's signed by HMAC. > > My problem with this draft is that they have different ideas about the > key length, compared to RFC 2104 (top of Sec. 5.1). Also, I am unhappy > that they spell out the HMAC construction instead of leaving it as a > black box. > > But I think Apad is just fine, if it weren't for the unfortunate name > that leads people to think it's modifying HMAC. > > Thanks, > Yaron > > > On 05/21/2014 04:28 PM, Uri Blumenthal wrote: > > Once again, please. > > > > 1. Who specifically, at NIST and at IESG, says that HMAC needs Apad for > security reasons (and therefore is not secure as-is)? > > > > 2. What are those security reasons, and what are the attacks that are > foiled by Apad? > > > > 3. What published papers/references/whatever is this documented? As HMA= C > came with security proofs, I=E2=80=99d like to see where and how they are > invalidated (if they indeed are). > > > > > > > > On May 21, 2014, at 8:57 , Stephen Farrell > wrote: > > > >> > >> > >> On 21/05/14 12:14, Bhatia, Manav (Manav) wrote: > >>> I agree with Loa. > >>> > >>> Our current draft is very simple and has gone through multiple > >>> iterations of reviews in at least two WGs. It brings LDP to the same > >>> level of security as other protocols running in the networks. > >> > >> Fully agree with that goal. > >> > >>> > >>> I think we should just push it forward and if there is an interest in > >>> writing a new ID that updates HMAC specification, then we write one > >>> that includes the Apad stuff. I think the latter should anyways be > >>> done, regardless of what happens to this particular draft. > >> > >> I need to read it. But I'd be happier if that HMAC draft existed > >> and was going to be processed - then we wouldn't have to do this > >> discussion again. > >> > >> Cheers, > >> S. > >> > >>> > >>> The IETF submission site is down and hence couldn=E2=80=99t upload th= e > >>> revised ID (addressing Yaron's comments). Will do it tomorrow once > >>> its up. > >>> > >>> After that its ready to be placed before the IESG. > >>> > >>> Cheers, Manav > >>> > >>>> -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu] > >>>> Sent: Wednesday, May 21, 2014 4:29 PM To: Manav Bhatia; Stephen > >>>> Farrell Cc: Bhatia, Manav (Manav); IETF Security Directorate; The > >>>> IESG; draft- ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org; > >>>> Yaron Sheffer Subject: Re: SecDir review of > >>>> draft-ietf-mpls-ldp-hello-crypto-auth-05 > >>>> > >>>> Folks, > >>>> > >>>> I'm only the document shepherd. My feeling is that we are raising > >>>> the hurdle step by step for the KARP - initiated RFCs, the first > >>>> was comparatively smooth, now we are trying to put an 18 months > >>>> effort (individual draft to RFC) in front of approving something > >>>> that is comparatively simple and seen as raising LDP to the same > >>>> security as the other routing protocols. > >>>> > >>>> So if we get to tired to push this, we are all better off not > >>>> doing the security work for this particular protocol? > >>>> > >>>> Someone said - "Never let the best be the enemy of the possible"! > >>>> > >>>> /Loa > >>>> > >>>> > >>>> > >>>> On 2014-05-21 12:39, Manav Bhatia wrote: > >>>>> Stephen, > >>>>> > >>>>>>> This however is a long drawn discussion because everyone > >>>>>>> needs to > >>>> be > >>>>>>> convinced on the merits of updating the HMAC specification -- > >>>>>>> which > >>>> I > >>>>>>> am not sure will take how long. > >>>>>> > >>>>>> So I need to look at this draft, HMAC and the other cases but > >>>>>> it seems to me that you're copying a page or two of crypto spec > >>>>>> each time and changing one line. Doing that over and over is a > >>>>>> recipe for long term pain, isn't it? > >>>>> > >>>>> It sure is. > >>>>> > >>>>> I had volunteered to write a 1-2 page long ID that updated the > >>>>> HMAC > >>>> to > >>>>> include the Apad, but the idea was shot down. The only > >>>>> alternative left was to include the crypto stuff in each standard > >>>>> that we wrote later. > >>>>> > >>>>>> > >>>>>> (And we've had this discussion for each such draft while I've > >>>>>> been on the IESG I think, which is also somewhat drawn out;-) > >>>>> > >>>>> This draft is probably the last one thats coming from the Routing > >>>>> WG which will have this level of crypto mathematics spelled out. > >>>>> All other IGPs are already covered. In case we need to change > >>>>> something > >>>> in > >>>>> the ones already covered we can refer to the base RFC where we > >>>>> have detailed the crypto maths. For example, > >>>>> draft-ietf-ospf-security-extension-manual-keying-08 amongst > >>>>> other things also updates the definition of Apad. It points to > >>>>> the exact mathematics in RFC 5709 and only updates the Apad > >>>>> definition in that draft. This draft btw has cleared the WG LC > >>>>> and would be appearing before you guys very soon. > >>>>> > >>>>> Given this, i think we should just pass this draft with this > >>>>> level of details. Subsequently, when LDP wants to update > >>>>> something, it can normatively refer to this RFC and only give the > >>>>> changes. > >>>>> > >>>>> Cheers, Manav > >>>>> > >>>>>> > >>>>>> S. > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> Cheers, Manav > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> S > >>>>>>>> > >>>>>>>>> > >>>>>>>>> Cheers, Manav > >>>>>>>>> > >>>>>>>>>> -----Original Message----- From: Stephen Farrell > >>>>>>>>>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, May > >>>>>>>>>> 21, 2014 2:53 AM To: Bhatia, Manav (Manav); IETF > >>>>>>>>>> Security Directorate; The IESG; draft- > >>>>>>>>>> ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org Cc: > >>>>>>>>>> Yaron Sheffer; manavbhatia@gmail.com Subject: Re: > >>>>>>>>>> SecDir review of > >>>>>>>>>> draft-ietf-mpls-ldp-hello-crypto-auth-05 > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On 19/05/14 21:27, Yaron Sheffer wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> * 5.1: Redefining HMAC (RFC 2104) is an extremely > >>>>>>>>>>>>> bad idea. This reviewer does not have the > >>>>>>>>>>>>> appropriate background to critique the proposed > >>>>>>>>>>>>> solution, but there must be an overwhelming > >>>>>>>>>>>>> reason to > >>>>>>>>>> reopen> >>>>> cryptographic primitives. > >>>>>>>>>>>> > >>>>>>>>>>>> This is a decision that was taken by Sec Ads when > >>>>>>>>>>>> we were doing the crypto protection for the IGPs > >>>>>>>>>>>> based on some feedback from NIST. > >>>>>>>>>> This > >>>>>>>>>>>> mathematics is not new and has been done for all > >>>>>>>>>>>> IGPs and has been approved and rather encouraged by > >>>>>>>>>>>> the Security ADs. > >>>>>>>>>> > >>>>>>>>>> The above does not sound like something I recognise. I > >>>>>>>>>> have repeatedly asked that documents not re-define > >>>>>>>>>> HMAC. Perhaps this time, I'll make that a DISCUSS and > >>>>>>>>>> not budge. I probably should have done that before > >>>>>>>>>> TBH. > >>>>>>>>>> > >>>>>>>>>> If you are revising that doc, *please* get rid of the > >>>>>>>>>> re-definition and just properly refer to HMAC. Its > >>>>>>>>>> about time to stop repeating that error. > >>>>>>>>>> > >>>>>>>>>> S. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>> > >>>> -- > >>>> > >>>> > >>>> Loa Andersson email: loa@mail01.huawei.com > >>>> Senior MPLS Expert loa@pi.nu Huawei > >>>> Technologies (consultant) phone: +46 739 81 21 64 > >> > >> _______________________________________________ > >> secdir mailing list > >> secdir@ietf.org > >> https://www.ietf.org/mailman/listinfo/secdir > >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > > > _______________________________________________ > > secdir mailing list > > secdir@ietf.org > > https://www.ietf.org/mailman/listinfo/secdir > > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > > --047d7b5d42f8ae28c404fa330811 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Yaron, I and few of us exchanged qu= ite a few emails offline and we have come up with a version that addresses = Yaron's and Stephen's concerns about repeating the HMAC stuff thats= already present in RFC 2104. We've cleaned it up pretty nicely with ve= ry minimal changes.

I am unable to submit this latest and the greatest vers= ion since i have updated my email ID in this version. The tracker requires = one of the co-authors to authenticate/approve the submission.

I am attaching the latest version with this email in case fo= lks want to go through this till it becomes available formally.
<= br>
The draft is all set to fly now! :-)

Cheers, Manav


On Wed, May 21, 2014 at 7:54 PM, Yaron Sheffer &= lt;yaronf.ietf@g= mail.com> wrote:
IMHO, this is purel= y a naming problem. Apad does NOT modify the base
HMAC, please see
http://tools.ietf.org/html/draft-ietf-mpls= -ldp-hello-crypto-auth-05#section-5.
It is just one more thing that's signed by HMAC.

My problem with this draft is that they have different ideas about the
key length, compared to RFC 2104 (top of Sec. 5.1). Also, I am unhappy
that they spell out the HMAC construction instead of leaving it as a
black box.

But I think Apad is just fine, if it weren't for the unfortunate name that leads people to think it's modifying HMAC.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron


On 05/21/2014 04:28 PM, Uri Blumenthal wrote:
> Once again, please.
>
> 1. Who specifically, at NIST and at IESG, says that HMAC needs Apad fo= r security reasons (and therefore is not secure as-is)?
>
> 2. What are those security reasons, and what are the attacks that are = foiled by Apad?
>
> 3. What published papers/references/whatever is this documented? As HM= AC came with security proofs, I=E2=80=99d like to see where and how they ar= e invalidated (if they indeed are).
>
>
>
> On May 21, 2014, at 8:57 , Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>
>>
>>
>> On 21/05/14 12:14, Bhatia, Manav (Manav) wrote:
>>> I agree with Loa.
>>>
>>> Our current draft is very simple and has gone through multiple=
>>> iterations of reviews in at least two WGs. It brings LDP to th= e same
>>> level of security as other protocols running in the networks.<= br> >>
>> Fully agree with that goal.
>>
>>>
>>> I think we should just push it forward and if there is an inte= rest in
>>> writing a new ID that updates HMAC specification, then we writ= e one
>>> that includes the Apad stuff. I think the latter should anyway= s be
>>> done, regardless of what happens to this particular draft.
>>
>> I need to read it. But I'd be happier if that HMAC draft exist= ed
>> and was going to be processed - then we wouldn't have to do th= is
>> discussion again.
>>
>> Cheers,
>> S.
>>
>>>
>>> The IETF submission site is down and hence couldn=E2=80=99t up= load the
>>> revised ID (addressing Yaron's comments). Will do it tomor= row once
>>> its up.
>>>
>>> After that its ready to be placed before the IESG.
>>>
>>> Cheers, Manav
>>>
>>>> -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu]
>>>> Sent: Wednesday, May 21, 2014 4:29 PM To: Manav Bhatia; St= ephen
>>>> Farrell Cc: Bhatia, Manav (Manav); IETF Security Directora= te; The
>>>> IESG; draft- ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org= ;
>>>> Yaron Sheffer Subject: Re: SecDir review of
>>>> draft-ietf-mpls-ldp-hello-crypto-auth-05
>>>>
>>>> Folks,
>>>>
>>>> I'm only the document shepherd. My feeling is that we = are raising
>>>> the hurdle step by step for the KARP - initiated RFCs, the= first
>>>> was comparatively smooth, now we are trying to put an 18 m= onths
>>>> effort (individual draft to RFC) in front of approving som= ething
>>>> that is comparatively simple and seen as raising LDP to th= e same
>>>> security as the other routing protocols.
>>>>
>>>> So if we get to tired to push this, we are all better off = not
>>>> doing the security work for this particular protocol?
>>>>
>>>> Someone said - "Never let the best be the enemy of th= e possible"!
>>>>
>>>> /Loa
>>>>
>>>>
>>>>
>>>> On 2014-05-21 12:39, Manav Bhatia wrote:
>>>>> Stephen,
>>>>>
>>>>>>> This however is a long drawn discussion becaus= e everyone
>>>>>>> needs to
>>>> be
>>>>>>> convinced on the merits of updating the HMAC s= pecification --
>>>>>>> which
>>>> I
>>>>>>> am not sure will take how long.
>>>>>>
>>>>>> So I need to look at this draft, HMAC and the othe= r cases but
>>>>>> it seems to me that you're copying a page or t= wo of crypto spec
>>>>>> each time and changing one line. Doing that over a= nd over is a
>>>>>> recipe for long term pain, isn't it?
>>>>>
>>>>> It sure is.
>>>>>
>>>>> I had volunteered to write a 1-2 page long ID that upd= ated the
>>>>> HMAC
>>>> to
>>>>> include the Apad, but the idea was shot down. The only=
>>>>> alternative left was to include the crypto stuff in ea= ch standard
>>>>> that we wrote later.
>>>>>
>>>>>>
>>>>>> (And we've had this discussion for each such d= raft while I've
>>>>>> been on the IESG I think, which is also somewhat d= rawn out;-)
>>>>>
>>>>> This draft is probably the last one thats coming from = the Routing
>>>>> WG which will have this level of crypto mathematics sp= elled out.
>>>>> All other IGPs are already covered. In case we need to= change
>>>>> something
>>>> in
>>>>> the ones already covered we can refer to the base RFC = where we
>>>>> have detailed the crypto maths. For example,
>>>>> draft-ietf-ospf-security-extension-manual-keying-08 am= ongst
>>>>> other things also updates the definition of Apad. It p= oints to
>>>>> the exact mathematics in RFC 5709 and only updates the= Apad
>>>>> definition in that draft. This draft btw has cleared t= he WG LC
>>>>> and would be appearing before you guys very soon.
>>>>>
>>>>> Given this, i think we should just pass this draft wit= h this
>>>>> level of details. Subsequently, when LDP wants to upda= te
>>>>> something, it can normatively refer to this RFC and on= ly give the
>>>>> changes.
>>>>>
>>>>> Cheers, Manav
>>>>>
>>>>>>
>>>>>> S.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Cheers, Manav
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> S
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Cheers, Manav
>>>>>>>>>
>>>>>>>>>> -----Original Message----- From: S= tephen Farrell
>>>>>>>>>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, May
>>>>>>>>>> 21, 2014 2:53 AM To: Bhatia, Manav= (Manav); IETF
>>>>>>>>>> Security Directorate; The IESG; dr= aft-
>>>>>>>>>> ietf-mpls-ldp-hello-crypto-auth.all@too= ls.ietf.org Cc:
>>>>>>>>>> Yaron Sheffer; manavbhatia@gmail.com Subject: Re:
>>>>>>>>>> SecDir review of
>>>>>>>>>> draft-ietf-mpls-ldp-hello-crypto-a= uth-05
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 19/05/14 21:27, Yaron Sheffer w= rote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> * 5.1: Redefining HMAC= (RFC 2104) is an extremely
>>>>>>>>>>>>> bad idea. This reviewe= r does not have the
>>>>>>>>>>>>> appropriate background= to critique the proposed
>>>>>>>>>>>>> solution, but there mu= st be an overwhelming
>>>>>>>>>>>>> reason to
>>>>>>>>>> reopen> >>>>> cr= yptographic primitives.
>>>>>>>>>>>>
>>>>>>>>>>>> This is a decision that wa= s taken by Sec Ads when
>>>>>>>>>>>> we were doing the crypto p= rotection for the IGPs
>>>>>>>>>>>> based on some feedback fro= m NIST.
>>>>>>>>>> This
>>>>>>>>>>>> mathematics is not new and= has been done for all
>>>>>>>>>>>> IGPs and has been approved= and rather encouraged by
>>>>>>>>>>>> the Security ADs.
>>>>>>>>>>
>>>>>>>>>> The above does not sound like some= thing I recognise. I
>>>>>>>>>> have repeatedly asked that documen= ts not re-define
>>>>>>>>>> HMAC. Perhaps this time, I'll = make that a DISCUSS and
>>>>>>>>>> not budge. I probably should have = done that before
>>>>>>>>>> TBH.
>>>>>>>>>>
>>>>>>>>>> If you are revising that doc, *ple= ase* get rid of the
>>>>>>>>>> re-definition and just properly re= fer to HMAC. Its
>>>>>>>>>> about time to stop repeating that = error.
>>>>>>>>>>
>>>>>>>>>> S.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>> --
>>>>
>>>>
>>>> Loa Andersson =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0email: loa@mail01.huawei.com
>>>> Senior MPLS Expert =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loa@pi.nu Huawei
>>>> Technologies (consultant) =C2=A0 =C2=A0 phone: +46 739 81 21 64=
>>
>> _______________________________________________
>> secdir mailing list
>> secdir@ietf.org
>> https://www.ietf.org/mailman/listinfo/secdir
>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirRevi= ew
>
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>

--047d7b5d42f8ae28c404fa330811-- --047d7b5d42f8ae28c704fa330813 Content-Type: text/plain; charset=US-ASCII; name="draft-ietf-mpls-ldp-hello-crypto-auth-06.txt" Content-Disposition: attachment; filename="draft-ietf-mpls-ldp-hello-crypto-auth-06.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hvlxcsbs0 CgoKCk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBMLiBaaGVuZwpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIE0uIENoZW4KSW50ZW5kZWQgc3RhdHVzOiBTdGFu ZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICBIdWF3ZWkgVGVjaG5vbG9naWVzCkV4cGly ZXM6IE5vdmVtYmVyIDIyLCAyMDE0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IE0uIEJoYXRpYQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgQWxjYXRlbC1MdWNlbnQKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWF5IDIxLCAyMDE0CgoKICAgICAgICAgICAg ICAgICBMRFAgSGVsbG8gQ3J5cHRvZ3JhcGhpYyBBdXRoZW50aWNhdGlvbgogICAgICAgICAgICAg IGRyYWZ0LWlldGYtbXBscy1sZHAtaGVsbG8tY3J5cHRvLWF1dGgtMDYudHh0CgpBYnN0cmFjdAoK ICAgVGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIGEgbmV3IG9wdGlvbmFsIENyeXB0b2dyYXBoaWMg QXV0aGVudGljYXRpb24KICAgVExWIHRoYXQgTERQIGNhbiB1c2UgdG8gc2VjdXJlIGl0cyBIZWxs byBtZXNzYWdlcy4gIEl0IHNlY3VyZXMgdGhlCiAgIEhlbGxvIG1lc3NhZ2VzIGFnYWluc3Qgc3Bv b2ZpbmcgYXR0YWNrcyBhbmQgc29tZSB3ZWxsIGtub3duIGF0dGFja3MKICAgYWdhaW5zdCB0aGUg SVAgaGVhZGVyLiAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBtZWNoYW5pc20gdG8gc2VjdXJl CiAgIHRoZSBMRFAgSGVsbG8gbWVzc2FnZXMgdXNpbmcgTmF0aW9uYWwgSW5zdGl0dXRlIG9mIFN0 YW5kYXJkcyBhbmQKICAgVGVjaG5vbG9neSAoTklTVCkgU2VjdXJlIEhhc2ggU3RhbmRhcmQgZmFt aWx5IG9mIGFsZ29yaXRobXMuCgpSZXF1aXJlbWVudHMgTGFuZ3VhZ2UKCiAgIFRoZSBrZXkgd29y ZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwK ICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BU SU9OQUwiIGluIHRoaXMKICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2Ny aWJlZCBpbiBSRkMgMjExOSBbUkZDMjExOV0uCgpTdGF0dXMgb2YgVGhpcyBNZW1vCgogICBUaGlz IEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhl CiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuCgogICBJbnRlcm5ldC1EcmFmdHMg YXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZwogICBUYXNr IEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0 ZQogICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBj dXJyZW50IEludGVybmV0LQogICBEcmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RyYWZ0cy9jdXJyZW50Ly4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1l bnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQgbWF5IGJlIHVwZGF0 ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0 aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVy ZW5jZQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBw cm9ncmVzcy4iCgogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIE5vdmVtYmVy IDIyLCAyMDE0LgoKQ29weXJpZ2h0IE5vdGljZQoKICAgQ29weXJpZ2h0IChjKSAyMDE0IElFVEYg VHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlCiAgIGRvY3VtZW50IGF1dGhv cnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLgoKCgoKWmhlbmcsIGV0IGFsLiAgICAgICAgICAgRXhw aXJlcyBOb3ZlbWJlciAyMiwgMjAxNCAgICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQt RHJhZnQgICBMRFAgSGVsbG8gQ3J5cHRvZ3JhcGhpYyBBdXRoZW50aWNhdGlvbiAgICAgICAgIE1h eSAyMDE0CgoKICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElF VEYgVHJ1c3QncyBMZWdhbAogICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRz CiAgIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0 aGUgZGF0ZSBvZgogICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmll dyB0aGVzZSBkb2N1bWVudHMKICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmln aHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0CiAgIHRvIHRoaXMgZG9jdW1lbnQuICBD b2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0CiAgIGluY2x1 ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQu ZSBvZgogICB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhv dXQgd2FycmFudHkgYXMKICAgZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNl LgoKVGFibGUgb2YgQ29udGVudHMKCiAgIDEuICBJbnRyb2R1Y3Rpb24gIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMgogICAyLiAgQ3J5cHRvZ3JhcGhp YyBBdXRoZW50aWNhdGlvbiBUTFYgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQKICAg ICAyLjEuICBPcHRpb25hbCBQYXJhbWV0ZXIgZm9yIEhlbGxvIE1lc3NhZ2UgIC4gLiAuIC4gLiAu IC4gLiAuIC4gICA0CiAgICAgMi4yLiAgTERQIFNlY3VyaXR5IEFzc29jaWF0aW9uICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNAogICAgIDIuMy4gIENyeXB0b2dyYXBoaWMgQXV0 aGVudGljYXRpb24gVExWIEVuY29kaW5nIC4gLiAuIC4gLiAuIC4gLiAgIDYKICAgICAyLjQuICBT ZXF1ZW5jZSBOdW1iZXIgV3JhcCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g ICA4CiAgIDMuICBDcnlwdG9ncmFwaGljIEF1dGhlbnRpY2F0aW9uIFByb2NlZHVyZSAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAgOAogICA0LiAgQ3Jvc3MgUHJvdG9jb2wgQXR0YWNrIE1pdGlnYXRp b24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDgKICAgNS4gIENyeXB0b2dyYXBoaWMg QXNwZWN0cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA4CiAgICAg NS4xLiAgUHJlcGFyaW5nIHRoZSBDcnlwdG9ncmFwaGljIEtleSAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAgOQogICAgIDUuMi4gIENvbXB1dGluZyB0aGUgSGFzaCAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDkKICAgICA1LjMuICBSZXN1bHQgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEwCiAgIDYuICBQcm9jZXNz aW5nIEhlbGxvIE1lc3NhZ2UgVXNpbmcgQ3J5cHRvZ3JhcGhpYyBBdXRoZW50aWNhdGlvbiAuICAx MAogICAgIDYuMS4gIFRyYW5zbWlzc2lvbiBVc2luZyBDcnlwdG9ncmFwaGljIEF1dGhlbnRpY2F0 aW9uIC4gLiAuIC4gLiAgMTAKICAgICA2LjIuICBSZWNlaXB0IFVzaW5nIENyeXB0b2dyYXBoaWMg QXV0aGVudGljYXRpb24gIC4gLiAuIC4gLiAuIC4gIDEwCiAgIDcuICBTZWN1cml0eSBDb25zaWRl cmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMQogICA4LiAg SUFOQSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgMTIKICAgOS4gIEFja25vd2xlZGdlbWVudHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEyCiAgIDEwLiBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMgogICAgIDEwLjEuICBOb3Jt YXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTIK ICAgICAxMC4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDEzCiAgIEF1dGhvcnMnIEFkZHJlc3NlcyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMwoKMS4gIEludHJvZHVjdGlvbgoKICAgVGhl IExhYmVsIERpc3RyaWJ1dGlvbiBQcm90b2NvbCAoTERQKSBbUkZDNTAzNl0gc2V0cyB1cCBMRFAg c2Vzc2lvbnMKICAgdGhhdCBydW4gYmV0d2VlbiBMRFAgcGVlcnMuICBUaGUgcGVlcnMgY291bGQg ZWl0aGVyIGJlIGRpcmVjdGx5CiAgIGNvbm5lY3RlZCBhdCB0aGUgbGluayBsZXZlbCBvciBjb3Vs ZCBiZSBtdWx0aXBsZSBob3BzIGF3YXkuICBBbiBMRFAKICAgTGFiZWwgU3dpdGNoaW5nIFJvdXRl ciAoTFNSKSBjb3VsZCBlaXRoZXIgYmUgY29uZmlndXJlZCB3aXRoIHRoZQogICBpZGVudGl0eSBv ZiBpdHMgcGVlcnMgb3IgY291bGQgZGlzY292ZXIgdGhlbSB1c2luZyBMRFAgSGVsbG8KICAgbWVz c2FnZXMuICBUaGVzZSBtZXNzYWdlcyBhcmUgc2VudCBlbmNhcHN1bGF0ZWQgaW4gVURQIGFkZHJl c3NlZCB0bwogICAiYWxsIHJvdXRlcnMgb24gdGhpcyBzdWJuZXQiIG9yIHRvIGEgc3BlY2lmaWMg SVAgYWRkcmVzcy4gIFBlcmlvZGljCiAgIEhlbGxvIG1lc3NhZ2VzIGFyZSBhbHNvIHVzZWQgdG8g bWFpbnRhaW4gdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIExEUAogICBwZWVycyBuZWNlc3Nhcnkg dG8ga2VlcCB0aGUgTERQIHNlc3Npb24gYWN0aXZlLgoKCgoKClpoZW5nLCBldCBhbC4gICAgICAg ICAgIEV4cGlyZXMgTm92ZW1iZXIgMjIsIDIwMTQgICAgICAgICAgICAgICBbUGFnZSAyXQoMCklu dGVybmV0LURyYWZ0ICAgTERQIEhlbGxvIENyeXB0b2dyYXBoaWMgQXV0aGVudGljYXRpb24gICAg ICAgICBNYXkgMjAxNAoKCiAgIFNpbmNlIHRoZSBIZWxsbyBtZXNzYWdlcyBhcmUgc2VudCB1c2lu ZyBVRFAgYW5kIG5vdCBUQ1AsIHRoZXNlCiAgIG1lc3NhZ2VzIGNhbm5vdCB1c2UgdGhlIHNlY3Vy aXR5IG1lY2hhbmlzbXMgZGVmaW5lZCBmb3IgVENQCiAgIFtSRkM1OTI2XS4gIFdoaWxlIHNvbWUg Y29uZmlndXJhdGlvbiBndWlkYW5jZSBpcyBnaXZlbiBpbiBbUkZDNTAzNl0KICAgdG8gaGVscCBw cm90ZWN0IGFnYWluc3QgZmFsc2UgZGlzY292ZXJ5IG1lc3NhZ2VzLCBpdCBkb2VzIG5vdCBwcm92 aWRlCiAgIGFuIGV4cGxpY2l0IHNlY3VyaXR5IG1lY2hhbmlzbSB0byBwcm90ZWN0IHRoZSBIZWxs byBtZXNzYWdlcy4KCiAgIFNwb29maW5nIGEgSGVsbG8gcGFja2V0IGZvciBhbiBleGlzdGluZyBh ZGphY2VuY3kgY2FuIGNhdXNlIHRoZSB2YWxpZAogICBhZGphY2VuY3kgdG8gdGltZSBvdXQgYW5k IGluIHR1cm4gY2FuIHJlc3VsdCBpbiB0ZXJtaW5hdGlvbiBvZiB0aGUKICAgYXNzb2NpYXRlZCBz ZXNzaW9uLiAgVGhpcyBjYW4gb2NjdXIgd2hlbiB0aGUgc3Bvb2ZlZCBIZWxsbyBzcGVjaWZpZXMK ICAgYSBzbWFsbGVyIEhvbGQgVGltZSwgY2F1c2luZyB0aGUgcmVjZWl2ZXIgdG8gZXhwZWN0IEhl bGxvcyB3aXRoaW4KICAgdGhpcyBzbWFsbGVyIGludGVydmFsLCB3aGlsZSB0aGUgdHJ1ZSBuZWln aGJvciBjb250aW51ZXMgc2VuZGluZwogICBIZWxsb3MgYXQgdGhlIHByZXZpb3VzbHkgYWdyZWVk IGxvd2VyIGZyZXF1ZW5jeS4gIFNwb29maW5nIGEgSGVsbG8KICAgcGFja2V0IGNhbiBhbHNvIGNh dXNlIHRoZSBMRFAgc2Vzc2lvbiB0byBiZSB0ZXJtaW5hdGVkIGRpcmVjdGx5LAogICB3aGljaCBj YW4gb2NjdXIgd2hlbiB0aGUgc3Bvb2ZlZCBIZWxsbyBzcGVjaWZpZXMgYSBkaWZmZXJlbnQKICAg VHJhbnNwb3J0IEFkZHJlc3MsIG90aGVyIHRoYW4gdGhlIHByZXZpb3VzbHkgYWdyZWVkIG9uZSBi ZXR3ZWVuCiAgIG5laWdoYm9ycy4gIFNwb29mZWQgSGVsbG8gbWVzc2FnZXMgaGF2ZSBiZWVuIG9i c2VydmVkIGFuZCByZXBvcnRlZCBhcwogICBhIHJlYWwgcHJvYmxlbSBpbiBwcm9kdWN0aW9uIG5l dHdvcmtzIFtSRkM2OTUyXS4KCiAgIEZvciBMaW5rIEhlbGxvLCBbUkZDNTAzNl0gc3RhdGVzIHRo YXQgdGhlIHRocmVhdCBvZiBzcG9vZmVkIEhlbGxvcwogICBjYW4gYmUgcmVkdWNlZCBieSBhY2Nl cHRpbmcgSGVsbG9zIG9ubHkgb24gaW50ZXJmYWNlcyB0byB3aGljaCBMU1JzCiAgIHRoYXQgY2Fu IGJlIHRydXN0ZWQgYXJlIGRpcmVjdGx5IGNvbm5lY3RlZCwgYW5kIGlnbm9yaW5nIEhlbGxvcyBu b3QKICAgYWRkcmVzc2VkIHRvIHRoZSAiYWxsIHJvdXRlcnMgb24gdGhpcyBzdWJuZXQiIG11bHRp Y2FzdCBncm91cC4gIFRoZQogICBHZW5lcmFsaXplZCBUVEwgU2VjdXJpdHkgTWVjaGFuaXNtIChH VFNNKSBwcm92aWRlcyBhIHNpbXBsZSBhbmQKICAgcmVhc29uYWJseSByb2J1c3QgZGVmZW5zZSBt ZWNoYW5pc20gZm9yIExpbmsgSGVsbG8gW1JGQzY3MjBdLCBidXQgaXQKICAgZG9lcyBub3Qgc2Vj dXJlIGFnYWluc3QgcGFja2V0IHNwb29maW5nIGF0dGFjayBvciByZXBsYXkKICAgYXR0YWNrW1JG QzUwODJdLgoKICAgU3Bvb2ZpbmcgYXR0YWNrcyB2aWEgVGFyZ2V0ZWQgSGVsbG9zIGFyZSBhIHBv dGVudGlhbGx5IG1vcmUgc2VyaW91cwogICB0aHJlYXQuICBbUkZDNTAzNl0gc3RhdGVzIHRoYXQg YW4gTFNSIGNhbiByZWR1Y2UgdGhlIHRocmVhdCBvZgogICBzcG9vZmVkIFRhcmdldGVkIEhlbGxv cyBieSBmaWx0ZXJpbmcgdGhlbSBhbmQgYWNjZXB0aW5nIG9ubHkgdGhvc2UKICAgb3JpZ2luYXRp bmcgYXQgc291cmNlcyBwZXJtaXR0ZWQgYnkgYW4gYWNjZXNzIGxpc3QuICBIb3dldmVyLAogICBm aWx0ZXJpbmcgdXNpbmcgYWNjZXNzIGxpc3RzIHJlcXVpcmVzIExTUiByZXNvdXJjZSwgYW5kIGRv ZXMgbm90CiAgIHByZXZlbnQgSVAtYWRkcmVzcyBzcG9vZmluZy4KCiAgIFRoaXMgZG9jdW1lbnQg aW50cm9kdWNlcyBhIG5ldyBDcnlwdG9ncmFwaGljIEF1dGhlbnRpY2F0aW9uIFRMViB3aGljaAog ICBpcyB1c2VkIGluIExEUCBIZWxsbyBtZXNzYWdlcyBhcyBhbiBvcHRpb25hbCBwYXJhbWV0ZXIu ICBJdCBlbmhhbmNlcwogICB0aGUgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtIGZvciBMRFAgYnkg c2VjdXJpbmcgdGhlIEhlbGxvIG1lc3NhZ2UKICAgYWdhaW5zdCBzcG9vZmluZyBhdHRhY2suICBJ dCBhbHNvIGludHJvZHVjZXMgYSBjcnlwdG9ncmFwaGljIHNlcXVlbmNlCiAgIG51bWJlciBjYXJy aWVkIGluIHRoZSBIZWxsbyBtZXNzYWdlcyB0aGF0IGNhbiBiZSB1c2VkIHRvIHByb3RlY3QKICAg YWdhaW5zdCByZXBsYXkgYXR0YWNrcy4gIFRoZSBMU1JzIGNvdWxkIGJlIGNvbmZpZ3VyZWQgdG8g b25seSBhY2NlcHQKICAgSGVsbG8gbWVzc2FnZXMgZnJvbSBzcGVjaWZpYyBwZWVycyB3aGVuIGF1 dGhlbnRpY2F0aW9uIGlzIGluIHVzZS4KCiAgIFVzaW5nIHRoaXMgQ3J5cHRvZ3JhcGhpYyBBdXRo ZW50aWNhdGlvbiBUTFYsIG9uZSBvciBtb3JlIHNlY3JldCBrZXlzCiAgICh3aXRoIGNvcnJlc3Bv bmRpbmcgU2VjdXJpdHkgQXNzb2NpYXRpb24gKFNBKSBJRHMpIGFyZSBjb25maWd1cmVkIGluCiAg IGVhY2ggc3lzdGVtLiAgRm9yIGVhY2ggTERQIEhlbGxvIG1lc3NhZ2UsIHRoZSBrZXkgaXMgdXNl ZCB0byBnZW5lcmF0ZQogICBhbmQgdmVyaWZ5IGEgSE1BQyBIYXNoIHRoYXQgaXMgc3RvcmVkIGlu IHRoZSBMRFAgSGVsbG8gbWVzc2FnZS4gIEZvcgogICBjcnlwdG9ncmFwaGljIGhhc2ggZnVuY3Rp b24sIHRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgdG8gdXNlIFNIQS0xLAogICBTSEEtMjU2LCBTSEEt Mzg0LCBhbmQgU0hBLTUxMiBkZWZpbmVkIGluIFVTIE5JU1QgU2VjdXJlIEhhc2ggU3RhbmRhcmQK CgoKWmhlbmcsIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMiwgMjAxNCAgICAg ICAgICAgICAgIFtQYWdlIDNdCgwKSW50ZXJuZXQtRHJhZnQgICBMRFAgSGVsbG8gQ3J5cHRvZ3Jh cGhpYyBBdXRoZW50aWNhdGlvbiAgICAgICAgIE1heSAyMDE0CgoKICAgKFNIUykgW0ZJUFMtMTgw LTNdLiAgVGhlIEhNQUMgYXV0aGVudGljYXRpb24gbW9kZSBkZWZpbmVkIGluCiAgIFtSRkMyMTA0 XSBpcyB1c2VkLiAgT2YgdGhlIGFib3ZlLCBpbXBsZW1lbnRhdGlvbnMgTVVTVCBpbmNsdWRlCiAg IHN1cHBvcnQgZm9yIGF0IGxlYXN0IEhNQUMtU0hBLTI1NiBhbmQgU0hPVUxEIGluY2x1ZGUgc3Vw cG9ydCBmb3IKICAgSE1BQy1TSEEtMSBhbmQgTUFZIGluY2x1ZGUgc3VwcG9ydCBmb3IgZWl0aGVy IG9mIEhNQUMtU0hBLTM4NCBvcgogICBITUFDLVNIQS01MTIuCgoyLiAgQ3J5cHRvZ3JhcGhpYyBB dXRoZW50aWNhdGlvbiBUTFYKCjIuMS4gIE9wdGlvbmFsIFBhcmFtZXRlciBmb3IgSGVsbG8gTWVz c2FnZQoKICAgW1JGQzUwMzZdIGRlZmluZXMgdGhlIGVuY29kaW5nIGZvciB0aGUgSGVsbG8gbWVz c2FnZS4gIEVhY2ggSGVsbG8KICAgbWVzc2FnZSBjb250YWlucyB6ZXJvIG9yIG1vcmUgT3B0aW9u YWwgUGFyYW1ldGVycywgZWFjaCBlbmNvZGVkIGFzIGEKICAgVExWLiAgVGhyZWUgT3B0aW9uYWwg UGFyYW1ldGVycyBhcmUgZGVmaW5lZCBieSBbUkZDNTAzNl0uICBUaGlzCiAgIGRvY3VtZW50IGRl ZmluZXMgYSBuZXcgT3B0aW9uYWwgUGFyYW1ldGVyOiB0aGUgQ3J5cHRvZ3JhcGhpYwogICBBdXRo ZW50aWNhdGlvbiBwYXJhbWV0ZXIuCgogICBPcHRpb25hbCBQYXJhbWV0ZXIgICAgICAgICAgICAg ICBUeXBlCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gIC0tLS0tLS0tCiAgIElQ djQgVHJhbnNwb3J0IEFkZHJlc3MgICAgICAgICAgIDB4MDQwMSAoUkZDNTAzNikKICAgQ29uZmln dXJhdGlvbiBTZXF1ZW5jZSBOdW1iZXIgICAgMHgwNDAyIChSRkM1MDM2KQogICBJUHY2IFRyYW5z cG9ydCBBZGRyZXNzICAgICAgICAgICAweDA0MDMgKFJGQzUwMzYpCiAgIENyeXB0b2dyYXBoaWMg QXV0aGVudGljYXRpb24gICAgIDB4MDQwNCAodGhpcyBkb2N1bWVudCwgVEJEMSBieSBJQU5BKQoK CiAgIFRoZSBDcnlwdG9ncmFwaGljIEF1dGhlbnRpY2F0aW9uIFRMViBFbmNvZGluZyBpcyBkZXNj cmliZWQgaW4gc2VjdGlvbgogICAyLjMuCgoyLjIuICBMRFAgU2VjdXJpdHkgQXNzb2NpYXRpb24K CiAgIEFuIExEUCBTZWN1cml0eSBBc3NvY2lhdGlvbiAoU0EpIGNvbnRhaW5zIGEgc2V0IG9mIHBh cmFtZXRlcnMgc2hhcmVkCiAgIGJldHdlZW4gYW55IHR3byBsZWdpdGltYXRlIExEUCBzcGVha2Vy cy4KCiAgIFBhcmFtZXRlcnMgYXNzb2NpYXRlZCB3aXRoIGFuIExEUCBTQSBhcmUgYXMgZm9sbG93 czoKCiAgIG8gIFNlY3VyaXR5IEFzc29jaWF0aW9uIElkZW50aWZpZXIgKFNBIElEKQoKICAgICAg VGhpcyBpcyBhIDMyLWJpdCB1bnNpZ25lZCBpbnRlZ2VyIHVzZWQgdG8gdW5pcXVlbHkgaWRlbnRp ZnkgYW4gTERQCiAgICAgIFNBIGJldHdlZW4gdHdvIExEUCBwZWVycywgYXMgbWFudWFsbHkgY29u ZmlndXJlZCBieSB0aGUgbmV0d29yawogICAgICBvcGVyYXRvciAob3IsIGluIHRoZSBmdXR1cmUs IHBvc3NpYmx5IGJ5IHNvbWUga2V5IG1hbmFnZW1lbnQKICAgICAgcHJvdG9jb2wgc3BlY2lmaWVk IGJ5IHRoZSBJRVRGKSAuCgogICAgICBUaGUgcmVjZWl2ZXIgZGV0ZXJtaW5lcyB0aGUgYWN0aXZl IFNBIGJ5IGxvb2tpbmcgYXQgdGhlIFNBIElECiAgICAgIGZpZWxkIGluIHRoZSBpbmNvbWluZyBI ZWxsbyBtZXNzYWdlLgoKICAgICAgVGhlIHNlbmRlciwgYmFzZWQgb24gdGhlIGFjdGl2ZSBjb25m aWd1cmF0aW9uLCBzZWxlY3RzIGFuIFNBIHRvCiAgICAgIHVzZSBhbmQgcHV0cyB0aGUgY29ycmVj dCBTQSBJRCB2YWx1ZSBhc3NvY2lhdGVkIHdpdGggdGhlIFNBIGluIHRoZQogICAgICBMRFAgSGVs bG8gbWVzc2FnZS4gIElmIG11bHRpcGxlIHZhbGlkIGFuZCBhY3RpdmUgTERQIFNBcyBleGlzdCBm b3IKCgoKClpoZW5nLCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMjIsIDIwMTQg ICAgICAgICAgICAgICBbUGFnZSA0XQoMCkludGVybmV0LURyYWZ0ICAgTERQIEhlbGxvIENyeXB0 b2dyYXBoaWMgQXV0aGVudGljYXRpb24gICAgICAgICBNYXkgMjAxNAoKCiAgICAgIGEgZ2l2ZW4g aW50ZXJmYWNlLCB0aGUgc2VuZGVyIG1heSB1c2UgYW55IG9mIHRob3NlIFNBcyB0byBwcm90ZWN0 CiAgICAgIHRoZSBwYWNrZXQuCgogICAgICBVc2luZyBTQSBJRHMgbWFrZXMgY2hhbmdpbmcga2V5 cyB3aGlsZSBtYWludGFpbmluZyBwcm90b2NvbAogICAgICBvcGVyYXRpb24gY29udmVuaWVudC4g IEVhY2ggU0EgSUQgc3BlY2lmaWVzIHR3byBpbmRlcGVuZGVudCBwYXJ0cywKICAgICAgdGhlIGF1 dGhlbnRpY2F0aW9uIGFsZ29yaXRobSBhbmQgdGhlIGF1dGhlbnRpY2F0aW9uIGtleSwgYXMKICAg ICAgZXhwbGFpbmVkIGJlbG93LgoKICAgICAgTm9ybWFsbHksIGFuIGltcGxlbWVudGF0aW9uIHdv dWxkIGFsbG93IHRoZSBuZXR3b3JrIG9wZXJhdG9yIHRvCiAgICAgIGNvbmZpZ3VyZSBhIHNldCBv ZiBrZXlzIGluIGEga2V5IGNoYWluLCB3aXRoIGVhY2gga2V5IGluIHRoZSBjaGFpbgogICAgICBo YXZpbmcgZml4ZWQgbGlmZXRpbWUuICBUaGUgYWN0dWFsIG9wZXJhdGlvbiBvZiB0aGVzZSBtZWNo YW5pc21zCiAgICAgIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuCgogICAg ICBOb3RlIHRoYXQgZWFjaCBTQSBJRCBjYW4gaW5kaWNhdGUgYSBrZXkgd2l0aCBhIGRpZmZlcmVu dAogICAgICBhdXRoZW50aWNhdGlvbiBhbGdvcml0aG0uICBUaGlzIGFsbG93cyB0aGUgaW50cm9k dWN0aW9uIG9mIG5ldwogICAgICBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc21zIHdpdGhvdXQgZGlz cnVwdGluZyBleGlzdGluZyBMRFAKICAgICAgc2Vzc2lvbnMuCgogICBvICBBdXRoZW50aWNhdGlv biBBbGdvcml0aG0KCiAgICAgIFRoaXMgc2lnbmlmaWVzIHRoZSBhdXRoZW50aWNhdGlvbiBhbGdv cml0aG0gdG8gYmUgdXNlZCB3aXRoIHRoZQogICAgICBMRFAgU0EuICBUaGlzIGluZm9ybWF0aW9u IGlzIG5ldmVyIHNlbnQgaW4gY2xlYXIgdGV4dCBvdmVyIHRoZQogICAgICB3aXJlLiAgQmVjYXVz ZSB0aGlzIGluZm9ybWF0aW9uIGlzIG5vdCBzZW50IG9uIHRoZSB3aXJlLCB0aGUKICAgICAgaW1w bGVtZW50ZXIgY2hvb3NlcyBhbiBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYyByZXByZXNlbnRhdGlv biBmb3IKICAgICAgdGhpcyBpbmZvcm1hdGlvbi4KCiAgICAgIEN1cnJlbnRseSwgdGhlIGZvbGxv d2luZyBhbGdvcml0aG1zIGFyZSBzdXBwb3J0ZWQ6CgogICAgICBITUFDLVNIQS0xLCBITUFDLVNI QS0yNTYsIEhNQUMtU0hBLTM4NCwgYW5kIEhNQUMtU0hBLTUxMi4KCiAgIG8gIEF1dGhlbnRpY2F0 aW9uIEtleQoKICAgICAgVGhpcyB2YWx1ZSBkZW5vdGVzIHRoZSBjcnlwdG9ncmFwaGljIGF1dGhl bnRpY2F0aW9uIGtleSBhc3NvY2lhdGVkCiAgICAgIHdpdGggdGhlIExEUCBTQS4gIFRoZSBsZW5n dGggb2YgdGhpcyBrZXkgaXMgdmFyaWFibGUgYW5kIGRlcGVuZHMKICAgICAgdXBvbiB0aGUgYXV0 aGVudGljYXRpb24gYWxnb3JpdGhtIHNwZWNpZmllZCBieSB0aGUgTERQIFNBLgoKICAgbyAgS2V5 U3RhcnRBY2NlcHQKCiAgICAgIFRoZSB0aW1lIHRoYXQgdGhpcyBMRFAgcm91dGVyIHdpbGwgYWNj ZXB0IHBhY2tldHMgdGhhdCBoYXZlIGJlZW4KICAgICAgY3JlYXRlZCB3aXRoIHRoaXMgTERQIFNl Y3VyaXR5IEFzc29jaWF0aW9uLgoKICAgbyAgS2V5U3RhcnRHZW5lcmF0ZQoKICAgICAgVGhlIHRp bWUgdGhhdCB0aGlzIExEUCByb3V0ZXIgd2lsbCBiZWdpbiB1c2luZyB0aGlzIExEUCBTZWN1cml0 eQogICAgICBBc3NvY2lhdGlvbiBmb3IgTERQIEhlbGxvIG1lc3NhZ2UgZ2VuZXJhdGlvbi4KCiAg IG8gIEtleVN0b3BHZW5lcmF0ZQoKCgoKWmhlbmcsIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBO b3ZlbWJlciAyMiwgMjAxNCAgICAgICAgICAgICAgIFtQYWdlIDVdCgwKSW50ZXJuZXQtRHJhZnQg ICBMRFAgSGVsbG8gQ3J5cHRvZ3JhcGhpYyBBdXRoZW50aWNhdGlvbiAgICAgICAgIE1heSAyMDE0 CgoKICAgICAgVGhlIHRpbWUgdGhhdCB0aGlzIExEUCByb3V0ZXIgd2lsbCBzdG9wIHVzaW5nIHRo aXMgTERQIFNlY3VyaXR5CiAgICAgIEFzc29jaWF0aW9uIGZvciBMRFAgSGVsbG8gbWVzc2FnZSBn ZW5lcmF0aW9uLgoKICAgbyAgS2V5U3RvcEFjY2VwdAoKICAgICAgVGhlIHRpbWUgdGhhdCB0aGlz IExEUCByb3V0ZXIgd2lsbCBzdG9wIGFjY2VwdGluZyBwYWNrZXRzCiAgICAgIGdlbmVyYXRlZCB3 aXRoIHRoaXMgTERQIFNlY3VyaXR5IEFzc29jaWF0aW9uLgoKICAgSW4gb3JkZXIgdG8gYWNoaWV2 ZSBzbW9vdGgga2V5IHRyYW5zaXRpb24sIEtleVN0YXJ0QWNjZXB0IFNIT1VMRCBiZQogICBsZXNz IHRoYW4gS2V5U3RhcnRHZW5lcmF0ZSBhbmQgS2V5U3RvcEdlbmVyYXRlIFNIT1VMRCBiZSBsZXNz IHRoYW4KICAgS2V5U3RvcEFjY2VwdC4gIElmIEtleVN0YXJ0R2VuZXJhdGUgb3IgS2V5U3RhcnRB Y2NlcHQgYXJlIGxlZnQKICAgdW5zcGVjaWZpZWQsIHRoZSB0aW1lIHdpbGwgZGVmYXVsdCB0byAw IGFuZCB0aGUga2V5IHdpbGwgYmUgdXNlZAogICBpbW1lZGlhdGVseS4gIElmIEtleVN0b3BHZW5l cmF0ZSBvciBLZXlTdG9wQWNjZXB0IGFyZSBsZWZ0CiAgIHVuc3BlY2lmaWVkLCB0aGUgdGltZSB3 aWxsIGRlZmF1bHQgdG8gaW5maW5pdHkgYW5kIHRoZSBrZXkncyBsaWZldGltZQogICB3aWxsIGJl IGluZmluaXRlLiAgV2hlbiBhIG5ldyBrZXkgcmVwbGFjZXMgYW4gb2xkLCB0aGUKICAgS2V5U3Rh cnRHZW5lcmF0ZSB0aW1lIGZvciB0aGUgbmV3IGtleSBNVVNUIGJlIGxlc3MgdGhhbiBvciBlcXVh bCB0bwogICB0aGUgS2V5U3RvcEdlbmVyYXRlIHRpbWUgb2YgdGhlIG9sZCBrZXkuICBBbnkgdW5z cGVjaWZpZWQgdmFsdWVzIGFyZQogICBlbmNvZGVkIGFzIFplcm8uCgogICBLZXkgc3RvcmFnZSBT SE9VTEQgcGVyc2lzdCBhY3Jvc3MgYSBzeXN0ZW0gcmVzdGFydCwgd2FybSBvciBjb2xkLCB0bwog ICBhdm9pZCBvcGVyYXRpb25hbCBpc3N1ZXMuICBJbiB0aGUgZXZlbnQgdGhhdCB0aGUgbGFzdCBr ZXkgYXNzb2NpYXRlZAogICB3aXRoIGFuIGludGVyZmFjZSBleHBpcmVzLCBpdCBpcyB1bmFjY2Vw dGFibGUgdG8gcmV2ZXJ0IHRvIGFuCiAgIHVuYXV0aGVudGljYXRlZCBjb25kaXRpb24sIGFuZCBu b3QgYWR2aXNhYmxlIHRvIGRpc3J1cHQgcm91dGluZy4KICAgVGhlcmVmb3JlLCB0aGUgcm91dGVy IFNIT1VMRCBzZW5kIGEgImxhc3QgQXV0aGVudGljYXRpb24gS2V5CiAgIGV4cGlyYXRpb24iIG5v dGlmaWNhdGlvbiB0byB0aGUgbmV0d29yayBtYW5hZ2VyIGFuZCB0cmVhdCB0aGUga2V5IGFzCiAg IGhhdmluZyBhbiBpbmZpbml0ZSBsaWZldGltZSB1bnRpbCB0aGUgbGlmZXRpbWUgaXMgZXh0ZW5k ZWQsIHRoZSBrZXkKICAgaXMgZGVsZXRlZCBieSBuZXR3b3JrIG1hbmFnZW1lbnQsIG9yIGEgbmV3 IGtleSBpcyBjb25maWd1cmVkCgoyLjMuICBDcnlwdG9ncmFwaGljIEF1dGhlbnRpY2F0aW9uIFRM ViBFbmNvZGluZwoKICAgICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAg ICAyICAgICAgICAgICAgICAgICAgIDMKICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIg MyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQogICAgICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAg ICB8MHwwfCAgICAgICAgQXV0aCAoVEJEMSkgICAgICAgIHwgICAgICAgICAgICAgTGVuZ3RoICAg ICAgICAgICAgfAogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgICB8ICAgICAgICAgICAgICAgICAgU2VjdXJp dHkgQXNzb2NpYXRpb24gSUQgICAgICAgICAgICAgICAgICAgICAgfAogICAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwog ICAgICB8ICAgICAgIENyeXB0b2dyYXBoaWMgU2VxdWVuY2UgTnVtYmVyIChIaWdoIE9yZGVyIDMy IEJpdHMpICAgICAgfAogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgICB8ICAgICAgIENyeXB0b2dyYXBoaWMg U2VxdWVuY2UgTnVtYmVyIChMb3cgT3JkZXIgMzIgQml0cykgICAgICAgfAogICAgICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst KwogICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfAogICAgICB8ICAgICAgICAgICAgICAgIEF1dGhlbnRpY2F0aW9uIERh dGEgKFZhcmlhYmxlKSAgICAgICAgICAgICAgICAgfAogICAgICB+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfgogICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfAogICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfAogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwoKCgoKWmhlbmcsIGV0IGFsLiAgICAg ICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMiwgMjAxNCAgICAgICAgICAgICAgIFtQYWdlIDZdCgwK SW50ZXJuZXQtRHJhZnQgICBMRFAgSGVsbG8gQ3J5cHRvZ3JhcGhpYyBBdXRoZW50aWNhdGlvbiAg ICAgICAgIE1heSAyMDE0CgoKICAgLSBUeXBlOiBUQkQxLCBDcnlwdG9ncmFwaGljIEF1dGhlbnRp Y2F0aW9uCgogICAtIExlbmd0aDogU3BlY2lmeWluZyB0aGUgbGVuZ3RoIGluIG9jdGV0cyBvZiB0 aGUgdmFsdWUgZmllbGQuCgogICAtIFNlY3VyaXR5IEFzc29jaWF0aW9uIElEOiAzMiBiaXQgZmll bGQgdGhhdCBtYXBzIHRvIHRoZQogICBhdXRoZW50aWNhdGlvbiBhbGdvcml0aG0gYW5kIHRoZSBz ZWNyZXQga2V5IHVzZWQgdG8gY3JlYXRlIHRoZQogICBtZXNzYWdlIGRpZ2VzdCBjYXJyaWVkIGlu IExEUCBwYXlsb2FkLgoKICAgVGhvdWdoIHRoZSBTQSBJRCBpbXBsaWVzIHRoZSBhbGdvcml0aG0s IHRoZSBITUFDIG91dHB1dCBzaXplIHNob3VsZAogICBub3QgYmUgdXNlZCBieSBpbXBsZW1lbnRl cnMgYXMgYW4gaW1wbGljaXQgaGludCwgYmVjYXVzZSBhZGRpdGlvbmFsCiAgIGFsZ29yaXRobXMg bWF5IGJlIGRlZmluZWQgaW4gdGhlIGZ1dHVyZSB0aGF0IGhhdmUgdGhlIHNhbWUgb3V0cHV0CiAg IHNpemUuCgogICAtIENyeXB0b2dyYXBoaWMgU2VxdWVuY2UgTnVtYmVyOiA2NC1iaXQgc3RyaWN0 bHkgaW5jcmVhc2luZyBzZXF1ZW5jZQogICBudW1iZXIgdGhhdCBpcyB1c2VkIHRvIGd1YXJkIGFn YWluc3QgcmVwbGF5IGF0dGFja3MuICBUaGUgNjQtYml0CiAgIHNlcXVlbmNlIG51bWJlciBNVVNU IGJlIGluY3JlbWVudGVkIGZvciBldmVyeSBMRFAgSGVsbG8gcGFja2V0IHNlbnQKICAgYnkgdGhl IExEUCByb3V0ZXIuICBVcG9uIHJlY2VwdGlvbiwgdGhlIHNlcXVlbmNlIG51bWJlciBNVVNUIGJl CiAgIGdyZWF0ZXIgdGhhbiB0aGUgc2VxdWVuY2UgbnVtYmVyIGluIHRoZSBsYXN0IExEUCBIZWxs byBwYWNrZXQKICAgYWNjZXB0ZWQgZnJvbSB0aGUgc2VuZGluZyBMRFAgbmVpZ2hib3IuICBPdGhl cndpc2UsIHRoZSBMRFAgcGFja2V0IGlzCiAgIGNvbnNpZGVyZWQgYSByZXBsYXllZCBwYWNrZXQg YW5kIGRyb3BwZWQuCgogICBMRFAgcm91dGVycyBpbXBsZW1lbnRpbmcgdGhpcyBzcGVjaWZpY2F0 aW9uIE1VU1QgdXNlIGV4aXN0aW5nCiAgIG1lY2hhbmlzbXMgdG8gcHJlc2VydmUgdGhlIHNlcXVl bmNlIG51bWJlcidzIHN0cmljdGx5IGluY3JlYXNpbmcKICAgcHJvcGVydHkgZm9yIHRoZSBkZXBs b3llZCBsaWZlIG9mIHRoZSBMRFAgcm91dGVyIChpbmNsdWRpbmcgY29sZAogICByZXN0YXJ0cyku ICBPbmUgbWVjaGFuaXNtIGZvciBhY2NvbXBsaXNoaW5nIHRoaXMgY291bGQgYmUgdG8gdXNlIHRo ZQogICBoaWdoLW9yZGVyIDMyIGJpdHMgb2YgdGhlIHNlcXVlbmNlIG51bWJlciBhcyBhIGJvb3Qg Y291bnQgdGhhdCBpcwogICBpbmNyZW1lbnRlZCBhbnl0aW1lIHRoZSBMRFAgcm91dGVyIGxvc2Vz IGl0cyBzZXF1ZW5jZSBudW1iZXIgc3RhdGUuCiAgIFRlY2huaXF1ZXMgc3VjaCBhcyBzZXF1ZW5j ZSBudW1iZXIgc3BhY2UgcGFydGl0aW9uaW5nIGRlc2NyaWJlZCBhYm92ZQogICBvciBub24tdm9s YXRpbGUgc3RvcmFnZSBwcmVzZXJ2YXRpb24gY2FuIGJlIHVzZWQgYnV0IGFyZSBiZXlvbmQgdGhl CiAgIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4gIFNlcXVlbmNlIG51bWJlciB3cmFwIGlz IGRlc2NyaWJlZCBpbgogICBTZWN0aW9uIDIuNC4KCiAgIC0gQXV0aGVudGljYXRpb24gRGF0YToK CiAgIFRoaXMgZmllbGQgY2FycmllcyB0aGUgZGlnZXN0IGNvbXB1dGVkIGJ5IHRoZSBDcnlwdG9n cmFwaGljCiAgIEF1dGhlbnRpY2F0aW9uIGFsZ29yaXRobSBpbiB1c2UuICBUaGUgbGVuZ3RoIG9m IHRoZSBBdXRoZW50aWNhdGlvbgogICBEYXRhIHZhcmllcyBiYXNlZCBvbiB0aGUgY3J5cHRvZ3Jh cGhpYyBhbGdvcml0aG0gaW4gdXNlLCB3aGljaCBpcwogICBzaG93biBhcyBiZWxvdzoKCiAgIEF1 dGggdHlwZSAgICAgICAgTGVuZ3RoCiAgIC0tLS0tLS0tLS0tLS0tLSAgLS0tLS0tLS0tLQogICBI TUFDLVNIQTEgICAgICAgIDIwIGJ5dGVzCiAgIEhNQUMtU0hBLTI1NiAgICAgMzIgYnl0ZXMKICAg SE1BQy1TSEEtMzg0ICAgICA0OCBieXRlcwogICBITUFDLVNIQS01MTIgICAgIDY0IGJ5dGVzCgoK CgoKClpoZW5nLCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMjIsIDIwMTQgICAg ICAgICAgICAgICBbUGFnZSA3XQoMCkludGVybmV0LURyYWZ0ICAgTERQIEhlbGxvIENyeXB0b2dy YXBoaWMgQXV0aGVudGljYXRpb24gICAgICAgICBNYXkgMjAxNAoKCjIuNC4gIFNlcXVlbmNlIE51 bWJlciBXcmFwCgogICBXaGVuIGluY3JlbWVudGluZyB0aGUgc2VxdWVuY2UgbnVtYmVyIGZvciBl YWNoIHRyYW5zbWl0dGVkIExEUAogICBwYWNrZXQsIHRoZSBzZXF1ZW5jZSBudW1iZXIgc2hvdWxk IGJlIHRyZWF0ZWQgYXMgYW4gdW5zaWduZWQgNjQtYml0CiAgIHZhbHVlLiAgSWYgdGhlIGxvd2Vy IG9yZGVyIDMyLWJpdCB2YWx1ZSB3cmFwcywgdGhlIGhpZ2hlciBvcmRlcgogICAzMi1iaXQgdmFs dWUgc2hvdWxkIGJlIGluY3JlbWVudGVkIGFuZCBzYXZlZCBpbiBub24tdm9sYXRpbGUgc3RvcmFn ZS4KICAgSWYgdGhlIExEUCByb3V0ZXIgaXMgZGVwbG95ZWQgbG9uZyBlbm91Z2ggdGhhdCB0aGUg NjQtYml0IHNlcXVlbmNlCiAgIG51bWJlciB3cmFwcywgYWxsIGtleXMsIGluZGVwZW5kZW50IG9m IGtleSBkaXN0cmlidXRpb24gbWVjaGFuaXNtCiAgIE1VU1QgYmUgcmVzZXQuICBUaGlzIGlzIGRv bmUgdG8gYXZvaWQgdGhlIHBvc3NpYmlsaXR5IG9mIHJlcGxheQogICBhdHRhY2tzLiAgT25jZSB0 aGUga2V5cyBoYXZlIGJlZW4gY2hhbmdlZCwgdGhlIGhpZ2hlciBvcmRlciBzZXF1ZW5jZQogICBu dW1iZXIgY2FuIGJlIHJlc2V0IHRvIDAgYW5kIHNhdmVkIHRvIG5vbi12b2xhdGlsZSBzdG9yYWdl LgoKMy4gIENyeXB0b2dyYXBoaWMgQXV0aGVudGljYXRpb24gUHJvY2VkdXJlCgogICBBcyBub3Rl ZCBlYXJsaWVyLCB0aGUgU2VjdXJpdHkgQXNzb2NpYXRpb24gSUQgbWFwcyB0byB0aGUKICAgYXV0 aGVudGljYXRpb24gYWxnb3JpdGhtIGFuZCB0aGUgc2VjcmV0IGtleSB1c2VkIHRvIGdlbmVyYXRl IGFuZAogICB2ZXJpZnkgdGhlIG1lc3NhZ2UgZGlnZXN0LiAgVGhpcyBzcGVjaWZpY2F0aW9uIGRp c2N1c3NlcyB0aGUKICAgY29tcHV0YXRpb24gb2YgTERQIENyeXB0b2dyYXBoaWMgQXV0aGVudGlj YXRpb24gZGF0YSB3aGVuIGFueSBvZiB0aGUKICAgTklTVCBTSFMgZmFtaWx5IG9mIGFsZ29yaXRo bXMgaXMgdXNlZCBpbiB0aGUgSGFzaGVkIE1lc3NhZ2UKICAgQXV0aGVudGljYXRpb24gQ29kZSAo SE1BQykgbW9kZS4KCiAgIFRoZSBjdXJyZW50bHkgdmFsaWQgYWxnb3JpdGhtcyAoaW5jbHVkaW5n IG1vZGUpIGZvciBMRFAgQ3J5cHRvZ3JhcGhpYwogICBBdXRoZW50aWNhdGlvbiBpbmNsdWRlOgoK ICAgSE1BQy1TSEEtMSwgSE1BQy1TSEEtMjU2LCBITUFDLVNIQS0zODQgYW5kIEhNQUMtU0hBLTUx MgoKICAgT2YgdGhlIGFib3ZlLCBpbXBsZW1lbnRhdGlvbnMgb2YgdGhpcyBzcGVjaWZpY2F0aW9u IE1VU1QgaW5jbHVkZQogICBzdXBwb3J0IGZvciBhdCBsZWFzdCBITUFDLVNIQS0yNTYgYW5kIFNI T1VMRCBpbmNsdWRlIHN1cHBvcnQgZm9yCiAgIEhNQUMtU0hBLTEgYW5kIE1BWSBhbHNvIGluY2x1 ZGUgc3VwcG9ydCBmb3IgSE1BQy1TSEEtMzg0IGFuZCBITUFDLQogICBTSEEtNTEyLgoKICAgSW1w bGVtZW50YXRpb25zIG9mIHRoaXMgc3RhbmRhcmQgTVVTVCB1c2UgSE1BQy1TSEEtMjU2IGFzIHRo ZSBkZWZhdWx0CiAgIGF1dGhlbnRpY2F0aW9uIGFsZ29yaXRobS4KCjQuICBDcm9zcyBQcm90b2Nv bCBBdHRhY2sgTWl0aWdhdGlvbgoKICAgSW4gb3JkZXIgdG8gcHJldmVudCBjcm9zcyBwcm90b2Nv bCByZXBsYXkgYXR0YWNrcyBmb3IgcHJvdG9jb2xzCiAgIHNoYXJpbmcgY29tbW9uIGtleXMsIHRo ZSB0d28gb2N0ZXQgTERQIENyeXB0b2dyYXBoaWMgUHJvdG9jb2wgSUQgaXMKICAgYXBwZW5kZWQg dG8gdGhlIGF1dGhlbnRpY2F0aW9uIGtleSBwcmlvciB0byB1c2UgKHJlZmVyIHRvIFNlY3Rpb24g OCkuCiAgIE90aGVyIHByb3RvY29scyB1c2luZyB0aGUgY29tbW9uIGtleSBzaW1pbGFybHkgYXBw ZW5kIHRoZWlyIG93bgogICBDcnlwdG9ncmFwaGljIFByb3RvY29sIElEcyB0byB0aGVpciBrZXlz IHByaW9yIHRvIHVzZSB0aHVzIGVuc3VyaW5nCiAgIHRoYXQgYSBkaWZmZXJlbnQga2V5IHZhbHVl IGlzIHVzZWQgZm9yIGVhY2ggcHJvdG9jb2wuCgo1LiAgQ3J5cHRvZ3JhcGhpYyBBc3BlY3RzCgog ICBJbiB0aGUgYWxnb3JpdGhtIGRlc2NyaXB0aW9uIGJlbG93LCB0aGUgZm9sbG93aW5nIG5vbWVu Y2xhdHVyZSBpcwogICB1c2VkOgoKCgoKWmhlbmcsIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBO b3ZlbWJlciAyMiwgMjAxNCAgICAgICAgICAgICAgIFtQYWdlIDhdCgwKSW50ZXJuZXQtRHJhZnQg ICBMRFAgSGVsbG8gQ3J5cHRvZ3JhcGhpYyBBdXRoZW50aWNhdGlvbiAgICAgICAgIE1heSAyMDE0 CgoKICAgSCBpcyB0aGUgc3BlY2lmaWMgaGFzaGluZyBhbGdvcml0aG0gKGUuZy4gIFNIQS0yNTYp LgoKICAgSyBpcyB0aGUgQXV0aGVudGljYXRpb24gS2V5IGZyb20gdGhlIExEUCBzZWN1cml0eSBh c3NvY2lhdGlvbi4KCiAgIEtzIGlzIGEgUHJvdG9jb2wgU3BlY2lmaWMgQXV0aGVudGljYXRpb24g S2V5IG9idGFpbmVkIGJ5IGFwcGVuZGluZwogICBBdXRoZW50aWNhdGlvbiBLZXkgKEspIHdpdGgg dGhlIHR3by1vY3RldCBMRFAgQ3J5cHRvZ3JhcGhpYyBQcm90b2NvbAogICBJRCAuCgogICBLbyBp cyB0aGUgY3J5cHRvZ3JhcGhpYyBrZXkgdXNlZCB3aXRoIHRoZSBoYXNoIGFsZ29yaXRobS4KCiAg IEwgaXMgdGhlIGxlbmd0aCBvZiB0aGUgaGFzaCwgbWVhc3VyZWQgaW4gb2N0ZXRzIHJhdGhlciB0 aGFuIGJpdHMuCgogICBBdXRoVGFnIGlzIGEgdmFsdWUgd2hpY2ggaXMgdGhlIHNhbWUgbGVuZ3Ro IGFzIHRoZSBoYXNoIG91dHB1dC4gIEluCiAgIGNhc2Ugb2YgSVB2NCwgdGhlIGZpcnN0IDQgb2N0 ZXRzIGNvbnRhaW4gdGhlIElQdjQgc291cmNlIGFkZHJlc3MKICAgZm9sbG93ZWQgYnkgdGhlIGhl eGFkZWNpbWFsIHZhbHVlIDB4ODc4RkUxRjMgcmVwZWF0ZWQgKEwtNCkvNCB0aW1lcy4KICAgSW4g Y2FzZSBvZiBJUHY2LCB0aGUgZmlyc3QgMTYgb2N0ZXRzIGNvbnRhaW4gdGhlIElQdjYgc291cmNl IGFkZHJlc3MKICAgZm9sbG93ZWQgYnkgdGhlIGhleGFkZWNpbWFsIHZhbHVlIDB4ODc4RkUxRjMg cmVwZWF0ZWQgKEwtMTYpLzQgdGltZXMuCiAgIFRoaXMgaW1wbGllcyB0aGF0IGhhc2ggb3V0cHV0 IGlzIGFsd2F5cyBhIGxlbmd0aCBvZiBhdCBsZWFzdCAxNgogICBvY3RldHMuCgoKNS4xLiAgUHJl cGFyaW5nIHRoZSBDcnlwdG9ncmFwaGljIEtleQoKICAgVGhlIExEUCBDcnlwdG9ncmFwaGljIFBy b3RvY29sIElEIGlzIGFwcGVuZGVkIHRvIHRoZSBBdXRoZW50aWNhdGlvbgogICBLZXkgKEspIHlp ZWxkaW5nIGEgUHJvdG9jb2wgU3BlY2lmaWMgQXV0aGVudGljYXRpb24gS2V5IChLcykuICBJbgog ICB0aGlzIGFwcGxpY2F0aW9uLCBLbyBpcyBhbHdheXMgTCBvY3RldHMgbG9uZy4gIEtleXMgdGhh dCBhcmUgbG9uZ2VyCiAgIHRoYW4gdGhlIGJpdCBsZW5ndGggb2YgdGhlIGhhc2ggZnVuY3Rpb24g YXJlIGhhc2hlZCB0byBmb3JjZSB0aGVtIHRvCiAgIHRoaXMgbGVuZ3RoLCBhcyB3ZSBkZXNjcmli ZSBiZWxvdy4gIEtzIGlzIGNvbXB1dGVkIGFzIGZvbGxvd3M6CgogICBJZiB0aGUgUHJvdG9jb2wg U3BlY2lmaWMgQXV0aGVudGljYXRpb24gS2V5IChLcykgaXMgTCBvY3RldHMgbG9uZywKICAgdGhl biBLbyBpcyBlcXVhbCB0byBLcy4gIElmIHRoZSBQcm90b2NvbCBTcGVjaWZpYyBBdXRoZW50aWNh dGlvbiBLZXkKICAgKEtzKSBpcyBtb3JlIHRoYW4gTCBvY3RldHMgbG9uZywgdGhlbiBLbyBpcyBz ZXQgdG8gSChLcykuICBJZiB0aGUKICAgUHJvdG9jb2wgU3BlY2lmaWMgQXV0aGVudGljYXRpb24g S2V5IChLcykgaXMgbGVzcyB0aGFuIEwgb2N0ZXRzIGxvbmcsCiAgIHRoZW4gS28gaXMgc2V0IHRv IHRoZSBQcm90b2NvbCBTcGVjaWZpYyBBdXRoZW50aWNhdGlvbiBLZXkgKEtzKSB3aXRoCiAgIHpl cm9zIGFwcGVuZGVkIHRvIHRoZSBlbmQgb2YgdGhlIFByb3RvY29sIFNwZWNpZmljIEF1dGhlbnRp Y2F0aW9uIEtleQogICAoS3MpIHN1Y2ggdGhhdCBLbyBpcyBMIG9jdGV0cyBsb25nLgoKICAgRm9y IGhpZ2hlciBlbnRyb3B5IGl0IGlzIFJFQ09NTUVOREVEIHRoYXQgS2V5IEtzIHNob3VsZCBiZSBh dCBsZWFzdCBMCiAgIG9jdGV0cyBsb25nLgoKNS4yLiAgQ29tcHV0aW5nIHRoZSBIYXNoCgogICBG aXJzdCwgdGhlIEF1dGhlbnRpY2F0aW9uIERhdGEgZmllbGQgaW4gdGhlIENyeXB0b2dyYXBoaWMK ICAgQXV0aGVudGljYXRpb24gVExWIGlzIGZpbGxlZCB3aXRoIHRoZSB2YWx1ZSBBdXRoVGFnLiAg VGhlbiwgdG8KICAgY29tcHV0ZSBITUFDIG92ZXIgdGhlIEhlbGxvIG1lc3NhZ2UgaXQgcGVyZm9y bXM6CgogICBBdXRoRGF0YSA9IEhNQUMoS28sIEhlbGxvIE1lc3NhZ2UpCgoKCgpaaGVuZywgZXQg YWwuICAgICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDIyLCAyMDE0ICAgICAgICAgICAgICAgW1Bh Z2UgOV0KDApJbnRlcm5ldC1EcmFmdCAgIExEUCBIZWxsbyBDcnlwdG9ncmFwaGljIEF1dGhlbnRp Y2F0aW9uICAgICAgICAgTWF5IDIwMTQKCgogICBIZWxsbyBNZXNzYWdlIHJlZmVycyB0byB0aGUg TERQIEhlbGxvIG1lc3NhZ2UgZXhjbHVkaW5nIHRoZSBJUCBhbmQKICAgdGhlIFVEUCBoZWFkZXJz LgoKNS4zLiAgUmVzdWx0CgogICBUaGUgcmVzdWx0YW50IEhhc2ggYmVjb21lcyB0aGUgQXV0aGVu dGljYXRpb24gRGF0YSB0aGF0IGlzIHNlbnQgaW4KICAgdGhlIEF1dGhlbnRpY2F0aW9uIERhdGEg ZmllbGQgb2YgdGhlIENyeXB0b2dyYXBoaWMgQXV0aGVudGljYXRpb24KICAgVExWLiAgVGhlIGxl bmd0aCBvZiB0aGUgQXV0aGVudGljYXRpb24gRGF0YSBmaWVsZCBpcyBhbHdheXMgaWRlbnRpY2Fs CiAgIHRvIHRoZSBtZXNzYWdlIGRpZ2VzdCBzaXplIG9mIHRoZSBzcGVjaWZpYyBoYXNoIGZ1bmN0 aW9uIEggdGhhdCBpcwogICBiZWluZyB1c2VkLgoKICAgVGhpcyBhbHNvIG1lYW5zIHRoYXQgdGhl IHVzZSBvZiBoYXNoIGZ1bmN0aW9ucyB3aXRoIGxhcmdlciBvdXRwdXQKICAgc2l6ZXMgd2lsbCBh bHNvIGluY3JlYXNlIHRoZSBzaXplIG9mIHRoZSBMRFAgbWVzc2FnZSBhcyB0cmFuc21pdHRlZAog ICBvbiB0aGUgd2lyZS4KCjYuICBQcm9jZXNzaW5nIEhlbGxvIE1lc3NhZ2UgVXNpbmcgQ3J5cHRv Z3JhcGhpYyBBdXRoZW50aWNhdGlvbgoKNi4xLiAgVHJhbnNtaXNzaW9uIFVzaW5nIENyeXB0b2dy YXBoaWMgQXV0aGVudGljYXRpb24KCiAgIFByaW9yIHRvIHRyYW5zbWl0dGluZyB0aGUgSGVsbG8g bWVzc2FnZSwgdGhlIExlbmd0aCBpbiB0aGUKICAgQ3J5cHRvZ3JhcGhpYyBBdXRoZW50aWNhdGlv biBUTFYgaGVhZGVyIGlzIHNldCBhcyBwZXIgdGhlCiAgIGF1dGhlbnRpY2F0aW9uIGFsZ29yaXRo bSB0aGF0IGlzIGJlaW5nIHVzZWQuICBJdCBpcyBzZXQgdG8gMjQgZm9yCiAgIEhNQUMtU0hBLTEs IDM2IGZvciBITUFDLVNIQS0yNTYsIDUyIGZvciBITUFDLVNIQS0zODQgYW5kIDY4IGZvciBITUFD LQogICBTSEEtNTEyLgoKICAgVGhlIFNlY3VyaXR5IEFzc29jaWF0aW9uIElEIGZpZWxkIGlzIHNl dCB0byB0aGUgSUQgb2YgdGhlIGN1cnJlbnQKICAgYXV0aGVudGljYXRpb24ga2V5LiAgVGhlIEhN QUMgSGFzaCBpcyBjb21wdXRlZCBhcyBleHBsYWluZWQgaW4KICAgU2VjdGlvbiAzLiAgVGhlIHJl c3VsdGluZyBIYXNoIGlzIHN0b3JlZCBpbiB0aGUgQXV0aGVudGljYXRpb24gRGF0YQogICBmaWVs ZCBwcmlvciB0byB0cmFuc21pc3Npb24uICBUaGUgYXV0aGVudGljYXRpb24ga2V5IE1VU1QgTk9U IGJlCiAgIGNhcnJpZWQgaW4gdGhlIHBhY2tldC4KCjYuMi4gIFJlY2VpcHQgVXNpbmcgQ3J5cHRv Z3JhcGhpYyBBdXRoZW50aWNhdGlvbgoKICAgVGhlIHJlY2VpdmluZyBMU1IgYXBwbGllcyBhY2Nl cHRhYmlsaXR5IGNyaXRlcmlhIGZvciByZWNlaXZlZCBIZWxsb3MKICAgdXNpbmcgY3J5cHRvZ3Jh cGhpYyBhdXRoZW50aWNhdGlvbi4gIElmIHRoZSBDcnlwdG9ncmFwaGljCiAgIEF1dGhlbnRpY2F0 aW9uIFRMViBpcyB1bmtub3duIHRvIHRoZSByZWNlaXZpbmcgTFNSLCB0aGUgcmVjZWl2ZWQKICAg cGFja2V0IE1VU1QgYmUgZGlzY2FyZGVkIGFjY29yZGluZyB0byBTZWN0aW9uIDMuNS4xLjIuMiBv ZiBbUkZDNTAzNl0uCgogICBUaGUgcmVjZWl2aW5nIExTUiBsb2NhdGVzIHRoZSBMRFAgU0EgdXNp bmcgdGhlIFNlY3VyaXR5IEFzc29jaWF0aW9uCiAgIElEIGZpZWxkIGNhcnJpZWQgaW4gdGhlIG1l c3NhZ2UuICBJZiB0aGUgU0EgaXMgbm90IGZvdW5kLCBvciBpZiB0aGUKICAgU0EgaXMgbm90IHZh bGlkIGZvciByZWNlcHRpb24gKGkuZS4sIGN1cnJlbnQgdGltZSA8IEtleVN0YXJ0QWNjZXB0IG9y CiAgIGN1cnJlbnQgdGltZSA+PSBLZXlTdG9wQWNjZXB0KSwgTERQIEhlbGxvIG1lc3NhZ2UgTVVT VCBiZSBkaXNjYXJkZWQsCiAgIGFuZCBhbiBlcnJvciBldmVudCBTSE9VTEQgYmUgbG9nZ2VkLgoK ICAgSWYgdGhlIGNyeXB0b2dyYXBoaWMgc2VxdWVuY2UgbnVtYmVyIGluIHRoZSBMRFAgcGFja2V0 IGlzIGxlc3MgdGhhbgogICBvciBlcXVhbCB0byB0aGUgbGFzdCBzZXF1ZW5jZSBudW1iZXIgcmVj ZWl2ZWQgZnJvbSB0aGUgc2FtZSBuZWlnaGJvciwKICAgdGhlIExEUCBtZXNzYWdlIE1VU1QgYmUg ZGlzY2FyZGVkLCBhbmQgYW4gZXJyb3IgZXZlbnQgU0hPVUxEIGJlCiAgIGxvZ2dlZC4KCgoKWmhl bmcsIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMiwgMjAxNCAgICAgICAgICAg ICAgW1BhZ2UgMTBdCgwKSW50ZXJuZXQtRHJhZnQgICBMRFAgSGVsbG8gQ3J5cHRvZ3JhcGhpYyBB dXRoZW50aWNhdGlvbiAgICAgICAgIE1heSAyMDE0CgoKICAgQmVmb3JlIHRoZSByZWNlaXZpbmcg TFNSIHBlcmZvcm1zIGFueSBwcm9jZXNzaW5nLCBpdCBuZWVkcyB0byBzYXZlCiAgIHRoZSB2YWx1 ZXMgb2YgdGhlIEF1dGhlbnRpY2F0aW9uIERhdGEgZmllbGQuICBUaGUgcmVjZWl2aW5nIExTUiB0 aGVuCiAgIHJlcGxhY2VzIHRoZSBjb250ZW50cyBvZiB0aGUgQXV0aGVudGljYXRpb24gRGF0YSBm aWVsZCB3aXRoIEF1dGhUYWcsCiAgIGNvbXB1dGVzIHRoZSBIYXNoLCB1c2luZyB0aGUgYXV0aGVu dGljYXRpb24ga2V5IHNwZWNpZmllZCBieSB0aGUKICAgcmVjZWl2ZWQgU2VjdXJpdHkgQXNzb2Np YXRpb24gSUQgZmllbGQsIGFzIGV4cGxhaW5lZCBpbiBTZWN0aW9uIDMuCiAgIElmIHRoZSBsb2Nh bGx5IGNvbXB1dGVkIEhhc2ggaXMgZXF1YWwgdG8gdGhlIHJlY2VpdmVkIHZhbHVlIG9mIHRoZQog ICBBdXRoZW50aWNhdGlvbiBEYXRhIGZpZWxkLCB0aGUgcmVjZWl2ZWQgcGFja2V0IGlzIGFjY2Vw dGVkIGZvciBvdGhlcgogICBub3JtYWwgY2hlY2tzIGFuZCBwcm9jZXNzaW5nIGFzIGRlc2NyaWJl ZCBpbiBbUkZDNTAzNl0uICBPdGhlcndpc2UsCiAgIGlmIHRoZSBsb2NhbGx5IGNvbXB1dGVkIEhh c2ggaXMgbm90IGVxdWFsIHRvIHRoZSByZWNlaXZlZCB2YWx1ZSBvZgogICB0aGUgQXV0aGVudGlj YXRpb24gRGF0YSBmaWVsZCwgdGhlIHJlY2VpdmVkIHBhY2tldCBNVVNUIGJlIGRpc2NhcmRlZCwK ICAgYW5kIGFuIGVycm9yIGV2ZW50IFNIT1VMRCBiZSBsb2dnZWQuICBUaGUgZm9yZXNhaWQgbG9n Z2luZyBuZWVkIHRvIGJlCiAgIGNhcmVmdWxseSByYXRlIGxpbWl0ZWQsIHNpbmNlIHdoaWxlIGEg TERQIHJvdXRlciBpcyB1bmRlciBhdHRhY2sgb2YgYQogICBzdG9ybSBvZiBzcG9vZmVkIGhlbGxv cywgdGhlIHJlc291cmNlIHRha2luZyBmb3IgbG9nZ2luZyBjb3VsZCBiZQogICBvdmVyd2VsbWlu Zy4KCiAgIEFmdGVyIHRoZSBMRFAgSGVsbG8gbWVzc2FnZSBoYXMgYmVlbiBzdWNjZXNzZnVsbHkg YXV0aGVudGljYXRlZCwKICAgaW1wbGVtZW50YXRpb25zIE1VU1Qgc3RvcmUgdGhlIDY0LWJpdCBj cnlwdG9ncmFwaGljIHNlcXVlbmNlIG51bWJlcgogICBmb3IgdGhlIEhlbGxvIG1lc3NhZ2UgcmVj ZWl2ZWQgZnJvbSB0aGUgbmVpZ2hib3IuICBUaGUgc2F2ZWQKICAgY3J5cHRvZ3JhcGhpYyBzZXF1 ZW5jZSBudW1iZXJzIHdpbGwgYmUgdXNlZCBmb3IgcmVwbGF5IGNoZWNraW5nIGZvcgogICBzdWJz ZXF1ZW50IHBhY2tldHMgcmVjZWl2ZWQgZnJvbSB0aGUgbmVpZ2hib3IuCgo3LiAgU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMKCiAgIFNlY3Rpb24gMSBvZiB0aGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0 aGUgc2VjdXJpdHkgaXNzdWVzIGFyaXNpbmcgZnJvbQogICB0aGUgdXNlIG9mIHVuYXV0aGVudGlj YXRlZCBMRFAgSGVsbG8gbWVzc2FnZXMuICBJbiBvcmRlciB0byBhZGRyZXNzCiAgIHRob3NlIGlz c3VlcywgaXQgaXMgUkVDT01NRU5ERUQgdGhhdCBhbGwgZGVwbG95bWVudHMgdXNlIHRoZQogICBD cnlwdG9ncmFwaGljIEF1dGhlbnRpY2F0aW9uIFRMViB0byBhdXRoZW50aWNhdGUgdGhlIEhlbGxv IG1lc3NhZ2VzLgoKICAgVGhlIHF1YWxpdHkgb2YgdGhlIHNlY3VyaXR5IHByb3ZpZGVkIGJ5IHRo ZSBDcnlwdG9ncmFwaGljCiAgIEF1dGhlbnRpY2F0aW9uIFRMViBkZXBlbmRzIGNvbXBsZXRlbHkg b24gdGhlIHN0cmVuZ3RoIG9mIHRoZQogICBjcnlwdG9ncmFwaGljIGFsZ29yaXRobSBpbiB1c2Us IHRoZSBzdHJlbmd0aCBvZiB0aGUga2V5IGJlaW5nIHVzZWQsCiAgIGFuZCB0aGUgY29ycmVjdCBp bXBsZW1lbnRhdGlvbiBvZiB0aGUgc2VjdXJpdHkgbWVjaGFuaXNtIGluCiAgIGNvbW11bmljYXRp bmcgTERQIGltcGxlbWVudGF0aW9ucy4gIEFsc28sIHRoZSBsZXZlbCBvZiBzZWN1cml0eQogICBw cm92aWRlZCBieSB0aGUgQ3J5cHRvZ3JhcGhpYyBBdXRoZW50aWNhdGlvbiBUTFYgdmFyaWVzIGJh c2VkIG9uIHRoZQogICBhdXRoZW50aWNhdGlvbiB0eXBlIHVzZWQuCgogICBJdCBzaG91bGQgYmUg bm90ZWQgdGhhdCB0aGUgYXV0aGVudGljYXRpb24gbWV0aG9kIGRlc2NyaWJlZCBpbiB0aGlzCiAg IGRvY3VtZW50IGlzIG5vdCBiZWluZyB1c2VkIHRvIGF1dGhlbnRpY2F0ZSB0aGUgc3BlY2lmaWMg b3JpZ2luYXRvciBvZgogICBhIHBhY2tldCBidXQgaXMgcmF0aGVyIGJlaW5nIHVzZWQgdG8gY29u ZmlybSB0aGF0IHRoZSBwYWNrZXQgaGFzCiAgIGluZGVlZCBiZWVuIGlzc3VlZCBieSBhIHJvdXRl ciB0aGF0IGhhcyBhY2Nlc3MgdG8gdGhlIEF1dGhlbnRpY2F0aW9uCiAgIEtleS4KCiAgIERlcGxv eW1lbnRzIFNIT1VMRCB1c2Ugc3VmZmljaWVudGx5IGxvbmcgYW5kIHJhbmRvbSB2YWx1ZXMgZm9y IHRoZQogICBBdXRoZW50aWNhdGlvbiBLZXkgc28gdGhhdCBndWVzc2luZyBhbmQgb3RoZXIgY3J5 cHRvZ3JhcGhpYyBhdHRhY2tzCiAgIG9uIHRoZSBrZXkgYXJlIG5vdCBmZWFzaWJsZSBpbiB0aGVp ciBlbnZpcm9ubWVudHMuICBJbiBzdXBwb3J0IG9mCiAgIHRoZXNlIHJlY29tbWVuZGF0aW9ucywg bWFuYWdlbWVudCBzeXN0ZW1zIFNIT1VMRCBzdXBwb3J0IGhleGFkZWNpbWFsCiAgIGlucHV0IG9m IEF1dGhlbnRpY2F0aW9uIEtleXMuCgoKCgpaaGVuZywgZXQgYWwuICAgICAgICAgICBFeHBpcmVz IE5vdmVtYmVyIDIyLCAyMDE0ICAgICAgICAgICAgICBbUGFnZSAxMV0KDApJbnRlcm5ldC1EcmFm dCAgIExEUCBIZWxsbyBDcnlwdG9ncmFwaGljIEF1dGhlbnRpY2F0aW9uICAgICAgICAgTWF5IDIw MTQKCgogICBUaGUgbWVjaGFuaXNtIGRlc2NyaWJlZCBoZXJlaW4gaXMgbm90IHBlcmZlY3QgLiAg SG93ZXZlciwgdGhpcwogICBtZWNoYW5pc20gaW50cm9kdWNlcyBhIHNpZ25pZmljYW50IGluY3Jl YXNlIGluIHRoZSBlZmZvcnQgcmVxdWlyZWQKICAgZm9yIGFuIGFkdmVyc2FyeSB0byBzdWNjZXNz ZnVsbHkgYXR0YWNrIHRoZSBMRFAgSGVsbG8gcHJvdG9jb2wgd2hpbGUKICAgbm90IGNhdXNpbmcg dW5kdWUgaW1wbGVtZW50YXRpb24sIGRlcGxveW1lbnQsIG9yIG9wZXJhdGlvbmFsCiAgIGNvbXBs ZXhpdHkuCgo4LiAgSUFOQSBDb25zaWRlcmF0aW9ucwoKICAgVGhlIElBTkEgaXMgcmVxdWVzdGVk IHRvIGFzIGFzc2lnbiBhIG5ldyBUTFYgZnJvbSB0aGUgIk11bHRpcHJvdG9jb2wKICAgTGFiZWwg U3dpdGNoaW5nIEFyY2hpdGVjdHVyZSAoTVBMUykgTGFiZWwgU3dpdGNoZWQgUGF0aHMgKExTUHMp CiAgIFBhcmFtZXRlcnMgLSBUTFZzIiByZWdpc3RyeSwgIlRMVnMgYW5kIHN1Yi1UTFZzIiBzdWIt IHJlZ2lzdHJ5LgoKICAgVmFsdWUgICBNZWFuaW5nICAgICAgICAgICAgICAgICAgICAgICAgICAg IFJlZmVyZW5jZQogICAtLS0tLSAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tICAg LS0tLS0tLS0tCiAgIFRCRDEgICAgIENyeXB0b2dyYXBoaWMgQXV0aGVudGljYXRpb24gVExWICAg dGhpcyBkb2N1bWVudCAoc2VjdCAyLjMpCgogICBUaGUgSUFOQSBpcyBhbHNvIHJlcXVlc3RlZCB0 byBhcyBhc3NpZ24gdmFsdWUgZnJvbSB0aGUKICAgIkF1dGhlbnRpY2F0aW9uIENyeXB0b2dyYXBo aWMgUHJvdG9jb2wgSUQiLCByZWdpc3RyeSB1bmRlciB0aGUKICAgIktleWluZyBhbmQgQXV0aGVu dGljYXRpb24gZm9yIFJvdXRpbmcgUHJvdG9jb2xzIChLQVJQKSBQYXJhbWV0ZXJzIgogICBjYXRl Z29yeS4KCiAgIFZhbHVlICAgTWVhbmluZyAgICAgICAgICAgICAgICAgICAgICAgICAgICBSZWZl cmVuY2UKICAgLS0tLS0gICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAgIC0tLS0t LS0tLQogICBUQkQyICAgICBMRFAgQ3J5cHRvZ3JhcGhpYyBQcm90b2NvbCBJRCAgICAgIHRoaXMg ZG9jdW1lbnQgKHNlY3QgNCkKCjkuICBBY2tub3dsZWRnZW1lbnRzCgogICBXZSBhcmUgaW5kZWJ0 ZWQgdG8gWWFyb24gU2hlZmZlciB3aG8gaGVscGVkIHVzIGVub3Jtb3VzbHkgaW4KICAgcmV3cml0 aW5nIHRoZSBkcmFmdCB0byBnZXQgcmlkIG9mIHRoZSByZWR1bmRhbnQgY3J5cHRvIG1hdGhlbWF0 aWNzCiAgIHRoYXQgd2UgaGFkIGFkZGVkIGhlcmUuCgogICBXZSB3b3VsZCBhbHNvIGxpa2UgdG8g dGhhbmsgTGl1IFh1ZWh1IGZvciBoaXMgd29yayBvbiBiYWNrZ3JvdW5kIGFuZAogICBtb3RpdmF0 aW9uIGZvciBMRFAgSGVsbG8gYXV0aGVudGljYXRpb24uICBBbmQgbGFzdCBidXQgbm90IHRoZSBs ZWFzdCwKICAgd2Ugd291bGQgYWxzbyB0aGFuayBBZHJpYW4gRmFycmVsLCBFcmljIFJvc2VuLCBT YW0gSGFydG1hbiwgU3RlcGhlbgogICBGYXJyZWxsLCBFcmljIEdyYXksIEthbXJhbiBSYXphIGFu ZCBBY2VlIExpbmRlbSBmb3IgdGhlaXIgdmFsdWFibGUKICAgY29tbWVudHMuCgoxMC4gIFJlZmVy ZW5jZXMKCjEwLjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW0ZJUFMtMTgwLTNdCiAgICAg ICAgICAgICAgIlNlY3VyZSBIYXNoIFN0YW5kYXJkIChTSFMpLCBGSVBTIFBVQiAxODAtMyIsIE9j dG9iZXIKICAgICAgICAgICAgICAyMDA4LgoKICAgW0ZJUFMtMTk4XQogICAgICAgICAgICAgICJU aGUgS2V5ZWQtSGFzaCBNZXNzYWdlIEF1dGhlbnRpY2F0aW9uIENvZGUgKEhNQUMpLCBGSVBTCiAg ICAgICAgICAgICAgUFVCIDE5OCIsIE1hcmNoIDIwMDIuCgoKClpoZW5nLCBldCBhbC4gICAgICAg ICAgIEV4cGlyZXMgTm92ZW1iZXIgMjIsIDIwMTQgICAgICAgICAgICAgIFtQYWdlIDEyXQoMCklu dGVybmV0LURyYWZ0ICAgTERQIEhlbGxvIENyeXB0b2dyYXBoaWMgQXV0aGVudGljYXRpb24gICAg ICAgICBNYXkgMjAxNAoKCiAgIFtSRkMyMTA0XSAgS3Jhd2N6eWssIEguLCBCZWxsYXJlLCBNLiwg YW5kIFIuIENhbmV0dGksICJITUFDOiBLZXllZC0KICAgICAgICAgICAgICBIYXNoaW5nIGZvciBN ZXNzYWdlIEF1dGhlbnRpY2F0aW9uIiwgUkZDIDIxMDQsIEZlYnJ1YXJ5CiAgICAgICAgICAgICAg MTk5Ny4KCiAgIFtSRkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBS RkNzIHRvIEluZGljYXRlCiAgICAgICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0 LCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4KCiAgIFtSRkM0ODIyXSAgQXRraW5zb24sIFIuIGFuZCBN LiBGYW50bywgIlJJUHYyIENyeXB0b2dyYXBoaWMKICAgICAgICAgICAgICBBdXRoZW50aWNhdGlv biIsIFJGQyA0ODIyLCBGZWJydWFyeSAyMDA3LgoKICAgW1JGQzUwMzZdICBBbmRlcnNzb24sIEwu LCBNaW5laSwgSS4sIGFuZCBCLiBUaG9tYXMsICJMRFAKICAgICAgICAgICAgICBTcGVjaWZpY2F0 aW9uIiwgUkZDIDUwMzYsIE9jdG9iZXIgMjAwNy4KCiAgIFtSRkM1MzEwXSAgQmhhdGlhLCBNLiwg TWFucmFsLCBWLiwgTGksIFQuLCBBdGtpbnNvbiwgUi4sIFdoaXRlLCBSLiwKICAgICAgICAgICAg ICBhbmQgTS4gRmFudG8sICJJUy1JUyBHZW5lcmljIENyeXB0b2dyYXBoaWMKICAgICAgICAgICAg ICBBdXRoZW50aWNhdGlvbiIsIFJGQyA1MzEwLCBGZWJydWFyeSAyMDA5LgoKICAgW1JGQzU3MDld ICBCaGF0aWEsIE0uLCBNYW5yYWwsIFYuLCBGYW50bywgTS4sIFdoaXRlLCBSLiwgQmFybmVzLCBN LiwKICAgICAgICAgICAgICBMaSwgVC4sIGFuZCBSLiBBdGtpbnNvbiwgIk9TUEZ2MiBITUFDLVNI QSBDcnlwdG9ncmFwaGljCiAgICAgICAgICAgICAgQXV0aGVudGljYXRpb24iLCBSRkMgNTcwOSwg T2N0b2JlciAyMDA5LgoKICAgW1JGQzcxNjZdICBCaGF0aWEsIE0uLCBNYW5yYWwsIFYuLCBhbmQg QS4gTGluZGVtLCAiU3VwcG9ydGluZwogICAgICAgICAgICAgIEF1dGhlbnRpY2F0aW9uIFRyYWls ZXIgZm9yIE9TUEZ2MyIsIFJGQyA3MTY2LCBNYXJjaCAyMDE0LgoKMTAuMi4gIEluZm9ybWF0aXZl IFJlZmVyZW5jZXMKCiAgIFtSRkM1MDgyXSAgR2lsbCwgVi4sIEhlYXNsZXksIEouLCBNZXllciwg RC4sIFNhdm9sYSwgUC4sIGFuZCBDLgogICAgICAgICAgICAgIFBpZ25hdGFybywgIlRoZSBHZW5l cmFsaXplZCBUVEwgU2VjdXJpdHkgTWVjaGFuaXNtCiAgICAgICAgICAgICAgKEdUU00pIiwgUkZD IDUwODIsIE9jdG9iZXIgMjAwNy4KCiAgIFtSRkM1OTI2XSAgTGVib3ZpdHosIEcuIGFuZCBFLiBS ZXNjb3JsYSwgIkNyeXB0b2dyYXBoaWMgQWxnb3JpdGhtcwogICAgICAgICAgICAgIGZvciB0aGUg VENQIEF1dGhlbnRpY2F0aW9uIE9wdGlvbiAoVENQLUFPKSIsIFJGQyA1OTI2LAogICAgICAgICAg ICAgIEp1bmUgMjAxMC4KCiAgIFtSRkM2NzIwXSAgUGlnbmF0YXJvLCBDLiBhbmQgUi4gQXNhdGks ICJUaGUgR2VuZXJhbGl6ZWQgVFRMIFNlY3VyaXR5CiAgICAgICAgICAgICAgTWVjaGFuaXNtIChH VFNNKSBmb3IgdGhlIExhYmVsIERpc3RyaWJ1dGlvbiBQcm90b2NvbAogICAgICAgICAgICAgIChM RFApIiwgUkZDIDY3MjAsIEF1Z3VzdCAyMDEyLgoKICAgW1JGQzY5NTJdICBKZXRoYW5hbmRhbmks IE0uLCBQYXRlbCwgSy4sIGFuZCBMLiBaaGVuZywgIkFuYWx5c2lzIG9mCiAgICAgICAgICAgICAg QkdQLCBMRFAsIFBDRVAsIGFuZCBNU0RQIElzc3VlcyBBY2NvcmRpbmcgdG8gdGhlIEtleWluZwog ICAgICAgICAgICAgIGFuZCBBdXRoZW50aWNhdGlvbiBmb3IgUm91dGluZyBQcm90b2NvbHMgKEtB UlApIERlc2lnbgogICAgICAgICAgICAgIEd1aWRlIiwgUkZDIDY5NTIsIE1heSAyMDEzLgoKQXV0 aG9ycycgQWRkcmVzc2VzCgoKCgoKCgpaaGVuZywgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIE5v dmVtYmVyIDIyLCAyMDE0ICAgICAgICAgICAgICBbUGFnZSAxM10KDApJbnRlcm5ldC1EcmFmdCAg IExEUCBIZWxsbyBDcnlwdG9ncmFwaGljIEF1dGhlbnRpY2F0aW9uICAgICAgICAgTWF5IDIwMTQK CgogICBMaWFuc2h1IFpoZW5nCiAgIEh1YXdlaSBUZWNobm9sb2dpZXMKICAgQ2hpbmEKCiAgIEVt YWlsOiB2ZXJvLnpoZW5nQGh1YXdlaS5jb20KCgogICBNYWNoKEd1b3lpKSBDaGVuCiAgIEh1YXdl aSBUZWNobm9sb2dpZXMKICAgQ2hpbmEKCiAgIEVtYWlsOiBtYWNoLmNoZW5AaHVhd2VpLmNvbQoK CiAgIE1hbmF2IEJoYXRpYQogICBBbGNhdGVsLUx1Y2VudAogICBJbmRpYQoKICAgRW1haWw6IG1h bmF2YmhhdGlhQGdtYWlsLmNvbQoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKClpoZW5n LCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMjIsIDIwMTQgICAgICAgICAgICAg IFtQYWdlIDE0XQo= --047d7b5d42f8ae28c704fa330813 Content-Type: text/xml; charset=US-ASCII; name="draft-ietf-mpls-ldp-hello-crypto-auth-06.xml" Content-Disposition: attachment; filename="draft-ietf-mpls-ldp-hello-crypto-auth-06.xml" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hvlxcsc11 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVMtQVNDSUkiPz4NCjwhRE9DVFlQRSByZmMg U1lTVEVNICJyZmMyNjI5LmR0ZCI+DQo8P3JmYyB0b2M9InllcyI/Pg0KPD9yZmMgdG9jb21wYWN0 PSJubyI/Pg0KPD9yZmMgdG9jZGVwdGg9IjYiPz4NCjw/cmZjIHN5bXJlZnM9InllcyI/Pg0KPD9y ZmMgc29ydHJlZnM9InllcyI/Pg0KPHJmYyBjYXRlZ29yeT0ic3RkIiBkb2NOYW1lPSJkcmFmdC1p ZXRmLW1wbHMtbGRwLWhlbGxvLWNyeXB0by1hdXRoLTA2LnR4dCINCiAgICAgaXByPSJ0cnVzdDIw MDkwMiI+DQogIDxmcm9udD4NCiAgICA8dGl0bGUgYWJicmV2PSJMRFAgSGVsbG8gQ3J5cHRvZ3Jh cGhpYyBBdXRoZW50aWNhdGlvbiI+TERQIEhlbGxvDQogICAgQ3J5cHRvZ3JhcGhpYyBBdXRoZW50 aWNhdGlvbjwvdGl0bGU+DQoNCiAgICA8YXV0aG9yIGZ1bGxuYW1lPSJMaWFuc2h1IFpoZW5nIiBp bml0aWFscz0iTC4iIHN1cm5hbWU9IlpoZW5nIj4NCiAgICAgIDxvcmdhbml6YXRpb24+SHVhd2Vp IFRlY2hub2xvZ2llczwvb3JnYW5pemF0aW9uPg0KDQogICAgICA8YWRkcmVzcz4NCiAgICAgICAg PHBvc3RhbD4NCiAgICAgICAgICA8c3RyZWV0Lz4NCg0KICAgICAgICAgIDxjaXR5Lz4NCg0KICAg ICAgICAgIDxyZWdpb24vPg0KDQogICAgICAgICAgPGNvZGUvPg0KDQogICAgICAgICAgPGNvdW50 cnk+Q2hpbmE8L2NvdW50cnk+DQogICAgICAgIDwvcG9zdGFsPg0KDQogICAgICAgIDxlbWFpbD52 ZXJvLnpoZW5nQGh1YXdlaS5jb208L2VtYWlsPg0KICAgICAgPC9hZGRyZXNzPg0KICAgIDwvYXV0 aG9yPg0KDQogICAgPGF1dGhvciBmdWxsbmFtZT0iTWFjaChHdW95aSkgQ2hlbiIgaW5pdGlhbHM9 Ik0uIiBzdXJuYW1lPSJDaGVuIj4NCiAgICAgIDxvcmdhbml6YXRpb24+SHVhd2VpIFRlY2hub2xv Z2llczwvb3JnYW5pemF0aW9uPg0KDQogICAgICA8YWRkcmVzcz4NCiAgICAgICAgPHBvc3RhbD4N CiAgICAgICAgICA8c3RyZWV0Lz4NCg0KICAgICAgICAgIDxjaXR5Lz4NCg0KICAgICAgICAgIDxy ZWdpb24vPg0KDQogICAgICAgICAgPGNvZGUvPg0KDQogICAgICAgICAgPGNvdW50cnk+Q2hpbmE8 L2NvdW50cnk+DQogICAgICAgIDwvcG9zdGFsPg0KDQogICAgICAgIDxlbWFpbD5tYWNoLmNoZW5A aHVhd2VpLmNvbTwvZW1haWw+DQogICAgICA8L2FkZHJlc3M+DQogICAgPC9hdXRob3I+DQoNCiAg ICA8YXV0aG9yIGZ1bGxuYW1lPSJNYW5hdiBCaGF0aWEiIGluaXRpYWxzPSJNLiIgc3VybmFtZT0i QmhhdGlhIj4NCiAgICAgIDxvcmdhbml6YXRpb24+QWxjYXRlbC1MdWNlbnQ8L29yZ2FuaXphdGlv bj4NCg0KICAgICAgPGFkZHJlc3M+DQogICAgICAgIDxwb3N0YWw+DQogICAgICAgICAgPHN0cmVl dC8+DQoNCiAgICAgICAgICA8Y2l0eS8+DQoNCiAgICAgICAgICA8cmVnaW9uLz4NCg0KICAgICAg ICAgIDxjb2RlLz4NCg0KICAgICAgICAgIDxjb3VudHJ5PkluZGlhPC9jb3VudHJ5Pg0KICAgICAg ICA8L3Bvc3RhbD4NCg0KICAgICAgICA8ZW1haWw+bWFuYXZiaGF0aWFAZ21haWwuY29tPC9lbWFp bD4NCiAgICAgIDwvYWRkcmVzcz4NCiAgICA8L2F1dGhvcj4NCg0KICAgIDxkYXRlIGRheT0iMjEi IG1vbnRoPSJNYXkiIHllYXI9IjIwMTQiLz4NCg0KICAgIDxhYnN0cmFjdD4NCiAgICAgIDx0PlRo aXMgZG9jdW1lbnQgaW50cm9kdWNlcyBhIG5ldyBvcHRpb25hbCBDcnlwdG9ncmFwaGljIEF1dGhl bnRpY2F0aW9uDQogICAgICBUTFYgdGhhdCBMRFAgY2FuIHVzZSB0byBzZWN1cmUgaXRzIEhlbGxv IG1lc3NhZ2VzLiBJdCBzZWN1cmVzIHRoZSBIZWxsbw0KICAgICAgbWVzc2FnZXMgYWdhaW5zdCBz cG9vZmluZyBhdHRhY2tzIGFuZCBzb21lIHdlbGwga25vd24gYXR0YWNrcyBhZ2FpbnN0DQogICAg ICB0aGUgSVAgaGVhZGVyLiBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIG1lY2hhbmlzbSB0byBz ZWN1cmUgdGhlIExEUA0KICAgICAgSGVsbG8gbWVzc2FnZXMgdXNpbmcgTmF0aW9uYWwgSW5zdGl0 dXRlIG9mIFN0YW5kYXJkcyBhbmQgVGVjaG5vbG9neQ0KICAgICAgKE5JU1QpIFNlY3VyZSBIYXNo IFN0YW5kYXJkIGZhbWlseSBvZiBhbGdvcml0aG1zLjwvdD4NCiAgICA8L2Fic3RyYWN0Pg0KDQog ICAgPG5vdGUgdGl0bGU9IlJlcXVpcmVtZW50cyBMYW5ndWFnZSI+DQogICAgICA8dD5UaGUga2V5 IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5P VCIsDQogICAgICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwg YW5kICJPUFRJT05BTCIgaW4gdGhpcw0KICAgICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJl dGVkIGFzIGRlc2NyaWJlZCBpbiA8eHJlZg0KICAgICAgdGFyZ2V0PSJSRkMyMTE5Ij5SRkMgMjEx OTwveHJlZj4uPC90Pg0KICAgIDwvbm90ZT4NCiAgPC9mcm9udD4NCg0KICA8bWlkZGxlPg0KICAg IDxzZWN0aW9uIHRpdGxlPSJJbnRyb2R1Y3Rpb24iPg0KICAgICAgPHQ+VGhlIExhYmVsIERpc3Ry aWJ1dGlvbiBQcm90b2NvbCAoTERQKSA8eHJlZiB0YXJnZXQ9IlJGQzUwMzYiLz4gc2V0cw0KICAg ICAgdXAgTERQIHNlc3Npb25zIHRoYXQgcnVuIGJldHdlZW4gTERQIHBlZXJzLiBUaGUgcGVlcnMg Y291bGQgZWl0aGVyIGJlDQogICAgICBkaXJlY3RseSBjb25uZWN0ZWQgYXQgdGhlIGxpbmsgbGV2 ZWwgb3IgY291bGQgYmUgbXVsdGlwbGUgaG9wcyBhd2F5LiBBbg0KICAgICAgTERQIExhYmVsIFN3 aXRjaGluZyBSb3V0ZXIgKExTUikgY291bGQgZWl0aGVyIGJlIGNvbmZpZ3VyZWQgd2l0aCB0aGUN CiAgICAgIGlkZW50aXR5IG9mIGl0cyBwZWVycyBvciBjb3VsZCBkaXNjb3ZlciB0aGVtIHVzaW5n IExEUCBIZWxsbyBtZXNzYWdlcy4NCiAgICAgIFRoZXNlIG1lc3NhZ2VzIGFyZSBzZW50IGVuY2Fw c3VsYXRlZCBpbiBVRFAgYWRkcmVzc2VkIHRvICJhbGwgcm91dGVycyBvbg0KICAgICAgdGhpcyBz dWJuZXQiIG9yIHRvIGEgc3BlY2lmaWMgSVAgYWRkcmVzcy4gUGVyaW9kaWMgSGVsbG8gbWVzc2Fn ZXMgYXJlDQogICAgICBhbHNvIHVzZWQgdG8gbWFpbnRhaW4gdGhlIHJlbGF0aW9uc2hpcCBiZXR3 ZWVuIExEUCBwZWVycyBuZWNlc3NhcnkgdG8NCiAgICAgIGtlZXAgdGhlIExEUCBzZXNzaW9uIGFj dGl2ZS48L3Q+DQoNCiAgICAgIDx0PlNpbmNlIHRoZSBIZWxsbyBtZXNzYWdlcyBhcmUgc2VudCB1 c2luZyBVRFAgYW5kIG5vdCBUQ1AsIHRoZXNlDQogICAgICBtZXNzYWdlcyBjYW5ub3QgdXNlIHRo ZSBzZWN1cml0eSBtZWNoYW5pc21zIGRlZmluZWQgZm9yIFRDUCA8eHJlZg0KICAgICAgdGFyZ2V0 PSJSRkM1OTI2Ij4gPC94cmVmPi4gV2hpbGUgc29tZSBjb25maWd1cmF0aW9uIGd1aWRhbmNlIGlz IGdpdmVuIGluDQogICAgICA8eHJlZiB0YXJnZXQ9IlJGQzUwMzYiLz4gdG8gaGVscCBwcm90ZWN0 IGFnYWluc3QgZmFsc2UgZGlzY292ZXJ5DQogICAgICBtZXNzYWdlcywgaXQgZG9lcyBub3QgcHJv dmlkZSBhbiBleHBsaWNpdCBzZWN1cml0eSBtZWNoYW5pc20gdG8gcHJvdGVjdA0KICAgICAgdGhl IEhlbGxvIG1lc3NhZ2VzLjwvdD4NCg0KICAgICAgPHQ+U3Bvb2ZpbmcgYSBIZWxsbyBwYWNrZXQg Zm9yIGFuIGV4aXN0aW5nIGFkamFjZW5jeSBjYW4gY2F1c2UgdGhlIHZhbGlkDQogICAgICBhZGph Y2VuY3kgdG8gdGltZSBvdXQgYW5kIGluIHR1cm4gY2FuIHJlc3VsdCBpbiB0ZXJtaW5hdGlvbiBv ZiB0aGUNCiAgICAgIGFzc29jaWF0ZWQgc2Vzc2lvbi4gVGhpcyBjYW4gb2NjdXIgd2hlbiB0aGUg c3Bvb2ZlZCBIZWxsbyBzcGVjaWZpZXMgYQ0KICAgICAgc21hbGxlciBIb2xkIFRpbWUsIGNhdXNp bmcgdGhlIHJlY2VpdmVyIHRvIGV4cGVjdCBIZWxsb3Mgd2l0aGluIHRoaXMNCiAgICAgIHNtYWxs ZXIgaW50ZXJ2YWwsIHdoaWxlIHRoZSB0cnVlIG5laWdoYm9yIGNvbnRpbnVlcyBzZW5kaW5nIEhl bGxvcyBhdA0KICAgICAgdGhlIHByZXZpb3VzbHkgYWdyZWVkIGxvd2VyIGZyZXF1ZW5jeS4gU3Bv b2ZpbmcgYSBIZWxsbyBwYWNrZXQgY2FuIGFsc28NCiAgICAgIGNhdXNlIHRoZSBMRFAgc2Vzc2lv biB0byBiZSB0ZXJtaW5hdGVkIGRpcmVjdGx5LCB3aGljaCBjYW4gb2NjdXIgd2hlbg0KICAgICAg dGhlIHNwb29mZWQgSGVsbG8gc3BlY2lmaWVzIGEgZGlmZmVyZW50IFRyYW5zcG9ydCBBZGRyZXNz LCBvdGhlciB0aGFuDQogICAgICB0aGUgcHJldmlvdXNseSBhZ3JlZWQgb25lIGJldHdlZW4gbmVp Z2hib3JzLiBTcG9vZmVkIEhlbGxvIG1lc3NhZ2VzIGhhdmUNCiAgICAgIGJlZW4gb2JzZXJ2ZWQg YW5kIHJlcG9ydGVkIGFzIGEgcmVhbCBwcm9ibGVtIGluIHByb2R1Y3Rpb24gbmV0d29ya3MNCiAg ICAgIDx4cmVmIHRhcmdldD0iUkZDNjk1MiIvPi4gPC90Pg0KDQogICAgICA8dD5Gb3IgTGluayBI ZWxsbywgPHhyZWYgdGFyZ2V0PSJSRkM1MDM2Ii8+IHN0YXRlcyB0aGF0IHRoZSB0aHJlYXQgb2YN CiAgICAgIHNwb29mZWQgSGVsbG9zIGNhbiBiZSByZWR1Y2VkIGJ5IGFjY2VwdGluZyBIZWxsb3Mg b25seSBvbiBpbnRlcmZhY2VzIHRvDQogICAgICB3aGljaCBMU1JzIHRoYXQgY2FuIGJlIHRydXN0 ZWQgYXJlIGRpcmVjdGx5IGNvbm5lY3RlZCwgYW5kIGlnbm9yaW5nDQogICAgICBIZWxsb3Mgbm90 IGFkZHJlc3NlZCB0byB0aGUgImFsbCByb3V0ZXJzIG9uIHRoaXMgc3VibmV0IiBtdWx0aWNhc3QN CiAgICAgIGdyb3VwLiBUaGUgR2VuZXJhbGl6ZWQgVFRMIFNlY3VyaXR5IE1lY2hhbmlzbSAoR1RT TSkgcHJvdmlkZXMgYSBzaW1wbGUNCiAgICAgIGFuZCByZWFzb25hYmx5IHJvYnVzdCBkZWZlbnNl IG1lY2hhbmlzbSBmb3IgTGluayBIZWxsbyA8eHJlZg0KICAgICAgdGFyZ2V0PSJSRkM2NzIwIi8+ LCBidXQgaXQgZG9lcyBub3Qgc2VjdXJlIGFnYWluc3QgcGFja2V0IHNwb29maW5nDQogICAgICBh dHRhY2sgb3IgcmVwbGF5IGF0dGFjazx4cmVmIHRhcmdldD0iUkZDNTA4MiIvPi48L3Q+DQoNCiAg ICAgIDx0PlNwb29maW5nIGF0dGFja3MgdmlhIFRhcmdldGVkIEhlbGxvcyBhcmUgYSBwb3RlbnRp YWxseSBtb3JlIHNlcmlvdXMNCiAgICAgIHRocmVhdC4gPHhyZWYgdGFyZ2V0PSJSRkM1MDM2Ii8+ IHN0YXRlcyB0aGF0IGFuIExTUiBjYW4gcmVkdWNlIHRoZQ0KICAgICAgdGhyZWF0IG9mIHNwb29m ZWQgVGFyZ2V0ZWQgSGVsbG9zIGJ5IGZpbHRlcmluZyB0aGVtIGFuZCBhY2NlcHRpbmcgb25seQ0K ICAgICAgdGhvc2Ugb3JpZ2luYXRpbmcgYXQgc291cmNlcyBwZXJtaXR0ZWQgYnkgYW4gYWNjZXNz IGxpc3QuIEhvd2V2ZXIsDQogICAgICBmaWx0ZXJpbmcgdXNpbmcgYWNjZXNzIGxpc3RzIHJlcXVp cmVzIExTUiByZXNvdXJjZSwgYW5kIGRvZXMgbm90IHByZXZlbnQNCiAgICAgIElQLWFkZHJlc3Mg c3Bvb2ZpbmcuPC90Pg0KDQogICAgICA8dD5UaGlzIGRvY3VtZW50IGludHJvZHVjZXMgYSBuZXcg Q3J5cHRvZ3JhcGhpYyBBdXRoZW50aWNhdGlvbiBUTFYgd2hpY2gNCiAgICAgIGlzIHVzZWQgaW4g TERQIEhlbGxvIG1lc3NhZ2VzIGFzIGFuIG9wdGlvbmFsIHBhcmFtZXRlci4gSXQgZW5oYW5jZXMg dGhlDQogICAgICBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20gZm9yIExEUCBieSBzZWN1cmluZyB0 aGUgSGVsbG8gbWVzc2FnZSBhZ2FpbnN0DQogICAgICBzcG9vZmluZyBhdHRhY2suIEl0IGFsc28g aW50cm9kdWNlcyBhIGNyeXB0b2dyYXBoaWMgc2VxdWVuY2UgbnVtYmVyDQogICAgICBjYXJyaWVk IGluIHRoZSBIZWxsbyBtZXNzYWdlcyB0aGF0IGNhbiBiZSB1c2VkIHRvIHByb3RlY3QgYWdhaW5z dCByZXBsYXkNCiAgICAgIGF0dGFja3MuIFRoZSBMU1JzIGNvdWxkIGJlIGNvbmZpZ3VyZWQgdG8g b25seSBhY2NlcHQgSGVsbG8gbWVzc2FnZXMgZnJvbQ0KICAgICAgc3BlY2lmaWMgcGVlcnMgd2hl biBhdXRoZW50aWNhdGlvbiBpcyBpbiB1c2UuIDwvdD4NCg0KICAgICAgPHQ+VXNpbmcgdGhpcyBD cnlwdG9ncmFwaGljIEF1dGhlbnRpY2F0aW9uIFRMViwgb25lIG9yIG1vcmUgc2VjcmV0IGtleXMN CiAgICAgICh3aXRoIGNvcnJlc3BvbmRpbmcgU2VjdXJpdHkgQXNzb2NpYXRpb24gKFNBKSBJRHMp IGFyZSBjb25maWd1cmVkIGluDQogICAgICBlYWNoIHN5c3RlbS4gRm9yIGVhY2ggTERQIEhlbGxv IG1lc3NhZ2UsIHRoZSBrZXkgaXMgdXNlZCB0byBnZW5lcmF0ZSBhbmQNCiAgICAgIHZlcmlmeSBh IEhNQUMgSGFzaCB0aGF0IGlzIHN0b3JlZCBpbiB0aGUgTERQIEhlbGxvIG1lc3NhZ2UuIEZvcg0K ICAgICAgY3J5cHRvZ3JhcGhpYyBoYXNoIGZ1bmN0aW9uLCB0aGlzIGRvY3VtZW50IHByb3Bvc2Vz IHRvIHVzZSBTSEEtMSwNCiAgICAgIFNIQS0yNTYsIFNIQS0zODQsIGFuZCBTSEEtNTEyIGRlZmlu ZWQgaW4gVVMgTklTVCBTZWN1cmUgSGFzaCBTdGFuZGFyZA0KICAgICAgKFNIUykgPHhyZWYgdGFy Z2V0PSJGSVBTLTE4MC0zIi8+LiBUaGUgSE1BQyBhdXRoZW50aWNhdGlvbiBtb2RlIGRlZmluZWQN CiAgICAgIGluIDx4cmVmIHRhcmdldD0iUkZDMjEwNCIvPiBpcyB1c2VkLg0KICAgICAgPCEtLSBS ZXBsYWNlZCBGSVBTIGJ5IHRoZSByZXNwZWN0aXZlIFJGQyAtLT4NCiAgICAgIE9mIHRoZSBhYm92 ZSwNCiAgICAgIGltcGxlbWVudGF0aW9ucyBNVVNUIGluY2x1ZGUgc3VwcG9ydCBmb3IgYXQgbGVh c3QgSE1BQy1TSEEtMjU2IGFuZA0KICAgICAgU0hPVUxEIGluY2x1ZGUgc3VwcG9ydCBmb3IgSE1B Qy1TSEEtMSBhbmQgTUFZIGluY2x1ZGUgc3VwcG9ydCBmb3IgZWl0aGVyDQogICAgICBvZiBITUFD LVNIQS0zODQgb3IgSE1BQy1TSEEtNTEyLjwvdD4NCiAgICA8L3NlY3Rpb24+DQoNCiAgICA8c2Vj dGlvbiB0aXRsZT0iQ3J5cHRvZ3JhcGhpYyBBdXRoZW50aWNhdGlvbiBUTFYiPg0KICAgICAgPHNl Y3Rpb24gdGl0bGU9Ik9wdGlvbmFsIFBhcmFtZXRlciBmb3IgSGVsbG8gTWVzc2FnZSI+DQogICAg ICAgIDx0Pjx4cmVmIHRhcmdldD0iUkZDNTAzNiIvPiBkZWZpbmVzIHRoZSBlbmNvZGluZyBmb3Ig dGhlIEhlbGxvDQogICAgICAgIG1lc3NhZ2UuIEVhY2ggSGVsbG8gbWVzc2FnZSBjb250YWlucyB6 ZXJvIG9yIG1vcmUgT3B0aW9uYWwgUGFyYW1ldGVycywNCiAgICAgICAgZWFjaCBlbmNvZGVkIGFz IGEgVExWLiBUaHJlZSBPcHRpb25hbCBQYXJhbWV0ZXJzIGFyZSBkZWZpbmVkIGJ5IDx4cmVmDQog ICAgICAgIHRhcmdldD0iUkZDNTAzNiIvPi4gVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbmV3IE9w dGlvbmFsIFBhcmFtZXRlcjoNCiAgICAgICAgdGhlIENyeXB0b2dyYXBoaWMgQXV0aGVudGljYXRp b24gcGFyYW1ldGVyLjwvdD4NCg0KICAgICAgICA8ZmlndXJlIGFsaWduPSJsZWZ0Ij4NCiAgICAg ICAgICA8YXJ0d29yaz48IVtDREFUQVsNCk9wdGlvbmFsIFBhcmFtZXRlciAgICAgICAgICAgICAg IFR5cGUNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gIC0tLS0tLS0tDQpJUHY0IFRy YW5zcG9ydCBBZGRyZXNzICAgICAgICAgICAweDA0MDEgKFJGQzUwMzYpDQpDb25maWd1cmF0aW9u IFNlcXVlbmNlIE51bWJlciAgICAweDA0MDIgKFJGQzUwMzYpDQpJUHY2IFRyYW5zcG9ydCBBZGRy ZXNzICAgICAgICAgICAweDA0MDMgKFJGQzUwMzYpDQpDcnlwdG9ncmFwaGljIEF1dGhlbnRpY2F0 aW9uICAgICAweDA0MDQgKHRoaXMgZG9jdW1lbnQsIFRCRDEgYnkgSUFOQSkNCg0KXV0+PC9hcnR3 b3JrPg0KICAgICAgICA8L2ZpZ3VyZT4NCg0KICAgICAgICA8dD5UaGUgQ3J5cHRvZ3JhcGhpYyBB dXRoZW50aWNhdGlvbiBUTFYgRW5jb2RpbmcgaXMgZGVzY3JpYmVkIGluDQogICAgICAgIHNlY3Rp b24gMi4zLjwvdD4NCiAgICAgIDwvc2VjdGlvbj4NCg0KICAgICAgPHNlY3Rpb24gdGl0bGU9IkxE UCBTZWN1cml0eSBBc3NvY2lhdGlvbiI+DQogICAgICAgIDx0PkFuIExEUCBTZWN1cml0eSBBc3Nv Y2lhdGlvbiAoU0EpIGNvbnRhaW5zIGEgc2V0IG9mIHBhcmFtZXRlcnMNCiAgICAgICAgc2hhcmVk IGJldHdlZW4gYW55IHR3byBsZWdpdGltYXRlIExEUCBzcGVha2Vycy48L3Q+DQoNCiAgICAgICAg PHQ+UGFyYW1ldGVycyBhc3NvY2lhdGVkIHdpdGggYW4gTERQIFNBIGFyZSBhcyBmb2xsb3dzOjwv dD4NCg0KICAgICAgICA8dD48bGlzdCBzdHlsZT0ic3ltYm9scyI+DQogICAgICAgICAgICA8dD5T ZWN1cml0eSBBc3NvY2lhdGlvbiBJZGVudGlmaWVyIChTQSBJRCkgPHZzcGFjZQ0KICAgICAgICAg ICAgYmxhbmtMaW5lcz0iMSIvPiBUaGlzIGlzIGEgMzItYml0IHVuc2lnbmVkIGludGVnZXIgdXNl ZCB0bw0KICAgICAgICAgICAgdW5pcXVlbHkgaWRlbnRpZnkgYW4gTERQIFNBIGJldHdlZW4gdHdv IExEUCBwZWVycywgYXMgbWFudWFsbHkNCiAgICAgICAgICAgIGNvbmZpZ3VyZWQgYnkgdGhlIG5l dHdvcmsgb3BlcmF0b3IgKG9yLCBpbiB0aGUgZnV0dXJlLCBwb3NzaWJseSBieQ0KICAgICAgICAg ICAgc29tZSBrZXkgbWFuYWdlbWVudCBwcm90b2NvbCBzcGVjaWZpZWQgYnkgdGhlIElFVEYpIC48 dnNwYWNlDQogICAgICAgICAgICBibGFua0xpbmVzPSIxIi8+IFRoZSByZWNlaXZlciBkZXRlcm1p bmVzIHRoZSBhY3RpdmUgU0EgYnkgbG9va2luZw0KICAgICAgICAgICAgYXQgdGhlIFNBIElEIGZp ZWxkIGluIHRoZSBpbmNvbWluZyBIZWxsbyBtZXNzYWdlLiA8dnNwYWNlDQogICAgICAgICAgICBi bGFua0xpbmVzPSIxIi8+IFRoZSBzZW5kZXIsIGJhc2VkIG9uIHRoZSBhY3RpdmUgY29uZmlndXJh dGlvbiwNCiAgICAgICAgICAgIHNlbGVjdHMgYW4gU0EgdG8gdXNlIGFuZCBwdXRzIHRoZSBjb3Jy ZWN0IFNBIElEIHZhbHVlIGFzc29jaWF0ZWQNCiAgICAgICAgICAgIHdpdGggdGhlIFNBIGluIHRo ZSBMRFAgSGVsbG8gbWVzc2FnZS4gSWYgbXVsdGlwbGUgdmFsaWQgYW5kIGFjdGl2ZQ0KICAgICAg ICAgICAgTERQIFNBcyBleGlzdCBmb3IgYSBnaXZlbiBpbnRlcmZhY2UsIHRoZSBzZW5kZXIgbWF5 IHVzZSBhbnkgb2YNCiAgICAgICAgICAgIHRob3NlIFNBcyB0byBwcm90ZWN0IHRoZSBwYWNrZXQu PHZzcGFjZSBibGFua0xpbmVzPSIxIi8+IFVzaW5nIFNBDQogICAgICAgICAgICBJRHMgbWFrZXMg Y2hhbmdpbmcga2V5cyB3aGlsZSBtYWludGFpbmluZyBwcm90b2NvbCBvcGVyYXRpb24NCiAgICAg ICAgICAgIGNvbnZlbmllbnQuIEVhY2ggU0EgSUQgc3BlY2lmaWVzIHR3byBpbmRlcGVuZGVudCBw YXJ0cywgdGhlDQogICAgICAgICAgICBhdXRoZW50aWNhdGlvbiBhbGdvcml0aG0gYW5kIHRoZSBh dXRoZW50aWNhdGlvbiBrZXksIGFzIGV4cGxhaW5lZA0KICAgICAgICAgICAgYmVsb3cuIDx2c3Bh Y2UgYmxhbmtMaW5lcz0iMSIvPiBOb3JtYWxseSwgYW4gaW1wbGVtZW50YXRpb24gd291bGQNCiAg ICAgICAgICAgIGFsbG93IHRoZSBuZXR3b3JrIG9wZXJhdG9yIHRvIGNvbmZpZ3VyZSBhIHNldCBv ZiBrZXlzIGluIGEga2V5DQogICAgICAgICAgICBjaGFpbiwgd2l0aCBlYWNoIGtleSBpbiB0aGUg Y2hhaW4gaGF2aW5nIGZpeGVkIGxpZmV0aW1lLiBUaGUNCiAgICAgICAgICAgIGFjdHVhbCBvcGVy YXRpb24gb2YgdGhlc2UgbWVjaGFuaXNtcyBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzDQog ICAgICAgICAgICBkb2N1bWVudC48dnNwYWNlIGJsYW5rTGluZXM9IjEiLz4gTm90ZSB0aGF0IGVh Y2ggU0EgSUQgY2FuDQogICAgICAgICAgICBpbmRpY2F0ZSBhIGtleSB3aXRoIGEgZGlmZmVyZW50 IGF1dGhlbnRpY2F0aW9uIGFsZ29yaXRobS4gVGhpcw0KICAgICAgICAgICAgYWxsb3dzIHRoZSBp bnRyb2R1Y3Rpb24gb2YgbmV3IGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbXMgd2l0aG91dA0KICAg ICAgICAgICAgZGlzcnVwdGluZyBleGlzdGluZyBMRFAgc2Vzc2lvbnMuPC90Pg0KDQogICAgICAg ICAgICA8dD5BdXRoZW50aWNhdGlvbiBBbGdvcml0aG0gPHZzcGFjZSBibGFua0xpbmVzPSIxIi8+ IFRoaXMNCiAgICAgICAgICAgIHNpZ25pZmllcyB0aGUgYXV0aGVudGljYXRpb24gYWxnb3JpdGht IHRvIGJlIHVzZWQgd2l0aCB0aGUgTERQIFNBLg0KICAgICAgICAgICAgVGhpcyBpbmZvcm1hdGlv biBpcyBuZXZlciBzZW50IGluIGNsZWFyIHRleHQgb3ZlciB0aGUgd2lyZS4NCiAgICAgICAgICAg IEJlY2F1c2UgdGhpcyBpbmZvcm1hdGlvbiBpcyBub3Qgc2VudCBvbiB0aGUgd2lyZSwgdGhlIGlt cGxlbWVudGVyDQogICAgICAgICAgICBjaG9vc2VzIGFuIGltcGxlbWVudGF0aW9uIHNwZWNpZmlj IHJlcHJlc2VudGF0aW9uIGZvciB0aGlzDQogICAgICAgICAgICBpbmZvcm1hdGlvbi4gPHZzcGFj ZSBibGFua0xpbmVzPSIxIi8+IEN1cnJlbnRseSwgdGhlIGZvbGxvd2luZw0KICAgICAgICAgICAg YWxnb3JpdGhtcyBhcmUgc3VwcG9ydGVkOiA8dnNwYWNlIGJsYW5rTGluZXM9IjEiLz4gSE1BQy1T SEEtMSwNCiAgICAgICAgICAgIEhNQUMtU0hBLTI1NiwgSE1BQy1TSEEtMzg0LCBhbmQgSE1BQy1T SEEtNTEyLjwvdD4NCg0KICAgICAgICAgICAgPHQ+QXV0aGVudGljYXRpb24gS2V5IDx2c3BhY2Ug YmxhbmtMaW5lcz0iMSIvPiBUaGlzIHZhbHVlIGRlbm90ZXMNCiAgICAgICAgICAgIHRoZSBjcnlw dG9ncmFwaGljIGF1dGhlbnRpY2F0aW9uIGtleSBhc3NvY2lhdGVkIHdpdGggdGhlIExEUCBTQS4N CiAgICAgICAgICAgIFRoZSBsZW5ndGggb2YgdGhpcyBrZXkgaXMgdmFyaWFibGUgYW5kIGRlcGVu ZHMgdXBvbiB0aGUNCiAgICAgICAgICAgIGF1dGhlbnRpY2F0aW9uIGFsZ29yaXRobSBzcGVjaWZp ZWQgYnkgdGhlIExEUCBTQS48L3Q+DQoNCiAgICAgICAgICAgIDx0PktleVN0YXJ0QWNjZXB0IDx2 c3BhY2UgYmxhbmtMaW5lcz0iMSIvPiBUaGUgdGltZSB0aGF0IHRoaXMgTERQDQogICAgICAgICAg ICByb3V0ZXIgd2lsbCBhY2NlcHQgcGFja2V0cyB0aGF0IGhhdmUgYmVlbiBjcmVhdGVkIHdpdGgg dGhpcyBMRFANCiAgICAgICAgICAgIFNlY3VyaXR5IEFzc29jaWF0aW9uLjwvdD4NCg0KICAgICAg ICAgICAgPHQ+S2V5U3RhcnRHZW5lcmF0ZSA8dnNwYWNlIGJsYW5rTGluZXM9IjEiLz4gVGhlIHRp bWUgdGhhdCB0aGlzDQogICAgICAgICAgICBMRFAgcm91dGVyIHdpbGwgYmVnaW4gdXNpbmcgdGhp cyBMRFAgU2VjdXJpdHkgQXNzb2NpYXRpb24gZm9yIExEUA0KICAgICAgICAgICAgSGVsbG8gbWVz c2FnZSBnZW5lcmF0aW9uLjwvdD4NCg0KICAgICAgICAgICAgPHQ+S2V5U3RvcEdlbmVyYXRlIDx2 c3BhY2UgYmxhbmtMaW5lcz0iMSIvPiBUaGUgdGltZSB0aGF0IHRoaXMgTERQDQogICAgICAgICAg ICByb3V0ZXIgd2lsbCBzdG9wIHVzaW5nIHRoaXMgTERQIFNlY3VyaXR5IEFzc29jaWF0aW9uIGZv ciBMRFAgSGVsbG8NCiAgICAgICAgICAgIG1lc3NhZ2UgZ2VuZXJhdGlvbi48L3Q+DQoNCiAgICAg ICAgICAgIDx0PktleVN0b3BBY2NlcHQgPHZzcGFjZSBibGFua0xpbmVzPSIxIi8+IFRoZSB0aW1l IHRoYXQgdGhpcyBMRFANCiAgICAgICAgICAgIHJvdXRlciB3aWxsIHN0b3AgYWNjZXB0aW5nIHBh Y2tldHMgZ2VuZXJhdGVkIHdpdGggdGhpcyBMRFANCiAgICAgICAgICAgIFNlY3VyaXR5IEFzc29j aWF0aW9uLjwvdD4NCiAgICAgICAgICA8L2xpc3Q+PC90Pg0KDQogICAgICAgIDx0PkluIG9yZGVy IHRvIGFjaGlldmUgc21vb3RoIGtleSB0cmFuc2l0aW9uLCBLZXlTdGFydEFjY2VwdCBTSE9VTEQg YmUNCiAgICAgICAgbGVzcyB0aGFuIEtleVN0YXJ0R2VuZXJhdGUgYW5kIEtleVN0b3BHZW5lcmF0 ZSBTSE9VTEQgYmUgbGVzcyB0aGFuDQogICAgICAgIEtleVN0b3BBY2NlcHQuIElmIEtleVN0YXJ0 R2VuZXJhdGUgb3IgS2V5U3RhcnRBY2NlcHQgYXJlIGxlZnQNCiAgICAgICAgdW5zcGVjaWZpZWQs IHRoZSB0aW1lIHdpbGwgZGVmYXVsdCB0byAwIGFuZCB0aGUga2V5IHdpbGwgYmUgdXNlZA0KICAg ICAgICBpbW1lZGlhdGVseS4gSWYgS2V5U3RvcEdlbmVyYXRlIG9yIEtleVN0b3BBY2NlcHQgYXJl IGxlZnQgdW5zcGVjaWZpZWQsDQogICAgICAgIHRoZSB0aW1lIHdpbGwgZGVmYXVsdCB0byBpbmZp bml0eSBhbmQgdGhlIGtleSdzIGxpZmV0aW1lIHdpbGwgYmUNCiAgICAgICAgaW5maW5pdGUuIFdo ZW4gYSBuZXcga2V5IHJlcGxhY2VzIGFuIG9sZCwgdGhlIEtleVN0YXJ0R2VuZXJhdGUgdGltZQ0K ICAgICAgICBmb3IgdGhlIG5ldyBrZXkgTVVTVCBiZSBsZXNzIHRoYW4gb3IgZXF1YWwgdG8gdGhl IEtleVN0b3BHZW5lcmF0ZSB0aW1lDQogICAgICAgIG9mIHRoZSBvbGQga2V5LiBBbnkgdW5zcGVj aWZpZWQgdmFsdWVzIGFyZSBlbmNvZGVkIGFzIFplcm8uPC90Pg0KDQogICAgICAgIDx0PktleSBz dG9yYWdlIFNIT1VMRCBwZXJzaXN0IGFjcm9zcyBhIHN5c3RlbSByZXN0YXJ0LCB3YXJtIG9yIGNv bGQsDQogICAgICAgIHRvIGF2b2lkIG9wZXJhdGlvbmFsIGlzc3Vlcy4gSW4gdGhlIGV2ZW50IHRo YXQgdGhlIGxhc3Qga2V5IGFzc29jaWF0ZWQNCiAgICAgICAgd2l0aCBhbiBpbnRlcmZhY2UgZXhw aXJlcywgaXQgaXMgdW5hY2NlcHRhYmxlIHRvIHJldmVydCB0byBhbg0KICAgICAgICB1bmF1dGhl bnRpY2F0ZWQgY29uZGl0aW9uLCBhbmQgbm90IGFkdmlzYWJsZSB0byBkaXNydXB0IHJvdXRpbmcu DQogICAgICAgIFRoZXJlZm9yZSwgdGhlIHJvdXRlciBTSE9VTEQgc2VuZCBhICJsYXN0IEF1dGhl bnRpY2F0aW9uIEtleQ0KICAgICAgICBleHBpcmF0aW9uIiBub3RpZmljYXRpb24gdG8gdGhlIG5l dHdvcmsgbWFuYWdlciBhbmQgdHJlYXQgdGhlIGtleSBhcw0KICAgICAgICBoYXZpbmcgYW4gaW5m aW5pdGUgbGlmZXRpbWUgdW50aWwgdGhlIGxpZmV0aW1lIGlzIGV4dGVuZGVkLCB0aGUga2V5IGlz DQogICAgICAgIGRlbGV0ZWQgYnkgbmV0d29yayBtYW5hZ2VtZW50LCBvciBhIG5ldyBrZXkgaXMg Y29uZmlndXJlZDwvdD4NCiAgICAgIDwvc2VjdGlvbj4NCg0KICAgICAgPHNlY3Rpb24gdGl0bGU9 IkNyeXB0b2dyYXBoaWMgQXV0aGVudGljYXRpb24gVExWIEVuY29kaW5nIj4NCiAgICAgICAgPGZp Z3VyZSBhbGlnbj0ibGVmdCI+DQogICAgICAgICAgPGFydHdvcms+PCFbQ0RBVEFbDQogICAgMCAg ICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAg MyAgDQogICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMg NCA1IDYgNyA4IDkgMCAxDQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfDB8MHwgICAgICAgIEF1dGggKFRCRDEp ICAgICAgICB8ICAgICAgICAgICAgIExlbmd0aCAgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQog ICB8ICAgICAgICAgICAgICAgICAgU2VjdXJpdHkgQXNzb2NpYXRpb24gSUQgICAgICAgICAgICAg ICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgICAgICAgQ3J5cHRvZ3JhcGhpYyBTZXF1ZW5j ZSBOdW1iZXIgKEhpZ2ggT3JkZXIgMzIgQml0cykgICAgICB8DQogICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAg ICAgICBDcnlwdG9ncmFwaGljIFNlcXVlbmNlIE51bWJlciAoTG93IE9yZGVyIDMyIEJpdHMpICAg ICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rDQogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgfCAgICAgICAgICAgICAgICBBdXRo ZW50aWNhdGlvbiBEYXRhIChWYXJpYWJsZSkgICAgICAgICAgICAgICAgIHwNCiAgIH4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB+ DQogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfA0KICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQpdXT48L2FydHdvcms+DQog ICAgICAgIDwvZmlndXJlPg0KDQogICAgICAgIDx0Pi0gVHlwZTogVEJEMSwgQ3J5cHRvZ3JhcGhp YyBBdXRoZW50aWNhdGlvbjwvdD4NCg0KICAgICAgICA8dD4tIExlbmd0aDogU3BlY2lmeWluZyB0 aGUgbGVuZ3RoIGluIG9jdGV0cyBvZiB0aGUgdmFsdWUgZmllbGQuPC90Pg0KDQogICAgICAgIDx0 Pi0gU2VjdXJpdHkgQXNzb2NpYXRpb24gSUQ6IDMyIGJpdCBmaWVsZCB0aGF0IG1hcHMgdG8gdGhl DQogICAgICAgIGF1dGhlbnRpY2F0aW9uIGFsZ29yaXRobSBhbmQgdGhlIHNlY3JldCBrZXkgdXNl ZCB0byBjcmVhdGUgdGhlIG1lc3NhZ2UNCiAgICAgICAgZGlnZXN0IGNhcnJpZWQgaW4gTERQIHBh eWxvYWQuPC90Pg0KDQogICAgICAgIDx0PlRob3VnaCB0aGUgU0EgSUQgaW1wbGllcyB0aGUgYWxn b3JpdGhtLCB0aGUgSE1BQyBvdXRwdXQgc2l6ZSBzaG91bGQNCiAgICAgICAgbm90IGJlIHVzZWQg YnkgaW1wbGVtZW50ZXJzIGFzIGFuIGltcGxpY2l0IGhpbnQsIGJlY2F1c2UgYWRkaXRpb25hbA0K ICAgICAgICBhbGdvcml0aG1zIG1heSBiZSBkZWZpbmVkIGluIHRoZSBmdXR1cmUgdGhhdCBoYXZl IHRoZSBzYW1lIG91dHB1dA0KICAgICAgICBzaXplLjwvdD4NCg0KICAgICAgICA8dD4tIENyeXB0 b2dyYXBoaWMgU2VxdWVuY2UgTnVtYmVyOiA2NC1iaXQgc3RyaWN0bHkgaW5jcmVhc2luZw0KICAg ICAgICBzZXF1ZW5jZSBudW1iZXIgdGhhdCBpcyB1c2VkIHRvIGd1YXJkIGFnYWluc3QgcmVwbGF5 IGF0dGFja3MuIFRoZQ0KICAgICAgICA2NC1iaXQgc2VxdWVuY2UgbnVtYmVyIE1VU1QgYmUgaW5j cmVtZW50ZWQgZm9yIGV2ZXJ5IExEUCBIZWxsbyBwYWNrZXQNCiAgICAgICAgc2VudCBieSB0aGUg TERQIHJvdXRlci4gVXBvbiByZWNlcHRpb24sIHRoZSBzZXF1ZW5jZSBudW1iZXIgTVVTVCBiZQ0K ICAgICAgICBncmVhdGVyIHRoYW4gdGhlIHNlcXVlbmNlIG51bWJlciBpbiB0aGUgbGFzdCBMRFAg SGVsbG8gcGFja2V0IGFjY2VwdGVkDQogICAgICAgIGZyb20gdGhlIHNlbmRpbmcgTERQIG5laWdo Ym9yLiBPdGhlcndpc2UsIHRoZSBMRFAgcGFja2V0IGlzIGNvbnNpZGVyZWQNCiAgICAgICAgYSBy ZXBsYXllZCBwYWNrZXQgYW5kIGRyb3BwZWQuPC90Pg0KDQogICAgICAgIDx0PkxEUCByb3V0ZXJz IGltcGxlbWVudGluZyB0aGlzIHNwZWNpZmljYXRpb24gTVVTVCB1c2UgZXhpc3RpbmcNCiAgICAg ICAgbWVjaGFuaXNtcyB0byBwcmVzZXJ2ZSB0aGUgc2VxdWVuY2UgbnVtYmVyJ3Mgc3RyaWN0bHkg aW5jcmVhc2luZw0KICAgICAgICBwcm9wZXJ0eSBmb3IgdGhlIGRlcGxveWVkIGxpZmUgb2YgdGhl IExEUCByb3V0ZXIgKGluY2x1ZGluZyBjb2xkDQogICAgICAgIHJlc3RhcnRzKS4gT25lIG1lY2hh bmlzbSBmb3IgYWNjb21wbGlzaGluZyB0aGlzIGNvdWxkIGJlIHRvIHVzZSB0aGUNCiAgICAgICAg aGlnaC1vcmRlciAzMiBiaXRzIG9mIHRoZSBzZXF1ZW5jZSBudW1iZXIgYXMgYSBib290IGNvdW50 IHRoYXQgaXMNCiAgICAgICAgaW5jcmVtZW50ZWQgYW55dGltZSB0aGUgTERQIHJvdXRlciBsb3Nl cyBpdHMgc2VxdWVuY2UgbnVtYmVyIHN0YXRlLg0KICAgICAgICBUZWNobmlxdWVzIHN1Y2ggYXMg c2VxdWVuY2UgbnVtYmVyIHNwYWNlIHBhcnRpdGlvbmluZyBkZXNjcmliZWQgYWJvdmUNCiAgICAg ICAgb3Igbm9uLXZvbGF0aWxlIHN0b3JhZ2UgcHJlc2VydmF0aW9uIGNhbiBiZSB1c2VkIGJ1dCBh cmUgYmV5b25kIHRoZQ0KICAgICAgICBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24uIFNlcXVl bmNlIG51bWJlciB3cmFwIGlzIGRlc2NyaWJlZCBpbg0KICAgICAgICA8eHJlZiB0YXJnZXQ9IlNl cXVlbmNlLVdyYXAiLz4uPC90Pg0KDQogICAgICAgIDx0Pi0gQXV0aGVudGljYXRpb24gRGF0YTo8 L3Q+DQoNCiAgICAgICAgPHQ+VGhpcyBmaWVsZCBjYXJyaWVzIHRoZSBkaWdlc3QgY29tcHV0ZWQg YnkgdGhlIENyeXB0b2dyYXBoaWMNCiAgICAgICAgQXV0aGVudGljYXRpb24gYWxnb3JpdGhtIGlu IHVzZS4gVGhlIGxlbmd0aCBvZiB0aGUgQXV0aGVudGljYXRpb24gRGF0YQ0KICAgICAgICB2YXJp ZXMgYmFzZWQgb24gdGhlIGNyeXB0b2dyYXBoaWMgYWxnb3JpdGhtIGluIHVzZSwgd2hpY2ggaXMg c2hvd24gYXMNCiAgICAgICAgYmVsb3c6PC90Pg0KDQogICAgICAgIDxmaWd1cmUgYWxpZ249Imxl ZnQiPg0KICAgICAgICAgIDxhcnR3b3JrPjwhW0NEQVRBWw0KQXV0aCB0eXBlICAgICAgICBMZW5n dGgNCi0tLS0tLS0tLS0tLS0tLSAgLS0tLS0tLS0tLQ0KSE1BQy1TSEExICAgICAgICAyMCBieXRl cw0KSE1BQy1TSEEtMjU2ICAgICAzMiBieXRlcw0KSE1BQy1TSEEtMzg0ICAgICA0OCBieXRlcw0K SE1BQy1TSEEtNTEyICAgICA2NCBieXRlcw0KXV0+PC9hcnR3b3JrPg0KICAgICAgICA8L2ZpZ3Vy ZT4NCiAgICAgIDwvc2VjdGlvbj4NCg0KICAgICAgPHNlY3Rpb24gYW5jaG9yPSJTZXF1ZW5jZS1X cmFwIiB0aXRsZT0iU2VxdWVuY2UgTnVtYmVyIFdyYXAiPg0KICAgICAgICA8dD5XaGVuIGluY3Jl bWVudGluZyB0aGUgc2VxdWVuY2UgbnVtYmVyIGZvciBlYWNoIHRyYW5zbWl0dGVkIExEUA0KICAg ICAgICBwYWNrZXQsIHRoZSBzZXF1ZW5jZSBudW1iZXIgc2hvdWxkIGJlIHRyZWF0ZWQgYXMgYW4g dW5zaWduZWQgNjQtYml0DQogICAgICAgIHZhbHVlLiBJZiB0aGUgbG93ZXIgb3JkZXIgMzItYml0 IHZhbHVlIHdyYXBzLCB0aGUgaGlnaGVyIG9yZGVyIDMyLWJpdA0KICAgICAgICB2YWx1ZSBzaG91 bGQgYmUgaW5jcmVtZW50ZWQgYW5kIHNhdmVkIGluIG5vbi12b2xhdGlsZSBzdG9yYWdlLiBJZiB0 aGUNCiAgICAgICAgTERQIHJvdXRlciBpcyBkZXBsb3llZCBsb25nIGVub3VnaCB0aGF0IHRoZSA2 NC1iaXQgc2VxdWVuY2UgbnVtYmVyDQogICAgICAgIHdyYXBzLCBhbGwga2V5cywgaW5kZXBlbmRl bnQgb2Yga2V5IGRpc3RyaWJ1dGlvbiBtZWNoYW5pc20gTVVTVCBiZQ0KICAgICAgICByZXNldC4g VGhpcyBpcyBkb25lIHRvIGF2b2lkIHRoZSBwb3NzaWJpbGl0eSBvZiByZXBsYXkgYXR0YWNrcy4g T25jZQ0KICAgICAgICB0aGUga2V5cyBoYXZlIGJlZW4gY2hhbmdlZCwgdGhlIGhpZ2hlciBvcmRl ciBzZXF1ZW5jZSBudW1iZXIgY2FuIGJlDQogICAgICAgIHJlc2V0IHRvIDAgYW5kIHNhdmVkIHRv IG5vbi12b2xhdGlsZSBzdG9yYWdlLjwvdD4NCiAgICAgIDwvc2VjdGlvbj4NCiAgICA8L3NlY3Rp b24+DQoNCiAgICA8c2VjdGlvbiBhbmNob3I9IkNyeXB0b19BdXRoX1Byb2NlZHVyZSINCiAgICAg ICAgICAgICB0aXRsZT0iQ3J5cHRvZ3JhcGhpYyBBdXRoZW50aWNhdGlvbiBQcm9jZWR1cmUiPg0K ICAgICAgPHQ+QXMgbm90ZWQgZWFybGllciwgdGhlIFNlY3VyaXR5IEFzc29jaWF0aW9uIElEIG1h cHMgdG8gdGhlDQogICAgICBhdXRoZW50aWNhdGlvbiBhbGdvcml0aG0gYW5kIHRoZSBzZWNyZXQg a2V5IHVzZWQgdG8gZ2VuZXJhdGUgYW5kIHZlcmlmeQ0KICAgICAgdGhlIG1lc3NhZ2UgZGlnZXN0 LiBUaGlzIHNwZWNpZmljYXRpb24gZGlzY3Vzc2VzIHRoZSBjb21wdXRhdGlvbiBvZiBMRFANCiAg ICAgIENyeXB0b2dyYXBoaWMgQXV0aGVudGljYXRpb24gZGF0YSB3aGVuIGFueSBvZiB0aGUgTklT VCBTSFMgZmFtaWx5IG9mDQogICAgICBhbGdvcml0aG1zIGlzIHVzZWQgaW4gdGhlIEhhc2hlZCBN ZXNzYWdlIEF1dGhlbnRpY2F0aW9uIENvZGUgKEhNQUMpDQogICAgICBtb2RlLiA8dnNwYWNlIGJs YW5rTGluZXM9IjEiLz4gVGhlIGN1cnJlbnRseSB2YWxpZCBhbGdvcml0aG1zIChpbmNsdWRpbmcN CiAgICAgIG1vZGUpIGZvciBMRFAgQ3J5cHRvZ3JhcGhpYyBBdXRoZW50aWNhdGlvbiBpbmNsdWRl OiA8dnNwYWNlDQogICAgICBibGFua0xpbmVzPSIxIi8+IEhNQUMtU0hBLTEsIEhNQUMtU0hBLTI1 NiwgSE1BQy1TSEEtMzg0IGFuZCBITUFDLVNIQS01MTINCiAgICAgIDx2c3BhY2UgYmxhbmtMaW5l cz0iMSIvPiBPZiB0aGUgYWJvdmUsIGltcGxlbWVudGF0aW9ucyBvZiB0aGlzDQogICAgICBzcGVj aWZpY2F0aW9uIE1VU1QgaW5jbHVkZSBzdXBwb3J0IGZvciBhdCBsZWFzdCBITUFDLVNIQS0yNTYg YW5kIFNIT1VMRA0KICAgICAgaW5jbHVkZSBzdXBwb3J0IGZvciBITUFDLVNIQS0xIGFuZCBNQVkg YWxzbyBpbmNsdWRlIHN1cHBvcnQgZm9yDQogICAgICBITUFDLVNIQS0zODQgYW5kIEhNQUMtU0hB LTUxMi48dnNwYWNlIGJsYW5rTGluZXM9IjEiLz4gSW1wbGVtZW50YXRpb25zDQogICAgICBvZiB0 aGlzIHN0YW5kYXJkIE1VU1QgdXNlIEhNQUMtU0hBLTI1NiBhcyB0aGUgZGVmYXVsdCBhdXRoZW50 aWNhdGlvbg0KICAgICAgYWxnb3JpdGhtLjwvdD4NCiAgICA8L3NlY3Rpb24+DQoNCiAgICA8c2Vj dGlvbiBhbmNob3I9IkNyb3NzLVByb3RvY29sIiB0aXRsZT0iQ3Jvc3MgUHJvdG9jb2wgQXR0YWNr IE1pdGlnYXRpb24iPg0KICAgICAgPHQ+SW4gb3JkZXIgdG8gcHJldmVudCBjcm9zcyBwcm90b2Nv bCByZXBsYXkgYXR0YWNrcyBmb3IgcHJvdG9jb2xzDQogICAgICBzaGFyaW5nIGNvbW1vbiBrZXlz LCB0aGUgdHdvIG9jdGV0IExEUCBDcnlwdG9ncmFwaGljIFByb3RvY29sIElEIGlzDQogICAgICBh cHBlbmRlZCB0byB0aGUgYXV0aGVudGljYXRpb24ga2V5IHByaW9yIHRvIHVzZSAocmVmZXIgdG8g U2VjdGlvbiA4KS4NCiAgICAgIE90aGVyIHByb3RvY29scyB1c2luZyB0aGUgY29tbW9uIGtleSBz aW1pbGFybHkgYXBwZW5kIHRoZWlyIG93bg0KICAgICAgQ3J5cHRvZ3JhcGhpYyBQcm90b2NvbCBJ RHMgdG8gdGhlaXIga2V5cyBwcmlvciB0byB1c2UgdGh1cyBlbnN1cmluZyB0aGF0DQogICAgICBh IGRpZmZlcmVudCBrZXkgdmFsdWUgaXMgdXNlZCBmb3IgZWFjaCBwcm90b2NvbC48L3Q+DQogICAg PC9zZWN0aW9uPg0KDQogICAgPHNlY3Rpb24gdGl0bGU9IkNyeXB0b2dyYXBoaWMgQXNwZWN0cyI+ DQogICAgICA8dD5JbiB0aGUgYWxnb3JpdGhtIGRlc2NyaXB0aW9uIGJlbG93LCB0aGUgZm9sbG93 aW5nIG5vbWVuY2xhdHVyZSBpcyB1c2VkOjwvdD4NCiAgICAgIDwhLS0gTm8gbmVlZCB0byByZWZl cmVuY2UgRklQUyB3aGVuIHdlIGhhdmUgYW4gUkZDIGZvciBITUFDIC0tPg0KDQogICAgICA8dD5I IGlzIHRoZSBzcGVjaWZpYyBoYXNoaW5nIGFsZ29yaXRobSAoZS5nLiBTSEEtMjU2KS4gPHZzcGFj ZQ0KICAgICAgYmxhbmtMaW5lcz0iMSIvPiBLIGlzIHRoZSBBdXRoZW50aWNhdGlvbiBLZXkgZnJv bSB0aGUgTERQIHNlY3VyaXR5DQogICAgICBhc3NvY2lhdGlvbi48dnNwYWNlIGJsYW5rTGluZXM9 IjEiLz4gS3MgaXMgYSBQcm90b2NvbCBTcGVjaWZpYw0KICAgICAgQXV0aGVudGljYXRpb24gS2V5 IG9idGFpbmVkIGJ5IGFwcGVuZGluZyBBdXRoZW50aWNhdGlvbiBLZXkgKEspIHdpdGggdGhlDQog ICAgICB0d28tb2N0ZXQgTERQIENyeXB0b2dyYXBoaWMgUHJvdG9jb2wgSUQgLjx2c3BhY2UNCiAg ICAgIGJsYW5rTGluZXM9IjEiLz4gS28gaXMgdGhlIGNyeXB0b2dyYXBoaWMga2V5IHVzZWQgd2l0 aCB0aGUgaGFzaA0KICAgICAgYWxnb3JpdGhtLjwvdD4NCjwhLS0gUmVtb3ZlZCBwYXJhbWV0ZXJz IHRoYXQgYXJlIG5vdCBuZWVkZWQgaWYgSE1BQyBpcyBhIGJsYWNrIGJveCAtLT4NCiAgICAgIDx0 PkwgaXMgdGhlIGxlbmd0aCBvZiB0aGUgaGFzaCwgbWVhc3VyZWQgaW4gb2N0ZXRzIHJhdGhlciB0 aGFuDQogICAgICBiaXRzLjx2c3BhY2UgYmxhbmtMaW5lcz0iMSIvPiBBdXRoVGFnIGlzIGEgdmFs dWUgd2hpY2ggaXMgdGhlIHNhbWUgbGVuZ3RoDQogICAgICA8IS0tIHJlbmFtZWQgQXBhZCB0byBB dXRoVGFnLCBiZWNhdXNlIGl0IGlzIG5vdCBhIHBhZGRpbmcgc3RyaW5nIC0tPg0KICAgICAgYXMg dGhlIGhhc2ggb3V0cHV0LiBJbiBjYXNlIG9mIElQdjQsIHRoZSBmaXJzdCA0DQogICAgICBvY3Rl dHMgY29udGFpbiB0aGUgSVB2NCBzb3VyY2UgYWRkcmVzcyBmb2xsb3dlZCBieSB0aGUgaGV4YWRl Y2ltYWwgdmFsdWUNCiAgICAgIDB4ODc4RkUxRjMgcmVwZWF0ZWQgKEwtNCkvNCB0aW1lcy4gSW4g Y2FzZSBvZiBJUHY2LCB0aGUgZmlyc3QgMTYgb2N0ZXRzDQogICAgICBjb250YWluIHRoZSBJUHY2 IHNvdXJjZSBhZGRyZXNzIGZvbGxvd2VkIGJ5IHRoZSBoZXhhZGVjaW1hbCB2YWx1ZQ0KICAgICAg MHg4NzhGRTFGMyByZXBlYXRlZCAoTC0xNikvNCB0aW1lcy4gVGhpcyBpbXBsaWVzIHRoYXQgaGFz aCBvdXRwdXQgaXMNCiAgICAgIGFsd2F5cyBhIGxlbmd0aCBvZiBhdCBsZWFzdCAxNiBvY3RldHMu IDx2c3BhY2UgYmxhbmtMaW5lcz0iMSIvPjwvdD4NCg0KICAgICAgPHNlY3Rpb24gdGl0bGU9IlBy ZXBhcmluZyB0aGUgQ3J5cHRvZ3JhcGhpYyBLZXkiPg0KICAgICAgICA8dD5UaGUgTERQIENyeXB0 b2dyYXBoaWMgUHJvdG9jb2wgSUQgaXMgYXBwZW5kZWQgdG8gdGhlIEF1dGhlbnRpY2F0aW9uDQog ICAgICAgIEtleSAoSykgeWllbGRpbmcgYSBQcm90b2NvbCBTcGVjaWZpYyBBdXRoZW50aWNhdGlv biBLZXkgKEtzKS4gSW4gdGhpcw0KICAgICAgICBhcHBsaWNhdGlvbiwgS28gaXMgYWx3YXlzIEwg b2N0ZXRzIGxvbmcuDQoNCglLZXlzIHRoYXQgYXJlIGxvbmdlciB0aGFuIHRoZSBiaXQgbGVuZ3Ro IG9mIHRoZSBoYXNoIGZ1bmN0aW9uIGFyZSBoYXNoZWQgdG8gZm9yY2UgdGhlbQ0KCXRvIHRoaXMg bGVuZ3RoLCBhcyB3ZSBkZXNjcmliZSBiZWxvdy4NCgk8IS0tIGRpc2N1c3Npb24gYWJvdXQgbG9u Z2VyIGtleXMgcmVtb3ZlZC4gd2UgYXJlIHNpbXBseSBmb2xsb3dpbmcgUkZDIDIxMDQuIC0tPg0K CUtzIGlzIGNvbXB1dGVkIGFzIGZvbGxvd3M6PC90Pg0KDQoNCiAgICAgICAgPHQ+SWYgdGhlIFBy b3RvY29sIFNwZWNpZmljIEF1dGhlbnRpY2F0aW9uIEtleSAoS3MpIGlzIEwgb2N0ZXRzIGxvbmcs DQogICAgICAgIHRoZW4gS28gaXMgZXF1YWwgdG8gS3MuIElmIHRoZSBQcm90b2NvbCBTcGVjaWZp YyBBdXRoZW50aWNhdGlvbiBLZXkNCiAgICAgICAgKEtzKSBpcyBtb3JlIHRoYW4gTCBvY3RldHMg bG9uZywgdGhlbiBLbyBpcyBzZXQgdG8gSChLcykuIElmIHRoZQ0KICAgICAgICBQcm90b2NvbCBT cGVjaWZpYyBBdXRoZW50aWNhdGlvbiBLZXkgKEtzKSBpcyBsZXNzIHRoYW4gTCBvY3RldHMgbG9u ZywNCiAgICAgICAgdGhlbiBLbyBpcyBzZXQgdG8gdGhlIFByb3RvY29sIFNwZWNpZmljIEF1dGhl bnRpY2F0aW9uIEtleSAoS3MpIHdpdGgNCiAgICAgICAgemVyb3MgYXBwZW5kZWQgdG8gdGhlIGVu ZCBvZiB0aGUgUHJvdG9jb2wgU3BlY2lmaWMgQXV0aGVudGljYXRpb24gS2V5DQogICAgICAgIChL cykgc3VjaCB0aGF0IEtvIGlzIEwgb2N0ZXRzIGxvbmcuPC90Pg0KCQ0KCTx0PiAgRm9yIGhpZ2hl ciBlbnRyb3B5IGl0IGlzIFJFQ09NTUVOREVEIHRoYXQgS2V5IEtzIA0KCXNob3VsZCBiZSBhdCBs ZWFzdCBMIG9jdGV0cyBsb25nLiANCgk8L3Q+DQoNCiAgICAgIDwvc2VjdGlvbj4NCg0KICAgICAg PHNlY3Rpb24gdGl0bGU9IkNvbXB1dGluZyB0aGUgSGFzaCI+DQogICAgICAgIDx0PkZpcnN0LCB0 aGUgQXV0aGVudGljYXRpb24gRGF0YSBmaWVsZCBpbiB0aGUgQ3J5cHRvZ3JhcGhpYw0KICAgICAg ICBBdXRoZW50aWNhdGlvbiBUTFYgaXMgZmlsbGVkIHdpdGggdGhlIHZhbHVlIEF1dGhUYWcuIFRo ZW4sIHRvIGNvbXB1dGUNCiAgICAgICAgSE1BQyBvdmVyIHRoZSBIZWxsbyBtZXNzYWdlIGl0IHBl cmZvcm1zOjwvdD4NCg0KICAgICAgICA8dD5BdXRoRGF0YSA9IEhNQUMoS28sIEhlbGxvIE1lc3Nh Z2UpPC90Pg0KDQogICAgICAgIDx0PkhlbGxvIE1lc3NhZ2UgcmVmZXJzIHRvIHRoZSBMRFAgSGVs bG8gbWVzc2FnZSBleGNsdWRpbmcgdGhlIElQDQogICAgICAgIGFuZCB0aGUgVURQIGhlYWRlcnMu PC90Pg0KICAgICAgPC9zZWN0aW9uPg0KDQogICAgICA8c2VjdGlvbiB0aXRsZT0iUmVzdWx0Ij4N CiAgICAgICAgPHQ+VGhlIHJlc3VsdGFudCBIYXNoIGJlY29tZXMgdGhlIEF1dGhlbnRpY2F0aW9u IERhdGEgdGhhdCBpcyBzZW50IGluDQogICAgICAgIHRoZSBBdXRoZW50aWNhdGlvbiBEYXRhIGZp ZWxkIG9mIHRoZSBDcnlwdG9ncmFwaGljIEF1dGhlbnRpY2F0aW9uIFRMVi4NCiAgICAgICAgVGhl IGxlbmd0aCBvZiB0aGUgQXV0aGVudGljYXRpb24gRGF0YSBmaWVsZCBpcyBhbHdheXMgaWRlbnRp Y2FsIHRvIHRoZQ0KICAgICAgICBtZXNzYWdlIGRpZ2VzdCBzaXplIG9mIHRoZSBzcGVjaWZpYyBo YXNoIGZ1bmN0aW9uIEggdGhhdCBpcyBiZWluZw0KICAgICAgICB1c2VkLjwvdD4NCg0KICAgICAg ICA8dD5UaGlzIGFsc28gbWVhbnMgdGhhdCB0aGUgdXNlIG9mIGhhc2ggZnVuY3Rpb25zIHdpdGgg bGFyZ2VyIG91dHB1dA0KICAgICAgICBzaXplcyB3aWxsIGFsc28gaW5jcmVhc2UgdGhlIHNpemUg b2YgdGhlIExEUCBtZXNzYWdlIGFzIHRyYW5zbWl0dGVkIG9uDQogICAgICAgIHRoZSB3aXJlLjwv dD4NCiAgICAgIDwvc2VjdGlvbj4NCiAgICA8L3NlY3Rpb24+DQoNCiAgICA8c2VjdGlvbiB0aXRs ZT0iUHJvY2Vzc2luZyBIZWxsbyBNZXNzYWdlIFVzaW5nIENyeXB0b2dyYXBoaWMgQXV0aGVudGlj YXRpb24iPg0KICAgICAgPHNlY3Rpb24gdGl0bGU9IlRyYW5zbWlzc2lvbiBVc2luZyBDcnlwdG9n cmFwaGljIEF1dGhlbnRpY2F0aW9uIj4NCiAgICAgICAgPHQ+UHJpb3IgdG8gdHJhbnNtaXR0aW5n IHRoZSBIZWxsbyBtZXNzYWdlLCB0aGUgTGVuZ3RoIGluIHRoZQ0KICAgICAgICBDcnlwdG9ncmFw aGljIEF1dGhlbnRpY2F0aW9uIFRMViBoZWFkZXIgaXMgc2V0IGFzIHBlciB0aGUNCiAgICAgICAg YXV0aGVudGljYXRpb24gYWxnb3JpdGhtIHRoYXQgaXMgYmVpbmcgdXNlZC4gSXQgaXMgc2V0IHRv IDI0IGZvcg0KICAgICAgICBITUFDLVNIQS0xLCAzNiBmb3IgSE1BQy1TSEEtMjU2LCA1MiBmb3Ig SE1BQy1TSEEtMzg0IGFuZCA2OCBmb3INCiAgICAgICAgSE1BQy1TSEEtNTEyLjwvdD4NCg0KICAg ICAgICA8dD5UaGUgU2VjdXJpdHkgQXNzb2NpYXRpb24gSUQgZmllbGQgaXMgc2V0IHRvIHRoZSBJ RCBvZiB0aGUgY3VycmVudA0KICAgICAgICBhdXRoZW50aWNhdGlvbiBrZXkuIFRoZSBITUFDIEhh c2ggaXMgY29tcHV0ZWQgYXMgZXhwbGFpbmVkIGluIFNlY3Rpb24NCiAgICAgICAgMy4gVGhlIHJl c3VsdGluZyBIYXNoIGlzIHN0b3JlZCBpbiB0aGUgQXV0aGVudGljYXRpb24gRGF0YSBmaWVsZCBw cmlvcg0KICAgICAgICB0byB0cmFuc21pc3Npb24uIFRoZSBhdXRoZW50aWNhdGlvbiBrZXkgTVVT VCBOT1QgYmUgY2FycmllZCBpbiB0aGUNCiAgICAgICAgcGFja2V0LjwvdD4NCiAgICAgIDwvc2Vj dGlvbj4NCg0KICAgICAgPHNlY3Rpb24gdGl0bGU9IlJlY2VpcHQgVXNpbmcgQ3J5cHRvZ3JhcGhp YyBBdXRoZW50aWNhdGlvbiI+DQogICAgICAgIDx0PlRoZSByZWNlaXZpbmcgTFNSIGFwcGxpZXMg YWNjZXB0YWJpbGl0eSBjcml0ZXJpYSBmb3IgcmVjZWl2ZWQNCiAgICAgICAgSGVsbG9zIHVzaW5n IGNyeXB0b2dyYXBoaWMgYXV0aGVudGljYXRpb24uIElmIHRoZSBDcnlwdG9ncmFwaGljDQogICAg ICAgIEF1dGhlbnRpY2F0aW9uIFRMViBpcyB1bmtub3duIHRvIHRoZSByZWNlaXZpbmcgTFNSLCB0 aGUgcmVjZWl2ZWQNCiAgICAgICAgcGFja2V0IE1VU1QgYmUgZGlzY2FyZGVkIGFjY29yZGluZyB0 byBTZWN0aW9uIDMuNS4xLjIuMiBvZiA8eHJlZg0KICAgICAgICB0YXJnZXQ9IlJGQzUwMzYiLz4u PC90Pg0KDQogICAgICAgIDx0PlRoZSByZWNlaXZpbmcgTFNSIGxvY2F0ZXMgdGhlIExEUCBTQSB1 c2luZyB0aGUgU2VjdXJpdHkgQXNzb2NpYXRpb24NCiAgICAgICAgSUQgZmllbGQgY2FycmllZCBp biB0aGUgbWVzc2FnZS4gSWYgdGhlIFNBIGlzIG5vdCBmb3VuZCwgb3IgaWYgdGhlIFNBDQogICAg ICAgIGlzIG5vdCB2YWxpZCBmb3IgcmVjZXB0aW9uIChpLmUuLCBjdXJyZW50IHRpbWUgJmx0OyBL ZXlTdGFydEFjY2VwdCBvcg0KICAgICAgICBjdXJyZW50IHRpbWUgJmd0Oz0gS2V5U3RvcEFjY2Vw dCksIExEUCBIZWxsbyBtZXNzYWdlIE1VU1QgYmUNCiAgICAgICAgZGlzY2FyZGVkLCBhbmQgYW4g ZXJyb3IgZXZlbnQgU0hPVUxEIGJlIGxvZ2dlZC48L3Q+DQoNCiAgICAgICAgPHQ+SWYgdGhlIGNy eXB0b2dyYXBoaWMgc2VxdWVuY2UgbnVtYmVyIGluIHRoZSBMRFAgcGFja2V0IGlzIGxlc3MgdGhh bg0KICAgICAgICBvciBlcXVhbCB0byB0aGUgbGFzdCBzZXF1ZW5jZSBudW1iZXIgcmVjZWl2ZWQg ZnJvbSB0aGUgc2FtZSBuZWlnaGJvciwNCiAgICAgICAgdGhlIExEUCBtZXNzYWdlIE1VU1QgYmUg ZGlzY2FyZGVkLCBhbmQgYW4gZXJyb3IgZXZlbnQgU0hPVUxEIGJlDQogICAgICAgIGxvZ2dlZC48 L3Q+DQoNCiAgICAgICAgPHQ+QmVmb3JlIHRoZSByZWNlaXZpbmcgTFNSIHBlcmZvcm1zIGFueSBw cm9jZXNzaW5nLCBpdCBuZWVkcyB0byBzYXZlDQogICAgICAgIHRoZSB2YWx1ZXMgb2YgdGhlIEF1 dGhlbnRpY2F0aW9uIERhdGEgZmllbGQuIFRoZSByZWNlaXZpbmcgTFNSIHRoZW4NCiAgICAgICAg cmVwbGFjZXMgdGhlIGNvbnRlbnRzIG9mIHRoZSBBdXRoZW50aWNhdGlvbiBEYXRhIGZpZWxkIHdp dGggQXV0aFRhZywNCiAgICAgICAgY29tcHV0ZXMgdGhlIEhhc2gsIHVzaW5nIHRoZSBhdXRoZW50 aWNhdGlvbiBrZXkgc3BlY2lmaWVkIGJ5IHRoZQ0KICAgICAgICByZWNlaXZlZCBTZWN1cml0eSBB c3NvY2lhdGlvbiBJRCBmaWVsZCwgYXMgZXhwbGFpbmVkIGluIFNlY3Rpb24gMy4gSWYNCiAgICAg ICAgdGhlIGxvY2FsbHkgY29tcHV0ZWQgSGFzaCBpcyBlcXVhbCB0byB0aGUgcmVjZWl2ZWQgdmFs dWUgb2YgdGhlDQogICAgICAgIEF1dGhlbnRpY2F0aW9uIERhdGEgZmllbGQsIHRoZSByZWNlaXZl ZCBwYWNrZXQgaXMgYWNjZXB0ZWQgZm9yIG90aGVyDQogICAgICAgIG5vcm1hbCBjaGVja3MgYW5k IHByb2Nlc3NpbmcgYXMgZGVzY3JpYmVkIGluIDx4cmVmIHRhcmdldD0iUkZDNTAzNiIvPi4NCiAg ICAgICAgT3RoZXJ3aXNlLCBpZiB0aGUgbG9jYWxseSBjb21wdXRlZCBIYXNoIGlzIG5vdCBlcXVh bCB0byB0aGUgcmVjZWl2ZWQNCiAgICAgICAgdmFsdWUgb2YgdGhlIEF1dGhlbnRpY2F0aW9uIERh dGEgZmllbGQsIHRoZSByZWNlaXZlZCBwYWNrZXQgTVVTVCBiZQ0KICAgICAgICBkaXNjYXJkZWQs IGFuZCBhbiBlcnJvciBldmVudCBTSE9VTEQgYmUgbG9nZ2VkLiBUaGUgZm9yZXNhaWQgbG9nZ2lu Zw0KICAgICAgICBuZWVkIHRvIGJlIGNhcmVmdWxseSByYXRlIGxpbWl0ZWQsIHNpbmNlIHdoaWxl IGEgTERQIHJvdXRlciBpcyB1bmRlcg0KICAgICAgICBhdHRhY2sgb2YgYSBzdG9ybSBvZiBzcG9v ZmVkIGhlbGxvcywgdGhlIHJlc291cmNlIHRha2luZyBmb3IgbG9nZ2luZw0KICAgICAgICBjb3Vs ZCBiZSBvdmVyd2VsbWluZy48L3Q+DQoNCiAgICAgICAgPHQ+QWZ0ZXIgdGhlIExEUCBIZWxsbyBt ZXNzYWdlIGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBhdXRoZW50aWNhdGVkLA0KICAgICAgICBpbXBs ZW1lbnRhdGlvbnMgTVVTVCBzdG9yZSB0aGUgNjQtYml0IGNyeXB0b2dyYXBoaWMgc2VxdWVuY2Ug bnVtYmVyDQogICAgICAgIGZvciB0aGUgSGVsbG8gbWVzc2FnZSByZWNlaXZlZCBmcm9tIHRoZSBu ZWlnaGJvci4gVGhlIHNhdmVkDQogICAgICAgIGNyeXB0b2dyYXBoaWMgc2VxdWVuY2UgbnVtYmVy cyB3aWxsIGJlIHVzZWQgZm9yIHJlcGxheSBjaGVja2luZyBmb3INCiAgICAgICAgc3Vic2VxdWVu dCBwYWNrZXRzIHJlY2VpdmVkIGZyb20gdGhlIG5laWdoYm9yLjwvdD4NCiAgICAgIDwvc2VjdGlv bj4NCiAgICA8L3NlY3Rpb24+DQoNCiAgICA8c2VjdGlvbiBhbmNob3I9IlNlY3VyaXR5IiB0aXRs ZT0iU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMiPg0KICAgICAgPHQ+U2VjdGlvbiAxIG9mIHRoaXMg ZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBzZWN1cml0eSBpc3N1ZXMgYXJpc2luZyBmcm9tDQogICAg ICB0aGUgdXNlIG9mIHVuYXV0aGVudGljYXRlZCBMRFAgSGVsbG8gbWVzc2FnZXMuIEluIG9yZGVy IHRvIGFkZHJlc3MgdGhvc2UNCiAgICAgIGlzc3VlcywgaXQgaXMgUkVDT01NRU5ERUQgdGhhdCBh bGwgZGVwbG95bWVudHMgdXNlIHRoZSBDcnlwdG9ncmFwaGljDQogICAgICBBdXRoZW50aWNhdGlv biBUTFYgdG8gYXV0aGVudGljYXRlIHRoZSBIZWxsbyBtZXNzYWdlcy48L3Q+DQoNCiAgICAgIDx0 PlRoZSBxdWFsaXR5IG9mIHRoZSBzZWN1cml0eSBwcm92aWRlZCBieSB0aGUgQ3J5cHRvZ3JhcGhp Yw0KICAgICAgQXV0aGVudGljYXRpb24gVExWIGRlcGVuZHMgY29tcGxldGVseSBvbiB0aGUgc3Ry ZW5ndGggb2YgdGhlDQogICAgICBjcnlwdG9ncmFwaGljIGFsZ29yaXRobSBpbiB1c2UsIHRoZSBz dHJlbmd0aCBvZiB0aGUga2V5IGJlaW5nIHVzZWQsIGFuZA0KICAgICAgdGhlIGNvcnJlY3QgaW1w bGVtZW50YXRpb24gb2YgdGhlIHNlY3VyaXR5IG1lY2hhbmlzbSBpbiBjb21tdW5pY2F0aW5nDQog ICAgICBMRFAgaW1wbGVtZW50YXRpb25zLiBBbHNvLCB0aGUgbGV2ZWwgb2Ygc2VjdXJpdHkgcHJv dmlkZWQgYnkgdGhlDQogICAgICBDcnlwdG9ncmFwaGljIEF1dGhlbnRpY2F0aW9uIFRMViB2YXJp ZXMgYmFzZWQgb24gdGhlIGF1dGhlbnRpY2F0aW9uIHR5cGUNCiAgICAgIHVzZWQuPC90Pg0KDQog ICAgICA8dD5JdCBzaG91bGQgYmUgbm90ZWQgdGhhdCB0aGUgYXV0aGVudGljYXRpb24gbWV0aG9k IGRlc2NyaWJlZCBpbiB0aGlzDQogICAgICBkb2N1bWVudCBpcyBub3QgYmVpbmcgdXNlZCB0byBh dXRoZW50aWNhdGUgdGhlIHNwZWNpZmljIG9yaWdpbmF0b3Igb2YgYQ0KICAgICAgcGFja2V0IGJ1 dCBpcyByYXRoZXIgYmVpbmcgdXNlZCB0byBjb25maXJtIHRoYXQgdGhlIHBhY2tldCBoYXMgaW5k ZWVkDQogICAgICBiZWVuIGlzc3VlZCBieSBhIHJvdXRlciB0aGF0IGhhcyBhY2Nlc3MgdG8gdGhl IEF1dGhlbnRpY2F0aW9uIEtleS48L3Q+DQoNCiAgICAgIDx0PkRlcGxveW1lbnRzIFNIT1VMRCB1 c2Ugc3VmZmljaWVudGx5IGxvbmcgYW5kIHJhbmRvbSB2YWx1ZXMgZm9yIHRoZQ0KICAgICAgQXV0 aGVudGljYXRpb24gS2V5IHNvIHRoYXQgZ3Vlc3NpbmcgYW5kIG90aGVyIGNyeXB0b2dyYXBoaWMg YXR0YWNrcyBvbg0KICAgICAgdGhlIGtleSBhcmUgbm90IGZlYXNpYmxlIGluIHRoZWlyIGVudmly b25tZW50cy4gSW4gc3VwcG9ydCBvZg0KICAgICAgdGhlc2UgcmVjb21tZW5kYXRpb25zLCBtYW5h Z2VtZW50IHN5c3RlbXMgU0hPVUxEIHN1cHBvcnQgaGV4YWRlY2ltYWwNCiAgICAgIGlucHV0IG9m IEF1dGhlbnRpY2F0aW9uIEtleXMuPC90Pg0KDQogICAgICA8dD5UaGUgbWVjaGFuaXNtIGRlc2Ny aWJlZCBoZXJlaW4gaXMgbm90IHBlcmZlY3QgLg0KICAgICAgSG93ZXZlciwgdGhpcyBtZWNoYW5p c20gaW50cm9kdWNlcyBhIHNpZ25pZmljYW50IGluY3JlYXNlIGluDQogICAgICB0aGUgZWZmb3J0 IHJlcXVpcmVkIGZvciBhbiBhZHZlcnNhcnkgdG8gc3VjY2Vzc2Z1bGx5IGF0dGFjayB0aGUgTERQ DQogICAgICBIZWxsbyBwcm90b2NvbCB3aGlsZSBub3QgY2F1c2luZyB1bmR1ZSBpbXBsZW1lbnRh dGlvbiwgZGVwbG95bWVudCwgb3INCiAgICAgIG9wZXJhdGlvbmFsIGNvbXBsZXhpdHkuPC90Pg0K ICAgIDwvc2VjdGlvbj4NCg0KICAgIDxzZWN0aW9uIGFuY2hvcj0iSUFOQSIgdGl0bGU9IklBTkEg Q29uc2lkZXJhdGlvbnMiPg0KICAgICAgPHQ+VGhlIElBTkEgaXMgcmVxdWVzdGVkIHRvIGFzIGFz c2lnbiBhIG5ldyBUTFYgZnJvbSB0aGUgIk11bHRpcHJvdG9jb2wNCiAgICAgIExhYmVsIFN3aXRj aGluZyBBcmNoaXRlY3R1cmUgKE1QTFMpIExhYmVsIFN3aXRjaGVkIFBhdGhzIChMU1BzKQ0KICAg ICAgUGFyYW1ldGVycyAtIFRMVnMiIHJlZ2lzdHJ5LCAiVExWcyBhbmQgc3ViLVRMVnMiIHN1Yi0g cmVnaXN0cnkuPC90Pg0KDQogICAgICA8dD48ZmlndXJlPg0KICAgICAgICAgIDxhcnR3b3JrPjwh W0NEQVRBW1ZhbHVlICAgTWVhbmluZyAgICAgICAgICAgICAgICAgICAgICAgICAgICBSZWZlcmVu Y2UNCi0tLS0tICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gICAtLS0tLS0tLS0N ClRCRDEgICAgIENyeXB0b2dyYXBoaWMgQXV0aGVudGljYXRpb24gVExWICAgdGhpcyBkb2N1bWVu dCAoc2VjdCAyLjMpDQpdXT48L2FydHdvcms+DQogICAgICAgIDwvZmlndXJlPjwvdD4NCg0KICAg ICAgPHQ+VGhlIElBTkEgaXMgYWxzbyByZXF1ZXN0ZWQgdG8gYXMgYXNzaWduIHZhbHVlIGZyb20g dGhlDQogICAgICAiQXV0aGVudGljYXRpb24gQ3J5cHRvZ3JhcGhpYyBQcm90b2NvbCBJRCIsIHJl Z2lzdHJ5IHVuZGVyIHRoZSAiS2V5aW5nDQogICAgICBhbmQgQXV0aGVudGljYXRpb24gZm9yIFJv dXRpbmcgUHJvdG9jb2xzIChLQVJQKSBQYXJhbWV0ZXJzIg0KICAgICAgY2F0ZWdvcnkuPC90Pg0K DQogICAgICA8dD48ZmlndXJlPg0KICAgICAgICAgIDxhcnR3b3JrPjwhW0NEQVRBWw0KVmFsdWUg ICBNZWFuaW5nICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJlZmVyZW5jZQ0KLS0tLS0gICAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAgIC0tLS0tLS0tLQ0KVEJEMiAgICAgTERQ IENyeXB0b2dyYXBoaWMgUHJvdG9jb2wgSUQgICAgICB0aGlzIGRvY3VtZW50IChzZWN0IDQpDQpd XT48L2FydHdvcms+DQogICAgICAgIDwvZmlndXJlPjwvdD4NCiAgICA8L3NlY3Rpb24+DQoNCiAg ICA8c2VjdGlvbiBhbmNob3I9IkFja25vd2xlZGdlbWVudHMiIHRpdGxlPSJBY2tub3dsZWRnZW1l bnRzIj4NCiAgICAgICA8dD4gV2UgYXJlIGluZGVidGVkIHRvIFlhcm9uIFNoZWZmZXIgd2hvIGhl bHBlZCB1cyBlbm9ybW91c2x5IA0KICAgICAgICAgICBpbiByZXdyaXRpbmcgdGhlIGRyYWZ0IHRv IGdldCByaWQgb2YgdGhlIHJlZHVuZGFudA0KCSAgIGNyeXB0byBtYXRoZW1hdGljcyB0aGF0IHdl IGhhZCBhZGRlZCBoZXJlLg0KICAgICAgIDwvdD4NCiAgICAgIDx0PldlIHdvdWxkIGFsc28gbGlr ZSB0byB0aGFuayBMaXUgWHVlaHUgZm9yIGhpcyB3b3JrIG9uIGJhY2tncm91bmQNCiAgICAgIGFu ZCBtb3RpdmF0aW9uIGZvciBMRFAgSGVsbG8gYXV0aGVudGljYXRpb24uIEFuZCBsYXN0IGJ1dCBu b3QgdGhlIGxlYXN0LA0KICAgICAgIHdlIHdvdWxkIGFsc28gdGhhbmsgQWRyaWFuIEZhcnJlbCwg RXJpYyBSb3NlbiwgU2FtIEhhcnRtYW4sIFN0ZXBoZW4gRmFycmVsbCwNCiAgICAgICAgRXJpYyBH cmF5LCBLYW1yYW4gUmF6YSBhbmQgQWNlZSBMaW5kZW0gZm9yIHRoZWlyIHZhbHVhYmxlIGNvbW1l bnRzLjwvdD4NCg0KICAgICAgPCEtLSBtaW5vciBjb3B5ZWRpdCAtLT4NCiAgICA8L3NlY3Rpb24+ DQogIDwvbWlkZGxlPg0KDQogIDxiYWNrPg0KICAgIDxyZWZlcmVuY2VzIHRpdGxlPSJOb3JtYXRp dmUgUmVmZXJlbmNlcyI+DQogICAgICA8P3JmYyBpbmNsdWRlPSJyZWZlcmVuY2UuUkZDLjIxMTki Pz4NCg0KICAgICAgPD9yZmMgaW5jbHVkZT0ncmVmZXJlbmNlLlJGQy41MDM2Jz8+DQoNCiAgICAg IDw/cmZjIGluY2x1ZGU9J3JlZmVyZW5jZS5SRkMuNTcwOSc/Pg0KDQogICAgICA8P3JmYyBpbmNs dWRlPSdyZWZlcmVuY2UuUkZDLjUzMTAnPz4NCg0KICAgICAgPD9yZmMgaW5jbHVkZT0ncmVmZXJl bmNlLlJGQy40ODIyJz8+DQoNCiAgICAgIDw/cmZjIGluY2x1ZGU9J3JlZmVyZW5jZS5SRkMuNzE2 Nic/Pg0KICAgICAgDQogICAgICA8P3JmYyBpbmNsdWRlPSdyZWZlcmVuY2UuUkZDLjIxMDQnPz4N Cg0KICAgICAgPHJlZmVyZW5jZSBhbmNob3I9IkZJUFMtMTgwLTMiPg0KICAgICAgICA8ZnJvbnQ+ DQogICAgICAgICAgPHRpdGxlPlNlY3VyZSBIYXNoIFN0YW5kYXJkIChTSFMpLCBGSVBTIFBVQiAx ODAtMzwvdGl0bGU+DQoNCiAgICAgICAgICA8YXV0aG9yIGZ1bGxuYW1lPSJOYXRpb25hbCBJbnN0 aXR1dGUgb2YgU3RhbmRhcmRzIGFuZCBUZWNobm9sb2d5Ij4NCiAgICAgICAgICAgIDxvcmdhbml6 YXRpb24vPg0KICAgICAgICAgIDwvYXV0aG9yPg0KDQogICAgICAgICAgPGRhdGUgbW9udGg9Ik9j dG9iZXIiIHllYXI9IjIwMDgiLz4NCiAgICAgICAgPC9mcm9udD4NCiAgICAgIDwvcmVmZXJlbmNl Pg0KDQogICAgICA8cmVmZXJlbmNlIGFuY2hvcj0iRklQUy0xOTgiPg0KICAgICAgICA8ZnJvbnQ+ DQogICAgICAgICAgPHRpdGxlPlRoZSBLZXllZC1IYXNoIE1lc3NhZ2UgQXV0aGVudGljYXRpb24g Q29kZSAoSE1BQyksIEZJUFMgUFVCDQogICAgICAgICAgMTk4PC90aXRsZT4NCg0KICAgICAgICAg IDxhdXRob3IgZnVsbG5hbWU9IlVTIE5hdGlvbmFsIEluc3RpdHV0ZSBvZiBTdGFuZGFyZHMgJmFt cDsgVGVjaG5vbG9neSI+DQogICAgICAgICAgICA8b3JnYW5pemF0aW9uLz4NCiAgICAgICAgICA8 L2F1dGhvcj4NCg0KICAgICAgICAgIDxkYXRlIG1vbnRoPSJNYXJjaCIgeWVhcj0iMjAwMiIvPg0K ICAgICAgICA8L2Zyb250Pg0KICAgICAgPC9yZWZlcmVuY2U+DQogICAgPC9yZWZlcmVuY2VzPg0K DQogICAgPHJlZmVyZW5jZXMgdGl0bGU9IkluZm9ybWF0aXZlIFJlZmVyZW5jZXMiPg0KICAgICAg PD9yZmMgaW5jbHVkZT0ncmVmZXJlbmNlLlJGQy41MDgyJz8+DQoNCiAgICAgIDw/cmZjIGluY2x1 ZGU9J3JlZmVyZW5jZS5SRkMuNTkyNic/Pg0KDQogICAgICA8P3JmYyBpbmNsdWRlPSdyZWZlcmVu Y2UuUkZDLjY3MjAnPz4NCg0KICAgICAgPD9yZmMgaW5jbHVkZT0ncmVmZXJlbmNlLlJGQy42OTUy Jz8+DQoNCiAgICA8L3JlZmVyZW5jZXM+DQogIDwvYmFjaz4NCjwvcmZjPg0K --047d7b5d42f8ae28c704fa330813-- From nobody Sun May 25 12:02:44 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7A01A0367; Sun, 25 May 2014 12:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.752 X-Spam-Level: X-Spam-Status: No, score=-100.752 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4d2ynfUTQhW; Sun, 25 May 2014 12:02:40 -0700 (PDT) Received: from www.gondrom.org (www.gondrom.org [91.250.114.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4961E1A0362; Sun, 25 May 2014 12:02:40 -0700 (PDT) X-No-Relay: not in my network DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=Ens6cR8OF2GU/MJbmDmd/1BnsSpRO/+mZzTiq4qH/x/6BMZWwGoess9MOO5bWRMyps4f1qiRE4iK0kPQ71Trbcv2uFfJQGP1dXiiItPy38BbuAegRQD8BCME4bVqFc5pm8QkNIHYWk0iMAmAlyTwChcA4YzFYhwiB7YDtPpMv/U=; h=X-No-Relay:X-No-Relay:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Enigmail-Version:Content-Type; X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.6] (5ec20a52.skybroadband.com [94.194.10.82]) by www.gondrom.org (Postfix) with ESMTPSA id D95031539003B; Sun, 25 May 2014 21:02:35 +0200 (CEST) Message-ID: <53823E4A.6080106@gondrom.org> Date: Sun, 25 May 2014 20:02:34 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: draft-ietf-pwe3-p2mp-pw-requirements.all@tools.ietf.org X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------000600060101070800050009" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/N4vPOie1E5TZ1oV5ssSulxgsCBw Cc: iesg@ietf.org, secdir@ietf.org Subject: [secdir] secdir review of draft-ietf-pwe3-p2mp-pw-requirements-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2014 19:02:42 -0000 This is a multi-part message in MIME format. --------------000600060101070800050009 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 draft is informational and about requirements and a framework for Point-to-Multipoint Pseudowire (PW) over MPLS Packet Switched Networks. The document appears ready for publication. A couple of comments: 1. Even though this document is only about requirements, it uses in a couple of places 2119 language. In principle that could even been seen as improving "readability", however, I am not sure whether that is appropriate usage for a requirement document, as 2119 is intended to signal conformance with a specification (which this ID is not). 2. The security consideration section is basically empty, only referring to RFC3916 and P2P PW. Considering that this is only a requirements document, this can be sufficient. (Note: it could have been nice to think about whether or how a move from P2P to P2MP PW might change or require additional security requirements for the specification. However, as this is only the requirements document and not the specification, this question can also be answered in the following spec.) 3. Nits: section 5 security considerations: should have a reference for "initial P2P PW definition" Thank you and best regards. Tobias --------------000600060101070800050009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 draft is informational and about requirements and a framework for Point-to-Multipoint Pseudowire (PW) over MPLS Packet Switched Networks.

The document appears ready for publication.

A couple of comments:
1. Even though this document is only about requirements, it uses in a couple of places 2119 language.
In principle that could even been seen as improving "readability", however, I am not sure whether that is appropriate usage for a requirement document, as 2119 is intended to signal conformance with a specification (which this ID is not).

2. The security consideration section is basically empty, only referring to RFC3916 and P2P PW. Considering that this is only a requirements document, this can be sufficient.
(Note: it could have been nice to think about whether or how a move from P2P to P2MP PW might change or require additional security requirements for the specification. However, as this is only the requirements document and not the specification, this question can also be answered in the following spec.)

3. Nits:
section 5 security considerations:
should have a reference for "initial P2P PW definition"

 Thank you and best regards.

Tobias --------------000600060101070800050009-- From nobody Mon May 26 00:40:51 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 517951A0418; Sun, 25 May 2014 18:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMezzsRTad5z; Sun, 25 May 2014 18:30:18 -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 A4C141A0416; Sun, 25 May 2014 18:30:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEN23558; Mon, 26 May 2014 01:30:11 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 26 May 2014 02:29:49 +0100 Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 26 May 2014 02:30:08 +0100 Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.103]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Mon, 26 May 2014 09:30:05 +0800 From: Vero Zheng To: Manav Bhatia , Yaron Sheffer Thread-Topic: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 Thread-Index: AQHPd90r0DS+N+7Z9EeeVC8ahSnwZptSFBaQ Date: Mon, 26 May 2014 01:30:05 +0000 Message-ID: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8302E4@SZXEMA504-MBS.china.huawei.com> References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> <537BC7B6.5040406@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B609@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C5BCE.4010801@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B6A8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C7EDB.9050000@cs.tcd.ie> <537C86D6.1030703@pi.nu> <20211F91F544D247976D84C5D778A4C32E60BA5C@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537CA2D2.4070103@cs.tcd.ie> <54E263B5-41C7-4523-9941-B3E39AE077CD@mit.edu> <57ee448f94f94cd7ba040903e604aa3c@SG70XWXCHHUB01.zap.alcatel-lucent.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.115] Content-Type: multipart/alternative; boundary="_000_2EEA459CD95CCB4988BFAFC0F2287B5C5C8302E4SZXEMA504MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/OmEtp2gOVboW6spRKrJsUesuQZ4 X-Mailman-Approved-At: Mon, 26 May 2014 00:40:48 -0700 Cc: "Bhatia, Manav \(Manav\)" , IETF Security Directorate , "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" , The IESG , Loa Andersson Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 01:30:22 -0000 --_000_2EEA459CD95CCB4988BFAFC0F2287B5C5C8302E4SZXEMA504MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIFlhcm9uIGFuZCBNYW5hdiBmb3Igd29ya2luZyB0aGlzIG91dC4NCkkgaGF2ZSBqdXN0 IGNvbmZpcm1lZCB0aGUgcG9zdC4NCg0KQ2hlZXJzLCBWZXJvDQoNCkZyb206IE1hbmF2IEJoYXRp YSBbbWFpbHRvOm1hbmF2YmhhdGlhQGdtYWlsLmNvbV0NClNlbnQ6IFN1bmRheSwgTWF5IDI1LCAy MDE0IDE6NTAgUE0NClRvOiBZYXJvbiBTaGVmZmVyDQpDYzogVXJpIEJsdW1lbnRoYWw7IFN0ZXBo ZW4gRmFycmVsbDsgQmhhdGlhLCBNYW5hdiAoTWFuYXYpOyBJRVRGIFNlY3VyaXR5IERpcmVjdG9y YXRlOyBkcmFmdC1pZXRmLW1wbHMtbGRwLWhlbGxvLWNyeXB0by1hdXRoLmFsbEB0b29scy5pZXRm Lm9yZzsgVGhlIElFU0c7IExvYSBBbmRlcnNzb24NClN1YmplY3Q6IFJlOiBbc2VjZGlyXSBTZWNE aXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbXBscy1sZHAtaGVsbG8tY3J5cHRvLWF1dGgtMDUNCg0K SGksDQoNCllhcm9uLCBJIGFuZCBmZXcgb2YgdXMgZXhjaGFuZ2VkIHF1aXRlIGEgZmV3IGVtYWls cyBvZmZsaW5lIGFuZCB3ZSBoYXZlIGNvbWUgdXAgd2l0aCBhIHZlcnNpb24gdGhhdCBhZGRyZXNz ZXMgWWFyb24ncyBhbmQgU3RlcGhlbidzIGNvbmNlcm5zIGFib3V0IHJlcGVhdGluZyB0aGUgSE1B QyBzdHVmZiB0aGF0cyBhbHJlYWR5IHByZXNlbnQgaW4gUkZDIDIxMDQuIFdlJ3ZlIGNsZWFuZWQg aXQgdXAgcHJldHR5IG5pY2VseSB3aXRoIHZlcnkgbWluaW1hbCBjaGFuZ2VzLg0KDQpJIGFtIHVu YWJsZSB0byBzdWJtaXQgdGhpcyBsYXRlc3QgYW5kIHRoZSBncmVhdGVzdCB2ZXJzaW9uIHNpbmNl IGkgaGF2ZSB1cGRhdGVkIG15IGVtYWlsIElEIGluIHRoaXMgdmVyc2lvbi4gVGhlIHRyYWNrZXIg cmVxdWlyZXMgb25lIG9mIHRoZSBjby1hdXRob3JzIHRvIGF1dGhlbnRpY2F0ZS9hcHByb3ZlIHRo ZSBzdWJtaXNzaW9uLg0KDQpJIGFtIGF0dGFjaGluZyB0aGUgbGF0ZXN0IHZlcnNpb24gd2l0aCB0 aGlzIGVtYWlsIGluIGNhc2UgZm9sa3Mgd2FudCB0byBnbyB0aHJvdWdoIHRoaXMgdGlsbCBpdCBi ZWNvbWVzIGF2YWlsYWJsZSBmb3JtYWxseS4NCg0KVGhlIGRyYWZ0IGlzIGFsbCBzZXQgdG8gZmx5 IG5vdyEgOi0pDQoNCkNoZWVycywgTWFuYXYNCg0KT24gV2VkLCBNYXkgMjEsIDIwMTQgYXQgNzo1 NCBQTSwgWWFyb24gU2hlZmZlciA8eWFyb25mLmlldGZAZ21haWwuY29tPG1haWx0bzp5YXJvbmYu aWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCklNSE8sIHRoaXMgaXMgcHVyZWx5IGEgbmFtaW5nIHBy b2JsZW0uIEFwYWQgZG9lcyBOT1QgbW9kaWZ5IHRoZSBiYXNlDQpITUFDLCBwbGVhc2Ugc2VlDQpo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1wbHMtbGRwLWhlbGxvLWNyeXB0 by1hdXRoLTA1I3NlY3Rpb24tNS4NCkl0IGlzIGp1c3Qgb25lIG1vcmUgdGhpbmcgdGhhdCdzIHNp Z25lZCBieSBITUFDLg0KDQpNeSBwcm9ibGVtIHdpdGggdGhpcyBkcmFmdCBpcyB0aGF0IHRoZXkg aGF2ZSBkaWZmZXJlbnQgaWRlYXMgYWJvdXQgdGhlDQprZXkgbGVuZ3RoLCBjb21wYXJlZCB0byBS RkMgMjEwNCAodG9wIG9mIFNlYy4gNS4xKS4gQWxzbywgSSBhbSB1bmhhcHB5DQp0aGF0IHRoZXkg c3BlbGwgb3V0IHRoZSBITUFDIGNvbnN0cnVjdGlvbiBpbnN0ZWFkIG9mIGxlYXZpbmcgaXQgYXMg YQ0KYmxhY2sgYm94Lg0KDQpCdXQgSSB0aGluayBBcGFkIGlzIGp1c3QgZmluZSwgaWYgaXQgd2Vy ZW4ndCBmb3IgdGhlIHVuZm9ydHVuYXRlIG5hbWUNCnRoYXQgbGVhZHMgcGVvcGxlIHRvIHRoaW5r IGl0J3MgbW9kaWZ5aW5nIEhNQUMuDQoNClRoYW5rcywNCiAgICAgICAgWWFyb24NCg0KDQpPbiAw NS8yMS8yMDE0IDA0OjI4IFBNLCBVcmkgQmx1bWVudGhhbCB3cm90ZToNCj4gT25jZSBhZ2Fpbiwg cGxlYXNlLg0KPg0KPiAxLiBXaG8gc3BlY2lmaWNhbGx5LCBhdCBOSVNUIGFuZCBhdCBJRVNHLCBz YXlzIHRoYXQgSE1BQyBuZWVkcyBBcGFkIGZvciBzZWN1cml0eSByZWFzb25zIChhbmQgdGhlcmVm b3JlIGlzIG5vdCBzZWN1cmUgYXMtaXMpPw0KPg0KPiAyLiBXaGF0IGFyZSB0aG9zZSBzZWN1cml0 eSByZWFzb25zLCBhbmQgd2hhdCBhcmUgdGhlIGF0dGFja3MgdGhhdCBhcmUgZm9pbGVkIGJ5IEFw YWQ/DQo+DQo+IDMuIFdoYXQgcHVibGlzaGVkIHBhcGVycy9yZWZlcmVuY2VzL3doYXRldmVyIGlz IHRoaXMgZG9jdW1lbnRlZD8gQXMgSE1BQyBjYW1lIHdpdGggc2VjdXJpdHkgcHJvb2ZzLCBJ4oCZ ZCBsaWtlIHRvIHNlZSB3aGVyZSBhbmQgaG93IHRoZXkgYXJlIGludmFsaWRhdGVkIChpZiB0aGV5 IGluZGVlZCBhcmUpLg0KPg0KPg0KPg0KPiBPbiBNYXkgMjEsIDIwMTQsIGF0IDg6NTcgLCBTdGVw aGVuIEZhcnJlbGwgPHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU8bWFpbHRvOnN0ZXBoZW4uZmFy cmVsbEBjcy50Y2QuaWU+PiB3cm90ZToNCj4NCj4+DQo+Pg0KPj4gT24gMjEvMDUvMTQgMTI6MTQs IEJoYXRpYSwgTWFuYXYgKE1hbmF2KSB3cm90ZToNCj4+PiBJIGFncmVlIHdpdGggTG9hLg0KPj4+ DQo+Pj4gT3VyIGN1cnJlbnQgZHJhZnQgaXMgdmVyeSBzaW1wbGUgYW5kIGhhcyBnb25lIHRocm91 Z2ggbXVsdGlwbGUNCj4+PiBpdGVyYXRpb25zIG9mIHJldmlld3MgaW4gYXQgbGVhc3QgdHdvIFdH cy4gSXQgYnJpbmdzIExEUCB0byB0aGUgc2FtZQ0KPj4+IGxldmVsIG9mIHNlY3VyaXR5IGFzIG90 aGVyIHByb3RvY29scyBydW5uaW5nIGluIHRoZSBuZXR3b3Jrcy4NCj4+DQo+PiBGdWxseSBhZ3Jl ZSB3aXRoIHRoYXQgZ29hbC4NCj4+DQo+Pj4NCj4+PiBJIHRoaW5rIHdlIHNob3VsZCBqdXN0IHB1 c2ggaXQgZm9yd2FyZCBhbmQgaWYgdGhlcmUgaXMgYW4gaW50ZXJlc3QgaW4NCj4+PiB3cml0aW5n IGEgbmV3IElEIHRoYXQgdXBkYXRlcyBITUFDIHNwZWNpZmljYXRpb24sIHRoZW4gd2Ugd3JpdGUg b25lDQo+Pj4gdGhhdCBpbmNsdWRlcyB0aGUgQXBhZCBzdHVmZi4gSSB0aGluayB0aGUgbGF0dGVy IHNob3VsZCBhbnl3YXlzIGJlDQo+Pj4gZG9uZSwgcmVnYXJkbGVzcyBvZiB3aGF0IGhhcHBlbnMg dG8gdGhpcyBwYXJ0aWN1bGFyIGRyYWZ0Lg0KPj4NCj4+IEkgbmVlZCB0byByZWFkIGl0LiBCdXQg SSdkIGJlIGhhcHBpZXIgaWYgdGhhdCBITUFDIGRyYWZ0IGV4aXN0ZWQNCj4+IGFuZCB3YXMgZ29p bmcgdG8gYmUgcHJvY2Vzc2VkIC0gdGhlbiB3ZSB3b3VsZG4ndCBoYXZlIHRvIGRvIHRoaXMNCj4+ IGRpc2N1c3Npb24gYWdhaW4uDQo+Pg0KPj4gQ2hlZXJzLA0KPj4gUy4NCj4+DQo+Pj4NCj4+PiBU aGUgSUVURiBzdWJtaXNzaW9uIHNpdGUgaXMgZG93biBhbmQgaGVuY2UgY291bGRu4oCZdCB1cGxv YWQgdGhlDQo+Pj4gcmV2aXNlZCBJRCAoYWRkcmVzc2luZyBZYXJvbidzIGNvbW1lbnRzKS4gV2ls bCBkbyBpdCB0b21vcnJvdyBvbmNlDQo+Pj4gaXRzIHVwLg0KPj4+DQo+Pj4gQWZ0ZXIgdGhhdCBp dHMgcmVhZHkgdG8gYmUgcGxhY2VkIGJlZm9yZSB0aGUgSUVTRy4NCj4+Pg0KPj4+IENoZWVycywg TWFuYXYNCj4+Pg0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBMb2EgQW5k ZXJzc29uIFttYWlsdG86bG9hQHBpLm51PG1haWx0bzpsb2FAcGkubnU+XQ0KPj4+PiBTZW50OiBX ZWRuZXNkYXksIE1heSAyMSwgMjAxNCA0OjI5IFBNIFRvOiBNYW5hdiBCaGF0aWE7IFN0ZXBoZW4N Cj4+Pj4gRmFycmVsbCBDYzogQmhhdGlhLCBNYW5hdiAoTWFuYXYpOyBJRVRGIFNlY3VyaXR5IERp cmVjdG9yYXRlOyBUaGUNCj4+Pj4gSUVTRzsgZHJhZnQtIGlldGYtbXBscy1sZHAtaGVsbG8tY3J5 cHRvLWF1dGguYWxsQHRvb2xzLmlldGYub3JnPG1haWx0bzppZXRmLW1wbHMtbGRwLWhlbGxvLWNy eXB0by1hdXRoLmFsbEB0b29scy5pZXRmLm9yZz47DQo+Pj4+IFlhcm9uIFNoZWZmZXIgU3ViamVj dDogUmU6IFNlY0RpciByZXZpZXcgb2YNCj4+Pj4gZHJhZnQtaWV0Zi1tcGxzLWxkcC1oZWxsby1j cnlwdG8tYXV0aC0wNQ0KPj4+Pg0KPj4+PiBGb2xrcywNCj4+Pj4NCj4+Pj4gSSdtIG9ubHkgdGhl IGRvY3VtZW50IHNoZXBoZXJkLiBNeSBmZWVsaW5nIGlzIHRoYXQgd2UgYXJlIHJhaXNpbmcNCj4+ Pj4gdGhlIGh1cmRsZSBzdGVwIGJ5IHN0ZXAgZm9yIHRoZSBLQVJQIC0gaW5pdGlhdGVkIFJGQ3Ms IHRoZSBmaXJzdA0KPj4+PiB3YXMgY29tcGFyYXRpdmVseSBzbW9vdGgsIG5vdyB3ZSBhcmUgdHJ5 aW5nIHRvIHB1dCBhbiAxOCBtb250aHMNCj4+Pj4gZWZmb3J0IChpbmRpdmlkdWFsIGRyYWZ0IHRv IFJGQykgaW4gZnJvbnQgb2YgYXBwcm92aW5nIHNvbWV0aGluZw0KPj4+PiB0aGF0IGlzIGNvbXBh cmF0aXZlbHkgc2ltcGxlIGFuZCBzZWVuIGFzIHJhaXNpbmcgTERQIHRvIHRoZSBzYW1lDQo+Pj4+ IHNlY3VyaXR5IGFzIHRoZSBvdGhlciByb3V0aW5nIHByb3RvY29scy4NCj4+Pj4NCj4+Pj4gU28g aWYgd2UgZ2V0IHRvIHRpcmVkIHRvIHB1c2ggdGhpcywgd2UgYXJlIGFsbCBiZXR0ZXIgb2ZmIG5v dA0KPj4+PiBkb2luZyB0aGUgc2VjdXJpdHkgd29yayBmb3IgdGhpcyBwYXJ0aWN1bGFyIHByb3Rv Y29sPw0KPj4+Pg0KPj4+PiBTb21lb25lIHNhaWQgLSAiTmV2ZXIgbGV0IHRoZSBiZXN0IGJlIHRo ZSBlbmVteSBvZiB0aGUgcG9zc2libGUiIQ0KPj4+Pg0KPj4+PiAvTG9hDQo+Pj4+DQo+Pj4+DQo+ Pj4+DQo+Pj4+IE9uIDIwMTQtMDUtMjEgMTI6MzksIE1hbmF2IEJoYXRpYSB3cm90ZToNCj4+Pj4+ IFN0ZXBoZW4sDQo+Pj4+Pg0KPj4+Pj4+PiBUaGlzIGhvd2V2ZXIgaXMgYSBsb25nIGRyYXduIGRp c2N1c3Npb24gYmVjYXVzZSBldmVyeW9uZQ0KPj4+Pj4+PiBuZWVkcyB0bw0KPj4+PiBiZQ0KPj4+ Pj4+PiBjb252aW5jZWQgb24gdGhlIG1lcml0cyBvZiB1cGRhdGluZyB0aGUgSE1BQyBzcGVjaWZp Y2F0aW9uIC0tDQo+Pj4+Pj4+IHdoaWNoDQo+Pj4+IEkNCj4+Pj4+Pj4gYW0gbm90IHN1cmUgd2ls bCB0YWtlIGhvdyBsb25nLg0KPj4+Pj4+DQo+Pj4+Pj4gU28gSSBuZWVkIHRvIGxvb2sgYXQgdGhp cyBkcmFmdCwgSE1BQyBhbmQgdGhlIG90aGVyIGNhc2VzIGJ1dA0KPj4+Pj4+IGl0IHNlZW1zIHRv IG1lIHRoYXQgeW91J3JlIGNvcHlpbmcgYSBwYWdlIG9yIHR3byBvZiBjcnlwdG8gc3BlYw0KPj4+ Pj4+IGVhY2ggdGltZSBhbmQgY2hhbmdpbmcgb25lIGxpbmUuIERvaW5nIHRoYXQgb3ZlciBhbmQg b3ZlciBpcyBhDQo+Pj4+Pj4gcmVjaXBlIGZvciBsb25nIHRlcm0gcGFpbiwgaXNuJ3QgaXQ/DQo+ Pj4+Pg0KPj4+Pj4gSXQgc3VyZSBpcy4NCj4+Pj4+DQo+Pj4+PiBJIGhhZCB2b2x1bnRlZXJlZCB0 byB3cml0ZSBhIDEtMiBwYWdlIGxvbmcgSUQgdGhhdCB1cGRhdGVkIHRoZQ0KPj4+Pj4gSE1BQw0K Pj4+PiB0bw0KPj4+Pj4gaW5jbHVkZSB0aGUgQXBhZCwgYnV0IHRoZSBpZGVhIHdhcyBzaG90IGRv d24uIFRoZSBvbmx5DQo+Pj4+PiBhbHRlcm5hdGl2ZSBsZWZ0IHdhcyB0byBpbmNsdWRlIHRoZSBj cnlwdG8gc3R1ZmYgaW4gZWFjaCBzdGFuZGFyZA0KPj4+Pj4gdGhhdCB3ZSB3cm90ZSBsYXRlci4N Cj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiAoQW5kIHdlJ3ZlIGhhZCB0aGlzIGRpc2N1c3Npb24gZm9y IGVhY2ggc3VjaCBkcmFmdCB3aGlsZSBJJ3ZlDQo+Pj4+Pj4gYmVlbiBvbiB0aGUgSUVTRyBJIHRo aW5rLCB3aGljaCBpcyBhbHNvIHNvbWV3aGF0IGRyYXduIG91dDstKQ0KPj4+Pj4NCj4+Pj4+IFRo aXMgZHJhZnQgaXMgcHJvYmFibHkgdGhlIGxhc3Qgb25lIHRoYXRzIGNvbWluZyBmcm9tIHRoZSBS b3V0aW5nDQo+Pj4+PiBXRyB3aGljaCB3aWxsIGhhdmUgdGhpcyBsZXZlbCBvZiBjcnlwdG8gbWF0 aGVtYXRpY3Mgc3BlbGxlZCBvdXQuDQo+Pj4+PiBBbGwgb3RoZXIgSUdQcyBhcmUgYWxyZWFkeSBj b3ZlcmVkLiBJbiBjYXNlIHdlIG5lZWQgdG8gY2hhbmdlDQo+Pj4+PiBzb21ldGhpbmcNCj4+Pj4g aW4NCj4+Pj4+IHRoZSBvbmVzIGFscmVhZHkgY292ZXJlZCB3ZSBjYW4gcmVmZXIgdG8gdGhlIGJh c2UgUkZDIHdoZXJlIHdlDQo+Pj4+PiBoYXZlIGRldGFpbGVkIHRoZSBjcnlwdG8gbWF0aHMuIEZv ciBleGFtcGxlLA0KPj4+Pj4gZHJhZnQtaWV0Zi1vc3BmLXNlY3VyaXR5LWV4dGVuc2lvbi1tYW51 YWwta2V5aW5nLTA4IGFtb25nc3QNCj4+Pj4+IG90aGVyIHRoaW5ncyBhbHNvIHVwZGF0ZXMgdGhl IGRlZmluaXRpb24gb2YgQXBhZC4gSXQgcG9pbnRzIHRvDQo+Pj4+PiB0aGUgZXhhY3QgbWF0aGVt YXRpY3MgaW4gUkZDIDU3MDkgYW5kIG9ubHkgdXBkYXRlcyB0aGUgQXBhZA0KPj4+Pj4gZGVmaW5p dGlvbiBpbiB0aGF0IGRyYWZ0LiBUaGlzIGRyYWZ0IGJ0dyBoYXMgY2xlYXJlZCB0aGUgV0cgTEMN Cj4+Pj4+IGFuZCB3b3VsZCBiZSBhcHBlYXJpbmcgYmVmb3JlIHlvdSBndXlzIHZlcnkgc29vbi4N Cj4+Pj4+DQo+Pj4+PiBHaXZlbiB0aGlzLCBpIHRoaW5rIHdlIHNob3VsZCBqdXN0IHBhc3MgdGhp cyBkcmFmdCB3aXRoIHRoaXMNCj4+Pj4+IGxldmVsIG9mIGRldGFpbHMuIFN1YnNlcXVlbnRseSwg d2hlbiBMRFAgd2FudHMgdG8gdXBkYXRlDQo+Pj4+PiBzb21ldGhpbmcsIGl0IGNhbiBub3JtYXRp dmVseSByZWZlciB0byB0aGlzIFJGQyBhbmQgb25seSBnaXZlIHRoZQ0KPj4+Pj4gY2hhbmdlcy4N Cj4+Pj4+DQo+Pj4+PiBDaGVlcnMsIE1hbmF2DQo+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gUy4NCj4+ Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IENoZWVycywgTWFuYXYNCj4+Pj4+Pj4NCj4+ Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBTDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4gQ2hlZXJzLCBNYW5hdg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tIEZyb206IFN0ZXBoZW4gRmFycmVsbA0KPj4+Pj4+Pj4+PiBbbWFpbHRvOnN0ZXBo ZW4uZmFycmVsbEBjcy50Y2QuaWU8bWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+XSBT ZW50OiBXZWRuZXNkYXksIE1heQ0KPj4+Pj4+Pj4+PiAyMSwgMjAxNCAyOjUzIEFNIFRvOiBCaGF0 aWEsIE1hbmF2IChNYW5hdik7IElFVEYNCj4+Pj4+Pj4+Pj4gU2VjdXJpdHkgRGlyZWN0b3JhdGU7 IFRoZSBJRVNHOyBkcmFmdC0NCj4+Pj4+Pj4+Pj4gaWV0Zi1tcGxzLWxkcC1oZWxsby1jcnlwdG8t YXV0aC5hbGxAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmlldGYtbXBscy1sZHAtaGVsbG8tY3J5cHRv LWF1dGguYWxsQHRvb2xzLmlldGYub3JnPiBDYzoNCj4+Pj4+Pj4+Pj4gWWFyb24gU2hlZmZlcjsg bWFuYXZiaGF0aWFAZ21haWwuY29tPG1haWx0bzptYW5hdmJoYXRpYUBnbWFpbC5jb20+IFN1Ympl Y3Q6IFJlOg0KPj4+Pj4+Pj4+PiBTZWNEaXIgcmV2aWV3IG9mDQo+Pj4+Pj4+Pj4+IGRyYWZ0LWll dGYtbXBscy1sZHAtaGVsbG8tY3J5cHRvLWF1dGgtMDUNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gT24gMTkvMDUvMTQgMjE6MjcsIFlhcm9uIFNoZWZmZXIg d3JvdGU6DQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+ICogNS4xOiBSZWRlZmluaW5nIEhN QUMgKFJGQyAyMTA0KSBpcyBhbiBleHRyZW1lbHkNCj4+Pj4+Pj4+Pj4+Pj4gYmFkIGlkZWEuIFRo aXMgcmV2aWV3ZXIgZG9lcyBub3QgaGF2ZSB0aGUNCj4+Pj4+Pj4+Pj4+Pj4gYXBwcm9wcmlhdGUg YmFja2dyb3VuZCB0byBjcml0aXF1ZSB0aGUgcHJvcG9zZWQNCj4+Pj4+Pj4+Pj4+Pj4gc29sdXRp b24sIGJ1dCB0aGVyZSBtdXN0IGJlIGFuIG92ZXJ3aGVsbWluZw0KPj4+Pj4+Pj4+Pj4+PiByZWFz b24gdG8NCj4+Pj4+Pj4+Pj4gcmVvcGVuPiA+Pj4+PiBjcnlwdG9ncmFwaGljIHByaW1pdGl2ZXMu DQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiBUaGlzIGlzIGEgZGVjaXNpb24gdGhhdCB3YXMg dGFrZW4gYnkgU2VjIEFkcyB3aGVuDQo+Pj4+Pj4+Pj4+Pj4gd2Ugd2VyZSBkb2luZyB0aGUgY3J5 cHRvIHByb3RlY3Rpb24gZm9yIHRoZSBJR1BzDQo+Pj4+Pj4+Pj4+Pj4gYmFzZWQgb24gc29tZSBm ZWVkYmFjayBmcm9tIE5JU1QuDQo+Pj4+Pj4+Pj4+IFRoaXMNCj4+Pj4+Pj4+Pj4+PiBtYXRoZW1h dGljcyBpcyBub3QgbmV3IGFuZCBoYXMgYmVlbiBkb25lIGZvciBhbGwNCj4+Pj4+Pj4+Pj4+PiBJ R1BzIGFuZCBoYXMgYmVlbiBhcHByb3ZlZCBhbmQgcmF0aGVyIGVuY291cmFnZWQgYnkNCj4+Pj4+ Pj4+Pj4+PiB0aGUgU2VjdXJpdHkgQURzLg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBUaGUgYWJv dmUgZG9lcyBub3Qgc291bmQgbGlrZSBzb21ldGhpbmcgSSByZWNvZ25pc2UuIEkNCj4+Pj4+Pj4+ Pj4gaGF2ZSByZXBlYXRlZGx5IGFza2VkIHRoYXQgZG9jdW1lbnRzIG5vdCByZS1kZWZpbmUNCj4+ Pj4+Pj4+Pj4gSE1BQy4gUGVyaGFwcyB0aGlzIHRpbWUsIEknbGwgbWFrZSB0aGF0IGEgRElTQ1VT UyBhbmQNCj4+Pj4+Pj4+Pj4gbm90IGJ1ZGdlLiBJIHByb2JhYmx5IHNob3VsZCBoYXZlIGRvbmUg dGhhdCBiZWZvcmUNCj4+Pj4+Pj4+Pj4gVEJILg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBJZiB5 b3UgYXJlIHJldmlzaW5nIHRoYXQgZG9jLCAqcGxlYXNlKiBnZXQgcmlkIG9mIHRoZQ0KPj4+Pj4+ Pj4+PiByZS1kZWZpbml0aW9uIGFuZCBqdXN0IHByb3Blcmx5IHJlZmVyIHRvIEhNQUMuIEl0cw0K Pj4+Pj4+Pj4+PiBhYm91dCB0aW1lIHRvIHN0b3AgcmVwZWF0aW5nIHRoYXQgZXJyb3IuDQo+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IFMuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+ Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+DQo+Pj4+IC0tDQo+Pj4+DQo+Pj4+DQo+Pj4+ IExvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5o dWF3ZWkuY29tPG1haWx0bzpsb2FAbWFpbDAxLmh1YXdlaS5jb20+DQo+Pj4+IFNlbmlvciBNUExT IEV4cGVydCAgICAgICAgICAgICAgICAgICAgICAgICAgbG9hQHBpLm51PG1haWx0bzpsb2FAcGku bnU+IEh1YXdlaQ0KPj4+PiBUZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQpICAgICBwaG9uZTogKzQ2 IDczOSA4MSAyMSA2NDx0ZWw6JTJCNDYlMjA3MzklMjA4MSUyMDIxJTIwNjQ+DQo+Pg0KPj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHNlY2RpciBt YWlsaW5nIGxpc3QNCj4+IHNlY2RpckBpZXRmLm9yZzxtYWlsdG86c2VjZGlyQGlldGYub3JnPg0K Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZWNkaXINCj4+IHdpa2k6 IGh0dHA6Ly90b29scy5pZXRmLm9yZy9hcmVhL3NlYy90cmFjL3dpa2kvU2VjRGlyUmV2aWV3DQo+ DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNl Y2RpciBtYWlsaW5nIGxpc3QNCj4gc2VjZGlyQGlldGYub3JnPG1haWx0bzpzZWNkaXJAaWV0Zi5v cmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2VjZGlyDQo+IHdp a2k6IGh0dHA6Ly90b29scy5pZXRmLm9yZy9hcmVhL3NlYy90cmFjL3dpa2kvU2VjRGlyUmV2aWV3 DQo+DQoNCg== --_000_2EEA459CD95CCB4988BFAFC0F2287B5C5C8302E4SZXEMA504MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcy LjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3Mg WWFyb24gYW5kIE1hbmF2IGZvciB3b3JraW5nIHRoaXMgb3V0LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBoYXZlIGp1c3QgY29uZmlybWVkIHRoZSBwb3N0Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaGVlcnMsIFZlcm88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4gTWFuYXYgQmhhdGlhIFttYWlsdG86bWFuYXZiaGF0aWFAZ21haWwu Y29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgTWF5IDI1LCAyMDE0IDE6NTAgUE08YnI+ DQo8Yj5Ubzo8L2I+IFlhcm9uIFNoZWZmZXI8YnI+DQo8Yj5DYzo8L2I+IFVyaSBCbHVtZW50aGFs OyBTdGVwaGVuIEZhcnJlbGw7IEJoYXRpYSwgTWFuYXYgKE1hbmF2KTsgSUVURiBTZWN1cml0eSBE aXJlY3RvcmF0ZTsgZHJhZnQtaWV0Zi1tcGxzLWxkcC1oZWxsby1jcnlwdG8tYXV0aC5hbGxAdG9v bHMuaWV0Zi5vcmc7IFRoZSBJRVNHOyBMb2EgQW5kZXJzc29uPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbc2VjZGlyXSBTZWNEaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbXBscy1sZHAtaGVsbG8t Y3J5cHRvLWF1dGgtMDU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+WWFyb24sIEkgYW5k IGZldyBvZiB1cyBleGNoYW5nZWQgcXVpdGUgYSBmZXcgZW1haWxzIG9mZmxpbmUgYW5kIHdlIGhh dmUgY29tZSB1cCB3aXRoIGEgdmVyc2lvbiB0aGF0IGFkZHJlc3NlcyBZYXJvbidzIGFuZCBTdGVw aGVuJ3MgY29uY2VybnMgYWJvdXQgcmVwZWF0aW5nIHRoZSBITUFDIHN0dWZmIHRoYXRzIGFscmVh ZHkgcHJlc2VudCBpbiBSRkMgMjEwNC4gV2UndmUgY2xlYW5lZA0KIGl0IHVwIHByZXR0eSBuaWNl bHkgd2l0aCB2ZXJ5IG1pbmltYWwgY2hhbmdlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgYW0gdW5hYmxlIHRvIHN1Ym1pdCB0aGlzIGxhdGVzdCBh bmQgdGhlIGdyZWF0ZXN0IHZlcnNpb24gc2luY2UgaSBoYXZlIHVwZGF0ZWQgbXkgZW1haWwgSUQg aW4gdGhpcyB2ZXJzaW9uLiBUaGUgdHJhY2tlciByZXF1aXJlcyBvbmUgb2YgdGhlIGNvLWF1dGhv cnMgdG8gYXV0aGVudGljYXRlL2FwcHJvdmUgdGhlIHN1Ym1pc3Npb24uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGFtIGF0dGFjaGluZyB0aGUgbGF0 ZXN0IHZlcnNpb24gd2l0aCB0aGlzIGVtYWlsIGluIGNhc2UgZm9sa3Mgd2FudCB0byBnbyB0aHJv dWdoIHRoaXMgdGlsbCBpdCBiZWNvbWVzIGF2YWlsYWJsZSBmb3JtYWxseS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBkcmFmdCBpcyBhbGwgc2V0 IHRvIGZseSBub3chIDotKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+Q2hlZXJzLCBNYW5hdjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFdlZCwgTWF5IDIxLCAyMDE0IGF0IDc6NTQg UE0sIFlhcm9uIFNoZWZmZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj55YXJvbmYuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPklNSE8sIHRoaXMgaXMgcHVyZWx5IGEgbmFtaW5nIHByb2JsZW0uIEFwYWQg ZG9lcyBOT1QgbW9kaWZ5IHRoZSBiYXNlPGJyPg0KSE1BQywgcGxlYXNlIHNlZTxicj4NCjxhIGhy ZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbXBscy1sZHAtaGVsbG8t Y3J5cHRvLWF1dGgtMDUjc2VjdGlvbi01IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tcGxzLWxkcC1oZWxsby1jcnlwdG8tYXV0aC0wNSNzZWN0 aW9uLTU8L2E+Ljxicj4NCkl0IGlzIGp1c3Qgb25lIG1vcmUgdGhpbmcgdGhhdCdzIHNpZ25lZCBi eSBITUFDLjxicj4NCjxicj4NCk15IHByb2JsZW0gd2l0aCB0aGlzIGRyYWZ0IGlzIHRoYXQgdGhl eSBoYXZlIGRpZmZlcmVudCBpZGVhcyBhYm91dCB0aGU8YnI+DQprZXkgbGVuZ3RoLCBjb21wYXJl ZCB0byBSRkMgMjEwNCAodG9wIG9mIFNlYy4gNS4xKS4gQWxzbywgSSBhbSB1bmhhcHB5PGJyPg0K dGhhdCB0aGV5IHNwZWxsIG91dCB0aGUgSE1BQyBjb25zdHJ1Y3Rpb24gaW5zdGVhZCBvZiBsZWF2 aW5nIGl0IGFzIGE8YnI+DQpibGFjayBib3guPGJyPg0KPGJyPg0KQnV0IEkgdGhpbmsgQXBhZCBp cyBqdXN0IGZpbmUsIGlmIGl0IHdlcmVuJ3QgZm9yIHRoZSB1bmZvcnR1bmF0ZSBuYW1lPGJyPg0K dGhhdCBsZWFkcyBwZW9wbGUgdG8gdGhpbmsgaXQncyBtb2RpZnlpbmcgSE1BQy48YnI+DQo8YnI+ DQpUaGFua3MsPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFlhcm9uPGJyPg0KPGJy Pg0KPGJyPg0KT24gMDUvMjEvMjAxNCAwNDoyOCBQTSwgVXJpIEJsdW1lbnRoYWwgd3JvdGU6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IE9uY2UgYWdhaW4sIHBsZWFzZS48YnI+DQom Z3Q7PGJyPg0KJmd0OyAxLiBXaG8gc3BlY2lmaWNhbGx5LCBhdCBOSVNUIGFuZCBhdCBJRVNHLCBz YXlzIHRoYXQgSE1BQyBuZWVkcyBBcGFkIGZvciBzZWN1cml0eSByZWFzb25zIChhbmQgdGhlcmVm b3JlIGlzIG5vdCBzZWN1cmUgYXMtaXMpPzxicj4NCiZndDs8YnI+DQomZ3Q7IDIuIFdoYXQgYXJl IHRob3NlIHNlY3VyaXR5IHJlYXNvbnMsIGFuZCB3aGF0IGFyZSB0aGUgYXR0YWNrcyB0aGF0IGFy ZSBmb2lsZWQgYnkgQXBhZD88YnI+DQomZ3Q7PGJyPg0KJmd0OyAzLiBXaGF0IHB1Ymxpc2hlZCBw YXBlcnMvcmVmZXJlbmNlcy93aGF0ZXZlciBpcyB0aGlzIGRvY3VtZW50ZWQ/IEFzIEhNQUMgY2Ft ZSB3aXRoIHNlY3VyaXR5IHByb29mcywgSeKAmWQgbGlrZSB0byBzZWUgd2hlcmUgYW5kIGhvdyB0 aGV5IGFyZSBpbnZhbGlkYXRlZCAoaWYgdGhleSBpbmRlZWQgYXJlKS48YnI+DQomZ3Q7PGJyPg0K Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIE1heSAyMSwgMjAxNCwgYXQgODo1NyAsIFN0ZXBo ZW4gRmFycmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWUi PnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IE9uIDIxLzA1LzE0IDEyOjE0LCBC aGF0aWEsIE1hbmF2IChNYW5hdikgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7IEkgYWdyZWUgd2l0 aCBMb2EuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IE91ciBjdXJyZW50IGRy YWZ0IGlzIHZlcnkgc2ltcGxlIGFuZCBoYXMgZ29uZSB0aHJvdWdoIG11bHRpcGxlPGJyPg0KJmd0 OyZndDsmZ3Q7IGl0ZXJhdGlvbnMgb2YgcmV2aWV3cyBpbiBhdCBsZWFzdCB0d28gV0dzLiBJdCBi cmluZ3MgTERQIHRvIHRoZSBzYW1lPGJyPg0KJmd0OyZndDsmZ3Q7IGxldmVsIG9mIHNlY3VyaXR5 IGFzIG90aGVyIHByb3RvY29scyBydW5uaW5nIGluIHRoZSBuZXR3b3Jrcy48YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7IEZ1bGx5IGFncmVlIHdpdGggdGhhdCBnb2FsLjxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEkgdGhpbmsgd2Ugc2hvdWxkIGp1 c3QgcHVzaCBpdCBmb3J3YXJkIGFuZCBpZiB0aGVyZSBpcyBhbiBpbnRlcmVzdCBpbjxicj4NCiZn dDsmZ3Q7Jmd0OyB3cml0aW5nIGEgbmV3IElEIHRoYXQgdXBkYXRlcyBITUFDIHNwZWNpZmljYXRp b24sIHRoZW4gd2Ugd3JpdGUgb25lPGJyPg0KJmd0OyZndDsmZ3Q7IHRoYXQgaW5jbHVkZXMgdGhl IEFwYWQgc3R1ZmYuIEkgdGhpbmsgdGhlIGxhdHRlciBzaG91bGQgYW55d2F5cyBiZTxicj4NCiZn dDsmZ3Q7Jmd0OyBkb25lLCByZWdhcmRsZXNzIG9mIHdoYXQgaGFwcGVucyB0byB0aGlzIHBhcnRp Y3VsYXIgZHJhZnQuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJIG5lZWQgdG8gcmVhZCBp dC4gQnV0IEknZCBiZSBoYXBwaWVyIGlmIHRoYXQgSE1BQyBkcmFmdCBleGlzdGVkPGJyPg0KJmd0 OyZndDsgYW5kIHdhcyBnb2luZyB0byBiZSBwcm9jZXNzZWQgLSB0aGVuIHdlIHdvdWxkbid0IGhh dmUgdG8gZG8gdGhpczxicj4NCiZndDsmZ3Q7IGRpc2N1c3Npb24gYWdhaW4uPGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyBDaGVlcnMsPGJyPg0KJmd0OyZndDsgUy48YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBUaGUgSUVURiBzdWJtaXNzaW9uIHNp dGUgaXMgZG93biBhbmQgaGVuY2UgY291bGRu4oCZdCB1cGxvYWQgdGhlPGJyPg0KJmd0OyZndDsm Z3Q7IHJldmlzZWQgSUQgKGFkZHJlc3NpbmcgWWFyb24ncyBjb21tZW50cykuIFdpbGwgZG8gaXQg dG9tb3Jyb3cgb25jZTxicj4NCiZndDsmZ3Q7Jmd0OyBpdHMgdXAuPGJyPg0KJmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmZ3Q7IEFmdGVyIHRoYXQgaXRzIHJlYWR5IHRvIGJlIHBsYWNlZCBiZWZv cmUgdGhlIElFU0cuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IENoZWVycywg TWFuYXY8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tIEZyb206IExvYSBBbmRlcnNzb24gW21haWx0bzo8YSBocmVmPSJtYWls dG86bG9hQHBpLm51Ij5sb2FAcGkubnU8L2E+XTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgU2VudDog V2VkbmVzZGF5LCBNYXkgMjEsIDIwMTQgNDoyOSBQTSBUbzogTWFuYXYgQmhhdGlhOyBTdGVwaGVu PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBGYXJyZWxsIENjOiBCaGF0aWEsIE1hbmF2IChNYW5hdik7 IElFVEYgU2VjdXJpdHkgRGlyZWN0b3JhdGU7IFRoZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgSUVT RzsgZHJhZnQtIDxhIGhyZWY9Im1haWx0bzppZXRmLW1wbHMtbGRwLWhlbGxvLWNyeXB0by1hdXRo LmFsbEB0b29scy5pZXRmLm9yZyI+DQppZXRmLW1wbHMtbGRwLWhlbGxvLWNyeXB0by1hdXRoLmFs bEB0b29scy5pZXRmLm9yZzwvYT47PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBZYXJvbiBTaGVmZmVy IFN1YmplY3Q6IFJlOiBTZWNEaXIgcmV2aWV3IG9mPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBkcmFm dC1pZXRmLW1wbHMtbGRwLWhlbGxvLWNyeXB0by1hdXRoLTA1PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgRm9sa3MsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0OyZndDsgSSdtIG9ubHkgdGhlIGRvY3VtZW50IHNoZXBoZXJkLiBNeSBmZWVs aW5nIGlzIHRoYXQgd2UgYXJlIHJhaXNpbmc8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBodXJk bGUgc3RlcCBieSBzdGVwIGZvciB0aGUgS0FSUCAtIGluaXRpYXRlZCBSRkNzLCB0aGUgZmlyc3Q8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IHdhcyBjb21wYXJhdGl2ZWx5IHNtb290aCwgbm93IHdlIGFy ZSB0cnlpbmcgdG8gcHV0IGFuIDE4IG1vbnRoczxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgZWZmb3J0 IChpbmRpdmlkdWFsIGRyYWZ0IHRvIFJGQykgaW4gZnJvbnQgb2YgYXBwcm92aW5nIHNvbWV0aGlu Zzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgdGhhdCBpcyBjb21wYXJhdGl2ZWx5IHNpbXBsZSBhbmQg c2VlbiBhcyByYWlzaW5nIExEUCB0byB0aGUgc2FtZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgc2Vj dXJpdHkgYXMgdGhlIG90aGVyIHJvdXRpbmcgcHJvdG9jb2xzLjxicj4NCiZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFNvIGlmIHdlIGdldCB0byB0aXJlZCB0byBwdXNoIHRo aXMsIHdlIGFyZSBhbGwgYmV0dGVyIG9mZiBub3Q8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGRvaW5n IHRoZSBzZWN1cml0eSB3b3JrIGZvciB0aGlzIHBhcnRpY3VsYXIgcHJvdG9jb2w/PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgU29tZW9uZSBzYWlkIC0gJnF1b3Q7 TmV2ZXIgbGV0IHRoZSBiZXN0IGJlIHRoZSBlbmVteSBvZiB0aGUgcG9zc2libGUmcXVvdDshPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgL0xvYTxicj4NCiZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsgT24gMjAxNC0wNS0yMSAxMjozOSwgTWFuYXYgQmhhdGlhIHdy b3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFN0ZXBoZW4sPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoaXMgaG93ZXZlciBp cyBhIGxvbmcgZHJhd24gZGlzY3Vzc2lvbiBiZWNhdXNlIGV2ZXJ5b25lPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBuZWVkcyB0bzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgYmU8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNvbnZpbmNlZCBvbiB0aGUgbWVyaXRzIG9m IHVwZGF0aW5nIHRoZSBITUFDIHNwZWNpZmljYXRpb24gLS08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IHdoaWNoPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBJPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhbSBub3Qgc3VyZSB3aWxsIHRha2UgaG93IGxvbmcuPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNv IEkgbmVlZCB0byBsb29rIGF0IHRoaXMgZHJhZnQsIEhNQUMgYW5kIHRoZSBvdGhlciBjYXNlcyBi dXQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaXQgc2VlbXMgdG8gbWUgdGhhdCB5b3Un cmUgY29weWluZyBhIHBhZ2Ugb3IgdHdvIG9mIGNyeXB0byBzcGVjPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGVhY2ggdGltZSBhbmQgY2hhbmdpbmcgb25lIGxpbmUuIERvaW5nIHRoYXQg b3ZlciBhbmQgb3ZlciBpcyBhPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlY2lwZSBm b3IgbG9uZyB0ZXJtIHBhaW4sIGlzbid0IGl0Pzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgSXQgc3VyZSBpcy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgaGFkIHZvbHVudGVlcmVkIHRvIHdyaXRl IGEgMS0yIHBhZ2UgbG9uZyBJRCB0aGF0IHVwZGF0ZWQgdGhlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgSE1BQzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgdG88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBpbmNsdWRlIHRoZSBBcGFkLCBidXQgdGhlIGlkZWEgd2FzIHNob3QgZG93bi4gVGhlIG9u bHk8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhbHRlcm5hdGl2ZSBsZWZ0IHdhcyB0byBpbmNs dWRlIHRoZSBjcnlwdG8gc3R1ZmYgaW4gZWFjaCBzdGFuZGFyZDxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IHRoYXQgd2Ugd3JvdGUgbGF0ZXIuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg KEFuZCB3ZSd2ZSBoYWQgdGhpcyBkaXNjdXNzaW9uIGZvciBlYWNoIHN1Y2ggZHJhZnQgd2hpbGUg SSd2ZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBiZWVuIG9uIHRoZSBJRVNHIEkgdGhp bmssIHdoaWNoIGlzIGFsc28gc29tZXdoYXQgZHJhd24gb3V0Oy0pPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGlzIGRyYWZ0IGlzIHByb2JhYmx5 IHRoZSBsYXN0IG9uZSB0aGF0cyBjb21pbmcgZnJvbSB0aGUgUm91dGluZzxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IFdHIHdoaWNoIHdpbGwgaGF2ZSB0aGlzIGxldmVsIG9mIGNyeXB0byBtYXRo ZW1hdGljcyBzcGVsbGVkIG91dC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBbGwgb3RoZXIg SUdQcyBhcmUgYWxyZWFkeSBjb3ZlcmVkLiBJbiBjYXNlIHdlIG5lZWQgdG8gY2hhbmdlPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc29tZXRoaW5nPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBpbjxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBvbmVzIGFscmVhZHkgY292ZXJlZCB3ZSBjYW4g cmVmZXIgdG8gdGhlIGJhc2UgUkZDIHdoZXJlIHdlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsg aGF2ZSBkZXRhaWxlZCB0aGUgY3J5cHRvIG1hdGhzLiBGb3IgZXhhbXBsZSw8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBkcmFmdC1pZXRmLW9zcGYtc2VjdXJpdHktZXh0ZW5zaW9uLW1hbnVhbC1r ZXlpbmctMDggYW1vbmdzdDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG90aGVyIHRoaW5ncyBh bHNvIHVwZGF0ZXMgdGhlIGRlZmluaXRpb24gb2YgQXBhZC4gSXQgcG9pbnRzIHRvPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgdGhlIGV4YWN0IG1hdGhlbWF0aWNzIGluIFJGQyA1NzA5IGFuZCBv bmx5IHVwZGF0ZXMgdGhlIEFwYWQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkZWZpbml0aW9u IGluIHRoYXQgZHJhZnQuIFRoaXMgZHJhZnQgYnR3IGhhcyBjbGVhcmVkIHRoZSBXRyBMQzxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFuZCB3b3VsZCBiZSBhcHBlYXJpbmcgYmVmb3JlIHlvdSBn dXlzIHZlcnkgc29vbi48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IEdpdmVuIHRoaXMsIGkgdGhpbmsgd2Ugc2hvdWxkIGp1c3QgcGFzcyB0aGlzIGRy YWZ0IHdpdGggdGhpczxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGxldmVsIG9mIGRldGFpbHMu IFN1YnNlcXVlbnRseSwgd2hlbiBMRFAgd2FudHMgdG8gdXBkYXRlPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgc29tZXRoaW5nLCBpdCBjYW4gbm9ybWF0aXZlbHkgcmVmZXIgdG8gdGhpcyBSRkMg YW5kIG9ubHkgZ2l2ZSB0aGU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjaGFuZ2VzLjxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgQ2hlZXJzLCBN YW5hdjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFMuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQ2hlZXJz LCBNYW5hdjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQ2hlZXJzLCBN YW5hdjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0gRnJvbTogU3RlcGhlbiBGYXJyZWxsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllIj5zdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPC9hPl0gU2VudDogV2VkbmVzZGF5 LCBNYXk8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDIxLCAy MDE0IDI6NTMgQU0gVG86IEJoYXRpYSwgTWFuYXYgKE1hbmF2KTsgSUVURjxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU2VjdXJpdHkgRGlyZWN0b3JhdGU7IFRo ZSBJRVNHOyBkcmFmdC08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IDxhIGhyZWY9Im1haWx0bzppZXRmLW1wbHMtbGRwLWhlbGxvLWNyeXB0by1hdXRoLmFsbEB0 b29scy5pZXRmLm9yZyI+aWV0Zi1tcGxzLWxkcC1oZWxsby1jcnlwdG8tYXV0aC5hbGxAdG9vbHMu aWV0Zi5vcmc8L2E+IENjOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgWWFyb24gU2hlZmZlcjsgPGEgaHJlZj0ibWFpbHRvOm1hbmF2YmhhdGlhQGdtYWlsLmNv bSI+bWFuYXZiaGF0aWFAZ21haWwuY29tPC9hPiBTdWJqZWN0OiBSZTo8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNlY0RpciByZXZpZXcgb2Y8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRyYWZ0LWlldGYtbXBscy1sZHAt aGVsbG8tY3J5cHRvLWF1dGgtMDU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDE5LzA1LzE0IDIxOjI3LCBZYXJv biBTaGVmZmVyIHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7ICogNS4xOiBSZWRlZmluaW5nIEhNQUMgKFJGQyAyMTA0KSBpcyBh biBleHRyZW1lbHk8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGJhZCBpZGVhLiBUaGlzIHJldmlld2VyIGRvZXMgbm90IGhhdmUgdGhlPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBh cHByb3ByaWF0ZSBiYWNrZ3JvdW5kIHRvIGNyaXRpcXVlIHRoZSBwcm9wb3NlZDxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc29sdXRpb24s IGJ1dCB0aGVyZSBtdXN0IGJlIGFuIG92ZXJ3aGVsbWluZzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVhc29uIHRvPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZW9wZW4mZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IGNyeXB0b2dyYXBoaWMgcHJpbWl0aXZlcy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhpcyBpcyBhIGRlY2lzaW9uIHRoYXQgd2Fz IHRha2VuIGJ5IFNlYyBBZHMgd2hlbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3ZSB3ZXJlIGRvaW5nIHRoZSBjcnlwdG8gcHJvdGVjdGlvbiBm b3IgdGhlIElHUHM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgYmFzZWQgb24gc29tZSBmZWVkYmFjayBmcm9tIE5JU1QuPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGlzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1hdGhlbWF0aWNzIGlzIG5vdCBuZXcg YW5kIGhhcyBiZWVuIGRvbmUgZm9yIGFsbDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJR1BzIGFuZCBoYXMgYmVlbiBhcHByb3ZlZCBhbmQgcmF0 aGVyIGVuY291cmFnZWQgYnk8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgdGhlIFNlY3VyaXR5IEFEcy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBUaGUgYWJvdmUgZG9lcyBub3Qgc291bmQgbGlrZSBzb21ldGhpbmcgSSByZWNv Z25pc2UuIEk8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGhh dmUgcmVwZWF0ZWRseSBhc2tlZCB0aGF0IGRvY3VtZW50cyBub3QgcmUtZGVmaW5lPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBITUFDLiBQZXJoYXBzIHRoaXMg dGltZSwgSSdsbCBtYWtlIHRoYXQgYSBESVNDVVNTIGFuZDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbm90IGJ1ZGdlLiBJIHByb2JhYmx5IHNob3VsZCBoYXZl IGRvbmUgdGhhdCBiZWZvcmU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IFRCSC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJZiB5b3UgYXJl IHJldmlzaW5nIHRoYXQgZG9jLCAqcGxlYXNlKiBnZXQgcmlkIG9mIHRoZTxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmUtZGVmaW5pdGlvbiBhbmQganVzdCBw cm9wZXJseSByZWZlciB0byBITUFDLiBJdHM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IGFib3V0IHRpbWUgdG8gc3RvcCByZXBlYXRpbmcgdGhhdCBlcnJvci48 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTLjxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IC0tPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IExvYSBBbmRlcnNzb24gJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtlbWFpbDogPGEgaHJlZj0ibWFpbHRvOmxvYUBtYWlsMDEuaHVh d2VpLmNvbSI+DQpsb2FAbWFpbDAxLmh1YXdlaS5jb208L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyBTZW5pb3IgTVBMUyBFeHBlcnQgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEg aHJlZj0ibWFpbHRvOmxvYUBwaS5udSI+bG9hQHBpLm51PC9hPiBIdWF3ZWk8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7IFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgJm5ic3A7ICZuYnNwOyBwaG9uZTog PGEgaHJlZj0idGVsOiUyQjQ2JTIwNzM5JTIwODElMjAyMSUyMDY0Ij4NCiYjNDM7NDYgNzM5IDgx IDIxIDY0PC9hPjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyBzZWNkaXIgbWFpbGlu ZyBsaXN0PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNlY2RpckBpZXRmLm9yZyI+c2Vj ZGlyQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2VjZGlyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZWNkaXI8L2E+PGJyPg0KJmd0OyZndDsgd2lraTog PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2FyZWEvc2VjL3RyYWMvd2lraS9TZWNEaXJS ZXZpZXciIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9hcmVhL3NlYy90 cmFjL3dpa2kvU2VjRGlyUmV2aWV3PC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBzZWNkaXIgbWFp bGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86c2VjZGlyQGlldGYub3JnIj5zZWNk aXJAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NlY2RpciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2VjZGlyPC9hPjxicj4NCiZndDsgd2lraTogPGEgaHJlZj0i aHR0cDovL3Rvb2xzLmlldGYub3JnL2FyZWEvc2VjL3RyYWMvd2lraS9TZWNEaXJSZXZpZXciIHRh cmdldD0iX2JsYW5rIj4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9hcmVhL3NlYy90cmFjL3dpa2kv U2VjRGlyUmV2aWV3PC9hPjxicj4NCiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2EEA459CD95CCB4988BFAFC0F2287B5C5C8302E4SZXEMA504MBSchi_-- From nobody Mon May 26 21:35:53 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7851A0363; Mon, 26 May 2014 21:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJIKEsKO-QNT; Mon, 26 May 2014 21:35:50 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB56C1A0360; Mon, 26 May 2014 21:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1254; q=dns/txt; s=iport; t=1401165347; x=1402374947; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=6JXGooNeysUORUVL00cRoL67qxq1JKjmTqmeYSnZUNs=; b=T5xIRMBOyuSs2EqV6Uj6ib391lMi/9mOrBwbPlsHJnlEKV6ZximzSIMP 6DCdu72sgy4eR17092SGkxVVhoxiD3kpuaYPYcRLF7XrQ3PGFZRVwMQUX kLblcvlicQwBj5Q31IQA9AF+3pFlXrBhUSew7EUw6yXZrH/BKtns2BbAE o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAMkVhFOtJA2B/2dsb2JhbABZgweBKsMiFnSCLDpRAT5CJwQBiFTUGReSBIEVBJlzkyeDOIIv X-IronPort-AV: E=Sophos;i="4.98,916,1392163200"; d="scan'208";a="328100325" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-7.cisco.com with ESMTP; 27 May 2014 04:35:46 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s4R4Zkqk026228 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 May 2014 04:35:46 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.239]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Mon, 26 May 2014 23:35:45 -0500 From: "Joseph Salowey (jsalowey)" To: IESG Secretary , "" , "draft-moonesamy-sshfp-ed25519.all@tools.ietf.org" Thread-Topic: secdir review of draft-moonesamy-sshfp-ed25519-01 Thread-Index: AQHPeWUfo5K1BZN1JUqd29NR7Q9teQ== Date: Tue, 27 May 2014 04:35:44 +0000 Message-ID: <2ACBFFE4-BCEB-4F6D-A2D3-861BADF543DE@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.116] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/oawAi5fddJnXMfFvs-9yfgrsOO0 Subject: [secdir] secdir review of draft-moonesamy-sshfp-ed25519-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 04:35:51 -0000 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 document defines an SSHFP DNS record for ED25519 signature algorithm. = The document is ready with issues: 1) This document describes how to store the fingerprint of a public key th= at can be used with the ed25519 signature algorithm. I do not see any refe= rence as to how to use the ed25519 signature algorithm in SSH. Perhaps I a= m missing a reference somewhere, but it really seems that the use of the si= gnature algorithm in SSH should be defined somewhere, preferably in an IETF= document. I so not see the point of publishing the SSHFP record document = without some reference as to how it will be used.=20 2) The examples in RFC 6594 include the OpenSSH formatted key that is deco= ded and hashed to obtain the resulting fingerprint. It would be better if = the draft followed this aspect of 6594 and included the key used to generat= e the fingerprint. =20 Joe= From nobody Mon May 26 21:37:55 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2C01A036D; Mon, 26 May 2014 21:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d25Qi407vjUP; Mon, 26 May 2014 21:37:50 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 155ED1A0363; Mon, 26 May 2014 21:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1392; q=dns/txt; s=iport; t=1401165467; x=1402375067; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Vk9oJ0Tc0y4ovTrmVBGjgfFSg/2qXG0s+jObsLjU4qY=; b=jscdqXwP0iTUNpMS0Pr0ai/DyCeE97P6MQ+UAxKiIVV9QHQat4KemNeh s9bjmV/1AZVEw8oAbgIM8f3gHbxLRmSkOK066NN+S55aYyyA+77mXo9I6 FbYHHrwcSAYsCW7nmo0GtIQPNrEPVOzYtBjASYSdBMAZkZDD58MrwOJyC E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAL0VhFOtJV2P/2dsb2JhbABZgweBKsIVAYEMFnSCJQEBAQMBOkQLAgEINhAyJQIEARKIOgjUGReOHzqDK4EVAQOZc5MngziCLw X-IronPort-AV: E=Sophos;i="4.98,916,1392163200"; d="scan'208";a="47455761" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-5.cisco.com with ESMTP; 27 May 2014 04:37:46 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s4R4bkEK020397 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 May 2014 04:37:46 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.239]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Mon, 26 May 2014 23:37:46 -0500 From: "Joseph Salowey (jsalowey)" To: "" , "draft-moonesamy-sshfp-ed25519.all@tools.ietf.org" , "iesg@ietf.org IESG" Thread-Topic: secdir review of draft-moonesamy-sshfp-ed25519-01 Thread-Index: AQHPeWUfo5K1BZN1JUqd29NR7Q9teZtUK+AA Date: Tue, 27 May 2014 04:37:45 +0000 Message-ID: <09CA9BB8-E476-40B3-BEB3-FA3BB20FDAA8@cisco.com> References: <2ACBFFE4-BCEB-4F6D-A2D3-861BADF543DE@cisco.com> In-Reply-To: <2ACBFFE4-BCEB-4F6D-A2D3-861BADF543DE@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.116] Content-Type: text/plain; charset="us-ascii" Content-ID: <1D2A5B0EA26C5541A60F533C3EE44681@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/OwHPu_0c_QCYmBS3AhGJVRoeZSQ Subject: Re: [secdir] secdir review of draft-moonesamy-sshfp-ed25519-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 04:37:52 -0000 On May 26, 2014, at 9:35 PM, Joe Salowey wrote: > 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. >=20 > This document defines an SSHFP DNS record for ED25519 signature algorithm= . The document is ready with issues: >=20 > 1) This document describes how to store the fingerprint of a public key = that can be used with the ed25519 signature algorithm. I do not see any re= ference as to how to use the ed25519 signature algorithm in SSH. Perhaps I= am missing a reference somewhere, but it really seems that the use of the = signature algorithm in SSH should be defined somewhere, preferably in an IE= TF document. I so not see the point of publishing the SSHFP record documen= t without some reference as to how it will be used.=20 >=20 > 2) The examples in RFC 6594 include the OpenSSH formatted key that is de= coded and hashed to obtain the resulting fingerprint. It would be better i= f the draft followed this aspect of 6594 and included the key used to gener= ate the fingerprint. =20 >=20 > Joe From nobody Mon May 26 21:46:26 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0444C1A036C; Mon, 26 May 2014 21:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFBMH4f9PEtP; Mon, 26 May 2014 21:46:23 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C77171A0363; Mon, 26 May 2014 21:46:22 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id k48so8989777wev.3 for ; Mon, 26 May 2014 21:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=6Yx8mzPeycxzYNJvTRX7n+JL3ulosEXuFbD+FZogEds=; b=X8WquNOdnoli6SycfcDvEg+y9Z1TA/WYhDPn8RWwiWkICjBo0TwEsRaFvpdh4/dM7P xDJLxNC7M+LTcozbJi/bzQcy7SvLZNPvNTIT+pGjufNsDO6H4xlkqBXf/qZuvn5hZznk xgoID/CMCA3SYOPwd9zm5w8I9Z4MxroV530uPv+F0e1UaEizgqBuyZf3TY6UNcxX6Gb5 MP0UzHRd7qZPC1CjNj6df2sodTYV7vX1jSbY+pfnIlxuDmG289yOlCCSs+wXFRmCH7Ds uhO3bg7I2qXvx4AbjfaeNSyPocPaOHvJh033XYn1os4kUB6ukabttMA4WTRwalh45s2Z Dn6Q== MIME-Version: 1.0 X-Received: by 10.194.133.1 with SMTP id oy1mr19575284wjb.87.1401165978617; Mon, 26 May 2014 21:46:18 -0700 (PDT) Received: by 10.180.94.138 with HTTP; Mon, 26 May 2014 21:46:18 -0700 (PDT) Date: Mon, 26 May 2014 21:46:18 -0700 Message-ID: From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= To: "secdir@ietf.org" , draft-pal-eidr-urn@tools.ietf.org Content-Type: multipart/alternative; boundary=089e01228d466d4d6e04fa5a6092 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/INzy8qAwMpGOE8fhWqlM4hiPock Cc: "iesg@ietf.org" Subject: [secdir] Secdir review of draft-pal-eidr-urn-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 04:46:24 -0000 --089e01228d466d4d6e04fa5a6092 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 defines the URN namespace identifier for the entertainment > industry's registered identifiers for audiovisual works. As such, it only > specifies the syntax of these identifiers and the Sec Cons sections looks > adequate to me. > Thanks, -- Magnus --089e01228d466d4d6e04fa5a6092 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I have reviewed this= document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the IE= SG. These comments were written primarily for the benefit of the security=20 area directors. Document editors and WG chairs should treat these=20 comments just like any other last call comments.
=C2=A0
This = document defines the URN namespace identifier for the=C2=A0entertainment in= dustry's=C2=A0registered identifiers for audiovisual works. As such, it= only specifies the syntax of these identifiers and the Sec Cons sections l= ooks adequate to me.

Thanks,
-- Magnus
--089e01228d466d4d6e04fa5a6092-- From nobody Tue May 27 23:30:30 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3B01A036F; Tue, 27 May 2014 23:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gTvGIgwqV-D; Tue, 27 May 2014 23:30:21 -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 4E1BC1A0376; Tue, 27 May 2014 23:30:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHH81182; Wed, 28 May 2014 06:30:15 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 28 May 2014 07:29:36 +0100 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 28 May 2014 07:30:07 +0100 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.210]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.03.0158.001; Wed, 28 May 2014 14:29:59 +0800 From: Tina TSOU To: "" , The IESG , "draft-ietf-pce-pcep-inter-domain-p2mp-procedure.all@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-pce-pcep-inter-domain-p2mp-procedure-06 Thread-Index: Ac96Pf0qE//zx0DMR8GgI7NIsiLOdA== Date: Wed, 28 May 2014 06:29:58 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.108.8] Content-Type: multipart/alternative; boundary="_000_C0E0A32284495243BDE0AC8A066631A8182EEFFBszxeml557mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/KOUajfNIMsq8oWlVovy7kjk1H7s Subject: [secdir] Secdir review of draft-ietf-pce-pcep-inter-domain-p2mp-procedure-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 06:30:26 -0000 --_000_C0E0A32284495243BDE0AC8A066631A8182EEFFBszxeml557mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, 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. Technical comments: This draft focused on solving inter-domain P2MP procedures. The solution is= based on a core-tree and corresponding sub-trees construction, with BRPC u= sed as reference. The procedure in this draft is complete and promising for= an inter-domain P2MP path computation. However, for future work, following= comments may be considered: Now each PCE is considered friendly with each other, i.e., the cost on the = sub-tree will be reflected on the core-tree, and the signals are free to be= transmitted correspondingly. But, this is the ideal case, PCE may need to = hide some intra-domain information due to some security policies, so that g= lobal optimization may not be achieved. In this way, it should be better to= split into a few scenarios, such as 'friendly' and 'not friendly' case. In= the 'not friendly' scenario, it is also necessary to limit what signal is = allowed and what is prohibited. There is no much existing work for this sce= nario, even for a P2P path computation, so the work for P2MP computation in= this scenario should be listed as future work. Nits: In section 1, captions are not numbered correctly. The item "scope" and "Re= quirements Language" should be section 1.1 and 1.2 respectively. In section 3, the 5th paragraph, "as discussed in [RFC4461], ...", the last= sentence should be changed as follow: Not only is this selection constrained by the network topology and availabl= e network resources, but it is also determined by the objective functions (= OF) that may be applied to path computation. Then in the next paragraph, "Generally, an inter-domain ...", following cha= nges are suggested: For instance, while the BRPC may be well-suited for P2P paths, P2MP path co= mputation involves multiple branching path segments from the source to them= ultiple destinations. As such, inter-domain P2MP path computation may resul= t in a plurality of per-domain path options that may be difficult to coordi= nate efficiently and effectively between among domains. In the second paragraph from bottom of Section 3, "P2MP Minimum Cost Tree (= MCT), ...", following changes are suggested: P2MP Minimum Cost Tree (MCT), i.e., a computation which guarantees the leas= t cost resulting tree, typically is an NP-complete problem. Moreover, addin= g and/or removing a single destination to/from the tree may result in an en= tirely different tree. In this casethese cases, frequent MCT path computat= ion requests may prove computationally intensive, and the resulting frequen= t tunnel reconfiguration may even cause network destabilization. For section 4, the first assumption is suggested to be: Due to deployment and commercial limitations (e.g., inter-AS peering agreem= ents), the path domain tree willshould be known in advance; For section 5, the 4th requirements is suggested to change: 4. Specifying which nodes are being used as branch nodes SHOULD be s= upported in the PCReq. For section 7.2, in the paragraph "Without trimming, the ingress...", the f= ollowing change is recommended: Without trimming, the ingress PCE will obtain all the possible S2L sub-path= s set for the entry boundary nodes of the leaf domain. The PCE will then, b= y looking through all the combinations and taking one sub-path from each se= t to build one tree, canselect the optimal core-tree. For section 7.3, in the paragraph "Note that the P2MP path request...", the= following change is recommended: Note that the P2MP path request and response format is as per [RFC6006], wh= ere Record Route Object (RRO) areis used to carry the core-tree paths in th= e P2MP grafting request. For section 8.1, the following change is recommended: 8.1. End-to-end Protection An end-to-end protection (for nodes and links) principle can be applied = for computing backup P2MP TE LSPs. During computation of the core-tree and= sub-trees, the computation of protection may also be taken into considerat= ion. A PCE may compute the primary and backup P2MP TE LSP together or seque= ntially. Thank you, Tina --_000_C0E0A32284495243BDE0AC8A066631A8182EEFFBszxeml557mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,=

 

I have reviewed this docume= nt 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.  Do= cument editors and WG chairs should treat these comments just like any othe= r last call comments.

 

Technical comments:=

This draft focu= sed on solving inter-domain P2MP procedures. The solution is based on a cor= e-tree and corresponding sub-trees construction, with BRPC used as reference. The procedure in this draft is complete and promising f= or an inter-domain P2MP path computation. However, for future work, followi= ng comments may be considered:

Now each PCE is= considered friendly with each other, i.e., the cost on the sub-tree will b= e reflected on the core-tree, and the signals are free to be transmitted correspondingly. But, this is the ideal case, PCE may need = to hide some intra-domain information due to some security policies, so tha= t global optimization may not be achieved. In this way, it should be better= to split into a few scenarios, such as ‘friendly’ and ‘not friendly’ case. In the= ‘not friendly’ scenario, it is also necessary to limit what si= gnal is allowed and what is prohibited. There is no much existing work for = this scenario, even for a P2P path computation, so the work for P2MP computation in this scenario should be listed as future work.

 

Nits:

In section 1, captions are not= numbered correctly. The item “scope” and “Requirements L= anguage” should be section 1.1 and 1.2 respectively.

 

In section 3, the 5th paragraph, “as discussed in [RFC4461], …”, the last se= ntence should be changed as follow:

Not only is this selection con= strained by the network topology and available network resources, but it is also determined by the objectiv= e functions (OF) that may be applied to path computation.=

 

Then in the next paragraph, &#= 8220;Generally, an inter-domain …”, following changes are sugge= sted:

For instance, while the BRPC m= ay be well-suited for P2P paths, P2MP path computation involves multiple br= anching path segments from the source to themultiple destinations. As such, = inter-domain P2MP path computation may result in a plurality of per-domain = path options that may be difficult to coordinate efficiently and effectivel= y between among domains.

 

In the second paragraph from b= ottom of Section 3, “P2MP Minimum Cost Tree (MCT), …”, fo= llowing changes are suggested:

P2MP Minimum Cost Tree (MCT), = i.e., a computation which guarantees the least cost resulting tree, typical= ly is an NP-complete problem. Moreover, adding and/or removing a single destination to/from the tree may result in an entirely different = tree.  In this casethese cases, frequent MCT path computation requests may p= rove computationally intensive, and the resulting frequent tunnel reconfigu= ration may even cause network destabilization.

 

For section 4, the first assum= ption is suggested to be:

Due to deployment and commerci= al limitations (e.g., inter-AS peering agreements), the path domain tree willshould be known in advance;

 

For section 5, the 4th requirements is suggested to change:

     =  4.  Specifying which nodes are being used as branch nodes SHOULD be supported in the PCReq.

 

For section 7.2, in the paragr= aph “Without trimming, the ingress…”, the following chang= e is recommended:

Without trimming, the ingress = PCE will obtain all the possible S2L sub-paths set for the entry boundary n= odes of the leaf domain. The PCE will then, by looking through all the combinations and taking one sub-path from each set to build one tr= ee,  canselect the optimal core-tree.<= /o:p>

 

For section 7.3, in the paragr= aph “Note that the P2MP path request…”, the following cha= nge is recommended:

Note that the P2MP path reques= t and response format is as per [RFC6006], where Record Route Object (RRO) areis used to carry the core-tree paths in the P2MP grafting reque= st.

 

For section 8.1, the following= change is recommended:

8.1. End-to-end Protection

   An end-to-end pro= tection (for nodes and links) principle can be applied for computing backup= P2MP TE LSPs.  During computation of the core-tree and sub-trees, the computation of protection m= ay also be taken into consideration. A PCE may compute the primary and back= up P2MP TE LSP together or sequentially.

 

 

Thank you,

Tina

 

--_000_C0E0A32284495243BDE0AC8A066631A8182EEFFBszxeml557mbschi_-- From nobody Wed May 28 00:06:05 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCFEC1A0816; Wed, 28 May 2014 00:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5AhvAbOHan8; Wed, 28 May 2014 00:06:01 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 633BB1A0814; Wed, 28 May 2014 00:06:01 -0700 (PDT) Received: from [192.168.1.8] (unknown [119.94.254.248]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id D3A8418013DA; Wed, 28 May 2014 09:05:53 +0200 (CEST) Message-ID: <53858ACE.8030909@pi.nu> Date: Wed, 28 May 2014 09:05:50 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Vero Zheng , Manav Bhatia , Yaron Sheffer References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> <537BC7B6.5040406@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B609@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C5BCE.4010801@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B6A8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C7EDB.9050000@cs.tcd.ie> <537C86D6.1030703@pi.nu> <20211F91F544D247976D84C5D778A4C32E60BA5C@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537CA2D2.4070103@cs.tcd.ie> <54E263B5-41C7-4523-9941-B3E39AE077CD@mit.edu> <57ee448f94f94cd7ba040903e604aa3c@SG70XWXCHHUB01.zap.alcatel-lucent.com> <2EEA459CD95CCB4988BFAFC0F2287B5C5C8302E4@SZXEMA504-MBS.china.huawei.com> In-Reply-To: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8302E4@SZXEMA504-MBS.china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/0Wx9LMM4A348oc1W1sOVCaPdf2M Cc: "Bhatia, Manav \(Manav\)" , IETF Security Directorate , "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" , The IESG Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 07:06:04 -0000 All, Do I understand correctly if we are now OK to go ahead and have this draft approved? /Loa On 2014-05-26 03:30, Vero Zheng wrote: > Thanks Yaron and Manav for working this out. > > I have just confirmed the post. > > Cheers, Vero > > *From:*Manav Bhatia [mailto:manavbhatia@gmail.com] > *Sent:* Sunday, May 25, 2014 1:50 PM > *To:* Yaron Sheffer > *Cc:* Uri Blumenthal; Stephen Farrell; Bhatia, Manav (Manav); IETF > Security Directorate; > draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org; The IESG; Loa > Andersson > *Subject:* Re: [secdir] SecDir review of > draft-ietf-mpls-ldp-hello-crypto-auth-05 > > Hi, > > Yaron, I and few of us exchanged quite a few emails offline and we have > come up with a version that addresses Yaron's and Stephen's concerns > about repeating the HMAC stuff thats already present in RFC 2104. We've > cleaned it up pretty nicely with very minimal changes. > > I am unable to submit this latest and the greatest version since i have > updated my email ID in this version. The tracker requires one of the > co-authors to authenticate/approve the submission. > > I am attaching the latest version with this email in case folks want to > go through this till it becomes available formally. > > The draft is all set to fly now! :-) > > Cheers, Manav > > On Wed, May 21, 2014 at 7:54 PM, Yaron Sheffer > wrote: > > IMHO, this is purely a naming problem. Apad does NOT modify the base > HMAC, please see > http://tools.ietf.org/html/draft-ietf-mpls-ldp-hello-crypto-auth-05#section-5. > It is just one more thing that's signed by HMAC. > > My problem with this draft is that they have different ideas about the > key length, compared to RFC 2104 (top of Sec. 5.1). Also, I am unhappy > that they spell out the HMAC construction instead of leaving it as a > black box. > > But I think Apad is just fine, if it weren't for the unfortunate name > that leads people to think it's modifying HMAC. > > Thanks, > Yaron > > > On 05/21/2014 04:28 PM, Uri Blumenthal wrote: > >> Once again, please. >> >> 1. Who specifically, at NIST and at IESG, says that HMAC needs Apad for security reasons (and therefore is not secure as-is)? >> >> 2. What are those security reasons, and what are the attacks that are foiled by Apad? >> >> 3. What published papers/references/whatever is this documented? As HMAC came with security proofs, I’d like to see where and how they are invalidated (if they indeed are). >> >> >> >> On May 21, 2014, at 8:57 , Stephen Farrell > wrote: >> >>> >>> >>> On 21/05/14 12:14, Bhatia, Manav (Manav) wrote: >>>> I agree with Loa. >>>> >>>> Our current draft is very simple and has gone through multiple >>>> iterations of reviews in at least two WGs. It brings LDP to the same >>>> level of security as other protocols running in the networks. >>> >>> Fully agree with that goal. >>> >>>> >>>> I think we should just push it forward and if there is an interest in >>>> writing a new ID that updates HMAC specification, then we write one >>>> that includes the Apad stuff. I think the latter should anyways be >>>> done, regardless of what happens to this particular draft. >>> >>> I need to read it. But I'd be happier if that HMAC draft existed >>> and was going to be processed - then we wouldn't have to do this >>> discussion again. >>> >>> Cheers, >>> S. >>> >>>> >>>> The IETF submission site is down and hence couldn’t upload the >>>> revised ID (addressing Yaron's comments). Will do it tomorrow once >>>> its up. >>>> >>>> After that its ready to be placed before the IESG. >>>> >>>> Cheers, Manav >>>> >>>>> -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu ] >>>>> Sent: Wednesday, May 21, 2014 4:29 PM To: Manav Bhatia; Stephen >>>>> Farrell Cc: Bhatia, Manav (Manav); IETF Security Directorate; The >>>>> IESG; draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org > ; >>>>> Yaron Sheffer Subject: Re: SecDir review of >>>>> draft-ietf-mpls-ldp-hello-crypto-auth-05 >>>>> >>>>> Folks, >>>>> >>>>> I'm only the document shepherd. My feeling is that we are raising >>>>> the hurdle step by step for the KARP - initiated RFCs, the first >>>>> was comparatively smooth, now we are trying to put an 18 months >>>>> effort (individual draft to RFC) in front of approving something >>>>> that is comparatively simple and seen as raising LDP to the same >>>>> security as the other routing protocols. >>>>> >>>>> So if we get to tired to push this, we are all better off not >>>>> doing the security work for this particular protocol? >>>>> >>>>> Someone said - "Never let the best be the enemy of the possible"! >>>>> >>>>> /Loa >>>>> >>>>> >>>>> >>>>> On 2014-05-21 12:39, Manav Bhatia wrote: >>>>>> Stephen, >>>>>> >>>>>>>> This however is a long drawn discussion because everyone >>>>>>>> needs to >>>>> be >>>>>>>> convinced on the merits of updating the HMAC specification -- >>>>>>>> which >>>>> I >>>>>>>> am not sure will take how long. >>>>>>> >>>>>>> So I need to look at this draft, HMAC and the other cases but >>>>>>> it seems to me that you're copying a page or two of crypto spec >>>>>>> each time and changing one line. Doing that over and over is a >>>>>>> recipe for long term pain, isn't it? >>>>>> >>>>>> It sure is. >>>>>> >>>>>> I had volunteered to write a 1-2 page long ID that updated the >>>>>> HMAC >>>>> to >>>>>> include the Apad, but the idea was shot down. The only >>>>>> alternative left was to include the crypto stuff in each standard >>>>>> that we wrote later. >>>>>> >>>>>>> >>>>>>> (And we've had this discussion for each such draft while I've >>>>>>> been on the IESG I think, which is also somewhat drawn out;-) >>>>>> >>>>>> This draft is probably the last one thats coming from the Routing >>>>>> WG which will have this level of crypto mathematics spelled out. >>>>>> All other IGPs are already covered. In case we need to change >>>>>> something >>>>> in >>>>>> the ones already covered we can refer to the base RFC where we >>>>>> have detailed the crypto maths. For example, >>>>>> draft-ietf-ospf-security-extension-manual-keying-08 amongst >>>>>> other things also updates the definition of Apad. It points to >>>>>> the exact mathematics in RFC 5709 and only updates the Apad >>>>>> definition in that draft. This draft btw has cleared the WG LC >>>>>> and would be appearing before you guys very soon. >>>>>> >>>>>> Given this, i think we should just pass this draft with this >>>>>> level of details. Subsequently, when LDP wants to update >>>>>> something, it can normatively refer to this RFC and only give the >>>>>> changes. >>>>>> >>>>>> Cheers, Manav >>>>>> >>>>>>> >>>>>>> S. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Cheers, Manav >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> S >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Cheers, Manav >>>>>>>>>> >>>>>>>>>>> -----Original Message----- From: Stephen Farrell >>>>>>>>>>> [mailto:stephen.farrell@cs.tcd.ie ] Sent: > Wednesday, May >>>>>>>>>>> 21, 2014 2:53 AM To: Bhatia, Manav (Manav); IETF >>>>>>>>>>> Security Directorate; The IESG; draft- >>>>>>>>>>>ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org > Cc: >>>>>>>>>>> Yaron Sheffer;manavbhatia@gmail.com Subject: Re: >>>>>>>>>>> SecDir review of >>>>>>>>>>> draft-ietf-mpls-ldp-hello-crypto-auth-05 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 19/05/14 21:27, Yaron Sheffer wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> * 5.1: Redefining HMAC (RFC 2104) is an extremely >>>>>>>>>>>>>> bad idea. This reviewer does not have the >>>>>>>>>>>>>> appropriate background to critique the proposed >>>>>>>>>>>>>> solution, but there must be an overwhelming >>>>>>>>>>>>>> reason to >>>>>>>>>>> reopen> >>>>> cryptographic primitives. >>>>>>>>>>>>> >>>>>>>>>>>>> This is a decision that was taken by Sec Ads when >>>>>>>>>>>>> we were doing the crypto protection for the IGPs >>>>>>>>>>>>> based on some feedback from NIST. >>>>>>>>>>> This >>>>>>>>>>>>> mathematics is not new and has been done for all >>>>>>>>>>>>> IGPs and has been approved and rather encouraged by >>>>>>>>>>>>> the Security ADs. >>>>>>>>>>> >>>>>>>>>>> The above does not sound like something I recognise. I >>>>>>>>>>> have repeatedly asked that documents not re-define >>>>>>>>>>> HMAC. Perhaps this time, I'll make that a DISCUSS and >>>>>>>>>>> not budge. I probably should have done that before >>>>>>>>>>> TBH. >>>>>>>>>>> >>>>>>>>>>> If you are revising that doc, *please* get rid of the >>>>>>>>>>> re-definition and just properly refer to HMAC. Its >>>>>>>>>>> about time to stop repeating that error. >>>>>>>>>>> >>>>>>>>>>> S. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> Loa Andersson email:loa@mail01.huawei.com >>>>> Senior MPLS Expertloa@pi.nu Huawei >>>>> Technologies (consultant) phone:+46 739 81 21 64 >>> >>> _______________________________________________ >>> secdir mailing list >>>secdir@ietf.org >>>https://www.ietf.org/mailman/listinfo/secdir >>> wiki:http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >> >> _______________________________________________ >> secdir mailing list >>secdir@ietf.org >>https://www.ietf.org/mailman/listinfo/secdir >> wiki:http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >> > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed May 28 00:07:15 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5D21A0816; Wed, 28 May 2014 00:07:02 -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 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 zeueRa7Su74d; Wed, 28 May 2014 00:06:54 -0700 (PDT) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F12081A0384; Wed, 28 May 2014 00:06:53 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id j17so10663254oag.15 for ; Wed, 28 May 2014 00:06:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ybqDp56YYkD9MjD9CNtoG5a5dVCWNldrbQway4HY78w=; b=sEfvbojWKiufh0yXWIzzlIQvr7LBV8soIXcqUnfRODd64rswXAk4SzVrk3P9x6+Psy pjRw2pqR3CNkWK/+EryRtlM714T5ELE7YVQL1G2jXf2VZ2uiglzFJeHbjL9wOKCpTeqi xV8ZVRMgL5unTP9VfjKsIu6aZ2syVA4HA+wSyQbeaOM9tbUTXC/Y9y8ZpjNuOjzWeivO JjddfAiGuPQb7ggIZEvvpgVEc2XRaP7cSMNIRM/CL9Odzsm9R0R1rJnKBDdbA1JG8nuW MmbMDfYcktsFtHJblG8VF4foYayrPGu+wMPUa9e0tFUgintgNRK+vRIQXJ6HbCoW+N5t U45g== MIME-Version: 1.0 X-Received: by 10.60.45.4 with SMTP id i4mr39049204oem.49.1401260810295; Wed, 28 May 2014 00:06:50 -0700 (PDT) Received: by 10.76.77.97 with HTTP; Wed, 28 May 2014 00:06:50 -0700 (PDT) In-Reply-To: <53858ACE.8030909@pi.nu> References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> <537BC7B6.5040406@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B609@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C5BCE.4010801@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B6A8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C7EDB.9050000@cs.tcd.ie> <537C86D6.1030703@pi.nu> <20211F91F544D247976D84C5D778A4C32E60BA5C@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537CA2D2.4070103@cs.tcd.ie> <54E263B5-41C7-4523-9941-B3E39AE077CD@mit.edu> <57ee448f94f94cd7ba040903e604aa3c@SG70XWXCHHUB01.zap.alcatel-lucent.com> <2EEA459CD95CCB4988BFAFC0F2287B5C5C8302E4@SZXEMA504-MBS.china.huawei.com> <53858ACE.8030909@pi.nu> Date: Wed, 28 May 2014 12:36:50 +0530 Message-ID: From: Manav Bhatia To: Loa Andersson Content-Type: multipart/alternative; boundary=089e0149cb9cd6295e04fa707425 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/KOJrIGc2FEpgkGX17kaQ_geqZUk Cc: "Bhatia, Manav \(Manav\)" , IETF Security Directorate , "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" , The IESG , Vero Zheng Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 07:07:03 -0000 --089e0149cb9cd6295e04fa707425 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yup, thats correct! On Wed, May 28, 2014 at 12:35 PM, Loa Andersson wrote: > All, > > Do I understand correctly if we are now OK to go ahead and have > this draft approved? > > /Loa > > > On 2014-05-26 03:30, Vero Zheng wrote: > >> Thanks Yaron and Manav for working this out. >> >> I have just confirmed the post. >> >> Cheers, Vero >> >> *From:*Manav Bhatia [mailto:manavbhatia@gmail.com] >> *Sent:* Sunday, May 25, 2014 1:50 PM >> *To:* Yaron Sheffer >> *Cc:* Uri Blumenthal; Stephen Farrell; Bhatia, Manav (Manav); IETF >> >> Security Directorate; >> draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org; The IESG; Loa >> Andersson >> *Subject:* Re: [secdir] SecDir review of >> >> draft-ietf-mpls-ldp-hello-crypto-auth-05 >> >> Hi, >> >> Yaron, I and few of us exchanged quite a few emails offline and we have >> come up with a version that addresses Yaron's and Stephen's concerns >> about repeating the HMAC stuff thats already present in RFC 2104. We've >> cleaned it up pretty nicely with very minimal changes. >> >> I am unable to submit this latest and the greatest version since i have >> updated my email ID in this version. The tracker requires one of the >> co-authors to authenticate/approve the submission. >> >> I am attaching the latest version with this email in case folks want to >> go through this till it becomes available formally. >> >> The draft is all set to fly now! :-) >> >> Cheers, Manav >> >> On Wed, May 21, 2014 at 7:54 PM, Yaron Sheffer > > wrote: >> >> IMHO, this is purely a naming problem. Apad does NOT modify the base >> HMAC, please see >> http://tools.ietf.org/html/draft-ietf-mpls-ldp-hello- >> crypto-auth-05#section-5. >> It is just one more thing that's signed by HMAC. >> >> My problem with this draft is that they have different ideas about the >> key length, compared to RFC 2104 (top of Sec. 5.1). Also, I am unhappy >> that they spell out the HMAC construction instead of leaving it as a >> black box. >> >> But I think Apad is just fine, if it weren't for the unfortunate name >> that leads people to think it's modifying HMAC. >> >> Thanks, >> Yaron >> >> >> On 05/21/2014 04:28 PM, Uri Blumenthal wrote: >> >> Once again, please. >>> >>> 1. Who specifically, at NIST and at IESG, says that HMAC needs Apad for >>> security reasons (and therefore is not secure as-is)? >>> >>> 2. What are those security reasons, and what are the attacks that are >>> foiled by Apad? >>> >>> 3. What published papers/references/whatever is this documented? As HMA= C >>> came with security proofs, I=E2=80=99d like to see where and how they a= re >>> invalidated (if they indeed are). >>> >>> >>> >>> On May 21, 2014, at 8:57 , Stephen Farrell >> stephen.farrell@cs.tcd.ie>> wrote: >>> >>> >>>> >>>> On 21/05/14 12:14, Bhatia, Manav (Manav) wrote: >>>> >>>>> I agree with Loa. >>>>> >>>>> Our current draft is very simple and has gone through multiple >>>>> iterations of reviews in at least two WGs. It brings LDP to the same >>>>> level of security as other protocols running in the networks. >>>>> >>>> >>>> Fully agree with that goal. >>>> >>>> >>>>> I think we should just push it forward and if there is an interest in >>>>> writing a new ID that updates HMAC specification, then we write one >>>>> that includes the Apad stuff. I think the latter should anyways be >>>>> done, regardless of what happens to this particular draft. >>>>> >>>> >>>> I need to read it. But I'd be happier if that HMAC draft existed >>>> and was going to be processed - then we wouldn't have to do this >>>> discussion again. >>>> >>>> Cheers, >>>> S. >>>> >>>> >>>>> The IETF submission site is down and hence couldn=E2=80=99t upload th= e >>>>> revised ID (addressing Yaron's comments). Will do it tomorrow once >>>>> its up. >>>>> >>>>> After that its ready to be placed before the IESG. >>>>> >>>>> Cheers, Manav >>>>> >>>>> -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu>>>>> loa@pi.nu>] >>>>>> >>>>>> Sent: Wednesday, May 21, 2014 4:29 PM To: Manav Bhatia; Stephen >>>>>> Farrell Cc: Bhatia, Manav (Manav); IETF Security Directorate; The >>>>>> IESG; draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org >>>>>> >>>>> ; >> >>> Yaron Sheffer Subject: Re: SecDir review of >>>>>> draft-ietf-mpls-ldp-hello-crypto-auth-05 >>>>>> >>>>>> Folks, >>>>>> >>>>>> I'm only the document shepherd. My feeling is that we are raising >>>>>> the hurdle step by step for the KARP - initiated RFCs, the first >>>>>> was comparatively smooth, now we are trying to put an 18 months >>>>>> effort (individual draft to RFC) in front of approving something >>>>>> that is comparatively simple and seen as raising LDP to the same >>>>>> security as the other routing protocols. >>>>>> >>>>>> So if we get to tired to push this, we are all better off not >>>>>> doing the security work for this particular protocol? >>>>>> >>>>>> Someone said - "Never let the best be the enemy of the possible"! >>>>>> >>>>>> /Loa >>>>>> >>>>>> >>>>>> >>>>>> On 2014-05-21 12:39, Manav Bhatia wrote: >>>>>> >>>>>>> Stephen, >>>>>>> >>>>>>> This however is a long drawn discussion because everyone >>>>>>>>> needs to >>>>>>>>> >>>>>>>> be >>>>>> >>>>>>> convinced on the merits of updating the HMAC specification -- >>>>>>>>> which >>>>>>>>> >>>>>>>> I >>>>>> >>>>>>> am not sure will take how long. >>>>>>>>> >>>>>>>> >>>>>>>> So I need to look at this draft, HMAC and the other cases but >>>>>>>> it seems to me that you're copying a page or two of crypto spec >>>>>>>> each time and changing one line. Doing that over and over is a >>>>>>>> recipe for long term pain, isn't it? >>>>>>>> >>>>>>> >>>>>>> It sure is. >>>>>>> >>>>>>> I had volunteered to write a 1-2 page long ID that updated the >>>>>>> HMAC >>>>>>> >>>>>> to >>>>>> >>>>>>> include the Apad, but the idea was shot down. The only >>>>>>> alternative left was to include the crypto stuff in each standard >>>>>>> that we wrote later. >>>>>>> >>>>>>> >>>>>>>> (And we've had this discussion for each such draft while I've >>>>>>>> been on the IESG I think, which is also somewhat drawn out;-) >>>>>>>> >>>>>>> >>>>>>> This draft is probably the last one thats coming from the Routing >>>>>>> WG which will have this level of crypto mathematics spelled out. >>>>>>> All other IGPs are already covered. In case we need to change >>>>>>> something >>>>>>> >>>>>> in >>>>>> >>>>>>> the ones already covered we can refer to the base RFC where we >>>>>>> have detailed the crypto maths. For example, >>>>>>> draft-ietf-ospf-security-extension-manual-keying-08 amongst >>>>>>> other things also updates the definition of Apad. It points to >>>>>>> the exact mathematics in RFC 5709 and only updates the Apad >>>>>>> definition in that draft. This draft btw has cleared the WG LC >>>>>>> and would be appearing before you guys very soon. >>>>>>> >>>>>>> Given this, i think we should just pass this draft with this >>>>>>> level of details. Subsequently, when LDP wants to update >>>>>>> something, it can normatively refer to this RFC and only give the >>>>>>> changes. >>>>>>> >>>>>>> Cheers, Manav >>>>>>> >>>>>>> >>>>>>>> S. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Cheers, Manav >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> S >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Cheers, Manav >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- From: Stephen Farrell >>>>>>>>>>>> [mailto:stephen.farrell@cs.tcd.ie >>>>>>>>>>> tcd.ie>] Sent: >>>>>>>>>>>> >>>>>>>>>>> Wednesday, May >> >>> 21, 2014 2:53 AM To: Bhatia, Manav (Manav); IETF >>>>>>>>>>>> Security Directorate; The IESG; draft- >>>>>>>>>>>> ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org >>>>>>>>>>>> >>>>>>>>>>> Cc: >> >>> Yaron Sheffer;manavbhatia@gmail.com >>>>>>>>>>>> Subject: Re: >>>>>>>>>>>> >>>>>>>>>>>> SecDir review of >>>>>>>>>>>> draft-ietf-mpls-ldp-hello-crypto-auth-05 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 19/05/14 21:27, Yaron Sheffer wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> * 5.1: Redefining HMAC (RFC 2104) is an extremely >>>>>>>>>>>>>>> bad idea. This reviewer does not have the >>>>>>>>>>>>>>> appropriate background to critique the proposed >>>>>>>>>>>>>>> solution, but there must be an overwhelming >>>>>>>>>>>>>>> reason to >>>>>>>>>>>>>>> >>>>>>>>>>>>>> reopen> >>>>> cryptographic primitives. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> This is a decision that was taken by Sec Ads when >>>>>>>>>>>>>> we were doing the crypto protection for the IGPs >>>>>>>>>>>>>> based on some feedback from NIST. >>>>>>>>>>>>>> >>>>>>>>>>>>> This >>>>>>>>>>>> >>>>>>>>>>>>> mathematics is not new and has been done for all >>>>>>>>>>>>>> IGPs and has been approved and rather encouraged by >>>>>>>>>>>>>> the Security ADs. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> The above does not sound like something I recognise. I >>>>>>>>>>>> have repeatedly asked that documents not re-define >>>>>>>>>>>> HMAC. Perhaps this time, I'll make that a DISCUSS and >>>>>>>>>>>> not budge. I probably should have done that before >>>>>>>>>>>> TBH. >>>>>>>>>>>> >>>>>>>>>>>> If you are revising that doc, *please* get rid of the >>>>>>>>>>>> re-definition and just properly refer to HMAC. Its >>>>>>>>>>>> about time to stop repeating that error. >>>>>>>>>>>> >>>>>>>>>>>> S. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> Loa Andersson email:loa@mail01.huawei.com>>>>> loa@mail01.huawei.com> >>>>>> Senior MPLS Expertloa@pi.nu Huawei >>>>>> Technologies (consultant) phone:+46 739 81 21 64>>>>> 2064> >>>>>> >>>>> >>>> _______________________________________________ >>>> secdir mailing list >>>> secdir@ietf.org >>>> >>>> https://www.ietf.org/mailman/listinfo/secdir >>>> wiki:http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >>>> >>> >>> _______________________________________________ >>> secdir mailing list >>> secdir@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/secdir >>> wiki:http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >>> >>> >> > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > --089e0149cb9cd6295e04fa707425 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yup, thats correct!

On Wed, May 28, 2014 at 12:35 PM, Loa Andersso= n <loa@= pi.nu> wrote:
All,

Do I understand correctly if we are now OK to go ahead and have
this draft approved?

/Loa


On 2014-05-26 03:30, Vero Zheng wrote:
Thanks Yaron and Manav for working this out.

I have just confirmed the post.

Cheers, Vero

*From:*Manav Bhatia [mailto:manavbhatia@gmail.com]
*Sent:* Sunday, May 25, 2014 1:50 PM
*To:* Yaron Sheffer
*Cc:* Uri Blumenthal; Stephen Farrell; Bhatia, Manav (Manav); IETF

Security Directorate;
draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.i= etf.org; The IESG; Loa
Andersson
*Subject:* Re: [secdir] SecDir review of

draft-ietf-mpls-ldp-hello-crypto-auth-05

Hi,

Yaron, I and few of us exchanged quite a few emails offline and we have
come up with a version that addresses Yaron's and Stephen's concern= s
about repeating the HMAC stuff thats already present in RFC 2104. We've=
cleaned it up pretty nicely with very minimal changes.

I am unable to submit this latest and the greatest version since i have
updated my email ID in this version. The tracker requires one of the
co-authors to authenticate/approve the submission.

I am attaching the latest version with this email in case folks want to
go through this till it becomes available formally.

The draft is all set to fly now! :-)

Cheers, Manav

On Wed, May 21, 2014 at 7:54 PM, Yaron Sheffer <yaronf.ietf@gmail.com
<mailto:yaron= f.ietf@gmail.com>> wrote:

IMHO, this is purely a naming problem. Apad does NOT modify the base
HMAC, please see
http://tools.ietf.org/html/draft-ie= tf-mpls-ldp-hello-crypto-auth-05#section-5.
It is just one more thing that's signed by HMAC.

My problem with this draft is that they have different ideas about the
key length, compared to RFC 2104 (top of Sec. 5.1). Also, I am unhappy
that they spell out the HMAC construction instead of leaving it as a
black box.

But I think Apad is just fine, if it weren't for the unfortunate name that leads people to think it's modifying HMAC.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Yaron


On 05/21/2014 04:28 PM, Uri Blumenthal wrote:

Once again, please.

1. Who specifically, at NIST and at IESG, says that HMAC needs Apad for sec= urity reasons (and therefore is not secure as-is)?

2. What are those security reasons, and what are the attacks that are foile= d by Apad?

3. What published papers/references/whatever is this documented? As HMAC ca= me with security proofs, I=E2=80=99d like to see where and how they are inv= alidated (if they indeed are).



On May 21, 2014, at 8:57 , Stephen Farrell <stephen.farrell@cs.tcd.ie <mailto= :stephen.far= rell@cs.tcd.ie>> wrote:



On 21/05/14 12:14, Bhatia, Manav (Manav) wrote:
I agree with Loa.

Our current draft is very simple and has gone through multiple
iterations of reviews in at least two WGs. It brings LDP to the same
level of security as other protocols running in the networks.

Fully agree with that goal.


I think we should just push it forward and if there is an interest in
writing a new ID that updates HMAC specification, then we write one
that includes the Apad stuff. I think the latter should anyways be
done, regardless of what happens to this particular draft.

I need to read it. But I'd be happier if that HMAC draft existed
and was going to be processed - then we wouldn't have to do this
discussion again.

Cheers,
S.


The IETF submission site is down and hence couldn=E2=80=99t upload the
revised ID (addressing Yaron's comments). Will do it tomorrow once
its up.

After that its ready to be placed before the IESG.

Cheers, Manav

-----Original Message----- From: Loa Andersson [mailto:loa@pi.nu <mailto:loa@pi.nu>]

Sent: Wednesday, May 21, 2014 4:29 PM To: Manav Bhatia; Stephen
Farrell Cc: Bhatia, Manav (Manav); IETF Security Directorate; The
IESG; draft-ietf-mpls-ldp-hello-crypto-auth.all@t= ools.ietf.org
<mailto:ietf-mpls-ldp-hello-crypto-auth.all@tools.ie= tf.org>;
Yaron Sheffer Subject: Re: SecDir review of
draft-ietf-mpls-ldp-hello-crypto-auth-05

Folks,

I'm only the document shepherd. My feeling is that we are raising
the hurdle step by step for the KARP - initiated RFCs, the first
was comparatively smooth, now we are trying to put an 18 months
effort (individual draft to RFC) in front of approving something
that is comparatively simple and seen as raising LDP to the same
security as the other routing protocols.

So if we get to tired to push this, we are all better off not
doing the security work for this particular protocol?

Someone said - "Never let the best be the enemy of the possible"!=

/Loa



On 2014-05-21 12:39, Manav Bhatia wrote:
Stephen,

This however is a long drawn discussion because everyone
needs to
be
convinced on the merits of updating the HMAC specification --
which
I
am not sure will take how long.

So I need to look at this draft, HMAC and the other cases but
it seems to me that you're copying a page or two of crypto spec
each time and changing one line. Doing that over and over is a
recipe for long term pain, isn't it?

It sure is.

I had volunteered to write a 1-2 page long ID that updated the
HMAC
to
include the Apad, but the idea was shot down. The only
alternative left was to include the crypto stuff in each standard
that we wrote later.


(And we've had this discussion for each such draft while I've
been on the IESG I think, which is also somewhat drawn out;-)

This draft is probably the last one thats coming from the Routing
WG which will have this level of crypto mathematics spelled out.
All other IGPs are already covered. In case we need to change
something
in
the ones already covered we can refer to the base RFC where we
have detailed the crypto maths. For example,
draft-ietf-ospf-security-extension-manual-keying-08 amongst
other things also updates the definition of Apad. It points to
the exact mathematics in RFC 5709 and only updates the Apad
definition in that draft. This draft btw has cleared the WG LC
and would be appearing before you guys very soon.

Given this, i think we should just pass this draft with this
level of details. Subsequently, when LDP wants to update
something, it can normatively refer to this RFC and only give the
changes.

Cheers, Manav


S.



Cheers, Manav



S


Cheers, Manav

-----Original Message----- From: Stephen Farrell
[mailto:step= hen.farrell@cs.tcd.ie <mailto:stephen.farrell@cs.tcd.ie>] S= ent:
Wednesday, May
21, 2014 2:53 AM To: Bhatia, Manav (Manav); IETF
Security Directorate; The IESG; draft-
ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org<= br>
<mailto:ietf-mpls-ldp-hello-crypto-auth.all@tools.ie= tf.org> Cc:
Yaron = Sheffer;manavbhatia@gmail.com <mailto:manavbhatia@gmail.com> Subject: Re:

SecDir review of
draft-ietf-mpls-ldp-hello-crypto-auth-05



On 19/05/14 21:27, Yaron Sheffer wrote:

* 5.1: Redefining HMAC (RFC 2104) is an extremely
bad idea. This reviewer does not have the
appropriate background to critique the proposed
solution, but there must be an overwhelming
reason to
reopen> >>>>> cryptographic primitives.

This is a decision that was taken by Sec Ads when
we were doing the crypto protection for the IGPs
based on some feedback from NIST.
This
mathematics is not new and has been done for all
IGPs and has been approved and rather encouraged by
the Security ADs.

The above does not sound like something I recognise. I
have repeatedly asked that documents not re-define
HMAC. Perhaps this time, I'll make that a DISCUSS and
not budge. I probably should have done that before
TBH.

If you are revising that doc, *please* get rid of the
re-definition and just properly refer to HMAC. Its
about time to stop repeating that error.

S.







--


Loa Andersson =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0email:loa@mail01.huawei.com <mailto:loa@mail01.huawei.com>
Senior MPLS Expertloa@= pi.nu <mailto:loa@pi.= nu> Huawei
Technologies (consultant) =C2=A0 =C2=A0 phone:+46 739 81 21 64= <tel:%2B46%20739%2081%2021%2064>

_______________________________________________
secdir mailing list
secdir@ietf.org &l= t;mailto:secdir@ietf.o= rg>

= https://www.ietf.org/mailman/listinfo/secdir
wiki:http://tools.ietf.org/area/sec/trac/wiki/SecDir= Review

_______________________________________________
secdir mailing list
secdir@ietf.org &l= t;mailto:secdir@ietf.o= rg>

= https://www.ietf.org/mailman/listinfo/secdir
wiki:http://tools.ietf.org/area/sec/trac/wiki/SecDir= Review



--


Loa Andersson =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0email: loa@mail01.huawei.com
Senior MPLS Expert =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loa@pi.nu
Huawei Technologies (consultant) =C2=A0 =C2=A0 phone: +46 739 81 2= 1 64

--089e0149cb9cd6295e04fa707425-- From nobody Wed May 28 00:14:14 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF58A1A03C1; Wed, 28 May 2014 00:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsP9MtTcuhMN; Wed, 28 May 2014 00:14:10 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAD251A0384; Wed, 28 May 2014 00:14:09 -0700 (PDT) Received: from [192.168.1.8] (unknown [119.94.254.248]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 2721D18013DA; Wed, 28 May 2014 09:14:01 +0200 (CEST) Message-ID: <53858CB7.8080508@pi.nu> Date: Wed, 28 May 2014 09:13:59 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Manav Bhatia References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> <537BC7B6.5040406@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B609@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C5BCE.4010801@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B6A8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C7EDB.9050000@cs.tcd.ie> <537C86D6.1030703@pi.nu> <20211F91F544D247976D84C5D778A4C32E60BA5C@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537CA2D2.4070103@cs.tcd.ie> <54E263B5-41C7-4523-9941-B3E39AE077CD@mit.edu> <57ee448f94f94cd7ba040903e604aa3c@SG70XWXCHHUB01.zap.alcatel-lucent.com> <2EEA459CD95CCB4988BFAFC0F2287B5C5C8302E4@SZXEMA504-MBS.china.huawei.com> <53858ACE.8030909@pi.nu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/U6chDX66oJHh5Uuigjul1EPc2Uo Cc: "Bhatia, Manav \(Manav\)" , IETF Security Directorate , "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" , The IESG , Vero Zheng Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 07:14:13 -0000 Folks, This is not entirely scientific, but based on the diff's bwetween version -04 and -06, does to me not indicate that the changes are such that we need to take the draft back to the wg for a new wglc. Unless the responsible AD or my co-chairs speaks up and have a different opinion, it is my opinion that we now should move this draft ahead. /Loa On 2014-05-28 09:06, Manav Bhatia wrote: > Yup, thats correct! > > > On Wed, May 28, 2014 at 12:35 PM, Loa Andersson > wrote: > > All, > > Do I understand correctly if we are now OK to go ahead and have > this draft approved? > > /Loa > > > On 2014-05-26 03:30, Vero Zheng wrote: > > Thanks Yaron and Manav for working this out. > > I have just confirmed the post. > > Cheers, Vero > > *From:*Manav Bhatia [mailto:manavbhatia@gmail.com > ] > *Sent:* Sunday, May 25, 2014 1:50 PM > *To:* Yaron Sheffer > *Cc:* Uri Blumenthal; Stephen Farrell; Bhatia, Manav (Manav); IETF > > Security Directorate; > draft-ietf-mpls-ldp-hello-__crypto-auth.all@tools.ietf.org > __; > The IESG; Loa > Andersson > *Subject:* Re: [secdir] SecDir review of > > draft-ietf-mpls-ldp-hello-__crypto-auth-05 > > Hi, > > Yaron, I and few of us exchanged quite a few emails offline and > we have > come up with a version that addresses Yaron's and Stephen's concerns > about repeating the HMAC stuff thats already present in RFC > 2104. We've > cleaned it up pretty nicely with very minimal changes. > > I am unable to submit this latest and the greatest version since > i have > updated my email ID in this version. The tracker requires one of the > co-authors to authenticate/approve the submission. > > I am attaching the latest version with this email in case folks > want to > go through this till it becomes available formally. > > The draft is all set to fly now! :-) > > Cheers, Manav > > On Wed, May 21, 2014 at 7:54 PM, Yaron Sheffer > > >__> > wrote: > > IMHO, this is purely a naming problem. Apad does NOT modify the base > HMAC, please see > http://tools.ietf.org/html/__draft-ietf-mpls-ldp-hello-__crypto-auth-05#section-5 > . > It is just one more thing that's signed by HMAC. > > My problem with this draft is that they have different ideas > about the > key length, compared to RFC 2104 (top of Sec. 5.1). Also, I am > unhappy > that they spell out the HMAC construction instead of leaving it as a > black box. > > But I think Apad is just fine, if it weren't for the unfortunate > name > that leads people to think it's modifying HMAC. > > Thanks, > Yaron > > > On 05/21/2014 04:28 PM, Uri Blumenthal wrote: > > Once again, please. > > 1. Who specifically, at NIST and at IESG, says that HMAC > needs Apad for security reasons (and therefore is not secure > as-is)? > > 2. What are those security reasons, and what are the attacks > that are foiled by Apad? > > 3. What published papers/references/whatever is this > documented? As HMAC came with security proofs, I’d like to > see where and how they are invalidated (if they indeed are). > > > > On May 21, 2014, at 8:57 , Stephen Farrell > > >> wrote: > > > > On 21/05/14 12:14, Bhatia, Manav (Manav) wrote: > > I agree with Loa. > > Our current draft is very simple and has gone > through multiple > iterations of reviews in at least two WGs. It brings > LDP to the same > level of security as other protocols running in the > networks. > > > Fully agree with that goal. > > > I think we should just push it forward and if there > is an interest in > writing a new ID that updates HMAC specification, > then we write one > that includes the Apad stuff. I think the latter > should anyways be > done, regardless of what happens to this particular > draft. > > > I need to read it. But I'd be happier if that HMAC draft > existed > and was going to be processed - then we wouldn't have to > do this > discussion again. > > Cheers, > S. > > > The IETF submission site is down and hence couldn’t > upload the > revised ID (addressing Yaron's comments). Will do it > tomorrow once > its up. > > After that its ready to be placed before the IESG. > > Cheers, Manav > > -----Original Message----- From: Loa Andersson > [mailto:loa@pi.nu > >] > > Sent: Wednesday, May 21, 2014 4:29 PM To: Manav > Bhatia; Stephen > Farrell Cc: Bhatia, Manav (Manav); IETF Security > Directorate; The > IESG; > draft-ietf-mpls-ldp-hello-__crypto-auth.all@tools.ietf.org > > > __>; > > Yaron Sheffer Subject: Re: SecDir review of > draft-ietf-mpls-ldp-hello-__crypto-auth-05 > > Folks, > > I'm only the document shepherd. My feeling is > that we are raising > the hurdle step by step for the KARP - initiated > RFCs, the first > was comparatively smooth, now we are trying to > put an 18 months > effort (individual draft to RFC) in front of > approving something > that is comparatively simple and seen as raising > LDP to the same > security as the other routing protocols. > > So if we get to tired to push this, we are all > better off not > doing the security work for this particular > protocol? > > Someone said - "Never let the best be the enemy > of the possible"! > > /Loa > > > > On 2014-05-21 12:39, Manav Bhatia wrote: > > Stephen, > > This however is a long drawn > discussion because everyone > needs to > > be > > convinced on the merits of updating > the HMAC specification -- > which > > I > > am not sure will take how long. > > > So I need to look at this draft, HMAC > and the other cases but > it seems to me that you're copying a > page or two of crypto spec > each time and changing one line. Doing > that over and over is a > recipe for long term pain, isn't it? > > > It sure is. > > I had volunteered to write a 1-2 page long > ID that updated the > HMAC > > to > > include the Apad, but the idea was shot > down. The only > alternative left was to include the crypto > stuff in each standard > that we wrote later. > > > (And we've had this discussion for each > such draft while I've > been on the IESG I think, which is also > somewhat drawn out;-) > > > This draft is probably the last one thats > coming from the Routing > WG which will have this level of crypto > mathematics spelled out. > All other IGPs are already covered. In case > we need to change > something > > in > > the ones already covered we can refer to the > base RFC where we > have detailed the crypto maths. For example, > draft-ietf-ospf-security-__extension-manual-keying-08 > amongst > other things also updates the definition of > Apad. It points to > the exact mathematics in RFC 5709 and only > updates the Apad > definition in that draft. This draft btw has > cleared the WG LC > and would be appearing before you guys very > soon. > > Given this, i think we should just pass this > draft with this > level of details. Subsequently, when LDP > wants to update > something, it can normatively refer to this > RFC and only give the > changes. > > Cheers, Manav > > > S. > > > > Cheers, Manav > > > > S > > > Cheers, Manav > > -----Original > Message----- From: > Stephen Farrell > [mailto:stephen.farrell@cs.__tcd.ie > > >] > Sent: > > Wednesday, May > > 21, 2014 2:53 AM To: > Bhatia, Manav (Manav); IETF > Security Directorate; > The IESG; draft- > ietf-mpls-ldp-hello-crypto-__auth.all@tools.ietf.org > > > __> Cc: > > Yaron > Sheffer;manavbhatia@gmail.com > > > > Subject: Re: > > SecDir review of > draft-ietf-mpls-ldp-hello-__crypto-auth-05 > > > > On 19/05/14 21:27, Yaron > Sheffer wrote: > > > * 5.1: > Redefining > HMAC (RFC > 2104) is an > extremely > bad idea. > This > reviewer > does not > have the > appropriate > background > to critique > the proposed > solution, > but there > must be an > overwhelming > reason to > > reopen> >>>>> > cryptographic primitives. > > > This is a > decision that > was taken by Sec > Ads when > we were doing > the crypto > protection for > the IGPs > based on some > feedback from NIST. > > This > > mathematics is > not new and has > been done for all > IGPs and has > been approved > and rather > encouraged by > the Security ADs. > > > The above does not sound > like something I > recognise. I > have repeatedly asked > that documents not re-define > HMAC. Perhaps this time, > I'll make that a DISCUSS and > not budge. I probably > should have done that before > TBH. > > If you are revising that > doc, *please* get rid of the > re-definition and just > properly refer to HMAC. Its > about time to stop > repeating that error. > > S. > > > > > > > > > -- > > > Loa Andersson email:loa@mail01.huawei.com > > > > Senior MPLS Expertloa@pi.nu > > Huawei > Technologies (consultant) phone:+46 739 81 > 21 64 > > > > _________________________________________________ > secdir mailing list > secdir@ietf.org > > > > https://www.ietf.org/mailman/__listinfo/secdir > > wiki:http://tools.ietf.org/__area/sec/trac/wiki/__SecDirReview > > > > _________________________________________________ > secdir mailing list > secdir@ietf.org > > > > https://www.ietf.org/mailman/__listinfo/secdir > > wiki:http://tools.ietf.org/__area/sec/trac/wiki/__SecDirReview > > > > > -- > > > Loa Andersson email: loa@mail01.huawei.com > > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed May 28 00:21:17 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 196411A0814; Wed, 28 May 2014 00:21:11 -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 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 9YrBON42mnCF; Wed, 28 May 2014 00:21:06 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D77C1A03B7; Wed, 28 May 2014 00:21:06 -0700 (PDT) Received: by mail-ob0-f178.google.com with SMTP id va2so10433279obc.23 for ; Wed, 28 May 2014 00: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:date:message-id:subject:from:to :cc:content-type; bh=FAiLCH+fZ3owGNb97iGGiYgd/L4XO+tZqxajfHjuzvM=; b=jcZV98tCxU1CP5oviBv65kfurGFFo4cdoSKzS/xkWW5lpyFGaguh5b7EpEMsGN4B4Q eD0ejtNp0c2ZWHtC7rmjLFr1BHHSKzbHuNbjE9VwK9uUL6iProhmLiqRblclCjlvrmkj CVTJvHO3r8W0vQCnjUEuyoWBqsQJmZ5TcFY4JZEFGyzQio0KNqfKnM8s01Fy3oL+O2Yh INVbZu4BySXhHe3ARnDU0dxc5xeLrAYRafc5VGAijSnytY6YRVkloMwL42MotLKGi/yR pHu2JJZ/2OKDS0xDjZ5F/jf0luNORNaOLToTlt9xZpbENsonb5UBlLAFNkfUfzDTqKCx wEOA== MIME-Version: 1.0 X-Received: by 10.60.143.37 with SMTP id sb5mr29891692oeb.38.1401261662930; Wed, 28 May 2014 00:21:02 -0700 (PDT) Received: by 10.76.77.97 with HTTP; Wed, 28 May 2014 00:21:02 -0700 (PDT) In-Reply-To: References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> <537BC7B6.5040406@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B609@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C5BCE.4010801@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B6A8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C7EDB.9050000@cs.tcd.ie> <537C86D6.1030703@pi.nu> <20211F91F544D247976D84C5D778A4C32E60BA5C@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537CA2D2.4070103@cs.tcd.ie> <54E263B5-41C7-4523-9941-B3E39AE077CD@mit.edu> <57ee448f94f94cd7ba040903e604aa3c@SG70XWXCHHUB01.zap.alcatel-lucent.com> <2EEA459CD95CCB4988BFAFC0F2287B5C5C8302E4@SZXEMA504-MBS.china.huawei.com> <53858ACE.8030909@pi.nu> Date: Wed, 28 May 2014 12:51:02 +0530 Message-ID: From: Manav Bhatia To: Loa Andersson Content-Type: multipart/alternative; boundary=047d7b3a81a0a82d5b04fa70a761 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/QrejPhqDSVQZCD64yfOgsQhgAFU Cc: "Bhatia, Manav \(Manav\)" , IETF Security Directorate , "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" , The IESG , Vero Zheng Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 07:21:11 -0000 --047d7b3a81a0a82d5b04fa70a761 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Loa, We dont need to. The changes are only editorial in nature. Cheers, Manav On Wed, May 28, 2014 at 12:43 PM, Loa Andersson wrote: > Folks, > > This is not entirely scientific, but based on the diff's bwetween > version -04 and -06, does to me not indicate that the changes are > such that we need to take the draft back to the wg for a new wglc. > > Unless the responsible AD or my co-chairs speaks up and have a > different opinion, it is my opinion that we now should move this > draft ahead. > > /Loa > > On 2014-05-28 09:06, Manav Bhatia wrote: > > Yup, thats correct! > > > > > > On Wed, May 28, 2014 at 12:35 PM, Loa Andersson > > wrote: > > > > All, > > > > Do I understand correctly if we are now OK to go ahead and have > > this draft approved? > > > > /Loa > > > > > > On 2014-05-26 03:30, Vero Zheng wrote: > > > > Thanks Yaron and Manav for working this out. > > > > I have just confirmed the post. > > > > Cheers, Vero > > > > *From:*Manav Bhatia [mailto:manavbhatia@gmail.com > > ] > > *Sent:* Sunday, May 25, 2014 1:50 PM > > *To:* Yaron Sheffer > > *Cc:* Uri Blumenthal; Stephen Farrell; Bhatia, Manav (Manav); > IETF > > > > Security Directorate; > > draft-ietf-mpls-ldp-hello-__crypto-auth.all@tools.ietf.org > > >__; > > The IESG; Loa > > Andersson > > *Subject:* Re: [secdir] SecDir review of > > > > draft-ietf-mpls-ldp-hello-__crypto-auth-05 > > > > Hi, > > > > Yaron, I and few of us exchanged quite a few emails offline and > > we have > > come up with a version that addresses Yaron's and Stephen's > concerns > > about repeating the HMAC stuff thats already present in RFC > > 2104. We've > > cleaned it up pretty nicely with very minimal changes. > > > > I am unable to submit this latest and the greatest version sinc= e > > i have > > updated my email ID in this version. The tracker requires one o= f > the > > co-authors to authenticate/approve the submission. > > > > I am attaching the latest version with this email in case folks > > want to > > go through this till it becomes available formally. > > > > The draft is all set to fly now! :-) > > > > Cheers, Manav > > > > On Wed, May 21, 2014 at 7:54 PM, Yaron Sheffer > > > > >__= > > > wrote: > > > > IMHO, this is purely a naming problem. Apad does NOT modify the > base > > HMAC, please see > > > http://tools.ietf.org/html/__draft-ietf-mpls-ldp-hello-__crypto-auth-05#s= ection-5 > > < > http://tools.ietf.org/html/draft-ietf-mpls-ldp-hello-crypto-auth-05#secti= on-5 > >. > > It is just one more thing that's signed by HMAC. > > > > My problem with this draft is that they have different ideas > > about the > > key length, compared to RFC 2104 (top of Sec. 5.1). Also, I am > > unhappy > > that they spell out the HMAC construction instead of leaving it > as a > > black box. > > > > But I think Apad is just fine, if it weren't for the unfortunat= e > > name > > that leads people to think it's modifying HMAC. > > > > Thanks, > > Yaron > > > > > > On 05/21/2014 04:28 PM, Uri Blumenthal wrote: > > > > Once again, please. > > > > 1. Who specifically, at NIST and at IESG, says that HMAC > > needs Apad for security reasons (and therefore is not secur= e > > as-is)? > > > > 2. What are those security reasons, and what are the attack= s > > that are foiled by Apad? > > > > 3. What published papers/references/whatever is this > > documented? As HMAC came with security proofs, I=E2=80=99d = like to > > see where and how they are invalidated (if they indeed are)= . > > > > > > > > On May 21, 2014, at 8:57 , Stephen Farrell > > > > > > >> wrote: > > > > > > > > On 21/05/14 12:14, Bhatia, Manav (Manav) wrote: > > > > I agree with Loa. > > > > Our current draft is very simple and has gone > > through multiple > > iterations of reviews in at least two WGs. It bring= s > > LDP to the same > > level of security as other protocols running in the > > networks. > > > > > > Fully agree with that goal. > > > > > > I think we should just push it forward and if there > > is an interest in > > writing a new ID that updates HMAC specification, > > then we write one > > that includes the Apad stuff. I think the latter > > should anyways be > > done, regardless of what happens to this particular > > draft. > > > > > > I need to read it. But I'd be happier if that HMAC draf= t > > existed > > and was going to be processed - then we wouldn't have t= o > > do this > > discussion again. > > > > Cheers, > > S. > > > > > > The IETF submission site is down and hence couldn= =E2=80=99t > > upload the > > revised ID (addressing Yaron's comments). Will do i= t > > tomorrow once > > its up. > > > > After that its ready to be placed before the IESG. > > > > Cheers, Manav > > > > -----Original Message----- From: Loa Andersson > > [mailto:loa@pi.nu > > >] > > > > Sent: Wednesday, May 21, 2014 4:29 PM To: Manav > > Bhatia; Stephen > > Farrell Cc: Bhatia, Manav (Manav); IETF Securit= y > > Directorate; The > > IESG; > > > draft-ietf-mpls-ldp-hello-__crypto-auth.all@tools.ietf.org > > draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org> > > > > > __>; > > > > Yaron Sheffer Subject: Re: SecDir review of > > draft-ietf-mpls-ldp-hello-__crypto-auth-05 > > > > Folks, > > > > I'm only the document shepherd. My feeling is > > that we are raising > > the hurdle step by step for the KARP - initiate= d > > RFCs, the first > > was comparatively smooth, now we are trying to > > put an 18 months > > effort (individual draft to RFC) in front of > > approving something > > that is comparatively simple and seen as raisin= g > > LDP to the same > > security as the other routing protocols. > > > > So if we get to tired to push this, we are all > > better off not > > doing the security work for this particular > > protocol? > > > > Someone said - "Never let the best be the enemy > > of the possible"! > > > > /Loa > > > > > > > > On 2014-05-21 12:39, Manav Bhatia wrote: > > > > Stephen, > > > > This however is a long drawn > > discussion because everyone > > needs to > > > > be > > > > convinced on the merits of updating > > the HMAC specification -- > > which > > > > I > > > > am not sure will take how long. > > > > > > So I need to look at this draft, HMAC > > and the other cases but > > it seems to me that you're copying a > > page or two of crypto spec > > each time and changing one line. Doing > > that over and over is a > > recipe for long term pain, isn't it? > > > > > > It sure is. > > > > I had volunteered to write a 1-2 page long > > ID that updated the > > HMAC > > > > to > > > > include the Apad, but the idea was shot > > down. The only > > alternative left was to include the crypto > > stuff in each standard > > that we wrote later. > > > > > > (And we've had this discussion for each > > such draft while I've > > been on the IESG I think, which is also > > somewhat drawn out;-) > > > > > > This draft is probably the last one thats > > coming from the Routing > > WG which will have this level of crypto > > mathematics spelled out. > > All other IGPs are already covered. In case > > we need to change > > something > > > > in > > > > the ones already covered we can refer to th= e > > base RFC where we > > have detailed the crypto maths. For example= , > > > draft-ietf-ospf-security-__extension-manual-keying-08 > > amongst > > other things also updates the definition of > > Apad. It points to > > the exact mathematics in RFC 5709 and only > > updates the Apad > > definition in that draft. This draft btw ha= s > > cleared the WG LC > > and would be appearing before you guys very > > soon. > > > > Given this, i think we should just pass thi= s > > draft with this > > level of details. Subsequently, when LDP > > wants to update > > something, it can normatively refer to this > > RFC and only give the > > changes. > > > > Cheers, Manav > > > > > > S. > > > > > > > > Cheers, Manav > > > > > > > > S > > > > > > Cheers, Manav > > > > -----Original > > Message----- From: > > Stephen Farrell > > [mailto: > stephen.farrell@cs.__tcd.ie > > stephen.farrell@cs.tcd.ie> > > stephen.farrell@cs.__tcd.ie > > stephen.farrell@cs.tcd.ie>>] > > Sent: > > > > Wednesday, May > > > > 21, 2014 2:53 AM To: > > Bhatia, Manav (Manav); > IETF > > Security Directorate; > > The IESG; draft- > > > ietf-mpls-ldp-hello-crypto-__auth.all@tools.ietf.org > > ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org> > > > > > __> > Cc: > > > > Yaron > > > Sheffer;manavbhatia@gmail.com > > Sheffer%3Bmanavbhatia@gmail.com> > > manavbhatia@gmail.com > > manavbhatia@gmail.com>> > > Subject: Re: > > > > SecDir review of > > > draft-ietf-mpls-ldp-hello-__crypto-auth-05 > > > > > > > > On 19/05/14 21:27, Yaro= n > > Sheffer wrote: > > > > > > * 5.1: > > Redefining > > HMAC (RFC > > 2104) is an > > extremely > > bad idea. > > This > > reviewer > > does not > > have the > > appropriate > > background > > to critique > > the propose= d > > solution, > > but there > > must be an > > overwhelmin= g > > reason to > > > > reopen> >>>>> > > cryptographic primitive= s. > > > > > > This is a > > decision that > > was taken by Se= c > > Ads when > > we were doing > > the crypto > > protection for > > the IGPs > > based on some > > feedback from > NIST. > > > > This > > > > mathematics is > > not new and has > > been done for a= ll > > IGPs and has > > been approved > > and rather > > encouraged by > > the Security AD= s. > > > > > > The above does not soun= d > > like something I > > recognise. I > > have repeatedly asked > > that documents not > re-define > > HMAC. Perhaps this time= , > > I'll make that a DISCUS= S > and > > not budge. I probably > > should have done that > before > > TBH. > > > > If you are revising tha= t > > doc, *please* get rid o= f > the > > re-definition and just > > properly refer to HMAC. > Its > > about time to stop > > repeating that error. > > > > S. > > > > > > > > > > > > > > > > > > -- > > > > > > Loa Andersson email:loa@mail01.huawei.com > > > > > > > > Senior MPLS Expertloa@pi.nu > > > > Huawei > > Technologies (consultant) phone:+46 739 81 > > 21 64 > > > > > > > > _________________________________________________ > > secdir mailing list > > secdir@ietf.org > > > > > > > https://www.ietf.org/mailman/__listinfo/secdir > > > > wiki: > http://tools.ietf.org/__area/sec/trac/wiki/__SecDirReview > > > > > > > > _________________________________________________ > > secdir mailing list > > secdir@ietf.org > > > > > > > https://www.ietf.org/mailman/__listinfo/secdir > > > > wiki: > http://tools.ietf.org/__area/sec/trac/wiki/__SecDirReview > > > > > > > > > > -- > > > > > > Loa Andersson email: loa@mail01.huawei.com > > > > Senior MPLS Expert loa@pi.nu > > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > > > > > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > --047d7b3a81a0a82d5b04fa70a761 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+SGkgTG9hLDxkaXY+PGJyPjwvZGl2PjxkaXY+V2UgZG9udCBuZWVkIHRv LiBUaGUgY2hhbmdlcyBhcmUgb25seSBlZGl0b3JpYWwgaW4gbmF0dXJlLjwvZGl2PjxkaXY+PGJy PjwvZGl2PjxkaXY+Q2hlZXJzLCBNYW5hdjwvZGl2PjwvZGl2PjxkaXYgY2xhc3M9ImdtYWlsX2V4 dHJhIj48YnI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBXZWQsIE1heSAyOCwgMjAx NCBhdCAxMjo0MyBQTSwgTG9hIEFuZGVyc3NvbiA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9 Im1haWx0bzpsb2FAcGkubnUiIHRhcmdldD0iX2JsYW5rIj5sb2FAcGkubnU8L2E+Jmd0Ozwvc3Bh bj4gd3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFy Z2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFl eCI+PGRpdiBjbGFzcz0iIj5Gb2xrcyw8YnI+DQo8YnI+DQpUaGlzIGlzIG5vdCBlbnRpcmVseSBz Y2llbnRpZmljLCBidXQgYmFzZWQgb24gdGhlIGRpZmYmIzM5O3MgYndldHdlZW48YnI+DQp2ZXJz aW9uIC0wNCBhbmQgLTA2LCBkb2VzIHRvIG1lIG5vdCBpbmRpY2F0ZSB0aGF0IHRoZSBjaGFuZ2Vz IGFyZTxicj4NCnN1Y2ggdGhhdCB3ZSBuZWVkIHRvIHRha2UgdGhlIGRyYWZ0IGJhY2sgdG8gdGhl IHdnIGZvciBhIG5ldyB3Z2xjLjxicj4NCjxicj4NClVubGVzcyB0aGUgcmVzcG9uc2libGUgQUQg b3IgbXkgY28tY2hhaXJzIHNwZWFrcyB1cCBhbmQgaGF2ZSBhPGJyPg0KZGlmZmVyZW50IG9waW5p b24sIGl0IGlzIG15IG9waW5pb24gdGhhdCB3ZSBub3cgc2hvdWxkIG1vdmUgdGhpczxicj4NCmRy YWZ0IGFoZWFkLjxicj4NCjxicj4NCi9Mb2E8YnI+DQo8YnI+DQpPbiAyMDE0LTA1LTI4IDA5OjA2 LCBNYW5hdiBCaGF0aWEgd3JvdGU6PGJyPg0KPC9kaXY+PGRpdiBjbGFzcz0iIj4mZ3Q7IFl1cCwg dGhhdHMgY29ycmVjdCE8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgT24gV2VkLCBNYXkg MjgsIDIwMTQgYXQgMTI6MzUgUE0sIExvYSBBbmRlcnNzb24gJmx0OzxhIGhyZWY9Im1haWx0bzps b2FAcGkubnUiPmxvYUBwaS5udTwvYT48YnI+DQo8L2Rpdj48ZGl2IGNsYXNzPSIiPiZndDsgJmx0 O21haWx0bzo8YSBocmVmPSJtYWlsdG86bG9hQHBpLm51Ij5sb2FAcGkubnU8L2E+Jmd0OyZndDsg d3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgwqAgwqAgQWxsLDxicj4NCiZndDs8YnI+DQomZ3Q7 IMKgIMKgIERvIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHkgaWYgd2UgYXJlIG5vdyBPSyB0byBnbyBh aGVhZCBhbmQgaGF2ZTxicj4NCiZndDsgwqAgwqAgdGhpcyBkcmFmdCBhcHByb3ZlZD88YnI+DQom Z3Q7PGJyPg0KJmd0OyDCoCDCoCAvTG9hPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IMKg IMKgIE9uIDIwMTQtMDUtMjYgMDM6MzAsIFZlcm8gWmhlbmcgd3JvdGU6PGJyPg0KJmd0Ozxicj4N CiZndDsgwqAgwqAgwqAgwqAgVGhhbmtzIFlhcm9uIGFuZCBNYW5hdiBmb3Igd29ya2luZyB0aGlz IG91dC48YnI+DQomZ3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCBJIGhhdmUganVzdCBjb25maXJt ZWQgdGhlIHBvc3QuPGJyPg0KJmd0Ozxicj4NCiZndDsgwqAgwqAgwqAgwqAgQ2hlZXJzLCBWZXJv PGJyPg0KJmd0Ozxicj4NCiZndDsgwqAgwqAgwqAgwqAgKkZyb206Kk1hbmF2IEJoYXRpYSBbbWFp bHRvOjxhIGhyZWY9Im1haWx0bzptYW5hdmJoYXRpYUBnbWFpbC5jb20iPm1hbmF2YmhhdGlhQGdt YWlsLmNvbTwvYT48YnI+DQomZ3Q7IMKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFp bHRvOm1hbmF2YmhhdGlhQGdtYWlsLmNvbSI+bWFuYXZiaGF0aWFAZ21haWwuY29tPC9hPiZndDtd PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCAqU2VudDoqIFN1bmRheSwgTWF5IDI1LCAyMDE0IDE6NTAg UE08YnI+DQomZ3Q7IMKgIMKgIMKgIMKgICpUbzoqIFlhcm9uIFNoZWZmZXI8YnI+DQomZ3Q7IMKg IMKgIMKgIMKgICpDYzoqIFVyaSBCbHVtZW50aGFsOyBTdGVwaGVuIEZhcnJlbGw7IEJoYXRpYSwg TWFuYXYgKE1hbmF2KTsgSUVURjxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIFNlY3Vy aXR5IERpcmVjdG9yYXRlOzxicj4NCjwvZGl2PiZndDsgwqAgwqAgwqAgwqAgPGEgaHJlZj0ibWFp bHRvOmRyYWZ0LWlldGYtbXBscy1sZHAtaGVsbG8tX19jcnlwdG8tYXV0aC5hbGxAdG9vbHMuaWV0 Zi5vcmciPmRyYWZ0LWlldGYtbXBscy1sZHAtaGVsbG8tX19jcnlwdG8tYXV0aC5hbGxAdG9vbHMu aWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1h aWx0bzpkcmFmdC1pZXRmLW1wbHMtbGRwLWhlbGxvLWNyeXB0by1hdXRoLmFsbEB0b29scy5pZXRm Lm9yZyI+ZHJhZnQtaWV0Zi1tcGxzLWxkcC1oZWxsby1jcnlwdG8tYXV0aC5hbGxAdG9vbHMuaWV0 Zi5vcmc8L2E+Jmd0O19fOzxicj4NCjxkaXYgY2xhc3M9IiI+Jmd0OyDCoCDCoCDCoCDCoCBUaGUg SUVTRzsgTG9hPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCBBbmRlcnNzb248YnI+DQomZ3Q7IMKgIMKg IMKgIMKgICpTdWJqZWN0OiogUmU6IFtzZWNkaXJdIFNlY0RpciByZXZpZXcgb2Y8YnI+DQomZ3Q7 PGJyPg0KPC9kaXY+Jmd0OyDCoCDCoCDCoCDCoCBkcmFmdC1pZXRmLW1wbHMtbGRwLWhlbGxvLV9f Y3J5cHRvLWF1dGgtMDU8YnI+DQo8ZGl2IGNsYXNzPSIiPiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKg IMKgIEhpLDxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIFlhcm9uLCBJIGFuZCBmZXcg b2YgdXMgZXhjaGFuZ2VkIHF1aXRlIGEgZmV3IGVtYWlscyBvZmZsaW5lIGFuZDxicj4NCiZndDsg wqAgwqAgwqAgwqAgd2UgaGF2ZTxicj4NCiZndDsgwqAgwqAgwqAgwqAgY29tZSB1cCB3aXRoIGEg dmVyc2lvbiB0aGF0IGFkZHJlc3NlcyBZYXJvbiYjMzk7cyBhbmQgU3RlcGhlbiYjMzk7cyBjb25j ZXJuczxicj4NCiZndDsgwqAgwqAgwqAgwqAgYWJvdXQgcmVwZWF0aW5nIHRoZSBITUFDIHN0dWZm IHRoYXRzIGFscmVhZHkgcHJlc2VudCBpbiBSRkM8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIDIxMDQu IFdlJiMzOTt2ZTxicj4NCiZndDsgwqAgwqAgwqAgwqAgY2xlYW5lZCBpdCB1cCBwcmV0dHkgbmlj ZWx5IHdpdGggdmVyeSBtaW5pbWFsIGNoYW5nZXMuPGJyPg0KJmd0Ozxicj4NCiZndDsgwqAgwqAg wqAgwqAgSSBhbSB1bmFibGUgdG8gc3VibWl0IHRoaXMgbGF0ZXN0IGFuZCB0aGUgZ3JlYXRlc3Qg dmVyc2lvbiBzaW5jZTxicj4NCiZndDsgwqAgwqAgwqAgwqAgaSBoYXZlPGJyPg0KJmd0OyDCoCDC oCDCoCDCoCB1cGRhdGVkIG15IGVtYWlsIElEIGluIHRoaXMgdmVyc2lvbi4gVGhlIHRyYWNrZXIg cmVxdWlyZXMgb25lIG9mIHRoZTxicj4NCiZndDsgwqAgwqAgwqAgwqAgY28tYXV0aG9ycyB0byBh dXRoZW50aWNhdGUvYXBwcm92ZSB0aGUgc3VibWlzc2lvbi48YnI+DQomZ3Q7PGJyPg0KJmd0OyDC oCDCoCDCoCDCoCBJIGFtIGF0dGFjaGluZyB0aGUgbGF0ZXN0IHZlcnNpb24gd2l0aCB0aGlzIGVt YWlsIGluIGNhc2UgZm9sa3M8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIHdhbnQgdG88YnI+DQomZ3Q7 IMKgIMKgIMKgIMKgIGdvIHRocm91Z2ggdGhpcyB0aWxsIGl0IGJlY29tZXMgYXZhaWxhYmxlIGZv cm1hbGx5Ljxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIFRoZSBkcmFmdCBpcyBhbGwg c2V0IHRvIGZseSBub3chIDotKTxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIENoZWVy cywgTWFuYXY8YnI+DQomZ3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCBPbiBXZWQsIE1heSAyMSwg MjAxNCBhdCA3OjU0IFBNLCBZYXJvbiBTaGVmZmVyPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbSI+eWFyb25mLmlldGZAZ21haWwu Y29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20i Pnlhcm9uZi5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPC9kaXY+PGRpdiBjbGFzcz0iIj4m Z3Q7IMKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnlhcm9uZi5pZXRmQGdt YWlsLmNvbSI+eWFyb25mLmlldGZAZ21haWwuY29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1h aWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20iPnlhcm9uZi5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7 Jmd0O19fJmd0Ozxicj4NCjwvZGl2PjxkaXYgY2xhc3M9IiI+Jmd0OyDCoCDCoCDCoCDCoCB3cm90 ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCBJTUhPLCB0aGlzIGlzIHB1cmVseSBh IG5hbWluZyBwcm9ibGVtLiBBcGFkIGRvZXMgTk9UIG1vZGlmeSB0aGUgYmFzZTxicj4NCiZndDsg wqAgwqAgwqAgwqAgSE1BQywgcGxlYXNlIHNlZTxicj4NCjwvZGl2PiZndDsgwqAgwqAgwqAgwqAg PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvX19kcmFmdC1pZXRmLW1wbHMtbGRw LWhlbGxvLV9fY3J5cHRvLWF1dGgtMDUjc2VjdGlvbi01IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvX19kcmFmdC1pZXRmLW1wbHMtbGRwLWhlbGxvLV9fY3J5cHRv LWF1dGgtMDUjc2VjdGlvbi01PC9hPjxicj4NCiZndDsgwqAgwqAgwqAgwqAgJmx0OzxhIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbXBscy1sZHAtaGVsbG8tY3J5 cHRvLWF1dGgtMDUjc2VjdGlvbi01IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1tcGxzLWxkcC1oZWxsby1jcnlwdG8tYXV0aC0wNSNzZWN0aW9u LTU8L2E+Jmd0Oy48YnI+DQo8ZGl2PjxkaXYgY2xhc3M9Img1Ij4mZ3Q7IMKgIMKgIMKgIMKgIEl0 IGlzIGp1c3Qgb25lIG1vcmUgdGhpbmcgdGhhdCYjMzk7cyBzaWduZWQgYnkgSE1BQy48YnI+DQom Z3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCBNeSBwcm9ibGVtIHdpdGggdGhpcyBkcmFmdCBpcyB0 aGF0IHRoZXkgaGF2ZSBkaWZmZXJlbnQgaWRlYXM8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIGFib3V0 IHRoZTxicj4NCiZndDsgwqAgwqAgwqAgwqAga2V5IGxlbmd0aCwgY29tcGFyZWQgdG8gUkZDIDIx MDQgKHRvcCBvZiBTZWMuIDUuMSkuIEFsc28sIEkgYW08YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIHVu aGFwcHk8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIHRoYXQgdGhleSBzcGVsbCBvdXQgdGhlIEhNQUMg Y29uc3RydWN0aW9uIGluc3RlYWQgb2YgbGVhdmluZyBpdCBhcyBhPGJyPg0KJmd0OyDCoCDCoCDC oCDCoCBibGFjayBib3guPGJyPg0KJmd0Ozxicj4NCiZndDsgwqAgwqAgwqAgwqAgQnV0IEkgdGhp bmsgQXBhZCBpcyBqdXN0IGZpbmUsIGlmIGl0IHdlcmVuJiMzOTt0IGZvciB0aGUgdW5mb3J0dW5h dGU8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIG5hbWU8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIHRoYXQg bGVhZHMgcGVvcGxlIHRvIHRoaW5rIGl0JiMzOTtzIG1vZGlmeWluZyBITUFDLjxicj4NCiZndDs8 YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIFRoYW5rcyw8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIFlhcm9uPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIMKg IE9uIDA1LzIxLzIwMTQgMDQ6MjggUE0sIFVyaSBCbHVtZW50aGFsIHdyb3RlOjxicj4NCiZndDs8 YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIE9uY2UgYWdhaW4sIHBsZWFzZS48YnI+DQomZ3Q7 PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCAxLiBXaG8gc3BlY2lmaWNhbGx5LCBhdCBOSVNU IGFuZCBhdCBJRVNHLCBzYXlzIHRoYXQgSE1BQzxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAg bmVlZHMgQXBhZCBmb3Igc2VjdXJpdHkgcmVhc29ucyAoYW5kIHRoZXJlZm9yZSBpcyBub3Qgc2Vj dXJlPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCBhcy1pcyk/PGJyPg0KJmd0Ozxicj4NCiZn dDsgwqAgwqAgwqAgwqAgwqAgwqAgMi4gV2hhdCBhcmUgdGhvc2Ugc2VjdXJpdHkgcmVhc29ucywg YW5kIHdoYXQgYXJlIHRoZSBhdHRhY2tzPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCB0aGF0 IGFyZSBmb2lsZWQgYnkgQXBhZD88YnI+DQomZ3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDC oCAzLiBXaGF0IHB1Ymxpc2hlZCBwYXBlcnMvcmVmZXJlbmNlcy93aGF0ZXZlciBpcyB0aGlzPGJy Pg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCBkb2N1bWVudGVkPyBBcyBITUFDIGNhbWUgd2l0aCBz ZWN1cml0eSBwcm9vZnMsIEnigJlkIGxpa2UgdG88YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKg IHNlZSB3aGVyZSBhbmQgaG93IHRoZXkgYXJlIGludmFsaWRhdGVkIChpZiB0aGV5IGluZGVlZCBh cmUpLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgwqAgwqAgwqAgwqAg wqAgwqAgT24gTWF5IDIxLCAyMDE0LCBhdCA4OjU3ICwgU3RlcGhlbiBGYXJyZWxsPGJyPg0KJmd0 OyDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBj cy50Y2QuaWUiPnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU8L2E+PGJyPg0KJmd0OyDCoCDCoCDC oCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3Mu dGNkLmllIj5zdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPC9hPiZndDs8YnI+DQo8L2Rpdj48L2Rp dj4mZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnN0ZXBo ZW4uZmFycmVsbEBjcy4iPnN0ZXBoZW4uZmFycmVsbEBjcy48L2E+X188YSBocmVmPSJodHRwOi8v dGNkLmllIiB0YXJnZXQ9Il9ibGFuayI+dGNkLmllPC9hPjxicj4NCjxkaXY+PGRpdiBjbGFzcz0i aDUiPiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c3Rl cGhlbi5mYXJyZWxsQGNzLnRjZC5pZSI+c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZTwvYT4mZ3Q7 Jmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBPbiAyMS8wNS8xNCAxMjoxNCwgQmhhdGlhLCBNYW5hdiAo TWFuYXYpIHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIEkgYWdyZWUgd2l0aCBMb2EuPGJyPg0KJmd0Ozxicj4NCiZndDsgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgT3VyIGN1cnJlbnQgZHJhZnQgaXMgdmVyeSBzaW1wbGUgYW5kIGhh cyBnb25lPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aHJvdWdoIG11 bHRpcGxlPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpdGVyYXRpb25z IG9mIHJldmlld3MgaW4gYXQgbGVhc3QgdHdvIFdHcy4gSXQgYnJpbmdzPGJyPg0KJmd0OyDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBMRFAgdG8gdGhlIHNhbWU8YnI+DQomZ3Q7IMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGxldmVsIG9mIHNlY3VyaXR5IGFzIG90aGVyIHByb3Rv Y29scyBydW5uaW5nIGluIHRoZTxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgbmV0d29ya3MuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIEZ1bGx5IGFncmVlIHdpdGggdGhhdCBnb2FsLjxicj4NCiZndDs8YnI+DQomZ3Q7 PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBJIHRoaW5rIHdlIHNob3Vs ZCBqdXN0IHB1c2ggaXQgZm9yd2FyZCBhbmQgaWYgdGhlcmU8YnI+DQomZ3Q7IMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIGlzIGFuIGludGVyZXN0IGluPGJyPg0KJmd0OyDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCB3cml0aW5nIGEgbmV3IElEIHRoYXQgdXBkYXRlcyBITUFDIHNw ZWNpZmljYXRpb24sPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGVu IHdlIHdyaXRlIG9uZTxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhh dCBpbmNsdWRlcyB0aGUgQXBhZCBzdHVmZi4gSSB0aGluayB0aGUgbGF0dGVyPGJyPg0KJmd0OyDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzaG91bGQgYW55d2F5cyBiZTxicj4NCiZndDsg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZG9uZSwgcmVnYXJkbGVzcyBvZiB3aGF0IGhh cHBlbnMgdG8gdGhpcyBwYXJ0aWN1bGFyPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBkcmFmdC48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgSSBuZWVkIHRvIHJlYWQgaXQuIEJ1dCBJJiMzOTtkIGJlIGhhcHBpZXIgaWYg dGhhdCBITUFDIGRyYWZ0PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBleGlzdGVk PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhbmQgd2FzIGdvaW5nIHRvIGJlIHBy b2Nlc3NlZCAtIHRoZW4gd2Ugd291bGRuJiMzOTt0IGhhdmUgdG88YnI+DQomZ3Q7IMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIGRvIHRoaXM8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IGRpc2N1c3Npb24gYWdhaW4uPGJyPg0KJmd0Ozxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgQ2hlZXJzLDxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgUy48YnI+DQom Z3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgVGhl IElFVEYgc3VibWlzc2lvbiBzaXRlIGlzIGRvd24gYW5kIGhlbmNlIGNvdWxkbuKAmXQ8YnI+DQom Z3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHVwbG9hZCB0aGU8YnI+DQomZ3Q7IMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJldmlzZWQgSUQgKGFkZHJlc3NpbmcgWWFyb24m IzM5O3MgY29tbWVudHMpLiBXaWxsIGRvIGl0PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCB0b21vcnJvdyBvbmNlPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBpdHMgdXAuPGJyPg0KJmd0Ozxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgQWZ0ZXIgdGhhdCBpdHMgcmVhZHkgdG8gYmUgcGxhY2VkIGJlZm9yZSB0aGUgSUVT Ry48YnI+DQomZ3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBDaGVl cnMsIE1hbmF2PGJyPg0KJmd0Ozxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogTG9hIEFuZGVyc3Nvbjxi cj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgW21haWx0bzo8YSBo cmVmPSJtYWlsdG86bG9hQHBpLm51Ij5sb2FAcGkubnU8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0i bWFpbHRvOmxvYUBwaS5udSI+bG9hQHBpLm51PC9hPiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmxvYUBw aS5udSI+bG9hQHBpLm51PC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpsb2FAcGkubnUi PmxvYUBwaS5udTwvYT4mZ3Q7Jmd0O108YnI+DQomZ3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTZW50OiBXZWRuZXNkYXksIE1heSAyMSwgMjAxNCA0OjI5 IFBNIFRvOiBNYW5hdjxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgQmhhdGlhOyBTdGVwaGVuPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBGYXJyZWxsIENjOiBCaGF0aWEsIE1hbmF2IChNYW5hdik7IElFVEYgU2VjdXJpdHk8 YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIERpcmVjdG9yYXRl OyBUaGU8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIElFU0c7 PGJyPg0KPC9kaXY+PC9kaXY+PGRpdiBjbGFzcz0iIj4mZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW1wbHMtbGRwLWhlbGxv LV9fY3J5cHRvLWF1dGguYWxsQHRvb2xzLmlldGYub3JnIj5kcmFmdC1pZXRmLW1wbHMtbGRwLWhl bGxvLV9fY3J5cHRvLWF1dGguYWxsQHRvb2xzLmlldGYub3JnPC9hPjxicj4NCiZndDsgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86 ZHJhZnQtaWV0Zi1tcGxzLWxkcC1oZWxsby1jcnlwdG8tYXV0aC5hbGxAdG9vbHMuaWV0Zi5vcmci PmRyYWZ0LWlldGYtbXBscy1sZHAtaGVsbG8tY3J5cHRvLWF1dGguYWxsQHRvb2xzLmlldGYub3Jn PC9hPiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhy ZWY9Im1haWx0bzppZXRmLW1wbHMtbGRwLWhlbGxvLV9fY3J5cHRvLWF1dGguYWxsQHRvb2xzLmll dGYub3JnIj5pZXRmLW1wbHMtbGRwLWhlbGxvLV9fY3J5cHRvLWF1dGguYWxsQHRvb2xzLmlldGYu b3JnPC9hPjxicj4NCiZndDsgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86 aWV0Zi1tcGxzLWxkcC1oZWxsby1jcnlwdG8tYXV0aC5hbGxAdG9vbHMuaWV0Zi5vcmciPmlldGYt bXBscy1sZHAtaGVsbG8tY3J5cHRvLWF1dGguYWxsQHRvb2xzLmlldGYub3JnPC9hPiZndDtfXyZn dDs7PGJyPg0KJmd0Ozxicj4NCjwvZGl2PjxkaXYgY2xhc3M9IiI+Jmd0OyDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBZYXJvbiBTaGVmZmVyIFN1YmplY3Q6IFJlOiBTZWNEaXIg cmV2aWV3IG9mPGJyPg0KPC9kaXY+Jmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBkcmFmdC1pZXRmLW1wbHMtbGRwLWhlbGxvLV9fY3J5cHRvLWF1dGgtMDU8YnI+DQo8ZGl2 PjxkaXYgY2xhc3M9Img1Ij4mZ3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBGb2xrcyw8YnI+DQomZ3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBJJiMzOTttIG9ubHkgdGhlIGRvY3VtZW50IHNoZXBoZXJkLiBNeSBm ZWVsaW5nIGlzPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0 aGF0IHdlIGFyZSByYWlzaW5nPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCB0aGUgaHVyZGxlIHN0ZXAgYnkgc3RlcCBmb3IgdGhlIEtBUlAgLSBpbml0aWF0ZWQ8 YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFJGQ3MsIHRoZSBm aXJzdDxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgd2FzIGNv bXBhcmF0aXZlbHkgc21vb3RoLCBub3cgd2UgYXJlIHRyeWluZyB0bzxicj4NCiZndDsgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcHV0IGFuIDE4IG1vbnRoczxicj4NCiZndDsg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZWZmb3J0IChpbmRpdmlkdWFsIGRy YWZ0IHRvIFJGQykgaW4gZnJvbnQgb2Y8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIGFwcHJvdmluZyBzb21ldGhpbmc8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoYXQgaXMgY29tcGFyYXRpdmVseSBzaW1wbGUgYW5kIHNl ZW4gYXMgcmFpc2luZzxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgTERQIHRvIHRoZSBzYW1lPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBzZWN1cml0eSBhcyB0aGUgb3RoZXIgcm91dGluZyBwcm90b2NvbHMuPGJyPg0KJmd0 Ozxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgU28gaWYgd2Ug Z2V0IHRvIHRpcmVkIHRvIHB1c2ggdGhpcywgd2UgYXJlIGFsbDxicj4NCiZndDsgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYmV0dGVyIG9mZiBub3Q8YnI+DQomZ3Q7IMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRvaW5nIHRoZSBzZWN1cml0eSB3b3JrIGZv ciB0aGlzIHBhcnRpY3VsYXI8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHByb3RvY29sPzxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIFNvbWVvbmUgc2FpZCAtICZxdW90O05ldmVyIGxldCB0aGUgYmVzdCBi ZSB0aGUgZW5lbXk8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IG9mIHRoZSBwb3NzaWJsZSZxdW90OyE8YnI+DQomZ3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAvTG9hPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7 PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBPbiAyMDE0LTA1 LTIxIDEyOjM5LCBNYW5hdiBCaGF0aWEgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgU3RlcGhlbiw8YnI+DQomZ3Q7PGJy Pg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBUaGlzIGhvd2V2ZXIgaXMgYSBsb25nIGRyYXduPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkaXNjdXNzaW9uIGJlY2F1 c2UgZXZlcnlvbmU8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIG5lZWRzIHRvPGJyPg0KJmd0Ozxicj4NCiZndDsgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYmU8YnI+DQomZ3Q7PGJyPg0KJmd0OyDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBjb252aW5jZWQg b24gdGhlIG1lcml0cyBvZiB1cGRhdGluZzxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhlIEhNQUMgc3BlY2lmaWNhdGlvbiAt LTxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgd2hpY2g8YnI+DQomZ3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBJPGJyPg0KJmd0Ozxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYW0gbm90IHN1cmUgd2lsbCB0YWtlIGhv dyBsb25nLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTbyBJIG5lZWQgdG8gbG9vayBhdCB0aGlzIGRy YWZ0LCBITUFDPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBhbmQgdGhlIG90aGVyIGNhc2VzIGJ1dDxicj4NCiZndDsgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaXQgc2VlbXMgdG8gbWUgdGhhdCB5 b3UmIzM5O3JlIGNvcHlpbmcgYTxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgcGFnZSBvciB0d28gb2YgY3J5cHRvIHNwZWM8YnI+DQomZ3Q7 IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGVhY2ggdGlt ZSBhbmQgY2hhbmdpbmcgb25lIGxpbmUuIERvaW5nPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGF0IG92ZXIgYW5kIG92ZXIgaXMgYTxi cj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg cmVjaXBlIGZvciBsb25nIHRlcm0gcGFpbiwgaXNuJiMzOTt0IGl0Pzxicj4NCiZndDs8YnI+DQom Z3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBJ dCBzdXJlIGlzLjxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIEkgaGFkIHZvbHVudGVlcmVkIHRvIHdyaXRlIGEgMS0yIHBhZ2UgbG9u Zzxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgSUQg dGhhdCB1cGRhdGVkIHRoZTxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgSE1BQzxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHRvPGJyPg0KJmd0Ozxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaW5jbHVkZSB0aGUgQXBhZCwgYnV0IHRoZSBpZGVhIHdh cyBzaG90PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBkb3duLiBUaGUgb25seTxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgYWx0ZXJuYXRpdmUgbGVmdCB3YXMgdG8gaW5jbHVkZSB0aGUgY3J5cHRvPGJy Pg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzdHVmZiBp biBlYWNoIHN0YW5kYXJkPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCB0aGF0IHdlIHdyb3RlIGxhdGVyLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0K Jmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAoQW5k IHdlJiMzOTt2ZSBoYWQgdGhpcyBkaXNjdXNzaW9uIGZvciBlYWNoPGJyPg0KJmd0OyDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzdWNoIGRyYWZ0IHdoaWxl IEkmIzM5O3ZlPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBiZWVuIG9uIHRoZSBJRVNHIEkgdGhpbmssIHdoaWNoIGlzIGFsc288YnI+DQom Z3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHNvbWV3 aGF0IGRyYXduIG91dDstKTxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBUaGlzIGRyYWZ0IGlzIHByb2JhYmx5IHRo ZSBsYXN0IG9uZSB0aGF0czxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgY29taW5nIGZyb20gdGhlIFJvdXRpbmc8YnI+DQomZ3Q7IMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFdHIHdoaWNoIHdpbGwgaGF2ZSB0aGlzIGxl dmVsIG9mIGNyeXB0bzxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgbWF0aGVtYXRpY3Mgc3BlbGxlZCBvdXQuPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBBbGwgb3RoZXIgSUdQcyBhcmUgYWxyZWFkeSBj b3ZlcmVkLiBJbiBjYXNlPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCB3ZSBuZWVkIHRvIGNoYW5nZTxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgc29tZXRoaW5nPGJyPg0KJmd0Ozxicj4NCiZndDsgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaW48YnI+DQomZ3Q7PGJyPg0KJmd0OyDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGUgb25lcyBhbHJlYWR5 IGNvdmVyZWQgd2UgY2FuIHJlZmVyIHRvIHRoZTxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYmFzZSBSRkMgd2hlcmUgd2U8YnI+DQomZ3Q7IMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGhhdmUgZGV0YWlsZWQgdGhlIGNy eXB0byBtYXRocy4gRm9yIGV4YW1wbGUsPGJyPg0KPC9kaXY+PC9kaXY+Jmd0OyDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkcmFmdC1pZXRmLW9zcGYtc2VjdXJpdHkt X19leHRlbnNpb24tbWFudWFsLWtleWluZy0wODxicj4NCjxkaXYgY2xhc3M9IiI+Jmd0OyDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhbW9uZ3N0PGJyPg0KJmd0OyDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBvdGhlciB0aGluZ3MgYWxz byB1cGRhdGVzIHRoZSBkZWZpbml0aW9uIG9mPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBBcGFkLiBJdCBwb2ludHMgdG88YnI+DQomZ3Q7IMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoZSBleGFjdCBtYXRoZW1hdGlj cyBpbiBSRkMgNTcwOSBhbmQgb25seTxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgdXBkYXRlcyB0aGUgQXBhZDxicj4NCiZndDsgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZGVmaW5pdGlvbiBpbiB0aGF0IGRyYWZ0LiBU aGlzIGRyYWZ0IGJ0dyBoYXM8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIGNsZWFyZWQgdGhlIFdHIExDPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhbmQgd291bGQgYmUgYXBwZWFyaW5nIGJlZm9yZSB5 b3UgZ3V5cyB2ZXJ5PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBzb29uLjxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIEdpdmVuIHRoaXMsIGkgdGhpbmsgd2Ugc2hvdWxkIGp1c3QgcGFz cyB0aGlzPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBkcmFmdCB3aXRoIHRoaXM8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIGxldmVsIG9mIGRldGFpbHMuIFN1YnNlcXVlbnRseSwgd2hlbiBMRFA8YnI+ DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHdhbnRzIHRv IHVwZGF0ZTxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgc29tZXRoaW5nLCBpdCBjYW4gbm9ybWF0aXZlbHkgcmVmZXIgdG8gdGhpczxicj4NCiZndDsg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgUkZDIGFuZCBvbmx5IGdp dmUgdGhlPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBjaGFuZ2VzLjxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIENoZWVycywgTWFuYXY8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZn dDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgUy48YnI+ DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIENoZWVycywgTWFuYXY8YnI+DQomZ3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFM8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi cj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgQ2hlZXJzLCBNYW5hdjxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIC0tLS0tT3JpZ2luYWw8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIE1lc3NhZ2Ut LS0tLSBGcm9tOjxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgU3RlcGhlbiBGYXJyZWxsPGJyPg0K PC9kaXY+PGRpdiBjbGFzcz0iIj4mZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFttYWlsdG86PGEgaHJlZj0i bWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy4iPnN0ZXBoZW4uZmFycmVsbEBjcy48L2E+X188YSBo cmVmPSJodHRwOi8vdGNkLmllIiB0YXJnZXQ9Il9ibGFuayI+dGNkLmllPC9hPjxicj4NCiZndDsg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZSI+c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZTwvYT4mZ3Q7PGJyPg0KJmd0OyDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzdGVwaGVuLmZhcnJlbGxA Y3MuIj5zdGVwaGVuLmZhcnJlbGxAY3MuPC9hPl9fPGEgaHJlZj0iaHR0cDovL3RjZC5pZSIgdGFy Z2V0PSJfYmxhbmsiPnRjZC5pZTwvYT48YnI+DQo8L2Rpdj48ZGl2IGNsYXNzPSIiPiZndDsgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNz LnRjZC5pZSI+c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZTwvYT4mZ3Q7Jmd0O108YnI+DQomZ3Q7 IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIFNlbnQ6PGJyPg0KJmd0Ozxicj4NCiZndDsgwqAgwqAgwqAgwqAgV2Vk bmVzZGF5LCBNYXk8YnI+DQomZ3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAyMSwgMjAxNCAy OjUzIEFNIFRvOjxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgQmhhdGlhLCBNYW5hdiAoTWFuYXYp OyBJRVRGPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTZWN1cml0eSBEaXJlY3RvcmF0ZTs8YnI+ DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRoZSBJRVNHOyBkcmFmdC08YnI+DQo8L2Rpdj48ZGl2IGNs YXNzPSIiPiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgPGEgaHJlZj0ibWFpbHRvOmlldGYtbXBscy1sZHAt aGVsbG8tY3J5cHRvLV9fYXV0aC5hbGxAdG9vbHMuaWV0Zi5vcmciPmlldGYtbXBscy1sZHAtaGVs bG8tY3J5cHRvLV9fYXV0aC5hbGxAdG9vbHMuaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzppZXRmLW1wbHMtbGRwLWhlbGxvLWNy eXB0by1hdXRoLmFsbEB0b29scy5pZXRmLm9yZyI+aWV0Zi1tcGxzLWxkcC1oZWxsby1jcnlwdG8t YXV0aC5hbGxAdG9vbHMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKg IMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmlldGYtbXBscy1sZHAtaGVsbG8tX19j cnlwdG8tYXV0aC5hbGxAdG9vbHMuaWV0Zi5vcmciPmlldGYtbXBscy1sZHAtaGVsbG8tX19jcnlw dG8tYXV0aC5hbGxAdG9vbHMuaWV0Zi5vcmc8L2E+PGJyPg0KPC9kaXY+Jmd0OyDCoCDCoCDCoCDC oCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzppZXRmLW1wbHMtbGRwLWhlbGxvLWNyeXB0by1h dXRoLmFsbEB0b29scy5pZXRmLm9yZyI+aWV0Zi1tcGxzLWxkcC1oZWxsby1jcnlwdG8tYXV0aC5h bGxAdG9vbHMuaWV0Zi5vcmc8L2E+Jmd0O19fJmd0OyBDYzo8YnI+DQomZ3Q7PGJyPg0KJmd0OyDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBZYXJvbjxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgPGEgaHJlZj0ibWFp bHRvOlNoZWZmZXIlM0JtYW5hdmJoYXRpYUBnbWFpbC5jb20iPlNoZWZmZXI7bWFuYXZiaGF0aWFA Z21haWwuY29tPC9hPjxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVm PSJtYWlsdG86U2hlZmZlciUyNTNCbWFuYXZiaGF0aWFAZ21haWwuY29tIj5TaGVmZmVyJTNCbWFu YXZiaGF0aWFAZ21haWwuY29tPC9hPiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZsdDtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOm1hbmF2YmhhdGlhQGdtYWlsLmNvbSI+bWFuYXZiaGF0aWFA Z21haWwuY29tPC9hPjxicj4NCjxkaXYgY2xhc3M9IiI+Jmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7 bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptYW5hdmJoYXRpYUBnbWFpbC5jb20iPm1hbmF2YmhhdGlh QGdtYWlsLmNvbTwvYT4mZ3Q7Jmd0Ozxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgU3ViamVjdDog UmU6PGJyPg0KJmd0Ozxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgU2VjRGlyIHJldmlldyBvZjxi cj4NCjwvZGl2PiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZHJhZnQtaWV0Zi1tcGxzLWxkcC1oZWxsby1f X2NyeXB0by1hdXRoLTA1PGJyPg0KPGRpdj48ZGl2IGNsYXNzPSJoNSI+Jmd0Ozxicj4NCiZndDs8 YnI+DQomZ3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBPbiAxOS8wNS8xNCAyMToyNywgWWFy b248YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFNoZWZmZXIgd3JvdGU6PGJyPg0KJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICogNS4xOjxi cj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgUmVkZWZpbmluZzxicj4N CiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgSE1BQyAoUkZDPGJyPg0KJmd0 OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAyMTA0KSBpcyBhbjxicj4NCiZndDsg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZXh0cmVtZWx5PGJyPg0KJmd0OyDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBiYWQgaWRlYS48YnI+DQomZ3Q7IMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRoaXM8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHJldmlld2VyPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBkb2VzIG5vdDxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgaGF2ZSB0aGU8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IGFwcHJvcHJpYXRlPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBi YWNrZ3JvdW5kPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0byBj cml0aXF1ZTxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhlIHBy b3Bvc2VkPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzb2x1dGlv biw8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGJ1dCB0aGVyZTxi cj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgbXVzdCBiZSBhbjxicj4N CiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgb3ZlcndoZWxtaW5nPGJyPg0K Jmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCByZWFzb24gdG88YnI+DQomZ3Q7 PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCByZW9wZW4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBjcnlwdG9ncmFwaGljIHByaW1pdGl2ZXMuPGJyPg0K Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRoaXMg aXMgYTxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZGVjaXNpb24gdGhhdDxi cj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgd2FzIHRha2VuIGJ5IFNlYzxicj4N CiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgQWRzIHdoZW48YnI+DQomZ3Q7IMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHdlIHdlcmUgZG9pbmc8YnI+DQomZ3Q7IMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHRoZSBjcnlwdG88YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHByb3RlY3Rpb24gZm9yPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCB0aGUgSUdQczxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYmFzZWQgb24g c29tZTxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZmVlZGJhY2sgZnJvbSBO SVNULjxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRoaXM8YnI+DQomZ3Q7PGJy Pg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBtYXRoZW1hdGljcyBpczxicj4NCiZn dDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgbm90IG5ldyBhbmQgaGFzPGJyPg0KJmd0OyDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBiZWVuIGRvbmUgZm9yIGFsbDxicj4NCiZndDsgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgSUdQcyBhbmQgaGFzPGJyPg0KJmd0OyDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBiZWVuIGFwcHJvdmVkPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBhbmQgcmF0aGVyPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBlbmNvdXJhZ2VkIGJ5PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGUg U2VjdXJpdHkgQURzLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBUaGUgYWJvdmUgZG9lcyBub3Qgc291bmQ8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGxpa2Ug c29tZXRoaW5nIEk8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJlY29nbmlzZS4gSTxicj4NCiZn dDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgaGF2ZSByZXBlYXRlZGx5IGFza2VkPGJyPg0KJmd0OyDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCB0aGF0IGRvY3VtZW50cyBub3QgcmUtZGVmaW5lPGJyPg0KJmd0OyDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBITUFDLiBQZXJoYXBzIHRoaXMgdGltZSw8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEkm IzM5O2xsIG1ha2UgdGhhdCBhIERJU0NVU1MgYW5kPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBu b3QgYnVkZ2UuIEkgcHJvYmFibHk8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHNob3VsZCBoYXZl IGRvbmUgdGhhdCBiZWZvcmU8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRCSC48YnI+DQomZ3Q7 PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBJZiB5b3UgYXJlIHJldmlzaW5nIHRoYXQ8YnI+DQom Z3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIGRvYywgKnBsZWFzZSogZ2V0IHJpZCBvZiB0aGU8YnI+DQomZ3Q7 IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHJlLWRlZmluaXRpb24gYW5kIGp1c3Q8YnI+DQomZ3Q7IMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHByb3Blcmx5IHJlZmVyIHRvIEhNQUMuIEl0czxicj4NCiZndDsgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgYWJvdXQgdGltZSB0byBzdG9wPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCByZXBlYXRpbmcg dGhhdCBlcnJvci48YnI+DQomZ3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTLjxicj4NCiZn dDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCAtLTxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBMb2EgQW5kZXJzc29uIDxhIGhyZWY9Im1haWx0bzplbWFpbCUzQWxv YUBtYWlsMDEuaHVhd2VpLmNvbSI+ZW1haWw6bG9hQG1haWwwMS5odWF3ZWkuY29tPC9hPjxicj4N CjwvZGl2PjwvZGl2PiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0 O21haWx0bzo8YSBocmVmPSJtYWlsdG86ZW1haWwlMjUzQWxvYUBtYWlsMDEuaHVhd2VpLmNvbSI+ ZW1haWwlM0Fsb2FAbWFpbDAxLmh1YXdlaS5jb208L2E+Jmd0Ozxicj4NCiZndDsgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bG9h QG1haWwwMS5odWF3ZWkuY29tIj5sb2FAbWFpbDAxLmh1YXdlaS5jb208L2E+PGJyPg0KPGRpdiBj bGFzcz0iIj4mZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZsdDttYWls dG86PGEgaHJlZj0ibWFpbHRvOmxvYUBtYWlsMDEuaHVhd2VpLmNvbSI+bG9hQG1haWwwMS5odWF3 ZWkuY29tPC9hPiZndDsmZ3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBTZW5pb3IgTVBMUyA8YSBocmVmPSJtYWlsdG86RXhwZXJ0bG9hQHBpLm51Ij5FeHBl cnRsb2FAcGkubnU8L2E+PGJyPg0KPC9kaXY+Jmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpFeHBlcnRsb2FAcGkubnUiPkV4 cGVydGxvYUBwaS5udTwvYT4mZ3Q7ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmxvYUBwaS5u dSI+bG9hQHBpLm51PC9hPjxicj4NCjxkaXYgY2xhc3M9IiI+Jmd0OyDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpsb2FAcGkubnUi PmxvYUBwaS5udTwvYT4mZ3Q7Jmd0OyBIdWF3ZWk8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgwqAgwqAgcGhvbmU6 KzQ2IDczOSA4MTxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg MjEgNjQgJmx0O3RlbDolMkI0NiUyMDczOSUyMDgxJTIwMjElMjA2NCZndDs8YnI+DQo8L2Rpdj4m Z3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZsdDt0ZWw6JTJCNDYlMjA3 MzklMjA4MSUyMDIxJV9fMjA2NCZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCjxkaXYgY2xhc3M9IiI+Jmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBzZWNkaXIgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCA8YSBocmVmPSJtYWlsdG86c2VjZGlyQGlldGYub3JnIj5zZWNkaXJAaWV0Zi5vcmc8L2E+ICZs dDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNlY2RpckBpZXRmLm9yZyI+c2VjZGlyQGlldGYub3Jn PC9hPiZndDs8YnI+DQo8L2Rpdj48ZGl2IGNsYXNzPSIiPiZndDsgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2VjZGlyQGlldGYub3JnIj5zZWNkaXJA aWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNlY2RpckBpZXRmLm9yZyI+ c2VjZGlyQGlldGYub3JnPC9hPiZndDsmZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9fX2xp c3RpbmZvL3NlY2RpciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vX19saXN0aW5mby9zZWNkaXI8L2E+PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZWNk aXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NlY2RpcjwvYT4mZ3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB3aWtpOjxh IGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9fX2FyZWEvc2VjL3RyYWMvd2lraS9fX1NlY0Rp clJldmlldyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9fX2FyZWEvc2Vj L3RyYWMvd2lraS9fX1NlY0RpclJldmlldzwvYT48YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgICZsdDs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvYXJlYS9zZWMvdHJhYy93 aWtpL1NlY0RpclJldmlldyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9h cmVhL3NlYy90cmFjL3dpa2kvU2VjRGlyUmV2aWV3PC9hPiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0 Ozxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCjwvZGl2PjxkaXYgY2xhc3M9IiI+Jmd0OyDCoCDC oCDCoCDCoCDCoCDCoCBzZWNkaXIgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDC oCDCoCA8YSBocmVmPSJtYWlsdG86c2VjZGlyQGlldGYub3JnIj5zZWNkaXJAaWV0Zi5vcmc8L2E+ ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNlY2RpckBpZXRmLm9yZyI+c2VjZGlyQGlldGYu b3JnPC9hPiZndDs8YnI+DQo8L2Rpdj48ZGl2IGNsYXNzPSIiPiZndDsgwqAgwqAgwqAgwqAgwqAg wqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2VjZGlyQGlldGYub3JnIj5zZWNkaXJAaWV0 Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNlY2RpckBpZXRmLm9yZyI+c2Vj ZGlyQGlldGYub3JnPC9hPiZndDsmZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgwqAgwqAgwqAgwqAg wqAgwqAgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9fX2xpc3RpbmZvL3Nl Y2RpciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vX19saXN0 aW5mby9zZWNkaXI8L2E+PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7PGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZWNkaXIiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NlY2RpcjwvYT4mZ3Q7 PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCB3aWtpOjxhIGhyZWY9Imh0dHA6Ly90b29scy5p ZXRmLm9yZy9fX2FyZWEvc2VjL3RyYWMvd2lraS9fX1NlY0RpclJldmlldyIgdGFyZ2V0PSJfYmxh bmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9fX2FyZWEvc2VjL3RyYWMvd2lraS9fX1NlY0RpclJl dmlldzwvYT48YnI+DQo8L2Rpdj48ZGl2IGNsYXNzPSIiPiZndDsgwqAgwqAgwqAgwqAgwqAgwqAg Jmx0OzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9hcmVhL3NlYy90cmFjL3dpa2kvU2Vj RGlyUmV2aWV3IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2FyZWEvc2Vj L3RyYWMvd2lraS9TZWNEaXJSZXZpZXc8L2E+Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0K Jmd0Ozxicj4NCiZndDsgwqAgwqAgLS08YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgwqAg wqAgTG9hIEFuZGVyc3NvbiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGVtYWls OiA8YSBocmVmPSJtYWlsdG86bG9hQG1haWwwMS5odWF3ZWkuY29tIj5sb2FAbWFpbDAxLmh1YXdl aS5jb208L2E+PGJyPg0KPC9kaXY+Jmd0OyDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0 bzpsb2FAbWFpbDAxLmh1YXdlaS5jb20iPmxvYUBtYWlsMDEuaHVhd2VpLmNvbTwvYT4mZ3Q7PGJy Pg0KJmd0OyDCoCDCoCBTZW5pb3IgTVBMUyBFeHBlcnQgPGEgaHJlZj0ibWFpbHRvOmxvYUBwaS5u dSI+bG9hQHBpLm51PC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpsb2FAcGkubnUiPmxv YUBwaS5udTwvYT4mZ3Q7PGJyPg0KPGRpdiBjbGFzcz0iaW0gSE9FblpiIj4mZ3Q7IMKgIMKgIEh1 YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQpIMKgIMKgIHBob25lOiA8YSBocmVmPSJ0ZWw6 JTJCNDYlMjA3MzklMjA4MSUyMDIxJTIwNjQiIHZhbHVlPSIrNDY3Mzk4MTIxNjQiPis0NiA3Mzkg ODEgMjEgNjQ8L2E+PGJyPg0KJmd0OyDCoCDCoCAmbHQ7dGVsOiUyQjQ2JTIwNzM5JTIwODElMjAy MSUyMDY0Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KPGJyPg0KPC9kaXY+PGRpdiBjbGFz cz0iSE9FblpiIj48ZGl2IGNsYXNzPSJoNSI+LS08YnI+DQo8YnI+DQo8YnI+DQpMb2EgQW5kZXJz c29uIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZW1haWw6IDxhIGhyZWY9Im1h aWx0bzpsb2FAbWFpbDAxLmh1YXdlaS5jb20iPmxvYUBtYWlsMDEuaHVhd2VpLmNvbTwvYT48YnI+ DQpTZW5pb3IgTVBMUyBFeHBlcnQgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqA8YSBocmVmPSJtYWlsdG86bG9hQHBpLm51Ij5sb2FAcGkubnU8L2E+PGJyPg0KSHVhd2VpIFRl Y2hub2xvZ2llcyAoY29uc3VsdGFudCkgwqAgwqAgcGhvbmU6IDxhIGhyZWY9InRlbDolMkI0NiUy MDczOSUyMDgxJTIwMjElMjA2NCIgdmFsdWU9Iis0NjczOTgxMjE2NCI+KzQ2IDczOSA4MSAyMSA2 NDwvYT48YnI+DQo8L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjwvZGl2Pg0K --047d7b3a81a0a82d5b04fa70a761-- From nobody Wed May 28 02:42:45 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218731A08A3; Wed, 28 May 2014 02:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.639 X-Spam-Level: X-Spam-Status: No, score=-101.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnKeLiXXZQUy; Wed, 28 May 2014 02:42:40 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5EA31A08A6; Wed, 28 May 2014 02:42:35 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s4S9funE016271; Wed, 28 May 2014 10:41:56 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s4S9fqnF016235 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 May 2014 10:41:53 +0100 From: "Adrian Farrel" To: "'Tina TSOU'" , , "'The IESG'" , References: In-Reply-To: Date: Wed, 28 May 2014 10:41:54 +0100 Message-ID: <03b801cf7a59$10339e10$309ada30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03B9_01CF7A61.71FB1350" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHuqFyJr618hkIR4SkkIQUNznzMUJsXYEtw Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20720.006 X-TM-AS-Result: No--17.013-10.0-31-10 X-imss-scan-details: No--17.013-10.0-31-10 X-TMASE-MatchedRID: yebcs53SkkB5X0FJZbmEplaOpp/sV5nVOhJ9m53n4aBaW2Ktn+I8/gNz NPuvThWtkSqH+Kc9BkIQDZh9tV+I0ba2Vh2jQ2eErA6HcPclJMa1k3bRIdXVNLrfxlRjqBJ3Ffu 9xZgL7lcaGJ6hc5LcclmOdb8MqKJnIb5y7s6OC0xbuDP8ZuCmXr4kZYg1dp8susef4abk6p0yto nrvDOcsfD5I9mHdz1CRRKksvaWeO53daUeCOH6HfyAR9DgC/hHUCwb19dUaUllbnk1HqKhKjJ2n cI9Ab5F4FPBvB8THgwkyJUnPwZoviC92D94UBz+ZwmQqXe/8sNfjyTZEf6/10Yx760ONDcW9c93 RvN2G/cu/7HsWD1fMNopkMzURarkBdPqXpSPY10tR8fVMTBo3dIv4RV84lHTRL9uhZIYy10+avt yet/ecDAkDQ4MCPBMn35cKPv4RPYamKBTix5It3yisJcA82QktDSfcMR+7ZPn0JXek/DSxTnSYw R4FpNFBSuHQ7HM64ukt1bypCWySufehSI6eWNzpkIW3Gref32gF68P3HFTmci9AjK6C8p1biGmw SWrlIAcl4Vrs6KMmBIaAHp9icVsZP2HNi+vOdZjuN6nCSmvr6TYf9v9floldDwP5ItpCOwcSRF9 JP5Ozi4jb1n1eNA3hzKlTm8jzDLDWFe972ARUI7Su3QulAZ5FKliqHKCaOnrKAwxOgrz3aeFnJs qgWxcQt2470g7vecsWi4sXciGhT8G3G/wjVDpcLw8nYQVLsggFyxci4S+VuRnWbJNcqgXKqHlxT J7eJUibp8py4XIryhHQrcMnybC1lfDCm9+EZWeAiCmPx4NwGmRqNBHmBvevqq8s2MNhPB9j2Gwz TE3vXkguuQorcgMrjzoJQxQwa4C4tIeVX3Agh38xpL4Ps3Stazz1MQ8tR9+3BndfXUhXQ== Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/obIbbrU8Gi5jzliCXuPHQiCeywY Subject: Re: [secdir] Secdir review of draft-ietf-pce-pcep-inter-domain-p2mp-procedure-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 09:42:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03B9_01CF7A61.71FB1350 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thank you Tina, Authors, please look at Tina's review. I don't think there is anything to do in this draft for Tina's main comment (and we could easily rat-hole in the discussion of what routing neighbors can do to each other that is "unfriendly"), but there are quite a few nits you should clean up. Thanks, Adrian From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Tina TSOU Sent: 28 May 2014 07:30 To: ; The IESG; draft-ietf-pce-pcep-inter-domain-p2mp-procedure.all@tools.ietf.org Subject: Secdir review of draft-ietf-pce-pcep-inter-domain-p2mp-procedure-06 Dear all, 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. Technical comments: This draft focused on solving inter-domain P2MP procedures. The solution is based on a core-tree and corresponding sub-trees construction, with BRPC used as reference. The procedure in this draft is complete and promising for an inter-domain P2MP path computation. However, for future work, following comments may be considered: Now each PCE is considered friendly with each other, i.e., the cost on the sub-tree will be reflected on the core-tree, and the signals are free to be transmitted correspondingly. But, this is the ideal case, PCE may need to hide some intra-domain information due to some security policies, so that global optimization may not be achieved. In this way, it should be better to split into a few scenarios, such as 'friendly' and 'not friendly' case. In the 'not friendly' scenario, it is also necessary to limit what signal is allowed and what is prohibited. There is no much existing work for this scenario, even for a P2P path computation, so the work for P2MP computation in this scenario should be listed as future work. Nits: In section 1, captions are not numbered correctly. The item "scope" and "Requirements Language" should be section 1.1 and 1.2 respectively. In section 3, the 5th paragraph, "as discussed in [RFC4461], .", the last sentence should be changed as follow: Not only is this selection constrained by the network topology and available network resources, but it is also determined by the objective functions (OF) that may be applied to path computation. Then in the next paragraph, "Generally, an inter-domain .", following changes are suggested: For instance, while the BRPC may be well-suited for P2P paths, P2MP path computation involves multiple branching path segments from the source to themultiple destinations. As such, inter-domain P2MP path computation may result in a plurality of per-domain path options that may be difficult to coordinate efficiently and effectively between among domains. In the second paragraph from bottom of Section 3, "P2MP Minimum Cost Tree (MCT), .", following changes are suggested: P2MP Minimum Cost Tree (MCT), i.e., a computation which guarantees the least cost resulting tree, typically is an NP-complete problem. Moreover, adding and/or removing a single destination to/from the tree may result in an entirely different tree. In this casethese cases, frequent MCT path computation requests may prove computationally intensive, and the resulting frequent tunnel reconfiguration may even cause network destabilization. For section 4, the first assumption is suggested to be: Due to deployment and commercial limitations (e.g., inter-AS peering agreements), the path domain tree willshould be known in advance; For section 5, the 4th requirements is suggested to change: 4. Specifying which nodes are being used as branch nodes SHOULD be supported in the PCReq. For section 7.2, in the paragraph "Without trimming, the ingress.", the following change is recommended: Without trimming, the ingress PCE will obtain all the possible S2L sub-paths set for the entry boundary nodes of the leaf domain. The PCE will then, by looking through all the combinations and taking one sub-path from each set to build one tree, canselect the optimal core-tree. For section 7.3, in the paragraph "Note that the P2MP path request.", the following change is recommended: Note that the P2MP path request and response format is as per [RFC6006], where Record Route Object (RRO) areis used to carry the core-tree paths in the P2MP grafting request. For section 8.1, the following change is recommended: 8.1. End-to-end Protection An end-to-end protection (for nodes and links) principle can be applied for computing backup P2MP TE LSPs. During computation of the core-tree and sub-trees, the computation of protection may also be taken into consideration. A PCE may compute the primary and backup P2MP TE LSP together or sequentially. Thank you, Tina ------=_NextPart_000_03B9_01CF7A61.71FB1350 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank you = Tina,

 

Authors, please look = at Tina's review. I don't think there is anything to do in this draft = for Tina's main comment (and we could easily rat-hole in the discussion = of what routing neighbors can do to each other that is = "unfriendly"), but there are quite a few nits you should clean = up.

 

Thanks,

Adrian

 

From: iesg = [mailto:iesg-bounces@ietf.org] On Behalf Of Tina = TSOU
Sent: 28 May 2014 07:30
To: = <secdir@ietf.org>; The IESG; = draft-ietf-pce-pcep-inter-domain-p2mp-procedure.all@tools.ietf.org
= Subject: Secdir review of = draft-ietf-pce-pcep-inter-domain-p2mp-procedure-06

<= /div>

 

Dear = all,

 

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.

 

Technical = comments:

This draft focused = on solving inter-domain P2MP procedures. The solution is based on a = core-tree and corresponding sub-trees construction, with BRPC used as = reference. The procedure in this draft is complete and promising for an = inter-domain P2MP path computation. However, for future work, following = comments may be considered:

Now each PCE is = considered friendly with each other, i.e., the cost on the sub-tree will = be reflected on the core-tree, and the signals are free to be = transmitted correspondingly. But, this is the ideal case, PCE may need = to hide some intra-domain information due to some security policies, so = that global optimization may not be achieved. In this way, it should be = better to split into a few scenarios, such as ‘friendly’ and = ‘not friendly’ case. In the ‘not = friendly’ scenario, it is also necessary = to limit what signal is allowed and what is prohibited. There is no much = existing work for this scenario, even for a P2P path computation, so the = work for P2MP computation in this scenario should be listed as future = work.

 

Nits:

In section 1, captions are not = numbered correctly. The item “scope” and = “Requirements = Language” should be section 1.1 and 1.2 = respectively.

 

In section 3, the = 5th paragraph, “as = discussed in [RFC4461], …”, the = last sentence should be changed as = follow:

Not only is this selection = constrained by the network topology and available network resources, but = it is also determined by the = objective functions (OF) that may be applied to path = computation.

 

Then in the next paragraph, = “Generally, an inter-domain …”, following changes are = suggested:

For instance, while the BRPC = may be well-suited for P2P paths, P2MP path computation involves = multiple branching path segments from the source to themultiple destinations. As such, = inter-domain P2MP path computation may result in a plurality of = per-domain path options that may be difficult to coordinate efficiently = and effectively between among = domains.

 

In the second paragraph from = bottom of Section 3, “P2MP = Minimum Cost Tree (MCT), …”, = following changes are suggested:

P2MP Minimum Cost Tree (MCT), = i.e., a computation which guarantees the least cost resulting tree, = typically is an NP-complete problem. Moreover, adding and/or removing a = single destination to/from the tree may result in an entirely different = tree.  In this casethese cases, frequent MCT path = computation requests may prove computationally intensive, and the = resulting frequent tunnel reconfiguration may even cause network = destabilization.

 

For section 4, the first = assumption is suggested to be:

Due to deployment and = commercial limitations (e.g., inter-AS peering agreements), the path = domain tree willshould be known in = advance;

 

For section 5, the = 4th requirements is suggested to change: =

     &= nbsp;4.  Specifying which nodes are being used as branch nodes SHOULD be = supported in the PCReq.

 

For section 7.2, in the = paragraph “Without trimming, the ingress…”, the following change is recommended: =

Without trimming, the ingress = PCE will obtain all the possible S2L sub-paths set for the entry = boundary nodes of the leaf domain. The PCE will then, by looking through = all the combinations and taking one sub-path from each set to build one = tree,  canselect the = optimal core-tree.

 

For section 7.3, in the = paragraph “Note that the P2MP path request…”, the following change is = recommended:

Note that the P2MP path = request and response format is as per [RFC6006], where Record Route = Object (RRO) areis used to carry the core-tree paths = in the P2MP grafting request.

 

For section 8.1, the following = change is recommended:

8.1. End-to-end = Protection

   An end-to-end = protection (for nodes and links) principle can be applied for computing = backup P2MP TE LSPs.  During computation of the core-tree and = sub-trees, the computation of = protection may also be taken into consideration. A PCE may = compute the primary and backup P2MP TE LSP together or = sequentially.

 =

  =

Thank = you,

Tina

=

 

------=_NextPart_000_03B9_01CF7A61.71FB1350-- From nobody Wed May 28 16:58:48 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0C71A07AA; Wed, 28 May 2014 16:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62zI6vNTgeYO; Wed, 28 May 2014 16:58:41 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AB1F1A02AE; Wed, 28 May 2014 16:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=650; q=dns/txt; s=iport; t=1401321518; x=1402531118; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=Xwojo52Nvjlwfx+i0VvHdIRWML0mJgn3XKqqW6ajahE=; b=Eh2TVMgmOuA9D/hYVJqV0eg4Kdmnj/E+yGeVuipQrp1IaRfuJaqtrJMw vx+Wd2I3RaYvLjgrQLiwkSpgQZ1pnPaY84yNBhyYOkpp5jNPN1ItOsvvY mcXV0YcD3WCIP+gxDwJUVG3SwEj1aniccIzoyt9lHtyZHJO7ppzceaYep c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgGANJ3hlOtJA2N/2dsb2JhbABagwerOQEBAQEBAQUBBZgYgRAWdIJmP4E+AYhU2BYXhVWIGxEBUIMygRUEiiKPU4ZrjDyDWB2BOQ X-IronPort-AV: E=Sophos;i="4.98,931,1392163200"; d="scan'208";a="328660495" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-2.cisco.com with ESMTP; 28 May 2014 23:58:37 +0000 Received: from [10.154.165.36] ([10.154.165.36]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s4SNwaDc004067 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 May 2014 23:58:36 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 28 May 2014 16:58:35 -0700 Message-Id: To: "secdir@ietf.org" , The IESG Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/LjLDykTB7ZBCcHPtCxuuBN2UlLo Cc: draft-adolf-dvb-urn-upd.all@tools.ietf.org Subject: [secdir] Secdir review of draft-adolf-dvb-urn-upd-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 23:58:43 -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 changes the email address of the registrant to a URN = namespace. Given the the same email address is used for one of the = author's contact information and is presumably verified as part of this = document action, there appears to be no security considerations for the = change. Brian= From nobody Thu May 29 17:07:00 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9841A06FC; Thu, 29 May 2014 17:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.043 X-Spam-Level: X-Spam-Status: No, score=-0.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 313qAZfo_a5e; Thu, 29 May 2014 17:06:54 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE3691A06D5; Thu, 29 May 2014 17:06:53 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id s4U06lQk001024; Fri, 30 May 2014 09:06:47 +0900 (JST) Received: from VAIO (ssh.nict.go.jp [133.243.3.49]) by gw1.nict.go.jp with ESMTP id s4U06l5H000400; Fri, 30 May 2014 09:06:47 +0900 (JST) From: "Takeshi Takahashi" To: "'Emil Ivov'" , , , , References: <000001cf759b$d1250a40$736f1ec0$@nict.go.jp> <53875DAA.7040300@jitsi.org> In-Reply-To: <53875DAA.7040300@jitsi.org> Date: Fri, 30 May 2014 09:06:46 +0900 Message-ID: <006d01cf7b9b$0c5c5a00$25150e00$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQGpdc4eCM3X30+OF6FplBz+SBLqigGqk0X0m5bxE8A= Content-Language: ja X-Virus-Scanned: clamav-milter 0.97.8 at zenith1 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/3rsb2mqhpaApIyO2DYaf-9D3ZFI Subject: Re: [secdir] Secdir review of draft-ietf-mmusic-latching-05.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 00:06:56 -0000 Hi Emil, I've browsed the new version (-06). IMHO, this is a nice draft, and I am hoping to see this draft to be published soon. > Right. SDP and SIP were indeed transgressing (fixed now) but all of the > others seem to be expanded on first use. Or am I missing something? Thank you for checking. I believe you are correct, and the current version is fine for me. > Well, they actually refer to quite different things. RTC, as you point out, > refers to real-time communication. SBC on the other hand stands for session > border controller (which is a signalling entity used by some RTC services). > > Did I misunderstand the question, or do you believe the text is somehow > misleading? Thank you for the clarification. The texts were very fine, the texts were very easy to follow even for the people who does not know this area of work (like me) throughout the draft, and it is me who misinterpreted the texts. I misinterpreted the very first sentence of the draft in the abstract, and I believe no change is needed at all. (From the first sentence, I interpreted as "RTC = SBCs", but I should have interpreted as "signaling intermediaries in RTC = SBCs"). I personally like this draft very much. Thank you for writing this document. Take > -----Original Message----- > From: Emil Ivov [mailto:emcho@jitsi.org] > Sent: Friday, May 30, 2014 1:18 AM > To: Takeshi Takahashi; iesg@ietf.org; secdir@ietf.org; > mmusic-chairs@tools.ietf.org; draft-ietf-mmusic-latching@tools.ietf.org > Subject: Re: Secdir review of draft-ietf-mmusic-latching-05.txt > > Hey Takeshi, > > Thank you for your review. Comments inline: > > On 22.05.14, 10:57, Takeshi Takahashi 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. > > > > This document describes the behavior of signaling intermediaries in RTC > > deployments when performing hosted NAT traversal (HNT). > > The document begins with summarizing the problems with NAT traversal > > for protocols such as SIP, and then outlines HNT and the latching > > mechanism that approach the problems. > > Nevertheless, this document is not recommending the use of latching. > > Instead, the document alerts its use and elaborates its security > > concerns in Section 5 "Security considerations" by showing several > examples. > > The security consideration covers issues such as > > DoS-resistance/resource exhaustion, impersonation and addresses the use > of encryption mechanism. > > > > It is an interesting, tutorial-like document, and I think this > > document is ready. > > > > According to the mmusic mailing list, the security consideration > > section has been discussed from the early stage of this draft, so the > > section also seems to be mature, IMHO. > > A bit of editorial review would be helpful. > > > > 1. It could be helpful if you could spell out the abbreviations when > > they appear at the first time (e.g., UAC, UAS, SIP, SDP, and SBC), not > > at the second time. > > Right. SDP and SIP were indeed transgressing (fixed now) but all of the > others seem to be expanded on first use. Or am I missing something? > > > 2. In section 1: " and described in [RFC3424]" should be "as described > > in [RFC3424]"? > > Fixed. > > > 3. In section 4: "from from" -> "from" ? > > Fixed. > > > The review was based on the document uploaded at > > https://datatracker.ietf.org/doc/draft-ietf-mmusic-latching/ . > > > > By the way, if RTC and SBC are used as the identical terms in this > > document, why do we use the term RTC (Real Time Communication) in the > > document tile while we use the term SBC in the main body texts? > > Well, they actually refer to quite different things. RTC, as you point out, > refers to real-time communication. SBC on the other hand stands for session > border controller (which is a signalling entity used by some RTC services). > > Did I misunderstand the question, or do you believe the text is somehow > misleading? > > > In any case, it is a very minor comment, and I think the draft is > > ready to move forward. > > > > Take > > Thanks again, all fixes will be available in the next submission. > > Emil > > -- > https://jitsi.org From nobody Fri May 30 01:24:17 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 805231A026D; Fri, 30 May 2014 01:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyn8KwTiyv5s; Fri, 30 May 2014 01:24:14 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC5CC1A6EF8; Fri, 30 May 2014 01:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1867; q=dns/txt; s=iport; t=1401438250; x=1402647850; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=T22qZa/7VvZBjRkNHG03eSsrwLDvxH2pOawgKl16PCU=; b=M0C7oMUazVryBbQ+HRvYT7rXhcpnGUZD2K7ydyzca/eLucBKfR7XNv91 pmEss+sK1qZ6x1IdaaaETVnpRp3YQ41NKzkoikDYFvXmYoWZO76KK0XCb YkKz3BbKVLp6LBF9VlZ95+b8l6Tp6vh6xekdU6Ck4HjlyyiFfvgxaz8hp k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgGADo/iFOtJV2U/2dsb2JhbABZgweBKqoVAQEBAQEBBQEFmRoWdIIsgQsBgQAnBAGIVNZ1F4VVjC+BFQSZepMsgziCLw X-IronPort-AV: E=Sophos;i="4.98,939,1392163200"; d="scan'208";a="329137321" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-8.cisco.com with ESMTP; 30 May 2014 08:24:09 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s4U8O9YZ000415 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 May 2014 08:24:09 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.80]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Fri, 30 May 2014 03:24:09 -0500 From: "Klaas Wierenga (kwiereng)" To: "iesg@ietf.org" , "secdir@ietf.org" , "draft-iab-2870bis.all@tools.ietf.org" Thread-Topic: review of draft-iab-2870bis-01 Thread-Index: AQHPe+CHOiNbHuQdUUWnnFqhc5tLFw== Date: Fri, 30 May 2014 08:24:08 +0000 Message-ID: <0B5213DB-58F9-4947-BB2E-D5EACC0C42FB@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.96.46] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/OSrS20g0aSqxIBSukgIdMlhEAlM Subject: [secdir] review of draft-iab-2870bis-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 08:24:15 -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. This document specifies he protocol and deployment requirements expected to= be implemented for the DNS root name service, operational requirements are= taken out of 2870, those are published separately (one hopes, see below). The document is short (thank you! ;-) and clear. I consider it ready with a= few issues: =3D=3D=3D - paragraph 3 (deployment requirements): "The root name service: MUST answer queries from any entity conforming to [RFC1122] with a valid IP address.=94 I find this a bit confusing. Perhaps showing my ignorance, but should it no= t be be =93=85 with a valid IP-address or a referral to an authoritative na= me server=94? - paragraph 4 (security considerations): This is a bit weak imo.=20 At the very least I would expect some discussion about privacy here or in a= separate section =93privacy considerations=94, queries to the root give go= od insight into what sites the requester is visiting, mitigated by the fact= that most queries will not reach the root due to caching of responses. In = any case worth some discussion in the era of pervasive surveillance=85. Furthermore, the reference to [RSSAC-001] leads to a list of members of RSS= AC, not to a document. A quick search at the RSSAC site also didn=92t get m= e to any document called "Service Expectations of Root Servers=94, only to = the project that was supposed to deliver it. I think you need to fix that r= eference. =3D=3D=3D Hope this helps, Klaas From nobody Fri May 30 03:14:32 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 049961A079F for ; Fri, 30 May 2014 03:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6freD6FwdzN for ; Fri, 30 May 2014 03:14:30 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 9DFA41A03E3 for ; Fri, 30 May 2014 03:14:29 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s4UAEMaU013450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 30 May 2014 13:14:22 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s4UAEMTL006639; Fri, 30 May 2014 13:14:22 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21384.23038.480965.914583@fireball.kivinen.iki.fi> Date: Fri, 30 May 2014 13:14:22 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/IpLuBak81ykGS6wSadxxNH4umZI Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 30 May 2014 10:14:32 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Dan Harkins is next in the rotation. For telechat 2014-06-12 Reviewer LC end Draft Derek Atkins T 2014-06-03 draft-ietf-isis-fs-lsp-01 Rob Austein T 2014-06-04 draft-ietf-nvo3-framework-06 Tom Yu T 2014-05-30 draft-ietf-6man-multicast-scopes-05 Dacheng Zhang T 2014-06-03 draft-ietf-idr-bgp-enhanced-route-refresh-06 For telechat 2014-06-26 Shaun Cooley T 2014-06-12 draft-ietf-appsawg-sieve-duplicate-06 Last calls and special requests: Alan DeKok 2014-06-11 draft-ietf-hip-rfc4843-bis-05 Donald Eastlake 2014-06-11 draft-ietf-hip-rfc5201-bis-14 Shawn Emery 2014-06-11 draft-ietf-hip-rfc5202-bis-05 Dorothy Gellert 2014-06-10 draft-ietf-mmusic-udptl-dtls-07 Tobias Gondrom 2014-06-11 draft-ietf-p2psip-self-tuning-11 Phillip Hallam-Baker 2014-06-10 draft-ietf-v6ops-clatip-02 Steve Hanna 2014-06-09 draft-ietf-v6ops-enterprise-incremental-ipv6-05 Sam Hartman 2014-04-08 draft-ietf-l2vpn-vpls-ldp-mac-opt-11 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-06 Julien Laganier E 2013-11-21 draft-ietf-websec-key-pinning-13 Julien Laganier 2014-04-29 draft-ietf-dhc-dhcpv4-over-dhcpv6-08 Russ Mundy 2014-03-24 draft-mahalingam-dutt-dcops-vxlan-09 Sandy Murphy 2013-12-17 draft-ietf-netmod-iana-timezones-03 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Melinda Shore 2014-05-26 draft-ietf-dnsop-delegation-trust-maintainance-13 Ondrej Sury 2014-05-28 draft-ietf-ipfix-text-adt-05 David Waltermire 2014-06-10 draft-salgueiro-dispatch-websocket-sipclf-01 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-11 -- kivinen@iki.fi From nobody Fri May 30 06:21:03 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61C61A6FEF for ; Thu, 29 May 2014 09:18:42 -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, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jViOlZ3xxNm for ; Thu, 29 May 2014 09:18:40 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACDB11A6FFE for ; Thu, 29 May 2014 09:18:26 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id l18so653621wgh.11 for ; Thu, 29 May 2014 09:18:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EQTQDF80WH9jdOAQlAStAFQn2mvoHVyqz9kQTyZ5LFM=; b=TV0nff7CXC7fL91241dZaImpM7vYh4rYqfC9bdGdQNAIuAPJ9AqQaQvCV9Pn1/ftj8 P/n5gT4w5eibELZYsIN4epP8hPbdTpb7rV8aj0vQEiBiYeGpGKZsdbbcTbLCVZM6hNnh Ag/SBvVSDacWKOvI4fIXsoYfAS2/vUrmNfJxN2X7ZJo25JD5qE51NkhLbuwhngA1d9a2 R6UlxpNVWgQj+9H8qwAml5Q7U5UgQjXVbMXmheS20RIrSIbVcvWYo0bI0qZw1HjrU2WN 8RK5ShL6j2Urm8WRq1nsXgdZGs0lmN9SfqnE/5wcQctVwkHgzKeyJiZ7UZPyHotJdgLd VhRg== X-Gm-Message-State: ALoCoQm+jaHjrrMTtnPa/S3OmknV1OgK6Zfn0r8/FYhDHVxrOrhJI7WGJDdk2baL8ZgAdUBIk/CE X-Received: by 10.194.189.116 with SMTP id gh20mr12047974wjc.41.1401380301799; Thu, 29 May 2014 09:18:21 -0700 (PDT) Received: from camionet.local (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id s3sm2809456wje.36.2014.05.29.09.18.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 09:18:20 -0700 (PDT) Message-ID: <53875DAA.7040300@jitsi.org> Date: Thu, 29 May 2014 18:17:46 +0200 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Takeshi Takahashi , iesg@ietf.org, secdir@ietf.org, mmusic-chairs@tools.ietf.org, draft-ietf-mmusic-latching@tools.ietf.org References: <000001cf759b$d1250a40$736f1ec0$@nict.go.jp> In-Reply-To: <000001cf759b$d1250a40$736f1ec0$@nict.go.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/rUBDe_YNQCJp31BgA_UGqydYbcM X-Mailman-Approved-At: Fri, 30 May 2014 06:20:59 -0700 Subject: Re: [secdir] Secdir review of draft-ietf-mmusic-latching-05.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 16:18:42 -0000 Hey Takeshi, Thank you for your review. Comments inline: On 22.05.14, 10:57, Takeshi Takahashi 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. > > This document describes the behavior of signaling intermediaries in RTC > deployments when performing hosted NAT traversal (HNT). > The document begins with summarizing the problems with NAT traversal for > protocols such as SIP, and then outlines HNT and the latching mechanism that > approach the problems. > Nevertheless, this document is not recommending the use of latching. > Instead, the document alerts its use and elaborates its security concerns in > Section 5 "Security considerations" by showing several examples. > The security consideration covers issues such as DoS-resistance/resource > exhaustion, impersonation and addresses the use of encryption mechanism. > > It is an interesting, tutorial-like document, and I think this document is > ready. > > According to the mmusic mailing list, the security consideration section has > been discussed from the early stage of this draft, so the section also seems > to be mature, IMHO. > A bit of editorial review would be helpful. > > 1. It could be helpful if you could spell out the abbreviations when they > appear at the first time (e.g., UAC, UAS, SIP, SDP, and SBC), not at the > second time. Right. SDP and SIP were indeed transgressing (fixed now) but all of the others seem to be expanded on first use. Or am I missing something? > 2. In section 1: " and described in [RFC3424]" should be "as described in > [RFC3424]"? Fixed. > 3. In section 4: "from from" -> "from" ? Fixed. > The review was based on the document uploaded at > https://datatracker.ietf.org/doc/draft-ietf-mmusic-latching/ . > > By the way, if RTC and SBC are used as the identical terms in this document, > why do we use the term RTC (Real Time Communication) in the document tile > while we use the term SBC in the main body texts? Well, they actually refer to quite different things. RTC, as you point out, refers to real-time communication. SBC on the other hand stands for session border controller (which is a signalling entity used by some RTC services). Did I misunderstand the question, or do you believe the text is somehow misleading? > In any case, it is a very minor comment, and I think the draft is ready to > move forward. > > Take Thanks again, all fixes will be available in the next submission. Emil -- https://jitsi.org From nobody Fri May 30 06:21:04 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB3601A08C9; Fri, 30 May 2014 06:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccEEibYvVLPJ; Fri, 30 May 2014 06:09:45 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9B5A1A0687; Fri, 30 May 2014 06:09:44 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id k48so1980058wev.19 for ; Fri, 30 May 2014 06:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=tQEPbeIjw7xwKrFbTTzb6XDIfJXwDO4z0/TRGvzI+GY=; b=PA2vY89Q56y3BJOtofjMNnYpfmED9V5lHtwMir9XRnKCvgUgRNXQe3d2rKbEEj4WE/ alNJ6dpP9UqFdO0pyC52FjsgAM0tAqBqinWip60dNE40PxUVOW6XKvh3lBzhP/BMFFl8 /rhVPf1oJHpV5TpaKggQYrpE0Em9Tn3lSmtsXWpN7z59X/25xkGUMZcojTk32gSbXOqJ QaOuXQXUKnOyLTtqittLHxLh28m0DIucYL8OjU7zWxzFtvnNqb5gUQQEliMSDF/Cxahm 6PDnxhaip6ExNEkRYYmHvrAlZiSpjn0+vdIdKqgzlHsjA8vWNC9NvRvdiZIVfWiw5g0S HLOw== MIME-Version: 1.0 X-Received: by 10.180.13.139 with SMTP id h11mr6688978wic.34.1401455378898; Fri, 30 May 2014 06:09:38 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.79.136 with HTTP; Fri, 30 May 2014 06:09:38 -0700 (PDT) Date: Fri, 30 May 2014 09:09:38 -0400 X-Google-Sender-Auth: zbHfaWP_ZqUnE-6qox3JiNujUe0 Message-ID: From: Phillip Hallam-Baker To: draft-ietf-v6ops-clatip.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/474dv3VNBIJIDnUyhJ0f5JY7vqY X-Mailman-Approved-At: Fri, 30 May 2014 06:20:59 -0700 Subject: [secdir] SECDIR Review of http://tools.ietf.org/html/draft-ietf-v6ops-clatip-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 13:09:46 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document is simply an assignment request for a reserved IP address block for a scheme described in [RFC6333] and [RFC6877]. The block previously assigned to DSLite is now assigned to related, non-competing functions. The document would be rather easier to make sense of if the start and the end of the address range had been given. 192.0.0.0/29 is 192.0.0.0...192.0.0.7 This does not matter much because RFC6333 actually assigns specific addresses for specific functions within this range. Exhaustion is not really an issue since in extremis the response could be more tunnels. From nobody Fri May 30 08:42:22 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA281A08E6; Fri, 30 May 2014 08:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.849 X-Spam-Level: X-Spam-Status: No, score=-0.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G_urD9KICyCO; Fri, 30 May 2014 08:42:14 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7911A0411; Fri, 30 May 2014 08:42:14 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.140.99]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s4UFfnxL022067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 May 2014 08:41:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1401464522; bh=2uI+tJos8R1fQ5sQCJvDl1cZUmjnU4XJN0i4eeugTmk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=eHlMsxKM1huUdCPZtGT2gHAHovKyh4JlO7PVnDa7KGPw2K8hKVhk8JvYfFnlFeR/Q p8s4ziUkBZ+Zs44lG1IkqL9raOKskzNCWZX+lkVBYi4Ip5iKz6R5+eP6qb3qIVAjxW A+UUVOD55sWV/v8jCNZy3SP1mRHced8AyCJugao0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1401464522; i=@elandsys.com; bh=2uI+tJos8R1fQ5sQCJvDl1cZUmjnU4XJN0i4eeugTmk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=3A5H2XPhHw4JLXCGNDRJQgNRf6GV4ukHNhLxLnJWqmykdL7f4cAAKVo70yZsp7l9j u3BDI7q6eM1AbUgqIU6MSn2ObJmwbznXx3RuPOx2lVOhJxYUWr+FoHJz6/RxbbULqm omkMSgsjtu5ir6zjhq3yu8SaSYrj4JUB6RRLt450= Message-Id: <6.2.5.6.2.20140530040300.0bb93070@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 30 May 2014 04:43:56 -0700 To: "Joseph Salowey (jsalowey)" , iesg@ietf.org, secdir@ietf.org, draft-moonesamy-sshfp-ed25519.all@tools.ietf.org From: S Moonesamy In-Reply-To: <2ACBFFE4-BCEB-4F6D-A2D3-861BADF543DE@cisco.com> References: <2ACBFFE4-BCEB-4F6D-A2D3-861BADF543DE@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/wNbvjbt1EyMoSJCLzhfX0hJlLXk Cc: ietf@ietf.org Subject: Re: [secdir] secdir review of draft-moonesamy-sshfp-ed25519-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 15:42:16 -0000 Hi Joe, Thanks for the review. I'll comment below. At 21:35 26-05-2014, Joseph Salowey (jsalowey) wrote: >This document defines an SSHFP DNS record for ED25519 signature >algorithm. The document is ready with issues: > >1) This document describes how to store the fingerprint of a public >key that can be used with the ed25519 signature algorithm. I do not >see any reference as to how to use the ed25519 signature algorithm >in SSH. Perhaps I am missing a reference somewhere, but it really >seems that the use of the signature algorithm in SSH should be >defined somewhere, preferably in an IETF document. I so not see the >point of publishing the SSHFP record document without some reference >as to how it will be used. OpenSSH used the following reference to implement the ed25519 signature algorithm: Bernstein, D. J., Lange T., Schwabe P., Yang B-Y., High- Speed High-Security Signatures, Journal of Cryptographic Engineering, Vol. 2, September 26, 2011 TeraTerm also implemented that ( http://sourceforge.jp/ticket/browse.php?group_id=1412&tid=33263 ). In my opinion that passes the "running code" test. I'll highlight that the intended status of the document is Informational. The reason was to have documentation about the code point assignment and to determine IETF Consensus for the assignment. The point in publishing the document is to fulfill RFC 4255 requirements. >2) The examples in RFC 6594 include the OpenSSH formatted key that >is decoded and hashed to obtain the resulting fingerprint. It would >be better if the draft followed this aspect of 6594 and included the >key used to generate the fingerprint. Stephen Farrell raised that question during the AD Review (the message was on the ietf-ssh@netbsd.org mailing list). I mentioned that the public key fingerprint used for ED25519 in the SSHFP Resource Record relies on an undocumented OpenSSH public key format and I did not follow the examples in RFC 6594 because of that. Regards, S. Moonesamy From nobody Fri May 30 09:52:16 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8E21A03BE; Fri, 30 May 2014 09:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0A8p_aujBRnd; Fri, 30 May 2014 09:52:08 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E88A1A6F6E; Fri, 30 May 2014 09:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2876; q=dns/txt; s=iport; t=1401468723; x=1402678323; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DhJQ2k6+VHJC0uCWNv/jtRqQWhJZJRm5L2W/TgHV5Qo=; b=FNX5eCtf52R5MbrfR2b2LTGakQSKHcNu24GPLiwc7KkxtzwE9C2VCLOl 9k6PzR/01zS4oQBUc2kw0wttimD4OgBuEUkjH4VwLVCexSSA277qRtLZy PiktTtywrqt2L3i7VdjGxAtHQeZh7CbzsKseNTrenF7S11mBhRdJeH6m2 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAMS2iFOtJV2T/2dsb2JhbAA/GoMHUljCPAGBCRZ0giUBAQEDATo0CwULAgEIGB4QMiUCBA4FiDoIDTbWSheODRIzB4MrgRUEmX6BPpFvgziCLw X-IronPort-AV: E=Sophos;i="4.98,942,1392163200"; d="scan'208";a="329191875" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-2.cisco.com with ESMTP; 30 May 2014 16:52:02 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s4UGq2f2032679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 May 2014 16:52:02 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.239]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Fri, 30 May 2014 11:52:02 -0500 From: "Joseph Salowey (jsalowey)" To: S Moonesamy Thread-Topic: secdir review of draft-moonesamy-sshfp-ed25519-01 Thread-Index: AQHPeWUfo5K1BZN1JUqd29NR7Q9teZtZWecAgABWFIA= Date: Fri, 30 May 2014 16:52:01 +0000 Message-ID: References: <2ACBFFE4-BCEB-4F6D-A2D3-861BADF543DE@cisco.com> <6.2.5.6.2.20140530040300.0bb93070@elandnews.com> In-Reply-To: <6.2.5.6.2.20140530040300.0bb93070@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <4C183028FF95A242A1F0B85BBBDBDC07@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/K41JXL8Zs5rtjzLmON6CIMd2VrM Cc: "ietf@ietf.org" , "draft-moonesamy-sshfp-ed25519.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-moonesamy-sshfp-ed25519-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 16:52:10 -0000 On May 30, 2014, at 4:43 AM, S Moonesamy wrote: > Hi Joe, >=20 > Thanks for the review. I'll comment below. >=20 > At 21:35 26-05-2014, Joseph Salowey (jsalowey) wrote: >> This document defines an SSHFP DNS record for ED25519 signature algorith= m. The document is ready with issues: >>=20 >> 1) This document describes how to store the fingerprint of a public key= that can be used with the ed25519 signature algorithm. I do not see any r= eference as to how to use the ed25519 signature algorithm in SSH. Perhaps = I am missing a reference somewhere, but it really seems that the use of the= signature algorithm in SSH should be defined somewhere, preferably in an I= ETF document. I so not see the point of publishing the SSHFP record docume= nt without some reference as to how it will be used. >=20 > OpenSSH used the following reference to implement the ed25519 signature a= lgorithm: >=20 > Bernstein, D. J., Lange T., Schwabe P., Yang B-Y., High- > Speed High-Security Signatures, Journal of Cryptographic > Engineering, Vol. 2, September 26, 2011 >=20 > TeraTerm also implemented that ( http://sourceforge.jp/ticket/browse.php?= group_id=3D1412&tid=3D33263 ). In my opinion that passes the "running code= " test. I'll highlight that the intended status of the document is Informa= tional. The reason was to have documentation about the code point assignme= nt and to determine IETF Consensus for the assignment. The point in publis= hing the document is to fulfill RFC 4255 requirements. >=20 [Joe] Running code is certainly good, but I don't think the ed25519 paper b= y itself provides enough information to create an interoperable implementat= ion. Without this information I'm not sure its possible to implement the = draft. For example, as you mention below the format for the key is undocum= ented is it well enough understood what the format of the data to be hashed= in the fingerprint is from the draft and its references? It seems the onl= y documentation of the protocol is in the source code. I'm not sure if the= re is a precedent for referencing a source code, but if it is source contro= lled perhaps it is acceptable.=20 >> 2) The examples in RFC 6594 include the OpenSSH formatted key that is d= ecoded and hashed to obtain the resulting fingerprint. It would be better = if the draft followed this aspect of 6594 and included the key used to gene= rate the fingerprint. >=20 > Stephen Farrell raised that question during the AD Review (the message wa= s on the ietf-ssh@netbsd.org mailing list). I mentioned that the public ke= y fingerprint used for ED25519 in the SSHFP Resource Record relies on an un= documented OpenSSH public key format and I did not follow the examples in R= FC 6594 because of that. >=20 > Regards, > S. Moonesamy=20 From nobody Fri May 30 11:16:57 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01EB51A0982; Fri, 30 May 2014 11:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kz0Uti7RqMSx; Fri, 30 May 2014 11:16:31 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 200891A036A; Fri, 30 May 2014 11:16:31 -0700 (PDT) X-AuditID: 1209190f-f790b6d000000c38-2a-5388caf9b37c Received: from mailhub-2.mit.edu ( [18.7.62.30]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 4A.4D.03128.9FAC8835; Fri, 30 May 2014 14:16:25 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-1.mit.edu [18.9.28.12]) by mailhub-2.mit.edu (8.13.8/8.9.2) with ESMTP id s4UIGNLl003370; Fri, 30 May 2014 14:16:24 -0400 Received: from webmail-3.mit.edu (webmail-3.mit.edu [18.9.23.13]) ) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s4UIGK56002108; Fri, 30 May 2014 14:16:20 -0400 Received: from webmail-3.mit.edu (localhost.localdomain [127.0.0.1]) by webmail-3.mit.edu (8.13.8) with ESMTP id s4UIGJuS004578; Fri, 30 May 2014 14:16:19 -0400 Received: (from nobody@localhost) by webmail-3.mit.edu (8.13.8/8.13.8/Submit) id s4UIGIGL004577; Fri, 30 May 2014 14:16:18 -0400 X-Authentication-Warning: webmail-3.mit.edu: nobody set sender to uri@mit.edu using -f Received: from LLPROXY.LL.MIT.EDU (LLPROXY.LL.MIT.EDU [129.55.200.20]) (User authenticated as uri@ATHENA.MIT.EDU) by webmail.mit.edu (Horde MIME library) with HTTP; Fri, 30 May 2014 14:16:18 -0400 Message-ID: <20140530141618.kgnw4u9b4gw80o4s@webmail.mit.edu> X-Priority: 3 (Normal) Date: Fri, 30 May 2014 14:16:18 -0400 From: Uri Blumenthal To: "Joseph Salowey (jsalowey)" References: <2ACBFFE4-BCEB-4F6D-A2D3-861BADF543DE@cisco.com> <6.2.5.6.2.20140530040300.0bb93070@elandnews.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDKsWRmVeSWpSXmKPExsUixG4np/vzVEewwZn5NhYz7/pZzPgzkdni 2cb5LBZdR9eyW3xY+JDF4lX/TVYHNo8pvzeyetx785HJY8mSn0weXy5/ZgtgieKySUnNySxL LdK3S+DK6Nl9ga2gS6Zi9cXjjA2Mp8S6GDk5JARMJC59WMMOYYtJXLi3nq2LkYtDSGAak8S9 X+tZIJzljBI7P5xlgnBWM0osf/+KFcJZxCix7c9CqEwLo8SEdW2MEMPCJDZ232KGSJxilPg5 +T/YFl4BW4mWrivMMBsnrPsFZrMIqEos+r6UCcRmE1CSaG7ewgpiiwBdOPn9SrBBzAJdTBKX 3r1jAUkIC7hLnNg9AWrDYkaJX3NBLuTg4ATacPlMMcQyQYmTM5+A1TMLOEr87W1mAylhFpCW WP6PAyIsL7H97RywG0QFzCUe7N3BOIFRfBaS7llIumchdM9C0r2AkWUVo2xKbpVubmJmTnFq sm5xcmJeXmqRrolebmaJXmpK6SZGUKRySvLvYPx2UOkQowAHoxIPr8OMjmAh1sSy4srcQ4yS HExKorziJ4BCfEn5KZUZicUZ8UWlOanFhxglOJiVRHifHwHK8aYkVlalFuXDpKQ5WJTEed9a WwULCaQnlqRmp6YWpBbBZGU4OJQkeM+dBGoULEpNT61Iy8wpQUgzcXCCDOcBGj4TpIa3uCAx tzgzHSJ/ilFRSpw3FiQhAJLIKM2D64Ul0leM4kCvCPOuBqniASZhuO5XQIOZgAY/6WwFGVyS iJCSamCUuLeQs8/TZE2xi3iN83KvqZq3VkotW1Tw/8Szv0K3ApZ0aM+99+kUW0V/fp1vZMNz AfGeTs5nu+Tnp0vNYYhxjmU9OHGWbN7Vj82/vPasi/pdOyXnkEVMjfWdpjmWBqVz5saanHhW 9OULu0Pe96+dsc+ef7wlfFZK9sqG5W8sHpdLmJctfsunxFKckWioxVxUnAgAWSwHt38DAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/N6s2JTQqUBy93PsEM8e3nhTvctQ Cc: "iesg@ietf.org" , "secdir@ietf.org" , "draft-moonesamy-sshfp-ed25519.all@tools.ietf.org" , S Moonesamy , "ietf@ietf.org" Subject: Re: [secdir] secdir review of draft-moonesamy-sshfp-ed25519-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 18:16:41 -0000 I personally would not accept source code as the sole specification. IETF tradition has always been providing both the "verbal" description in English (or as close to it as practical) *plus* a reference implementation, preferably more than one. Mere existence of an implementation has never been an excuse to weasel out of actually documenting the protocol. My $0.02. Quoting "Joseph Salowey (jsalowey)" : > On May 30, 2014, at 4:43 AM, S Moonesamy wrote: > >> Hi Joe, >> >> Thanks for the review. I'll comment below. >> >> At 21:35 26-05-2014, Joseph Salowey (jsalowey) wrote: >>> This document defines an SSHFP DNS record for ED25519 signature >>> algorithm. The document is ready with issues: >>> >>> 1) This document describes how to store the fingerprint of a >>> public key that can be used with the ed25519 signature algorithm. >>> I do not see any reference as to how to use the ed25519 signature >>> algorithm in SSH. Perhaps I am missing a reference somewhere, but >>> it really seems that the use of the signature algorithm in SSH >>> should be defined somewhere, preferably in an IETF document. I so >>> not see the point of publishing the SSHFP record document without >>> some reference as to how it will be used. >> >> OpenSSH used the following reference to implement the ed25519 >> signature algorithm: >> >> Bernstein, D. J., Lange T., Schwabe P., Yang B-Y., High- >> Speed High-Security Signatures, Journal of Cryptographic >> Engineering, Vol. 2, September 26, 2011 >> >> TeraTerm also implemented that ( >> http://sourceforge.jp/ticket/browse.php?group_id=1412&tid=33263 ). >> In my opinion that passes the "running code" test. I'll highlight >> that the intended status of the document is Informational. The >> reason was to have documentation about the code point assignment and >> to determine IETF Consensus for the assignment. The point in >> publishing the document is to fulfill RFC 4255 requirements. >> > > [Joe] Running code is certainly good, but I don't think the ed25519 > paper by itself provides enough information to create an > interoperable implementation. Without this information I'm not sure > its possible to implement the draft. For example, as you mention > below the format for the key is undocumented is it well enough > understood what the format of the data to be hashed in the > fingerprint is from the draft and its references? It seems the only > documentation of the protocol is in the source code. I'm not sure if > there is a precedent for referencing a source code, but if it is > source controlled perhaps it is acceptable. > >>> 2) The examples in RFC 6594 include the OpenSSH formatted key that >>> is decoded and hashed to obtain the resulting fingerprint. It >>> would be better if the draft followed this aspect of 6594 and >>> included the key used to generate the fingerprint. >> >> Stephen Farrell raised that question during the AD Review (the >> message was on the ietf-ssh@netbsd.org mailing list). I mentioned >> that the public key fingerprint used for ED25519 in the SSHFP >> Resource Record relies on an undocumented OpenSSH public key format >> and I did not follow the examples in RFC 6594 because of that. >> >> Regards, >> S. Moonesamy > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > From nobody Fri May 30 12:04:29 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9901A0527; Fri, 30 May 2014 12:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0y_awhjKtpWq; Fri, 30 May 2014 12:04:20 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 574051A01B5; Fri, 30 May 2014 12:04:20 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.140.99]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s4UJ3sN2028788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 May 2014 12:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1401476647; bh=GX3wHqne2sz+PSAdaKDryItfsfWDa+OgwB5pxInOFqM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=lieCCRn38bWXEyutmZvfqQpp0voyFIispuyGO1CEi0ksrc/ib0jPLpPyrVVzFbN3Q zdIE/MXm9gdoeXQe9dbE4KO4dGfGv/OANAdu5hwuObcTfP5JsRZg5WNTdGdwLwpE15 laHwLQjnNvpBC7EX4gfLHNI9MxRLqPMrk+IO7gkM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1401476647; i=@elandsys.com; bh=GX3wHqne2sz+PSAdaKDryItfsfWDa+OgwB5pxInOFqM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Sj4Xvrqn7W3zA5c5qhaunBG3nl9/v9Q+NO7xHjje7Px0a32MzhNq/4EIbYfe/cL+5 tBSjKkNIJ8+4peTG3Tm3TXp5TDevYramgjuCBdUMtOPKgY5mkwZIG3B1sRVFthgKc2 8q9QWDQgZptfZ2H8wxziIPKhKl1Ay3WTjvksPw90= Message-Id: <6.2.5.6.2.20140530103304.0c0c8230@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 30 May 2014 11:44:30 -0700 To: "Joseph Salowey (jsalowey)" From: S Moonesamy In-Reply-To: References: <2ACBFFE4-BCEB-4F6D-A2D3-861BADF543DE@cisco.com> <6.2.5.6.2.20140530040300.0bb93070@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/kuVDPFXcgvm0chp7QV57SKX-EiE Cc: ietf@ietf.org, draft-moonesamy-sshfp-ed25519.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-moonesamy-sshfp-ed25519-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 19:04:22 -0000 Hi Joe, At 09:52 30-05-2014, Joseph Salowey (jsalowey) wrote: >[Joe] Running code is certainly good, but I don't think the ed25519 >paper by itself provides enough information to create an >interoperable implementation. Without this information I'm not >sure its possible to implement the draft. For example, as you >mention below the format for the key is undocumented is it well >enough understood what the format of the data to be hashed in the >fingerprint is from the draft and its references? It seems the only >documentation of the protocol is in the source code. I'm not sure >if there is a precedent for referencing a source code, but if it is >source controlled perhaps it is acceptable. According to http://www.openssh.com/ OpenSSH is used by "companies like NetApp, NETFLIX, EMC, Juniper, Cisco, Apple, Red Hat, and Novell; but probably includes almost all router, switch or unix-like operating system vendors". The source code has been under revision control since over 10 years and it is publicly accessible. The source code is distributed under a liberal license. I could have argued for "Proposed Standard". I thought that it was better to go for "Informational" to document what has been implemented as I would have raised arguments similar to the ones quoted above is a review about a "Proposed Standard". There was a comment from Rene Struik during the Last Call about the hash and the ed25519 paper ( http://www.ietf.org/mail-archive/web/ietf/current/msg87894.html ). I think that he understood how it works. The well understood test happens after publication as it depends on the unknown reader. There is a precedent for referencing source code. In my opinion it is better not to do that unless it is really necessary. I prefer not to use the precedent argument. I'll note that this draft does not break anything on the internet. Please let me know whether the above addresses the issues in the review. Regards, S. Moonesamy From nobody Fri May 30 12:04:31 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA9881A0527; Fri, 30 May 2014 12:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V_p7F-MUcM8O; Fri, 30 May 2014 12:04:21 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF301A04A1; Fri, 30 May 2014 12:04:21 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.140.99]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s4UJ3sN4028788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 May 2014 12:04:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1401476653; bh=XiDfTv+NFK0lxZ8atVBxM2B4v4LsDvgYOOslRfKbqGk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=dwEJnWcRpTonlbsXRTn87vKnoQP5IaYYZbdv6IJQznXEhC9f3Wu/YPjFAza/Yya+F VXlzbsiQ0mIDtyQl6q3M8jYp+DqV8SdChJ2p6jl/v+H05YfYzmMeJol+LeupH24qQP xK8arVmFtfveZunXahMSEvI/eNuIuZVd4adlzaug= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1401476653; i=@elandsys.com; bh=XiDfTv+NFK0lxZ8atVBxM2B4v4LsDvgYOOslRfKbqGk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=bCOa7ZD+HxiEIFYtc0JBU11uLQmFlmDR1mkm27WBNEI20Cxet0ZbyVpKD6PcIKn2N hn/BYEu11ejqpij44/kf1PqSZKIvbp1meExe95qBqVp2psbTifHSyqvnmsz+FbwxJY ZwpBl1hk2u2vm+3BG339GCo3f2n/scyBC4NYI9xo= Message-Id: <6.2.5.6.2.20140530114625.0c0d1aa8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 30 May 2014 11:56:58 -0700 To: Uri Blumenthal , "Joseph Salowey (jsalowey)" From: S Moonesamy In-Reply-To: <20140530141618.kgnw4u9b4gw80o4s@webmail.mit.edu> References: <2ACBFFE4-BCEB-4F6D-A2D3-861BADF543DE@cisco.com> <6.2.5.6.2.20140530040300.0bb93070@elandnews.com> <20140530141618.kgnw4u9b4gw80o4s@webmail.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/RqiUY9h9qRQTxA6KtpVwwvupEtI Cc: iesg@ietf.org, secdir@ietf.org, ietf@ietf.org, draft-moonesamy-sshfp-ed25519.all@tools.ietf.org Subject: Re: [secdir] secdir review of draft-moonesamy-sshfp-ed25519-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 19:04:23 -0000 Hi Uri, At 11:16 30-05-2014, Uri Blumenthal wrote: >I personally would not accept source code as the sole specification. IETF >tradition has always been providing both the "verbal" description in English >(or as close to it as practical) *plus* a reference implementation, preferably >more than one. > >Mere existence of an implementation has never been an excuse to weasel out of >actually documenting the protocol. IETF tradition is not to copy SecDir reviews to ietf@ietf.org. I agree that it is good to have a verbal description of a specification in English. It helps to have an implementation. The draft documents a code point assignment; it is not about a protocol. Regards, S. Moonesamy From nobody Fri May 30 13:42:46 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC57E1A87DB; Fri, 30 May 2014 13:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0odhsYbylP1a; Fri, 30 May 2014 13:42:38 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E23C1A87CD; Fri, 30 May 2014 13:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1181; q=dns/txt; s=iport; t=1401482554; x=1402692154; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Yf8v+UpTlci5V24Y1wYJjFvst+b+jOVUrQVGMp4c6Ak=; b=PFrDDC1/qzog755jXUuAM3f4YZ3eU7Z+T4qukrbmtt7pH5jbQn9mxKLf UMhycjCobtAJEdUOrqNMo1tdh3Yn9etwAfzt3p3VB28MPDeP9+KWru/pS 300cnf3CsMTf+vb8D51WujWEMKRp7Cdp05uG4mTZ8scO7u1hlRUMTlJV2 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAOTsiFOtJA2J/2dsb2JhbABZgweBKsI8AYEMFnSCJQEBAQMBOj8FCwIBCBgeEDIlAgQOBYg6CNcwF44fMweDK4EVAQOZfpMtgziCLw X-IronPort-AV: E=Sophos;i="4.98,943,1392163200"; d="scan'208";a="329289981" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-8.cisco.com with ESMTP; 30 May 2014 20:42:32 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s4UKgWmF021533 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 May 2014 20:42:32 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.239]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Fri, 30 May 2014 15:42:32 -0500 From: "Joseph Salowey (jsalowey)" To: S Moonesamy Thread-Topic: [secdir] secdir review of draft-moonesamy-sshfp-ed25519-01 Thread-Index: AQHPeWUfo5K1BZN1JUqd29NR7Q9teZtZWecAgABWFICAABeMAIAAC10AgAAdfoA= Date: Fri, 30 May 2014 20:42:31 +0000 Message-ID: <868A3427-6B46-4110-8D4B-45857D260C1D@cisco.com> References: <2ACBFFE4-BCEB-4F6D-A2D3-861BADF543DE@cisco.com> <6.2.5.6.2.20140530040300.0bb93070@elandnews.com> <20140530141618.kgnw4u9b4gw80o4s@webmail.mit.edu> <6.2.5.6.2.20140530114625.0c0d1aa8@elandnews.com> In-Reply-To: <6.2.5.6.2.20140530114625.0c0d1aa8@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.34] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/gskPusrx2dB8pLX9nsucEe2Wxuc Cc: "iesg@ietf.org" , "secdir@ietf.org" , "ietf@ietf.org" , "draft-moonesamy-sshfp-ed25519.all@tools.ietf.org" Subject: Re: [secdir] secdir review of draft-moonesamy-sshfp-ed25519-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 20:42:40 -0000 On May 30, 2014, at 11:56 AM, S Moonesamy wrote: > Hi Uri, > At 11:16 30-05-2014, Uri Blumenthal wrote: >> I personally would not accept source code as the sole specification. IET= F >> tradition has always been providing both the "verbal" description in Eng= lish >> (or as close to it as practical) *plus* a reference implementation, pref= erably >> more than one. >>=20 >> Mere existence of an implementation has never been an excuse to weasel o= ut of >> actually documenting the protocol. >=20 > IETF tradition is not to copy SecDir reviews to ietf@ietf.org. I agree t= hat it is good to have a verbal description of a specification in English. = It helps to have an implementation. >=20 > The draft documents a code point assignment; it is not about a protocol. >=20 [Joe] My concern is that there is not enough information in the draft to kn= ow what goes into the hash that is the subject of the code point assignment= . Perhaps it is obvious to someone who implemented the SSH code that is no= t documented in this draft, but it is not obvious to me as a reader of the = draft.=20 > Regards, > S. Moonesamy=20 From nobody Fri May 30 15:23:00 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B63E1A0379; Fri, 30 May 2014 15:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxMTeBLwgRAp; Fri, 30 May 2014 15:22:55 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 31DC81A0262; Fri, 30 May 2014 15:22:55 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.140.99]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s4UMMUQp006917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 May 2014 15:22:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1401488564; bh=67I5WXe1tL10Tt6T5NYcHikBhPp3AQUX+C0h2ZiObwk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=RG2QmtSZDhtNB89F36oLCWy8fL5F4/l42XS0usa8JB0gNqNfvohX1yTOasayqYjYg gqtFee6SyvJQHvVsgq2N+Q/P0hxBWtCbQjGodJerYUjSZj8XekuqtizIU675A4/MF9 qFnj7xnHnuYx4JSyUwkotoFCIwH88VXYKrLsBKQ8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1401488564; i=@elandsys.com; bh=67I5WXe1tL10Tt6T5NYcHikBhPp3AQUX+C0h2ZiObwk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=2CIiRDw3+sxgdYIhQu30/Ahhu/wZUAxX5BuOCEyW1WZdF60MMbCeszbbg6oP+uZCy Ucndyws2wbx436D6QtvoPFJQ7lor5x55nemLZucHfCqHqfkM0m1g97Q63dErvBXvvA 6AluewFNfRA9qJyswbXfglBbIvb2vVDrgjwM0vdA= Message-Id: <6.2.5.6.2.20140530135131.0c7bdba0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 30 May 2014 15:22:26 -0700 To: "Joseph Salowey (jsalowey)" From: S Moonesamy In-Reply-To: <868A3427-6B46-4110-8D4B-45857D260C1D@cisco.com> References: <2ACBFFE4-BCEB-4F6D-A2D3-861BADF543DE@cisco.com> <6.2.5.6.2.20140530040300.0bb93070@elandnews.com> <20140530141618.kgnw4u9b4gw80o4s@webmail.mit.edu> <6.2.5.6.2.20140530114625.0c0d1aa8@elandnews.com> <868A3427-6B46-4110-8D4B-45857D260C1D@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/8uR1RgfBC9BzT8ydaXFmXk3cBe4 Cc: iesg@ietf.org, secdir@ietf.org, ietf@ietf.org, draft-moonesamy-sshfp-ed25519.all@tools.ietf.org Subject: Re: [secdir] secdir review of draft-moonesamy-sshfp-ed25519-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 22:22:56 -0000 Hi Joe, At 13:42 30-05-2014, Joseph Salowey (jsalowey) wrote: >[Joe] My concern is that there is not enough information in the >draft to know what goes into the hash that is the subject of the >code point assignment. Perhaps it is obvious to someone who >implemented the SSH code that is not documented in this draft, but >it is not obvious to me as a reader of the draft. That's a fair point. I propose adding the following text in Section 2 as a warning to the reader: The format of the ED25519 public key with SHA-256 fingerprint is not documented in an authoritative specification. Regards, S. Moonesamy From nobody Fri May 30 15:44:30 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78B91A0673; Fri, 30 May 2014 15:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dve8PUHKguq3; Fri, 30 May 2014 15:42:39 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 405B81A024B; Fri, 30 May 2014 15:42:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6C173BED7; Fri, 30 May 2014 23:42:33 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yn1gSdwekDXK; Fri, 30 May 2014 23:42:32 +0100 (IST) Received: from [10.87.48.12] (unknown [86.42.20.19]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1FFEBBED6; Fri, 30 May 2014 23:42:32 +0100 (IST) Message-ID: <53890957.3090407@tolerantnetworks.com> Date: Fri, 30 May 2014 23:42:31 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: S Moonesamy , "Joseph Salowey (jsalowey)" References: <2ACBFFE4-BCEB-4F6D-A2D3-861BADF543DE@cisco.com> <6.2.5.6.2.20140530040300.0bb93070@elandnews.com> <20140530141618.kgnw4u9b4gw80o4s@webmail.mit.edu> <6.2.5.6.2.20140530114625.0c0d1aa8@elandnews.com> <868A3427-6B46-4110-8D4B-45857D260C1D@cisco.com> <6.2.5.6.2.20140530135131.0c7bdba0@elandnews.com> In-Reply-To: <6.2.5.6.2.20140530135131.0c7bdba0@elandnews.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/0r-3fEapNkvTxzh8MQPty0k2xEE X-Mailman-Approved-At: Fri, 30 May 2014 15:44:27 -0700 Cc: iesg@ietf.org, secdir@ietf.org, ietf@ietf.org, draft-moonesamy-sshfp-ed25519.all@tools.ietf.org Subject: Re: [secdir] secdir review of draft-moonesamy-sshfp-ed25519-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 22:42:41 -0000 On 30/05/14 23:22, S Moonesamy wrote: > Hi Joe, > At 13:42 30-05-2014, Joseph Salowey (jsalowey) wrote: >> [Joe] My concern is that there is not enough information in the draft >> to know what goes into the hash that is the subject of the code point >> assignment. Perhaps it is obvious to someone who implemented the SSH >> code that is not documented in this draft, but it is not obvious to me >> as a reader of the draft. > > That's a fair point. I propose adding the following text in Section 2 > as a warning to the reader: > > The format of the ED25519 public key with SHA-256 fingerprint is > not documented in an authoritative specification. Why? Why not just look at the code and write down what that does in terms of formatting the input. If >1 implementation interoperates it can't be that hard. S. > > Regards, > S. Moonesamy From nobody Fri May 30 17:20:26 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C5F1A0698; Fri, 30 May 2014 17:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSAugk6NBTDT; Fri, 30 May 2014 17:20:20 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF421A0636; Fri, 30 May 2014 17:20:20 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.140.99]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s4V0K0hw011597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 May 2014 17:20:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1401495615; bh=yfMEZkZfMGX9B7+E+EcvhBAWn1islk9jlTjM+t6IyvM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=SUu4St+5qfqdOeOjWQo4dePIxKWpm71JG9znf+rDmQSMtVNFPUbf8l6d2+AazmrIT DZt+minARJGyf6XEhFGCC3FXwMHxxD+nwjCJNoYX8VgX1XtOtR846v9cDjig6vguZK Zp7O2ilJyF41WUbLTo3u8BYTMPVk8BphDv34+p+A= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1401495615; i=@elandsys.com; bh=yfMEZkZfMGX9B7+E+EcvhBAWn1islk9jlTjM+t6IyvM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=tqu4iwf9kbPppu+YK7yL0wTYvTGXM6rupvH9cM76DCVuFzj7ljIA8DiDUH7ZSqFqE PYIj3IYIHpqoDmjGVaIdujM6ljYQ4mMLmP4If+0/08Wu9ButfrWuQ3MmI93EmL/vLu 5UFly27t5zUHBYpl6zN45yt4f8uHD3MgEVL75NdE= Message-Id: <6.2.5.6.2.20140530154830.0c7a8d38@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 30 May 2014 17:18:37 -0700 To: Stephen Farrell , "Joseph Salowey (jsalowey)" From: S Moonesamy In-Reply-To: <53890957.3090407@tolerantnetworks.com> References: <2ACBFFE4-BCEB-4F6D-A2D3-861BADF543DE@cisco.com> <6.2.5.6.2.20140530040300.0bb93070@elandnews.com> <20140530141618.kgnw4u9b4gw80o4s@webmail.mit.edu> <6.2.5.6.2.20140530114625.0c0d1aa8@elandnews.com> <868A3427-6B46-4110-8D4B-45857D260C1D@cisco.com> <6.2.5.6.2.20140530135131.0c7bdba0@elandnews.com> <53890957.3090407@tolerantnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/vebou61MiaglW4A1gTifZ6Lo07Q Cc: iesg@ietf.org, secdir@ietf.org, ietf@ietf.org, draft-moonesamy-sshfp-ed25519.all@tools.ietf.org Subject: Re: [secdir] secdir review of draft-moonesamy-sshfp-ed25519-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 00:20:22 -0000 Hi Stephen, At 15:42 30-05-2014, Stephen Farrell wrote: >Why? Why not just look at the code and write down what that does >in terms of formatting the input. > >If >1 implementation interoperates it can't be that hard. I had some private discussions about what the source code does to see how to turn that into a specification. The conclusion was that it would be non-trivial to write down something acceptable to the IETF. If it was not that hard everybody would be able to do it. :-) Regards, S. Moonesamy From nobody Sat May 31 00:07:20 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 021ED1A006C; Sat, 31 May 2014 00:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToENlb4w0Zcg; Sat, 31 May 2014 00:07:10 -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 DB4691A0421; Sat, 31 May 2014 00:07:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHQ08109; Sat, 31 May 2014 07:07:04 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 31 May 2014 08:06:27 +0100 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 31 May 2014 08:07:03 +0100 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.167]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Sat, 31 May 2014 15:06:57 +0800 From: "Zhangdacheng (Dacheng)" To: "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-idr-bgp-enhanced-route-refresh.all@tools.ietf.org" Thread-Topic: SECDIR Review of draft-ietf-idr-bgp-enhanced-route-refresh-06 Thread-Index: AQHPfJ7p3QZODynSR0imiS0zqxqnMw== Date: Sat, 31 May 2014 07:06:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/xEOmvmkKxfeqFhZzLKJoxGnDtrk Subject: [secdir] SECDIR Review of draft-ietf-idr-bgp-enhanced-route-refresh-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 07:07:12 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These 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 short document tries to enhance the existing BGP route refresh mechani= sms to provide for the demarcation of the beginning and the ending of a rou= te refresh. In order to achieve this, the "Reserved" field of the ROUTE-REF= RESH message is redefined to indicate the beginning and the ending of a rou= te refresh. I agree this extension will not introduce new security issues t= o the BGP protocol. The document is clear. I consider it ready with a few issues: I suggest defining how a BGP speaker should handle a EoRR without receiving= the associated BoRR especially when the peer does not support graceful sta= rt.=20 The description in the last paragraph of section 4 is not very clear. It wo= uld be better to briefly explain why the introduced procedures can simplify= the interaction with the BGP Graceful Restart. In addition, the EOR and Eo= R messages (the typos of EoRR?) mentioned in this paragraph are not defined= elsewhere.=20 Cheers Dacheng From nobody Sat May 31 05:46:37 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A640D1A08A9; Sat, 31 May 2014 05:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.651 X-Spam-Level: X-Spam-Status: No, score=-102.651 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbGYJ_bf5F6O; Sat, 31 May 2014 05:46:34 -0700 (PDT) Received: from www.gondrom.org (www.gondrom.org [91.250.114.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30FE81A089D; Sat, 31 May 2014 05:46:34 -0700 (PDT) X-No-Relay: not in my network DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=MLlO6FktzCepJ7bsvYlsV/oriw50lusI9TtlEHs9DR/7gqUmaHFTksqcRTDu72MMyCHxMB0lCepWRHQEWd1mir94Mz3xqskwRVpyn3yPQFReDk41sLPymuIsFmDkpsP04eCdmSPUVo9uMU4pvq6xqRF1FsZY57bSlMZvn/B/wLE=; h=X-No-Relay:X-No-Relay:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:X-Forwarded-Message-Id:Content-Type; X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.6] (5ec20a52.skybroadband.com [94.194.10.82]) by www.gondrom.org (Postfix) with ESMTPSA id B3A3715390020; Sat, 31 May 2014 14:46:27 +0200 (CEST) Message-ID: <5389CF23.8020007@gondrom.org> Date: Sat, 31 May 2014 13:46:27 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: draft-ietf-p2psip-self-tuning.all@tools.ietf.org References: <53823E4A.6080106@gondrom.org> In-Reply-To: <53823E4A.6080106@gondrom.org> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <53823E4A.6080106@gondrom.org> Content-Type: multipart/alternative; boundary="------------020701090105030408020801" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/MoMos2kO9oj_AeKQVVmW0qddJsU Cc: iesg@ietf.org, secdir@ietf.org Subject: [secdir] secdir review of draft-ietf-p2psip-self-tuning-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 12:46:36 -0000 This is a multi-part message in MIME format. --------------020701090105030408020801 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 draft is standards track and describes how the default topology plugin of RELOAD can be extended to support self-tuning, that is, to adapt to changing operating conditions such as churn and network size. It extends the mandatory-to-implement chord-reload algorithm by making it self-tuning. The document appears ready for publication. With one note for the IESG: This security review did only consider this specification, but did not verify the scientific data and research that lead to this algorithm. The Security Consideration Section 8 seems appropriate for the draft. It also refers to the security considerations of RFC6940 (RELOAD Base). One personal question to the authors: In section 8 and 6.5, you introduce the concept of "the statistical mechanisms applied in Section 6.5 (i.e., the use of 75th percentiles) to process the shared estimates a peer obtains help ensuring that estimates that are clearly different from..." How did you determine the value of 75th percentile? Is this based on research or experience or derived from some other estimates? Is this choice influenced by number of peers or churn in certain environments. Thank you and best regards. Tobias --------------020701090105030408020801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 draft is standards track and describes how the default topology plugin of RELOAD can be extended to support self-tuning, that is, to adapt to changing operating conditions such as churn and network size. It extends the mandatory-to-implement chord-reload algorithm by making it self-tuning.

The document appears ready for publication.

With one note for the IESG: This security review did only consider this specification, but did not verify the scientific data and research that lead to this algorithm.

The Security Consideration Section 8 seems appropriate for the draft. It also refers to the security considerations of RFC6940 (RELOAD Base). 

One personal question to the authors:
In section 8 and 6.5, you introduce the concept of "the statistical mechanisms applied in Section 6.5 (i.e., the use of 75th percentiles) to process the shared estimates a peer obtains help ensuring that estimates that are clearly different from..."
How did you determine the value of 75th percentile? Is this based on research or experience or derived from some other estimates? Is this choice influenced by number of peers or churn in certain environments.

Thank you and best regards.

Tobias

--------------020701090105030408020801-- From nobody Sat May 31 06:23:55 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43EC1A06CC; Fri, 30 May 2014 18:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwhFBOviXKkW; Fri, 30 May 2014 18:28:41 -0700 (PDT) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A6CD1A043C; Fri, 30 May 2014 18:28:41 -0700 (PDT) Received: by mail-yh0-f45.google.com with SMTP id b6so2240895yha.32 for ; Fri, 30 May 2014 18:28:36 -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-type; bh=aRCb01XuyhkZExgBJkKMWSfwE4yQraAgu8kT+s91Cw4=; b=ls8k9jGdvs8xtoiBx6JIQMqqIQ532VLSEHDUgIjnBTt35sUT8iPkWjua48ywD7i4fV v7ahYTj+UcDavcVTF3TDFxw2XbJTGT0otqVd70v7IOVuH9N+jd61KYwWqmvrjp/kjG0F teVeUknzQGHmhw0hdpp9kJ8iasjjC0ITHwQFEG9vtfFLVjyjysL3akb6Q7PB+lhGSGEo i45T2j9h0QL6zJ5O9HUchKMJMPM0vKuNJv1P6YxV9mXqjlZr3bYHtLhtwHCUhQI22Rwv dGvWDuk0KSksjHmQHwIibae7Ed0X6K9n50yfUEFTmtxV4g5fvYprp0lQBt4Hiz+v6ttc 7RJg== X-Received: by 10.236.124.237 with SMTP id x73mr26051618yhh.137.1401499716550; Fri, 30 May 2014 18:28:36 -0700 (PDT) MIME-Version: 1.0 Sender: rwfranks@gmail.com Received: by 10.170.197.193 with HTTP; Fri, 30 May 2014 18:27:56 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20140530154830.0c7a8d38@elandnews.com> References: <2ACBFFE4-BCEB-4F6D-A2D3-861BADF543DE@cisco.com> <6.2.5.6.2.20140530040300.0bb93070@elandnews.com> <20140530141618.kgnw4u9b4gw80o4s@webmail.mit.edu> <6.2.5.6.2.20140530114625.0c0d1aa8@elandnews.com> <868A3427-6B46-4110-8D4B-45857D260C1D@cisco.com> <6.2.5.6.2.20140530135131.0c7bdba0@elandnews.com> <53890957.3090407@tolerantnetworks.com> <6.2.5.6.2.20140530154830.0c7a8d38@elandnews.com> From: Dick Franks Date: Sat, 31 May 2014 02:27:56 +0100 X-Google-Sender-Auth: d7ZoBlr9G2TZLsTnYn-agqZahDo Message-ID: To: S Moonesamy Content-Type: multipart/alternative; boundary=20cf303a332bc204fa04faa81498 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/lLdi1ALu5MTr-VVxwHbRUbFVbBQ X-Mailman-Approved-At: Sat, 31 May 2014 06:23:53 -0700 Cc: Stephen Farrell , IETF Discussion , secdir@ietf.org, draft-moonesamy-sshfp-ed25519.all@tools.ietf.org, iesg@ietf.org Subject: Re: [secdir] secdir review of draft-moonesamy-sshfp-ed25519-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 01:28:44 -0000 --20cf303a332bc204fa04faa81498 Content-Type: text/plain; charset=UTF-8 On 31 May 2014 01:18, S Moonesamy wrote: > Hi Stephen, > At 15:42 30-05-2014, Stephen Farrell wrote: > >> Why? Why not just look at the code and write down what that does >> in terms of formatting the input. >> >> If >1 implementation interoperates it can't be that hard. >> > > I had some private discussions about what the source code does to see how > to turn that into a specification. The conclusion was that it would be > non-trivial to write down something acceptable to the IETF. If it is non-trivial to extract the data format from the code, it is essential that it be included here or incorporated by reference to a freely available public document. If it was not that hard everybody would be able to do it. :-) :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( --20cf303a332bc204fa04faa81498 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 31 May 2014 01:18, S Moonesamy <sm+ietf@elandsys.com> = wrote:
Hi Stephen,
At 15:42 30-05-2014, Stephen Farrell wrote:
Why? Why not just look at the code and write down what that does
in terms of formatting the input.

If >1 implementation interoperates it can't be that hard.

I had some private discussions about what the source code does to see how t= o turn that into a specification. =C2=A0The conclusion was that it would be= non-trivial to write down something acceptable to the IETF.

If it is non-trivial to extract the data format from the cod= e, it is essential that it be included here or incorporated by reference to= a freely available public document.


=C2=A0If it was not that hard everybody would be able to do it. :-)
=C2=A0
:-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2= =A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(
:-(= =C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2= =A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(
:-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(= =C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2= =A0 :-(
:-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(= =C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(
:-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(= =C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(
:-(=C2=A0 :-(=C2=A0 :-(=C2=A0 := -(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2= =A0 :-(
:-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(= =C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(
:-(=C2=A0 :-(=C2=A0 := -(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2= =A0 :-(=C2=A0 :-(
:-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(= =C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(
:-(=C2=A0 :-(=C2=A0 :-(=C2=A0 := -(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2= =A0 :-(
:-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(= =C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(
:-(=C2=A0 :-(=C2=A0 := -(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2=A0 :-(=C2= =A0 :-(=C2=A0 :-(



--20cf303a332bc204fa04faa81498-- From nobody Sat May 31 19:53:25 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D191A015B; Sat, 31 May 2014 19:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VCa9u0YMiyL; Sat, 31 May 2014 19:53:20 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id BEB5A1A010E; Sat, 31 May 2014 19:53:19 -0700 (PDT) X-AuditID: 12074422-f79376d000000c58-8a-538a959ac300 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 36.89.03160.A959A835; Sat, 31 May 2014 22:53:14 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s512rB6s024431; Sat, 31 May 2014 22:53:11 -0400 Received: from [192.168.1.107] (chostler.hsd1.ma.comcast.net [24.62.227.134]) (authenticated bits=0) (User authenticated as uri@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s512r6Ox009593 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 31 May 2014 22:53:09 -0400 References: <2ACBFFE4-BCEB-4F6D-A2D3-861BADF543DE@cisco.com> <6.2.5.6.2.20140530040300.0bb93070@elandnews.com> <20140530141618.kgnw4u9b4gw80o4s@webmail.mit.edu> <6.2.5.6.2.20140530114625.0c0d1aa8@elandnews.com> <868A3427-6B46-4110-8D4B-45857D260C1D@cisco.com> <6.2.5.6.2.20140530135131.0c7bdba0@elandnews.com> <53890957.3090407@tolerantnetworks.com> Mime-Version: 1.0 (1.0) In-Reply-To: <53890957.3090407@tolerantnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <129646BF-9249-4AE7-AEA8-D43A2E3BD4E3@mit.edu> X-Mailer: iPad Mail (11D201) From: Uri Blumenthal Date: Sat, 31 May 2014 22:53:06 -0400 To: Stephen Farrell X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBKsWRmVeSWpSXmKPExsUixCmqrDtralewwdGZ8hYz7/pZzPgzkdni 2cb5LBZdR9eyW3xY+JDF4lX/TVaL7klTmB3YPab83sjqce/NRyaPJUt+Mnlsa29k9fhy+TNb AGsUl01Kak5mWWqRvl0CV8blszuZCz5zVHTcXcXYwNjM3sXIySEhYCKx4t5PNghbTOLCvfVA NheHkMBsJomvTy+xQzgbGSU2vtzNBOHsY5JombudFcLpY5bo3NHA0sXIwcErIC5x9aAPyChO oLHbp99gAwkzC+hITF7ICBJmFtCWWLbwNTNEtZVE+3kTkCnMAqeYJJ7O3Qc2RUJARuLJZ2WQ cjYBJYnm5i2sILawgLvEid0TmEFsFgFVie/bX4PFRQSMJL72vmSfwCg4C+GGWQh7ZyHZu4CR eRWjbEpulW5uYmZOcWqybnFyYl5eapGuqV5uZoleakrpJkZQJLC7KO1g/HlQ6RCjAAejEg+v gl1XsBBrYllxZe4hRkkOJiVR3ux+oBBfUn5KZUZicUZ8UWlOavEhRgkOZiURXr4ioBxvSmJl VWpRPkxKmoNFSZz3rbVVsJBAemJJanZqakFqEUxWhoNDSYJ34RSgRsGi1PTUirTMnBKENBMH J8hwHqDhPSA1vMUFibnFmekQ+VOMuhzn5pxqYxJiycvPS5US5709GahIAKQoozQPbg4sgb1i FAd6S5h3FsgoHmDyg5v0CmgJE9CSt1WdIEtKEhFSUg2Mtpx7mSPj70+aNnt7XMemf3zRnzmv eKu27z4iwbvlk6jC1+BdZz/cDLQvYDXIkTTk7u1RfGcn7iL2XPnwZff2i0zq1ZH2R0vjY9Zb 6El8FMl/e3di2cqSxCmiFrZ6917aXvhfHFPp8Oaar/N5JUvr5MWLVtwT8us2P3jgrJ5/Y2/c tn82yWpKLMUZiYZazEXFiQCZCc9DOwMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/VCWGcw8Z2nuU1q_DwZ60ctlWbvA Cc: "ietf@ietf.org" , "secdir@ietf.org" , "draft-moonesamy-sshfp-ed25519.all@tools.ietf.org" , S Moonesamy , "iesg@ietf.org" Subject: Re: [secdir] secdir review of draft-moonesamy-sshfp-ed25519-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 02:53:21 -0000 I reject S. Moonesamy's proposal, and strongly support Stephen's recommendat= ion. Sent from my iPad > On May 30, 2014, at 18:42, Stephen Farrell w= rote: >=20 >=20 >=20 >> On 30/05/14 23:22, S Moonesamy wrote: >> Hi Joe, >> At 13:42 30-05-2014, Joseph Salowey (jsalowey) wrote: >>> [Joe] My concern is that there is not enough information in the draft >>> to know what goes into the hash that is the subject of the code point >>> assignment. Perhaps it is obvious to someone who implemented the SSH >>> code that is not documented in this draft, but it is not obvious to me >>> as a reader of the draft. >>=20 >> That's a fair point. I propose adding the following text in Section 2 >> as a warning to the reader: >>=20 >> The format of the ED25519 public key with SHA-256 fingerprint is >> not documented in an authoritative specification. >=20 > Why? Why not just look at the code and write down what that does > in terms of formatting the input. >=20 > If >1 implementation interoperates it can't be that hard. >=20 > S. >=20 >>=20 >> Regards, >> S. Moonesamy=20