From hallam@gmail.com Wed Mar 2 05:12:02 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5665B3A67D8; Wed, 2 Mar 2011 05:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.57 X-Spam-Level: X-Spam-Status: No, score=-3.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFCigS7VM7MK; Wed, 2 Mar 2011 05:12:01 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id CB2023A67EB; Wed, 2 Mar 2011 05:12:00 -0800 (PST) Received: by bwz13 with SMTP id 13so153494bwz.31 for ; Wed, 02 Mar 2011 05:13:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fsqzI//j1KcpmiAISen/GQm0UQLW4T+nKxq/ENyihAA=; b=qhyegXCJMstEsQXeEGDcTA1gWCFqVQ5n42gJ5cOxA6wHDIyvA+YhJiqI5ht19fqWzu pjJys34B8iRu+Cj0+iaPEJLR1mJIC5lzBqep2+02v/FTUo+I90MUnFmiOlsTVJG/K3xi 811qTfi5D3erch/rASnOCnxWWC5Wk3FbCPsT8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WZwGYjg32R55f/ARc4tY8bINwXts03XFstV5F5N6iN04O+LwenHeoHQRwVDYvEjBnN OSAnrC9UaHpxBz0of7IPToXtJhnsNMYDnSb/y6P+mzNsXVx0qW7aWhcbYA8ZNEn0+8kp MXrN5zltIARaBIO4YLlv6fIX/WLrAG5nY2RIM= MIME-Version: 1.0 Received: by 10.204.100.82 with SMTP id x18mr7269654bkn.20.1299071585793; Wed, 02 Mar 2011 05:13:05 -0800 (PST) Received: by 10.204.14.139 with HTTP; Wed, 2 Mar 2011 05:13:05 -0800 (PST) In-Reply-To: References: Date: Wed, 2 Mar 2011 08:13:05 -0500 Message-ID: From: Phillip Hallam-Baker To: Samuel Weiler Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alexey.Melnikov@isode.com, Barry Leiba , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR Review of draft-ietf-morg-multimailbox-search-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 13:12:02 -0000 On Sat, Feb 26, 2011 at 6:43 AM, Samuel Weiler wrote: > On Tue, 22 Feb 2011, Phillip Hallam-Baker wrote: > >> This document makes a minor adjustment to the search mechanism of imap, >> allowing searches to be made slightly more efficiently. > > > If the user specifies some mailbox(es) which she doesn't have access righ= ts > to AND some mailbox(es) which she can access, the doc says to IGNORE the > ones she can't access. =A0Wouldn't it be more useful to send an error for > those mailboxes rather than silently fail? I don't see any value there. If the user is not permitted access to a mailbox, they don't get the information. There might be value sending the notice to an exception log, but it does not make much sense to send it to the user's client. If the user is trying to maliciously access material they should not, what would be the value in telling them? The use case that would likely arise for this would be where there are shared folders (e.g. mailing lists) in some sort of hierarchy. --=20 Website: http://hallambaker.com/ From sra@hactrn.net Wed Mar 2 09:32:21 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EEE63A67B6; Wed, 2 Mar 2011 09:32:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOzN2EiOwmQY; Wed, 2 Mar 2011 09:32:20 -0800 (PST) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 1D2D93A6844; Wed, 2 Mar 2011 09:32:20 -0800 (PST) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id D79992844C; Wed, 2 Mar 2011 17:33:23 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 8849622829; Wed, 2 Mar 2011 12:33:23 -0500 (EST) Date: Wed, 02 Mar 2011 12:33:23 -0500 From: Rob Austein To: iesg@ietf.org, secdir@ietf.org, draft-ietf-netconf-rfc4742bis.all@tools.ietf.org MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20110302173323.8849622829@thrintun.hactrn.net> Subject: [secdir] Review of draft-ietf-netconf-rfc4742bis-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 17:32:21 -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 draft is an updated specification for transport of NETCONF message streams over SSH connections using the SSHv2 "subsystem" protocol. These message streams are bi-directional channels conveying multiple complete XML documents in each direction. The main change from RFC 4742 to this draft is a revision to the framing protocol. The original framing protocol in RFC 4742 used a magic delimiter string "]]>]]>" in the mistaken belief that such a string could never appear in a well-formed XML document. The current document defines a new counted-length framing protocol, but preserves vestiges of the old framing protocol for backwards compatibility and requires use of the old protocol during the initial capability exchange. I have no serious security concerns regarding this document, but I do have two comments: 1) If it's worth changing the framing protocol at all, which I'm willing to accept as a given, it is far from obvious to me that the current negotiated upgrade is the right way to do it, as this will require implementation of the old bad mechanism forever. Switching to a new SSH subsystem name seems like a much simpler solution. 2) As a matter of stylistic consistency with the last several decades of Internet protocols, the delimiter sequence in the new framing protocol should have been , not . Sigh. From bew@cisco.com Wed Mar 2 22:38:22 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D4C73A6924; Wed, 2 Mar 2011 22:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xVHoQvRPnAc; Wed, 2 Mar 2011 22:38:21 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 6DC053A6892; Wed, 2 Mar 2011 22:38:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=1909; q=dns/txt; s=iport; t=1299134369; x=1300343969; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=pkh2aZybHj2/guHm6i26gceFrISMPr9b2SydaXbfSw8=; b=Azf7mLuhdtp4dLOaPufhyo6vTSylunHd2Jto9gMw3VL2syasXTU1VTJR gcKyIFWvRrq5f2Tv35CyJ1yxF1C0NI9aWOdE4q7+zrH1H4CvLUef8DlDn fSzkvT7do4+G/EmVmXGJ7Y9S91XViv75xufbJSRXPNdrLWu/tVyE6LwwB Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFLGbk2rR7H+/2dsb2JhbACmdXSiRJt8hWEEhRqHEg X-IronPort-AV: E=Sophos;i="4.62,257,1297036800"; d="scan'208";a="268599513" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 03 Mar 2011 06:39:28 +0000 Received: from stealth-10-32-244-211.cisco.com (stealth-10-32-244-211.cisco.com [10.32.244.211]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p236dSDY016733; Thu, 3 Mar 2011 06:39:28 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Mar 2011 22:39:28 -0800 Message-Id: To: secdir@ietf.org, iesg@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Cc: draft-herzog-static-ecdh@tools.ietf.org Subject: [secdir] Secdir review of draft-herzog-static-ecdh-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 06:38:22 -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 defines how two CMS agents use static Diffie-Hellman = values for Elliptic Curve Diffie-Hellman key agreement. It is well = written. I have just a few comments. 1. The Abstract and Introduction use the term "static-static" Elliptic = Curve Diffie-Hellman key-agreement, which is a term not in common use. I = guessed correctly that it meant the case where both participants in the = key agreement were using static DH values, but I think until the term is = define (later on in the Introduction) it would be clearer to say = something like "Elliptic Curve Diffie-Hellman key-agreement where both = participants use static Diffie-Hellman values". 2. Reference [SEC1] is heavily referenced in this document, for both a = definition of ECDH and specific methods for using ECDH. But it would be = good to also mention RFC 6090, which is the best IETF document = describing ECDH. 3. Generally, when two parties use static DH values over different = exchanges they will use the same key for each exchange, which is = generally not a good practice. I believe this is true for ECDH as well. = Sections 2.2 and 2.3 mention "SharedInfo", which when used appropriately = will permute the shared key such that the sessions are not keyed = identically. But I believe the use of "SharedInfo" is optional, so I was = expecting the Security Considerations to describe this scenario and at = least say that "SharedInfo" SHOULD be used (or possibly MUST be used). = It would be good to add this discussion to Security Considerations. Brian From kivinen@iki.fi Thu Mar 3 05:05:07 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A7373A69DD; Thu, 3 Mar 2011 05:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmRSCaPMYOlk; Thu, 3 Mar 2011 05:05:05 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 2A4E93A699F; Thu, 3 Mar 2011 05:05:04 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p23D68w4029413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Mar 2011 15:06:08 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p23D67lj010594; Thu, 3 Mar 2011 15:06:08 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19823.37439.966900.314499@fireball.kivinen.iki.fi> Date: Thu, 3 Mar 2011 15:06:07 +0200 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 18 min X-Total-Time: 20 min Cc: draft-ietf-xcon-common-data-model.all@tools.ietf.org Subject: [secdir] Review of draft-ietf-xcon-common-data-model-23.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 13:05:07 -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 contains xml data model description for conference information. As this is data model and does not list any actual protocols to transmit those xml files its security considerations section is quite generic. It does say that database access must be authorized (access control rules) and that integrity of the database MUST be protected against unauthorized modifications. How this is done is left to the actual protocol documents. It does NOT require confidentiality of the database, but instead says: The confidentiality of the database SHOULD be protected from unauthorized users, given that the data model contains a set of sensitive elements (e.g., passwords). I do not agree on that comment. If the data model contains sensitive elements like passwords I think the confidentiality MUST be protected from unauthorized users. If it is possible that the data model does not contain any sensitive elements then I think the SHOULD could be enough. Also it does not specify what data in the data model is sensitive. Also the security considerations section completely fails to address the fact that the database most likely also contain data that has privacy issues. For example the list of users participating the specific conference could be quite big privacy issue (for example some group of human rights people discussing issues about their own goverment). Note, that this also might require some discussion about the lifetime of the data in the database. I.e. when is the list of participants removed from the database and how long it is stored there. In most countries there are specific laws protecting such information, so those might require preventing unauthorized access to the database. Also as there is fields like provide-anonymity in the database which tells which user is mapped to which "anonymous" name for users to see, but if someone gets read access to the database that person can directly map those anonoymous users to their real identities. I think the security consideation sections should include text about the privacy issues, and most likely mandate support for confidentiality of the database, and preventing unauthorized read access to it. -- kivinen@iki.fi From weiler@watson.org Thu Mar 3 05:54:46 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1D533A6884; Thu, 3 Mar 2011 05:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8sfnAFsTQzD; Thu, 3 Mar 2011 05:54:46 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 068513A6866; Thu, 3 Mar 2011 05:54:45 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p23DtnmZ009445; Thu, 3 Mar 2011 08:55:49 -0500 (EST) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p23Dtmc0009442; Thu, 3 Mar 2011 08:55:49 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 3 Mar 2011 08:55:48 -0500 (EST) From: Samuel Weiler To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-1335935227-1299160549=:7972" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 03 Mar 2011 08:55:49 -0500 (EST) Cc: Alexey.Melnikov@isode.com, Barry Leiba , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR Review of draft-ietf-morg-multimailbox-search-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 13:54:46 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --621616949-1335935227-1299160549=:7972 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT >> If the user specifies some mailbox(es) which she doesn't have access rights >> to AND some mailbox(es) which she can access, the doc says to IGNORE the >> ones she can't access.  Wouldn't it be more useful to send an error for >> those mailboxes rather than silently fail? > I don't see any value there. > > If the user is not permitted access to a mailbox, they don't get the > information. There might be value sending the notice to an exception > log, but it does not make much sense to send it to the user's client. > If the user is trying to maliciously access material they should not, > what would be the value in telling them? I'm thinking about this the other way around: if we're dealing with the (perhaps more common) case of misconfiguration rather than malice, this delivers a poor user experience. With a silent failure, the user is likely to be misled into assuming that no messages matched the search. > The use case that would likely arise for this would be where there > are shared folders (e.g. mailing lists) in some sort of hierarchy. Yep. -- Sam --621616949-1335935227-1299160549=:7972-- From barryleiba@gmail.com Thu Mar 3 05:59:06 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 579DD3A6826; Thu, 3 Mar 2011 05:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.165 X-Spam-Level: X-Spam-Status: No, score=-103.165 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xduN9V3orkd3; Thu, 3 Mar 2011 05:59:05 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 3CB0D3A67F9; Thu, 3 Mar 2011 05:59:05 -0800 (PST) Received: by iyj8 with SMTP id 8so1097138iyj.31 for ; Thu, 03 Mar 2011 06:00:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3eeJ2E+12KFjUHOnc/13UKYRUeltXbs6QvNRIRsJ11g=; b=Fsb+D0c0E6pQzn9FXpi8iPKFVutB8Xo7anRnpZxwN3jD0w2tlsD1jdZhU100K15WzG dINMTITwz+IOJSjiDVzFa4NYdpmOI0tF9ynbHYUn5byvLG0hRpykX3U6ZfSHbPJyRRnk wF6Zt3c2Z8vMFJYNmqEvJW7tVGXs82sLwoObU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=eoizjLPGrFbhBltnyPnct/0P+VZaiyyAfLAxj63xs+kA7xmHEDxI65De20pgqu2LR1 F9KyIsz+4VJHT1/AZ5EOxOgr7CcjJRiPwt5ijvfhVIPNr3YqBr3nQP8BzJDnYqISvvbw tXdRlgr8pM7AU8w+GHBStv1lW8xrXNesXcphI= MIME-Version: 1.0 Received: by 10.42.148.7 with SMTP id p7mr1625418icv.94.1299160812669; Thu, 03 Mar 2011 06:00:12 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.231.38.13 with HTTP; Thu, 3 Mar 2011 06:00:12 -0800 (PST) In-Reply-To: References: Date: Thu, 3 Mar 2011 09:00:12 -0500 X-Google-Sender-Auth: H6h3wpj83ML9Lv2P84ozA6xY6vY Message-ID: From: Barry Leiba To: Samuel Weiler Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alexey.Melnikov@isode.com, Phillip Hallam-Baker , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR Review of draft-ietf-morg-multimailbox-search-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 13:59:06 -0000 > I'm thinking about this the other way around: if we're dealing with the > (perhaps more common) case of misconfiguration rather than malice, this > delivers a poor user experience. =A0With a silent failure, the user is li= kely > to be misled into assuming that no messages matched the search. Understood. But as I said in my previous response, it would significantly go against WG consensus to change this, and there are pitfalls in trying to get the change right anyway. Barry From david.black@emc.com Thu Feb 24 14:42:22 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEE313A6867; Thu, 24 Feb 2011 14:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gp74bT20Czq; Thu, 24 Feb 2011 14:42:21 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 7C8303A687B; Thu, 24 Feb 2011 14:42:21 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1OMhBfT006955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Feb 2011 17:43:11 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Thu, 24 Feb 2011 17:43:03 -0500 Received: from mxhub10.corp.emc.com (mxhub10.corp.emc.com [10.254.92.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1OMevUA024863; Thu, 24 Feb 2011 17:40:58 -0500 Received: from mx14a.corp.emc.com ([169.254.1.143]) by mxhub10.corp.emc.com ([10.254.92.105]) with mapi; Thu, 24 Feb 2011 17:40:57 -0500 From: To: , , Date: Thu, 24 Feb 2011 17:40:55 -0500 Thread-Topic: secdir review of draft-ietf-pwe3-fc-encap-14.txt Thread-Index: AcvR2J79mnoqbMWXRHiAcNAfdrQddACmmx3A Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E03E5B1BE7F@MX14A.corp.emc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Thu, 03 Mar 2011 07:34:33 -0800 Cc: david.black@emc.com, draft-ietf-pwe3-fc-encap@tools.ietf.org Subject: Re: [secdir] secdir review of draft-ietf-pwe3-fc-encap-14.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 22:42:22 -0000 Steve, Thanks for reviewing this draft. > At least, the authors should add a reference to a document > that describes the attacks to which this protocol is susceptible > and the countermeasures that can be employed. Sure, I'll start with references to the security considerations sections of= RFC 3985 (PWE3 Architecture) and RFC 4385 (PWE3 Control Word). In additio= n, in thinking about this, I realized that there are aspects of the encapsu= lation that aren't covered by either the PWE3 or FC security material - for= example, an attacker who can inject delay can cause violation of the timin= g requirements in Section 5 sufficient to take down an FC PW link in a fash= ion that it will stay down (countermeasure to that is delay monitoring via = OAM functionality). I'll add at least that. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Stephen Hanna [mailto:shanna@juniper.net] > Sent: Monday, February 21, 2011 10:04 AM > To: secdir@ietf.org; iesg@ietf.org > Cc: draft-ietf-pwe3-fc-encap@tools.ietf.org > Subject: secdir review of draft-ietf-pwe3-fc-encap-14.txt >=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 > This document describes how Fibre Channel traffic can be carried > over MPLS networks using a Fibre Channel pseudowire (FC PW). I am > not an expert in Fibre Channel, MPLS, or pseudowires so I will not > venture any judgment on the content of the draft. I will focus > exclusively on the Security Considerations section. >=20 > The Security Considerations section is rather brief, only five > sentences long. While I support brevity, this section seems to > omit key information. For example, the text says "FC PW shares > susceptibility to a number of pseudowire-layer attacks and > implementations SHOULD use whatever mechanisms for confidentiality, > integrity, and authentication are developed for PWs in general. > These methods are beyond the scope of this document." That's too > brief. At least, the authors should add a reference to a document > that describes the attacks to which this protocol is susceptible > and the countermeasures that can be employed. If no such document > exists, either it should be written or this document should describe > the threats and countermeasures or this document should admit that > the threats and countermeasures are not understood at this time. > You can't just leave the analysis of threats and countermeasures > to the reader. >=20 > Thanks, >=20 > Steve Hanna >=20 From eunah.ietf@gmail.com Mon Feb 28 15:25:54 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 041A23A6CC9; Mon, 28 Feb 2011 15:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7vbuWI1eG2o; Mon, 28 Feb 2011 15:25:53 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id C6B043A6A4C; Mon, 28 Feb 2011 15:25:52 -0800 (PST) Received: by qyk7 with SMTP id 7so3463004qyk.10 for ; Mon, 28 Feb 2011 15:26:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/GSKcTAZdUn7iDPvapsdQxgTpYqkh+DmNWirOePZwC0=; b=Qjo2/C0xdXa66og2v8R+1PsSiFras7RB6oCIeTIZr5EK5eWcHZvDV83RPLyYk40nDb Zp84dItVlZEJHfsvnRi9QWF2cCd0xm1RVGZYur3R79S08uJNpike0MSfNIxyRgr6H+HK pjVDb3k/kjGfi8ML2Ujz7IScwAPo6MH/ZaGDM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=shAOF5ncXdiD5wyRWw+AoR8gVruJL/Bp/sOCg4DK6GXvkt1ExjjAK+2tSPE39A6EfE fEFtcLVyNkmaTBP4KafR542NqfFaBN9AM3aA6TevA0mi4DvYh8DsDqUXs1UPsGn+IQM9 6P7yvNvM6KED0GYq6ZmugNE2tfTAxGCzegq1s= MIME-Version: 1.0 Received: by 10.229.96.206 with SMTP id i14mr4649090qcn.247.1298935613727; Mon, 28 Feb 2011 15:26:53 -0800 (PST) Received: by 10.229.233.85 with HTTP; Mon, 28 Feb 2011 15:26:53 -0800 (PST) In-Reply-To: References: Date: Tue, 1 Mar 2011 00:26:53 +0100 Message-ID: From: "Eunsook \"Eunah\" Kim" To: Donald Eastlake Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 03 Mar 2011 07:34:33 -0800 Cc: draft-ietf-6lowpan-usecases.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-ietf-6lowpan-usecases-09.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 23:25:54 -0000 Dear Donald, Thanks for the valuable comment. I agree with you. It must be good to have such references. I'm now on my biz trip which quite occupies me. I will include your suggestion in the revision within the next week. Thanks, Eunah On Mon, Feb 28, 2011 at 4:43 AM, Donald Eastlake wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. Document editors and WG chairs should treat > these comments just like any other last call comments > > As you might guess from the draft name, this is an informational > document describing a number of use cases for low-power wireless > personal area networks. The security considerations section, > reasonably enough, briefly indicates why different use cases may have > considerably different security requirements and what some types of > such security requirements could be. > > The thing that I think is lacking is some hint as to where to look to > find possible mechanisms to meet those requirements. For this type of > document, no detailed analysis of mechanisms is needed. But I would > feel better if a sentence could be added such as follow (with some > alternative wording in square brackets): "These varied security > requirement [can commonly][are expected to] be met by the use of > mechanisms such as IPsec and IKE, TLS, or 802.15.4 link security.". If > there is an appropriate security mechanism survey document that would > be fine. I did look at RFC 4919 as something that could be referenced > and it seems too preliminary and tentative. RFC 4944 is only a little > better. Perhaps there should be a reference to > draft-qiu-6lowpan-secure-router at least as an example of work in > progress in this area. > > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) > =A0155 Beaver Street > =A0Milford, MA 01757 USA > =A0d3e3e3@gmail.com > From oscar.novo@ericsson.com Thu Mar 3 06:23:09 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE5DA3A67F9; Thu, 3 Mar 2011 06:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NWYx2GwB0Du; Thu, 3 Mar 2011 06:23:08 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 493F23A68AD; Thu, 3 Mar 2011 06:23:07 -0800 (PST) X-AuditID: c1b4fb3d-b7bbbae000005311-21-4d6fa48e64bc Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D9.1B.21265.E84AF6D4; Thu, 3 Mar 2011 15:24:14 +0100 (CET) Received: from ESESSCMS0355.eemea.ericsson.se ([169.254.1.115]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 3 Mar 2011 15:24:12 +0100 From: Oscar Novo To: Tero Kivinen , "iesg@ietf.org" , "secdir@ietf.org" Date: Thu, 3 Mar 2011 15:24:11 +0100 Thread-Topic: Review of draft-ietf-xcon-common-data-model-23.txt Thread-Index: AcvZo86eQ800UJ0oR5izK08lxz4OpwABgaFw Message-ID: <58E207308662A748A4AC1ECB4E885614052D3DE6F2@ESESSCMS0355.eemea.ericsson.se> References: <19823.37439.966900.314499@fireball.kivinen.iki.fi> In-Reply-To: <19823.37439.966900.314499@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Thu, 03 Mar 2011 07:34:33 -0800 Cc: "draft-ietf-xcon-common-data-model.all@tools.ietf.org" Subject: Re: [secdir] Review of draft-ietf-xcon-common-data-model-23.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 14:23:10 -0000 Hello Tero, Thank you very much for your comments. They're really valuable.=20 The authors of this document understand the Security considerations as a ge= neral guidelines for the implementers, rather than a set of absolute requir= ement for this specification. It might be the case in some particular scena= rios where the confidentiality can be ignored. For this reason, we decided = not to impose confidentiality (using SHOULD instead of MUST) in the documen= t and to leave that decision to the administrator of the conference. =20 The same reason applies to the definition in this document of 'private elem= ents'. Privacy is a subjective expectation and the definition of private el= ements in the conference depends very much on the context of such conferenc= e. As you point out, every country, company, association or entity would ha= ve a completely different meaning of privacy. For this reason, we just deci= ded to suggest some control and integrity of the data ( by using access con= trol rules) in the security section instead of imposing it: =20 In order to minimize these threats, the administrator of the conferencing system MUST ensure that only authorized users can connect to this database (e.g., by using access control rules). In particular, the integrity of the database MUST be protected against unauthorized modifications. Cheers, Oscar -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi]=20 Sent: 3. maaliskuuta 2011 15:06 To: iesg@ietf.org; secdir@ietf.org Cc: draft-ietf-xcon-common-data-model.all@tools.ietf.org Subject: Review of draft-ietf-xcon-common-data-model-23.txt I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document contains xml data model description for conference informatio= n. As this is data model and does not list any actual protocols to transmit= those xml files its security considerations section is quite generic. It does say that database access must be authorized (access control rules) and that integrity of the database MUST be protected against unautho= rized modifications. How this is done is left to the actual protocol docume= nts. It does NOT require confidentiality of the database, but instead says: The confidentiality of the database SHOULD be protected from unauthorized users, given that the data model contains a set of sensitive elements (e.g., passwords). =20 I do not agree on that comment. If the data model contains sensitive elemen= ts like passwords I think the confidentiality MUST be protected from unauth= orized users. If it is possible that the data model does not contain any sensitive elemen= ts then I think the SHOULD could be enough. Also it does not specify what d= ata in the data model is sensitive. Also the security considerations section completely fails to address the fa= ct that the database most likely also contain data that has privacy issues.= For example the list of users participating the specific conference could = be quite big privacy issue (for example some group of human rights people d= iscussing issues about their own goverment). Note, that this also might req= uire some discussion about the lifetime of the data in the database. I.e. w= hen is the list of participants removed from the database and how long it i= s stored there. In most countries there are specific laws protecting such information, so t= hose might require preventing unauthorized access to the database. Also as there is fields like provide-anonymity in the database which tells = which user is mapped to which "anonymous" name for users to see, but if som= eone gets read access to the database that person can directly map those an= onoymous users to their real identities. I think the security consideation sections should include text about the pr= ivacy issues, and most likely mandate support for confidentiality of the da= tabase, and preventing unauthorized read access to it.=20 -- kivinen@iki.fi From tena@huawei.com Thu Mar 3 10:30:47 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C0A73A69FE; Thu, 3 Mar 2011 10:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09iAiqVxTF+D; Thu, 3 Mar 2011 10:30:45 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id BFBC23A6A28; Thu, 3 Mar 2011 10:30:45 -0800 (PST) Received: from huawei.com (usaml01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHH003C2VH52H@usaga01-in.huawei.com>; Thu, 03 Mar 2011 12:31:53 -0600 (CST) Received: from TingZousc1 ([12.133.183.34]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LHH00DRRVH436@usaga01-in.huawei.com>; Thu, 03 Mar 2011 12:31:53 -0600 (CST) Date: Thu, 03 Mar 2011 10:31:18 -0800 From: Tina Tsou In-reply-to: To: secdir-secretary@mit.edu, secdir@ietf.org, 'The IESG' , ietf@ietf.org Message-id: <01b301cbd9d1$45668510$d0338f30$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcvVrFqFo5QMh4YpSHqzKGUtMqf9lAEJIpbw References: Cc: draft-ietf-netconf-4741bis@tools.ietf.org Subject: [secdir] Recheck on draft-ietf-netconf-4741bis-09//RE: Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 18:30:47 -0000 Hi, I rechecked draft-ietf-netconf-4741bis-09, only one more comment: Why is deleted from figure 1 compared with RFC4741? RFC4741: Layer Example +-------------+ +-----------------------------+ (4) | Content | | Configuration data | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ (3) | Operations | | , | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ (2) | RPC | | , | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ (1) | Transport | | BEEP, SSH, SSL, console | | Protocol | | | +-------------+ +-----------------------------+ RFC4741bis: Layer Example +-------------+ +-----------------+ +----------------+ (4) | Content | | Configuration | | Notification | | | | data | | data | +-------------+ +-----------------+ +----------------+ | | | +-------------+ +-----------------+ | (3) | Operations | | | | | | | | | +-------------+ +-----------------+ | | | | +-------------+ +-----------------+ +----------------+ (2) | Messages | | , | | | | | | | | | +-------------+ +-----------------+ +----------------+ | | | +-------------+ +-----------------------------------------+ (1) | Secure | | SSH, TLS, BEEP/TLS, SOAP/HTTP/TLS, ... | | Transports | | | +-------------+ +-----------------------------------------+ We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: secdir-bounces@ietf.org [mailto:secdir-bounces@ietf.org] On Behalf Of Samuel Weiler Sent: Saturday, February 26, 2011 3:57 AM To: secdir@ietf.org Subject: [secdir] Assignments Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Hilarie Orman is next in the rotation. For telechat 2011-03-03 Reviewer LC end Draft Rob Austein T 2011-02-16 draft-ietf-netconf-rfc4742bis-07 Alan DeKok T 2011-03-01 draft-ietf-hip-over-hip-05 Donald Eastlake T 2011-03-01 draft-ietf-6lowpan-usecases-09 Tobias Gondrom T 2011-03-01 draft-ietf-hip-cert-09 Love Hornquist-Astrand T 2011-02-21 draft-ietf-v6ops-v6-in-mobile-networks-03 Russ Mundy T 2011-02-17 draft-ietf-speermint-voipthreats-07 Tina TSOU TR2011-02-07 draft-ietf-netconf-4741bis-09 Sam Weiler TR2011-02-21 draft-ietf-sipcore-199-05 Sam Weiler T 2011-02-16 draft-ietf-hokey-ldn-discovery-06 Glen Zorn T 2011-02-10 draft-ietf-shim6-multihome-shim-api-16 For telechat 2011-03-17 Jeffrey Hutzelman T 2011-03-09 draft-zhu-mobility-survey-03 Catherine Meadows T 2011-03-09 draft-ietf-ancp-protocol-15 Kathleen Moriarty T 2011-03-11 draft-ietf-intarea-server-logging-recommendations-03 Magnus Nystrom T 2011-02-23 draft-meadors-multiple-attachments-ediint-10 Magnus Nystrom T 2011-03-10 draft-ietf-ipsecme-failure-detection-05 Carl Wallace TR2011-02-22 draft-herzog-setkey-03 For telechat 2011-04-14 Sandy Murphy T 2011-03-23 draft-kanno-tls-camellia-00 Last calls and special requests: Dave Cridland 2011-02-21 draft-ietf-sidr-arch-12 Alan DeKok 2011-02-23 draft-ietf-isis-reg-purge-00 Shawn Emery 2011-02-21 draft-ietf-ecrit-phonebcp-16 Sam Hartman 2011-02-21 draft-ietf-sidr-res-certs-21 Love Hornquist-Astrand 2011-03-16 draft-yevstifeyev-tn3270-uri-16 Charlie Kaufman 2011-03-08 draft-ietf-avtcore-ports-for-ucast-mcast-rtp-00 Scott Kelly 2011-03-18 draft-ietf-sipping-nat-scenarios-15 Tero Kivinen 2011-03-04 draft-ietf-xcon-common-data-model-23 Julien Laganier 2011-03-04 draft-ietf-xcon-examples-08 Matt Lepinski 2011-03-08 draft-ietf-dime-nat-control-07 Chris Lonvick R2011-03-17 draft-giralt-schac-ns-04 David McGrew - draft-ietf-ecrit-framework-12 David McGrew 2011-03-03 draft-ietf-sidr-iana-objects-01 Russ Mundy 2011-01-04 draft-cardona-cablelabs-urn-05 Vincent Roca 2011-02-07 draft-reed-urn-dgiwg-02 Brian Weis 2011-03-02 draft-herzog-static-ecdh-05 Nico Williams 2011-01-14 draft-yevstifeyev-http-headers-not-recognized-11 Nico Williams 2011-02-09 draft-ietf-rmt-bb-fec-raptorq-04 _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From kivinen@iki.fi Fri Mar 4 02:35:33 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84A633A68AF; Fri, 4 Mar 2011 02:35:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wINhU0NZ+M1Q; Fri, 4 Mar 2011 02:35:32 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 0DA8B3A6827; Fri, 4 Mar 2011 02:35:31 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p24AaaIU025108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Mar 2011 12:36:36 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p24AaZed001497; Fri, 4 Mar 2011 12:36:35 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19824.49331.334075.644185@fireball.kivinen.iki.fi> Date: Fri, 4 Mar 2011 12:36:35 +0200 From: Tero Kivinen To: Oscar Novo In-Reply-To: <58E207308662A748A4AC1ECB4E885614052D3DE6F2@ESESSCMS0355.eemea.ericsson.se> References: <19823.37439.966900.314499@fireball.kivinen.iki.fi> <58E207308662A748A4AC1ECB4E885614052D3DE6F2@ESESSCMS0355.eemea.ericsson.se> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 9 min Cc: "draft-ietf-xcon-common-data-model.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Review of draft-ietf-xcon-common-data-model-23.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 10:35:33 -0000 Oscar Novo writes: > The authors of this document understand the Security considerations > as a general guidelines for the implementers, rather than a set of > absolute requirement for this specification. It might be the case in > some particular scenarios where the confidentiality can be ignored. > For this reason, we decided not to impose confidentiality (using > SHOULD instead of MUST) in the document and to leave that decision > to the administrator of the conference. I can understand that, and I agree that on some scenarios the confidentiality can be ignored. But I do think that is the case when the database actually holds confidential information like passwords. I would be happy for text saying that if database has no confidential information then confidentiality may be ignored, but if in most cases I think it does include confidential information and then it needs to be protected. Anyways I think this is to point the fact out to iesg, they can decide whether it is appropriate or not. Usually protocols have required confidentiality when there are tihngs like passwords to be protected. > The same reason applies to the definition in this document of > 'private elements'. Privacy is a subjective expectation and the > definition of private elements in the conference depends very much > on the context of such conference. As you point out, every country, > company, association or entity would have a completely different > meaning of privacy. For this reason, we just decided to suggest some > control and integrity of the data ( by using access control rules) > in the security section instead of imposing it: The current security considerations section does not say anything about the privacy issue, and I think this is big omission. I am not sure if any real world requirement can be given, but I think the security considerations section should point out that the database has privacy related information stored in it and that should be taken in to consideration when deciding how the database is protected, and who has access to it. The privacy issue also brings up new topic, namely the lifetime of the data in the database. I do not know whether the entry stays in database only during the conference, or whether it stays there forever. For privacy information storing it long times can cause problems. -- kivinen@iki.fi From biermana@Brocade.com Thu Mar 3 10:43:11 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EE823A67EF; Thu, 3 Mar 2011 10:43:11 -0800 (PST) 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=[AWL=0.493, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytAq6ZUH3pMT; Thu, 3 Mar 2011 10:43:10 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id D15E53A67D3; Thu, 3 Mar 2011 10:43:09 -0800 (PST) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id p23Ia1su030475; Thu, 3 Mar 2011 10:44:13 -0800 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0b-000f0801.pphosted.com with ESMTP id utg90r0g0-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 03 Mar 2011 10:44:13 -0800 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 3 Mar 2011 10:52:13 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Thu, 3 Mar 2011 10:44:11 -0800 From: Andy Bierman To: Tina Tsou , "secdir-secretary@mit.edu" , "secdir@ietf.org" , "'The IESG'" , "ietf@ietf.org" Date: Thu, 3 Mar 2011 10:44:10 -0800 Thread-Topic: Recheck on draft-ietf-netconf-4741bis-09//RE: [secdir] Assignments Thread-Index: AcvVrFqFo5QMh4YpSHqzKGUtMqf9lAEJIpbwAAB2dxA= Message-ID: References: <01b301cbd9d1$45668510$d0338f30$@com> In-Reply-To: <01b301cbd9d1$45668510$d0338f30$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-03_06:2011-03-03, 2011-03-03, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1103030113 X-Mailman-Approved-At: Fri, 04 Mar 2011 11:12:33 -0800 Cc: "draft-ietf-netconf-4741bis@tools.ietf.org" Subject: Re: [secdir] Recheck on draft-ietf-netconf-4741bis-09//RE: Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 18:43:11 -0000 Hi, The was removed from the diagram to make room for the notification stuff on the right. It does not mean that was removed from the protocol. The box just showed 2 of the many operations, now only 1. Andy -----Original Message----- From: Tina Tsou [mailto:tena@huawei.com]=20 Sent: Thursday, March 03, 2011 10:31 AM To: secdir-secretary@mit.edu; secdir@ietf.org; 'The IESG'; ietf@ietf.org Cc: draft-ietf-netconf-4741bis@tools.ietf.org Subject: Recheck on draft-ietf-netconf-4741bis-09//RE: [secdir] Assignments Hi, I rechecked draft-ietf-netconf-4741bis-09, only one more comment: Why is deleted from figure 1 compared with RFC4741?=20 RFC4741: Layer Example=20 +-------------+ +-----------------------------+=20 (4) | Content | | Configuration data |=20 +-------------+ +-----------------------------+=20 | |=20 +-------------+ +-----------------------------+=20 (3) | Operations | | , |=20 +-------------+ +-----------------------------+=20 | |=20 +-------------+ +-----------------------------+=20 (2) | RPC | | , |=20 +-------------+ +-----------------------------+=20 | |=20 +-------------+ +-----------------------------+=20 (1) | Transport | | BEEP, SSH, SSL, console |=20 | Protocol | | |=20 +-------------+ +-----------------------------+=20 RFC4741bis:=20 Layer Example=20 +-------------+ +-----------------+ +----------------+=20 (4) | Content | | Configuration | | Notification |=20 | | | data | | data |=20 +-------------+ +-----------------+ +----------------+=20 | | |=20 +-------------+ +-----------------+ |=20 (3) | Operations | | | |=20 | | | | |=20 +-------------+ +-----------------+ |=20 | | |=20 +-------------+ +-----------------+ +----------------+=20 (2) | Messages | | , | | |=20 | | | | | |=20 +-------------+ +-----------------+ +----------------+=20 | | |=20 +-------------+ +-----------------------------------------+=20 (1) | Secure | | SSH, TLS, BEEP/TLS, SOAP/HTTP/TLS, ... |=20 | Transports | | |=20 +-------------+ +-----------------------------------------+ We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: secdir-bounces@ietf.org [mailto:secdir-bounces@ietf.org] On Behalf Of Samuel Weiler Sent: Saturday, February 26, 2011 3:57 AM To: secdir@ietf.org Subject: [secdir] Assignments Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Hilarie Orman is next in the rotation. For telechat 2011-03-03 Reviewer LC end Draft Rob Austein T 2011-02-16 draft-ietf-netconf-rfc4742bis-07 Alan DeKok T 2011-03-01 draft-ietf-hip-over-hip-05 Donald Eastlake T 2011-03-01 draft-ietf-6lowpan-usecases-09 Tobias Gondrom T 2011-03-01 draft-ietf-hip-cert-09 Love Hornquist-Astrand T 2011-02-21 draft-ietf-v6ops-v6-in-mobile-networks-03 Russ Mundy T 2011-02-17 draft-ietf-speermint-voipthreats-07 Tina TSOU TR2011-02-07 draft-ietf-netconf-4741bis-09 Sam Weiler TR2011-02-21 draft-ietf-sipcore-199-05 Sam Weiler T 2011-02-16 draft-ietf-hokey-ldn-discovery-06 Glen Zorn T 2011-02-10 draft-ietf-shim6-multihome-shim-api-16 For telechat 2011-03-17 Jeffrey Hutzelman T 2011-03-09 draft-zhu-mobility-survey-03 Catherine Meadows T 2011-03-09 draft-ietf-ancp-protocol-15 Kathleen Moriarty T 2011-03-11 draft-ietf-intarea-server-logging-recommendations-03 Magnus Nystrom T 2011-02-23 draft-meadors-multiple-attachments-ediint-10 Magnus Nystrom T 2011-03-10 draft-ietf-ipsecme-failure-detection-05 Carl Wallace TR2011-02-22 draft-herzog-setkey-03 For telechat 2011-04-14 Sandy Murphy T 2011-03-23 draft-kanno-tls-camellia-00 Last calls and special requests: Dave Cridland 2011-02-21 draft-ietf-sidr-arch-12 Alan DeKok 2011-02-23 draft-ietf-isis-reg-purge-00 Shawn Emery 2011-02-21 draft-ietf-ecrit-phonebcp-16 Sam Hartman 2011-02-21 draft-ietf-sidr-res-certs-21 Love Hornquist-Astrand 2011-03-16 draft-yevstifeyev-tn3270-uri-16 Charlie Kaufman 2011-03-08 draft-ietf-avtcore-ports-for-ucast-mcast-rtp-00 Scott Kelly 2011-03-18 draft-ietf-sipping-nat-scenarios-15 Tero Kivinen 2011-03-04 draft-ietf-xcon-common-data-model-23 Julien Laganier 2011-03-04 draft-ietf-xcon-examples-08 Matt Lepinski 2011-03-08 draft-ietf-dime-nat-control-07 Chris Lonvick R2011-03-17 draft-giralt-schac-ns-04 David McGrew - draft-ietf-ecrit-framework-12 David McGrew 2011-03-03 draft-ietf-sidr-iana-objects-01 Russ Mundy 2011-01-04 draft-cardona-cablelabs-urn-05 Vincent Roca 2011-02-07 draft-reed-urn-dgiwg-02 Brian Weis 2011-03-02 draft-herzog-static-ecdh-05 Nico Williams 2011-01-14 draft-yevstifeyev-http-headers-not-recognized-11 Nico Williams 2011-02-09 draft-ietf-rmt-bb-fec-raptorq-04 _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From weiler+secdir@watson.org Fri Mar 4 12:02:52 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B61E13A681B for ; Fri, 4 Mar 2011 12:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VY83WX+iA6J for ; Fri, 4 Mar 2011 12:02:52 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 569F43A6A13 for ; Fri, 4 Mar 2011 12:02:51 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p24K3xs6037695 for ; Fri, 4 Mar 2011 15:03:59 -0500 (EST) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p24K3xZc037690 for ; Fri, 4 Mar 2011 15:03:59 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 4 Mar 2011 15:03:58 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Fri, 04 Mar 2011 15:03:59 -0500 (EST) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 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, 04 Mar 2011 20:02:52 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Joe Salowey is next in the rotation. For telechat 2011-03-17 Love Hornquist-Astrand T 2011-02-21 draft-ietf-v6ops-v6-in-mobile-networks-03 Jeffrey Hutzelman T 2011-03-09 draft-zhu-mobility-survey-03 Catherine Meadows T 2011-03-09 draft-ietf-ancp-protocol-15 Kathleen Moriarty T 2011-03-11 draft-ietf-intarea-server-logging-recommendations-03 Magnus Nystrom T 2011-03-10 draft-ietf-ipsecme-failure-detection-05 Hilarie Orman T 2011-03-14 draft-ietf-httpbis-content-disp-06 Radia Perlman T 2011-03-14 draft-ietf-mip4-gre-key-extension-04 Eric Rescorla T 2011-03-14 draft-ietf-netext-pmip6-lr-ps-05 Carl Wallace TR2011-02-22 draft-herzog-setkey-03 For telechat 2011-04-14 Reviewer LC end Draft Sandy Murphy T 2011-03-23 draft-kanno-tls-camellia-00 Vincent Roca T - draft-ietf-netlmm-pmipv6-mib-04 Last calls and special requests: Reviewer LC end Draft Dave Cridland 2011-02-21 draft-ietf-sidr-arch-12 Alan DeKok 2011-02-23 draft-ietf-isis-reg-purge-01 Shawn Emery 2011-02-21 draft-ietf-ecrit-phonebcp-16 Sam Hartman 2011-02-21 draft-ietf-sidr-res-certs-21 Love Hornquist-Astrand 2011-03-16 draft-yevstifeyev-tn3270-uri-16 Charlie Kaufman 2011-03-08 draft-ietf-avtcore-ports-for-ucast-mcast-rtp-00 Scott Kelly 2011-03-18 draft-ietf-sipping-nat-scenarios-15 Julien Laganier 2011-03-04 draft-ietf-xcon-examples-08 Matt Lepinski 2011-03-08 draft-ietf-dime-nat-control-07 Chris Lonvick R2011-03-17 draft-giralt-schac-ns-04 David McGrew - draft-ietf-ecrit-framework-12 David McGrew 2011-03-03 draft-ietf-sidr-iana-objects-01 Russ Mundy 2011-01-04 draft-cardona-cablelabs-urn-05 Vincent Roca 2011-02-07 draft-reed-urn-dgiwg-02 Nico Williams 2011-01-14 draft-yevstifeyev-http-headers-not-recognized-11 Nico Williams 2011-02-09 draft-ietf-rmt-bb-fec-raptorq-04 From magnusn@gmail.com Sun Mar 6 23:13:39 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94DFC3A6902; Sun, 6 Mar 2011 23:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmZyAbmUd7S3; Sun, 6 Mar 2011 23:13:38 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 692633A68F2; Sun, 6 Mar 2011 23:13:38 -0800 (PST) Received: by iyj8 with SMTP id 8so4528508iyj.31 for ; Sun, 06 Mar 2011 23:14:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=9cu1G2XccRxlGjnuicfzIsfy/UK1vb9BBdiTEWrGIYg=; b=xGUs66d6jcfhMrl3c64dLy5xpIkGCFNxNPIr3HaDBNHLD/CTbtgnRPCqh5piyRP5vK Vyg4voho2njuDgbS4ESy8E2m8z/enMGL2rQ/BnHoF8dIM9qM85UbSG4L3mLu81bsdkxL X3eNJ0JedeR2/jyFzhyqhJhsl1Mx0qYnDCqDA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ZZfEzjKXkaMzkp6M6UlfJ0nm7EIYnIKjXByfd+6XayNZQbmusUHHxKRClcw/u8/ZQ3 sM8jTZe6iJGNOwI3XDnnjOJ5QTfOUZJBt1NU0Qg58iwUzMldKS5c+ScJQWBXuBSmp46b 5Hpz3oYXWU0QrnZJtPrRHJyTyyJLQnv+vI7Iw= MIME-Version: 1.0 Received: by 10.42.130.10 with SMTP id t10mr4064881ics.34.1299482091288; Sun, 06 Mar 2011 23:14:51 -0800 (PST) Received: by 10.231.11.140 with HTTP; Sun, 6 Mar 2011 23:14:51 -0800 (PST) Date: Sun, 6 Mar 2011 23:14:51 -0800 Message-ID: From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: iesg@ietf.org, secdir@ietf.org, draft-ietf-ipsecme-failure-detection@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] Secdir review of draft-ietf-ipsecme-failure-detection-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 07:13:39 -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 defines a new extension (the "QCD token") to the IKEv2 protocol that allows for faster detection of SA de-synchronization. - General: o "Quick Crash Detection": Is "crash" really the right term here? As the document indicates, the SA de-synchronization may have had other reasons than a crash...? The term "failure detection" seems more accurate. - Section 1, Introduction: o "However, in many cases the rebooted peer is a VPN gateway that protects only servers, or else the non-rebooted peer has a dynamic IP address" - it is not clear from this how or why the dynamic IP address of the non-rebooted peer impacts the tunnel re-establishment? o Editorial: "is a quick" -> "in a quick"? - Section 2, RFC 5996 Crash Recovery : o "There are cases where the peer loses state and is able to recover immediately; in those cases it might take several minutes to recover." - so a peer is able to recover immediately, yet it might take several minutes to recover?? Unclear what is meant here. - Section 5, Token Generation and Verification: o (Not sure why these methods are called stateless as the QCD_SECRET must be maintained?) o By adding a nonce to the token generation the attack outlined in Section 9.3 would be impossible, as the attacker would also need to guess the nonce (adding a nonce to the TOKEN_SECRET_DATA generation would also have the effect that even for the same SPIs, the TOKEN_SECRET_DATA would be different). More generally, a standard key derivation scheme such as the Concatenation KDF in NIST SP 800-56 may be considered. - Section 9.2, Security Considerations: o Last paragraph: "This method should not be used..." - unclear what method is being referred to here? - Appendix A.2: o Would have been useful with a sentence or two that indicated why the working group preferred the QCD proposal over the SIR one. -- Magnus From clonvick@cisco.com Mon Mar 7 13:45:01 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBFB43A6863; Mon, 7 Mar 2011 13:45:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvFohIDtCdIw; Mon, 7 Mar 2011 13:44:59 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 60D663A684A; Mon, 7 Mar 2011 13:44:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=clonvick@cisco.com; l=4647; q=dns/txt; s=iport; t=1299534373; x=1300743973; h=date:from:to:cc:subject:message-id:mime-version; bh=q9+feKbycsOzVRPZ8EYGdyr+WRXVcDq/BdvRv7UVXAs=; b=Lnf9UNCQxbMQ2fV5++sDlkimh+QaKXrzIMORltbWT7tlw6jZB728I5zU pB8h2RhuBFt8p4Wgbuix7Wq+ABxQIM/MPttXMUfrQOM4thRCbVXQhCWfc nFdJ9E6AOGEV1tZ1yb6+T5dQHRStN6Xl77fbWH9uQ6iqhvcMtTtr4bUrz A=; X-IronPort-AV: E=Sophos;i="4.62,279,1297036800"; d="scan'208";a="272094481" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 07 Mar 2011 21:46:11 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p27LkA6w024776; Mon, 7 Mar 2011 21:46:10 GMT Date: Mon, 7 Mar 2011 13:46:10 -0800 (PST) From: Chris Lonvick To: draft-giralt-schac-ns.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [secdir] SECDIR review of draft-giralt-schac-ns-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 21:45:01 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This is actually my second review of this document. It looks like many of my comments from 31 December 2009 have not been addressed. Below are my comments from then with new comments preceeded by "CML>". The only security concern I have is that the registration URN is not yet active and that it is limited to HTTPS. While I think it is still going to take some time for this ID to become an RFC, I'd just like to see the web site set up sooner rather than later so the kinks may be ironed out. Beyond that, I think that it would be better to state that it will always be a "secure web site" which will offer credentials signed by such-n-such, and will require the latest secure methods for accessing a web site; that currently being http [reference] with the latest TLS transport [reference]. My issue with this is that "https" can still reference SSLv2 and I don't think that's the intent of the statement in this ID. I don't have any concerns about the Security Considerations section other than the statement about using "HTTPS" as noted above. I do have a few nits that the authors may want to address. The terms TERENA and TF-EMC2 are used without first defining them. Maybe some changes in Section 1. CURRENT: The SCHAC international activity was born inside the TF-EMC2 middleware task force of the Trans European Research and Education Network Association. The initial aim of SCHAC was to harmonise the PROPOSED: The SCHAC international activity was born inside the TF-EMC2 (Task Force on European Middleware Coordination and Collaboration) of the Trans European Research and Education Network Association (TERENA). The initial aim of SCHAC was to harmonise the... CML> I do see that TERENA was defined, but EMC2 is still not defined. I think that the second paragraph of the Abstract could use some polishing. CURRENT: This namespace is for naming persistent resources defined by the SCHAC international activity participants, their working groups and other designated subordinates. The namespace main use will be the creation of controlled vocabulary values for attributes in the SCHAC schema. This values will be associated to particular instances of persons or objects belonging to any of the SCHAC object classes. SUGGESTED: The namespace described in this document is for naming persistent resources defined by the SCHAC participants internationally, their working groups, and other designated subordinates. The main use of this namespace will be for the creation of controlled vocabulary values for attributes in the SCHAC schema. These values will be associated with particular instances of persons or objects belonging to any of the SCHAC object classes. CML> I see that this paragraph is been duplicated into the Introduction. I don't think that's necessary. In Section 4, the word "Anyhow" is ambiguous. I'd suggest replacing it with a more definite word such as "Regardless", or with the term "In any case". In Section 5, the term "NREN" is not defined before it is used. I'd suggest: CURRENT: The assignment and use of identifiers within the namespace are open, and the related rule is established by the SCHAC activity members. Registration agencies (the next level naming authorities) will be the National Research and Education Networks and established organizational cross-border organizations that participate in SCHAC. SUGGESTED: The assignment and use of identifiers within the namespace are open, and the related rule is established by the SCHAC activity members. Registration agencies (the next level naming authorities) will be the National Research and Education Networks (NRENS) and other established, cross-border organizations that participate in SCHAC. CML> I see that this version does use the term "National Research and Education Network" but it's not associated with the acronym. In the third paragraph of Section 5, remove the term "as soon as practical". ...just get it done. :-) Could you add a URL to reference [4]? CML> Could you also add a URL for reference [5]? Best regards, Chris From bew@cisco.com Mon Mar 7 21:14:11 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7058F3A696F; Mon, 7 Mar 2011 21:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.224 X-Spam-Level: X-Spam-Status: No, score=-110.224 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_OBFU_ALL=0.751, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nD1sDZ-AH7cT; Mon, 7 Mar 2011 21:14:10 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 1098D3A6847; Mon, 7 Mar 2011 21:14:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=7469; q=dns/txt; s=iport; t=1299561324; x=1300770924; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=zMDsdRuaLDK0HDovTJFhsEyaXKRJdkbPnRaNElTdfZk=; b=DpGTLoCtuFL3bf0gtGJ5zaEEY+Gmfbu3A/+iOO6Jwnzz+HCVYWKNZO8Z UbQYgVuDApll43zIEXNWXOHMaasmrlNezVx0ZGRPLvvU985lh0OkXj/+G ioDo51dtjB9HO/czVeburFIV90/ZcgSnZIod6mE31DVEsdnwGdfjEVhaL 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJtKdU2rR7Hu/2dsb2JhbACmVnShdZw+gxiCSgSFHYcVjCA X-IronPort-AV: E=Sophos;i="4.62,282,1297036800"; d="scan'208";a="274576348" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 08 Mar 2011 05:15:07 +0000 Received: from stealth-10-32-244-213.cisco.com (stealth-10-32-244-213.cisco.com [10.32.244.213]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p285F6m1027114; Tue, 8 Mar 2011 05:15:06 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Brian Weis In-Reply-To: <552BBAA9-712F-49B4-8A5F-C671C3817C05@ll.mit.edu> Date: Mon, 7 Mar 2011 21:15:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <552BBAA9-712F-49B4-8A5F-C671C3817C05@ll.mit.edu> To: "Herzog, Jonathan - 0668 - MITLL" X-Mailer: Apple Mail (2.1082) Cc: "draft-herzog-static-ecdh@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 05:14:11 -0000 Hi Jonathan, On Mar 6, 2011, at 1:43 PM, Herzog, Jonathan - 0668 - MITLL wrote: >=20 > On Mar 3, 2011, at 1:39 AM, Brian Weis wrote: >=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.=20= >=20 > I plan to address these comments and submit a new draft in the next = few days. Before I do, however, do you mind if I asked you a few = questions? >=20 >> 1. The Abstract and Introduction use the term "static-static" = Elliptic Curve Diffie-Hellman key-agreement, which is a term not in = common use. I guessed correctly that it meant the case where both = participants in the key agreement were using static DH values, but I = think until the term is define (later on in the Introduction) it would = be clearer to say something like "Elliptic Curve Diffie-Hellman = key-agreement where both participants use static Diffie-Hellman values". >=20 > Good catch. I have included your suggestion in both the abstract: >=20 > "This document describes how to use 'static-static' Elliptic > Curve Diffie-Hellman key-agreement (i.e., Elliptic Curve > Diffie-Hellman where both participants use static Diffie-Hellman > values) with the Cryptographic Message Syntax." >=20 > and the introduction: >=20 > "This document describes how to use the static-static Elliptic-Curve > Diffie-Hellman key agreement scheme (i.e., Elliptic Curve Diffie- > Hellman [SEC1] where both participants use static Diffie-Hellman > values) in the Cryptographic Message Syntax (CMS) [CMS]." >=20 > And the rest of the introduction remains the same. Do you think this = will be enough to orient the reader correctly? That'll do the trick nicely, I think. >=20 >=20 >> 2. Reference [SEC1] is heavily referenced in this document, for both = a definition of ECDH and specific methods for using ECDH. But it would = be good to also mention RFC 6090, which is the best IETF document = describing ECDH. >=20 > I was not previous aware of this RFC-- my bad. I have added it as an = informative reference, but continued to refer to [Sec1] as the normative = reference for the ECDH operation. Or do you think that RFC 6090 should = be the normative reference? I would suggesting using RFC 6090 for a normative reference to ECDH if = you need such a reference. But I don't believe RFC 6090 discusses = static-static consideration or issues at all, so for that [Sec1] seems = to be the appropriate normative reference. >> 3. Generally, when two parties use static DH values over different = exchanges they will use the same key for each exchange, which is = generally not a good practice. I believe this is true for ECDH as well. = Sections 2.2 and 2.3 mention "SharedInfo", which when used appropriately = will permute the shared key such that the sessions are not keyed = identically. But I believe the use of "SharedInfo" is optional, so I was = expecting the Security Considerations to describe this scenario and at = least say that "SharedInfo" SHOULD be used (or possibly MUST be used). = It would be good to add this discussion to Security Considerations. >=20 > I'm not sure what you mean, here. Do you mean the SharedInfo value, or = the ukm value? According to RFC 3278, the SharedInfo value is the DER = encoding of the ECC-CMS-SharedInfo value: >=20 >=20 > ECC-CMS-SharedInfo ::=3D SEQUENCE { > keyInfo AlgorithmIdentifier, > entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL, > suppPubInfo [2] EXPLICIT OCTET STRING } >=20 > Also according to that RFC: >=20 > entityUInfo optionally contains additional keying material > supplied by the sending agent. When used with ECDH and CMS, the > entityUInfo field contains the octet string ukm. >=20 > So, my read of the RFC is that ECDH in CMS will always use a = SharedInfo value to derive keys, and this value will contain a = per-message unique value if and only if the ukm field was used by the = sender. Now, the ukm value *is* optional, according to RFC 5652, which = is why our Draft says they SHOULD be used: >=20 > Section 2.1: >=20 > o ukm MAY be present or absent. However, message originators = SHOULD > include the ukm. As specified in [CMS], implementations MUST > support ukm message recipient processing, so interoperability is > not a concern if the ukm is present or absent. The use of a = fresh > value for ukm will ensure that a different key is generated for > each message between the same sender and receiver. ukm, if > present, is placed in the entityUInfo field of the ECC-CMS- > SharedInfo structure [CMS-ECC] and therefore used as an input to > the key derivation function. >=20 >=20 > Security Considerations: >=20 > Extreme care must be used when using static-static Diffie-Hellman > (either standard or cofactor) without the use of some per-message > value in ukm. If no message-specific information is used (such as a > counter value, or a fresh random string) then the resulting secret > key could be used in more than one message. Under some > circumstances, this will open the sender to the 'small subgroup' > attack [MenezesUstaoglu] or other, yet-undiscovered attacks on re- > used Diffie-Hellman keys. Applications that cannot tolerate the > inclusion of per-message information in ukm (due to bandwidth > requirements, for example) SHOULD NOT use static-static ECDH for a > recipient without ascertaining that the recipient knows the private > value associated with their certified Diffie-Hellman value. >=20 >=20 > So I'm under the impression that our Draft requires a ukm value (with = a SHOULD), and that RFC 3278 requires that this ukm value be included in = a SharedInfor value which is used to derive keys. But did I misread RFC = 3278? I did notice the text regarding ukm in your I-D, but definitely missed = linkage you quote from RFC 3278 above. So rather than misreading RFC = 3278 you've clarified it for me. :-) Your explanation makes sense to me. > Do I need to explicitly require that the SharedInfo value be used? I think your requirements are fine. But because you discuss both ukm and = SharedInfo, I would clarifying their linkage. For example, in your = Security Considerations you could mention the role of SharedInfo to = permute the session so that two sessions setup between the same entities = will be keyed independently, point out that CMS specifies that ukm is to = be the value used in SharedInfo, and how ukm is determined so that it = will properly do its job. This is also rationale for the SHOULD in = section 2.1. BTW, the RFC Index search engine says that RFC 3278 has been obsoleted = by RFC 5753. You should reference that one (which hopefully makes the = same statements regarding ukm). Hope that helps, Brian >=20 > Thanks. >=20 > --=20 > Jonathan Herzog = voice: (781) 981-2356 > Technical Staff = fax: (781) 981-7687 > Cyber Systems and Technology Group email: = jherzog@ll.mit.edu > MIT Lincoln Laboratory www: = http://www.ll.mit.edu/CST/ > 244 Wood Street =20 > Lexington, MA 02420-9185 >=20 --=20 Brian Weis Security Standards and Technology, ARTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From prvs=204623e733=jherzog@ll.mit.edu Sun Mar 6 13:42:13 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F7913A688B; Sun, 6 Mar 2011 13:42:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.847 X-Spam-Level: X-Spam-Status: No, score=-5.847 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmzeYBxCkMmz; Sun, 6 Mar 2011 13:42:12 -0800 (PST) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by core3.amsl.com (Postfix) with ESMTP id 7A9C13A6845; Sun, 6 Mar 2011 13:42:11 -0800 (PST) Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id p26LhKu0031978; Sun, 6 Mar 2011 16:43:20 -0500 From: "Herzog, Jonathan - 0668 - MITLL" To: Brian Weis Date: Sun, 6 Mar 2011 16:42:47 -0500 Thread-Topic: Secdir review of draft-herzog-static-ecdh-05 Thread-Index: AcvcR4KihL0SzAu+RdmncC3oRytiVg== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-112--981979745"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-06_04:2011-03-04, 2011-03-06, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=8 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1012030000 definitions=main-1103060102 X-Mailman-Approved-At: Tue, 08 Mar 2011 08:18:12 -0800 Cc: "draft-herzog-static-ecdh@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2011 21:42:13 -0000 --Apple-Mail-112--981979745 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 3, 2011, at 1:39 AM, Brian Weis wrote: > I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG.=20= I plan to address these comments and submit a new draft in the next few = days. Before I do, however, do you mind if I asked you a few questions? > 1. The Abstract and Introduction use the term "static-static" Elliptic = Curve Diffie-Hellman key-agreement, which is a term not in common use. I = guessed correctly that it meant the case where both participants in the = key agreement were using static DH values, but I think until the term is = define (later on in the Introduction) it would be clearer to say = something like "Elliptic Curve Diffie-Hellman key-agreement where both = participants use static Diffie-Hellman values". Good catch. I have included your suggestion in both the abstract: "This document describes how to use 'static-static' Elliptic Curve Diffie-Hellman key-agreement (i.e., Elliptic Curve Diffie-Hellman where both participants use static Diffie-Hellman values) with the Cryptographic Message Syntax." and the introduction: "This document describes how to use the static-static Elliptic-Curve Diffie-Hellman key agreement scheme (i.e., Elliptic Curve Diffie- Hellman [SEC1] where both participants use static Diffie-Hellman values) in the Cryptographic Message Syntax (CMS) [CMS]." And the rest of the introduction remains the same. Do you think this = will be enough to orient the reader correctly? > 2. Reference [SEC1] is heavily referenced in this document, for both a = definition of ECDH and specific methods for using ECDH. But it would be = good to also mention RFC 6090, which is the best IETF document = describing ECDH. I was not previous aware of this RFC-- my bad. I have added it as an = informative reference, but continued to refer to [Sec1] as the normative = reference for the ECDH operation. Or do you think that RFC 6090 should = be the normative reference? > 3. Generally, when two parties use static DH values over different = exchanges they will use the same key for each exchange, which is = generally not a good practice. I believe this is true for ECDH as well. = Sections 2.2 and 2.3 mention "SharedInfo", which when used appropriately = will permute the shared key such that the sessions are not keyed = identically. But I believe the use of "SharedInfo" is optional, so I was = expecting the Security Considerations to describe this scenario and at = least say that "SharedInfo" SHOULD be used (or possibly MUST be used). = It would be good to add this discussion to Security Considerations. I'm not sure what you mean, here. Do you mean the SharedInfo value, or = the ukm value? According to RFC 3278, the SharedInfo value is the DER = encoding of the ECC-CMS-SharedInfo value: ECC-CMS-SharedInfo ::=3D SEQUENCE { keyInfo AlgorithmIdentifier, entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL, suppPubInfo [2] EXPLICIT OCTET STRING } Also according to that RFC: entityUInfo optionally contains additional keying material supplied by the sending agent. When used with ECDH and CMS, the entityUInfo field contains the octet string ukm. So, my read of the RFC is that ECDH in CMS will always use a SharedInfo = value to derive keys, and this value will contain a per-message unique = value if and only if the ukm field was used by the sender. Now, the ukm = value *is* optional, according to RFC 5652, which is why our Draft says = they SHOULD be used: Section 2.1: o ukm MAY be present or absent. However, message originators SHOULD include the ukm. As specified in [CMS], implementations MUST support ukm message recipient processing, so interoperability is not a concern if the ukm is present or absent. The use of a fresh value for ukm will ensure that a different key is generated for each message between the same sender and receiver. ukm, if present, is placed in the entityUInfo field of the ECC-CMS- SharedInfo structure [CMS-ECC] and therefore used as an input to the key derivation function. Security Considerations: Extreme care must be used when using static-static Diffie-Hellman (either standard or cofactor) without the use of some per-message value in ukm. If no message-specific information is used (such as a counter value, or a fresh random string) then the resulting secret key could be used in more than one message. Under some circumstances, this will open the sender to the 'small subgroup' attack [MenezesUstaoglu] or other, yet-undiscovered attacks on re- used Diffie-Hellman keys. Applications that cannot tolerate the inclusion of per-message information in ukm (due to bandwidth requirements, for example) SHOULD NOT use static-static ECDH for a recipient without ascertaining that the recipient knows the private value associated with their certified Diffie-Hellman value. So I'm under the impression that our Draft requires a ukm value (with a = SHOULD), and that RFC 3278 requires that this ukm value be included in a = SharedInfor value which is used to derive keys. But did I misread RFC = 3278? Do I need to explicitly require that the SharedInfo value be used? Thanks. --=20 Jonathan Herzog voice: = (781) 981-2356 Technical Staff fax: = (781) 981-7687 Cyber Systems and Technology Group email: = jherzog@ll.mit.edu MIT Lincoln Laboratory www: = http://www.ll.mit.edu/CST/ 244 Wood Street =20 Lexington, MA 02420-9185 --Apple-Mail-112--981979745 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJrzCCBNIw ggO6oAMCAQICChVM3JYAAAAAIh8wDQYJKoZIhvcNAQEFBQAwUTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwg Q0EtMTAeFw0xMDA1MjUyMDQ1MzhaFw0xMTA1MjUyMDQ1MzhaMGQxCzAJBgNVBAYTAlVTMR8wHQYD VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQZW9wbGUxIzAhBgNVBAMTGkhl cnpvZy5Kb25hdGhhbi5DLjUwMDExMzA1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 93mr5a6zq6EQsVtIX9BadxwzpjabF8pvDmoMSP/ZhbWrncNJ1j7xiBGcihYqsDaQz9+hJITxi7IM NUx5fnFtOQRHZgkOCLR1URFc0AlJ3Pknv6XoQ4fqPODmSMB882c9l/8AbO7N/27r8n/V0Ip4Rpw8 1qnrDXk6UH/1zHlssGmlVng0RSREuQy98xPxzbLr5cOMWLwHs5OLNYcGv0KlD6rp1DPzJ3qplU/+ 0P2jyYbGyXStJ/h+3Kx5mOWFLB4j8HDyLG90ZHlZjZXo9FrSoFubVJK/mdVzIuXd00Ldl1fCyxhR D9elkpTc7xOLJsEzCCi8Gqo6eQuvz1RH93u3PwIDAQABo4IBlzCCAZMwDgYDVR0PAQH/BAQDAgbA MB0GA1UdDgQWBBRPjG6+CxR6H/o9vyq5PgmW9vmuajAfBgNVHSMEGDAWgBSUWsZYybYmm6AJe6gv ZJDDiQJuKjAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xM Q0ExMGIGCCsGAQUFBwEBBFYwVDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dHRvL0xMQ0ExMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5sbC5taXQuZWR1LzAMBgNVHRMBAf8E AjAAMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH /4pzAgFkAgEFMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8w DQYLKoZIhvcSAgEDAQgwHQYDVR0RBBYwFIESamhlcnpvZ0BsbC5taXQuZWR1MA0GCSqGSIb3DQEB BQUAA4IBAQBI6aoe1c6Glzs3Hh/lIzf2TzmtZSQLl8UZaIFGi0zG0EjsO6wjX6bfv/WizE30OEef 6So76p0dNt7j21lrH+FGaH6r41ggikbkoazNkAePsQk0WPZhmpus1rByNUozK4KMPpzLAynHNd5m POtqoIwDiTEgktLuZ1nwU7bUHmv7BO14dkhLhMOFKRCIi3vqe9rDh9pTYt1YNhQe1fBme6Y5DWLA TxBBqErz05e7rVngKi6yk6j7cqWpiM6L93z2Zq5p9FqACsJHmMwxH/8XFeeXgFf/CKMAIuSZCGFU 29ouEZWL7LLu87SFGm3f/3sLS7xgXei7d/PlXte1HKKdKOCPMIIE1TCCA72gAwIBAgIKFU5e0QAA AAAiIDANBgkqhkiG9w0BAQUFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4g TGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xMB4XDTEwMDUyNTIw NDcxN1oXDTExMDUyNTIwNDcxN1owZDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xu IExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEjMCEGA1UEAxMaSGVyem9nLkpvbmF0aGFuLkMu NTAwMTEzMDUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtC8sNdkCteQagOVEnQQs4 5uLqsmaOfjqTywNWuvaVj0F8Jsek8bOcuK4rlB1PrBk0Q+s/N4FVcGEn6BEDWRIDFaETVr1jweTE yRUtqngTIvpbpeixV37BcFkVnbV2VrZC5oaa0c0bkxXkuE0lohQS5AIBXQRADEJVnfXIM44yvsmo T7J5rdGwjIg4QJ2YA07po0JkbndcylcjU0zW2Lv432MEZrX/o+T0rraFAhT8A+8De9CIo0LJkXCK cNwk6LwuNKQS0qeezDo5wRiqZaht3ftiAuOImOxN44hxnDa2cHVbOFQ+pevN08gH7d39CVHUbHMC PnuIBoQNu61I2+ItAgMBAAGjggGaMIIBljAOBgNVHQ8BAf8EBAMCBSAwHQYDVR0OBBYEFEuYUJcI JTs8b2SWTJN28DD/qqsNMB8GA1UdIwQYMBaAFJRaxljJtiaboAl7qC9kkMOJAm4qMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTEwYgYIKwYBBQUHAQEE VjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTEwIwYIKwYB BQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUH BDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0l BB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMB CDAdBgNVHREEFjAUgRJqaGVyem9nQGxsLm1pdC5lZHUwDQYJKoZIhvcNAQEFBQADggEBAAmf5m3W 0Di4aQhLS1e2xejG3MQPQJvWL3dHbnHYG+NDVFWcuqyE5t73eb7nV2UyGRVHDt6MyIquedAPPm86 FSPZ6CUGGj5imp9pAu7C+xESBMY4z0k5htK/h5vlSB9X/i3JbXI8KBOioH1QYenMfrvTISmk/+5A BHsMDOpK7//bX66DP+iopoIiWJktY+dfiak7uTZhuYEOmICq4QlP9dDqdPiQGje4Y8xZ45YL6+2I m5GIzuIac/r51YTBuCk+TxTZIITMx+Fr50Ur6s4dOnvApxMR7iZX6oKnmVfXrjFMMQxR1TN5ISUn IoMyID3yCiInqQh6G3WPCAhwa/qG/moxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYD VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExM IENBLTECChVM3JYAAAAAIh8wCQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTEwMzA2MjE0MjQ3WjAjBgkqhkiG9w0BCQQxFgQU0SSJpdwhbihQ jO7xJAcT7pfy0gIwbgYJKwYBBAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xAgoV Tl7RAAAAACIgMHAGCyqGSIb3DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xAgoV Tl7RAAAAACIgMA0GCSqGSIb3DQEBAQUABIIBAH+BE96MNZQ4VXFkawVSWlDOiLkhR9j80eLhatvA 4JSy7MR9ZHrLyCQluToV0AnpPCPo1v7cmKl3k8NY6uPKjZ/0oxh0GX90Hi+uvElPmp9M9+4cRQPk pnZPyysfn5HK5ZBWxN+E+UXegHq+4t5VSwsR1GjxW43ZkSn5diWzwWbbtmTpYNEq3FJ1qw3yI7zn mc4SD2fHfsDviuaxg68859x+8YfwwSPaoH2gbUs4cFJSvL68UZFbxZVLM6Y5RUgWtxBCKBJhz4iH IrbpeR0d4ObmP9w3GIgTuzV1J7dTuLdISg1h28T7rfVUGTwD0l9rHekfvvKMdn8f4i30lQm0tLgA AAAAAAA= --Apple-Mail-112--981979745-- From prvs=204623e733=jherzog@ll.mit.edu Sun Mar 6 13:42:15 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB0E23A6864; Sun, 6 Mar 2011 13:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.847 X-Spam-Level: X-Spam-Status: No, score=-5.847 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5J8Up4W9oiq; Sun, 6 Mar 2011 13:42:14 -0800 (PST) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by core3.amsl.com (Postfix) with ESMTP id 5EAF43A687B; Sun, 6 Mar 2011 13:42:14 -0800 (PST) Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id p26LhJpZ031977; Sun, 6 Mar 2011 16:43:20 -0500 From: "Herzog, Jonathan - 0668 - MITLL" To: Brian Weis Date: Sun, 6 Mar 2011 16:43:19 -0500 Thread-Topic: Secdir review of draft-herzog-static-ecdh-05 Thread-Index: AcvcR4Jw3Q5Fg9pVRIaH7ergG1Dcag== Message-ID: <552BBAA9-712F-49B4-8A5F-C671C3817C05@ll.mit.edu> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-110--986904504"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-06_04:2011-03-04, 2011-03-06, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=8 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1012030000 definitions=main-1103060102 X-Mailman-Approved-At: Tue, 08 Mar 2011 08:18:12 -0800 Cc: "draft-herzog-static-ecdh@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2011 21:42:15 -0000 --Apple-Mail-110--986904504 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 3, 2011, at 1:39 AM, Brian Weis wrote: > I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG.=20= I plan to address these comments and submit a new draft in the next few = days. Before I do, however, do you mind if I asked you a few questions? > 1. The Abstract and Introduction use the term "static-static" Elliptic = Curve Diffie-Hellman key-agreement, which is a term not in common use. I = guessed correctly that it meant the case where both participants in the = key agreement were using static DH values, but I think until the term is = define (later on in the Introduction) it would be clearer to say = something like "Elliptic Curve Diffie-Hellman key-agreement where both = participants use static Diffie-Hellman values". Good catch. I have included your suggestion in both the abstract: "This document describes how to use 'static-static' Elliptic Curve Diffie-Hellman key-agreement (i.e., Elliptic Curve Diffie-Hellman where both participants use static Diffie-Hellman values) with the Cryptographic Message Syntax." and the introduction: "This document describes how to use the static-static Elliptic-Curve Diffie-Hellman key agreement scheme (i.e., Elliptic Curve Diffie- Hellman [SEC1] where both participants use static Diffie-Hellman values) in the Cryptographic Message Syntax (CMS) [CMS]." And the rest of the introduction remains the same. Do you think this = will be enough to orient the reader correctly? > 2. Reference [SEC1] is heavily referenced in this document, for both a = definition of ECDH and specific methods for using ECDH. But it would be = good to also mention RFC 6090, which is the best IETF document = describing ECDH. I was not previous aware of this RFC-- my bad. I have added it as an = informative reference, but continued to refer to [Sec1] as the normative = reference for the ECDH operation. Or do you think that RFC 6090 should = be the normative reference? > 3. Generally, when two parties use static DH values over different = exchanges they will use the same key for each exchange, which is = generally not a good practice. I believe this is true for ECDH as well. = Sections 2.2 and 2.3 mention "SharedInfo", which when used appropriately = will permute the shared key such that the sessions are not keyed = identically. But I believe the use of "SharedInfo" is optional, so I was = expecting the Security Considerations to describe this scenario and at = least say that "SharedInfo" SHOULD be used (or possibly MUST be used). = It would be good to add this discussion to Security Considerations. I'm not sure what you mean, here. Do you mean the SharedInfo value, or = the ukm value? According to RFC 3278, the SharedInfo value is the DER = encoding of the ECC-CMS-SharedInfo value: ECC-CMS-SharedInfo ::=3D SEQUENCE { keyInfo AlgorithmIdentifier, entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL, suppPubInfo [2] EXPLICIT OCTET STRING } Also according to that RFC: entityUInfo optionally contains additional keying material supplied by the sending agent. When used with ECDH and CMS, the entityUInfo field contains the octet string ukm. So, my read of the RFC is that ECDH in CMS will always use a SharedInfo = value to derive keys, and this value will contain a per-message unique = value if and only if the ukm field was used by the sender. Now, the ukm = value *is* optional, according to RFC 5652, which is why our Draft says = they SHOULD be used: Section 2.1: o ukm MAY be present or absent. However, message originators SHOULD include the ukm. As specified in [CMS], implementations MUST support ukm message recipient processing, so interoperability is not a concern if the ukm is present or absent. The use of a fresh value for ukm will ensure that a different key is generated for each message between the same sender and receiver. ukm, if present, is placed in the entityUInfo field of the ECC-CMS- SharedInfo structure [CMS-ECC] and therefore used as an input to the key derivation function. Security Considerations: Extreme care must be used when using static-static Diffie-Hellman (either standard or cofactor) without the use of some per-message value in ukm. If no message-specific information is used (such as a counter value, or a fresh random string) then the resulting secret key could be used in more than one message. Under some circumstances, this will open the sender to the 'small subgroup' attack [MenezesUstaoglu] or other, yet-undiscovered attacks on re- used Diffie-Hellman keys. Applications that cannot tolerate the inclusion of per-message information in ukm (due to bandwidth requirements, for example) SHOULD NOT use static-static ECDH for a recipient without ascertaining that the recipient knows the private value associated with their certified Diffie-Hellman value. =20 So I'm under the impression that our Draft requires a ukm value (with a = SHOULD), and that RFC 3278 requires that this ukm value be included in a = SharedInfor value which is used to derive keys. But did I misread RFC = 3278? Do I need to explicitly require that the SharedInfo value be used? Thanks. --=20 Jonathan Herzog voice: = (781) 981-2356 Technical Staff fax: = (781) 981-7687 Cyber Systems and Technology Group email: = jherzog@ll.mit.edu MIT Lincoln Laboratory www: = http://www.ll.mit.edu/CST/ 244 Wood Street =20 Lexington, MA 02420-9185 --Apple-Mail-110--986904504 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJrzCCBNIw ggO6oAMCAQICChVM3JYAAAAAIh8wDQYJKoZIhvcNAQEFBQAwUTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwg Q0EtMTAeFw0xMDA1MjUyMDQ1MzhaFw0xMTA1MjUyMDQ1MzhaMGQxCzAJBgNVBAYTAlVTMR8wHQYD VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQZW9wbGUxIzAhBgNVBAMTGkhl cnpvZy5Kb25hdGhhbi5DLjUwMDExMzA1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 93mr5a6zq6EQsVtIX9BadxwzpjabF8pvDmoMSP/ZhbWrncNJ1j7xiBGcihYqsDaQz9+hJITxi7IM NUx5fnFtOQRHZgkOCLR1URFc0AlJ3Pknv6XoQ4fqPODmSMB882c9l/8AbO7N/27r8n/V0Ip4Rpw8 1qnrDXk6UH/1zHlssGmlVng0RSREuQy98xPxzbLr5cOMWLwHs5OLNYcGv0KlD6rp1DPzJ3qplU/+ 0P2jyYbGyXStJ/h+3Kx5mOWFLB4j8HDyLG90ZHlZjZXo9FrSoFubVJK/mdVzIuXd00Ldl1fCyxhR D9elkpTc7xOLJsEzCCi8Gqo6eQuvz1RH93u3PwIDAQABo4IBlzCCAZMwDgYDVR0PAQH/BAQDAgbA MB0GA1UdDgQWBBRPjG6+CxR6H/o9vyq5PgmW9vmuajAfBgNVHSMEGDAWgBSUWsZYybYmm6AJe6gv ZJDDiQJuKjAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xM Q0ExMGIGCCsGAQUFBwEBBFYwVDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dHRvL0xMQ0ExMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5sbC5taXQuZWR1LzAMBgNVHRMBAf8E AjAAMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH /4pzAgFkAgEFMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8w DQYLKoZIhvcSAgEDAQgwHQYDVR0RBBYwFIESamhlcnpvZ0BsbC5taXQuZWR1MA0GCSqGSIb3DQEB BQUAA4IBAQBI6aoe1c6Glzs3Hh/lIzf2TzmtZSQLl8UZaIFGi0zG0EjsO6wjX6bfv/WizE30OEef 6So76p0dNt7j21lrH+FGaH6r41ggikbkoazNkAePsQk0WPZhmpus1rByNUozK4KMPpzLAynHNd5m POtqoIwDiTEgktLuZ1nwU7bUHmv7BO14dkhLhMOFKRCIi3vqe9rDh9pTYt1YNhQe1fBme6Y5DWLA TxBBqErz05e7rVngKi6yk6j7cqWpiM6L93z2Zq5p9FqACsJHmMwxH/8XFeeXgFf/CKMAIuSZCGFU 29ouEZWL7LLu87SFGm3f/3sLS7xgXei7d/PlXte1HKKdKOCPMIIE1TCCA72gAwIBAgIKFU5e0QAA AAAiIDANBgkqhkiG9w0BAQUFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4g TGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xMB4XDTEwMDUyNTIw NDcxN1oXDTExMDUyNTIwNDcxN1owZDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xu IExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEjMCEGA1UEAxMaSGVyem9nLkpvbmF0aGFuLkMu NTAwMTEzMDUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtC8sNdkCteQagOVEnQQs4 5uLqsmaOfjqTywNWuvaVj0F8Jsek8bOcuK4rlB1PrBk0Q+s/N4FVcGEn6BEDWRIDFaETVr1jweTE yRUtqngTIvpbpeixV37BcFkVnbV2VrZC5oaa0c0bkxXkuE0lohQS5AIBXQRADEJVnfXIM44yvsmo T7J5rdGwjIg4QJ2YA07po0JkbndcylcjU0zW2Lv432MEZrX/o+T0rraFAhT8A+8De9CIo0LJkXCK cNwk6LwuNKQS0qeezDo5wRiqZaht3ftiAuOImOxN44hxnDa2cHVbOFQ+pevN08gH7d39CVHUbHMC PnuIBoQNu61I2+ItAgMBAAGjggGaMIIBljAOBgNVHQ8BAf8EBAMCBSAwHQYDVR0OBBYEFEuYUJcI JTs8b2SWTJN28DD/qqsNMB8GA1UdIwQYMBaAFJRaxljJtiaboAl7qC9kkMOJAm4qMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTEwYgYIKwYBBQUHAQEE VjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTEwIwYIKwYB BQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUH BDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0l BB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMB CDAdBgNVHREEFjAUgRJqaGVyem9nQGxsLm1pdC5lZHUwDQYJKoZIhvcNAQEFBQADggEBAAmf5m3W 0Di4aQhLS1e2xejG3MQPQJvWL3dHbnHYG+NDVFWcuqyE5t73eb7nV2UyGRVHDt6MyIquedAPPm86 FSPZ6CUGGj5imp9pAu7C+xESBMY4z0k5htK/h5vlSB9X/i3JbXI8KBOioH1QYenMfrvTISmk/+5A BHsMDOpK7//bX66DP+iopoIiWJktY+dfiak7uTZhuYEOmICq4QlP9dDqdPiQGje4Y8xZ45YL6+2I m5GIzuIac/r51YTBuCk+TxTZIITMx+Fr50Ur6s4dOnvApxMR7iZX6oKnmVfXrjFMMQxR1TN5ISUn IoMyID3yCiInqQh6G3WPCAhwa/qG/moxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYD VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExM IENBLTECChVM3JYAAAAAIh8wCQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTEwMzA2MjAyMDQzWjAjBgkqhkiG9w0BCQQxFgQU7R+otGDxVDLw U4n8QjYAaul59G0wbgYJKwYBBAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xAgoV Tl7RAAAAACIgMHAGCyqGSIb3DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xAgoV Tl7RAAAAACIgMA0GCSqGSIb3DQEBAQUABIIBAHhXEaQ9g1uKrZ3bUHMTuuwW8Nzus2Zr7mz3/4L4 OfIL768UNaEu6pfOoAtFQSBl5Jr+m6umoWNdWDi22A/fzIM941wcratvFPWVPw/Xdd3XbyCA6vAs gxmjrCuEN9YrVzwYg1Wi6EBhKiLOodlCke+iePGY1fLJswQI6FdSIaGPmVG/cok7qqysLQ4HBOSj bdBLSikEI6/rsih8PwRI916g7MoVQUTw2Zmt5xbriT4qZ4rp9UjsrGXqkVdimBtAT2IS2zB5vHTF 20OX6I61+EXDxyqL8TocpTsM76Ug0sfIoRFqOslRsvq4l5OjT7dLuCkQM3Zpql+riP3NdflxUMgA AAAAAAA= --Apple-Mail-110--986904504-- From prvs=20488723d3=jherzog@ll.mit.edu Tue Mar 8 08:08:55 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FB253A6936; Tue, 8 Mar 2011 08:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.847 X-Spam-Level: X-Spam-Status: No, score=-5.847 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aoi2Lmoco07G; Tue, 8 Mar 2011 08:08:54 -0800 (PST) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by core3.amsl.com (Postfix) with ESMTP id A72A33A6933; Tue, 8 Mar 2011 08:08:53 -0800 (PST) Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id p28GA53Y029092; Tue, 8 Mar 2011 11:10:05 -0500 From: "Herzog, Jonathan - 0668 - MITLL" To: Brian Weis Date: Tue, 8 Mar 2011 11:10:05 -0500 Thread-Topic: Secdir review of draft-herzog-static-ecdh-05 Thread-Index: Acvdq0nTW9g/1+l8QpWWcECA90OY7Q== Message-ID: <47CF9528-81A1-49D7-8D4B-B1DCC136581E@ll.mit.edu> References: <552BBAA9-712F-49B4-8A5F-C671C3817C05@ll.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-128--829141881"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-08_06:2011-03-08, 2011-03-08, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=8 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1012030000 definitions=main-1103080076 X-Mailman-Approved-At: Tue, 08 Mar 2011 08:18:12 -0800 Cc: "draft-herzog-static-ecdh@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 16:08:55 -0000 --Apple-Mail-128--829141881 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 8, 2011, at 12:15 AM, Brian Weis wrote: > Hi Jonathan, >=20 > On Mar 6, 2011, at 1:43 PM, Herzog, Jonathan - 0668 - MITLL wrote: >>=20 >> I plan to address these comments and submit a new draft in the next = few days. Before I do, however, do you mind if I asked you a few = questions? [snip] >>=20 >> And the rest of the introduction remains the same. Do you think this = will be enough to orient the reader correctly? >=20 > That'll do the trick nicely, I think. Excellent. Thanks. >>=20 >>> 2. Reference [SEC1] is heavily referenced in this document, for both = a definition of ECDH and specific methods for using ECDH. But it would = be good to also mention RFC 6090, which is the best IETF document = describing ECDH. >>=20 >> I was not previous aware of this RFC-- my bad. I have added it as an = informative reference, but continued to refer to [Sec1] as the normative = reference for the ECDH operation. Or do you think that RFC 6090 should = be the normative reference? >=20 > I would suggesting using RFC 6090 for a normative reference to ECDH if = you need such a reference. But I don't believe RFC 6090 discusses = static-static consideration or issues at all, so for that [Sec1] seems = to be the appropriate normative reference. I'm a little uneasy with using RFC 6090 as a normative reference for = ECDH, as my impression is that the rest of CMS uses SEC1 as the = normative reference. (See RFC 5753.) This may be because RFC 6090 is so = new, but I'm worried that switching to RFC 6090 as the normative = reference for ECDH will introduce subtle incompatibilities. Also, RFC 6090 doesn't seem to include the cofactor ECDH operation (I = think), or the use of the SharedInfo/ukm value. Given this, do you mind if I keep SEC1 as normative and use RFC 6090 as = informative? [snip] >> So I'm under the impression that our Draft requires a ukm value (with = a SHOULD), and that RFC 3278 requires that this ukm value be included in = a SharedInfor value which is used to derive keys. But did I misread RFC = 3278? >=20 > I did notice the text regarding ukm in your I-D, but definitely missed = linkage you quote from RFC 3278 above. So rather than misreading RFC = 3278 you've clarified it for me. :-) Your explanation makes sense to me. Ah, good. >> Do I need to explicitly require that the SharedInfo value be used? >=20 > I think your requirements are fine. But because you discuss both ukm = and SharedInfo, I would clarifying their linkage. For example, in your = Security Considerations you could mention the role of SharedInfo to = permute the session so that two sessions setup between the same entities = will be keyed independently, point out that CMS specifies that ukm is to = be the value used in SharedInfo, and how ukm is determined so that it = will properly do its job. This is also rationale for the SHOULD in = section 2.1. Good point. What do you think of the following change? WAS Extreme care must be used when using static-static Diffie-Hellman (either standard or cofactor) without the use of some per-message value in ukm. If no message-specific information is used (such as a counter value, or a fresh random string) then the resulting secret key could be used in more than one message. Under some circumstances, this will open the sender to the 'small subgroup' attack [MenezesUstaoglu] or other, yet-undiscovered attacks on re- used Diffie-Hellman keys. Applications that cannot tolerate the inclusion of per-message information in ukm (due to bandwidth requirements, for example) SHOULD NOT use static-static ECDH for a recipient without ascertaining that the recipient knows the private value associated with their certified Diffie-Hellman value.=20 IS NOW Extreme care must be used when using static-static Diffie-Hellman (either standard or cofactor) without the use of some per-message value in ukm. As described in [RFC5753], the ukm value (if present) will be embedded in a ECC-CMS-SharedInfo structure and the DER- encoding of this structure will be used as the 'SharedInfo' input to the ECDH key-agreement operation in [SEC1], Section 6.1.3. The purpose of this input is to add a message-unique value to the key- distribution function so that two different sessions of static-static ECDH between a given pair of agents result in independent keys. If the ukm value is not used or is re-used, on the other hand, then the ECC-CMS-SharedInfo structure (and 'SharedInfo' input) will likely not vary from message to message. In this case, the two agents will re- use the same keying material across multiple messages. This is considered to be bad cryptographic practice and may open the sender to attacks on Diffie-Hellman (e.g., the 'small subgroup' attack [MenezesUstaoglu] or other, yet-undiscovered attacks). It is for these reasons that Section 2.1 states that message-senders SHOULD include the ukm and SHOULD ensure that the value of ukm is unique to the message being sent. One way to ensure the uniqueness of ukm is for the message sender to choose a 'sufficiently long' random string for each message (where, as a rule of thumb, a 'sufficiently long' string is one at least as long as the keys used by the key-wrap algorithm identified in the keyEncryptionAlgorithm field of the KeyAgreeRecipientInfo structure). However, other methods (such as a counter) are possible. Also, applications which cannot tolerate the inclusion of per-message information in ukm (due to bandwidth requirements, for example) SHOULD NOT use static-static ECDH for a recipient without ascertaining that the recipient knows the private value associated with their certified Diffie-Hellman value. > BTW, the RFC Index search engine says that RFC 3278 has been obsoleted = by RFC 5753. You should reference that one (which hopefully makes the = same statements regarding ukm). Whoops! Good catch. Fortunately, the draft already did reference RFC = 5753. My brain, on the other hand, seem to be taking longer to catch up. = ;-) Thanks. --=20 Jonathan Herzog voice: = (781) 981-2356 Technical Staff fax: = (781) 981-7687 Cyber Systems and Technology Group email: = jherzog@ll.mit.edu MIT Lincoln Laboratory www: = http://www.ll.mit.edu/CST/ 244 Wood Street =20 Lexington, MA 02420-9185 --Apple-Mail-128--829141881 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJrzCCBNIw ggO6oAMCAQICChVM3JYAAAAAIh8wDQYJKoZIhvcNAQEFBQAwUTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwg Q0EtMTAeFw0xMDA1MjUyMDQ1MzhaFw0xMTA1MjUyMDQ1MzhaMGQxCzAJBgNVBAYTAlVTMR8wHQYD VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQZW9wbGUxIzAhBgNVBAMTGkhl cnpvZy5Kb25hdGhhbi5DLjUwMDExMzA1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 93mr5a6zq6EQsVtIX9BadxwzpjabF8pvDmoMSP/ZhbWrncNJ1j7xiBGcihYqsDaQz9+hJITxi7IM NUx5fnFtOQRHZgkOCLR1URFc0AlJ3Pknv6XoQ4fqPODmSMB882c9l/8AbO7N/27r8n/V0Ip4Rpw8 1qnrDXk6UH/1zHlssGmlVng0RSREuQy98xPxzbLr5cOMWLwHs5OLNYcGv0KlD6rp1DPzJ3qplU/+ 0P2jyYbGyXStJ/h+3Kx5mOWFLB4j8HDyLG90ZHlZjZXo9FrSoFubVJK/mdVzIuXd00Ldl1fCyxhR D9elkpTc7xOLJsEzCCi8Gqo6eQuvz1RH93u3PwIDAQABo4IBlzCCAZMwDgYDVR0PAQH/BAQDAgbA MB0GA1UdDgQWBBRPjG6+CxR6H/o9vyq5PgmW9vmuajAfBgNVHSMEGDAWgBSUWsZYybYmm6AJe6gv ZJDDiQJuKjAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xM Q0ExMGIGCCsGAQUFBwEBBFYwVDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dHRvL0xMQ0ExMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5sbC5taXQuZWR1LzAMBgNVHRMBAf8E AjAAMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH /4pzAgFkAgEFMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8w DQYLKoZIhvcSAgEDAQgwHQYDVR0RBBYwFIESamhlcnpvZ0BsbC5taXQuZWR1MA0GCSqGSIb3DQEB BQUAA4IBAQBI6aoe1c6Glzs3Hh/lIzf2TzmtZSQLl8UZaIFGi0zG0EjsO6wjX6bfv/WizE30OEef 6So76p0dNt7j21lrH+FGaH6r41ggikbkoazNkAePsQk0WPZhmpus1rByNUozK4KMPpzLAynHNd5m POtqoIwDiTEgktLuZ1nwU7bUHmv7BO14dkhLhMOFKRCIi3vqe9rDh9pTYt1YNhQe1fBme6Y5DWLA TxBBqErz05e7rVngKi6yk6j7cqWpiM6L93z2Zq5p9FqACsJHmMwxH/8XFeeXgFf/CKMAIuSZCGFU 29ouEZWL7LLu87SFGm3f/3sLS7xgXei7d/PlXte1HKKdKOCPMIIE1TCCA72gAwIBAgIKFU5e0QAA AAAiIDANBgkqhkiG9w0BAQUFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4g TGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xMB4XDTEwMDUyNTIw NDcxN1oXDTExMDUyNTIwNDcxN1owZDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xu IExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEjMCEGA1UEAxMaSGVyem9nLkpvbmF0aGFuLkMu NTAwMTEzMDUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtC8sNdkCteQagOVEnQQs4 5uLqsmaOfjqTywNWuvaVj0F8Jsek8bOcuK4rlB1PrBk0Q+s/N4FVcGEn6BEDWRIDFaETVr1jweTE yRUtqngTIvpbpeixV37BcFkVnbV2VrZC5oaa0c0bkxXkuE0lohQS5AIBXQRADEJVnfXIM44yvsmo T7J5rdGwjIg4QJ2YA07po0JkbndcylcjU0zW2Lv432MEZrX/o+T0rraFAhT8A+8De9CIo0LJkXCK cNwk6LwuNKQS0qeezDo5wRiqZaht3ftiAuOImOxN44hxnDa2cHVbOFQ+pevN08gH7d39CVHUbHMC PnuIBoQNu61I2+ItAgMBAAGjggGaMIIBljAOBgNVHQ8BAf8EBAMCBSAwHQYDVR0OBBYEFEuYUJcI JTs8b2SWTJN28DD/qqsNMB8GA1UdIwQYMBaAFJRaxljJtiaboAl7qC9kkMOJAm4qMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTEwYgYIKwYBBQUHAQEE VjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTEwIwYIKwYB BQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUH BDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0l BB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMB CDAdBgNVHREEFjAUgRJqaGVyem9nQGxsLm1pdC5lZHUwDQYJKoZIhvcNAQEFBQADggEBAAmf5m3W 0Di4aQhLS1e2xejG3MQPQJvWL3dHbnHYG+NDVFWcuqyE5t73eb7nV2UyGRVHDt6MyIquedAPPm86 FSPZ6CUGGj5imp9pAu7C+xESBMY4z0k5htK/h5vlSB9X/i3JbXI8KBOioH1QYenMfrvTISmk/+5A BHsMDOpK7//bX66DP+iopoIiWJktY+dfiak7uTZhuYEOmICq4QlP9dDqdPiQGje4Y8xZ45YL6+2I m5GIzuIac/r51YTBuCk+TxTZIITMx+Fr50Ur6s4dOnvApxMR7iZX6oKnmVfXrjFMMQxR1TN5ISUn IoMyID3yCiInqQh6G3WPCAhwa/qG/moxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYD VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExM IENBLTECChVM3JYAAAAAIh8wCQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTEwMzA4MTYxMDA1WjAjBgkqhkiG9w0BCQQxFgQUlMFJ9rbktx/h WcTG4Azcp49LQ3UwbgYJKwYBBAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xAgoV Tl7RAAAAACIgMHAGCyqGSIb3DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xAgoV Tl7RAAAAACIgMA0GCSqGSIb3DQEBAQUABIIBAAaQlfAnrZxAvHOXMoFPekWPoM57tTb842zg68ms PnJDv42ut1sZZCs+PbiT3DWPDxxAdcsyDQujqSRDCZiqXSUNNciJDh6yX05AlxK2JKRNLrUi9hlK wsR73abpVVPtd9/30YKlJ80ndQlmzQzth3KwpCncJdDfPJTCKv0xVq4N054CG8YD1V1rewf/9IF9 uc0gGbgmmw/LQAM00XhERECxiAzjagXhERi2khxDGeqYgQsVQLZblPNoFBDMHpwsbVtd+tptMvDF pLzhDp5h6z4eA7RwVZml6ttIP7jJS09GlF0lG+QQwL1Y2abME+7czFma5EqtA3InU6Ybt0Q0aPkA AAAAAAA= --Apple-Mail-128--829141881-- From bew@cisco.com Tue Mar 8 09:12:12 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCF803A6906; Tue, 8 Mar 2011 09:12:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.848 X-Spam-Level: X-Spam-Status: No, score=-109.848 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_OBFU_ALL=0.751, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TApMZ-2GgiMV; Tue, 8 Mar 2011 09:12:11 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 87A323A68C5; Tue, 8 Mar 2011 09:12:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=6711; q=dns/txt; s=iport; t=1299604406; x=1300814006; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=NelAVHGDKta/at5DrJUsE5ig0mpEbdhPsbFkxPJ8/kM=; b=FHG6cxOXM9bm4yYIDCi3sxzOff6M89NZj5H6WH3fDzl43Ot8x/0E1bZ/ gb+8pdOW3FVad6F82sDFIzPmAzh/qEAYhUwtYQS4I9omBwxYmF6T6qM8q qxFWWRbbWZBC6d1RPgk6uQy2pd47+cBcXtK41N+iBE5aMtG5FHHESYfni k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKbydU2rRN+K/2dsb2JhbACmT3Sjd5w3gxiCSwSFHYcVjCM X-IronPort-AV: E=Sophos;i="4.62,285,1297036800"; d="scan'208";a="272604843" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 08 Mar 2011 17:13:26 +0000 Received: from stealth-10-32-244-213.cisco.com (stealth-10-32-244-213.cisco.com [10.32.244.213]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p28HDQRe020098; Tue, 8 Mar 2011 17:13:26 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Brian Weis In-Reply-To: <47CF9528-81A1-49D7-8D4B-B1DCC136581E@ll.mit.edu> Date: Tue, 8 Mar 2011 09:13:26 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3E69AF7B-D325-4FC5-A003-FEBA1997D67E@cisco.com> References: <552BBAA9-712F-49B4-8A5F-C671C3817C05@ll.mit.edu> <47CF9528-81A1-49D7-8D4B-B1DCC136581E@ll.mit.edu> To: "Herzog, Jonathan - 0668 - MITLL" X-Mailer: Apple Mail (2.1082) Cc: "draft-herzog-static-ecdh@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 17:12:13 -0000 Hi Jonathan, On Mar 8, 2011, at 8:10 AM, Herzog, Jonathan - 0668 - MITLL wrote: >=20 > On Mar 8, 2011, at 12:15 AM, Brian Weis wrote: >=20 >> Hi Jonathan, >>=20 >> On Mar 6, 2011, at 1:43 PM, Herzog, Jonathan - 0668 - MITLL wrote: >>>=20 >>> I plan to address these comments and submit a new draft in the next = few days. Before I do, however, do you mind if I asked you a few = questions? >=20 >=20 > [snip] >=20 >=20 >>>=20 >>> And the rest of the introduction remains the same. Do you think this = will be enough to orient the reader correctly? >>=20 >> That'll do the trick nicely, I think. >=20 > Excellent. Thanks. >=20 >=20 >=20 >>>=20 >>>> 2. Reference [SEC1] is heavily referenced in this document, for = both a definition of ECDH and specific methods for using ECDH. But it = would be good to also mention RFC 6090, which is the best IETF document = describing ECDH. >>>=20 >>> I was not previous aware of this RFC-- my bad. I have added it as an = informative reference, but continued to refer to [Sec1] as the normative = reference for the ECDH operation. Or do you think that RFC 6090 should = be the normative reference? >>=20 >> I would suggesting using RFC 6090 for a normative reference to ECDH = if you need such a reference. But I don't believe RFC 6090 discusses = static-static consideration or issues at all, so for that [Sec1] seems = to be the appropriate normative reference. >=20 > I'm a little uneasy with using RFC 6090 as a normative reference for = ECDH, as my impression is that the rest of CMS uses SEC1 as the = normative reference. (See RFC 5753.) This may be because RFC 6090 is so = new, but I'm worried that switching to RFC 6090 as the normative = reference for ECDH will introduce subtle incompatibilities. >=20 > Also, RFC 6090 doesn't seem to include the cofactor ECDH operation (I = think), or the use of the SharedInfo/ukm value. >=20 > Given this, do you mind if I keep SEC1 as normative and use RFC 6090 = as informative? Sure, that's fine. [snip] >=20 >>> Do I need to explicitly require that the SharedInfo value be used? >>=20 >> I think your requirements are fine. But because you discuss both ukm = and SharedInfo, I would clarifying their linkage. For example, in your = Security Considerations you could mention the role of SharedInfo to = permute the session so that two sessions setup between the same entities = will be keyed independently, point out that CMS specifies that ukm is to = be the value used in SharedInfo, and how ukm is determined so that it = will properly do its job. This is also rationale for the SHOULD in = section 2.1. >=20 > Good point. What do you think of the following change? Bingo! That explanation seems both complete and clear to me. With that = inclusion, I think its ready to publish. Thanks, Brian >=20 > WAS >=20 >=20 > Extreme care must be used when using static-static Diffie-Hellman > (either standard or cofactor) without the use of some per-message > value in ukm. If no message-specific information is used (such as a > counter value, or a fresh random string) then the resulting secret > key could be used in more than one message. Under some > circumstances, this will open the sender to the 'small subgroup' > attack [MenezesUstaoglu] or other, yet-undiscovered attacks on re- > used Diffie-Hellman keys. Applications that cannot tolerate the > inclusion of per-message information in ukm (due to bandwidth > requirements, for example) SHOULD NOT use static-static ECDH for a > recipient without ascertaining that the recipient knows the private > value associated with their certified Diffie-Hellman value.=20 >=20 > IS NOW >=20 >=20 > Extreme care must be used when using static-static Diffie-Hellman > (either standard or cofactor) without the use of some per-message > value in ukm. As described in [RFC5753], the ukm value (if present) > will be embedded in a ECC-CMS-SharedInfo structure and the DER- > encoding of this structure will be used as the 'SharedInfo' input to > the ECDH key-agreement operation in [SEC1], Section 6.1.3. The > purpose of this input is to add a message-unique value to the key- > distribution function so that two different sessions of = static-static > ECDH between a given pair of agents result in independent keys. If > the ukm value is not used or is re-used, on the other hand, then the > ECC-CMS-SharedInfo structure (and 'SharedInfo' input) will likely = not > vary from message to message. In this case, the two agents will re- > use the same keying material across multiple messages. This is > considered to be bad cryptographic practice and may open the sender > to attacks on Diffie-Hellman (e.g., the 'small subgroup' attack > [MenezesUstaoglu] or other, yet-undiscovered attacks). >=20 > It is for these reasons that Section 2.1 states that message-senders > SHOULD include the ukm and SHOULD ensure that the value of ukm is > unique to the message being sent. One way to ensure the uniqueness > of ukm is for the message sender to choose a 'sufficiently long' > random string for each message (where, as a rule of thumb, a > 'sufficiently long' string is one at least as long as the keys used > by the key-wrap algorithm identified in the keyEncryptionAlgorithm > field of the KeyAgreeRecipientInfo structure). However, other > methods (such as a counter) are possible. Also, applications which > cannot tolerate the inclusion of per-message information in ukm (due > to bandwidth requirements, for example) SHOULD NOT use static-static > ECDH for a recipient without ascertaining that the recipient knows > the private value associated with their certified Diffie-Hellman > value. >=20 >=20 >=20 >> BTW, the RFC Index search engine says that RFC 3278 has been = obsoleted by RFC 5753. You should reference that one (which hopefully = makes the same statements regarding ukm). >=20 > Whoops! Good catch. Fortunately, the draft already did reference RFC = 5753. My brain, on the other hand, seem to be taking longer to catch up. = ;-) >=20 >=20 >=20 > Thanks. >=20 > --=20 > Jonathan Herzog = voice: (781) 981-2356 > Technical Staff = fax: (781) 981-7687 > Cyber Systems and Technology Group email: = jherzog@ll.mit.edu > MIT Lincoln Laboratory www: = http://www.ll.mit.edu/CST/ > 244 Wood Street =20 > Lexington, MA 02420-9185 >=20 --=20 Brian Weis Security Standards and Technology, ARTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From prvs=20488723d3=jherzog@ll.mit.edu Tue Mar 8 09:13:54 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BD533A68C5; Tue, 8 Mar 2011 09:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.847 X-Spam-Level: X-Spam-Status: No, score=-5.847 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id io2cTWNSvIYo; Tue, 8 Mar 2011 09:13:53 -0800 (PST) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by core3.amsl.com (Postfix) with ESMTP id 0824A3A67FB; Tue, 8 Mar 2011 09:13:52 -0800 (PST) Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id p28HF5dw018346; Tue, 8 Mar 2011 12:15:05 -0500 From: "Herzog, Jonathan - 0668 - MITLL" To: Brian Weis Date: Tue, 8 Mar 2011 12:15:04 -0500 Thread-Topic: Secdir review of draft-herzog-static-ecdh-05 Thread-Index: AcvdtF5CBHTlGIs/Sm+A5W/J/CmQvg== Message-ID: <6C54A01F-F793-4CBF-AA1E-CC4D68DB9648@ll.mit.edu> References: <552BBAA9-712F-49B4-8A5F-C671C3817C05@ll.mit.edu> <47CF9528-81A1-49D7-8D4B-B1DCC136581E@ll.mit.edu> <3E69AF7B-D325-4FC5-A003-FEBA1997D67E@cisco.com> In-Reply-To: <3E69AF7B-D325-4FC5-A003-FEBA1997D67E@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-134--825242190"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-08_06:2011-03-08, 2011-03-08, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=8 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1012030000 definitions=main-1103080089 X-Mailman-Approved-At: Wed, 09 Mar 2011 10:13:17 -0800 Cc: "draft-herzog-static-ecdh@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 17:13:54 -0000 --Apple-Mail-134--825242190 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [Snip] > Bingo! That explanation seems both complete and clear to me. With that = inclusion, I think its ready to publish. Great. Thanks so much for your comments. --=20 Jonathan Herzog voice: = (781) 981-2356 Technical Staff fax: = (781) 981-7687 Cyber Systems and Technology Group email: = jherzog@ll.mit.edu MIT Lincoln Laboratory www: = http://www.ll.mit.edu/CST/ 244 Wood Street =20 Lexington, MA 02420-9185 --Apple-Mail-134--825242190 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJrzCCBNIw ggO6oAMCAQICChVM3JYAAAAAIh8wDQYJKoZIhvcNAQEFBQAwUTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwg Q0EtMTAeFw0xMDA1MjUyMDQ1MzhaFw0xMTA1MjUyMDQ1MzhaMGQxCzAJBgNVBAYTAlVTMR8wHQYD VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQZW9wbGUxIzAhBgNVBAMTGkhl cnpvZy5Kb25hdGhhbi5DLjUwMDExMzA1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 93mr5a6zq6EQsVtIX9BadxwzpjabF8pvDmoMSP/ZhbWrncNJ1j7xiBGcihYqsDaQz9+hJITxi7IM NUx5fnFtOQRHZgkOCLR1URFc0AlJ3Pknv6XoQ4fqPODmSMB882c9l/8AbO7N/27r8n/V0Ip4Rpw8 1qnrDXk6UH/1zHlssGmlVng0RSREuQy98xPxzbLr5cOMWLwHs5OLNYcGv0KlD6rp1DPzJ3qplU/+ 0P2jyYbGyXStJ/h+3Kx5mOWFLB4j8HDyLG90ZHlZjZXo9FrSoFubVJK/mdVzIuXd00Ldl1fCyxhR D9elkpTc7xOLJsEzCCi8Gqo6eQuvz1RH93u3PwIDAQABo4IBlzCCAZMwDgYDVR0PAQH/BAQDAgbA MB0GA1UdDgQWBBRPjG6+CxR6H/o9vyq5PgmW9vmuajAfBgNVHSMEGDAWgBSUWsZYybYmm6AJe6gv ZJDDiQJuKjAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xM Q0ExMGIGCCsGAQUFBwEBBFYwVDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dHRvL0xMQ0ExMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5sbC5taXQuZWR1LzAMBgNVHRMBAf8E AjAAMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH /4pzAgFkAgEFMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8w DQYLKoZIhvcSAgEDAQgwHQYDVR0RBBYwFIESamhlcnpvZ0BsbC5taXQuZWR1MA0GCSqGSIb3DQEB BQUAA4IBAQBI6aoe1c6Glzs3Hh/lIzf2TzmtZSQLl8UZaIFGi0zG0EjsO6wjX6bfv/WizE30OEef 6So76p0dNt7j21lrH+FGaH6r41ggikbkoazNkAePsQk0WPZhmpus1rByNUozK4KMPpzLAynHNd5m POtqoIwDiTEgktLuZ1nwU7bUHmv7BO14dkhLhMOFKRCIi3vqe9rDh9pTYt1YNhQe1fBme6Y5DWLA TxBBqErz05e7rVngKi6yk6j7cqWpiM6L93z2Zq5p9FqACsJHmMwxH/8XFeeXgFf/CKMAIuSZCGFU 29ouEZWL7LLu87SFGm3f/3sLS7xgXei7d/PlXte1HKKdKOCPMIIE1TCCA72gAwIBAgIKFU5e0QAA AAAiIDANBgkqhkiG9w0BAQUFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4g TGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xMB4XDTEwMDUyNTIw NDcxN1oXDTExMDUyNTIwNDcxN1owZDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xu IExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEjMCEGA1UEAxMaSGVyem9nLkpvbmF0aGFuLkMu NTAwMTEzMDUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtC8sNdkCteQagOVEnQQs4 5uLqsmaOfjqTywNWuvaVj0F8Jsek8bOcuK4rlB1PrBk0Q+s/N4FVcGEn6BEDWRIDFaETVr1jweTE yRUtqngTIvpbpeixV37BcFkVnbV2VrZC5oaa0c0bkxXkuE0lohQS5AIBXQRADEJVnfXIM44yvsmo T7J5rdGwjIg4QJ2YA07po0JkbndcylcjU0zW2Lv432MEZrX/o+T0rraFAhT8A+8De9CIo0LJkXCK cNwk6LwuNKQS0qeezDo5wRiqZaht3ftiAuOImOxN44hxnDa2cHVbOFQ+pevN08gH7d39CVHUbHMC PnuIBoQNu61I2+ItAgMBAAGjggGaMIIBljAOBgNVHQ8BAf8EBAMCBSAwHQYDVR0OBBYEFEuYUJcI JTs8b2SWTJN28DD/qqsNMB8GA1UdIwQYMBaAFJRaxljJtiaboAl7qC9kkMOJAm4qMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTEwYgYIKwYBBQUHAQEE VjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTEwIwYIKwYB BQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUH BDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0l BB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMB CDAdBgNVHREEFjAUgRJqaGVyem9nQGxsLm1pdC5lZHUwDQYJKoZIhvcNAQEFBQADggEBAAmf5m3W 0Di4aQhLS1e2xejG3MQPQJvWL3dHbnHYG+NDVFWcuqyE5t73eb7nV2UyGRVHDt6MyIquedAPPm86 FSPZ6CUGGj5imp9pAu7C+xESBMY4z0k5htK/h5vlSB9X/i3JbXI8KBOioH1QYenMfrvTISmk/+5A BHsMDOpK7//bX66DP+iopoIiWJktY+dfiak7uTZhuYEOmICq4QlP9dDqdPiQGje4Y8xZ45YL6+2I m5GIzuIac/r51YTBuCk+TxTZIITMx+Fr50Ur6s4dOnvApxMR7iZX6oKnmVfXrjFMMQxR1TN5ISUn IoMyID3yCiInqQh6G3WPCAhwa/qG/moxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYD VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExM IENBLTECChVM3JYAAAAAIh8wCQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTEwMzA4MTcxNTA1WjAjBgkqhkiG9w0BCQQxFgQUdWFPH8w5Efhn zRg3kb3KyLM3PccwbgYJKwYBBAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xAgoV Tl7RAAAAACIgMHAGCyqGSIb3DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xAgoV Tl7RAAAAACIgMA0GCSqGSIb3DQEBAQUABIIBAD7OevS6UZfCnVYV91lIhhaSYvmredIb5XyNim7M +1riWqTcD2P8fEcNtJ2t5laXJ0FIcNEkwjlGndnyeB5PM7187q3smju21apkXfz6g9dU6dYINt6H VTfggSXpiiQag+P7NPslA50udmJCZls4V4YP/Gg1Zlt1i+mYoTUicqp51wLxDILcw1esHZWNGite ck3+CcaHEHQ9wttxqtQl2UOSWGF95E10eOo64ADfpz01C2qCbzjGN78qJqttzLTY5/jKzK+SdrFk kn8R59cQlDFfUD97btncglQ/XI5MWcwFfuiElQn1pfoKw8Ny/bWHxSm8gvSWHGqYJfreizj1+zEA AAAAAAA= --Apple-Mail-134--825242190-- From new-work-bounces@ietf.org Tue Mar 8 09:57:39 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9DE43A6957; Tue, 8 Mar 2011 09:57:39 -0800 (PST) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id C10BE3A6956; Tue, 8 Mar 2011 09:57:38 -0800 (PST) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20110308175738.C10BE3A6956@core3.amsl.com> Date: Tue, 8 Mar 2011 09:57:38 -0800 (PST) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Wed, 09 Mar 2011 10:13:17 -0800 Subject: [secdir] [new-work] WG Review: Verification Involving PSTN Reachability (vipr) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 17:57:39 -0000 A new IETF working group has been proposed in the Real-time Applications and Infrastructure Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, March 15, 2011. Verification Involving PSTN Reachability (vipr) ------------------------------------------------ Current Status: Proposed Working Group Last updated: 2011-02-18 Chair(s): TBD Real-time Applications and Infrastructure Area Director(s): * Gonzalo Camarillo * Robert Sparks Real-time Applications and Infrastructure Area Advisor: * Robert Sparks Mailing Lists: General Discussion: TBD (expected to be vipr@ietf.org) To Subscribe: TBD Archive: TBD Description of Working Group: There are two globally deployed address spaces for communications used by more than a billion people daily - phone numbers and DNS rooted address such as web servers and email addresses. The inter-domain signaling design of SIP is primarily designed for email style addresses yet a large percentage of SIP deployments mostly use phone numbers for identifying users, thus DNS lookups are not sufficient. The goal of this working group is to enable inter-domain communications over the Internet, using protocols such as SIP, while still allowing people to use phone numbers to identify the person with whom they wish to communicate. The VIPR WG will develop a peer to peer based approach to finding domains that claim to be responsible for a given phone number to mitigate the involvement of centralized entities to avoid some of the issues encountered by past attempts to support SIP inter-domain communications. Validation protocols will be developed to ensure a reasonable likelihood that a given domain actually is responsible for the phone number. In this context, "responsible" means an administrative domain, which is at least one of the domains, to which a PSTN call to this phone number would be routed. Once the domain responsible for the phone number is found, existing protocols, such as SIP, can be used for inter-domain communications. Some validation protocols may be based on knowledge gathered around a PSTN call; for example, the ability to prove a call was received over the PSTN based on start and stop times. Other validation schemes, such as examining fingerprints or watermarking of PSTN media to show that a domain received a particular PSTN phone call, may also be considered by the working group. This validation will be accomplished using publicly available open interfaces to the PSTN, so the validation can be performed by any domain wishing to participate. The WG will select and standardize at least one validation scheme. The validation mechanism requires a domain to gather and maintain information related to PSTN calls. This information is used by call agents such as phones, SBCs and IP PBXs to route calls. The WG will also develop mechanisms to detect in a timely manner that a given domain is no longer responsible for a phone number. The WG will define a client-server protocol between these call agents and the entity within a domain that maintains the information. To help mitigate SPAM issues when using SIP between domains, the WG will define a mechanism to enable one domain to check that incoming SIP messages are coming from a validated phone number. A phone number is considered validated if it is coming from a domain to which the calling domain had previously successfully placed a PSTN call. The working group will define new SIP headers and option tags, as necessary, to enable this. The essential characteristic of VIPR is establishing authentication by PSTN reachability when it is not possible to use a direct reference to ENUM databases or other direct assertions of PSTN number ownership. Elements such as public ENUM easily coexist with VIPR but no direct interaction with ENUM will be required. The solution set defined by this WG will be incrementally deployable using only existing interfaces to the PSTN. No changes will be required to existing PSTN capabilities, no new database access is needed nor is any new support from PSTN service providers required. The WG will produce the following deliverables: 1) A document describing the requirements, problem statement and architectural approach to support SIP inter-domain communications. 2) A document describing the use of the p2psip protocol (RELOAD) as applied to this problem space. 3) A document defining a scheme for validating the phone numbers using publicly available open interfaces to the PSTN. 4) A document defining client-server protocol between call agents and the entity within a domain that gathers and maintains information related to PSTN calls. 5) A document describing a mechanism to mitigate SPAM issues. The working group will carefully coordinate with the security area, O&M area, as well as the appropriate RAI WGs such as sipcore and p2psip. Goals and Milestones: Sep 2011 Submit Requirements, Problem statement, and architecture overview for publication as Informational Dec 2011 Submit Peer to peer base protocol specification for publication as Proposed Standard Dec 2011 Submit PSTN based number validation techniques for publication as Proposed Standard Apr 2012 Submit Protocol for call agents to exchange call and routing information for publication as Proposed Standard Apr 2012 Submit Specification of authorization tokens to mitigate SPAM for publication as Proposed Standard _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue Mar 8 10:04:15 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74A8B3A693D; Tue, 8 Mar 2011 10:04:15 -0800 (PST) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id E04273A6928; Tue, 8 Mar 2011 10:04:13 -0800 (PST) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20110308180413.E04273A6928@core3.amsl.com> Date: Tue, 8 Mar 2011 10:04:13 -0800 (PST) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Wed, 09 Mar 2011 10:13:17 -0800 Subject: [secdir] [new-work] WG Review: Address Resolution for Massive numbers of hosts in the Data center (armd) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 18:04:15 -0000 A new IETF working group has been proposed in the Operations and Management Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, March 15, 2011. Address Resolution for Massive numbers of hosts in the Data center (armd) ------------------------------------------------ Current Status: Proposed Working Group Last updated: 2011-02-18 Chairs: TBD Operations and Management Area Directors: Ronald Bonica Dan Romascanu Operations and Management Area Advisor: Ronald Bonica Internet Area Advisor: Ralph Droms Mailing lists: Address: armd@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/armd Archive: http://www.ietf.org/mail-archive/web/armd/ Description of Working Group: Changing workloads in datacenters are having an impact on the performance of current datacenter network designs. For example, the use of virtual machines (VMs) as a means for deployment and management of new services often results in a significant increase in the number of hosts attached to the network. Various requirements for the deployment of VMs in data center networks, such as support for VM mobility, has led to architectures in which broadcast domains are scaling up to span more switching devices and VM servers, and to interconnect more hosts (as represented by VMs). In these deployment architectures, heavily used protocols that are based on broadcast or multicast, such as ARP and ND, may contribute to poor network performance. The armd Working Group will investigate the impact of changing workloads and existing protocols on datacenter network performance. In its work, the armd Working Group will take into consideration work done in data center networking standardization by other SDOs, such as the IEEE 802.1 Data Center Bridging Task Group, and will communicate and exchange information with these organizations. Working Group objectives: (1) Document the current practices in data center network architectures and the scaling characteristics of ARP and ND with respect to large sized layer-2 domains in data centers. (2) Provide operational recommendations intended to minimize issues associated with these architectures and characteristics. Area affiliation of the Working Group: The armd Working Group is assigned to the Operations and Management area, and will maintain close collaboration with the Internet area. Because of its affiliation with Operations and Management, the armd Working Group will focus on documenting current practices and scaling characteristics, and will not do any protocol development or extension work. If the Working Group identifies opportunities for protocol development or extensions, it will first develop requirements for that work. Any protocol development work will be conducted in the appropriate existing Working Groups if such work groups exist. If no such working groups exist, armd may recharter to address the work and may be moved to a different area. Deliverables (Informational RFCs; list to be removed prior to posting): o Problem statement and review of current L2/L3 architectures o Report on ARP/ND statistics collection and behavior analysis in various Data Center environments o Recommendations on data center L2/L3 architectures and identification of opportunities for protocol development work Milestones (Informational RFCs to be completed for IESG review): May 2011 - Problem statement Nov 2011 - ARP/ND statistics collection and behavior analysis in various Data Center environments - many subnets with various sizes - subnets with hosts with VMs and VMs migrate over time - subnets with some hosts on local VMs and others on VMs in the cloud (like Amazon's ECS), - Large subnet. Nov 2011 - Survey of Existing Implementations Nov 2011 - Survey of Security Mar 2012 - Recommendations to avoid or minimize issues caused by ARP/ND Mar 2012 - Gap Analysis _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From mlepinsk@bbn.com Wed Mar 9 05:31:16 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDDE43A69D7; Wed, 9 Mar 2011 05:31:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZwajvKo82qX; Wed, 9 Mar 2011 05:31:15 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id A2C343A696D; Wed, 9 Mar 2011 05:31:15 -0800 (PST) Received: from [128.89.254.106] (port=1477) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PxJV9-000IpN-IL; Wed, 09 Mar 2011 08:32:31 -0500 Message-ID: <4D77818E.4050703@bbn.com> Date: Wed, 09 Mar 2011 08:33:02 -0500 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: draft-ietf-dime-nat-control.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 09 Mar 2011 10:13:17 -0800 Subject: [secdir] SECDIR review of draft-ietf-dime-nat-control-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 13:31:16 -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 defines a Diameter application whereby a Diameter NAT Contr= ol Application (DNCA) server (either a AAA server or a Network Access Ser= ver) can control a DNCA client (either a NAT or NAPT device). For example= , the DNCA server can determine the number of port bindings available to = a given host, cause the allocation of particular NAT bindings, define the= external address pool used for by the NAT device, or generate reports us= ed for accounting purposes. The principle security concern is that an unauthorized (or unauthenticate= d) DNCA server could effect a denial of service of attack on any or all h= osts using a NAT/NAPT device in several ways. (E.g., an unauthorized serv= er could exhaust resources in the NAPT device, set maximum bindings to ze= ro for all hosts, provide a set of external addresses that are in use els= ewhere in the network, etc.) An additional concern is that an unauthentic= ated DNCA client could provide incorrect reporting data to the DNCA serve= r to prevent correct accounting within the system. Therefore, the NAT con= trol application requires mutual authentication, authorization of the DNC= A server, and integrity protection of the Diameter messages in the DNCA i= nteraction. Additionally, the application may require confidentiality dep= ending on the deployment scenario and, particularly, how authorization is= accomplished. The Security Considerations section of the document claims that security = considerations are essentially the same as in the Diameter QoS (RFC 5866)= =2E I agree with the authors that the security concerns for Diameter NAT = Control are very similar to the security concerns for Diameter QoS, but I= think the additional layer of indirection is not helpful to the reader. = (In particular, the NAT Control Application has no dependencies on the Di= ameter QoS document. Therefore it is reasonable to believe that an implem= enter of Diameter NAT Control may not be familiar with the Diameter QoS d= ocument.) I would recommend that the authors add additional text explaini= ng why mutual authentication, server authorization, and message integrity= are required (copying a bit of text from RFC 5866 may be appropriate). T= hen I would recommend that the authors cite the Diameter specification (R= FC 3588) for a discussion of how IPsec or TLS can be used to obtain these= security properties. (To me, this seems preferable to sending a reader t= o RFC 5866 for discussion of required security properties, which in turn = sends the reader to RFC 3588 for an information on the use of IPsec or TL= S to achieve these properties.) Finally, the end of the security considerations section claims that "Auth= orization between DNCA Agent and DNCA Manager is beyond the scope of this document". I understand that= the authors do not want to mandate a particular mechanism for making an = authorization decision. That being said, providing some guidance as to ho= w a DNCA client would determine if a DNCA server were authorized to issue= NAT control commands. I imagine in practice that the way authorization i= s accomplished is that the NAT/NAPT device stores a local authorization p= olicy. (E.g., the device stores a list of server identities that authoriz= ed, and then once the server has been authenticated its identity can be c= hecked against the list). At the very least having text analogous to firs= t paragraph of RFC 5866 Section 11 would be helpful (RFC 5866 says the de= vice making the authorization decision needs to have sufficient informati= on to make this decision and then provides examples of where this informa= tion would come from.) - Matt Lepinski From new-work-bounces@ietf.org Wed Mar 9 07:37:37 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B7473A69D9; Wed, 9 Mar 2011 07:37:37 -0800 (PST) X-Original-To: new-work@core3.amsl.com Delivered-To: new-work@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86E303A695C for ; Wed, 9 Mar 2011 07:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.351 X-Spam-Level: X-Spam-Status: No, score=-10.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6-czs8aTO93 for ; Wed, 9 Mar 2011 07:37:34 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id A93473A68D1 for ; Wed, 9 Mar 2011 07:37:34 -0800 (PST) Received: from localhost ([127.0.0.1] helo=[IPv6:::1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1PxLTO-0004uA-A5; Wed, 09 Mar 2011 10:38:50 -0500 Message-Id: <97016051-36C8-4AB3-8F28-4314BFF12739@w3.org> From: Ian Jacobs To: new-work@ietf.org Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 9 Mar 2011 09:38:49 -0600 X-Mailer: Apple Mail (2.936) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Wed, 09 Mar 2011 10:13:17 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Web Performance Working Group (until 2011-04-06) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 15:37:37 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Rich Web Client Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Web Performance Working Group: http://www.w3.org/2011/02/webperf 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 2011-04-06 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 Philippe Le H=E9garet, Team Contact . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/2006/rwc/Activity [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Ian Jacobs (ij@w3.org) 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 bew@cisco.com Wed Mar 9 10:52:35 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 562A73A6928; Wed, 9 Mar 2011 10:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.848 X-Spam-Level: X-Spam-Status: No, score=-109.848 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_OBFU_ALL=0.751, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYXsIzA-R2NI; Wed, 9 Mar 2011 10:52:34 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 2FF703A680F; Wed, 9 Mar 2011 10:52:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=2579; q=dns/txt; s=iport; t=1299696831; x=1300906431; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=DJS5GD5NprxL3G9pFnIdfVFeo3B+W/gzDiK0v2Fdj3M=; b=l96OKQmoC2avz4oIwLUtEJdheZudqqLkf8k9BqrbWp6aoxuhPIQ52BUD HdvbjGsyqKxHr5zhv5By1qWu6dWJR0tGbIerBZJWmRarVku+pMf4gJu3O ihL9K/PHlTRaOz/Rh6O4hF2CMJI09+n8bh33PPLOvNiuirOAk5xhfEPEZ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAP5bd02rR7Hu/2dsb2JhbACmcHSnM5xRgxiCTQSFIocYjCk X-IronPort-AV: E=Sophos;i="4.62,291,1297036800"; d="scan'208";a="318641062" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 09 Mar 2011 18:53:50 +0000 Received: from dhcp-128-107-111-194.cisco.com (dhcp-128-107-111-194.cisco.com [128.107.111.194]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p29Iro7e018228; Wed, 9 Mar 2011 18:53:50 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Brian Weis In-Reply-To: Date: Wed, 9 Mar 2011 10:53:50 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <552BBAA9-712F-49B4-8A5F-C671C3817C05@ll.mit.edu> <47CF9528-81A1-49D7-8D4B-B1DCC136581E@ll.mit.edu> <3E69AF7B-D325-4FC5-A003-FEBA1997D67E@cisco.com> To: "Herzog, Jonathan - 0668 - MITLL" X-Mailer: Apple Mail (2.1082) Cc: "draft-herzog-static-ecdh@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 18:52:35 -0000 Hi Jonathan, No objections. Thanks, Brian On Mar 9, 2011, at 10:34 AM, Herzog, Jonathan - 0668 - MITLL wrote: >=20 > On Mar 8, 2011, at 12:13 PM, Brian Weis wrote: >=20 >>>>>=20 >>>>>> 2. Reference [SEC1] is heavily referenced in this document, for = both a definition of ECDH and specific methods for using ECDH. But it = would be good to also mention RFC 6090, which is the best IETF document = describing ECDH. >>>>>=20 >>>>> I was not previous aware of this RFC-- my bad. I have added it as = an informative reference, but continued to refer to [Sec1] as the = normative reference for the ECDH operation. Or do you think that RFC = 6090 should be the normative reference? >>>>=20 >>>> I would suggesting using RFC 6090 for a normative reference to ECDH = if you need such a reference. But I don't believe RFC 6090 discusses = static-static consideration or issues at all, so for that [Sec1] seems = to be the appropriate normative reference. >>>=20 >>> I'm a little uneasy with using RFC 6090 as a normative reference for = ECDH, as my impression is that the rest of CMS uses SEC1 as the = normative reference. (See RFC 5753.) This may be because RFC 6090 is so = new, but I'm worried that switching to RFC 6090 as the normative = reference for ECDH will introduce subtle incompatibilities. >>>=20 >>> Also, RFC 6090 doesn't seem to include the cofactor ECDH operation = (I think), or the use of the SharedInfo/ukm value. >>>=20 >>> Given this, do you mind if I keep SEC1 as normative and use RFC 6090 = as informative? >>=20 >> Sure, that's fine. >=20 >=20 > I've thought a little more about this, and change my proposal to: >=20 > * Reference RFC 6090 for ECDH in general, but > * SEC1 for co-factor ECDH, the public-key validation primitives, and = the key-derivation function (KDF). >=20 > Unfortunately, none of those algorithms in the second bullet are = present in RFC 6090. (Though the security considerations of RFC 6090 = discuss why one would want to validate public keys, it doesn't describe = how to do so.) >=20 >=20 > Any objections? >=20 > Thanks. > --=20 > Jonathan Herzog = voice: (781) 981-2356 > Technical Staff = fax: (781) 981-7687 > Cyber Systems and Technology Group email: = jherzog@ll.mit.edu > MIT Lincoln Laboratory www: = http://www.ll.mit.edu/CST/ > 244 Wood Street =20 > Lexington, MA 02420-9185 >=20 --=20 Brian Weis Security Standards and Technology, ARTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From prvs=2049ffe0e7=jherzog@ll.mit.edu Wed Mar 9 10:33:31 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71F093A6A02; Wed, 9 Mar 2011 10:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.847 X-Spam-Level: X-Spam-Status: No, score=-5.847 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmBiCi4pVerC; Wed, 9 Mar 2011 10:33:30 -0800 (PST) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by core3.amsl.com (Postfix) with ESMTP id 3FC353A6933; Wed, 9 Mar 2011 10:33:30 -0800 (PST) Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id p29IYf4t026025; Wed, 9 Mar 2011 13:34:41 -0500 From: "Herzog, Jonathan - 0668 - MITLL" To: Brian Weis Date: Wed, 9 Mar 2011 13:34:40 -0500 Thread-Topic: Secdir review of draft-herzog-static-ecdh-05 Thread-Index: AcveiKcEiqs+K4A7TLSMukbPot0zIw== Message-ID: References: <552BBAA9-712F-49B4-8A5F-C671C3817C05@ll.mit.edu> <47CF9528-81A1-49D7-8D4B-B1DCC136581E@ll.mit.edu> <3E69AF7B-D325-4FC5-A003-FEBA1997D67E@cisco.com> In-Reply-To: <3E69AF7B-D325-4FC5-A003-FEBA1997D67E@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-137--734066668"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-09_07:2011-03-09, 2011-03-09, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=8 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1012030000 definitions=main-1103090118 X-Mailman-Approved-At: Wed, 09 Mar 2011 11:46:48 -0800 Cc: "draft-herzog-static-ecdh@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 18:33:31 -0000 --Apple-Mail-137--734066668 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 8, 2011, at 12:13 PM, Brian Weis wrote: >>>>=20 >>>>> 2. Reference [SEC1] is heavily referenced in this document, for = both a definition of ECDH and specific methods for using ECDH. But it = would be good to also mention RFC 6090, which is the best IETF document = describing ECDH. >>>>=20 >>>> I was not previous aware of this RFC-- my bad. I have added it as = an informative reference, but continued to refer to [Sec1] as the = normative reference for the ECDH operation. Or do you think that RFC = 6090 should be the normative reference? >>>=20 >>> I would suggesting using RFC 6090 for a normative reference to ECDH = if you need such a reference. But I don't believe RFC 6090 discusses = static-static consideration or issues at all, so for that [Sec1] seems = to be the appropriate normative reference. >>=20 >> I'm a little uneasy with using RFC 6090 as a normative reference for = ECDH, as my impression is that the rest of CMS uses SEC1 as the = normative reference. (See RFC 5753.) This may be because RFC 6090 is so = new, but I'm worried that switching to RFC 6090 as the normative = reference for ECDH will introduce subtle incompatibilities. >>=20 >> Also, RFC 6090 doesn't seem to include the cofactor ECDH operation (I = think), or the use of the SharedInfo/ukm value. >>=20 >> Given this, do you mind if I keep SEC1 as normative and use RFC 6090 = as informative? >=20 > Sure, that's fine. I've thought a little more about this, and change my proposal to: * Reference RFC 6090 for ECDH in general, but * SEC1 for co-factor ECDH, the public-key validation primitives, and the = key-derivation function (KDF). Unfortunately, none of those algorithms in the second bullet are present = in RFC 6090. (Though the security considerations of RFC 6090 discuss why = one would want to validate public keys, it doesn't describe how to do = so.) Any objections? Thanks. --=20 Jonathan Herzog voice: = (781) 981-2356 Technical Staff fax: = (781) 981-7687 Cyber Systems and Technology Group email: = jherzog@ll.mit.edu MIT Lincoln Laboratory www: = http://www.ll.mit.edu/CST/ 244 Wood Street =20 Lexington, MA 02420-9185 --Apple-Mail-137--734066668 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJrzCCBNIw ggO6oAMCAQICChVM3JYAAAAAIh8wDQYJKoZIhvcNAQEFBQAwUTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwg Q0EtMTAeFw0xMDA1MjUyMDQ1MzhaFw0xMTA1MjUyMDQ1MzhaMGQxCzAJBgNVBAYTAlVTMR8wHQYD VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQZW9wbGUxIzAhBgNVBAMTGkhl cnpvZy5Kb25hdGhhbi5DLjUwMDExMzA1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 93mr5a6zq6EQsVtIX9BadxwzpjabF8pvDmoMSP/ZhbWrncNJ1j7xiBGcihYqsDaQz9+hJITxi7IM NUx5fnFtOQRHZgkOCLR1URFc0AlJ3Pknv6XoQ4fqPODmSMB882c9l/8AbO7N/27r8n/V0Ip4Rpw8 1qnrDXk6UH/1zHlssGmlVng0RSREuQy98xPxzbLr5cOMWLwHs5OLNYcGv0KlD6rp1DPzJ3qplU/+ 0P2jyYbGyXStJ/h+3Kx5mOWFLB4j8HDyLG90ZHlZjZXo9FrSoFubVJK/mdVzIuXd00Ldl1fCyxhR D9elkpTc7xOLJsEzCCi8Gqo6eQuvz1RH93u3PwIDAQABo4IBlzCCAZMwDgYDVR0PAQH/BAQDAgbA MB0GA1UdDgQWBBRPjG6+CxR6H/o9vyq5PgmW9vmuajAfBgNVHSMEGDAWgBSUWsZYybYmm6AJe6gv ZJDDiQJuKjAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xM Q0ExMGIGCCsGAQUFBwEBBFYwVDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dHRvL0xMQ0ExMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5sbC5taXQuZWR1LzAMBgNVHRMBAf8E AjAAMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH /4pzAgFkAgEFMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8w DQYLKoZIhvcSAgEDAQgwHQYDVR0RBBYwFIESamhlcnpvZ0BsbC5taXQuZWR1MA0GCSqGSIb3DQEB BQUAA4IBAQBI6aoe1c6Glzs3Hh/lIzf2TzmtZSQLl8UZaIFGi0zG0EjsO6wjX6bfv/WizE30OEef 6So76p0dNt7j21lrH+FGaH6r41ggikbkoazNkAePsQk0WPZhmpus1rByNUozK4KMPpzLAynHNd5m POtqoIwDiTEgktLuZ1nwU7bUHmv7BO14dkhLhMOFKRCIi3vqe9rDh9pTYt1YNhQe1fBme6Y5DWLA TxBBqErz05e7rVngKi6yk6j7cqWpiM6L93z2Zq5p9FqACsJHmMwxH/8XFeeXgFf/CKMAIuSZCGFU 29ouEZWL7LLu87SFGm3f/3sLS7xgXei7d/PlXte1HKKdKOCPMIIE1TCCA72gAwIBAgIKFU5e0QAA AAAiIDANBgkqhkiG9w0BAQUFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4g TGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xMB4XDTEwMDUyNTIw NDcxN1oXDTExMDUyNTIwNDcxN1owZDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xu IExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEjMCEGA1UEAxMaSGVyem9nLkpvbmF0aGFuLkMu NTAwMTEzMDUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtC8sNdkCteQagOVEnQQs4 5uLqsmaOfjqTywNWuvaVj0F8Jsek8bOcuK4rlB1PrBk0Q+s/N4FVcGEn6BEDWRIDFaETVr1jweTE yRUtqngTIvpbpeixV37BcFkVnbV2VrZC5oaa0c0bkxXkuE0lohQS5AIBXQRADEJVnfXIM44yvsmo T7J5rdGwjIg4QJ2YA07po0JkbndcylcjU0zW2Lv432MEZrX/o+T0rraFAhT8A+8De9CIo0LJkXCK cNwk6LwuNKQS0qeezDo5wRiqZaht3ftiAuOImOxN44hxnDa2cHVbOFQ+pevN08gH7d39CVHUbHMC PnuIBoQNu61I2+ItAgMBAAGjggGaMIIBljAOBgNVHQ8BAf8EBAMCBSAwHQYDVR0OBBYEFEuYUJcI JTs8b2SWTJN28DD/qqsNMB8GA1UdIwQYMBaAFJRaxljJtiaboAl7qC9kkMOJAm4qMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTEwYgYIKwYBBQUHAQEE VjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTEwIwYIKwYB BQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUH BDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0l BB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMB CDAdBgNVHREEFjAUgRJqaGVyem9nQGxsLm1pdC5lZHUwDQYJKoZIhvcNAQEFBQADggEBAAmf5m3W 0Di4aQhLS1e2xejG3MQPQJvWL3dHbnHYG+NDVFWcuqyE5t73eb7nV2UyGRVHDt6MyIquedAPPm86 FSPZ6CUGGj5imp9pAu7C+xESBMY4z0k5htK/h5vlSB9X/i3JbXI8KBOioH1QYenMfrvTISmk/+5A BHsMDOpK7//bX66DP+iopoIiWJktY+dfiak7uTZhuYEOmICq4QlP9dDqdPiQGje4Y8xZ45YL6+2I m5GIzuIac/r51YTBuCk+TxTZIITMx+Fr50Ur6s4dOnvApxMR7iZX6oKnmVfXrjFMMQxR1TN5ISUn IoMyID3yCiInqQh6G3WPCAhwa/qG/moxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYD VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExM IENBLTECChVM3JYAAAAAIh8wCQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTEwMzA5MTgzNDQwWjAjBgkqhkiG9w0BCQQxFgQUqmPlmXKQbwME KYzPdVSz2FfNVfgwbgYJKwYBBAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xAgoV Tl7RAAAAACIgMHAGCyqGSIb3DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xAgoV Tl7RAAAAACIgMA0GCSqGSIb3DQEBAQUABIIBAL7iw+iSlbeAgerTP1xQF9pDEM8DPfkSaBDMg4cw D2DufKXlkQFWxPRaZImUzUe6ViBSzli/4yROtGpxKmnmUVXD354TOLoTQ4yy818yIuYzVM0bIR/v nMR9TI1PHhaefOIwjkEqZEV1aWfnrsgW1fjK5rG6IeJF+exD6C2XzNBVrFl93VAv3eGjVpnHkP86 85YitKgAqH67pLjmMly0b9ZoRRCXlqU11SXtw+u8qd48AmE01G6jtK7yFjgOmshZgmTMDpJ0Es7h RetYWqmMUXqtDOeIa2RZZdpU+2LSg54IohEen+eTx/rTRPt4j7mGqwLY1xaCcapjBKI2q/tmH+gA AAAAAAA= --Apple-Mail-137--734066668-- From stephen.farrell@cs.tcd.ie Wed Mar 9 12:30:32 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C740F3A6AA8; Wed, 9 Mar 2011 12:30:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=-0.619, BAYES_00=-2.599, SARE_OBFU_ALL=0.751, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6WDkKbNcdgC; Wed, 9 Mar 2011 12:30:31 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id DDB6C3A6969; Wed, 9 Mar 2011 12:30:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 0AE453E4087; Wed, 9 Mar 2011 20:31:45 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1299702704; bh=XU9+hL2VuU6kjP ogG1U1BcGqKTyYRSbOhoeHfgmNvrA=; b=k5uaBkyeE4npTI1mt2/VI3T4/xf6Un Xjg1RV3P1I/K4hQnbAUecbgy6wfn2rTmWLUTz95Znk0qzS/cEUzqbUxIpORI8jt5 pRyQCIRFVtCnpYdiKMm7W4mqYELxvoJ4yGI408Rv6Z56LNKD76tdKv7iukoIG1A1 1e8B0O+rNd8LfFAFul/4pmfYSWqH4a40MbK74X+R55ZmczdkX68+PfNkz45MBK29 2vRcogEvgu7J7XBaGXeBtoIHWncXf95Qg/AjYZufRBj7RHBHkZZT/G/76bDc11vU 4NGYC8xKv8xPyV4kxUakrr7t2LucIQDGDiESUwf2w8g1ppKfffoUXfrw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id b0kUZCCwt71F; Wed, 9 Mar 2011 20:31:44 +0000 (GMT) Received: from [10.87.48.7] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 62A9A3E4084; Wed, 9 Mar 2011 20:31:42 +0000 (GMT) Message-ID: <4D77E3AE.5060903@cs.tcd.ie> Date: Wed, 09 Mar 2011 20:31:42 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: "Herzog, Jonathan - 0668 - MITLL" References: <552BBAA9-712F-49B4-8A5F-C671C3817C05@ll.mit.edu> <47CF9528-81A1-49D7-8D4B-B1DCC136581E@ll.mit.edu> <3E69AF7B-D325-4FC5-A003-FEBA1997D67E@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "secdir@ietf.org" , "draft-herzog-static-ecdh@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 20:30:33 -0000 Hi, I've three concerns about this. 1) Now that we have 6090, if there's a way to do any ECC stuff that can be built *only* on that, then that IMO gives a much better basis on which implementers might have confidence in their IPR situation. I think every reference to e.g. [SEC1] included muddies those waters somewhat and hence may further delay widespread adoption of ECC. Since the authors presumably would like to see adoption, I wonder is there any way to excise [SEC1] entirely and just use 6090 or other things with perhaps clearer IPR? (If there are technical issues with how to only use 6090 perhaps checking with cfrg and/or the authors of 6090 would help.) 2) If [SEC1] remains as a reference, do we expect to get an IPR declaration related to this? Have the authors asked anyone from Certicom? 3) As far as I recall the only use-case specific to static-static is that it allows employers to wiretap much more easily that ephemeral-static. Am I right there? (Its been a while.) If not, then I would suggest adding some use-case so that people might know when to go for this setup and when to go for ephemeral-static. If I am right above, then I think that warrants some security consideration and even more guidance as to when its appropriate to use static-static. (And I'd have to wonder if its worthwhile as an RFC personally, but then I guess some "customers" do like static-static for exactly this reason.) Thanks, Stephen. On 09/03/11 18:53, Brian Weis wrote: > Hi Jonathan, > > No objections. > > Thanks, > Brian > > On Mar 9, 2011, at 10:34 AM, Herzog, Jonathan - 0668 - MITLL wrote: > >> >> On Mar 8, 2011, at 12:13 PM, Brian Weis wrote: >> >>>>>> >>>>>>> 2. Reference [SEC1] is heavily referenced in this document, for both a definition of ECDH and specific methods for using ECDH. But it would be good to also mention RFC 6090, which is the best IETF document describing ECDH. >>>>>> >>>>>> I was not previous aware of this RFC-- my bad. I have added it as an informative reference, but continued to refer to [Sec1] as the normative reference for the ECDH operation. Or do you think that RFC 6090 should be the normative reference? >>>>> >>>>> I would suggesting using RFC 6090 for a normative reference to ECDH if you need such a reference. But I don't believe RFC 6090 discusses static-static consideration or issues at all, so for that [Sec1] seems to be the appropriate normative reference. >>>> >>>> I'm a little uneasy with using RFC 6090 as a normative reference for ECDH, as my impression is that the rest of CMS uses SEC1 as the normative reference. (See RFC 5753.) This may be because RFC 6090 is so new, but I'm worried that switching to RFC 6090 as the normative reference for ECDH will introduce subtle incompatibilities. >>>> >>>> Also, RFC 6090 doesn't seem to include the cofactor ECDH operation (I think), or the use of the SharedInfo/ukm value. >>>> >>>> Given this, do you mind if I keep SEC1 as normative and use RFC 6090 as informative? >>> >>> Sure, that's fine. >> >> >> I've thought a little more about this, and change my proposal to: >> >> * Reference RFC 6090 for ECDH in general, but >> * SEC1 for co-factor ECDH, the public-key validation primitives, and the key-derivation function (KDF). >> >> Unfortunately, none of those algorithms in the second bullet are present in RFC 6090. (Though the security considerations of RFC 6090 discuss why one would want to validate public keys, it doesn't describe how to do so.) >> >> >> Any objections? >> >> Thanks. >> -- >> Jonathan Herzog voice: (781) 981-2356 >> Technical Staff fax: (781) 981-7687 >> Cyber Systems and Technology Group email: jherzog@ll.mit.edu >> MIT Lincoln Laboratory www: http://www.ll.mit.edu/CST/ >> 244 Wood Street >> Lexington, MA 02420-9185 >> > > From mcgrew@cisco.com Wed Mar 9 12:31:36 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45C843A6AB6; Wed, 9 Mar 2011 12:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.224 X-Spam-Level: X-Spam-Status: No, score=-110.224 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_OBFU_ALL=0.751, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrkVmgxtW8OA; Wed, 9 Mar 2011 12:31:34 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B3B123A69FD; Wed, 9 Mar 2011 12:31:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=4951; q=dns/txt; s=iport; t=1299702771; x=1300912371; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=Jl9Lq1bM/gQeFuo+QhJbh5VGvpxKNOlfmeAY4HJPJsA=; b=jW3O2qMGrRcGDXsO+JN7BEeCVkduCcWhSQkdVSLojtatOAU/+YPX/Yut 5iNwiA537nBZ+Aq2JuqRRBaBFc+XF5FwmwFH+n0obi5pfklmHHt1mdWy8 a+gwXSFyKisydv4FmFNITof3zZtdWAtWkk8uKGmfzATFqe9apRwctsJRI w=; X-IronPort-AV: E=Sophos;i="4.62,292,1297036800"; d="scan'208";a="413163172" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 09 Mar 2011 20:32:51 +0000 Received: from stealth-10-32-254-214.cisco.com (stealth-10-32-254-214.cisco.com [10.32.254.214]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p29KWo8G020966; Wed, 9 Mar 2011 20:32:50 GMT Message-Id: <65D56695-894D-458E-A9C4-6DCF6A38F196@cisco.com> From: David McGrew To: "Herzog, Jonathan - 0668 - MITLL" In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 9 Mar 2011 12:32:49 -0800 References: <552BBAA9-712F-49B4-8A5F-C671C3817C05@ll.mit.edu> <47CF9528-81A1-49D7-8D4B-B1DCC136581E@ll.mit.edu> <3E69AF7B-D325-4FC5-A003-FEBA1997D67E@cisco.com> X-Mailer: Apple Mail (2.936) Cc: "secdir@ietf.org" , "draft-herzog-static-ecdh@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 20:31:36 -0000 Hi Jonathan, On Mar 9, 2011, at 10:34 AM, Herzog, Jonathan - 0668 - MITLL wrote: > > On Mar 8, 2011, at 12:13 PM, Brian Weis wrote: > >>>>> >>>>>> 2. Reference [SEC1] is heavily referenced in this document, for =20= >>>>>> both a definition of ECDH and specific methods for using ECDH. =20= >>>>>> But it would be good to also mention RFC 6090, which is the =20 >>>>>> best IETF document describing ECDH. >>>>> >>>>> I was not previous aware of this RFC-- my bad. I have added it =20 >>>>> as an informative reference, but continued to refer to [Sec1] as =20= >>>>> the normative reference for the ECDH operation. Or do you think =20= >>>>> that RFC 6090 should be the normative reference? >>>> >>>> I would suggesting using RFC 6090 for a normative reference to =20 >>>> ECDH if you need such a reference. But I don't believe RFC 6090 =20 >>>> discusses static-static consideration or issues at all, so for =20 >>>> that [Sec1] seems to be the appropriate normative reference. >>> >>> I'm a little uneasy with using RFC 6090 as a normative reference =20 >>> for ECDH, as my impression is that the rest of CMS uses SEC1 as =20 >>> the normative reference. (See RFC 5753.) This may be because RFC =20 >>> 6090 is so new, but I'm worried that switching to RFC 6090 as the =20= >>> normative reference for ECDH will introduce subtle =20 >>> incompatibilities. >>> >>> Also, RFC 6090 doesn't seem to include the cofactor ECDH operation =20= >>> (I think), or the use of the SharedInfo/ukm value. >>> >>> Given this, do you mind if I keep SEC1 as normative and use RFC =20 >>> 6090 as informative? >> >> Sure, that's fine. > > > I've thought a little more about this, and change my proposal to: > > * Reference RFC 6090 for ECDH in general, but > * SEC1 for co-factor ECDH, the public-key validation primitives, and =20= > the key-derivation function (KDF). > > Unfortunately, none of those algorithms in the second bullet are =20 > present in RFC 6090. (Though the security considerations of RFC 6090 =20= > discuss why one would want to validate public keys, it doesn't =20 > describe how to do so.) That's exactly right. RFC6090 should be referenced for ECDH, but not =20= cofactor-ECDH. I would like to know: why does the draft reference [SEC1] instead of a =20= NIST or IEEE standard? I would strongly prefer to see explicit =20 references to the appropriate NIST algorithms and KDFs in this =20 document. That would make it clear that the specification conformed =20 to the NIST crypto guidelines, and that is apparently a goal for the =20 document. It mentions Suite B conformance as a motivator, and Suite B =20= references the NIST guidelines. I think the document describes =20 something useful, and that it would be more valuable if it referenced =20= the NIST specifications. Probably the easiest way to do this would =20 be to add an additional reference, rather than replace the references =20= to [SEC1]. Here is some detail on how RFC6090 EDCH can be used to implement =20 static-static ECDH as it is defined by NIST SP 800-56A. RFC6090 =20 describes how the ECDH protocol it describes can interoperate with the =20= ECSVDP-DH primitive. NIST SP 800-56 defines static-static ECDH using =20= a primitive which it calls the "unified cofactor method", the ECC CDH =20= primitive in SP800-56 Section 5.7.1.2 (in conjunction with a NIST-=20 defined KDF). The "unified cofactor method" is equivalent to the =20 RFC6090 ECDH when the cofactor h=3D1. I'll outline the correspondence. = =20 The "unified cofactor method" is: Input: 1. (q, FR, a, b{, SEED}, G, n, h): Domain parameters, 2. dA : One=92s own private key, and 3. QB : The other party=92s public key. Process: 1. Compute the point P =3D hdAQB. 2. If P =3D O, output an error indicator. 3. Z =3D xP where xP is the x-coordinate of P. And here is the table of correspondence between parameters: SP-800-56A RFC6090 q p a a b b G g h 1 h is not used in RFC6090; is is the cofactor associated with the =20 elliptic curve generator. when h=3D1, ECC CDH is equivalent to ECDH FR is not used in RFC6090; it is an indication of the field =20 representation in ANSI X9.63 SEED is not used in RFC6090; it is an indication of how the ECC =20 parameters were created David > > > Any objections? > > Thanks. > --=20 > Jonathan Herzog = voice: (781) 981-2356 > Technical Staff = fax: (781) 981-7687 > Cyber Systems and Technology Group email: = jherzog@ll.mit.edu > MIT Lincoln Laboratory www: = http://www.ll.mit.edu/CST/ > 244 Wood Street > Lexington, MA 02420-9185 > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir From mcgrew@cisco.com Wed Mar 9 12:55:31 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F8AF3A6ABC; Wed, 9 Mar 2011 12:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.036 X-Spam-Level: X-Spam-Status: No, score=-110.036 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_OBFU_ALL=0.751, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAdsGjTu+U1X; Wed, 9 Mar 2011 12:55:28 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id C4A9D3A6943; Wed, 9 Mar 2011 12:55:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=4808; q=dns/txt; s=iport; t=1299704205; x=1300913805; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=4a7A70vYN9HFzNSqQeWtSDyPEyQPjWIO07Ez5YkfLrw=; b=dtOTLSQBAR2DE9g6pzrTclY6WXZgS7u+ySGlyb9VeYRpZVXdGPRNFuCm +zAlXIHGPQsYoDS1aQJ1cqTGuVoO5yWSZeeu7q/ZMtQQOoE1kz64wWbAo qswNsL7oQpZHcyHSSiof16QXY748gOeBThRzcHbY9AKTNXobF/7MvLj7o Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKZ4d02rR7H+/2dsb2JhbACmcXSnR5xPgxiCTQSFIocY X-IronPort-AV: E=Sophos;i="4.62,292,1297036800"; d="scan'208";a="275938354" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 09 Mar 2011 20:56:45 +0000 Received: from stealth-10-32-254-214.cisco.com (stealth-10-32-254-214.cisco.com [10.32.254.214]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p29Kuiai003357; Wed, 9 Mar 2011 20:56:44 GMT Message-Id: <88DD8520-CE2A-41BF-B13F-74D3B51A73A5@cisco.com> From: David McGrew To: Stephen Farrell In-Reply-To: <4D77E3AE.5060903@cs.tcd.ie> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 9 Mar 2011 12:56:43 -0800 References: <552BBAA9-712F-49B4-8A5F-C671C3817C05@ll.mit.edu> <47CF9528-81A1-49D7-8D4B-B1DCC136581E@ll.mit.edu> <3E69AF7B-D325-4FC5-A003-FEBA1997D67E@cisco.com> <4D77E3AE.5060903@cs.tcd.ie> X-Mailer: Apple Mail (2.936) Cc: "iesg@ietf.org" , "secdir@ietf.org" , "draft-herzog-static-ecdh@tools.ietf.org" , "Herzog, Jonathan - 0668 - MITLL" Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 20:55:31 -0000 Hi Stephen, On Mar 9, 2011, at 12:31 PM, Stephen Farrell wrote: > > Hi, > > I've three concerns about this. > > 1) Now that we have 6090, if there's a way to do any ECC stuff > that can be built *only* on that, then that IMO gives a much > better basis on which implementers might have confidence in > their IPR situation. I think every reference to e.g. [SEC1] > included muddies those waters somewhat and hence may further > delay widespread adoption of ECC. Since the authors presumably > would like to see adoption, I wonder is there any way to > excise [SEC1] entirely and just use 6090 or other things with > perhaps clearer IPR? (If there are technical issues with how > to only use 6090 perhaps checking with cfrg and/or the authors > of 6090 would help.) > I think that RFC6090, combined with NIST SP800-56A, could be used as the sole normative reference for static-static ECDH (the vanilla flavored variant, not the cofactor variant). I sketched some thoughts in that direction in a separate email. Jonathan, what do you think? Jonathan was correct that RFC6090 can't be used as a reference for the cofactor variant. David > 2) If [SEC1] remains as a reference, do we expect to get an > IPR declaration related to this? Have the authors asked anyone > from Certicom? > > 3) As far as I recall the only use-case specific to static-static > is that it allows employers to wiretap much more easily that > ephemeral-static. Am I right there? (Its been a while.) If not, > then I would suggest adding some use-case so that people might > know when to go for this setup and when to go for > ephemeral-static. If I am right above, then I think that warrants > some security consideration and even more guidance as to when > its appropriate to use static-static. (And I'd have to wonder > if its worthwhile as an RFC personally, but then I guess some > "customers" do like static-static for exactly this reason.) > > Thanks, > Stephen. > > On 09/03/11 18:53, Brian Weis wrote: >> Hi Jonathan, >> >> No objections. >> >> Thanks, >> Brian >> >> On Mar 9, 2011, at 10:34 AM, Herzog, Jonathan - 0668 - MITLL wrote: >> >>> >>> On Mar 8, 2011, at 12:13 PM, Brian Weis wrote: >>> >>>>>>> >>>>>>>> 2. Reference [SEC1] is heavily referenced in this document, >>>>>>>> for both a definition of ECDH and specific methods for using >>>>>>>> ECDH. But it would be good to also mention RFC 6090, which is >>>>>>>> the best IETF document describing ECDH. >>>>>>> >>>>>>> I was not previous aware of this RFC-- my bad. I have added it >>>>>>> as an informative reference, but continued to refer to [Sec1] >>>>>>> as the normative reference for the ECDH operation. Or do you >>>>>>> think that RFC 6090 should be the normative reference? >>>>>> >>>>>> I would suggesting using RFC 6090 for a normative reference to >>>>>> ECDH if you need such a reference. But I don't believe RFC 6090 >>>>>> discusses static-static consideration or issues at all, so for >>>>>> that [Sec1] seems to be the appropriate normative reference. >>>>> >>>>> I'm a little uneasy with using RFC 6090 as a normative reference >>>>> for ECDH, as my impression is that the rest of CMS uses SEC1 as >>>>> the normative reference. (See RFC 5753.) This may be because RFC >>>>> 6090 is so new, but I'm worried that switching to RFC 6090 as >>>>> the normative reference for ECDH will introduce subtle >>>>> incompatibilities. >>>>> >>>>> Also, RFC 6090 doesn't seem to include the cofactor ECDH >>>>> operation (I think), or the use of the SharedInfo/ukm value. >>>>> >>>>> Given this, do you mind if I keep SEC1 as normative and use RFC >>>>> 6090 as informative? >>>> >>>> Sure, that's fine. >>> >>> >>> I've thought a little more about this, and change my proposal to: >>> >>> * Reference RFC 6090 for ECDH in general, but >>> * SEC1 for co-factor ECDH, the public-key validation primitives, >>> and the key-derivation function (KDF). >>> >>> Unfortunately, none of those algorithms in the second bullet are >>> present in RFC 6090. (Though the security considerations of RFC >>> 6090 discuss why one would want to validate public keys, it >>> doesn't describe how to do so.) >>> >>> >>> Any objections? >>> >>> Thanks. >>> -- >>> Jonathan Herzog voice: (781) 981-2356 >>> Technical Staff fax: (781) 981-7687 >>> Cyber Systems and Technology Group email: jherzog@ll.mit.edu >>> MIT Lincoln Laboratory www: http://www.ll.mit.edu/CST/ >>> 244 Wood Street >>> Lexington, MA 02420-9185 >>> >> >> > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir From prvs=2049ffe0e7=jherzog@ll.mit.edu Wed Mar 9 13:07:53 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A19F93A6ABF; Wed, 9 Mar 2011 13:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.847 X-Spam-Level: X-Spam-Status: No, score=-5.847 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnqrs0e4LdtK; Wed, 9 Mar 2011 13:07:52 -0800 (PST) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by core3.amsl.com (Postfix) with ESMTP id EA0083A6A69; Wed, 9 Mar 2011 13:07:51 -0800 (PST) Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id p29L95UP029905; Wed, 9 Mar 2011 16:09:05 -0500 From: "Herzog, Jonathan - 0668 - MITLL" To: Stephen Farrell Date: Wed, 9 Mar 2011 16:09:04 -0500 Thread-Topic: [secdir] Secdir review of draft-herzog-static-ecdh-05 Thread-Index: Acvenjk3ZfssIOPyR2OHJhtiwLdnIw== Message-ID: References: <552BBAA9-712F-49B4-8A5F-C671C3817C05@ll.mit.edu> <47CF9528-81A1-49D7-8D4B-B1DCC136581E@ll.mit.edu> <3E69AF7B-D325-4FC5-A003-FEBA1997D67E@cisco.com> <4D77E3AE.5060903@cs.tcd.ie> In-Reply-To: <4D77E3AE.5060903@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-143--724802457"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-09_08:2011-03-09, 2011-03-09, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=8 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1012030000 definitions=main-1103090155 X-Mailman-Approved-At: Wed, 09 Mar 2011 13:08:37 -0800 Cc: "secdir@ietf.org" , "draft-herzog-static-ecdh@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 21:07:53 -0000 --Apple-Mail-143--724802457 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 9, 2011, at 3:31 PM, Stephen Farrell wrote: >=20 > Hi, >=20 > I've three concerns about this. >=20 > 1) Now that we have 6090, if there's a way to do any ECC stuff > that can be built *only* on that, then that IMO gives a much > better basis on which implementers might have confidence in > their IPR situation. I think every reference to e.g. [SEC1] > included muddies those waters somewhat and hence may further > delay widespread adoption of ECC. Since the authors presumably > would like to see adoption, I wonder is there any way to > excise [SEC1] entirely and just use 6090 or other things with > perhaps clearer IPR? (If there are technical issues with how > to only use 6090 perhaps checking with cfrg and/or the authors > of 6090 would help.) We currently (in the -06 version, not yet submitted to the IETF) cite = SEC1 for only the following: 1) Co-factor ECDH, 2) Validation of public-key parameters (both full and partial), and 3) A key-derivation function. I am sure we can find another RFC to cite for (3). Unfortunately, = however, neither (1) nor (2) seem to be in RFC 6090. (At least, I didn't = see it there. I could be wrong.) I just realized, however, that we can cite NIST SP 800-56A for both (1) = and (2). Interestingly, that SP only permits/specifies static-static = cofactor ECDH, not static-static standard ECDH. But that may not be = relevant-- we can still cite RFC 6090 for standard ECDH. So, I propose to replace SEC1 with SP 800-56A for (1) and (2), and some = other RFC for (3). Would that address your concerns? > 2) If [SEC1] remains as a reference, do we expect to get an > IPR declaration related to this? Have the authors asked anyone > from Certicom? We have not asked anyone from Certicom, no. But if we remove SEC1 entirely, does the issue become moot? > 3) As far as I recall the only use-case specific to static-static > is that it allows employers to wiretap much more easily that > ephemeral-static. Am I right there? I'm not sure what you mean by this, but I'm fairly sure it's not our = motivation. We propose this draft because we would like to use CMS in an = environment where: 1) Participants must use Suite-B algorithms, and therefore cannot use = ECMQV, and 2) Participants will have certified ECDH keys but not certified = signature keys. (Yes, ECDH keys are mathematically identical to ECDSA = keys, but our participants will be constrained by various policies and = will be unable to use their ECDH keys for ECDSA signatures.) Without this Draft, CMS supports only ECMQV (which we cannot use) and = ephemeral-static ECDH. In our setting, then, there is no way for = recipients to cryptographically ascertain the identity of a message's = sender. Now (and as we explain in the Security Considerations) it is = true that this Draft does not fully solve the problem of data = authentication in the fully general case. But (1) it gets fairly close, = at least in the case of a single recipient, and (2) we believe that the = 'attack' described in the Security Considerations is better addressed by = a separate Draft.=20 > (Its been a while.) If not, > then I would suggest adding some use-case so that people might > know when to go for this setup and when to go for > ephemeral-static. If I am right above, then I think that warrants > some security consideration and even more guidance as to when > its appropriate to use static-static. (And I'd have to wonder > if its worthwhile as an RFC personally, but then I guess some > "customers" do like static-static for exactly this reason.) Given what I say above, would you rather see more explanation in the = Security Considerations, or to the discussion of our motivations in the = Introduction? --=20 Jonathan Herzog voice: = (781) 981-2356 Technical Staff fax: = (781) 981-7687 Cyber Systems and Technology Group email: = jherzog@ll.mit.edu MIT Lincoln Laboratory www: = http://www.ll.mit.edu/CST/ 244 Wood Street =20 Lexington, MA 02420-9185 --Apple-Mail-143--724802457 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJrzCCBNIw ggO6oAMCAQICChVM3JYAAAAAIh8wDQYJKoZIhvcNAQEFBQAwUTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwg Q0EtMTAeFw0xMDA1MjUyMDQ1MzhaFw0xMTA1MjUyMDQ1MzhaMGQxCzAJBgNVBAYTAlVTMR8wHQYD VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQZW9wbGUxIzAhBgNVBAMTGkhl cnpvZy5Kb25hdGhhbi5DLjUwMDExMzA1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 93mr5a6zq6EQsVtIX9BadxwzpjabF8pvDmoMSP/ZhbWrncNJ1j7xiBGcihYqsDaQz9+hJITxi7IM NUx5fnFtOQRHZgkOCLR1URFc0AlJ3Pknv6XoQ4fqPODmSMB882c9l/8AbO7N/27r8n/V0Ip4Rpw8 1qnrDXk6UH/1zHlssGmlVng0RSREuQy98xPxzbLr5cOMWLwHs5OLNYcGv0KlD6rp1DPzJ3qplU/+ 0P2jyYbGyXStJ/h+3Kx5mOWFLB4j8HDyLG90ZHlZjZXo9FrSoFubVJK/mdVzIuXd00Ldl1fCyxhR D9elkpTc7xOLJsEzCCi8Gqo6eQuvz1RH93u3PwIDAQABo4IBlzCCAZMwDgYDVR0PAQH/BAQDAgbA MB0GA1UdDgQWBBRPjG6+CxR6H/o9vyq5PgmW9vmuajAfBgNVHSMEGDAWgBSUWsZYybYmm6AJe6gv ZJDDiQJuKjAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xM Q0ExMGIGCCsGAQUFBwEBBFYwVDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dHRvL0xMQ0ExMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5sbC5taXQuZWR1LzAMBgNVHRMBAf8E AjAAMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH /4pzAgFkAgEFMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8w DQYLKoZIhvcSAgEDAQgwHQYDVR0RBBYwFIESamhlcnpvZ0BsbC5taXQuZWR1MA0GCSqGSIb3DQEB BQUAA4IBAQBI6aoe1c6Glzs3Hh/lIzf2TzmtZSQLl8UZaIFGi0zG0EjsO6wjX6bfv/WizE30OEef 6So76p0dNt7j21lrH+FGaH6r41ggikbkoazNkAePsQk0WPZhmpus1rByNUozK4KMPpzLAynHNd5m POtqoIwDiTEgktLuZ1nwU7bUHmv7BO14dkhLhMOFKRCIi3vqe9rDh9pTYt1YNhQe1fBme6Y5DWLA TxBBqErz05e7rVngKi6yk6j7cqWpiM6L93z2Zq5p9FqACsJHmMwxH/8XFeeXgFf/CKMAIuSZCGFU 29ouEZWL7LLu87SFGm3f/3sLS7xgXei7d/PlXte1HKKdKOCPMIIE1TCCA72gAwIBAgIKFU5e0QAA AAAiIDANBgkqhkiG9w0BAQUFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4g TGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xMB4XDTEwMDUyNTIw NDcxN1oXDTExMDUyNTIwNDcxN1owZDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xu IExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEjMCEGA1UEAxMaSGVyem9nLkpvbmF0aGFuLkMu NTAwMTEzMDUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtC8sNdkCteQagOVEnQQs4 5uLqsmaOfjqTywNWuvaVj0F8Jsek8bOcuK4rlB1PrBk0Q+s/N4FVcGEn6BEDWRIDFaETVr1jweTE yRUtqngTIvpbpeixV37BcFkVnbV2VrZC5oaa0c0bkxXkuE0lohQS5AIBXQRADEJVnfXIM44yvsmo T7J5rdGwjIg4QJ2YA07po0JkbndcylcjU0zW2Lv432MEZrX/o+T0rraFAhT8A+8De9CIo0LJkXCK cNwk6LwuNKQS0qeezDo5wRiqZaht3ftiAuOImOxN44hxnDa2cHVbOFQ+pevN08gH7d39CVHUbHMC PnuIBoQNu61I2+ItAgMBAAGjggGaMIIBljAOBgNVHQ8BAf8EBAMCBSAwHQYDVR0OBBYEFEuYUJcI JTs8b2SWTJN28DD/qqsNMB8GA1UdIwQYMBaAFJRaxljJtiaboAl7qC9kkMOJAm4qMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTEwYgYIKwYBBQUHAQEE VjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTEwIwYIKwYB BQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUH BDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0l BB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMB CDAdBgNVHREEFjAUgRJqaGVyem9nQGxsLm1pdC5lZHUwDQYJKoZIhvcNAQEFBQADggEBAAmf5m3W 0Di4aQhLS1e2xejG3MQPQJvWL3dHbnHYG+NDVFWcuqyE5t73eb7nV2UyGRVHDt6MyIquedAPPm86 FSPZ6CUGGj5imp9pAu7C+xESBMY4z0k5htK/h5vlSB9X/i3JbXI8KBOioH1QYenMfrvTISmk/+5A BHsMDOpK7//bX66DP+iopoIiWJktY+dfiak7uTZhuYEOmICq4QlP9dDqdPiQGje4Y8xZ45YL6+2I m5GIzuIac/r51YTBuCk+TxTZIITMx+Fr50Ur6s4dOnvApxMR7iZX6oKnmVfXrjFMMQxR1TN5ISUn IoMyID3yCiInqQh6G3WPCAhwa/qG/moxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYD VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExM IENBLTECChVM3JYAAAAAIh8wCQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTEwMzA5MjEwOTA1WjAjBgkqhkiG9w0BCQQxFgQUHmjw+4r5kPBA Ra5UKtq3d8wShF0wbgYJKwYBBAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xAgoV Tl7RAAAAACIgMHAGCyqGSIb3DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xAgoV Tl7RAAAAACIgMA0GCSqGSIb3DQEBAQUABIIBADhsSFXQ8gssdJR9hKRdpoq65HO9qVP+L+j41uuC SNLoYD3Jsfqg95rQddgJTrdSbfK/z6flESqgy4SoWwEGegiZXneav8TzMiXEV9Mm3U4/+ztPbHvt MyGelk/IetPnbbZRi2+kUGVefhw5wJjqUruww65pXwj/3GbCT3uOBbsw9WeCP726hZgyhUeQxhgj H4uWiwA38c4qJYbjxVTtvd7Bcl58mO0J1smzQlNnkEvqwnDJIL8HQOyh854gOczbkHGW3IO1dOuD fFRBax6zJJJmPkEToHZoKzR+GqUtPMHuXKdTJ4bhrX7xLHDThbnmj5ORbs9to/TTnyBKwYke4z4A AAAAAAA= --Apple-Mail-143--724802457-- From prvs=2049ffe0e7=jherzog@ll.mit.edu Wed Mar 9 13:47:04 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DDE23A6778; Wed, 9 Mar 2011 13:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.847 X-Spam-Level: X-Spam-Status: No, score=-5.847 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlsTbobO6wqv; Wed, 9 Mar 2011 13:47:03 -0800 (PST) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by core3.amsl.com (Postfix) with ESMTP id 3B5A13A6AE1; Wed, 9 Mar 2011 13:47:01 -0800 (PST) Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id p29Llkit009134; Wed, 9 Mar 2011 16:47:46 -0500 From: "Herzog, Jonathan - 0668 - MITLL" To: David McGrew Date: Wed, 9 Mar 2011 16:47:45 -0500 Thread-Topic: [secdir] Secdir review of draft-herzog-static-ecdh-05 Thread-Index: Acveo6B1edHPaUNbQbaRUiX8Q0yc1A== Message-ID: <29C1F1D5-6EF0-4055-BA88-03F03E3F0A84@ll.mit.edu> References: <552BBAA9-712F-49B4-8A5F-C671C3817C05@ll.mit.edu> <47CF9528-81A1-49D7-8D4B-B1DCC136581E@ll.mit.edu> <3E69AF7B-D325-4FC5-A003-FEBA1997D67E@cisco.com> <65D56695-894D-458E-A9C4-6DCF6A38F196@cisco.com> In-Reply-To: <65D56695-894D-458E-A9C4-6DCF6A38F196@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-145--722481887"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-09_08:2011-03-09, 2011-03-09, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=8 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1012030000 definitions=main-1103090161 X-Mailman-Approved-At: Wed, 09 Mar 2011 13:48:09 -0800 Cc: "secdir@ietf.org" , "draft-herzog-static-ecdh@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 21:47:04 -0000 --Apple-Mail-145--722481887 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 9, 2011, at 3:32 PM, David McGrew wrote: > Hi Jonathan, >=20 > On Mar 9, 2011, at 10:34 AM, Herzog, Jonathan - 0668 - MITLL wrote: >=20 >>=20 >> On Mar 8, 2011, at 12:13 PM, Brian Weis wrote: >>=20 >>>>>>=20 >>>>>>> 2. Reference [SEC1] is heavily referenced in this document, for =20= >>>>>>> both a definition of ECDH and specific methods for using ECDH. =20= >>>>>>> But it would be good to also mention RFC 6090, which is the =20 >>>>>>> best IETF document describing ECDH. >>>>>>=20 >>>>>> I was not previous aware of this RFC-- my bad. I have added it =20= >>>>>> as an informative reference, but continued to refer to [Sec1] as =20= >>>>>> the normative reference for the ECDH operation. Or do you think =20= >>>>>> that RFC 6090 should be the normative reference? >>>>>=20 >>>>> I would suggesting using RFC 6090 for a normative reference to =20 >>>>> ECDH if you need such a reference. But I don't believe RFC 6090 =20= >>>>> discusses static-static consideration or issues at all, so for =20 >>>>> that [Sec1] seems to be the appropriate normative reference. >>>>=20 >>>> I'm a little uneasy with using RFC 6090 as a normative reference =20= >>>> for ECDH, as my impression is that the rest of CMS uses SEC1 as =20 >>>> the normative reference. (See RFC 5753.) This may be because RFC =20= >>>> 6090 is so new, but I'm worried that switching to RFC 6090 as the =20= >>>> normative reference for ECDH will introduce subtle =20 >>>> incompatibilities. >>>>=20 >>>> Also, RFC 6090 doesn't seem to include the cofactor ECDH operation =20= >>>> (I think), or the use of the SharedInfo/ukm value. >>>>=20 >>>> Given this, do you mind if I keep SEC1 as normative and use RFC =20 >>>> 6090 as informative? >>>=20 >>> Sure, that's fine. >>=20 >>=20 >> I've thought a little more about this, and change my proposal to: >>=20 >> * Reference RFC 6090 for ECDH in general, but >> * SEC1 for co-factor ECDH, the public-key validation primitives, and =20= >> the key-derivation function (KDF). >>=20 >> Unfortunately, none of those algorithms in the second bullet are =20 >> present in RFC 6090. (Though the security considerations of RFC 6090 =20= >> discuss why one would want to validate public keys, it doesn't =20 >> describe how to do so.) >=20 > That's exactly right. RFC6090 should be referenced for ECDH, but not =20= > cofactor-ECDH. >=20 > I would like to know: why does the draft reference [SEC1] instead of a = =20 > NIST or IEEE standard? No particular reason. Obviously, this was a bad choice on my part. > I would strongly prefer to see explicit =20 > references to the appropriate NIST algorithms and KDFs in this =20 > document. That would make it clear that the specification conformed =20= > to the NIST crypto guidelines, and that is apparently a goal for the =20= > document. It mentions Suite B conformance as a motivator, and Suite B = =20 > references the NIST guidelines. I think the document describes =20 > something useful, and that it would be more valuable if it referenced =20= > the NIST specifications. Probably the easiest way to do this would =20= > be to add an additional reference, rather than replace the references =20= > to [SEC1]. >=20 > Here is some detail on how RFC6090 EDCH can be used to implement =20 > static-static ECDH as it is defined by NIST SP 800-56A. RFC6090 =20 > describes how the ECDH protocol it describes can interoperate with the = =20 > ECSVDP-DH primitive. NIST SP 800-56 defines static-static ECDH using =20= > a primitive which it calls the "unified cofactor method", the ECC CDH =20= > primitive in SP800-56 Section 5.7.1.2 (in conjunction with a NIST-=20 > defined KDF). The "unified cofactor method" is equivalent to the =20 > RFC6090 ECDH when the cofactor h=3D1. =20 [snip] Right: standard ECDH is the same as cofactor ECDH when the cofactor h =3D = 1. Granted, this is true for the two Suite B curved (P256 and P384) but = not true for all the curved named in FIPS 186-3 / RFC 5480. (For the = curves over binary fields, the co-factor can be h =3D 2 or h =3D 4.) So = unless I'm missing something (which is more than likely) I don't think = we can use RFC 6090 for both standard ECDH and cofactor ECDH for all = curves in FIPS 186-3. However, SP800-56A does define cofactor ECDH. So let me propose the = following citation scheme: * ECDH in general: RFC 6090 * Standard ECDH: RFC 6090 * Co-factor Diffie-Hellman: SP 800-56A, Section 5.7.1.2 * Full public-key validation: SP800-56A, Section 5.6.2.5 * Partial public-key validation: SP800-56A: Section 5.6.2.6 * Key-derivation function... still working on it. Thoughts? --=20 Jonathan Herzog voice: = (781) 981-2356 Technical Staff fax: = (781) 981-7687 Cyber Systems and Technology Group email: = jherzog@ll.mit.edu MIT Lincoln Laboratory www: = http://www.ll.mit.edu/CST/ 244 Wood Street =20 Lexington, MA 02420-9185 --Apple-Mail-145--722481887 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJrzCCBNIw ggO6oAMCAQICChVM3JYAAAAAIh8wDQYJKoZIhvcNAQEFBQAwUTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwg Q0EtMTAeFw0xMDA1MjUyMDQ1MzhaFw0xMTA1MjUyMDQ1MzhaMGQxCzAJBgNVBAYTAlVTMR8wHQYD VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQZW9wbGUxIzAhBgNVBAMTGkhl cnpvZy5Kb25hdGhhbi5DLjUwMDExMzA1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 93mr5a6zq6EQsVtIX9BadxwzpjabF8pvDmoMSP/ZhbWrncNJ1j7xiBGcihYqsDaQz9+hJITxi7IM NUx5fnFtOQRHZgkOCLR1URFc0AlJ3Pknv6XoQ4fqPODmSMB882c9l/8AbO7N/27r8n/V0Ip4Rpw8 1qnrDXk6UH/1zHlssGmlVng0RSREuQy98xPxzbLr5cOMWLwHs5OLNYcGv0KlD6rp1DPzJ3qplU/+ 0P2jyYbGyXStJ/h+3Kx5mOWFLB4j8HDyLG90ZHlZjZXo9FrSoFubVJK/mdVzIuXd00Ldl1fCyxhR D9elkpTc7xOLJsEzCCi8Gqo6eQuvz1RH93u3PwIDAQABo4IBlzCCAZMwDgYDVR0PAQH/BAQDAgbA MB0GA1UdDgQWBBRPjG6+CxR6H/o9vyq5PgmW9vmuajAfBgNVHSMEGDAWgBSUWsZYybYmm6AJe6gv ZJDDiQJuKjAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xM Q0ExMGIGCCsGAQUFBwEBBFYwVDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dHRvL0xMQ0ExMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5sbC5taXQuZWR1LzAMBgNVHRMBAf8E AjAAMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH /4pzAgFkAgEFMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8w DQYLKoZIhvcSAgEDAQgwHQYDVR0RBBYwFIESamhlcnpvZ0BsbC5taXQuZWR1MA0GCSqGSIb3DQEB BQUAA4IBAQBI6aoe1c6Glzs3Hh/lIzf2TzmtZSQLl8UZaIFGi0zG0EjsO6wjX6bfv/WizE30OEef 6So76p0dNt7j21lrH+FGaH6r41ggikbkoazNkAePsQk0WPZhmpus1rByNUozK4KMPpzLAynHNd5m POtqoIwDiTEgktLuZ1nwU7bUHmv7BO14dkhLhMOFKRCIi3vqe9rDh9pTYt1YNhQe1fBme6Y5DWLA TxBBqErz05e7rVngKi6yk6j7cqWpiM6L93z2Zq5p9FqACsJHmMwxH/8XFeeXgFf/CKMAIuSZCGFU 29ouEZWL7LLu87SFGm3f/3sLS7xgXei7d/PlXte1HKKdKOCPMIIE1TCCA72gAwIBAgIKFU5e0QAA AAAiIDANBgkqhkiG9w0BAQUFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4g TGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xMB4XDTEwMDUyNTIw NDcxN1oXDTExMDUyNTIwNDcxN1owZDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xu IExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEjMCEGA1UEAxMaSGVyem9nLkpvbmF0aGFuLkMu NTAwMTEzMDUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtC8sNdkCteQagOVEnQQs4 5uLqsmaOfjqTywNWuvaVj0F8Jsek8bOcuK4rlB1PrBk0Q+s/N4FVcGEn6BEDWRIDFaETVr1jweTE yRUtqngTIvpbpeixV37BcFkVnbV2VrZC5oaa0c0bkxXkuE0lohQS5AIBXQRADEJVnfXIM44yvsmo T7J5rdGwjIg4QJ2YA07po0JkbndcylcjU0zW2Lv432MEZrX/o+T0rraFAhT8A+8De9CIo0LJkXCK cNwk6LwuNKQS0qeezDo5wRiqZaht3ftiAuOImOxN44hxnDa2cHVbOFQ+pevN08gH7d39CVHUbHMC PnuIBoQNu61I2+ItAgMBAAGjggGaMIIBljAOBgNVHQ8BAf8EBAMCBSAwHQYDVR0OBBYEFEuYUJcI JTs8b2SWTJN28DD/qqsNMB8GA1UdIwQYMBaAFJRaxljJtiaboAl7qC9kkMOJAm4qMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTEwYgYIKwYBBQUHAQEE VjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTEwIwYIKwYB BQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUH BDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0l BB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMB CDAdBgNVHREEFjAUgRJqaGVyem9nQGxsLm1pdC5lZHUwDQYJKoZIhvcNAQEFBQADggEBAAmf5m3W 0Di4aQhLS1e2xejG3MQPQJvWL3dHbnHYG+NDVFWcuqyE5t73eb7nV2UyGRVHDt6MyIquedAPPm86 FSPZ6CUGGj5imp9pAu7C+xESBMY4z0k5htK/h5vlSB9X/i3JbXI8KBOioH1QYenMfrvTISmk/+5A BHsMDOpK7//bX66DP+iopoIiWJktY+dfiak7uTZhuYEOmICq4QlP9dDqdPiQGje4Y8xZ45YL6+2I m5GIzuIac/r51YTBuCk+TxTZIITMx+Fr50Ur6s4dOnvApxMR7iZX6oKnmVfXrjFMMQxR1TN5ISUn IoMyID3yCiInqQh6G3WPCAhwa/qG/moxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYD VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExM IENBLTECChVM3JYAAAAAIh8wCQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTEwMzA5MjE0NzQ1WjAjBgkqhkiG9w0BCQQxFgQUzNnWyYu3Fa6G ZC6ZEEBVPVRzISUwbgYJKwYBBAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xAgoV Tl7RAAAAACIgMHAGCyqGSIb3DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xAgoV Tl7RAAAAACIgMA0GCSqGSIb3DQEBAQUABIIBAMn4JQ294yOrM8XgUYLLp6ky6i40fK+1V8Qss+Gt zPhtJ3hfC5dRmHCRgXl488BRZaCfvZIMOx8kMbOvoAfPazqpjQYfdy4pw5R79WG7U41x4GInLalO GKUlPg4fHMnmJO60MTXAr9Ml+I1kw/mIdaT8q0+tAt2hBxJR/r0ezA94K2EBLa72//2rgdpHWsol OBUDjqEVgyhNxPW8CWM0mo/6lwr4ad1mXieKO+rrxnN8ULE7VgUcvWNqQFok8+z0OkERUJudZR4J wlH+O2XkY2bwqfmxMjEI3n9A7Zr0AjM70NbqD2Ng84sQGIhOJQj4cgL0vbMDkQmzEeltFyxH+mAA AAAAAAA= --Apple-Mail-145--722481887-- From stephen.farrell@cs.tcd.ie Wed Mar 9 14:48:47 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC9493A6AEC; Wed, 9 Mar 2011 14:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.801 X-Spam-Level: X-Spam-Status: No, score=-102.801 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpJNa9V53kNX; Wed, 9 Mar 2011 14:48:45 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id 62DA43A6768; Wed, 9 Mar 2011 14:48:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id EEBAA3E4087; Wed, 9 Mar 2011 22:49:59 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1299710999; bh=yn1hvq+awOmoZF 2Yc5sKxuXZR6Nw2uxnOd9+M2C5U6s=; b=H41UxUFtfWxwbZPCLniLP+LDXLcWNk Z1otVn91rNl40MaKhG4HP5bZ5Sg9Ngob/M7A5hudPIhTZ7rXH4XM+rfrew9lg69o fInOTcblj5uoUv9jZC8EoP98FyDLTggEqjlUE5TjDuLA5RETm/LBDlUFxU+FPUju zU+tUf2ScmQduBqiskBhomvj9SorZ8w9hK7JQsstMv3wnW/6LZVbRq2zZVm0BZsW 4hCNLIbt0VR14ekKf9AmB5GsXMk2/zIJIMKx5QmLeGLJMRQU1OB0nOgluzj94b1k VK9EgyrG1Olo/nnEW63VkhJu1o2KZ1AWu3VnAgxoAbxD8Nw4PGV8K0AQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id O-NyXQvNmgBU; Wed, 9 Mar 2011 22:49:59 +0000 (GMT) Received: from [10.87.48.7] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 1B14B3E4077; Wed, 9 Mar 2011 22:49:59 +0000 (GMT) Message-ID: <4D780411.9060108@cs.tcd.ie> Date: Wed, 09 Mar 2011 22:49:53 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: "Herzog, Jonathan - 0668 - MITLL" References: <552BBAA9-712F-49B4-8A5F-C671C3817C05@ll.mit.edu> <47CF9528-81A1-49D7-8D4B-B1DCC136581E@ll.mit.edu> <3E69AF7B-D325-4FC5-A003-FEBA1997D67E@cisco.com> <4D77E3AE.5060903@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "secdir@ietf.org" , "draft-herzog-static-ecdh@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 22:48:47 -0000 Hi Jonathan, On 09/03/11 21:09, Herzog, Jonathan - 0668 - MITLL wrote: > > On Mar 9, 2011, at 3:31 PM, Stephen Farrell wrote: > >> >> Hi, >> >> I've three concerns about this. >> >> 1) Now that we have 6090, if there's a way to do any ECC stuff >> that can be built *only* on that, then that IMO gives a much >> better basis on which implementers might have confidence in >> their IPR situation. I think every reference to e.g. [SEC1] >> included muddies those waters somewhat and hence may further >> delay widespread adoption of ECC. Since the authors presumably >> would like to see adoption, I wonder is there any way to >> excise [SEC1] entirely and just use 6090 or other things with >> perhaps clearer IPR? (If there are technical issues with how >> to only use 6090 perhaps checking with cfrg and/or the authors >> of 6090 would help.) > > We currently (in the -06 version, not yet submitted to the IETF) cite SEC1 for only the following: > > 1) Co-factor ECDH, > 2) Validation of public-key parameters (both full and partial), and > 3) A key-derivation function. > > I am sure we can find another RFC to cite for (3). Unfortunately, however, neither (1) nor (2) seem to be in RFC 6090. (At least, I didn't see it there. I could be wrong.) > > I just realized, however, that we can cite NIST SP 800-56A for both (1) and (2). Interestingly, that SP only permits/specifies static-static cofactor ECDH, not static-static standard ECDH. But that may not be relevant-- we can still cite RFC 6090 for standard ECDH. > > So, I propose to replace SEC1 with SP 800-56A for (1) and (2), and some other RFC for (3). Would that address your concerns? To be honest, I don't know for sure. I'm not familiar with how NIST do or don't handle IPR so I don't know if the outcome here will or won't make it easier for implementers to decide whether or no to adopt this. But I think you're definitely working in the right direction in the thread with David so that's good. >> 2) If [SEC1] remains as a reference, do we expect to get an >> IPR declaration related to this? Have the authors asked anyone >> from Certicom? > > We have not asked anyone from Certicom, no. > > But if we remove SEC1 entirely, does the issue become moot? I wish;-) Not sure I've seen an RFC about ECC that didn't come with an IPR declaration from them attached. (Though the content of those declarations is improving.) >> 3) As far as I recall the only use-case specific to static-static >> is that it allows employers to wiretap much more easily that >> ephemeral-static. Am I right there? > > I'm not sure what you mean by this, I'm thinking of schemes from some years ago where the requirement was to be able to decrypt outbound mails at the outbound MTA when sender private values had been centrally generated. I don't really recall any other specific benefit of static-static. > but I'm fairly sure it's not our motivation. Sure. I wasn't trying to say it was. > We propose this draft because we would like to use CMS in an environment where: > > 1) Participants must use Suite-B algorithms, and therefore cannot use ECMQV, and > > 2) Participants will have certified ECDH keys but not certified signature keys. (Yes, ECDH keys are mathematically identical to ECDSA keys, but our participants will be constrained by various policies and will be unable to use their ECDH keys for ECDSA signatures.) > > Without this Draft, CMS supports only ECMQV (which we cannot use) and ephemeral-static ECDH. In our setting, then, there is no way for recipients to cryptographically ascertain the identity of a message's sender. I think that's useful context for the intro. > Now (and as we explain in the Security Considerations) it is true that this Draft does not fully solve the problem of data authentication in the fully general case. But (1) it gets fairly close, at least in the case of a single recipient, and (2) we believe that the 'attack' described in the Security Considerations is better addressed by a separate Draft. To be honest I'll have to read the draft again to answer that, and its late here. Tomorrow. Cheers, S. > > >> (Its been a while.) If not, >> then I would suggest adding some use-case so that people might >> know when to go for this setup and when to go for >> ephemeral-static. If I am right above, then I think that warrants >> some security consideration and even more guidance as to when >> its appropriate to use static-static. (And I'd have to wonder >> if its worthwhile as an RFC personally, but then I guess some >> "customers" do like static-static for exactly this reason.) > > Given what I say above, would you rather see more explanation in the Security Considerations, or to the discussion of our motivations in the Introduction? > From hartmans@mit.edu Thu Mar 10 09:36:37 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9FCA3A6992; Thu, 10 Mar 2011 09:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.618 X-Spam-Level: X-Spam-Status: No, score=-102.618 tagged_above=-999 required=5 tests=[AWL=-0.953, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcdkokaPsiuF; Thu, 10 Mar 2011 09:36:35 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id B8D373A691F; Thu, 10 Mar 2011 09:36:35 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id D7FEE20265; Thu, 10 Mar 2011 12:35:09 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D780E432D; Thu, 10 Mar 2011 12:37:26 -0500 (EST) From: Sam Hartman To: ietf@ietf.org,secdir@ietf.org Date: Thu, 10 Mar 2011 12:37:26 -0500 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: draft-ietf-sidr-res-certs@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-sidr-res-certs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 17:36:37 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes a certificate profile for resource certificates in the RPKI. That is, this is a profile of RFC 5280 that describes behavior for CAs and RPs in the RPKI with regard to resource certificates. I have one large issue I'd like to call to the IETF's attention; I think the WG has made an incorrect technical decision and I'd like the IESG both to review whether they believe that decision is correct and to see if that decision has sufficient support in the broader security and routing community. The basic issue surrounds extensibility and extensions. The working group concluded that they want to closely control how resource certificates are used. To me, that seems like a reasonable decision. So, they mandate that only a specific set of options from RFC 5280 are permitted in resource certificates. This is a constraint on the behavior of CAs. A CA could not for example generate a certificate useful both as a resource certificate and for a purpose requiring a specific subjectAlternativeName. Again, doing so seems entirely reasonable. The document also requires that relying parties reject certificates that include unknown extensions. The rationale explained in section 8 is that it is undesirable to have a situation where if an RP implemented more extensions it would reject certificates that a more minimal RP would accept. In other words the profile picks security and minimalism over extensibility. I'm a fan of security, but I believe this decision is misplaced because I believe it provides the IETF insufficient flexibility to correct errors or evolve the RPKI in the future. Remember that CAs are trusted entities typically within an organization or that you have a contract with. Examples of CAs in the RPKI include RIRs, your ISP and potentially a RPKI CA within your organization. We're saying that the possibility that one of these entities would include an unexpected extension and cause some harm is worth giving up the mechanisms we'd likely use to fix problems or deploy additions to the RPKI in a backward compatible manner. How realistic is it that we would end up finding errors?Well let's take a look at changes in information managed by the RPKI over the last few years. The most obvious change I can think of is that we've moved from 16-bit AS numbers to 32-bit AS numbers (or at least we're trying to get there.) Now it turns out that RFC 3779 handles this correctly and that we don't have a problem in this area. It's also likely given that RFC 3779 uses an unconstrained ASN.1 integer that we wouldn't have run across this specific problem. However I argue that if we've had a transition that could potentially have issues that's a good argument that we need to have a strategy for dealing with errors. There is no discussion in draft-ietf-sidr-arch or draft-ietf-sidr-res-certs that I was able to find out explaining how we'll add information to the RPKI if we find we need to do so in a backward compatible manner. I believe that this needs to be considered by the WG. I also recommend that the restrictions in draft-ietf-sidr-res-certs be relaxed. The restrictions on certificate issuance should remain. The restrictions on validation should be relaxed to permit unknown non-critical Extensions. If we decide that for some certificate we do wish to break backward compatibility we can always introduce a critical Extension. Nothing in section 8 of draft-ietf-sidr-res-certs causes me to believe that the extensibility model of the RPKI is significantly differnt than the model already described in RFC 5280. There's also a consistency problem between RFC 5280 and draft-ietf-sidr-res-certs. Section 4.6 and 4.7 describe validFrom and ValidTo elements. Shouldn't these be notBefore and notAfter? Thanks, --Sam From mcgrew@cisco.com Thu Mar 10 10:10:56 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E65C43A6A50; Thu, 10 Mar 2011 10:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.973 X-Spam-Level: X-Spam-Status: No, score=-109.973 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_OBFU_ALL=0.751, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1b7e02LvbJF; Thu, 10 Mar 2011 10:10:51 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 3FAE33A6B3B; Thu, 10 Mar 2011 10:10:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=5253; q=dns/txt; s=iport; t=1299780727; x=1300990327; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=QP+LRxO/hvnxyufBtmv410uTy9KJXC78Qibvamdo5d0=; b=KR4L+lCp1/mipm60q8qgzw9/rkQJaKGVvQuhnhjcJUgfUcu87Poa+o8r SVLPvLyELp/wdG+RnSB6r4HTyZIzgcjnuYZe9fpFVtNdH6ix8dSP+fMfh Tl0MaxcS2+blSLdXgWFhD/FHVi++M1jVL9zH6F5wR/wFzcs92TK7GTX4c M=; X-IronPort-AV: E=Sophos;i="4.62,297,1297036800"; d="scan'208";a="666326303" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 10 Mar 2011 18:12:07 +0000 Received: from stealth-10-32-254-214.cisco.com (stealth-10-32-254-214.cisco.com [10.32.254.214]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p2AIC6bI006505; Thu, 10 Mar 2011 18:12:06 GMT Message-Id: From: David McGrew To: "Herzog, Jonathan - 0668 - MITLL" In-Reply-To: <29C1F1D5-6EF0-4055-BA88-03F03E3F0A84@ll.mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 10 Mar 2011 10:12:05 -0800 References: <552BBAA9-712F-49B4-8A5F-C671C3817C05@ll.mit.edu> <47CF9528-81A1-49D7-8D4B-B1DCC136581E@ll.mit.edu> <3E69AF7B-D325-4FC5-A003-FEBA1997D67E@cisco.com> <65D56695-894D-458E-A9C4-6DCF6A38F196@cisco.com> <29C1F1D5-6EF0-4055-BA88-03F03E3F0A84@ll.mit.edu> X-Mailer: Apple Mail (2.936) Cc: "secdir@ietf.org" , "draft-herzog-static-ecdh@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 18:10:56 -0000 Hi Jonathan, On Mar 9, 2011, at 1:47 PM, Herzog, Jonathan - 0668 - MITLL wrote: > > On Mar 9, 2011, at 3:32 PM, David McGrew wrote: > >> Hi Jonathan, >> >> On Mar 9, 2011, at 10:34 AM, Herzog, Jonathan - 0668 - MITLL wrote: >> >>> >>> On Mar 8, 2011, at 12:13 PM, Brian Weis wrote: >>> >>>>>>> >>>>>>>> 2. Reference [SEC1] is heavily referenced in this document, for >>>>>>>> both a definition of ECDH and specific methods for using ECDH. >>>>>>>> But it would be good to also mention RFC 6090, which is the >>>>>>>> best IETF document describing ECDH. >>>>>>> >>>>>>> I was not previous aware of this RFC-- my bad. I have added it >>>>>>> as an informative reference, but continued to refer to [Sec1] as >>>>>>> the normative reference for the ECDH operation. Or do you think >>>>>>> that RFC 6090 should be the normative reference? >>>>>> >>>>>> I would suggesting using RFC 6090 for a normative reference to >>>>>> ECDH if you need such a reference. But I don't believe RFC 6090 >>>>>> discusses static-static consideration or issues at all, so for >>>>>> that [Sec1] seems to be the appropriate normative reference. >>>>> >>>>> I'm a little uneasy with using RFC 6090 as a normative reference >>>>> for ECDH, as my impression is that the rest of CMS uses SEC1 as >>>>> the normative reference. (See RFC 5753.) This may be because RFC >>>>> 6090 is so new, but I'm worried that switching to RFC 6090 as the >>>>> normative reference for ECDH will introduce subtle >>>>> incompatibilities. >>>>> >>>>> Also, RFC 6090 doesn't seem to include the cofactor ECDH operation >>>>> (I think), or the use of the SharedInfo/ukm value. >>>>> >>>>> Given this, do you mind if I keep SEC1 as normative and use RFC >>>>> 6090 as informative? >>>> >>>> Sure, that's fine. >>> >>> >>> I've thought a little more about this, and change my proposal to: >>> >>> * Reference RFC 6090 for ECDH in general, but >>> * SEC1 for co-factor ECDH, the public-key validation primitives, and >>> the key-derivation function (KDF). >>> >>> Unfortunately, none of those algorithms in the second bullet are >>> present in RFC 6090. (Though the security considerations of RFC 6090 >>> discuss why one would want to validate public keys, it doesn't >>> describe how to do so.) >> >> That's exactly right. RFC6090 should be referenced for ECDH, but not >> cofactor-ECDH. >> >> I would like to know: why does the draft reference [SEC1] instead >> of a >> NIST or IEEE standard? > > No particular reason. Obviously, this was a bad choice on my part. "You are lost in a maze of public key cryptography standards, all nearly alike" I've had that feeling before ;-) > > >> I would strongly prefer to see explicit >> references to the appropriate NIST algorithms and KDFs in this >> document. That would make it clear that the specification conformed >> to the NIST crypto guidelines, and that is apparently a goal for the >> document. It mentions Suite B conformance as a motivator, and >> Suite B >> references the NIST guidelines. I think the document describes >> something useful, and that it would be more valuable if it referenced >> the NIST specifications. Probably the easiest way to do this would >> be to add an additional reference, rather than replace the references >> to [SEC1]. >> >> Here is some detail on how RFC6090 EDCH can be used to implement >> static-static ECDH as it is defined by NIST SP 800-56A. RFC6090 >> describes how the ECDH protocol it describes can interoperate with >> the >> ECSVDP-DH primitive. NIST SP 800-56 defines static-static ECDH using >> a primitive which it calls the "unified cofactor method", the ECC CDH >> primitive in SP800-56 Section 5.7.1.2 (in conjunction with a NIST- >> defined KDF). The "unified cofactor method" is equivalent to the >> RFC6090 ECDH when the cofactor h=1. > > [snip] > > Right: standard ECDH is the same as cofactor ECDH when the cofactor > h = 1. Granted, this is true for the two Suite B curved (P256 and > P384) but not true for all the curved named in FIPS 186-3 / RFC > 5480. (For the curves over binary fields, the co-factor can be h = 2 > or h = 4.) So unless I'm missing something (which is more than > likely) I don't think we can use RFC 6090 for both standard ECDH and > cofactor ECDH for all curves in FIPS 186-3. That's right, you're not missing anything. > > However, SP800-56A does define cofactor ECDH. So let me propose the > following citation scheme: > > * ECDH in general: RFC 6090 > * Standard ECDH: RFC 6090 > * Co-factor Diffie-Hellman: SP 800-56A, Section 5.7.1.2 > * Full public-key validation: SP800-56A, Section 5.6.2.5 > * Partial public-key validation: SP800-56A: Section 5.6.2.6 > * Key-derivation function... still working on it. > > Thoughts? That looks good to me. Let me know if I can help with the KDF. David > > > > -- > Jonathan Herzog voice: (781) 981-2356 > Technical Staff fax: (781) 981-7687 > Cyber Systems and Technology Group email: jherzog@ll.mit.edu > MIT Lincoln Laboratory www: http://www.ll.mit.edu/CST/ > 244 Wood Street > Lexington, MA 02420-9185 > From paul.hoffman@vpnc.org Thu Mar 10 10:39:23 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAAE23A6942; Thu, 10 Mar 2011 10:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.946 X-Spam-Level: X-Spam-Status: No, score=-101.946 tagged_above=-999 required=5 tests=[AWL=0.653, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKXicEs++Mfq; Thu, 10 Mar 2011 10:39:22 -0800 (PST) Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 7B53B3A67EE; Thu, 10 Mar 2011 10:39:22 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p2AIecGQ079872 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 10 Mar 2011 11:40:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D791B26.8020001@vpnc.org> Date: Thu, 10 Mar 2011 10:40:38 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-sidr-res-certs@tools.ietf.org, ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-sidr-res-certs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 18:39:23 -0000 On 3/10/11 9:37 AM, Sam Hartman wrote: > The document also requires that relying parties reject certificates that > include unknown extensions. The rationale explained in section 8 is that > it is undesirable to have a situation where if an RP implemented more > extensions it would reject certificates that a more minimal RP would > accept. > In other words the profile picks security and minimalism over > extensibility. This statement is too narrow, and it causes your analysis to come to a too narrow conclusion. The profile picks security and minimalism over extensibility *of this profile only*. If a flaw is later found that requires an extension, that extension will be written up in a standards-track document that will obsolete this profile. An implementation that conforms to that new profile will use the extension. Thus, errors can be corrected with new profiles, and the RPKI will have multiple profiles running on it, just as the Internet has multiple versions of some protocols running on it. --Paul Hoffman From hartmans@mit.edu Thu Mar 10 11:06:42 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C90903A6828; Thu, 10 Mar 2011 11:06:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.878 X-Spam-Level: X-Spam-Status: No, score=-102.878 tagged_above=-999 required=5 tests=[AWL=-0.613, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScvgkMKD0PRs; Thu, 10 Mar 2011 11:06:42 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 0D4BE3A6806; Thu, 10 Mar 2011 11:06:41 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 89FBA202B2; Thu, 10 Mar 2011 14:05:14 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 78108432D; Thu, 10 Mar 2011 14:07:31 -0500 (EST) From: Sam Hartman To: Paul Hoffman References: <4D791B26.8020001@vpnc.org> Date: Thu, 10 Mar 2011 14:07:31 -0500 In-Reply-To: <4D791B26.8020001@vpnc.org> (Paul Hoffman's message of "Thu, 10 Mar 2011 10:40:38 -0800") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: draft-ietf-sidr-res-certs@tools.ietf.org, Sam Hartman , ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-sidr-res-certs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 19:06:42 -0000 >>>>> "Paul" == Paul Hoffman writes: Paul> On 3/10/11 9:37 AM, Sam Hartman wrote: >> The document also requires that relying parties reject >> certificates that include unknown extensions. The rationale >> explained in section 8 is that it is undesirable to have a >> situation where if an RP implemented more extensions it would >> reject certificates that a more minimal RP would accept. In >> other words the profile picks security and minimalism over >> extensibility. Paul> This statement is too narrow, and it causes your analysis to Paul> come to a too narrow conclusion. The profile picks security Paul> and minimalism over extensibility *of this profile only*. If a Paul> flaw is later found that requires an extension, that extension Paul> will be written up in a standards-track document that will Paul> obsolete this profile. An implementation that conforms to that Paul> new profile will use the extension. Thus, errors can be Paul> corrected with new profiles, and the RPKI will have multiple Paul> profiles running on it, just as the Internet has multiple Paul> versions of some protocols running on it. Paul, that's a great argument for why it's OK to prohibit issuing certificates with new extensions in this profile. We absolutely can change CA behavior with a new profile. However, I don't think your argument makes sense for RP behavior. Under this profile, if an RP is presented with a certificate issued under a new RPKI profile, it will reject that certificate. So, it sounds a lot like you'd need to upgrade all the RPs that might need to rely on a particular resource certificate before you could issue that certificate under a new profile. Given that resource certificates can be used by a lot of RPs--for example anyone who needs to verify origins of a route presumably--that's a long wait. I think that's unjustified. One of us is clearly missing something. I would be happy if it's me. From paul.hoffman@vpnc.org Thu Mar 10 11:30:28 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70E9D3A6828; Thu, 10 Mar 2011 11:30:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.952 X-Spam-Level: X-Spam-Status: No, score=-101.952 tagged_above=-999 required=5 tests=[AWL=0.647, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWfmMDCE7cRg; Thu, 10 Mar 2011 11:30:27 -0800 (PST) Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 14CC73A6826; Thu, 10 Mar 2011 11:30:26 -0800 (PST) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p2AJVhi7082352 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 10 Mar 2011 12:31:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D79271E.6080707@vpnc.org> Date: Thu, 10 Mar 2011 11:31:42 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Sam Hartman References: <4D791B26.8020001@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-sidr-res-certs@tools.ietf.org, ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-sidr-res-certs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 19:30:28 -0000 On 3/10/11 11:07 AM, Sam Hartman wrote: >>>>>> "Paul" == Paul Hoffman writes: > > Paul> On 3/10/11 9:37 AM, Sam Hartman wrote: > >> The document also requires that relying parties reject > >> certificates that include unknown extensions. The rationale > >> explained in section 8 is that it is undesirable to have a > >> situation where if an RP implemented more extensions it would > >> reject certificates that a more minimal RP would accept. In > >> other words the profile picks security and minimalism over > >> extensibility. > > Paul> This statement is too narrow, and it causes your analysis to > Paul> come to a too narrow conclusion. The profile picks security > Paul> and minimalism over extensibility *of this profile only*. If a > Paul> flaw is later found that requires an extension, that extension > Paul> will be written up in a standards-track document that will > Paul> obsolete this profile. An implementation that conforms to that > Paul> new profile will use the extension. Thus, errors can be > Paul> corrected with new profiles, and the RPKI will have multiple > Paul> profiles running on it, just as the Internet has multiple > Paul> versions of some protocols running on it. > > > Paul, that's a great argument for why it's OK to prohibit issuing > certificates with new extensions in this profile. > We absolutely can change CA behavior with a new profile. > > However, I don't think your argument makes sense for RP behavior. > Under this profile, if an RP is presented with a certificate issued > under a new RPKI profile, it will reject that certificate. > > So, it sounds a lot like you'd need to upgrade all the RPs that might > need to rely on a particular resource certificate before you could > issue that certificate under a new profile. > Given that resource certificates can be used by a lot of RPs--for > example anyone who needs to verify origins of a route presumably--that's > a long wait. > I think that's unjustified. > > One of us is clearly missing something. I would be happy if it's me. I don't think either of us is missing something, we just disagree about what needs to happen if a fix that changes the semantics of the certs needs to be made to the system as a whole. For changes that don't change the semantics, you change an existing extension or other part of the certificate; for changes that need to change the system's semantics, you change the certificates in a way that relying parties that don't understand the change won't accept the certificate. Maybe you and I are envisioning different choices being made about those changes. I trust the IETF not to make a change that will cause a lot of relying parties to fail unless the IETF really thinks that is necessary; you may have less faith than I do. (You were on the IESG, so you get to be in the sausage-making more than I have...) From sra@hactrn.net Thu Mar 10 11:54:50 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1FAF3A698B; Thu, 10 Mar 2011 11:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCH+2as7cvoX; Thu, 10 Mar 2011 11:54:49 -0800 (PST) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 7F6243A67FF; Thu, 10 Mar 2011 11:54:49 -0800 (PST) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 4938028464; Thu, 10 Mar 2011 19:56:05 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id EE3C522829; Thu, 10 Mar 2011 14:56:04 -0500 (EST) Date: Thu, 10 Mar 2011 14:56:04 -0500 From: Rob Austein To: draft-ietf-sidr-res-certs@tools.ietf.org, ietf@ietf.org, secdir@ietf.org In-Reply-To: <4D79271E.6080707@vpnc.org> References: <4D791B26.8020001@vpnc.org> <4D79271E.6080707@vpnc.org> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <20110310195604.EE3C522829@thrintun.hactrn.net> Subject: Re: [secdir] Secdir review of draft-ietf-sidr-res-certs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 19:54:50 -0000 Speaking as someone who has implemented relying party tools for this, I support the current restrictive choices in the profile, for a very simple reason: I can't validate what I don't understand. The current profile is written to restrict what's allowed today to things we understand today. As Paul says, if we understand something new tomorrow, we'll have to update both profile and code. "La perfection soit atteinte non quand il n'y a plus rien =E0 ajouter, mais quand il n'y a plus rien =E0 retrancher." From hartmans@mit.edu Thu Mar 10 12:53:00 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2B1A3A6A1C; Thu, 10 Mar 2011 12:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.084 X-Spam-Level: X-Spam-Status: No, score=-102.084 tagged_above=-999 required=5 tests=[AWL=-1.359, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_LWHUGE=1.54, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxI1v174R9M3; Thu, 10 Mar 2011 12:52:58 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id EC3113A67F8; Thu, 10 Mar 2011 12:52:57 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 9A2CB2010F; Thu, 10 Mar 2011 15:51:31 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8A242432D; Thu, 10 Mar 2011 15:53:44 -0500 (EST) From: Sam Hartman To: Paul Hoffman References: <4D791B26.8020001@vpnc.org> <4D79271E.6080707@vpnc.org> Date: Thu, 10 Mar 2011 15:53:44 -0500 In-Reply-To: <4D79271E.6080707@vpnc.org> (Paul Hoffman's message of "Thu, 10 Mar 2011 11:31:42 -0800") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: draft-ietf-sidr-res-certs@tools.ietf.org, Sam Hartman , ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-sidr-res-certs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 20:53:00 -0000 >>>>> "Paul" == Paul Hoffman writes: Paul> I don't think either of us is missing something, we just Paul> disagree about what needs to happen if a fix that changes the Paul> semantics of the certs needs to be made to the system as a Paul> whole. For changes that don't change the semantics, you change Paul> an existing extension or other part of the certificate; for Paul> changes that need to change the system's semantics, you change Paul> the certificates in a way that relying parties that don't Paul> understand the change won't accept the certificate. Paul> Maybe you and I are envisioning different choices being made Paul> about those changes. I trust the IETF not to make a change Paul> that will cause a lot of relying parties to fail unless the Paul> IETF really thinks that is necessary; you may have less faith Paul> than I do. (You were on the IESG, so you get to be in the Paul> sausage-making more than I have...) I do trust the IETF, which is why I think the current document is very broken. I want to give the IETF the *future* opportunity to balance breaking RPs against confusing behavior. I hate to get into a specific example, because it's very easy to attack the example without the general point. However in the interests of trying to explore our difference, I'd like to come up with a specific example. I may drop the discussion if I feel that we're focusing on the example rather than the general point. So let's pretend that we'd been much more efficient about SIDR and that the RPKI was done prior to 32-bit ASes being a significant issue. Let's pretend that RFC 3779 managed to specify the AS constraint in such a way that 32-bit ASes were excluded. Perhaps there is an ASN.1 constraint on the size of the AS that happens to be rigorously enforced by widely deployed RPs. Regardless of how it happened, assume that we cannot encode 32-bit ASes in the existing extension. In the current model, we have to come up with a new extension. I think this means you need a new independent CA hierarchy for the 32-bit AS certificates. New RPs can use that hierarchy for 32-bit ASes, all RPs use the old hierarchy for the 16-bit AS certs and to the extent they are combined IP certs. In theory we could some day combine these hierarchies when all the RPs support 32-bit ASes. In practice we probably wouldn't because someone out there would implement an RP that broke when the hierarchies were combined and even though it would simplify things the risk of breakage would not justify combining the hierarchies. I'm not sure if this model works: I'd need to analyze whether you can have multiple signatures on an RPKI object, whether you need to claim both an AS and an IP address in signing a route, etc etc. If we're going to go forward with the current model we need at least convince ourselves that even if we did have to duplicate the RPKI to deploy some feature we could do so and not also duplicate the instances of the protocols signing RPKI objects. However, if we had a relaxed model, we'd give the IETF another option. The IETF could also provide a new version of the AS extension for 32-bit ASes. There are huge tradeoffs here. Only new RPs will validate the 32-bit ASes. So you can get into a situation where an RP who is unaware of 32-bit ASes accepts a certificate that a newer RP would reject. However, the 16-bit ASes in that certificate would validate. The IP addresses in that certificate would validate. An appropriately authorized trust anchor would need to create a certificate with a valid certification path that passed all the checks in the old profile. Such a certificate could only be used by an old-profile RP to validate objects permitted under the old profile. An RP that understood 32-bit ASes would be required to understand the 32-bit AS validation. I don't know what the right choice would be in this situation. However in similar situations I'd prefer to make that choice in the future when the IETF is in a position to evaluate the tradeoffs rather than forcing our hand now. Similarly you could imagine a desire to add information to a certificate for auditing, debugging or the like, where validation rules were not changed. Again, I'd prefer to allow the IETF to decide whether breaking RPs should be required to make such changes in the future rather than now. Again, because of extension criticality, we always have the option to force RPs to reject new things they don't understand. The question is whether we want options beyond that. From kent@bbn.com Thu Mar 10 16:23:49 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF8B93A6ADF; Thu, 10 Mar 2011 16:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1s9TeRjlMyur; Thu, 10 Mar 2011 16:23:49 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 0253E3A69B6; Thu, 10 Mar 2011 16:23:49 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:35762 helo=[10.84.130.113]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PxqAE-000G8F-6F; Thu, 10 Mar 2011 19:25:07 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 10 Mar 2011 19:21:22 -0500 To: Sam Hartman From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: draft-ietf-sidr-res-certs@tools.ietf.org, ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-sidr-res-certs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 00:23:50 -0000 Sam, The cert profile is intentionally very restrictive, as you noted. A primary rationale is that we are asking folks who manage address (and AS#) allocation to act as CAs , and we want to limit their liability. One way to do this is to restrict the fields and extensions in resource certs to make then not very useful for other applications. we also wanted to make it as easy as possible for relying parties to process resource certs. X.509 has a lot of potentially complex "features" and RFC 5280 did not kill off as many as some of would have liked :-). So, profiling certs (and CRLs) for the RPKI makes sense. Allowing unknown, non-critical extensions would undermine this stragey. Much as I liked Jon Postel, and worked with him on the IAB for a decade, his oft cited dictum is bad design advice in the security arena. I also note that we want to impose these constraints on both CAs and RPs, because we have lots of examples of CAs issuing "bad" certs, accidentally. se want to use RP strictness to help "motivate" CAs to do the right thing :-). I must admit that I found it a bit amusing that you chose to illustrate the potential for a change that would motivate being less stringent by citing RFC 3779, which you noted didn't have the problem in question :-). (Also note that integers usually are not very much constrained in ASN.1 in general, so the observation you made there seems a bit odd to me.) Nonetheless, I get your point. My response is that IF we discover a need to change the profile, we could do so, e.g., by changing the cert policy (since the policy is specified in the CP, which references this version of the cert profile. Any change of this sort would have to be phased in over a long time scale. I suggest you look at the algorithm agility I-D for RPKI to see the sort of planning envisioned for that sort of change. I do agree that there is a typo in the doc, re the validity interval. Sean noted that after the doc was released, and we agreed that it can be fixed after last call. Steve From jhutz@cmu.edu Thu Mar 10 19:34:56 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 516593A686E; Thu, 10 Mar 2011 19:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-fmjO+a4-p1; Thu, 10 Mar 2011 19:34:55 -0800 (PST) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by core3.amsl.com (Postfix) with ESMTP id 2F3103A67EC; Thu, 10 Mar 2011 19:34:55 -0800 (PST) Received: from [128.2.184.182] (JHUTZ-DYN5.PC.CS.CMU.EDU [128.2.184.182]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id p2B3aBbN009705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Mar 2011 22:36:12 -0500 (EST) From: Jeffrey Hutzelman To: Paul Hoffman In-Reply-To: <18075_1299785510_p2AJVnAa005345_4D79271E.6080707@vpnc.org> References: <4D791B26.8020001@vpnc.org> <18075_1299785510_p2AJVnAa005345_4D79271E.6080707@vpnc.org> Content-Type: text/plain; charset="UTF-8" Date: Thu, 10 Mar 2011 22:36:11 -0500 Message-ID: <1299814571.28172.111.camel@destiny> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: secdir@ietf.org, draft-ietf-sidr-res-certs@tools.ietf.org, Sam Hartman , ietf@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-sidr-res-certs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 03:34:56 -0000 On Thu, 2011-03-10 at 11:31 -0800, Paul Hoffman wrote: > for changes that need to change the system's semantics, you > change the certificates in a way that relying parties that don't > understand the change won't accept the certificate. Sure. The way to do that is to issue a certificate with a critical extension. An RP encountering a certificate with a critical extension it doesn't understand will not accept the certificate. What the profile does as written is require RP's to treat all extensions as critical, even if they are not so marked. That reduces flexibility without gaining anything in return. In particular, we don't gain the ability to make a change that will prevent certificates from being accpted by RPs that don't understand them, because we already had that. Steve noted a desire to limit the liability of entities acting as CAs in the RPKI. I agree that goal is desirable, and restrictions on what certificates issued by those CAs can contain help to do that (provided the CAs actually comply). However, requiring compliant RPs to treat all extensions as critical does _not_ help, because an RP which incorrectly accepts an over-broad RPKI certificate for some other purpose is probably not an implementation of this profile and thus not bound by the restriction. --Jeff From magnusn@gmail.com Thu Mar 10 22:32:03 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C689F3A6892; Thu, 10 Mar 2011 22:32:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGJmKchnBxnQ; Thu, 10 Mar 2011 22:31:56 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id F36453A6845; Thu, 10 Mar 2011 22:31:54 -0800 (PST) Received: by iyj8 with SMTP id 8so2856559iyj.31 for ; Thu, 10 Mar 2011 22:33:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Zy9w3lXfSqyAfmAgT70+cqzZRShvfjhNMAp+yIQr3HA=; b=TT1tWM33mT/ekYfdCUrPfQJzyWztuGFVc7zbrYWcKD4vfGrL18ZdUEOn8FWarwkJtk CPwmdIDRTUd1unIcPzX8YsNPbrgpvzZf+kF9tlCqcTqwp5Fny15RK0adwgfIzHxbIXYF 6IFSbU0MkhHUpAhhBjxNi5i5DqOWPIjHiuph8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=PafONJDWlJcGBxMAsbiCzAJXR5gfeNrAap7C8CGyjj9JyXFT8DTWgsY61xUmy6FlwZ xSmdjoa84LPQvaa0fcd4ewzy8fqoqWFlj56iXSndnCUCG0VxdO33UzYO/6BsAGXZMi0m sem50zmLbSFDuPf4Ect+Q8bQwhBw+uE5uk4zM= MIME-Version: 1.0 Received: by 10.43.64.135 with SMTP id xi7mr11230840icb.168.1299825193564; Thu, 10 Mar 2011 22:33:13 -0800 (PST) Received: by 10.231.11.140 with HTTP; Thu, 10 Mar 2011 22:33:13 -0800 (PST) In-Reply-To: <648DF71C-4CF5-45B0-84CD-9230DE9D0B6F@checkpoint.com> References: <648DF71C-4CF5-45B0-84CD-9230DE9D0B6F@checkpoint.com> Date: Thu, 10 Mar 2011 22:33:13 -0800 Message-ID: From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "draft-ietf-ipsecme-failure-detection@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ipsecme-failure-detection-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 06:32:04 -0000 Yoav, Thanks for your quick response. Inline... On Wed, Mar 9, 2011 at 11:50 PM, Yoav Nir wrote: > Hi Magnus, thanks for the review. =A0My answers are inline. > > > On Mar 7, 2011, at 9:14 AM, Magnus Nystr=F6m wrote: > >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. =A0These 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 new extension (the "QCD token") to the IKEv2 >> protocol that allows for faster detection of SA de-synchronization. >> >> - General: >> =A0o "Quick Crash Detection": Is "crash" really the right term here? As >> the document indicates, the SA de-synchronization may have had other >> reasons than a crash...? The term "failure detection" seems more >> accurate. > > There are indeed several reasons why an IKE implementation might lose sta= te. There's bugs in implementations or underlying operating systems, which = may cause state loss, and are colloquially referred to as "crashes", there = are power interruptions, and every product that I know of also has a user i= nterface command to clear state. =A0At least the last of these is not even = a failure at all. =A0So we might have termed this "Quick State Desynchroniz= ation Detection" (QSDD?), but crashes were the primary motivation for writi= ng this, so we have used the name QCD from the start. =A0I think it stay, a= s long as the introduction says that it's OK. OK >> - Section 1, Introduction: >> =A0o "However, in many cases the rebooted peer is a VPN gateway that >> protects only servers, or else the non-rebooted peer has a dynamic IP >> address" - it is not clear from this how or why the dynamic IP address >> of the non-rebooted peer impacts the tunnel re-establishment? > > I agree it is a little confusing and should be split into two sentences. = How about: > > However, in many cases the rebooted peer is a VPN gateway that protects o= nly server, so all traffic is inbound. In other cases, the non-rebooted pee= r has a dynamic IP address, so the rebooted peer cannot initiate IKE becaus= e its current IP address is unknown. Yes, much clearer IMO. >> =A0o Editorial: "is a quick" -> "in a quick"? > > Yes. Thanks. > >> >> - Section 2, RFC 5996 Crash Recovery : >> =A0o "There are cases where the peer loses state and is able to recover >> immediately; in those cases it might take several minutes to recover." >> - so a peer is able to recover immediately, yet it might take several >> minutes to recover?? Unclear what is meant here. > > How about "in those cases it might still take several minutes to recover = the IPsec SAs." Thanks; that's clearer. >> - Section 5, Token Generation and Verification: >> =A0o (Not sure why these methods are called stateless as the QCD_SECRET >> must be maintained?) > > That's because they don't have a per-tunnel persistent state. An obvious = (though never described) alternative is to generate a random token for each= IKE SA, and store that in non-volatile storage. This was actually the desi= gn in one of the early drafts. > >> =A0o By adding a nonce to the token generation the attack outlined in >> Section 9.3 would be impossible, as the attacker would also need to >> guess the nonce (adding a nonce to the TOKEN_SECRET_DATA generation >> would also have the effect that even for the same SPIs, the >> TOKEN_SECRET_DATA would be different). More generally, a standard key >> derivation scheme such as the Concatenation KDF in NIST SP 800-56 may >> be considered. > > Yes, but then we would have to keep the nonce in state for each IKE SA, a= nd this would vastly increase the non-volatile storage requirements. The go= al is for the rebooted gateway to generate the correct token based only on = an encrypted (with keys it doesn't have) IKE packet. OK.But I still think SP 800-56A's Concat KDF could or should be considered. It would map SPI-I and SPI-R as PartyUInfo and PartyVInfo and for "free" you would be NIST-compatible. No nonce is required. >> - Section 9.2, Security Considerations: >> =A0o Last paragraph: "This method should not be used..." - unclear what >> method is being referred to here? > > Seems clear to me. The first sentence in that paragraph talks about the m= ethod in section 5.2. The following sentences begin with "This method...", = referring to the same method. I see the text has changed slightly; A minor clarification could be to replace the last "that method" with "The method in Section 5.2". >> - Appendix A.2: >> =A0o Would have been useful with a sentence or two that indicated why >> the working group preferred the QCD proposal over the SIR one. > > OLD: > =A0 The working group preferred the QCD proposal to this one. > > NEW: > =A0 The working group preferred the QCD proposal to this one, because > =A0 of the lack of cryptographic protection for the queries and > =A0 responses. Thanks! -- Magnus From mlepinski@bbn.com Fri Mar 11 07:13:15 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE4E53A6B81 for ; Fri, 11 Mar 2011 07:13:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4w64ztKF+FZ for ; Fri, 11 Mar 2011 07:13:14 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id C9B2F3A680D for ; Fri, 11 Mar 2011 07:13:14 -0800 (PST) Received: from [128.89.254.142] (port=1103) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Py42z-000Lnq-Ns; Fri, 11 Mar 2011 10:14:33 -0500 Message-ID: <4D7A3C83.80209@bbn.com> Date: Fri, 11 Mar 2011 10:15:15 -0500 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: draft-ietf-dime-nat-control@tools.ietf.org, secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] Secdir review of draft-ietf-dime-nat-control-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 15:13:15 -0000 [I apologize if you received this message twice] 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 Diameter application whereby a Diameter NAT Control Application (DNCA) server (either a AAA server or a Network Access Server) can control a DNCA client (either a NAT or NAPT device). For example, the DNCA server can determine the number of port bindings available to a given host, cause the allocation of particular NAT bindings, define the external address pool used for by the NAT device, or generate reports used for accounting purposes. The principle security concern is that an unauthorized (or unauthenticated) DNCA server could effect a denial of service of attack on any or all hosts using a NAT/NAPT device in several ways. (E.g., an unauthorized server could exhaust resources in the NAPT device, set maximum bindings to zero for all hosts, provide a set of external addresses that are in use elsewhere in the network, etc.) An additional concern is that an unauthenticated DNCA client could provide incorrect reporting data to the DNCA server to prevent correct accounting within the system. Therefore, the NAT control application requires mutual authentication, authorization of the DNCA server, and integrity protection of the Diameter messages in the DNCA interaction. Additionally, the application may require confidentiality depending on the deployment scenario and, particularly, how authorization is accomplished. The Security Considerations section of the document claims that security considerations are essentially the same as in the Diameter QoS (RFC 5866). I agree with the authors that the security concerns for Diameter NAT Control are very similar to the security concerns for Diameter QoS, but I think the additional layer of indirection is not helpful to the reader. (In particular, the NAT Control Application has no dependencies on the Diameter QoS document. Therefore it is reasonable to believe that an implementer of Diameter NAT Control may not be familiar with the Diameter QoS document.) I would recommend that the authors add additional text explaining why mutual authentication, server authorization, and message integrity are required (copying a bit of text from RFC 5866 may be appropriate). Then I would recommend that the authors cite the Diameter specification (RFC 3588) for a discussion of how IPsec or TLS can be used to obtain these security properties. (To me, this seems preferable to sending a reader to RFC 5866 for discussion of required security properties, which in turn sends the reader to RFC 3588 for an information on the use of IPsec or TLS to achieve these properties.) Finally, the end of the security considerations section claims that "Authorization between DNCA Agent and DNCA Manager is beyond the scope of this document". I understand that the authors do not want to mandate a particular mechanism for making an authorization decision. That being said, providing some guidance as to how a DNCA client would determine if a DNCA server were authorized to issue NAT control commands. I imagine in practice that the way authorization is accomplished is that the NAT/NAPT device stores a local authorization policy. (E.g., the device stores a list of server identities that authorized, and then once the server has been authenticated its identity can be checked against the list). At the very least having text analogous to first paragraph of RFC 5866 Section 11 would be helpful (RFC 5866 says the device making the authorization decision needs to have sufficient information to make this decision and then provides examples of where this information would come from.) - Matt Lepinski From ynir@checkpoint.com Wed Mar 9 23:49:36 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 574DB3A67FA; Wed, 9 Mar 2011 23:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.419 X-Spam-Level: X-Spam-Status: No, score=-10.419 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XtCp1lHWAMc; Wed, 9 Mar 2011 23:49:35 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id E3F403A67EF; Wed, 9 Mar 2011 23:49:34 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p2A7omYk005506; Thu, 10 Mar 2011 09:50:48 +0200 X-CheckPoint: {4D7882BB-1-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 10 Mar 2011 09:50:48 +0200 From: Yoav Nir To: =?iso-8859-1?Q?Magnus_Nystr=F6m?= Date: Thu, 10 Mar 2011 09:50:54 +0200 Thread-Topic: Secdir review of draft-ietf-ipsecme-failure-detection-05 Thread-Index: Acve996V76BNQ+NgTrOULn70eOVlpw== Message-ID: <648DF71C-4CF5-45B0-84CD-9230DE9D0B6F@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 11 Mar 2011 08:19:10 -0800 Cc: "draft-ietf-ipsecme-failure-detection@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ipsecme-failure-detection-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 07:49:36 -0000 Hi Magnus, thanks for the review. My answers are inline. On Mar 7, 2011, at 9:14 AM, Magnus Nystr=F6m wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > This document defines a new extension (the "QCD token") to the IKEv2 > protocol that allows for faster detection of SA de-synchronization. >=20 > - General: > o "Quick Crash Detection": Is "crash" really the right term here? As > the document indicates, the SA de-synchronization may have had other > reasons than a crash...? The term "failure detection" seems more > accurate. There are indeed several reasons why an IKE implementation might lose state= . There's bugs in implementations or underlying operating systems, which ma= y cause state loss, and are colloquially referred to as "crashes", there ar= e power interruptions, and every product that I know of also has a user int= erface command to clear state. At least the last of these is not even a fa= ilure at all. So we might have termed this "Quick State Desynchronization = Detection" (QSDD?), but crashes were the primary motivation for writing thi= s, so we have used the name QCD from the start. I think it stay, as long a= s the introduction says that it's OK. >=20 > - Section 1, Introduction: > o "However, in many cases the rebooted peer is a VPN gateway that > protects only servers, or else the non-rebooted peer has a dynamic IP > address" - it is not clear from this how or why the dynamic IP address > of the non-rebooted peer impacts the tunnel re-establishment? I agree it is a little confusing and should be split into two sentences. Ho= w about: However, in many cases the rebooted peer is a VPN gateway that protects onl= y server, so all traffic is inbound. In other cases, the non-rebooted peer = has a dynamic IP address, so the rebooted peer cannot initiate IKE because = its current IP address is unknown. > o Editorial: "is a quick" -> "in a quick"? Yes. Thanks. >=20 > - Section 2, RFC 5996 Crash Recovery : > o "There are cases where the peer loses state and is able to recover > immediately; in those cases it might take several minutes to recover." > - so a peer is able to recover immediately, yet it might take several > minutes to recover?? Unclear what is meant here. How about "in those cases it might still take several minutes to recover th= e IPsec SAs." >=20 > - Section 5, Token Generation and Verification: > o (Not sure why these methods are called stateless as the QCD_SECRET > must be maintained?) That's because they don't have a per-tunnel persistent state. An obvious (t= hough never described) alternative is to generate a random token for each I= KE SA, and store that in non-volatile storage. This was actually the design= in one of the early drafts. > o By adding a nonce to the token generation the attack outlined in > Section 9.3 would be impossible, as the attacker would also need to > guess the nonce (adding a nonce to the TOKEN_SECRET_DATA generation > would also have the effect that even for the same SPIs, the > TOKEN_SECRET_DATA would be different). More generally, a standard key > derivation scheme such as the Concatenation KDF in NIST SP 800-56 may > be considered. Yes, but then we would have to keep the nonce in state for each IKE SA, and= this would vastly increase the non-volatile storage requirements. The goal= is for the rebooted gateway to generate the correct token based only on an= encrypted (with keys it doesn't have) IKE packet. >=20 > - Section 9.2, Security Considerations: > o Last paragraph: "This method should not be used..." - unclear what > method is being referred to here? Seems clear to me. The first sentence in that paragraph talks about the met= hod in section 5.2. The following sentences begin with "This method...", re= ferring to the same method.=20 >=20 > - Appendix A.2: > o Would have been useful with a sentence or two that indicated why > the working group preferred the QCD proposal over the SIR one. OLD: The working group preferred the QCD proposal to this one. NEW: The working group preferred the QCD proposal to this one, because=20 of the lack of cryptographic protection for the queries and=20 responses. >=20 > -- Magnus From prvs=2050876065=jherzog@ll.mit.edu Thu Mar 10 12:40:43 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFA133A6A2F; Thu, 10 Mar 2011 12:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.847 X-Spam-Level: X-Spam-Status: No, score=-5.847 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqY8onbFffYz; Thu, 10 Mar 2011 12:40:39 -0800 (PST) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by core3.amsl.com (Postfix) with ESMTP id C25A53A69F1; Thu, 10 Mar 2011 12:40:37 -0800 (PST) Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id p2AKfr38006704; Thu, 10 Mar 2011 15:41:53 -0500 From: "Herzog, Jonathan - 0668 - MITLL" To: David McGrew Date: Thu, 10 Mar 2011 15:41:52 -0500 Thread-Topic: [secdir] Secdir review of draft-herzog-static-ecdh-05 Thread-Index: AcvfY5aiZDxPn8h4ScW7DlnSEoXROg== Message-ID: <63667400-81DF-438E-869F-247222DECA18@ll.mit.edu> References: <552BBAA9-712F-49B4-8A5F-C671C3817C05@ll.mit.edu> <47CF9528-81A1-49D7-8D4B-B1DCC136581E@ll.mit.edu> <3E69AF7B-D325-4FC5-A003-FEBA1997D67E@cisco.com> <65D56695-894D-458E-A9C4-6DCF6A38F196@cisco.com> <29C1F1D5-6EF0-4055-BA88-03F03E3F0A84@ll.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-167--640034663"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-10_10:2011-03-10, 2011-03-10, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=8 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1012030000 definitions=main-1103100151 X-Mailman-Approved-At: Fri, 11 Mar 2011 08:19:10 -0800 Cc: "secdir@ietf.org" , "draft-herzog-static-ecdh@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 20:40:43 -0000 --Apple-Mail-167--640034663 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 10, 2011, at 1:12 PM, David McGrew wrote: >=20 >=20 >>=20 >> However, SP800-56A does define cofactor ECDH. So let me propose the =20= >> following citation scheme: >>=20 >> * ECDH in general: RFC 6090 >> * Standard ECDH: RFC 6090 >> * Co-factor Diffie-Hellman: SP 800-56A, Section 5.7.1.2 >> * Full public-key validation: SP800-56A, Section 5.6.2.5 >> * Partial public-key validation: SP800-56A: Section 5.6.2.6 >> * Key-derivation function... still working on it. >>=20 >> Thoughts? >=20 > That looks good to me. Let me know if I can help with the KDF. I'd appreciate it, thanks. One of the goals of this draft is to remain = as compatible with RFC 5753 as possible, so as to impact implementations = as little as possible. RFC 5753, for its part, specifies the KDF in = SEC1. And the KDF in SEC1 is just the 'simple hash function construct = described in ANSI X9.63'. So, do you think I can cite X9.63 as the = normative reference? And if so, what are your thoughts on citing SEC1 as = an informative reference for this KDF? SEC1 is, after all, freely = available on the web. (Note: I'm still chasing down the ANSI spec to ensure that it does, in = fact, match the description in SEC1.) Thanks. --=20 Jonathan Herzog voice: = (781) 981-2356 Technical Staff fax: = (781) 981-7687 Cyber Systems and Technology Group email: = jherzog@ll.mit.edu MIT Lincoln Laboratory www: = http://www.ll.mit.edu/CST/ 244 Wood Street =20 Lexington, MA 02420-9185 --Apple-Mail-167--640034663 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJrzCCBNIw ggO6oAMCAQICChVM3JYAAAAAIh8wDQYJKoZIhvcNAQEFBQAwUTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwg Q0EtMTAeFw0xMDA1MjUyMDQ1MzhaFw0xMTA1MjUyMDQ1MzhaMGQxCzAJBgNVBAYTAlVTMR8wHQYD VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQZW9wbGUxIzAhBgNVBAMTGkhl cnpvZy5Kb25hdGhhbi5DLjUwMDExMzA1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 93mr5a6zq6EQsVtIX9BadxwzpjabF8pvDmoMSP/ZhbWrncNJ1j7xiBGcihYqsDaQz9+hJITxi7IM NUx5fnFtOQRHZgkOCLR1URFc0AlJ3Pknv6XoQ4fqPODmSMB882c9l/8AbO7N/27r8n/V0Ip4Rpw8 1qnrDXk6UH/1zHlssGmlVng0RSREuQy98xPxzbLr5cOMWLwHs5OLNYcGv0KlD6rp1DPzJ3qplU/+ 0P2jyYbGyXStJ/h+3Kx5mOWFLB4j8HDyLG90ZHlZjZXo9FrSoFubVJK/mdVzIuXd00Ldl1fCyxhR D9elkpTc7xOLJsEzCCi8Gqo6eQuvz1RH93u3PwIDAQABo4IBlzCCAZMwDgYDVR0PAQH/BAQDAgbA MB0GA1UdDgQWBBRPjG6+CxR6H/o9vyq5PgmW9vmuajAfBgNVHSMEGDAWgBSUWsZYybYmm6AJe6gv ZJDDiQJuKjAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xM Q0ExMGIGCCsGAQUFBwEBBFYwVDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dHRvL0xMQ0ExMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5sbC5taXQuZWR1LzAMBgNVHRMBAf8E AjAAMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH /4pzAgFkAgEFMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8w DQYLKoZIhvcSAgEDAQgwHQYDVR0RBBYwFIESamhlcnpvZ0BsbC5taXQuZWR1MA0GCSqGSIb3DQEB BQUAA4IBAQBI6aoe1c6Glzs3Hh/lIzf2TzmtZSQLl8UZaIFGi0zG0EjsO6wjX6bfv/WizE30OEef 6So76p0dNt7j21lrH+FGaH6r41ggikbkoazNkAePsQk0WPZhmpus1rByNUozK4KMPpzLAynHNd5m POtqoIwDiTEgktLuZ1nwU7bUHmv7BO14dkhLhMOFKRCIi3vqe9rDh9pTYt1YNhQe1fBme6Y5DWLA TxBBqErz05e7rVngKi6yk6j7cqWpiM6L93z2Zq5p9FqACsJHmMwxH/8XFeeXgFf/CKMAIuSZCGFU 29ouEZWL7LLu87SFGm3f/3sLS7xgXei7d/PlXte1HKKdKOCPMIIE1TCCA72gAwIBAgIKFU5e0QAA AAAiIDANBgkqhkiG9w0BAQUFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4g TGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xMB4XDTEwMDUyNTIw NDcxN1oXDTExMDUyNTIwNDcxN1owZDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xu IExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEjMCEGA1UEAxMaSGVyem9nLkpvbmF0aGFuLkMu NTAwMTEzMDUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtC8sNdkCteQagOVEnQQs4 5uLqsmaOfjqTywNWuvaVj0F8Jsek8bOcuK4rlB1PrBk0Q+s/N4FVcGEn6BEDWRIDFaETVr1jweTE yRUtqngTIvpbpeixV37BcFkVnbV2VrZC5oaa0c0bkxXkuE0lohQS5AIBXQRADEJVnfXIM44yvsmo T7J5rdGwjIg4QJ2YA07po0JkbndcylcjU0zW2Lv432MEZrX/o+T0rraFAhT8A+8De9CIo0LJkXCK cNwk6LwuNKQS0qeezDo5wRiqZaht3ftiAuOImOxN44hxnDa2cHVbOFQ+pevN08gH7d39CVHUbHMC PnuIBoQNu61I2+ItAgMBAAGjggGaMIIBljAOBgNVHQ8BAf8EBAMCBSAwHQYDVR0OBBYEFEuYUJcI JTs8b2SWTJN28DD/qqsNMB8GA1UdIwQYMBaAFJRaxljJtiaboAl7qC9kkMOJAm4qMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTEwYgYIKwYBBQUHAQEE VjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTEwIwYIKwYB BQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUH BDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0l BB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMB CDAdBgNVHREEFjAUgRJqaGVyem9nQGxsLm1pdC5lZHUwDQYJKoZIhvcNAQEFBQADggEBAAmf5m3W 0Di4aQhLS1e2xejG3MQPQJvWL3dHbnHYG+NDVFWcuqyE5t73eb7nV2UyGRVHDt6MyIquedAPPm86 FSPZ6CUGGj5imp9pAu7C+xESBMY4z0k5htK/h5vlSB9X/i3JbXI8KBOioH1QYenMfrvTISmk/+5A BHsMDOpK7//bX66DP+iopoIiWJktY+dfiak7uTZhuYEOmICq4QlP9dDqdPiQGje4Y8xZ45YL6+2I m5GIzuIac/r51YTBuCk+TxTZIITMx+Fr50Ur6s4dOnvApxMR7iZX6oKnmVfXrjFMMQxR1TN5ISUn IoMyID3yCiInqQh6G3WPCAhwa/qG/moxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYD VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExM IENBLTECChVM3JYAAAAAIh8wCQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTEwMzEwMjA0MTUyWjAjBgkqhkiG9w0BCQQxFgQUg7B9v5HGWLPY CvtamtfByFEoT8gwbgYJKwYBBAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xAgoV Tl7RAAAAACIgMHAGCyqGSIb3DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xAgoV Tl7RAAAAACIgMA0GCSqGSIb3DQEBAQUABIIBAL0oYXbiJ4O/RODAcKxuFcPY2YjF19QXibOi37cn 0AMQ9OkU0ylOGmd93r/soelrlhr82//LqZTqMBbi96Mvv1x1sMJDH/zyZ3eMB2E/LYtGl/uPiTcB Jpbz23mLnuhBI8cmolNQPWUvfX0EAsxHv3HQqeq3SslZV8WGj8jPLSlOgN+P4Hm061cpRpyqIU42 IDFxCPQEr5DsYGMA65CkDqLbFjmaw60oAMkPnCILmQ4q+Ebc0r5Rl2+Ydbf5POSQ5Ea4Q2lWqUsh 4OfmhGL33y8uvR2IkdFpLP18o0u5m45O7siJuxtnjDqUpszhSOWlaC4Pk59lW6JraQrBYkRmi84A AAAAAAA= --Apple-Mail-167--640034663-- From prvs=2050876065=jherzog@ll.mit.edu Thu Mar 10 13:01:42 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E7EC3A6945; Thu, 10 Mar 2011 13:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.847 X-Spam-Level: X-Spam-Status: No, score=-5.847 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMuwgirt2D+G; Thu, 10 Mar 2011 13:01:41 -0800 (PST) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by core3.amsl.com (Postfix) with ESMTP id D5EA03A67F8; Thu, 10 Mar 2011 13:01:40 -0800 (PST) Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id p2AL2qsA027860; Thu, 10 Mar 2011 16:02:52 -0500 From: "Herzog, Jonathan - 0668 - MITLL" To: Stephen Farrell Date: Thu, 10 Mar 2011 16:02:51 -0500 Thread-Topic: [secdir] Secdir review of draft-herzog-static-ecdh-05 Thread-Index: AcvfZoTngIbDfpYOSEivledSPY2ZZw== Message-ID: <7896C06F-C680-4794-9DB3-CDC84CA5579D@ll.mit.edu> References: <552BBAA9-712F-49B4-8A5F-C671C3817C05@ll.mit.edu> <47CF9528-81A1-49D7-8D4B-B1DCC136581E@ll.mit.edu> <3E69AF7B-D325-4FC5-A003-FEBA1997D67E@cisco.com> <4D77E3AE.5060903@cs.tcd.ie> <4D780411.9060108@cs.tcd.ie> In-Reply-To: <4D780411.9060108@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-169--638775773"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-10_10:2011-03-10, 2011-03-10, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=8 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1012030000 definitions=main-1103100154 X-Mailman-Approved-At: Fri, 11 Mar 2011 08:19:10 -0800 Cc: "secdir@ietf.org" , "draft-herzog-static-ecdh@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 21:01:42 -0000 --Apple-Mail-169--638775773 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 9, 2011, at 5:49 PM, Stephen Farrell wrote: >>=20 >> So, I propose to replace SEC1 with SP 800-56A for (1) and (2), and = some other RFC for (3). Would that address your concerns? >=20 > To be honest, I don't know for sure. I'm not familiar with how > NIST do or don't handle IPR so I don't know if the outcome > here will or won't make it easier for implementers to decide > whether or no to adopt this. But I think you're definitely > working in the right direction in the thread with David so > that's good. [and] > I wish;-) Not sure I've seen an RFC about ECC that didn't > come with an IPR declaration from them attached. (Though > the content of those declarations is improving.) Sean Turner has graciously agreed to step in and handle the IPR issues = of this draft, so I'll let him address this. >> We propose this draft because we would like to use CMS in an > environment where: >>=20 >> 1) Participants must use Suite-B algorithms, and therefore cannot use = ECMQV, and >>=20 >> 2) Participants will have certified ECDH keys but not certified = signature keys. (Yes, ECDH keys are mathematically identical to ECDSA = keys, but our participants will be constrained by various policies and = will be unable to use their ECDH keys for ECDSA signatures.) >>=20 >> Without this Draft, CMS supports only ECMQV (which we cannot use) and = ephemeral-static ECDH. In our setting, then, there is no way for = recipients to cryptographically ascertain the identity of a message's = sender.=20 >=20 > I think that's useful context for the intro. Based on this, and some other comments from Rene Struik, I will try to = make this clearer in the 'motivations' section of the Introduction. Thanks. --=20 Jonathan Herzog voice: = (781) 981-2356 Technical Staff fax: = (781) 981-7687 Cyber Systems and Technology Group email: = jherzog@ll.mit.edu MIT Lincoln Laboratory www: = http://www.ll.mit.edu/CST/ 244 Wood Street =20 Lexington, MA 02420-9185 --Apple-Mail-169--638775773 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJrzCCBNIw ggO6oAMCAQICChVM3JYAAAAAIh8wDQYJKoZIhvcNAQEFBQAwUTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwg Q0EtMTAeFw0xMDA1MjUyMDQ1MzhaFw0xMTA1MjUyMDQ1MzhaMGQxCzAJBgNVBAYTAlVTMR8wHQYD VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQZW9wbGUxIzAhBgNVBAMTGkhl cnpvZy5Kb25hdGhhbi5DLjUwMDExMzA1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 93mr5a6zq6EQsVtIX9BadxwzpjabF8pvDmoMSP/ZhbWrncNJ1j7xiBGcihYqsDaQz9+hJITxi7IM NUx5fnFtOQRHZgkOCLR1URFc0AlJ3Pknv6XoQ4fqPODmSMB882c9l/8AbO7N/27r8n/V0Ip4Rpw8 1qnrDXk6UH/1zHlssGmlVng0RSREuQy98xPxzbLr5cOMWLwHs5OLNYcGv0KlD6rp1DPzJ3qplU/+ 0P2jyYbGyXStJ/h+3Kx5mOWFLB4j8HDyLG90ZHlZjZXo9FrSoFubVJK/mdVzIuXd00Ldl1fCyxhR D9elkpTc7xOLJsEzCCi8Gqo6eQuvz1RH93u3PwIDAQABo4IBlzCCAZMwDgYDVR0PAQH/BAQDAgbA MB0GA1UdDgQWBBRPjG6+CxR6H/o9vyq5PgmW9vmuajAfBgNVHSMEGDAWgBSUWsZYybYmm6AJe6gv ZJDDiQJuKjAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xM Q0ExMGIGCCsGAQUFBwEBBFYwVDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dHRvL0xMQ0ExMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5sbC5taXQuZWR1LzAMBgNVHRMBAf8E AjAAMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH /4pzAgFkAgEFMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8w DQYLKoZIhvcSAgEDAQgwHQYDVR0RBBYwFIESamhlcnpvZ0BsbC5taXQuZWR1MA0GCSqGSIb3DQEB BQUAA4IBAQBI6aoe1c6Glzs3Hh/lIzf2TzmtZSQLl8UZaIFGi0zG0EjsO6wjX6bfv/WizE30OEef 6So76p0dNt7j21lrH+FGaH6r41ggikbkoazNkAePsQk0WPZhmpus1rByNUozK4KMPpzLAynHNd5m POtqoIwDiTEgktLuZ1nwU7bUHmv7BO14dkhLhMOFKRCIi3vqe9rDh9pTYt1YNhQe1fBme6Y5DWLA TxBBqErz05e7rVngKi6yk6j7cqWpiM6L93z2Zq5p9FqACsJHmMwxH/8XFeeXgFf/CKMAIuSZCGFU 29ouEZWL7LLu87SFGm3f/3sLS7xgXei7d/PlXte1HKKdKOCPMIIE1TCCA72gAwIBAgIKFU5e0QAA AAAiIDANBgkqhkiG9w0BAQUFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4g TGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xMB4XDTEwMDUyNTIw NDcxN1oXDTExMDUyNTIwNDcxN1owZDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xu IExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEjMCEGA1UEAxMaSGVyem9nLkpvbmF0aGFuLkMu NTAwMTEzMDUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtC8sNdkCteQagOVEnQQs4 5uLqsmaOfjqTywNWuvaVj0F8Jsek8bOcuK4rlB1PrBk0Q+s/N4FVcGEn6BEDWRIDFaETVr1jweTE yRUtqngTIvpbpeixV37BcFkVnbV2VrZC5oaa0c0bkxXkuE0lohQS5AIBXQRADEJVnfXIM44yvsmo T7J5rdGwjIg4QJ2YA07po0JkbndcylcjU0zW2Lv432MEZrX/o+T0rraFAhT8A+8De9CIo0LJkXCK cNwk6LwuNKQS0qeezDo5wRiqZaht3ftiAuOImOxN44hxnDa2cHVbOFQ+pevN08gH7d39CVHUbHMC PnuIBoQNu61I2+ItAgMBAAGjggGaMIIBljAOBgNVHQ8BAf8EBAMCBSAwHQYDVR0OBBYEFEuYUJcI JTs8b2SWTJN28DD/qqsNMB8GA1UdIwQYMBaAFJRaxljJtiaboAl7qC9kkMOJAm4qMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTEwYgYIKwYBBQUHAQEE VjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTEwIwYIKwYB BQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUH BDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0l BB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMB CDAdBgNVHREEFjAUgRJqaGVyem9nQGxsLm1pdC5lZHUwDQYJKoZIhvcNAQEFBQADggEBAAmf5m3W 0Di4aQhLS1e2xejG3MQPQJvWL3dHbnHYG+NDVFWcuqyE5t73eb7nV2UyGRVHDt6MyIquedAPPm86 FSPZ6CUGGj5imp9pAu7C+xESBMY4z0k5htK/h5vlSB9X/i3JbXI8KBOioH1QYenMfrvTISmk/+5A BHsMDOpK7//bX66DP+iopoIiWJktY+dfiak7uTZhuYEOmICq4QlP9dDqdPiQGje4Y8xZ45YL6+2I m5GIzuIac/r51YTBuCk+TxTZIITMx+Fr50Ur6s4dOnvApxMR7iZX6oKnmVfXrjFMMQxR1TN5ISUn IoMyID3yCiInqQh6G3WPCAhwa/qG/moxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYD VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExM IENBLTECChVM3JYAAAAAIh8wCQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTEwMzEwMjEwMjUxWjAjBgkqhkiG9w0BCQQxFgQUfaLRZOOAlEje gUM8Zf223xBlrEUwbgYJKwYBBAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xAgoV Tl7RAAAAACIgMHAGCyqGSIb3DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xAgoV Tl7RAAAAACIgMA0GCSqGSIb3DQEBAQUABIIBAH6Zu2YW/NkTjpRw/bOsa+7CxidRI7pKtxzf2jup gJ1ob87caphdmm9pJ61Gi0nl9Ju/gvGYSYN/2JmKrOCEZQhOYR87+SjaqztmY7fg3ePslJr6o6fU wrXB4AJmi9ruV1sDTyyubnsRCwDgeH17QRZEeAIe5EJIIYFvyQSxOcPj+d3yI6+P8bTvN8REXd0/ 9sXT3wQeFdGnbPUc0G1Qbw5SVK8b2yxzO2E0pYjrLQaBc780UdXoCQq4gFDEA5djagYnreEybMSF daxwlylGyJV/ym1XVA1bZAcMO6VzDfPo4zBL+cIdGWtrzmiMIubPfiM9zypkBCd8WF7GtzaivxkA AAAAAAA= --Apple-Mail-169--638775773-- From mrex@sap.com Thu Mar 10 21:00:33 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FA0D3A6AD5; Thu, 10 Mar 2011 21:00:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.223 X-Spam-Level: X-Spam-Status: No, score=-10.223 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzF3FezuaZV0; Thu, 10 Mar 2011 21:00:32 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id DD8593A680D; Thu, 10 Mar 2011 21:00:31 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p2B4whgu000351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Mar 2011 05:58:48 +0100 (MET) From: Martin Rex Message-Id: <201103110458.p2B4wgaa024318@fs4113.wdf.sap.corp> To: kent@bbn.com (Stephen Kent) Date: Fri, 11 Mar 2011 05:58:42 +0100 (MET) In-Reply-To: from "Stephen Kent" at Mar 10, 11 07:21:22 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-Mailman-Approved-At: Fri, 11 Mar 2011 08:19:10 -0800 Cc: draft-ietf-sidr-res-certs@tools.ietf.org, hartmans-ietf@mit.edu, ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-sidr-res-certs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 05:00:33 -0000 Stephen Kent wrote: > > n to act as CAs , and we want to limit their liability. > One way to do this is to restrict the fields and extensions in > resource certs to make then not very useful for other applications. A CA should never sign extensions that it doesn't understand. Why has the RP to be bothered with this? A request "everything must be considered critical, even if not marked as such" implies that every conceivable extension can only be a constraint. With its original meaning, the "ciriticality" flag could be used to sort extensions into "constraints" (critical) and "capabilities" (non-critical). The problem with newly inventend constraints is that they require flag days. capabilities do not suffer from this, and allow for a smoother migration. > > I also note that we want to impose these constraints on both CAs and > RPs, because we have lots of examples of CAs issuing "bad" certs, > accidentally. se want to use RP strictness to help "motivate" CAs to > do the right thing :-). I don't think that this idea will work. The consumers of the technology will want things to interoperate, not to fail. And implementations will provide the necessary workarouds. Besides, such an idea is in conflict with rfc-2119 section 6 6. Guidance in the use of these Imperatives ... they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. -Martin From mary.ietf.barnes@gmail.com Fri Mar 11 06:19:23 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C05223A6C23 for ; Fri, 11 Mar 2011 06:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.448 X-Spam-Level: X-Spam-Status: No, score=-103.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCwbX+-MU1Yn for ; Fri, 11 Mar 2011 06:19:21 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id E20C53A6BD9 for ; Fri, 11 Mar 2011 06:19:20 -0800 (PST) Received: by vws12 with SMTP id 12so740891vws.31 for ; Fri, 11 Mar 2011 06:20:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ww+QG6FsJQPm3tEg1cZksQ/0RGwhOEqoQhLQ0kUvECI=; b=pzUSoGvITffVTk3gXKETDy+nxYyAQRlb4LR4rQJ7dKw0/W9kOX9UZbbpb18dnEMc/9 9gCI3m7TmxZrFM5wxE2FmuihgH9VMvyDXVs8o3m+wSvrRKRxeqF6OMk3JTk2HO+PWZ0H iVwfy+SRxgp+HURoacbLiglKo6qyR280tc33I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sMKo8Gx+P9cuwCx181zJnlDmHts7WEgNEorGEOUO4wVi+IvOFbqX7gLzpc/GU8T55Y 9wDbx+DisF/6gP6dQ0kBfSp5xv71OvLtmmsaQ8g11+Opj06uN5YKZ+913VclJ0wHnolJ +YE12vdzHST+riSuFjjFymhQGNtZVmpG4XNCE= MIME-Version: 1.0 Received: by 10.52.179.169 with SMTP id dh9mr8861749vdc.23.1299853239386; Fri, 11 Mar 2011 06:20:39 -0800 (PST) Received: by 10.52.162.202 with HTTP; Fri, 11 Mar 2011 06:20:39 -0800 (PST) In-Reply-To: References: Date: Fri, 11 Mar 2011 08:20:39 -0600 Message-ID: From: Mary Barnes To: Stephen Kent Content-Type: multipart/alternative; boundary=bcaec5171de59802e0049e35aa08 X-Mailman-Approved-At: Fri, 11 Mar 2011 08:19:10 -0800 Cc: secdir@ietf.org, spromano@unina.it, chris@ns-technologies.com, xcon-chairs@tools.ietf.org, hgs+xcon@cs.columbia.edu, rjsparks@nostrum.com Subject: Re: [secdir] review of draft-ietf-xcon-ccmp-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 14:19:23 -0000 --bcaec5171de59802e0049e35aa08 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Stephen, Thank you for the very thorough review. Responses are inline below [MB]. Mary. On Tue, Feb 22, 2011 at 9:50 PM, Stephen Kent wrote: > I reviewed this document (draft-ietf-xcon-ccmp-12) 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 long (111 page) document defines a protocol (CCMP) to manage > centralized conferencing consistent with the XCON framework. It enables > users who are "authenticated and authorized" to "create, manipulate, and > delete conference objects." I did not read the whole document. I focused= on > the security considerations section and sections referenced by it. > > The security considerations section is about 4 pages long, a pleasant > change from the one sentence or one paragraph SC sections I often encount= er. > > The SC section begins with a list of six security requirements posited fo= r > CCMP. Each requirement cites the relevant section of the document where t= he > mechanisms needed to fulfill the requirement are described. This is a nic= e > organizational approach, but half of the requirements are addressed in la= ter > subsections of the SC section, not in the CCMP definition that forms the > bulk of this document. > [MB] I'm not entirely clear on the concern here. Is the concern that the mechanisms to fulfill the requirements are within the security section rather than in the detailed protocol section? I think the approach was that in cases where it seemed to naturally fit, we included the text in the protocol section, whereas in others when we were reviewing security considerations we found gaps and thus included the details in the security section. Perhaps if we re-iterated such - i.e., add a statement something like the following at the end of section 10: " Of the considerations listed above, items 1 and 3 are addressed within the referenced sections earlier in this document. The remaining security considerations are addressed in detail in the following sections." An alternative, of course, is to move the details into the appropriate sections. [/MB] > Also, requirement #6 strays from the "requirement/reference" model, and > provides an inline description of RECOMMENDED DoS mitigation strategies. = It > might be better if some of the text associated with this requirement (e.g= ., > dealing with long request pending times) were moved to the relevant > section(s) of the document. > [MB] I agree. We should move the last three sentences to either the last paragraph of section 4.4 or to the paragraph in section 5 and replace the text in requirement 6 with something like the following: " Section x describes the use of a timer mechanism to alleviate the situation whereby CCMP commands pend indefinitely, which would increase the potential that pending requests can continue to increase when a server is receiving more requests than it can process within a specific time period." [/MB] > > The remainder of the SC section is divided into 3 subsections, dealing wi= th > a client contacting the "proper" conference server, user authentication a= nd > authorization, and the security and privacy of user identities. > > The first subsection (10.1) cites use of TLS (with server certificates) a= s > a secure transport, to enable a user (as a client) to authenticate the > identity of the server to which the user is connecting. The text calls fo= r > the server certificate to attest to the IP address or DNS name for the CM= PP > server, via a Subject Alternative Name (SAN). However, the discussion > includes an odd sentence: > > "If the client has external information as to the expected identity or > credentials of the proper conference server (e.g., a certificate > fingerprint), these checks MAY be omitted." > > It is not clear what the phrase "these checks" refers to with respect to > TLS checks on server certificate validity. For example, does this mean th= at > the TLS implementation is supposed to allow the user to provide a > certificate fingerprint as an input in lieu of the more common check of t= he > FQDN portion of a URI against selected fields from the server certificate= ? > [MB] "these checks" is referring to TLS in general and isn't prescribing behavior for TLS, but rather noting that if the client has other informatio= n (e.g., preconfigured) that provides assurance that the proper conference server has been contacted then there is no need for the conference server t= o authenticate its identity using TLS. [/MB] > The HTTPS RFC (2818) makes no mention of such a facility, and it is > outside the scope of the TLS RFC (5246). This text needs to be clarified. > [MB] The *this* in the text related to the statement above ("With the use o= f HTTP as a transport for CCMP, *this* is exactly....") is referring to the following text RFC 2818: " If a subjectAltName extension of type dNSName is present, that MUST be used as the identity." I almost think we could just delete that sentence entirely. [/MB] > A client would normally be expected to have a priori knowledge of some fo= rm > of server identity, e.g., a FQDN. If the client is able to contact the > server it needs this info, and it needs this info to be able to interpret > the server certificate as evidence of having contacted the "proper" serve= r. > So the fist part of the sentence above "If the client has external > information as to the expected identity =C5=A0 of the proper conference s= erver =C5=A0" > seems odd. The second option here "=C5=A0 (e.g., a certificate fingerpri= nt)" is > a different way of confirming that the proper server has been contacted, = but > it would not be a way of determining which server to contact in the first > place. > [MB] The server to contact in the first place is described in section 7 and is referenced in the first item in the list of considrations - perhaps a reference to such would be helpful. [/MB] > This text needs to be expanded upon to provide an unambiguous > characterization of the intended security requirement. > [MB] Agreed - hopefully the responses above address this concern. [/MB] > > Section 7 of the document describes how to determine the proper server > (fulfilling requirement #1 from the SC section), if it is not > pre-configured. That section calls for use of the DNS (via U-NAPTR > resolution) to acquire a URI for the server. If a URI is the server ID, t= hen > it makes sense to requires use of a FQDN SAN in a server certificate. (I = am > surprised that the document suggests an IP address SAN as an option for t= he > server certificate; who prefers hard-wired addresses over DNS names?) > [MB] While, an IP address isn't preferred, it is unfortunately a very commo= n mechanism with existing systems, some of which could be upgraded to support CCMP without changes to the server discovery/authentication mechanisms. [/MB] > There is no mention in Section 7 of a certificate fingerprint, so I sugge= st > removing this text. Also, there should be some discussion of the role of > DNSSEC here, i.e., if one is relying on NAPTR resolution to locate the > proper CMPP server, a spoofed DNS reply can lead the user to the wrong > server (even if the user can authenticate that server, via TLS). > [MB] Okay. [/MB] > > Section 10.2 describes the need for a user to authenticate to a conferenc= e > server, and it RECOMMENDs use of TLS, or use of a call signaling protocol= . > This text is a bit vague, as it does not cite any specific call signaling > protocols. It says "In the cases where a user is authorized via multiple > mechanisms, it is RECOMMENDED that the conference server correlate the > authorization of the CCMP interface with other authorization mechanisms - > e.g., PSTN users that join with a PIN and > control the conference using CCMP." The term "correlate" is ambiguous in > this context. > [MB] Agreed. We can add some text with SIP as an example of a call signalin= g protocol and include references. "associates" is likely a better verb than "correlate" and the former is used in a subsequent paragraph in the same context, so we'll change that. [/MB] > > For a user employing CMPP, the text does not indicate whether the > RECOMMENDATION is for TLS to be used to protect a password sent to a CMPP > server, or whether a user certificate is the goal. This text needs furthe= r > clarification. > [MB] Agreed. The recommendation is for the former as the protocol itself has a mechanism for the user to include a password in the CCMP requests. > > The discussion of a "conference user identifier" in Section 3.2 (and in > other sections) is not precise. Perhaps the XCON framework doc makes thi= s > concept clear, but it should be restated here for completeness. > [MB] Yeah - I can see the lack of precision. The XCON framework introduce= d the term XCON-Userid as a fundamental identifier in the framework. We did have more information on the XCON-Userid in section 3.2 but it was moved to the XCON data model as that provides the XML schema and the representation of the XCON-UserID in the conference objects carried in the CCMP messages. In addition, the IANA registration is included in the XCON data model. The XCON-UserID is represented by the 'entity' attribute in the element in the XML schema. In addition, the XCON-Userid is reflected in the confUserID in the CCMP Request messages. I can see that this isn't at all clear in the current text. I will update section 3.2 to clarify this. [/MB] > > There is a paragraph in this section discussing Role-based access control= . > It is unnecessarily vague. In an RBAC context > The user ID would be a role that is occupied by an authorized user. The > text here does not make this as clear as it could (should) be. > [MB] The intent of the current text is to note that elements in the XCON data model can be mapped directly to the RBAC elements (users, roles, objects and permissions) and that CCMP operations provide the necessary mechanisms to support the RBAC operations. The policy mechanisms (configuration and application of such) are out of scope, but the XCON data model provides the necessary data elements that are required to implement policy. The policy would be applied using the configured policy data based upon the specific data in the CCMP operation - e.g., setting roles using th= e "so-called role-assignment policies". I agree it could be stated more clearly. On your last point, the Users aspect of RBAC is represented in XCON with the "users" portion of an XCON conference object. The UserID is one element in a "user" element in the conference object. The the "users" element in the XCON data model is comprised of one or more "user" elements. The "user" element within the XCON data model also has a "role" element, s= o I don't think the sentence above "The user ID..." is how that would be stated. [/MB] > > The final subsection of this document (10.3) deals with security and > privacy for user identities. The writing in this subsection needs help a= s > there are a number of indefinite antecedents for pronouns scattered > throughout (and mismatches in number). Nonetheless, the privacy requireme= nts > put forth seem fairly simple. However, the text does not note that the CM= PP > server will know the identity of each participant (in order to implement = the > authorization functions in 10.2) and thus user anonymity needs to be > interpreted in that context. (If the user authenticates in the context of= a > role some additional privacy may be offered, but that too is not discusse= d.) > I saw no mention of whether CMPP provides a way for participants in a > conference to be made aware of whether they may be anonymous or invisible > participants on a call. It seems that this might be a reasonable feature = to > offer, if one offers the privacy features discussed here. > [MB] I think this section could be improved if we re-arrange the text such that it describes how a client can request levels of anonymity and then how the server handles the specific data elements used to reflect the level of anonymity for the user. As far as the conference server having visibility t= o all the information, that's obviously necessary, but as noted policy can control whether humans/an administrator has visibility to that information. I can add a statement clarifying that. As far as whether users know that they are anonymous, that is reflected in the conference data to which the client has access which is included in responses and in conference event package notifications. I can add text around that, as well. [/MB] --bcaec5171de59802e0049e35aa08 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Stephen,

Thank you for the very thorough review. =C2= =A0Responses are inline below [MB].

Mary.

<= div class=3D"gmail_quote">On Tue, Feb 22, 2011 at 9:50 PM, Stephen Kent <kent@b= bn.com> wrote:
I reviewed this document (draft-ietf-xcon-ccmp-12) as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.=C2=A0 These comments were written primarily for the benefit of the security area directors.=C2=A0 Document editors and WG chairs should treat these comments just like any other last call comments.
This long (111 page) document defines a protocol (CCMP) to manage centralized conferencing consistent with the XCON framework. It enables users who are "authenticated and authorized" to "create, manipulate, and delete conference objects." I did=C2=A0 not read the whole document. I focused on the security considerations section and sections referenced by it.

The security considerations section is about 4 pages long, a pleasant change from the one sentence or one paragraph SC sections I often encounter.

The SC section begins with a list of six security requirements posited for CCMP. Each requirement cites the relevant section of the document where the mechanisms needed to fulfill the requirement are described. This is a nice organizational approach, but half of the requirements are addressed in later subsections of the SC section, not in the CCMP definition that forms the bulk of this document.
[MB] I'm not entirely clear on the concern here. =C2=A0Is th= e concern that the mechanisms to fulfill the requirements are within the se= curity section rather than in the detailed protocol section? =C2=A0 I think= the approach was that in cases where it seemed to naturally fit, we includ= ed the text in the protocol section, whereas in others when we were reviewi= ng security considerations we found gaps and thus included the details in t= he security section. Perhaps if we re-iterated such - i.e., add a statement= something like the following at the end of section 10:
=C2=A0=C2=A0 =C2=A0 " Of the considerations listed above, items 1= and 3 are addressed within=C2=A0
=C2=A0=C2=A0 =C2=A0 =C2=A0 the = referenced sections earlier in this document. The remaining security =C2=A0=
=C2=A0=C2=A0 =C2=A0 =C2=A0 considerations are addressed in detai= l in the following sections."=C2=A0

An alternative, of course, is to move the details into = the appropriate sections. =C2=A0
[/MB]
=C2=A0
<= font color=3D"#000000">Also, requirement #6 strays from the "requirement/reference" model, and provides an inline description of RECOMMENDED DoS mitigation strategies. It might be better if some of the text associated with this requirement (e.g., dealing with long request pending times) were moved to the relevant section(s) of the document.
[MB] = =C2=A0I agree. =C2=A0We should move the last three sentences to either the = last paragraph of section 4.4 or to the paragraph in section 5 and replace = the text in requirement 6 with something like the following:
=C2=A0=C2=A0 =C2=A0 =C2=A0 " Section x describes the use of = a timer mechanism to alleviate the
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2= =A0 situation whereby CCMP commands pend indefinitely,
=C2=A0=C2= =A0 =C2=A0 =C2=A0 =C2=A0 which would increase=C2=A0the
=C2=A0=C2= =A0 =C2=A0 =C2=A0 =C2=A0 potential that pending requests can continue to in= crease when a
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 server is receiving more requests th= an it can process within a
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 spec= ific time period."
[/MB]

=C2= =A0=C2=A0

The remainder of the SC section is divided into 3 subsections, dealing with a client contacting the "proper" conference server, user authentication and authorization, and the security and privacy of user identities.

The first subsection (10.1) cites use of TLS (with server certificates) as a secure transport, to enable a user (as a client) to authenticate the identity of the server to which the user is connecting. The text calls for the server certificate to attest to the IP address or DNS name for the CMPP server, via a Subject Alternative Name (SAN). However, the discussion includes an odd sentence:

"If the client has external information as to the expected identity or credentials of the proper conference server (e.g., a certificate fingerprint), these checks MAY be omitted."

It is not clear what the phrase "these checks" refers to with respect to TLS checks on server certificate validity. For example, does this mean that the TLS implementation is supposed to allow the user to provide a certificate fingerprint as an input in lieu of the more common check of the FQDN portion of a URI against selected fields from the server certificate?
[MB] "= ;these checks" is referring to TLS in general and isn't prescribin= g behavior for TLS, but rather noting that if the client has other informat= ion (e.g., preconfigured) =C2=A0that provides assurance that the proper con= ference server has been contacted then there is no need for the conference = server to authenticate its identity using TLS. =C2=A0[/MB]
=C2=A0=C2=A0
The HTTPS RFC (2818) makes no mention of such a facility, and it is outside the scope of the TLS RFC (5246). This text needs to be clarified.
[MB] The *this* in the text related to the statement above (&q= uot;With the use of HTTP as a transport for CCMP, *this* is exactly....&quo= t;) is referring to the following text=C2=A0RFC 2818:
" If a subjectAltName extension =
of type dNSName is present, that MUST be used as the identity."
I almost think we could =
just delete that sentence entirely.=C2=A0
[/MB]=C2=A0
=


A client would normally be expected to have a priori knowledge of some form of server identity, e.g., a FQDN. If the client is able to contact the server it needs this info, and it needs this info to be able to interpret the server certificate as evidence of having contacted the "proper" server. So the fist part of the sentence above "If the client has external information as to the expected identity =C5=A0 of the proper conference server =C5=A0" seems odd.=C2= =A0 The second option here "=C5=A0 (e.g., a certificate fingerprint)"= is a different way of confirming that the proper server has been contacted, but it would not be a way of determining which server to contact in the first place.

=
[MB] The server to contact in the first place is described in section = 7 and is referenced in the first item in the list of considrations - perhap= s a reference to such would be helpful. [/MB]
=C2=A0
This text = needs to be expanded upon to provide an unambiguous characterization of the intended security requirement.
=C2=A0
[MB] = Agreed - hopefully the responses above address this concern.=C2=A0
[/MB]

Section 7 of the document describes how to determine the proper server (fulfilling requirement #1 from the SC section), if it is not pre-configured. That section calls for use of the DNS (via U-NAPTR resolution) to acquire a URI for the server. If a URI is the server ID, then it makes sense to requires use of a FQDN SAN in a server certificate. (I am surprised that the document suggests an IP address SAN as an option for the server certificate; who prefers hard-wired addresses over DNS names?)
[MB] While,= an IP address isn't preferred, it is unfortunately a very common mecha= nism with existing systems, some of which could be upgraded to support CCMP= without changes to the server discovery/authentication mechanisms. [/MB]
=C2=A0
There is no mention in Section 7 of a certificate fingerprint, so I suggest removing this text. Also, there should be some discussion of the role of DNSSEC here, i.e., if one is relying on NAPTR resolution to locate the proper CMPP server, a spoofed DNS reply can lead the user to the wrong server (even if the user can authenticate that server, via TLS).
[MB] Okay. [/MB]=C2=A0

Section 10.2 describes the need for a user to authenticate to a conference server, and it RECOMMENDs use of TLS, or use of a call signaling protocol. This text is a bit vague, as it does not cite any specific call signaling protocols. It says "In the cases where a user is authorized via multiple mechanisms, it is RECOMMENDED that the conference server correlate the authorization of the CCMP interface with other authorization mechanisms - e.g., PSTN users that join with a PIN and
control the conference using CCMP." The term "correlate" is ambiguous in this context.
[MB] Agr= eed. We can add some text with SIP as an example of a call signaling protoc= ol and include references. =C2=A0"associates" is likely a better = verb than "correlate" and the former is used in a subsequent para= graph in the same context, so we'll change that. [/MB]
=C2=A0
For a user employing CMPP, the text does not indicate whether the RECOMMENDATION is for TLS to be used to protect a password sent to a CMPP server, or whether a user certificate is the goal. This text needs further clarification.
[MB] A= greed. =C2=A0The recommendation is for the former as the protocol itself ha= s a mechanism for the user to include a password in the CCMP requests. =C2= =A0

The discussion of a "conference user identifier" in Section 3.2 (and in other sections) is not precise.=C2=A0 Perhaps the XCON framework doc makes this concept clear, but it should be restated here for completeness.
[MB] =C2=A0Yeah -= I can see the lack of precision. =C2=A0The XCON framework introduced the t= erm XCON-Userid as a fundamental identifier in the framework. =C2=A0We did = have more information on the XCON-Userid in section 3.2 but it was moved to= the XCON data model as that provides the XML schema and the representation= of the XCON-UserID in the conference objects carried in the CCMP messages.= In addition, the IANA registration is included in the XCON data model. The= XCON-UserID is represented by the 'entity' attribute in the <us= er> element in the XML schema. =C2=A0In addition, the XCON-Userid is ref= lected in the confUserID in the CCMP Request messages. =C2=A0I can see that= this isn't at all clear in the current text. =C2=A0I will update secti= on 3.2 to clarify this. =C2=A0[/MB]

There is a paragraph in this section discussing Role-based access control.=C2=A0 It is unnecessarily vague. In an RBAC context
The user ID would be a role that is occupied by an authorized user. The text here does not make this as clear as it could (should) be.
[MB] The intent of the current text= is to note that elements in the XCON data model can be mapped directly to = the RBAC elements (users, roles, objects and permissions) and that CCMP ope= rations provide the necessary mechanisms to support the RBAC operations. = =C2=A0The policy mechanisms (configuration and application of such) are out= of scope, but the XCON data model provides the necessary data elements tha= t are required to implement policy. =C2=A0The policy would be applied using= the configured policy data based upon the specific data in the CCMP operat= ion - e.g., setting roles using the "so-called role-assignment policie= s". =C2=A0 =C2=A0=C2=A0I agree it could be stated more clearly. =C2=A0= On your last point, the Users aspect of RBAC is represented in XCON with th= e "users" portion of an XCON conference object. =C2=A0The UserID = is one element in a "user" element in the conference object. =C2= =A0The =C2=A0the "users" element in the XCON data model is compri= sed of one or more "user" elements. =C2=A0The "user" el= ement within the XCON data model also has a "role" element, so I = don't think the sentence above "The user ID..." is how that w= ould be stated. [/MB]=C2=A0
=C2=A0

The final subsection of this document (10.3) deals with security and privacy for user identities.=C2=A0 The writing in this subsection needs help as there are a number of indefinite antecedents for pronouns scattered throughout (and mismatches in number). Nonetheless, the privacy requirements put forth seem fairly simple. However, the text does not note that the CMPP server will know the identity of each participant (in order to implement the authorization functions in 10.2) and thus user anonymity needs to be interpreted in that context. (If the user authenticates in the context of a role some additional privacy may be offered, but that too is not discussed.) I saw no mention of whether CMPP provides a way for participants in a conference to be made aware of whether they may be anonymous or invisible participants on a call. It seems that this might be a reasonable feature to offer, if one offers the privacy features discussed here.
[MB] I think t= his section could be improved if we re-arrange the text such that it descri= bes how a client can request levels of anonymity and then how the server ha= ndles the specific data elements used to reflect the level of anonymity for= the user. As far as the conference server having visibility to all the inf= ormation, that's obviously necessary, but as noted policy can control w= hether humans/an administrator has visibility to that information. =C2=A0I = can add a statement clarifying that. As far as whether users know that they= are anonymous, that is reflected in the conference data to which the clien= t has access which is included in responses and in conference event package= notifications. I can add text around that, as well.=C2=A0
[/MB]

--bcaec5171de59802e0049e35aa08-- From weiler+secdir@watson.org Fri Mar 11 12:10:44 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F1C33A6A68 for ; Fri, 11 Mar 2011 12:10:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0vK-W+LWyjw for ; Fri, 11 Mar 2011 12:10:40 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 6E71C3A6A4C for ; Fri, 11 Mar 2011 12:10:40 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p2BKBx00098685 for ; Fri, 11 Mar 2011 15:11:59 -0500 (EST) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p2BKBxrp098682 for ; Fri, 11 Mar 2011 15:11:59 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 11 Mar 2011 15:11:59 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Fri, 11 Mar 2011 15:11:59 -0500 (EST) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 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, 11 Mar 2011 20:10:44 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Glen Zorn is next in the rotation. For telechat 2011-03-17 Reviewer LC end Draft Dave Cridland T 2011-02-21 draft-ietf-sidr-arch-12 Love Hornquist-Astrand T 2011-02-21 draft-ietf-v6ops-v6-in-mobile-networks-03 Jeffrey Hutzelman T 2011-03-09 draft-zhu-mobility-survey-03 David McGrew T 2011-03-03 draft-ietf-sidr-iana-objects-01 Catherine Meadows T 2011-03-09 draft-ietf-ancp-protocol-15 Kathleen Moriarty T 2011-03-11 draft-ietf-intarea-server-logging-recommendations-03 Hilarie Orman T 2011-03-14 draft-ietf-httpbis-content-disp-06 Radia Perlman T 2011-03-14 draft-ietf-mip4-gre-key-extension-04 Eric Rescorla T 2011-03-14 draft-ietf-netext-pmip6-lr-ps-05 Carl Wallace TR2011-02-22 draft-herzog-setkey-03 For telechat 2011-04-14 Reviewer LC end Draft Sandy Murphy T 2011-03-23 draft-kanno-tls-camellia-00 Vincent Roca T - draft-ietf-netlmm-pmipv6-mib-04 Joe Salowey T 2011-04-01 draft-housley-rfc5008bis-00 Last calls and special requests: Reviewer LC end Draft Alan DeKok 2011-02-23 draft-ietf-isis-reg-purge-01 Shawn Emery 2011-02-21 draft-ietf-ecrit-phonebcp-16 Love Hornquist-Astrand 2011-03-16 draft-yevstifeyev-tn3270-uri-16 Charlie Kaufman 2011-03-08 draft-ietf-avtcore-ports-for-ucast-mcast-rtp-00 Scott Kelly 2011-03-18 draft-ietf-sipping-nat-scenarios-15 Julien Laganier 2011-03-04 draft-ietf-xcon-examples-08 David McGrew - draft-ietf-ecrit-framework-12 Russ Mundy 2011-01-04 draft-cardona-cablelabs-urn-05 Vincent Roca 2011-02-07 draft-reed-urn-dgiwg-02 Stefan Santesson 2011-03-23 draft-ietf-dccp-tfrc-rtt-option-04 Juergen Schoenwaelder 2011-03-18 draft-ietf-genarea-datatracker-community-06 Yaron Sheffer 2011-03-21 draft-ietf-ipfix-structured-data-05 Tina TSOU 2011-03-24 draft-ietf-ledbat-survey-05 Sam Weiler 2011-03-24 draft-ietf-sidr-roa-format-10 Brian Weis 2011-03-24 draft-ietf-sidr-rpki-algs-04 Nico Williams 2011-01-14 draft-yevstifeyev-http-headers-not-recognized-11 Nico Williams 2011-02-09 draft-ietf-rmt-bb-fec-raptorq-05 Nico Williams 2011-03-24 draft-ietf-sidr-rpki-manifests-09 Tom Yu 2011-03-23 draft-ietf-sidr-signed-object-03 Kurt Zeilenga 2011-03-22 draft-ietf-sidr-ta-06 From mcgrew@cisco.com Fri Mar 11 12:31:30 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E33EE3A692E; Fri, 11 Mar 2011 12:31:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.848 X-Spam-Level: X-Spam-Status: No, score=-109.848 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_OBFU_ALL=0.751, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpP-Ec+rQq88; Fri, 11 Mar 2011 12:31:29 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id A15BB3A68DC; Fri, 11 Mar 2011 12:31:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=2025; q=dns/txt; s=iport; t=1299875569; x=1301085169; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=a66fJ/PYcW5gy98TWovQo5geJMRoZWXWBZdLUi7gLsg=; b=E4CeW6YdoXlUNvJbZqBKBElO/tds+QYd3IryJ+Z6JWWmMlsJ3ogkYYLS NLa77pcRv2vOwlICe8oq6pXZJOGCJK4FqQsIcKP8wYd547v9YksrJsTNr FbIcFNSci3ER2CU0eYR7ADd268rWlnjau6K/WqSOJ/3mtK9YAlVhC6X+E w=; X-IronPort-AV: E=Sophos;i="4.62,305,1297036800"; d="scan'208";a="274968806" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by sj-iport-4.cisco.com with ESMTP; 11 Mar 2011 20:32:49 +0000 Received: from stealth-10-32-254-214.cisco.com (stealth-10-32-254-214.cisco.com [10.32.254.214]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2BKWk0F021290; Fri, 11 Mar 2011 20:32:46 GMT Message-Id: <7EA8F35D-5D31-472E-BE37-3789470D059A@cisco.com> From: David McGrew To: "Herzog, Jonathan - 0668 - MITLL" In-Reply-To: <63667400-81DF-438E-869F-247222DECA18@ll.mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 11 Mar 2011 12:32:45 -0800 References: <552BBAA9-712F-49B4-8A5F-C671C3817C05@ll.mit.edu> <47CF9528-81A1-49D7-8D4B-B1DCC136581E@ll.mit.edu> <3E69AF7B-D325-4FC5-A003-FEBA1997D67E@cisco.com> <65D56695-894D-458E-A9C4-6DCF6A38F196@cisco.com> <29C1F1D5-6EF0-4055-BA88-03F03E3F0A84@ll.mit.edu> <63667400-81DF-438E-869F-247222DECA18@ll.mit.edu> X-Mailer: Apple Mail (2.936) Cc: "secdir@ietf.org" , "draft-herzog-static-ecdh@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 20:31:31 -0000 Hi Jonthan, On Mar 10, 2011, at 12:41 PM, Herzog, Jonathan - 0668 - MITLL wrote: > > On Mar 10, 2011, at 1:12 PM, David McGrew wrote: >> >> >>> >>> However, SP800-56A does define cofactor ECDH. So let me propose the >>> following citation scheme: >>> >>> * ECDH in general: RFC 6090 >>> * Standard ECDH: RFC 6090 >>> * Co-factor Diffie-Hellman: SP 800-56A, Section 5.7.1.2 >>> * Full public-key validation: SP800-56A, Section 5.6.2.5 >>> * Partial public-key validation: SP800-56A: Section 5.6.2.6 >>> * Key-derivation function... still working on it. >>> >>> Thoughts? >> >> That looks good to me. Let me know if I can help with the KDF. > > > I'd appreciate it, thanks. One of the goals of this draft is to > remain as compatible with RFC 5753 as possible, so as to impact > implementations as little as possible. RFC 5753, for its part, > specifies the KDF in SEC1. And the KDF in SEC1 is just the 'simple > hash function construct described in ANSI X9.63'. So, do you think I > can cite X9.63 as the normative reference? And if so, what are your > thoughts on citing SEC1 as an informative reference for this KDF? > SEC1 is, after all, freely available on the web. Good point. I hope that the KDF from X9.63 that is referenced in SEC1 is the Concatenation Key Derivation Function (Section 5.8.1 of SP800-56A), or if not, the ASN.1 Key Derivation Function (Section 5.8.2). The 800-56A text on key agreement schemes says that they are based on X9.63 algorithms, though it doesn't explicitly mention the KDFs. David > > (Note: I'm still chasing down the ANSI spec to ensure that it does, > in fact, match the description in SEC1.) > > Thanks. > > -- > Jonathan Herzog voice: (781) 981-2356 > Technical Staff fax: (781) 981-7687 > Cyber Systems and Technology Group email: jherzog@ll.mit.edu > MIT Lincoln Laboratory www: http://www.ll.mit.edu/CST/ > 244 Wood Street > Lexington, MA 02420-9185 > From j.schoenwaelder@jacobs-university.de Sun Mar 13 10:42:23 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C72C13A67F8; Sun, 13 Mar 2011 10:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.177 X-Spam-Level: X-Spam-Status: No, score=-103.177 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bznahLMXLKX; Sun, 13 Mar 2011 10:42:22 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id BE6773A68C3; Sun, 13 Mar 2011 10:42:22 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 718D4C001A; Sun, 13 Mar 2011 18:43:44 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 5ShmtWZsmBDV; Sun, 13 Mar 2011 18:43:44 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C6F58C0008; Sun, 13 Mar 2011 18:43:43 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CF5E516F0A02; Sun, 13 Mar 2011 18:43:38 +0100 (CET) Date: Sun, 13 Mar 2011 18:43:38 +0100 From: Juergen Schoenwaelder To: iesg@ietf.org, secdir@ietf.org, draft-ietf-genarea-datatracker-community.all@tools.ietf.org Message-ID: <20110313174338.GA67401@elstar.local> Mail-Followup-To: iesg@ietf.org, secdir@ietf.org, draft-ietf-genarea-datatracker-community.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [secdir] secdir review of draft-ietf-genarea-datatracker-community-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 17:42:23 -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 I-D documents requirements for extensions of the data tracker and as such has no impact on the security of the Internet at large. The Security Considerations section spells out privacy concerns for users of the data tracker although it does not require that security protocols are mandatory to implement for the data tracker, which is kind of what I expected this document would say. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From kent@bbn.com Mon Mar 14 08:40:06 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B35813A6D0F; Mon, 14 Mar 2011 08:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcIyDx9tO04k; Mon, 14 Mar 2011 08:40:03 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 8FC0C3A6D1C; Mon, 14 Mar 2011 08:40:03 -0700 (PDT) Received: from dhcp89-089-213.bbn.com ([128.89.89.213]:49160) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Pz9td-000MNL-AW; Mon, 14 Mar 2011 11:41:25 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <1299814571.28172.111.camel@destiny> References: <4D791B26.8020001@vpnc.org> <18075_1299785510_p2AJVnAa005345_4D79271E.6080707@vpnc.org> <1299814571.28172.111.camel@destiny> Date: Mon, 14 Mar 2011 11:41:19 -0400 To: Jeffrey Hutzelman From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: ietf@ietf.org, draft-ietf-sidr-res-certs@tools.ietf.org, Sam Hartman , Paul Hoffman , secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-sidr-res-certs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 15:40:06 -0000 Jeff > >Steve noted a desire to limit the liability of entities acting as CAs in >the RPKI. I agree that goal is desirable, and restrictions on what >certificates issued by those CAs can contain help to do that (provided >the CAs actually comply). However, requiring compliant RPs to treat all >extensions as critical does _not_ help, because an RP which incorrectly >accepts an over-broad RPKI certificate for some other purpose is >probably not an implementation of this profile and thus not bound by the >restriction. My comments also noted that part of the strategy to limit the utility of resource certs in other contexts is to restrict their content. In principle, establishing constraints on what RPKI C As issue would do this, but experience suggests otherwise :-). Thus, in order to provide immediate feedback to a CA that the certs it is issuing are non-compliant, we would like to have RPs reject the certs (when used in the intended context). Thus having RPs be very strict in what they accept is important as well. Steve P.S. Sam noted that there are potentially lots of RPs. In principle, there are just as many CAs, since every ISP is a CA as well as an RP. In reality we anticipate that many small ISPs will take advantage of managed CA services (the RIRs are already offering such services), so there should be many fewer distinct CAs vs. RPs. Balancing that is the possibility that a number of ISPs, ones that rely on default routes, will also not be RPs. So, it's not clear whether we have more (distinct) CA or RPs. I am hopeful that the RIRs will do a good job of generating compliant certs in their primary and managed service CA roles. From kent@bbn.com Mon Mar 14 08:40:07 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F357E3A6D1C; Mon, 14 Mar 2011 08:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TF+3tJOIUyCH; Mon, 14 Mar 2011 08:40:04 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 670023A6D2B; Mon, 14 Mar 2011 08:40:04 -0700 (PDT) Received: from dhcp89-089-213.bbn.com ([128.89.89.213]:49160) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Pz9te-000MNL-9U; Mon, 14 Mar 2011 11:41:26 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <201103110458.p2B4wgaa024318@fs4113.wdf.sap.corp> References: <201103110458.p2B4wgaa024318@fs4113.wdf.sap.corp> Date: Mon, 14 Mar 2011 11:41:19 -0400 To: mrex@sap.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: draft-ietf-sidr-res-certs@tools.ietf.org, hartmans-ietf@mit.edu, ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-sidr-res-certs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 15:40:07 -0000 At 5:58 AM +0100 3/11/11, Martin Rex wrote: >Stephen Kent wrote: >> >> n to act as CAs , and we want to limit their liability. >> One way to do this is to restrict the fields and extensions in >> resource certs to make then not very useful for other applications. > >A CA should never sign extensions that it doesn't understand. >Why has the RP to be bothered with this? this is not about signing certs with extensions submitted by a Subject and which the CA does not understand. >A request "everything must be considered critical, even if not marked >as such" implies that every conceivable extension can only be a constraint. I would prefer to say that the vast majority of extensions are excluded from this profile, to make it easier for RP software to process resource certs. The critical marking is not equivalent to what we have stated in this doc, although there are similarities. For example, there are a lot of standard extensions that 5280 requires RP software to recognize that are explicitly forbidden in the RPKI context. >With its original meaning, the "ciriticality" flag could be used to sort >extensions into "constraints" (critical) and "capabilities" (non-critical). Note that not all extensions can be marked critical, so that using the critical flag would not be a solution in all cases anyway. >The problem with newly inventend constraints is that they require flag days. >capabilities do not suffer from this, and allow for a smoother migration. This doc is a profile of 5280 and thus the imposition of constraints is to be expected. I do not know what you mean by the phrase "... capabilities do not suffer from this ..." > > I also note that we want to impose these constraints on both CAs and > > RPs, because we have lots of examples of CAs issuing "bad" certs, >> accidentally. se want to use RP strictness to help "motivate" CAs to >> do the right thing :-). > >I don't think that this idea will work. >The consumers of the technology will want things to interoperate, >not to fail. And implementations will provide the necessary workarouds. Interoperability is NOT enhanced by allowing certs with extensions that are extraneous to the focus of this architecture, and to the CP for this PKI. I suggest you read the architecture doc and the CP, both of which are available at the SIDR page to get a better sense of the context targeted by this profile. >Besides, such an idea is in conflict with rfc-2119 section 6 > >6. Guidance in the use of these Imperatives > > ... they must not be used to try to impose a particular method > on implementors where the method is not required for interoperability. > I disagree with our reading of this text, relative to this context. Steve From hilarie@purplestreak.com Mon Mar 14 10:56:59 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 242CD3A6DEB; Mon, 14 Mar 2011 10:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EBUv0CFa0mU; Mon, 14 Mar 2011 10:56:58 -0700 (PDT) Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) by core3.amsl.com (Postfix) with ESMTP id 66FB13A6E46; Mon, 14 Mar 2011 10:56:58 -0700 (PDT) Received: from mx01.mta.xmission.com ([166.70.13.211]) by out02.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PzC27-00020X-HV; Mon, 14 Mar 2011 11:58:20 -0600 Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=fermat.rhmr.com) by mx01.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PzC22-0004ci-DP; Mon, 14 Mar 2011 11:58:19 -0600 Received: from fermat.rhmr.com (localhost [127.0.0.1]) by fermat.rhmr.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p2EHwl9B032698; Mon, 14 Mar 2011 11:58:47 -0600 Received: (from ho@localhost) by fermat.rhmr.com (8.14.3/8.14.3/Submit) id p2EHwkmS032697; Mon, 14 Mar 2011 11:58:46 -0600 Date: Mon, 14 Mar 2011 11:58:46 -0600 Message-Id: <201103141758.p2EHwkmS032697@fermat.rhmr.com> X-Authentication-Warning: fermat.rhmr.com: ho set sender to hilarie using -f From: "Hilarie Orman" To: iesg@ietf.org, secdir@ietf.org X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx01.mta.xmission.com; ; ; ip=166.70.57.249; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-DomainKey: sender_domain=alum.mit.edu; ; ; sender=ho@alum.mit.edu; ; ; status=error X-SA-Exim-Connect-IP: 166.70.57.249 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa01 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;iesg@ietf.org, secdir@ietf.org X-Spam-Relay-Country: X-SA-Exim-Version: 4.2.1 (built Fri, 06 Aug 2010 16:31:04 -0600) X-SA-Exim-Scanned: Yes (on mx01.mta.xmission.com) Cc: draft-ietf-httpbis-content-disp-06@tools.ietf.org, julian.reschke@greenbytes.de Subject: [secdir] review draft-ietf-httpbis-content-disp-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hilarie Orman List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 17:56:59 -0000 Security Review of Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document specifies the syntax of the content-disposition field and its parameters for http responses. It is based on the MIME specification for the same field. The Content-Disposition header supports a parameter called "filename", the recommended name for saving the content. That feature is just plain dangerous. A good many exploits are based it. But, it's not really the fault of the protocol. Protocols don't kill people, people clicking "yes" kill themselves. The document is clearly written, and it does point out many of the dangers inherent in trusting arbitrary filenames and file extensions. However, I think that this feature will continue to be a major source of vulnerabilities. >From a security viewpoint, I think the protocol should restrict filenames to ascii alphabetic characters (no "." or "/"), and that if the filename does not conform, the receiver SHOULD reject the message and send an error code back to the sender. The sender should not be allowed to specify a file extension. The receiver SHOULD write the files into a quarantined disk area using a temporary filename, the file to be released to the recommended name pending manual review. But, that would break the world, as would so many security recommendations. Hilarie From stbryant@cisco.com Mon Mar 14 11:29:42 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3451F3A6A03; Mon, 14 Mar 2011 11:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.441 X-Spam-Level: X-Spam-Status: No, score=-110.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ao3n7r174BBV; Mon, 14 Mar 2011 11:29:41 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id A4EBE3A68C3; Mon, 14 Mar 2011 11:29:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=721; q=dns/txt; s=iport; t=1300127465; x=1301337065; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Oo6+F5bSGHNpx5aC5YsBGhpONifgaqUjrpdZwMh/Gcw=; b=WqFc129S8Xy3GAJ9SDOt4pmTjMK6psq0T5sBod2q0VKEGgC5HO6NAPIJ Kw5z+TKvGh2rGS3Hv4Dnca1FOFKYHRyuxIfvd40cPaDX5Qn0Tllk6BMwY vA//c4kua9pc47JM9p6x8c4db2MDhRmanc3bWAL24+CPR8i1hMt0Lfcmk o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoEAP77fU2Q/khNgWdsb2JhbACmChQBARYmJaQbgmoOAZkohWIEjFKMPw X-IronPort-AV: E=Sophos;i="4.62,317,1297036800"; d="scan'208";a="21662565" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 14 Mar 2011 18:31:04 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2EIV3cF012099; Mon, 14 Mar 2011 18:31:03 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p2EIUlU18105; Mon, 14 Mar 2011 18:30:51 GMT Message-ID: <4D7E5ED7.9020404@cisco.com> Date: Mon, 14 Mar 2011 18:30:47 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Hilarie Orman References: <201103141758.p2EHwkmS032697@fermat.rhmr.com> In-Reply-To: <201103141758.p2EHwkmS032697@fermat.rhmr.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: julian.reschke@greenbytes.de, draft-ietf-httpbis-content-disp-06@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] review draft-ietf-httpbis-content-disp-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 18:29:42 -0000 > > From a security viewpoint, I think the protocol should restrict > filenames to ascii alphabetic characters (no "." or "/"), and that if > the filename does not conform, the receiver SHOULD reject the message > and send an error code back to the sender. The sender should not be > allowed to specify a file extension. The receiver SHOULD write the > files into a quarantined disk area using a temporary filename, the > file to be released to the recommended name pending manual review. > But, that would break the world, as would so many security > recommendations. Surely you mean ascii alpha-numeric characters? Text fixing this would also address the security component of my Discuss. - Stewart From hilarie@purplestreak.com Mon Mar 14 11:39:52 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 293933A68CE; Mon, 14 Mar 2011 11:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YRzMGR1Q6NE; Mon, 14 Mar 2011 11:39:51 -0700 (PDT) Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by core3.amsl.com (Postfix) with ESMTP id 5E9433A68C3; Mon, 14 Mar 2011 11:39:51 -0700 (PDT) Received: from mx01.mta.xmission.com ([166.70.13.211]) by out01.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PzChd-0001u3-7f; Mon, 14 Mar 2011 12:41:13 -0600 Received: from mta2.zcs.xmission.com ([166.70.13.66]) by mx01.mta.xmission.com with esmtp (Exim 4.69) (envelope-from ) id 1PzChd-0002oC-4C; Mon, 14 Mar 2011 12:41:13 -0600 Received: from zms03.zcs.xmission.com (zms03.zcs.xmission.com [166.70.13.73]) by mta2.zcs.xmission.com (Postfix) with ESMTP id 6E1A860017F; Mon, 14 Mar 2011 12:41:12 -0600 (MDT) Date: Mon, 14 Mar 2011 12:41:11 -0600 (MDT) From: Hilarie Orman To: stbryant@cisco.com Message-ID: <719652105.466767.1300128071617.JavaMail.root@zms03.zcs> In-Reply-To: <4D7E5ED7.9020404@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [166.70.13.71] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Linux)/6.0.10_GA_2692) X-SA-Exim-Connect-IP: 166.70.13.66 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-SA-Exim-Scanned: No (on mx01.mta.xmission.com); SAEximRunCond expanded to false Cc: secdir@ietf.org, draft-ietf-httpbis-content-disp@tools.ietf.org, iesg@ietf.org, julian reschke Subject: Re: [secdir] review draft-ietf-httpbis-content-disp-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 18:39:52 -0000 Oh, all right, you can use numbers, too. Slippery slope and all. Hilarie ----- Original Message ----- From: "Stewart Bryant" To: "Hilarie Orman" Cc: "julian reschke" , draft-ietf-httpbis-content-disp-06@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Sent: Monday, March 14, 2011 12:30:47 PM Subject: Re: [secdir] review draft-ietf-httpbis-content-disp-06 > > From a security viewpoint, I think the protocol should restrict > filenames to ascii alphabetic characters (no "." or "/"), and that if > the filename does not conform, the receiver SHOULD reject the message > and send an error code back to the sender. The sender should not be > allowed to specify a file extension. The receiver SHOULD write the > files into a quarantined disk area using a temporary filename, the > file to be released to the recommended name pending manual review. > But, that would break the world, as would so many security > recommendations. Surely you mean ascii alpha-numeric characters? Text fixing this would also address the security component of my Discuss. - Stewart _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From alexey.melnikov@isode.com Mon Mar 14 11:41:26 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB5213A6A03; Mon, 14 Mar 2011 11:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.344 X-Spam-Level: X-Spam-Status: No, score=-102.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opoMrANd8hLx; Mon, 14 Mar 2011 11:41:26 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 1A0BA3A68CE; Mon, 14 Mar 2011 11:41:26 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 14 Mar 2011 18:42:48 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4D7E618A.6000007@isode.com> Date: Mon, 14 Mar 2011 18:42:18 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: stbryant@cisco.com, Hilarie Orman References: <201103141758.p2EHwkmS032697@fermat.rhmr.com> <4D7E5ED7.9020404@cisco.com> In-Reply-To: <4D7E5ED7.9020404@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, secdir@ietf.org, draft-ietf-httpbis-content-disp-06@tools.ietf.org, julian.reschke@greenbytes.de Subject: Re: [secdir] review draft-ietf-httpbis-content-disp-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 18:41:27 -0000 Hi Hilarie/Stewart, A couple of quick comments: Stewart Bryant wrote: >> > From a security viewpoint, I think the protocol should restrict >> filenames to ascii alphabetic characters > I don't think this is realistic. Filenames should be allowed to be in non-ASCII, as pure ASCII is not sufficient for naming files in many languages. >> (no "." or "/"), and that if >> the filename does not conform, the receiver SHOULD reject the message >> and send an error code back to the sender. > This value is coming in a HTTP response from a server, so the client can't do that. >> The sender should not be >> allowed to specify a file extension. The receiver SHOULD write the >> files into a quarantined disk area using a temporary filename, the >> file to be released to the recommended name pending manual review. >> But, that would break the world, as would so many security >> recommendations. > > Surely you mean ascii alpha-numeric characters? > > Text fixing this would also address the security component of my Discuss. From turners@ieca.com Mon Mar 14 12:50:56 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F27A43A67EE for ; Mon, 14 Mar 2011 12:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ovi4LknMC2Y for ; Mon, 14 Mar 2011 12:50:55 -0700 (PDT) Received: from nm16.bullet.mail.ac4.yahoo.com (nm16.bullet.mail.ac4.yahoo.com [98.139.52.213]) by core3.amsl.com (Postfix) with SMTP id 897C33A6D9A for ; Mon, 14 Mar 2011 12:50:50 -0700 (PDT) Received: from [98.139.52.190] by nm16.bullet.mail.ac4.yahoo.com with NNFMP; 14 Mar 2011 19:52:11 -0000 Received: from [98.139.52.142] by tm3.bullet.mail.ac4.yahoo.com with NNFMP; 14 Mar 2011 19:52:11 -0000 Received: from [127.0.0.1] by omp1025.mail.ac4.yahoo.com with NNFMP; 14 Mar 2011 19:52:11 -0000 X-Yahoo-Newman-Id: 969409.42396.bm@omp1025.mail.ac4.yahoo.com Received: (qmail 25056 invoked from network); 14 Mar 2011 19:52:11 -0000 Received: from thunderfish.local (turners@96.231.119.32 with plain) by smtp111.biz.mail.re2.yahoo.com with SMTP; 14 Mar 2011 12:52:11 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 3Qaz2pUVM1kWc_2FnN.qGDS31diy14Zi1VEKjxuYxMuojYG Fc0jreKtzAS1IjwrTbE78ZJKmegbH3xBEK3WnAX51kPU3avu4YFgXuYYShIV sB0OZIIA0dRt6PKdaKN9uaV56ZzXsZAMtIVp.zta4eSm506hiBxP5rPKFj9C hBG8UJK_R5om4kyzvekFwIc6f7J0gDbOnVJZVpNhrCYHgHpP506yaOqVNMUc RJ.j5TcqVc5IYtUovjtKRmAfm6HuKfL2WQlEyxtxaPEEKIG1UXGttA08- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D7E71EA.9030207@ieca.com> Date: Mon, 14 Mar 2011 15:52:10 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Herzog, Jonathan - 0668 - MITLL" References: <552BBAA9-712F-49B4-8A5F-C671C3817C05@ll.mit.edu> <47CF9528-81A1-49D7-8D4B-B1DCC136581E@ll.mit.edu> <3E69AF7B-D325-4FC5-A003-FEBA1997D67E@cisco.com> <65D56695-894D-458E-A9C4-6DCF6A38F196@cisco.com> <29C1F1D5-6EF0-4055-BA88-03F03E3F0A84@ll.mit.edu> <63667400-81DF-438E-869F-247222DECA18@ll.mit.edu> <7EA8F35D-5D31-472E-BE37-3789470D059A@cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "iesg@ietf.org" , "draft-herzog-static-ecdh@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 19:50:56 -0000 On 3/14/11 9:47 AM, Herzog, Jonathan - 0668 - MITLL wrote: > > On Mar 11, 2011, at 4:13 PM, Herzog, Jonathan - 0668 - MITLL wrote: >> On Mar 11, 2011, at 3:32 PM, David McGrew wrote: >>> >>> I hope that the KDF from X9.63 that is referenced in SEC1 is the >>> Concatenation Key Derivation Function (Section 5.8.1 of SP800-56A), or >>> if not, the ASN.1 Key Derivation Function (Section 5.8.2). >> >> >> Mostly 'yes,' but just enough 'no' to be a real problem for us. Both the KDF in SEC1/X9.63 and the KDFs in 800-56A take the Diffie Hellman secret and some Other Stuff, and produce keying material as output. But they are not the exact same KDF. From SP 800-56A, Appendix A ("Summary of Differences between this Recommendation and ANS X9 Standards"): >> >> [Begin quote] >> >> 8. Regarding the key derivation function (KDF): >> >> a. This recommendation specifies two Approved KDFs, the concatenation KDF specified in Section 5.8.1 and the ASN.1 KDF specified in Section 5.8.2. Other key derivation methods may be temporarily allowed for backward compatibility. These other allowable methods and any restrictions on their use will be specified in FIPS 140-2 Annex D. >> >> b. ANS X9.42 provides a concatenation KDF and an ASN.1 KDF, while ANS X9.63 provides only the concatenation KDF. However, the Approved KDFs of this Recommendation require that the counter appears before the shared secret as input to the hash function, whereas the ANSI KDFs place the counter after the shared secret >> >> c. The Approved KDFs in this Recommendation require the input of the identifiers of the communicating parties; such information is not required in ANS X9.42 and X9.63. >> >> d. In this Recommendation, the shared secret is zeroized after a single call to a key derivation function, before the key agreement scheme releases any portion of the DerivedKeyingMaterial for use by relying applications.. The ANS X9.42 and X9.63 standards do not indicate when the shared secret needs to be zeroized. An implication of this Recommendation’s requirement concerning zeroization is that all of the keying material directly derived from the shared secret must be computed during one call to the KDF. >> >> [End quote] >> >> Point (d) is not an issue for this discussion, and point (a) is just informative. But points (b) and (c) are both show-stoppers. Point (b) says that SEC1/X9.63 and SP 800-56A disagree on how to turn the inputs into keying material. Point (c) says that they disagree on what the Other Stuff must contain. Specifically, SP 800-56A requires that the Other Stuff contain: >> >> * ID of the algorithm, >> * ID of the sender, >> * ID of the receiver, >> * Sender randomness (optional), and >> * Receiver randomness (optional). >> >> SEC1 places no restriction on the Other Stuff. But RFC 5753 says that the Other Stuff must be the DER encoding of an ECC-CMS-SharedInfo structure, which contains: >> >> * ID of the algorithm, >> * Sender randomness (optional), and >> * Length of output key (optional). >> >> So unless I'm wrong (again, more than likely) the SEC1/X9.63 and SP 800-56A KDFs are not compatible. And in fact, we can't switch to the SP 800-56A KDFs without introducing some tricky incompatibilities with RFC 5753. (Implementors would have to implement one KDF for ephemeral-static ECDH and a different one for static-static ECDH). >> >> Given this, what do people think of citing X9.63 for the KDF? And about citing SEC1 as an informative reference so that people can find the KDF without having to buy an ANSI standard? > > I was advised to submit an updated draft over the weekend, even if some issues were still up in the air. So, draft-herzog-static-ecdh-06.txt has been submitted and is awaiting manual posting. In the meantime, a copy is attached to this mail. As you can see, I went ahead and made the change I proposed above: citing X9.63 as the normative standard for the KDF in RFC 5753, wit SEC1 as an informative reference. > > Thoughts? While I'd prefer a pointer to NIST specs, I think we have to maintain compatibility with RFC 5753 (i.e., doing the KDF one way for SS ECDH and another way for ES ECDH just seems like a bad idea). I like the approach of pointing to ANSI normatively and SEC1 informatively. spt From julian.reschke@greenbytes.de Mon Mar 14 12:51:13 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 223233A6E8C; Mon, 14 Mar 2011 12:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nw9xER+sLRIA; Mon, 14 Mar 2011 12:51:12 -0700 (PDT) Received: from donbot.greenbytes.de (mail.greenbytes.de [217.91.35.233]) by core3.amsl.com (Postfix) with ESMTP id D5E763A6E9A; Mon, 14 Mar 2011 12:51:09 -0700 (PDT) Received: from [192.168.178.33] (unknown [80.143.179.239]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by donbot.greenbytes.de (Postfix) with ESMTPSA id 56532C4C0ED; Mon, 14 Mar 2011 20:52:31 +0100 (CET) Message-ID: <4D7E71FD.7060208@greenbytes.de> Date: Mon, 14 Mar 2011 20:52:29 +0100 From: Julian Reschke Organization: greenbytes GmbH User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Alexey Melnikov References: <201103141758.p2EHwkmS032697@fermat.rhmr.com> <4D7E5ED7.9020404@cisco.com> <4D7E618A.6000007@isode.com> In-Reply-To: <4D7E618A.6000007@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, secdir@ietf.org, draft-ietf-httpbis-content-disp-06@tools.ietf.org, stbryant@cisco.com Subject: Re: [secdir] review draft-ietf-httpbis-content-disp-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 19:51:13 -0000 On 14.03.2011 19:42, Alexey Melnikov wrote: > Hi Hilarie/Stewart, > A couple of quick comments: > > Stewart Bryant wrote: > >>> > From a security viewpoint, I think the protocol should restrict >>> filenames to ascii alphabetic characters >> > I don't think this is realistic. Filenames should be allowed to be in > non-ASCII, as pure ASCII is not sufficient for naming files in many > languages. Right. Fixing the I18N problem actually was the main motivation for writing this spec. >>> (no "." or "/"), and that if >>> the filename does not conform, the receiver SHOULD reject the message >>> and send an error code back to the sender. >> > This value is coming in a HTTP response from a server, so the client > can't do that. Even if we *did* forbid these characters, we'd still need to advise recipients how to handle them. > ... Best regards, Julian From julian.reschke@greenbytes.de Mon Mar 14 12:58:58 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB93B3A6B6B; Mon, 14 Mar 2011 12:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iH5eG0bJV1Bs; Mon, 14 Mar 2011 12:58:57 -0700 (PDT) Received: from donbot.greenbytes.de (mail.greenbytes.de [217.91.35.233]) by core3.amsl.com (Postfix) with ESMTP id B18723A6B57; Mon, 14 Mar 2011 12:58:57 -0700 (PDT) Received: from [192.168.178.33] (unknown [80.143.179.239]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by donbot.greenbytes.de (Postfix) with ESMTPSA id 9B0A7C4CA34; Mon, 14 Mar 2011 21:00:20 +0100 (CET) Message-ID: <4D7E73D2.5040507@greenbytes.de> Date: Mon, 14 Mar 2011 21:00:18 +0100 From: Julian Reschke Organization: greenbytes GmbH User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Hilarie Orman References: <201103141758.p2EHwkmS032697@fermat.rhmr.com> In-Reply-To: <201103141758.p2EHwkmS032697@fermat.rhmr.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-httpbis-content-disp-06@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] review draft-ietf-httpbis-content-disp-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 19:58:58 -0000 On 14.03.2011 18:58, Hilarie Orman wrote: > Security Review of > > Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol > (HTTP) > > 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. Hilarie, thanks for the feedback. > The document specifies the syntax of the content-disposition field and > its parameters for http responses. It is based on the MIME > specification for the same field. > > The Content-Disposition header supports a parameter called "filename", > the recommended name for saving the content. That feature is just > plain dangerous. A good many exploits are based it. But, it's not > really the fault of the protocol. Protocols don't kill people, people > clicking "yes" kill themselves. Indeed. Furthermore, it's saving web content, not the header field itself. Recall that if the C-D header field is not present, the UA will derive one from the URI, which can have exactly the same problems (except for the path-related ones). > The document is clearly written, and it does point out many of the > dangers inherent in trusting arbitrary filenames and file extensions. > However, I think that this feature will continue to be a major source > of vulnerabilities. Out of curiosity: do you believe it's a vulnerability today? Anything specific? UA bug reports that haven't been fixed? > From a security viewpoint, I think the protocol should restrict > filenames to ascii alphabetic characters (no "." or "/"), and that if We can't rule out "."; it just occurs frequently in filenames (think "foo.tar.gz"). We *could* forbid path separators, but that wouldn't mean that we wouldn't have to say what to do when you see them. > the filename does not conform, the receiver SHOULD reject the message > and send an error code back to the sender. The sender should not be As Alexey said, there's no back channel. Also, if sending a non-conforming name was actually intentional, complaining about it will not achieve anything. > allowed to specify a file extension. The receiver SHOULD write the > files into a quarantined disk area using a temporary filename, the > file to be released to the recommended name pending manual review. > But, that would break the world, as would so many security > recommendations. Indeed. I'd rather not try to impose normative requirements here when we know that UAs won't do it anyway. It's much more important to call out the risks. Best regards, Julian From radiaperlman@gmail.com Mon Mar 14 21:49:36 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C3953A6AB9; Mon, 14 Mar 2011 21:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.07 X-Spam-Level: X-Spam-Status: No, score=-4.07 tagged_above=-999 required=5 tests=[AWL=-0.471, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqsxTi+YIQeL; Mon, 14 Mar 2011 21:49:35 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 3494B3A68BE; Mon, 14 Mar 2011 21:49:35 -0700 (PDT) Received: by iwl42 with SMTP id 42so291269iwl.31 for ; Mon, 14 Mar 2011 21:50:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=p4n04VFTVvKy7x0cKvzYmR5iI16wJGUScnA/iuIQJI8=; b=av7HKzPPwv9+LVtE2LOIKsl+c3KOaQ9zMmMoYBLN1r66dgVP9twJ9fwUKsM5r0s0Bq NZBxgsDUQfMH1qlrdcS4BOAN7btlp16tJxFGOvbL75sJ7TaRiEX1ZTjqD6eKMLsVVwSN Csgk9Wicjr6O/0JNCwVqb9m3DAb6qDpwMbWVE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=i5qG6u/VNIFEl+8iRlYjbLargEbRQ3zLRZ36l/jE+xGC/MafrvXAKPvSa1/if6IV44 xg44uCnBno6gaCF6XckdmPVCWRm6pj8N0jkB33b/9lkSfTUmjoDduIXqYyHNaKML8OMs 4ePIENBGHW0e/qnJEfBFhtE2KFJePOWFETQ9w= MIME-Version: 1.0 Received: by 10.43.61.138 with SMTP id ww10mr6176103icb.390.1300161102753; Mon, 14 Mar 2011 20:51:42 -0700 (PDT) Received: by 10.43.131.2 with HTTP; Mon, 14 Mar 2011 20:51:42 -0700 (PDT) Date: Mon, 14 Mar 2011 20:51:42 -0700 Message-ID: From: Radia Perlman To: iesg@ietf.org, secdir@ietf.org, draft-ietf-mip4-gre-key-extension.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] secdir review of draft-ietf-mip4-gre-key-extension-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 04:49:36 -0000 Summary: No issues found I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes a new field, somewhat disturbingly called "key" (in that it has nothing to do with a cryptography key) which is an extension to Mobile IP that allows specification of a specific GRE tunnel, allowing (care of address, home address, and home agent address) not to need to be unique across VPNs. As they rightly point out, this does not introduce new security issues. Radia From yaronf.ietf@gmail.com Tue Mar 15 00:27:03 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CF593A6C0D; Tue, 15 Mar 2011 00:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psxFJPThTx7i; Tue, 15 Mar 2011 00:27:02 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 23E483A6982; Tue, 15 Mar 2011 00:27:01 -0700 (PDT) Received: by bwz13 with SMTP id 13so331616bwz.31 for ; Tue, 15 Mar 2011 00:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=7Am46UOU2J3CYE1Z0/h8VeyCOjvrfkfc7zZqp46UhZE=; b=eyv43CIFM2/4JnND8MbaQsogMYTVMnxVvy+KnTLc5If+WmwI1AN1PPJyowbobKnioG DtxQ8WWinmPW5npxVB0Z1eLxX8x0aw2V+gezEXcNGImsdU+vnv0s+iNGiQglrO1VSdkD 0LK5Q3nvQjgfeeh45ZtixXMA73D2ihqjH9KVU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=L5AspGR9LPG/EmjK6bycMa8x7dYJdaDNgHAEupwzxjJbVDVrT2iqofzLO97ssr2VYZ xAJPIl8qNUtltT1ZiMl3jxxjc4ZIl6LicRS8SLDlBX/pHE+fTiafwNGY/1/faKI4OvRZ 58XlRVajqVf0m+dl8f/I3bioA7V87xcjKTu0I= Received: by 10.204.169.130 with SMTP id z2mr7077648bky.137.1300174105915; Tue, 15 Mar 2011 00:28:25 -0700 (PDT) Received: from [192.168.2.104] (IGLD-84-229-42-92.inter.net.il [84.229.42.92]) by mx.google.com with ESMTPS id k5sm240755bku.16.2011.03.15.00.28.23 (version=SSLv3 cipher=OTHER); Tue, 15 Mar 2011 00:28:24 -0700 (PDT) Message-ID: <4D7F1516.6080401@gmail.com> Date: Tue, 15 Mar 2011 09:28:22 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: iesg@ietf.org, secdir@ietf.org, draft-ietf-ipfix-structured-data.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] SecDir review of draft-ietf-ipfix-structured-data-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 07:27:03 -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. IPFIX is a structured information model and protocol for transmitting information about data flows. This document extends the model with structured data, basically several types of lists. I have not reviewed the document in full, rather I have looked at the security aspects only. The Security Considerations refer the reader to the IPFIX protocol and data model RFCs, and I mostly agree, with one exception. I suggest to add text similar to the next paragraph: The addition of complex data types necessarily complicates the implementation of the Collector. This could easily result in new security vulnerabilities (e.g., buffer overflows); this creates additional risk in cases where either DTLS is not used, or if the Observation Point and Collector belong to different trust domains. Thanks, Yaron From prvs=20519a3477=jherzog@ll.mit.edu Fri Mar 11 13:12:23 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF9393A68AB; Fri, 11 Mar 2011 13:12:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.847 X-Spam-Level: X-Spam-Status: No, score=-5.847 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKvb8sHdhrKA; Fri, 11 Mar 2011 13:12:22 -0800 (PST) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by core3.amsl.com (Postfix) with ESMTP id 8CEA53A68DA; Fri, 11 Mar 2011 13:12:22 -0800 (PST) Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id p2BLDchD017979; Fri, 11 Mar 2011 16:13:39 -0500 From: "Herzog, Jonathan - 0668 - MITLL" To: David McGrew Date: Fri, 11 Mar 2011 16:13:40 -0500 Thread-Topic: [secdir] Secdir review of draft-herzog-static-ecdh-05 Thread-Index: AcvgMTBMY3k9faC+Qt2JM+UW5NLq1g== Message-ID: References: <552BBAA9-712F-49B4-8A5F-C671C3817C05@ll.mit.edu> <47CF9528-81A1-49D7-8D4B-B1DCC136581E@ll.mit.edu> <3E69AF7B-D325-4FC5-A003-FEBA1997D67E@cisco.com> <65D56695-894D-458E-A9C4-6DCF6A38F196@cisco.com> <29C1F1D5-6EF0-4055-BA88-03F03E3F0A84@ll.mit.edu> <63667400-81DF-438E-869F-247222DECA18@ll.mit.edu> <7EA8F35D-5D31-472E-BE37-3789470D059A@cisco.com> In-Reply-To: <7EA8F35D-5D31-472E-BE37-3789470D059A@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-184--551726109"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-11_07:2011-03-11, 2011-03-11, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=8 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1012030000 definitions=main-1103110115 X-Mailman-Approved-At: Tue, 15 Mar 2011 08:10:09 -0700 Cc: "secdir@ietf.org" , "draft-herzog-static-ecdh@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 21:12:24 -0000 --Apple-Mail-184--551726109 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Mar 11, 2011, at 3:32 PM, David McGrew wrote: >=20 > I hope that the KDF from X9.63 that is referenced in SEC1 is the =20 > Concatenation Key Derivation Function (Section 5.8.1 of SP800-56A), or = =20 > if not, the ASN.1 Key Derivation Function (Section 5.8.2). =20 Mostly 'yes,' but just enough 'no' to be a real problem for us. Both the = KDF in SEC1/X9.63 and the KDFs in 800-56A take the Diffie Hellman secret = and some Other Stuff, and produce keying material as output. But they = are not the exact same KDF. =46rom SP 800-56A, Appendix A ("Summary of = Differences between this Recommendation and ANS X9 Standards"): [Begin quote] 8. Regarding the key derivation function (KDF): a. This recommendation specifies two Approved KDFs, the concatenation = KDF specified in Section 5.8.1 and the ASN.1 KDF specified in Section = 5.8.2. Other key derivation methods may be temporarily allowed for = backward compatibility. These other allowable methods and any = restrictions on their use will be specified in FIPS 140-2 Annex D. b. ANS X9.42 provides a concatenation KDF and an ASN.1 KDF, while ANS = X9.63 provides only the concatenation KDF. However, the Approved KDFs of = this Recommendation require that the counter appears before the shared = secret as input to the hash function, whereas the ANSI KDFs place the = counter after the shared secret c. The Approved KDFs in this Recommendation require the input of the = identifiers of the communicating parties; such information is not = required in ANS X9.42 and X9.63. d. In this Recommendation, the shared secret is zeroized after a single = call to a key derivation function, before the key agreement scheme = releases any portion of the DerivedKeyingMaterial for use by relying = applications.. The ANS X9.42 and X9.63 standards do not indicate when = the shared secret needs to be zeroized. An implication of this = Recommendation=92s requirement concerning zeroization is that all of the = keying material directly derived from the shared secret must be computed = during one call to the KDF. [End quote] Point (d) is not an issue for this discussion, and point (a) is just = informative. But points (b) and (c) are both show-stoppers. Point (b) = says that SEC1/X9.63 and SP 800-56A disagree on how to turn the inputs = into keying material. Point (c) says that they disagree on what the = Other Stuff must contain. Specifically, SP 800-56A requires that the = Other Stuff contain: * ID of the algorithm, * ID of the sender, * ID of the receiver, * Sender randomness (optional), and * Receiver randomness (optional).=20 SEC1 places no restriction on the Other Stuff. But RFC 5753 says that = the Other Stuff must be the DER encoding of an ECC-CMS-SharedInfo = structure, which contains: * ID of the algorithm, * Sender randomness (optional), and * Length of output key (optional). So unless I'm wrong (again, more than likely) the SEC1/X9.63 and SP = 800-56A KDFs are not compatible. And in fact, we can't switch to the SP = 800-56A KDFs without introducing some tricky incompatibilities with RFC = 5753. (Implementors would have to implement one KDF for ephemeral-static = ECDH and a different one for static-static ECDH). Given this, what do people think of citing X9.63 for the KDF? And about = citing SEC1 as an informative reference so that people can find the KDF = without having to buy an ANSI standard? Thanks. --=20 Jonathan Herzog voice: = (781) 981-2356 Technical Staff fax: = (781) 981-7687 Cyber Systems and Technology Group email: = jherzog@ll.mit.edu MIT Lincoln Laboratory www: = http://www.ll.mit.edu/CST/ 244 Wood Street =20 Lexington, MA 02420-9185 --Apple-Mail-184--551726109 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJrzCCBNIw ggO6oAMCAQICChVM3JYAAAAAIh8wDQYJKoZIhvcNAQEFBQAwUTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwg Q0EtMTAeFw0xMDA1MjUyMDQ1MzhaFw0xMTA1MjUyMDQ1MzhaMGQxCzAJBgNVBAYTAlVTMR8wHQYD VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQZW9wbGUxIzAhBgNVBAMTGkhl cnpvZy5Kb25hdGhhbi5DLjUwMDExMzA1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 93mr5a6zq6EQsVtIX9BadxwzpjabF8pvDmoMSP/ZhbWrncNJ1j7xiBGcihYqsDaQz9+hJITxi7IM NUx5fnFtOQRHZgkOCLR1URFc0AlJ3Pknv6XoQ4fqPODmSMB882c9l/8AbO7N/27r8n/V0Ip4Rpw8 1qnrDXk6UH/1zHlssGmlVng0RSREuQy98xPxzbLr5cOMWLwHs5OLNYcGv0KlD6rp1DPzJ3qplU/+ 0P2jyYbGyXStJ/h+3Kx5mOWFLB4j8HDyLG90ZHlZjZXo9FrSoFubVJK/mdVzIuXd00Ldl1fCyxhR D9elkpTc7xOLJsEzCCi8Gqo6eQuvz1RH93u3PwIDAQABo4IBlzCCAZMwDgYDVR0PAQH/BAQDAgbA MB0GA1UdDgQWBBRPjG6+CxR6H/o9vyq5PgmW9vmuajAfBgNVHSMEGDAWgBSUWsZYybYmm6AJe6gv ZJDDiQJuKjAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xM Q0ExMGIGCCsGAQUFBwEBBFYwVDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dHRvL0xMQ0ExMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5sbC5taXQuZWR1LzAMBgNVHRMBAf8E AjAAMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH /4pzAgFkAgEFMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8w DQYLKoZIhvcSAgEDAQgwHQYDVR0RBBYwFIESamhlcnpvZ0BsbC5taXQuZWR1MA0GCSqGSIb3DQEB BQUAA4IBAQBI6aoe1c6Glzs3Hh/lIzf2TzmtZSQLl8UZaIFGi0zG0EjsO6wjX6bfv/WizE30OEef 6So76p0dNt7j21lrH+FGaH6r41ggikbkoazNkAePsQk0WPZhmpus1rByNUozK4KMPpzLAynHNd5m POtqoIwDiTEgktLuZ1nwU7bUHmv7BO14dkhLhMOFKRCIi3vqe9rDh9pTYt1YNhQe1fBme6Y5DWLA TxBBqErz05e7rVngKi6yk6j7cqWpiM6L93z2Zq5p9FqACsJHmMwxH/8XFeeXgFf/CKMAIuSZCGFU 29ouEZWL7LLu87SFGm3f/3sLS7xgXei7d/PlXte1HKKdKOCPMIIE1TCCA72gAwIBAgIKFU5e0QAA AAAiIDANBgkqhkiG9w0BAQUFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4g TGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xMB4XDTEwMDUyNTIw NDcxN1oXDTExMDUyNTIwNDcxN1owZDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xu IExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEjMCEGA1UEAxMaSGVyem9nLkpvbmF0aGFuLkMu NTAwMTEzMDUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtC8sNdkCteQagOVEnQQs4 5uLqsmaOfjqTywNWuvaVj0F8Jsek8bOcuK4rlB1PrBk0Q+s/N4FVcGEn6BEDWRIDFaETVr1jweTE yRUtqngTIvpbpeixV37BcFkVnbV2VrZC5oaa0c0bkxXkuE0lohQS5AIBXQRADEJVnfXIM44yvsmo T7J5rdGwjIg4QJ2YA07po0JkbndcylcjU0zW2Lv432MEZrX/o+T0rraFAhT8A+8De9CIo0LJkXCK cNwk6LwuNKQS0qeezDo5wRiqZaht3ftiAuOImOxN44hxnDa2cHVbOFQ+pevN08gH7d39CVHUbHMC PnuIBoQNu61I2+ItAgMBAAGjggGaMIIBljAOBgNVHQ8BAf8EBAMCBSAwHQYDVR0OBBYEFEuYUJcI JTs8b2SWTJN28DD/qqsNMB8GA1UdIwQYMBaAFJRaxljJtiaboAl7qC9kkMOJAm4qMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTEwYgYIKwYBBQUHAQEE VjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTEwIwYIKwYB BQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUH BDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0l BB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMB CDAdBgNVHREEFjAUgRJqaGVyem9nQGxsLm1pdC5lZHUwDQYJKoZIhvcNAQEFBQADggEBAAmf5m3W 0Di4aQhLS1e2xejG3MQPQJvWL3dHbnHYG+NDVFWcuqyE5t73eb7nV2UyGRVHDt6MyIquedAPPm86 FSPZ6CUGGj5imp9pAu7C+xESBMY4z0k5htK/h5vlSB9X/i3JbXI8KBOioH1QYenMfrvTISmk/+5A BHsMDOpK7//bX66DP+iopoIiWJktY+dfiak7uTZhuYEOmICq4QlP9dDqdPiQGje4Y8xZ45YL6+2I m5GIzuIac/r51YTBuCk+TxTZIITMx+Fr50Ur6s4dOnvApxMR7iZX6oKnmVfXrjFMMQxR1TN5ISUn IoMyID3yCiInqQh6G3WPCAhwa/qG/moxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYD VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExM IENBLTECChVM3JYAAAAAIh8wCQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTEwMzExMjExMzQxWjAjBgkqhkiG9w0BCQQxFgQUg/EoyNvOIOFn xfr0OlqoplyvUSwwbgYJKwYBBAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xAgoV Tl7RAAAAACIgMHAGCyqGSIb3DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xAgoV Tl7RAAAAACIgMA0GCSqGSIb3DQEBAQUABIIBABTEGigg9Qxad4DYe2eaaUA9HOOiOP3cLxW5a8Dn jKL/P4lASH0rPlbIUXkCybnH7UWS0s05aU07CEE06Eeq4TL4TSIXsbM0EqJd7ZsZD+TmVRQ62YDk SbrJz2RkEW/crgcXOmEZuoqf+aWXG6txfeuteXj9luslWfLRgc7xbTs0s+P1hv69xEILUKu7EI4s MC+/NIsCiOTORcxxSoryJOHhlnKYoERmhId9HWQVkcdpQZyYU1WGW/G0hOivVnxz/aZ5kb5F/zto XzmBKjf/urFiTfj0QO2lRHO0foInQS0V0jhrG8y+3TRV3DHJhikZLGF2/Ud8vVyksjK9wjrdMDwA AAAAAAA= --Apple-Mail-184--551726109-- From prvs=20548b1026=jherzog@ll.mit.edu Mon Mar 14 06:46:00 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C55023A6D73; Mon, 14 Mar 2011 06:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.847 X-Spam-Level: X-Spam-Status: No, score=-5.847 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjjjpW5QmyQX; Mon, 14 Mar 2011 06:45:57 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by core3.amsl.com (Postfix) with ESMTP id B948C3A6D72; Mon, 14 Mar 2011 06:45:56 -0700 (PDT) Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id p2EDlFfZ021630; Mon, 14 Mar 2011 09:47:15 -0400 From: "Herzog, Jonathan - 0668 - MITLL" To: "Herzog, Jonathan - 0668 - MITLL" Date: Mon, 14 Mar 2011 09:47:14 -0400 Thread-Topic: [secdir] Secdir review of draft-herzog-static-ecdh-05 Thread-Index: AcviTlPwVoTcbTm5SiGIfQxALeXKCw== Message-ID: References: <552BBAA9-712F-49B4-8A5F-C671C3817C05@ll.mit.edu> <47CF9528-81A1-49D7-8D4B-B1DCC136581E@ll.mit.edu> <3E69AF7B-D325-4FC5-A003-FEBA1997D67E@cisco.com> <65D56695-894D-458E-A9C4-6DCF6A38F196@cisco.com> <29C1F1D5-6EF0-4055-BA88-03F03E3F0A84@ll.mit.edu> <63667400-81DF-438E-869F-247222DECA18@ll.mit.edu> <7EA8F35D-5D31-472E-BE37-3789470D059A@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-9--319312425"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-14_04:2011-03-14, 2011-03-14, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=8 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1012030000 definitions=main-1103140068 X-Mailman-Approved-At: Tue, 15 Mar 2011 08:10:09 -0700 Cc: "secdir@ietf.org" , "draft-herzog-static-ecdh@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 13:46:00 -0000 --Apple-Mail-9--319312425 Content-Type: multipart/mixed; boundary=Apple-Mail-8--319312457 --Apple-Mail-8--319312457 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Mar 11, 2011, at 4:13 PM, Herzog, Jonathan - 0668 - MITLL wrote: > On Mar 11, 2011, at 3:32 PM, David McGrew wrote: >>=20 >> I hope that the KDF from X9.63 that is referenced in SEC1 is the =20 >> Concatenation Key Derivation Function (Section 5.8.1 of SP800-56A), = or =20 >> if not, the ASN.1 Key Derivation Function (Section 5.8.2). =20 >=20 >=20 > Mostly 'yes,' but just enough 'no' to be a real problem for us. Both = the KDF in SEC1/X9.63 and the KDFs in 800-56A take the Diffie Hellman = secret and some Other Stuff, and produce keying material as output. But = they are not the exact same KDF. =46rom SP 800-56A, Appendix A ("Summary = of Differences between this Recommendation and ANS X9 Standards"): >=20 > [Begin quote] >=20 > 8. Regarding the key derivation function (KDF): >=20 > a. This recommendation specifies two Approved KDFs, the concatenation = KDF specified in Section 5.8.1 and the ASN.1 KDF specified in Section = 5.8.2. Other key derivation methods may be temporarily allowed for = backward compatibility. These other allowable methods and any = restrictions on their use will be specified in FIPS 140-2 Annex D. >=20 > b. ANS X9.42 provides a concatenation KDF and an ASN.1 KDF, while ANS = X9.63 provides only the concatenation KDF. However, the Approved KDFs of = this Recommendation require that the counter appears before the shared = secret as input to the hash function, whereas the ANSI KDFs place the = counter after the shared secret >=20 > c. The Approved KDFs in this Recommendation require the input of the = identifiers of the communicating parties; such information is not = required in ANS X9.42 and X9.63. >=20 > d. In this Recommendation, the shared secret is zeroized after a = single call to a key derivation function, before the key agreement = scheme releases any portion of the DerivedKeyingMaterial for use by = relying applications.. The ANS X9.42 and X9.63 standards do not indicate = when the shared secret needs to be zeroized. An implication of this = Recommendation=92s requirement concerning zeroization is that all of the = keying material directly derived from the shared secret must be computed = during one call to the KDF. >=20 > [End quote] >=20 > Point (d) is not an issue for this discussion, and point (a) is just = informative. But points (b) and (c) are both show-stoppers. Point (b) = says that SEC1/X9.63 and SP 800-56A disagree on how to turn the inputs = into keying material. Point (c) says that they disagree on what the = Other Stuff must contain. Specifically, SP 800-56A requires that the = Other Stuff contain: >=20 > * ID of the algorithm, > * ID of the sender, > * ID of the receiver, > * Sender randomness (optional), and > * Receiver randomness (optional).=20 >=20 > SEC1 places no restriction on the Other Stuff. But RFC 5753 says that = the Other Stuff must be the DER encoding of an ECC-CMS-SharedInfo = structure, which contains: >=20 > * ID of the algorithm, > * Sender randomness (optional), and > * Length of output key (optional). >=20 > So unless I'm wrong (again, more than likely) the SEC1/X9.63 and SP = 800-56A KDFs are not compatible. And in fact, we can't switch to the SP = 800-56A KDFs without introducing some tricky incompatibilities with RFC = 5753. (Implementors would have to implement one KDF for ephemeral-static = ECDH and a different one for static-static ECDH). >=20 > Given this, what do people think of citing X9.63 for the KDF? And = about citing SEC1 as an informative reference so that people can find = the KDF without having to buy an ANSI standard? I was advised to submit an updated draft over the weekend, even if some = issues were still up in the air. So, draft-herzog-static-ecdh-06.txt has = been submitted and is awaiting manual posting. In the meantime, a copy = is attached to this mail. As you can see, I went ahead and made the = change I proposed above: citing X9.63 as the normative standard for the = KDF in RFC 5753, wit SEC1 as an informative reference. Thoughts? Cheers. --=20 Jonathan Herzog voice: = (781) 981-2356 Technical Staff fax: = (781) 981-7687 Cyber Systems and Technology Group email: = jherzog@ll.mit.edu MIT Lincoln Laboratory www: = http://www.ll.mit.edu/CST/ 244 Wood Street =20 Lexington, MA 02420-9185 --Apple-Mail-8--319312457 Content-Disposition: attachment; filename=draft-herzog-static-ecdh-06.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-herzog-static-ecdh-06.txt" Content-Transfer-Encoding: quoted-printable Network Working Group J. Herzog Internet-Draft R. Khazan Intended status: Informational MIT Lincoln Laboratory Expires: September 14, 2011 March 13, 2011 Use of static-static Elliptic-Curve Diffie-Hellman key agreement in Cryptographic Message Syntax draft-herzog-static-ecdh-06 Abstract This document describes how to use 'static-static' Elliptic Curve Diffie-Hellman key-agreement (i.e., Elliptic Curve Diffie-Hellman where both participants use static Diffie-Hellman values) with the Cryptographic Message Syntax. In this form of key-agreement, the Diffie-Hellman values of both sender and receiver are long-term values contained in certificates. Disclaimer This work is sponsored by the United States Air Force under Air Force Contract FA8721-05-C-0002. Opinions, interpretations, conclusions and recommendations are those of the authors and are not necessarily endorsed by the United States Government. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 14, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Herzog & Khazan Expires September 14, 2011 [Page 1] =0C Internet-Draft Static-static ECDH in CMS March 2011 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Terminology . . . . . . . . . . . . . . . . . 5 2. EnvelopedData using static-static ECDH . . . . . . . . . . . . 5 2.1. Fields of the KeyAgreeRecipientInfo . . . . . . . . . . . 5 2.2. Actions of the sending agent . . . . . . . . . . . . . . . 6 2.3. Actions of the receiving agent . . . . . . . . . . . . . . 7 3. AuthenticatedData using static-static ECDH . . . . . . . . . . 8 3.1. Fields of the KeyAgreeRecipientInfo . . . . . . . . . . . 8 3.2. Actions of the sending agent . . . . . . . . . . . . . . . 9 3.3. Actions of the receiving agent . . . . . . . . . . . . . . 9 4. AuthEnvelopedData using static-static ECDH . . . . . . . . . . 9 4.1. Fields of the KeyAgreeRecipientInfo . . . . . . . . . . . 9 4.2. Actions of the sending agent . . . . . . . . . . . . . . . 9 4.3. Actions of the receiving agent . . . . . . . . . . . . . . 9 5. Comparison to [RFC5753] . . . . . . . . . . . . . . . . . . . 9 6. Requirements and Recommendations . . . . . . . . . . . . . . . 11 7. Security considerations . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Herzog & Khazan Expires September 14, 2011 [Page 2] =0C Internet-Draft Static-static ECDH in CMS March 2011 1. Introduction This document describes how to use the static-static Elliptic-Curve Diffie-Hellman key agreement scheme (i.e., Elliptic Curve Diffie- Hellman [RFC6090] where both participants use static Diffie-Hellman values) in the Cryptographic Message Syntax (CMS) [RFC5652]. The CMS is a standard notation and representation for cryptographic messages. CMS uses ASN.1 notation [X.680] [X.681] [X.682] [X.683] to define a number of structures that carry both cryptographically-protected information and key-management information regarding the keys used. Of particular interest here are three structures: o EnvelopedData, which holds encrypted (but not necessarily authenticated) information [RFC5652], o AuthenticatedData, which holds authenticated (MACed) information [RFC5652], and o AuthEnvelopedData, which holds information protected by authenticated encryption: a cryptographic scheme that combines encryption and authentication [RFC5083]. All three of these types share the same basic structure. First, a fresh symmetric key is generated. This symmetric key has a different name that reflects its usage in each of the three structures. EnvelopedData uses a content-encryption key (CEK); AuthenticatedData uses an authentication key; AuthEnvelopedData uses a content- authenticated-encryption key. The originator uses the symmetric key to cryptographically protect the content. The symmetric key is then used wrapped for each recipient; only the intended recipient has access to the private keying material necessary to unwrap the symmetric key. Once unwrapped, the recipient uses the symmetric key to decrypt the content, check the authenticity of the content, or both. The CMS supports several different approaches to symmetric key wrapping, including: o key transport: the symmetric key is encrypted using the public encryption key of some recipient, o key-encryption key: the symmetric key is encrypted using a previously-distributed symmetric key, and o key agreement: the symmetric key is encrypted using a key- encryption key (KEK) created using a key-agreement scheme and a key-derivation function (KDF). One such key-agreement scheme is the Diffie-Hellman algorithm [RFC2631] which uses group-theory to produce a value known only to Herzog & Khazan Expires September 14, 2011 [Page 3] =0C Internet-Draft Static-static ECDH in CMS March 2011 its two participants. In this case, the participants are the originator and one of the recipients. Each participant produces a private value and a public value, and each participant can produce the shared secret value from their own private value and their counterpart's public value. There are some variations on the basic algorithm: o The basic algorithm typically uses the group 'Z mod p', meaning the set of integers modulo some prime p. One can also use an elliptic-curve group, which allows for shorter messages. o Over elliptic-curve groups, the standard algorithm can be extended to incorporate the 'cofactor' of the group. This method, called 'cofactor Elliptic Curve Diffie-Hellman' [SP800-56A] can prevent certain attacks possible in the elliptic-curve group. o The participants can generate fresh new public/private values (called ephemeral values) for each run of the algorithm, or they can re-use long-term values (called static values). Ephemeral values add randomness to the resulting private value, while static values can be embedded in certificates. The two participants do not need to use the same kind of value: either participant can use either type. In 'ephemeral-static' Diffie-Hellman, for example, the sender uses an ephemeral public/private pair value while the receiver uses a static pair. In 'static-static' Diffie-Hellman, on the other hand, both participants use static pairs. (Receivers cannot use ephemeral values in this setting, and so we ignore ephemeral-ephemeral and static-ephemeral Diffie-Hellman in this document.) Several of these variations are already described in existing CMS standards. [RFC3370] contains the conventions for using for ephemeral-static and static-static Diffie-Hellman over the 'basic' (Z mod p) group. [RFC5753] contains the conventions for using ephemeral-static Diffie-Hellman over elliptic curves (both standard and cofactor methods). It does not, however, contain conventions for using either method of static-static Elliptic-Curve Diffie-Hellman, preferring to discuss the ECMQV algorithm instead. In this document, we specify the conventions for using static-static Elliptic-Curve Diffie-Hellman (ECDH) for both standard and cofactor methods. Our motivation stems from the fact that ECMQV has been removed from the National Security Agency's Suite B of cryptographic algorithms and will therefore be unavailable to some participants. These participants can use ephemeral-static Elliptic Curve Diffie- Hellman, of course, but ephemeral-static Diffie-Hellman does not provide source authentication. CMS does allow the application of digital signatures for source authentication, but this alternative is Herzog & Khazan Expires September 14, 2011 [Page 4] =0C Internet-Draft Static-static ECDH in CMS March 2011 available only to those participants with certified signature keys. By specifying conventions for static-static Elliptic Curve Diffie- Hellman in this document, we present a third alternative for source- authentication, available to those participants with certified Elliptic Curve Diffie-Hellman keys. We note that like ephemeral-static ECDH, static-static ECDH creates a secret key shared by sender and receiver. Unlike ephemeral-static ECDH, however, static-static ECDH uses a static key pair for the sender. Each of the three CMS structures discussed in this document (EnvelopedData, AuthenticatedData, and AuthEnvelopedData) uses static-static ECDH to achieve different goals: o EnvelopedData uses static-static ECDH to provide data confidentiality. It will not necessarily, however, provide data authenticity. o AuthenticatedData uses static-static ECDH to provide data- authenticity. It will not provide data-confidentiality. o AuthEnvelopedData uses static-static ECDH to provide both of confidentiality and data-authenticity. 1.1. Requirements Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. EnvelopedData using static-static ECDH If an implementation uses static-static ECDH with CMS EnvelopedData then the following techniques and formats MUST be used. The fields of EnvelopedData are as in [RFC5652]; as static-static ECDH is a key agreement algorithm, the RecipientInfo kari choice is used. When using static-static ECDH, the EnvelopedData originatorInfo field MAY include the certificate(s) for the EC public key(s) used in the formation of the pairwise key. 2.1. Fields of the KeyAgreeRecipientInfo When using static-static ECDH with EnvelopedData, the fields of KeyAgreeRecipientInfo [RFC5652] are: o version MUST be 3. Herzog & Khazan Expires September 14, 2011 [Page 5] =0C Internet-Draft Static-static ECDH in CMS March 2011 o originator identifies the static EC public key of the sender. It MUST be either issuerAndSerialNumber or subjectKeyIdentifier, and point to one of the sending agent's certificates. o ukm MAY be present or absent. However, message originators SHOULD include the ukm and SHOULD ensure that the value of ukm is unique to the message being sent. As specified in [RFC5652], implementations MUST support ukm message recipient processing, so interoperability is not a concern if the ukm is present or absent. The use of a fresh value for ukm will ensure that a different key is generated for each message between the same sender and receiver. ukm, if present, is placed in the entityUInfo field of the ECC-CMS-SharedInfo structure [RFC5753] and therefore used as an input to the key derivation function. o keyEncryptionAlgorithm MUST contain the object identifier of the key encryption algorithm, which in this case is a key agreement algorithm (see Section 5). The parameters field contains KeyWrapAlgorithm. The KeyWrapAlgorithm is the algorithm identifier that indicates the symmetric encryption algorithm used to encrypt the content-encryption key (CEK) with the key- encryption key (KEK) and any associated parameters (see Section 5). o recipientEncryptedKeys contains an identifier and an encrypted CEK for each recipient. The RecipientEncryptedKey KeyAgreeRecipientIdentifier MUST contain either the issuerAndSerialNumber identifying the recipient's certificate or the RecipientKeyIdentifier containing the subject key identifier from the recipient's certificate. In both cases, the recipient's certificate contains the recipient's static ECDH public key. RecipientEncryptedKey EncryptedKey MUST contain the content- encryption key encrypted with the static-static ECDH-generated pairwise key-encryption key using the algorithm specified by the KeyWrapAlgorithm. 2.2. Actions of the sending agent When using static-static ECDH with EnvelopedData, the sending agent first obtains the EC public key(s) and domain parameters contained in the recipient's certificate. It MUST confirm the following at least once per recipient-certificate: o That both certificates (the recipient's certificate and its own) contain public-key values with the same curve parameters, and o That both of these public-key values are marked as appropriate for ECDH (that is, marked with algorithm-identifiers id-ecPublicKey or Herzog & Khazan Expires September 14, 2011 [Page 6] =0C Internet-Draft Static-static ECDH in CMS March 2011 id-ecDH [RFC5480]). The sender then determines whether to use standard or cofactor Diffie-Hellman. After doing so, the sender then determines which hash algorithms to use for the key-derivation function. It then chooses keyEncryptionAlgorithm that reflects these choices. It then determines: o an integer "keydatalen", which is the KeyWrapAlgorithm symmetric key-size in bits, and o the value of ukm, if used. The sender then determines a bit string "SharedInfo", which is the DER encoding of ECC-CMS-SharedInfo (see Section 7.2 of [RFC5753]). The sending agent then performs either the Elliptic Curve Diffie Hellman operation of [RFC6090] (for standard Diffie-Hellman) or the Elliptic Curve Cryptography Cofactor Diffie-Hellman (ECC CDH) Primitive of [SP800-56A] (for cofactor Diffie-Hellman). The sending agent then applies the simple hash function construct of [X963] (using the hash algorithm identified in the key agreement algorithm) to the results of the Diffie-Hellman operation and the SharedInfo string. (This construct is also described in Section 3.6.1 of [SEC1].) As a result the sending agent obtains a shared secret bit string "K", which is used as the pairwise key-encryption key (KEK) to wrap the CEK for that recipient, as specified in [RFC5652]. 2.3. Actions of the receiving agent When using static-static ECDH with EnvelopedData, the receiving agent retrieves keyEncryptionAlgorithm to determine the key-agreement algorithm chosen by the sender, which will identify: o the domain-parameters of the curve used, o whether standard or cofactor Diffie-Hellman was used, and o which hash-function was used for the KDF. The receiver then retrieves the sender's certificate identified in the rid field, and extracts the EC public key(s) and domain parameters contained therein. It MUST confirm the following at least once per sender-certificate: o That both certificates (the sender's certificate and its own) contain public-key values with the same curve parameters, and Herzog & Khazan Expires September 14, 2011 [Page 7] =0C Internet-Draft Static-static ECDH in CMS March 2011 o That both of these public-key values are marked as appropriate for ECDH (that is, marked with algorithm-identifiers id-ecPublicKey or id-ecDH [RFC5480]). The receiver then determines whether standard or cofactor Diffie- Hellman was used. The receiver then determines a bit string "SharedInfo", which is the DER encoding of ECC-CMS-SharedInfo (see Section 7.2 of [RFC5753]). The receiving agent then performs either the Elliptic Curve Diffie Hellman operation of [RFC6090] (for standard Diffie-Hellman) or the Elliptic Curve Cryptography Cofactor Diffie-Hellman (ECC CDH) Primitive of [SP800-56A] (for cofactor Diffie-Hellman). The receiving agent then applies the simple hash function construct of [X963] (using the hash algorithm identified in the key agreement algorithm) to the results of the Diffie-Hellman operation and the SharedInfo string. (This construct is also described in Section 3.6.1 of [SEC1].) As a result, the receiving agent obtains a shared secret bit string "K", which it uses as the pairwise key-encryption key to unwrap the CEK. 3. AuthenticatedData using static-static ECDH This section describes how to use the static-static ECDH key agreement algorithm with AuthenticatedData. When using static-static ECDH with AuthenticatedData, the fields of AuthenticatedData are as in [RFC5652], but with the following restrictions: o macAlgorithm MUST contain the algorithm identifier of the message authentication code (MAC) algorithm. This algorithm SHOULD be one of the following: id-hmacWITHSHA224, id-hmacWITHSHA256, id- hmacWITHSHA384, or id-hmacWITHSHA512, and SHOULD NOT be hmac-SHA1. (See Section 5.) o digestAlgorithm MUST contain the algorithm identifier of the hash algorithm. This algorithm SHOULD be one of the following: id- sha224, id-sha256, id-sha384, and id-sha512, and SHOULD NOT be id- sha1. (See Section 5.) As static-static ECDH is a key agreement algorithm, the RecipientInfo kari choice is used in the AuthenticatedData. When using static- static ECDH, the AuthenticatedData originatorInfo field MAY include the certificate(s) for the EC public key(s) used in the formation of the pairwise key. 3.1. Fields of the KeyAgreeRecipientInfo The AuthenticatedData KeyAgreeRecipientInfo fields are used in the same manner as the fields for the corresponding EnvelopedData Herzog & Khazan Expires September 14, 2011 [Page 8] =0C Internet-Draft Static-static ECDH in CMS March 2011 KeyAgreeRecipientInfo fields of Section 2.1 of this document. The authentication key is wrapped in the same manner as is described there for the content-encryption key. 3.2. Actions of the sending agent The sending agent uses the same actions as for EnvelopedData with static-static ECDH, as specified in Section 2.2 of this document. 3.3. Actions of the receiving agent The receiving agent uses the same actions as for EnvelopedData with static-static ECDH, as specified in Section 2.3 of this document. 4. AuthEnvelopedData using static-static ECDH When using static-static ECDH with AuthEnvelopedData, the fields of AuthEnvelopedData are as in [RFC5083]. As static-static ECDH is a key agreement algorithm, the RecipientInfo kari choice is used. When using static-static ECDH, the AuthEnvelopedData originatorInfo field MAY include the certificate(s) for the EC public key used in the formation of the pairwise key. 4.1. Fields of the KeyAgreeRecipientInfo The AuthEnvelopedData KeyAgreeRecipientInfo fields are used in the same manner as the fields for the corresponding EnvelopedData KeyAgreeRecipientInfo fields of Section 2.1 of this document. The content-authenticated-encryption key is wrapped in the same manner as is described there for the content-encryption key. 4.2. Actions of the sending agent The sending agent uses the same actions as for EnvelopedData with static-static ECDH, as specified in Section 2.2 of this document. 4.3. Actions of the receiving agent The receiving agent uses the same actions as for EnvelopedData with static-static ECDH, as specified in Section 2.3 of this document. 5. Comparison to [RFC5753] This document defines the use of static-static ECDH for EnvelopedData, AuthenticatedData, and AuthEnvelopedData. The standard [RFC5753] defines ephemeral-static ECDH for EnvelopedData Herzog & Khazan Expires September 14, 2011 [Page 9] =0C Internet-Draft Static-static ECDH in CMS March 2011 only. With regard to EnvelopedData, this document and [RFC5753] greatly parallel each other. Both specify how to apply Elliptic-Curve Diffie-Hellman, and differ only on how the sender's public value is to be communicated to the recipient. In [RFC5753], the sender provides the public value explicitly by including an OriginatorPublicKey value in the originator field of KeyAgreeRecipientInfo. In this document, the sender include a reference to a (certified) public value by including either an IssuerAndSerialNumber or SubjectKeyIdentifier value in the same field. Put another way, [RFC5753] provides an interpretation of a KeyAgreeRecipientInfo structure where: o the keyEncryptionAlgorithm value indicates Elliptic-Curve Diffie- Hellman, and o the originator field contains a OriginatorPublicKey value. This document, on the other hand, provides an interpretation of a KeyAgreeRecipientInfo structure where o the keyEncryptionAlgorithm value indicates Elliptic-Curve Diffie- Hellman, and o the originator field contains either a IssuerAndSerialNumber value or a SubjectKeyIdentifier value. AuthenticatedData or AuthEnvelopedData messages, on the other hand, are not given any form of ECDH by [RFC5753]. This is appropriate: that document only defines ephemeral-static Diffie-Hellman, and this form of Diffie-Hellman does not (inherently) provide any form of data-authentication or data-origin authentication. This document, on the other hand, requires that the sender use a certified public value. Thus, this form of key-agreement provides implicit key authentication and, under some limited circumstances, data-origin authentication. (See Section 7.) This document does not define any new ASN.1 structures or algorithm identifiers. It provides new ways to interpret structures from [RFC5652] and [RFC5753], and allows previously-defined algorithms to be used under these new interpretations. Specifically: o The ECDH key-agreement algorithm-identifiers from [RFC5753] define only how Diffie-Hellman values are processed, not where these values are created. Therefore, they can be used for static-static ECDH with no changes. Herzog & Khazan Expires September 14, 2011 [Page 10] =0C Internet-Draft Static-static ECDH in CMS March 2011 o The key-wrap, MAC, and digest algorithms referenced in [RFC5753] describe how the secret key is to be used, not created. Therefore, they can be used with keys from static-static ECDH without modification. 6. Requirements and Recommendations It is RECOMMENDED that implementations of this specification support AuthenticatedData and EnvelopedData. Support for AuthEnvelopedData is OPTIONAL. Implementations that support this specification MUST support standard Elliptic Curve Diffie-Hellman, and these implementation MAY also support cofactor Elliptic Curve Diffie-Hellman. In order to encourage interoperability, implementations SHOULD use the elliptic curve domain parameters specified by [RFC5480]. Implementations that support standard static-static Elliptic Curve Diffie-Hellman: MUST support the dhSinglePass-stdDH-sha256kdf-scheme key agreement algorithm; MAY support the dhSinglePass-stdDH-sha224kdf-scheme, dhSinglePass- stdDH-sha384kdf-scheme and dhSinglePass-stdDH-sha512kdf-scheme key agreement algorithms; and SHOULD NOT support the dhSinglePass-stdDH-sha1kdf-scheme Other algorithms MAY also be supported. Implementations that support cofactor static-static Elliptic-Curve Diffie-Hellman: MUST support the dhSinglePass-cofactorDH-sha256kdf-scheme key agreement algorithm; MAY support the dhSinglePass-cofactorDH-sha224kdf-scheme, dhSinglePass-cofactorDH-sha384kdf-scheme, and dhSinglePass- cofactorDH-sha512kdf-scheme key agreement algorithms; and, SHOULD NOT support the dhSinglePass-cofactorDH-sha1kdf-scheme. In addition, all implementations: Herzog & Khazan Expires September 14, 2011 [Page 11] =0C Internet-Draft Static-static ECDH in CMS March 2011 MUST support the id-aes128-wrap key wrap algorithm and the id- aes128-cbc content encryption algorithm; MAY support: * The the id-aes192-wrap and id-aes256-wrap key wrap algorithms; * The id-aes128-CCM, id-aes192-CCM, id-aes256-CCM, id-aes128-GCM, id-aes192-GCM, id-aes256-GCM authenticated-encryption algorithms; and * id-aes192-cbc, and id-aes256-cbc content encryption algorithms. SHOULD NOT support the id-alg-CMS3DESwrap key-wrap algorithm or the des-ede3-cbc content encryption algorithms. (All algorithms above defined in [RFC3370], [RFC3565], [RFC5084], and [RFC5753].) Unless otherwise noted above, other algorithms MAY also be supported. 7. Security considerations All security considerations in Section 9 of [RFC5753] apply. Extreme care must be used when using static-static Diffie-Hellman (either standard or cofactor) without the use of some per-message value in ukm. As described in [RFC5753], the ukm value (if present) will be embedded in a ECC-CMS-SharedInfo structure and the DER- encoding of this structure will be used as the 'SharedInfo' input to the key-derivation function of [X963]. The purpose of this input is to add a message-unique value to the key-distribution function so that two different sessions of static-static ECDH between a given pair of agents result in independent keys. If the ukm value is not used or is re-used, on the other hand, then the ECC-CMS-SharedInfo structure (and 'SharedInfo' input) will likely not vary from message to message. In this case, the two agents will re-use the same keying material across multiple messages. This is considered to be bad cryptographic practice and may open the sender to attacks on Diffie- Hellman (e.g., the 'small subgroup' attack [MenezesUstaoglu] or other, yet-undiscovered attacks). It is for these reasons that Section 2.1 states that message-senders SHOULD include the ukm and SHOULD ensure that the value of ukm is unique to the message being sent. One way to ensure the uniqueness of ukm is for the message sender to choose a 'sufficiently long' random string for each message (where, as a rule of thumb, a 'sufficiently long' string is one at least as long as the keys used Herzog & Khazan Expires September 14, 2011 [Page 12] =0C Internet-Draft Static-static ECDH in CMS March 2011 by the key-wrap algorithm identified in the keyEncryptionAlgorithm field of the KeyAgreeRecipientInfo structure). However, other methods (such as a counter) are possible. Also, applications which cannot tolerate the inclusion of per-message information in ukm (due to bandwidth requirements, for example) SHOULD NOT use static-static ECDH for a recipient without ascertaining that the recipient knows the private value associated with their certified Diffie-Hellman value. Static-static Diffie-Hellman, when used as described in this document, does not necessarily provide data-origin authentication. Consider, for example, the following sequence of events: o Alice sends an AuthEnvelopedData message to both Bob and Mallory. Furthermore, Alice uses a static-static DH method to transport the content-authenticated-encryption key to Bob, and some arbitrary method to transport the same key to Mallory. o Mallory intercepts the message and prevents Bob from receiving it. o Mallory recovers the content-authenticated-encryption key from the message received from Alice. Mallory then creates new plaintext of her choice, and encrypts it using the same authenticated- encryption algorithm and the same content-authenticated-encryption key used by Alice. o Mallory then replaces the EncryptedContentInfo and MessageAuthenticationCode fields of Alice's message with the values Mallory just generated. She may additionally remove her RecipientInfo value from Alice's message. o Mallory sends the modified message to Bob. o Bob receives the message, validates the static-static DH works and decrypts/authenticates the message. At this point, Bob has received and validated a message that appears to have been sent by Alice, but whose content was chosen by Mallory. Mallory may not even be an apparent receiver of the modified message. Thus, this use of static-static Diffie-Hellman does not necessarily provide data-origin authentication. (We note that this example does not also contradict either confidentiality or data-authentication: Alice's message was not received by anyone not intended by Alice, and Mallory's message was not modified before reaching Bob.) More generally, data-origin may not be authenticated unless Herzog & Khazan Expires September 14, 2011 [Page 13] =0C Internet-Draft Static-static ECDH in CMS March 2011 o It is a priori guaranteed that the message in question was sent to exactly one recipient, or o Data-origin authentication is provided by some other mechanism (such as digital signatures). However, we also note that this lack of authentication is not a product of static-static ECDH, per se, but is inherent in the way key-agreement schemes are used in the AuthenticatedData and AuthEnvelopedData structures of CMS. 8. IANA Considerations There are no IANA considerations. 9. Acknowledgements The authors would like to thank Jim Schaad, Russ Housley, Sean Turner, Brian Weis, Rene Struik, Brian Carpenter, David McGrew and Stephen Farrell for their helpful comments and suggestions. We would also like to thank Jim Schaad for describing to us the attack described in Section 7. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002. [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, July 2003. [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", RFC 5083, November 2007. [RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)", RFC 5084, November 2007. Herzog & Khazan Expires September 14, 2011 [Page 14] =0C Internet-Draft Static-static ECDH in CMS March 2011 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, March 2009. [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 5652, September 2009. [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", RFC 5753, January 2010. [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011. [SP800-56A] Barker, E., Johnson, D., and M. Smid, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised)", NIST Special Publication (SP) 800-56A, March 2007. [X963] "Public Key Cryptography for the Financial Services Industry, Key Agreement and Key Transport Using Elliptic Curve Cryptography", ANSI X9.63, 2001. 10.2. Informative References [MenezesUstaoglu] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys in Diffie-Hellman Key Agreement Protocols". International Journal of Applied Cryptography, Vol. 2, No. 2, pp. 154-158, 2010. [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999. [SEC1] Standards for Efficient Cryptography Group (SECG), "SEC 1: Elliptic Curve Cryptography", Version 2.0, May 2009. [X.680] ITU-T, "Information Technology - Abstract Syntax Notation One", Recommendation X.680, ISO/IEC 8824-1:2002, 2002. [X.681] ITU-T, "Information Technology - Abstract Syntax Notation One: Information Object Specification", Recommendation X.681, ISO/IEC 8824-2:2002, 2002. [X.682] ITU-T, "Information Technology - Abstract Syntax Notation One: Constraint Specification", Recommendation X.682, ISO/ Herzog & Khazan Expires September 14, 2011 [Page 15] =0C Internet-Draft Static-static ECDH in CMS March 2011 IEC 8824-3:2002, 2002. [X.683] ITU-T, "Information Technology - Abstract Syntax Notation One: Parameterization of ASN.1 Specifications", Recommendation X.683, ISO/IEC 8824-4:2002, 2002. Authors' Addresses Jonathan C. Herzog MIT Lincoln Laboratory 244 Wood St. Lexington, MA 02144 USA Email: jherzog@ll.mit.edu Roger Khazan MIT Lincoln Laboratory 244 Wood St. Lexington, MA 02144 USA Email: rkh@ll.mit.edu Herzog & Khazan Expires September 14, 2011 [Page 16] =0C --Apple-Mail-8--319312457-- --Apple-Mail-9--319312425 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJrzCCBNIw ggO6oAMCAQICChVM3JYAAAAAIh8wDQYJKoZIhvcNAQEFBQAwUTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwg Q0EtMTAeFw0xMDA1MjUyMDQ1MzhaFw0xMTA1MjUyMDQ1MzhaMGQxCzAJBgNVBAYTAlVTMR8wHQYD VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQZW9wbGUxIzAhBgNVBAMTGkhl cnpvZy5Kb25hdGhhbi5DLjUwMDExMzA1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 93mr5a6zq6EQsVtIX9BadxwzpjabF8pvDmoMSP/ZhbWrncNJ1j7xiBGcihYqsDaQz9+hJITxi7IM NUx5fnFtOQRHZgkOCLR1URFc0AlJ3Pknv6XoQ4fqPODmSMB882c9l/8AbO7N/27r8n/V0Ip4Rpw8 1qnrDXk6UH/1zHlssGmlVng0RSREuQy98xPxzbLr5cOMWLwHs5OLNYcGv0KlD6rp1DPzJ3qplU/+ 0P2jyYbGyXStJ/h+3Kx5mOWFLB4j8HDyLG90ZHlZjZXo9FrSoFubVJK/mdVzIuXd00Ldl1fCyxhR D9elkpTc7xOLJsEzCCi8Gqo6eQuvz1RH93u3PwIDAQABo4IBlzCCAZMwDgYDVR0PAQH/BAQDAgbA MB0GA1UdDgQWBBRPjG6+CxR6H/o9vyq5PgmW9vmuajAfBgNVHSMEGDAWgBSUWsZYybYmm6AJe6gv ZJDDiQJuKjAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xM Q0ExMGIGCCsGAQUFBwEBBFYwVDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dHRvL0xMQ0ExMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5sbC5taXQuZWR1LzAMBgNVHRMBAf8E AjAAMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH /4pzAgFkAgEFMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8w DQYLKoZIhvcSAgEDAQgwHQYDVR0RBBYwFIESamhlcnpvZ0BsbC5taXQuZWR1MA0GCSqGSIb3DQEB BQUAA4IBAQBI6aoe1c6Glzs3Hh/lIzf2TzmtZSQLl8UZaIFGi0zG0EjsO6wjX6bfv/WizE30OEef 6So76p0dNt7j21lrH+FGaH6r41ggikbkoazNkAePsQk0WPZhmpus1rByNUozK4KMPpzLAynHNd5m POtqoIwDiTEgktLuZ1nwU7bUHmv7BO14dkhLhMOFKRCIi3vqe9rDh9pTYt1YNhQe1fBme6Y5DWLA TxBBqErz05e7rVngKi6yk6j7cqWpiM6L93z2Zq5p9FqACsJHmMwxH/8XFeeXgFf/CKMAIuSZCGFU 29ouEZWL7LLu87SFGm3f/3sLS7xgXei7d/PlXte1HKKdKOCPMIIE1TCCA72gAwIBAgIKFU5e0QAA AAAiIDANBgkqhkiG9w0BAQUFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4g TGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xMB4XDTEwMDUyNTIw NDcxN1oXDTExMDUyNTIwNDcxN1owZDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xu IExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEjMCEGA1UEAxMaSGVyem9nLkpvbmF0aGFuLkMu NTAwMTEzMDUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtC8sNdkCteQagOVEnQQs4 5uLqsmaOfjqTywNWuvaVj0F8Jsek8bOcuK4rlB1PrBk0Q+s/N4FVcGEn6BEDWRIDFaETVr1jweTE yRUtqngTIvpbpeixV37BcFkVnbV2VrZC5oaa0c0bkxXkuE0lohQS5AIBXQRADEJVnfXIM44yvsmo T7J5rdGwjIg4QJ2YA07po0JkbndcylcjU0zW2Lv432MEZrX/o+T0rraFAhT8A+8De9CIo0LJkXCK cNwk6LwuNKQS0qeezDo5wRiqZaht3ftiAuOImOxN44hxnDa2cHVbOFQ+pevN08gH7d39CVHUbHMC PnuIBoQNu61I2+ItAgMBAAGjggGaMIIBljAOBgNVHQ8BAf8EBAMCBSAwHQYDVR0OBBYEFEuYUJcI JTs8b2SWTJN28DD/qqsNMB8GA1UdIwQYMBaAFJRaxljJtiaboAl7qC9kkMOJAm4qMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTEwYgYIKwYBBQUHAQEE VjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTEwIwYIKwYB BQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUH BDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0l BB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMB CDAdBgNVHREEFjAUgRJqaGVyem9nQGxsLm1pdC5lZHUwDQYJKoZIhvcNAQEFBQADggEBAAmf5m3W 0Di4aQhLS1e2xejG3MQPQJvWL3dHbnHYG+NDVFWcuqyE5t73eb7nV2UyGRVHDt6MyIquedAPPm86 FSPZ6CUGGj5imp9pAu7C+xESBMY4z0k5htK/h5vlSB9X/i3JbXI8KBOioH1QYenMfrvTISmk/+5A BHsMDOpK7//bX66DP+iopoIiWJktY+dfiak7uTZhuYEOmICq4QlP9dDqdPiQGje4Y8xZ45YL6+2I m5GIzuIac/r51YTBuCk+TxTZIITMx+Fr50Ur6s4dOnvApxMR7iZX6oKnmVfXrjFMMQxR1TN5ISUn IoMyID3yCiInqQh6G3WPCAhwa/qG/moxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYD VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExM IENBLTECChVM3JYAAAAAIh8wCQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTEwMzE0MTM0NzE1WjAjBgkqhkiG9w0BCQQxFgQUIDf66QzJs7aD jVfAaXeWgBCt+B8wbgYJKwYBBAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xAgoV Tl7RAAAAACIgMHAGCyqGSIb3DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xAgoV Tl7RAAAAACIgMA0GCSqGSIb3DQEBAQUABIIBACszXC2fHSSdOyiOhXPp3FeMKcCcpk3RBSNQSHxH Kl3V/iSrR0Bb+IIKG2sWaTbjkMZ5wEhEr9QPJt+MiHYS5QuqVo3SmfYZjbGKXlprDpCUvGSb6Hm8 /PtIIZV4l7C8B750m+RW+ZUCfc6BL2N+d5OazfKTxmuXB9bTfl+OD3iczM0kw7N4MGN0UL1lYnJm jLoqH+pVCmiglXS5mRAsNPVyYtVBRAwCmekxVjEpVnJGnQSyjpz8E870xb7CZst+ha7EM0yaWuTR OvHnH4Q80krOMiZyH7PPicIZu9H4HAFVPg/NQ0Xp5KHwPin7EHS7+gTDLDEthGafvV2jVtVugcYA AAAAAAA= --Apple-Mail-9--319312425-- From kathleen.moriarty@emc.com Mon Mar 14 16:28:35 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD66A3A6D2E; Mon, 14 Mar 2011 16:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSIG2oT7uAvS; Mon, 14 Mar 2011 16:28:33 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id C4F793A6BA1; Mon, 14 Mar 2011 16:28:32 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2ENTqQW023279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Mar 2011 19:29:52 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Mon, 14 Mar 2011 19:29:40 -0400 Received: from mxhub06.corp.emc.com (mxhub06.corp.emc.com [128.221.46.114]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2ENTajW021399; Mon, 14 Mar 2011 19:29:36 -0400 Received: from mx06a.corp.emc.com ([169.254.1.171]) by mxhub06.corp.emc.com ([128.221.46.114]) with mapi; Mon, 14 Mar 2011 19:29:36 -0400 From: To: , , , Date: Mon, 14 Mar 2011 19:29:34 -0400 Thread-Topic: Secdir review of draft-ietf-intarea-server-logging-recommendations-03 Thread-Index: Acvin61M1zcGWjzaRNK+x7zSSR0zkQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Tue, 15 Mar 2011 08:10:08 -0700 Cc: draft-ietf-intarea-server-logging-recommendations@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: [secdir] Secdir review of draft-ietf-intarea-server-logging-recommendations-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 23:28:35 -0000 I reviewed this document (draft-ietf-intarea-server-logging-recommendations= -03) as part of the security directorate's ongoing effort to review all IET= F documents being processed by the IESG. These comments were written prima= rily for the benefit of the security area directors. Document editors and = WG chairs should treat these comments just like any other last call comment= s. The document looks pretty good from a security standpoint, but I would reco= mmend adding a few other items to be considered out-of-scope or additional = security considerations would be necessary. Since the document already men= tions that record retention is out-of-scope, I think it would be useful to = add that server security and transport security is important for the protec= tion of logs for Internet facing systems. After stating that it is an im= portant consideration, then state something to the effect of the service pr= ovider must consider the risks, including the data and services on the serv= er to determine the appropriate measures. The protection of logs is critical in incident investigations. If logs are= tampered with, evidence could be destroyed. I did see a few grammar nits as well. The Gen-Art review should cover that= . If you want me to take a look at it after these adjustments have been ma= de, I would be happy to assist. Best regards, Kathleen From bclaise@cisco.com Tue Mar 15 02:21:07 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 828A63A6BDA; Tue, 15 Mar 2011 02:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.642 X-Spam-Level: X-Spam-Status: No, score=-2.642 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kO7u6BOHWDSS; Tue, 15 Mar 2011 02:21:06 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id D42773A6C11; Tue, 15 Mar 2011 02:21:05 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2F8HwEk022511; Tue, 15 Mar 2011 09:17:58 +0100 (CET) Received: from [10.55.43.52] (ams-bclaise-8713.cisco.com [10.55.43.52]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2F8Hsxl010671; Tue, 15 Mar 2011 09:17:54 +0100 (CET) Message-ID: <4D7F20B2.3070102@cisco.com> Date: Tue, 15 Mar 2011 09:17:54 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Yaron Sheffer References: <4D7F1516.6080401@gmail.com> In-Reply-To: <4D7F1516.6080401@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 15 Mar 2011 08:10:08 -0700 Cc: me , draft-ietf-ipfix-structured-data.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-ipfix-structured-data-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 09:21:07 -0000 Hi Yaron, Thanks for your feedback. Sure we should add your proposed sentence. Regards, Benoit. > 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. > > IPFIX is a structured information model and protocol for transmitting > information about data flows. This document extends the model with > structured data, basically several types of lists. > > I have not reviewed the document in full, rather I have looked at the > security aspects only. The Security Considerations refer the reader to > the IPFIX protocol and data model RFCs, and I mostly agree, with one > exception. I suggest to add text similar to the next paragraph: > > The addition of complex data types necessarily complicates the > implementation of the Collector. This could easily result in new > security vulnerabilities (e.g., buffer overflows); this creates > additional risk in cases where either DTLS is not used, or if the > Observation Point and Collector belong to different trust domains. > > Thanks, > Yaron From uri@mit.edu Tue Mar 15 13:26:13 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40B8A3A6E44; Tue, 15 Mar 2011 13:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_OBFU_ALL=0.751] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1C90LM7IaovT; Tue, 15 Mar 2011 13:26:12 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by core3.amsl.com (Postfix) with ESMTP id 0700F3A6A8B; Tue, 15 Mar 2011 13:26:11 -0700 (PDT) X-AuditID: 12074424-b7b0bae000000a05-c7-4d7fcbb885ec Received: from mailhub-3.mit.edu ( [18.9.21.44]) by dmz-mailsec-scanner-7.mit.edu (Symantec Brightmail Gateway) with SMTP id DC.2B.02565.8BBCF7D4; Tue, 15 Mar 2011 16:27:36 -0400 (EDT) Received: from outgoing-legacy.mit.edu (OUTGOING-LEGACY.MIT.EDU [18.7.22.104]) by mailhub-3.mit.edu (8.13.8/8.9.2) with ESMTP id p2FKRZYh005498; Tue, 15 Mar 2011 16:27:36 -0400 Received: from webmail-8.mit.edu (WEBMAIL-8.MIT.EDU [18.9.23.18]) ) by outgoing-legacy.mit.edu (8.13.6/8.12.4) with ESMTP id p2FKSsfM014965; Tue, 15 Mar 2011 16:28:54 -0400 (EDT) Received: from webmail-8.mit.edu (webmail-8.mit.edu [127.0.0.1]) by webmail-8.mit.edu (8.13.8) with ESMTP id p2FKRTEw002007; Tue, 15 Mar 2011 16:27:29 -0400 Received: (from nobody@localhost) by webmail-8.mit.edu (8.13.8/8.13.8/Submit) id p2FKROcF002002; Tue, 15 Mar 2011 16:27:24 -0400 X-Authentication-Warning: webmail-8.mit.edu: nobody set sender to uri@mit.edu using -f Received: from c-24-63-227-189.hsd1.ma.comcast.net (c-24-63-227-189.hsd1.ma.comcast.net [24.63.227.189]) (User authenticated as uri@ATHENA.MIT.EDU) by webmail.mit.edu (Horde MIME library) with HTTP; Tue, 15 Mar 2011 16:27:24 -0400 Message-ID: <20110315162724.dv4j170hkw8oooo0@webmail.mit.edu> X-Priority: 3 (Normal) Date: Tue, 15 Mar 2011 16:27:24 -0400 From: Uri Blumenthal To: "Herzog, Jonathan - 0668 - MITLL" References: <552BBAA9-712F-49B4-8A5F-C671C3817C05@ll.mit.edu> <47CF9528-81A1-49D7-8D4B-B1DCC136581E@ll.mit.edu> <3E69AF7B-D325-4FC5-A003-FEBA1997D67E@cisco.com> <65D56695-894D-458E-A9C4-6DCF6A38F196@cisco.com> <29C1F1D5-6EF0-4055-BA88-03F03E3F0A84@ll.mit.edu> <63667400-81DF-438E-869F-247222DECA18@ll.mit.edu> <7EA8F35D-5D31-472E-BE37-3789470D059A@cisco.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: AAAAAReea6k= Cc: "iesg@ietf.org" , "draft-herzog-static-ecdh@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 20:26:13 -0000 Without diving into the details of various KDF and their cryptographic soundness - I think the proposal to cite X9.63 as normative and SEC1 as informative is good. Thanks! -- Quoting "Herzog, Jonathan - 0668 - MITLL" : > On Mar 11, 2011, at 4:13 PM, Herzog, Jonathan - 0668 - MITLL wrote: >> On Mar 11, 2011, at 3:32 PM, David McGrew wrote: >>> >>> I hope that the KDF from X9.63 that is referenced in SEC1 is the >>> Concatenation Key Derivation Function (Section 5.8.1 of SP800-56A), or >>> if not, the ASN.1 Key Derivation Function (Section 5.8.2). >> >> >> Mostly 'yes,' but just enough 'no' to be a real problem for us. Both >> the KDF in SEC1/X9.63 and the KDFs in 800-56A take the Diffie >> Hellman secret and some Other Stuff, and produce keying material as >> output. But they are not the exact same KDF. From SP 800-56A, >> Appendix A ("Summary of Differences between this Recommendation and >> ANS X9 Standards"): >> >> [Begin quote] >> >> 8. Regarding the key derivation function (KDF): >> >> a. This recommendation specifies two Approved KDFs, the >> concatenation KDF specified in Section 5.8.1 and the ASN.1 KDF >> specified in Section 5.8.2. Other key derivation methods may be >> temporarily allowed for backward compatibility. These other >> allowable methods and any restrictions on their use will be >> specified in FIPS 140-2 Annex D. >> >> b. ANS X9.42 provides a concatenation KDF and an ASN.1 KDF, while >> ANS X9.63 provides only the concatenation KDF. However, the Approved >> KDFs of this Recommendation require that the counter appears before >> the shared secret as input to the hash function, whereas the ANSI >> KDFs place the counter after the shared secret >> >> c. The Approved KDFs in this Recommendation require the input of the >> identifiers of the communicating parties; such information is not >> required in ANS X9.42 and X9.63. >> >> d. In this Recommendation, the shared secret is zeroized after a >> single call to a key derivation function, before the key agreement >> scheme releases any portion of the DerivedKeyingMaterial for use by >> relying applications.. The ANS X9.42 and X9.63 standards do not >> indicate when the shared secret needs to be zeroized. An implication >> of this Recommendation?s requirement concerning zeroization is that >> all of the keying material directly derived from the shared secret >> must be computed during one call to the KDF. >> >> [End quote] >> >> Point (d) is not an issue for this discussion, and point (a) is just >> informative. But points (b) and (c) are both show-stoppers. Point >> (b) says that SEC1/X9.63 and SP 800-56A disagree on how to turn the >> inputs into keying material. Point (c) says that they disagree on >> what the Other Stuff must contain. Specifically, SP 800-56A requires >> that the Other Stuff contain: >> >> * ID of the algorithm, >> * ID of the sender, >> * ID of the receiver, >> * Sender randomness (optional), and >> * Receiver randomness (optional). >> >> SEC1 places no restriction on the Other Stuff. But RFC 5753 says >> that the Other Stuff must be the DER encoding of an >> ECC-CMS-SharedInfo structure, which contains: >> >> * ID of the algorithm, >> * Sender randomness (optional), and >> * Length of output key (optional). >> >> So unless I'm wrong (again, more than likely) the SEC1/X9.63 and SP >> 800-56A KDFs are not compatible. And in fact, we can't switch to the >> SP 800-56A KDFs without introducing some tricky incompatibilities >> with RFC 5753. (Implementors would have to implement one KDF for >> ephemeral-static ECDH and a different one for static-static ECDH). >> >> Given this, what do people think of citing X9.63 for the KDF? And >> about citing SEC1 as an informative reference so that people can >> find the KDF without having to buy an ANSI standard? > > I was advised to submit an updated draft over the weekend, even if > some issues were still up in the air. So, > draft-herzog-static-ecdh-06.txt has been submitted and is awaiting > manual posting. In the meantime, a copy is attached to this mail. As > you can see, I went ahead and made the change I proposed above: > citing X9.63 as the normative standard for the KDF in RFC 5753, wit > SEC1 as an informative reference. > > Thoughts? > > Cheers. > > -- > Jonathan Herzog voice: (781) 981-2356 > Technical Staff fax: (781) 981-7687 > Cyber Systems and Technology Group email: jherzog@ll.mit.edu > MIT Lincoln Laboratory www: http://www.ll.mit.edu/CST/ > 244 Wood Street > Lexington, MA 02420-9185 > From turners@ieca.com Wed Mar 16 16:56:41 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0232A3A6AAE for ; Wed, 16 Mar 2011 16:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6gyvRJR8C2J for ; Wed, 16 Mar 2011 16:56:40 -0700 (PDT) Received: from nm19.bullet.mail.ac4.yahoo.com (nm19.bullet.mail.ac4.yahoo.com [98.139.52.216]) by core3.amsl.com (Postfix) with SMTP id 2CFF13A6A0D for ; Wed, 16 Mar 2011 16:56:40 -0700 (PDT) Received: from [98.139.52.196] by nm19.bullet.mail.ac4.yahoo.com with NNFMP; 16 Mar 2011 23:58:04 -0000 Received: from [98.139.52.140] by tm9.bullet.mail.ac4.yahoo.com with NNFMP; 16 Mar 2011 23:58:04 -0000 Received: from [127.0.0.1] by omp1023.mail.ac4.yahoo.com with NNFMP; 16 Mar 2011 23:58:04 -0000 X-Yahoo-Newman-Id: 550902.59442.bm@omp1023.mail.ac4.yahoo.com Received: (qmail 93877 invoked from network); 16 Mar 2011 23:58:04 -0000 Received: from thunderfish.local (turners@96.241.6.185 with plain) by smtp115.biz.mail.re2.yahoo.com with SMTP; 16 Mar 2011 16:58:04 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: Y0RdYv4VM1lYC0ls4JL37dZXd8lC_fDzf0yB_b4FX17.3fZ ia3kqgtaNMxtNPTN_YXwhAWphA5NXPNCj68WXR9cumyWT2_7_hQ8rQRRN2gl lh4EwhpmCMJ7sD2tlmSRLUI5qLbmHEkJScyKU1RvxAFaVkGdHKRkE68oi8S4 AiaZSPy3faB6ov9pzB9b.RlCARYTkRl5zOp4ERXeNLYxmv5aBi3pw8jty04i VGd5XQvrhyJx2YDtPCUPFHoSBqN.fHWfHIm2G2H2n77a1lBcWgmuGH0k- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D814E8B.5000809@ieca.com> Date: Wed, 16 Mar 2011 19:58:03 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Herzog, Jonathan - 0668 - MITLL" References: <552BBAA9-712F-49B4-8A5F-C671C3817C05@ll.mit.edu> <47CF9528-81A1-49D7-8D4B-B1DCC136581E@ll.mit.edu> <3E69AF7B-D325-4FC5-A003-FEBA1997D67E@cisco.com> <4D77E3AE.5060903@cs.tcd.ie> <4D780411.9060108@cs.tcd.ie> <7896C06F-C680-4794-9DB3-CDC84CA5579D@ll.mit.edu> In-Reply-To: <7896C06F-C680-4794-9DB3-CDC84CA5579D@ll.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "iesg@ietf.org" , "secdir@ietf.org" , "draft-herzog-static-ecdh@tools.ietf.org" Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 23:56:41 -0000 On 3/10/11 4:02 PM, Herzog, Jonathan - 0668 - MITLL wrote: > > On Mar 9, 2011, at 5:49 PM, Stephen Farrell wrote: ..snip > Sean Turner has graciously agreed to step in and handle the IPR issues of this draft, so I'll let him address this. I submitted a 3rd party IPR statement at 6pm. I should have done it but forgot. It's the same ol' Certicom IPR. I submitted the same 3rd party earlier on another draft that mentioned EC algs. spt From stephen.farrell@cs.tcd.ie Wed Mar 16 17:34:53 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD9293A6906; Wed, 16 Mar 2011 17:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eZmCWEZO11M; Wed, 16 Mar 2011 17:34:52 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id B77AA3A67EE; Wed, 16 Mar 2011 17:34:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 5598D3E4083; Thu, 17 Mar 2011 00:36:17 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1300322177; bh=LBmrtCQNSsRjeg z+Nl43mRt+gqUPAsVW7Fkm2Os5rNs=; b=xJZOzGaF7PLTcINWXRbAABdNqz4EZZ 1JS6pnGg6n2GqHY7FntTro4aevYX89Cz2sjZ592r4J3/yfU6zYFZ2ZSO+5mIgh6k +L/TKN2QmzygVvN/oDDefPuGkFuuRsA7xi2stzGkDmr5aY4j05kZ5M3X0xCVOBSc XHA3PIvkBuGJ98YP6Gn+d7fXdlL3l0TenOeIcjfFCv7TYjodnTfhEFkxQSTz3HVD bg7NghPr0wnPDOTrzRxcyBn03PazXUqr4Ql8M8lhyknbrTsbhcFs1twg62H3u1oo B9vYpTR2avH1yMvH4/mVsmIPKOL/DAYAOec3li0qrox0HJzeso6br3FA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id GCBrCr3hmyLa; Thu, 17 Mar 2011 00:36:17 +0000 (GMT) Received: from [10.87.48.6] (unknown [86.41.7.122]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 1189C3E4082; Thu, 17 Mar 2011 00:36:15 +0000 (GMT) Message-ID: <4D815774.6050301@cs.tcd.ie> Date: Thu, 17 Mar 2011 00:36:04 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Sean Turner References: <552BBAA9-712F-49B4-8A5F-C671C3817C05@ll.mit.edu> <47CF9528-81A1-49D7-8D4B-B1DCC136581E@ll.mit.edu> <3E69AF7B-D325-4FC5-A003-FEBA1997D67E@cisco.com> <4D77E3AE.5060903@cs.tcd.ie> <4D780411.9060108@cs.tcd.ie> <7896C06F-C680-4794-9DB3-CDC84CA5579D@ll.mit.edu> <4D814E8B.5000809@ieca.com> In-Reply-To: <4D814E8B.5000809@ieca.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "draft-herzog-static-ecdh@tools.ietf.org" , "secdir@ietf.org" , "iesg@ietf.org" , "Herzog, Jonathan - 0668 - MITLL" Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 00:34:53 -0000 I had a quick look at the -06 version. It still doesn't call out what I think is the real functional difference between static-static (s-s) and ephemeral-static (e-s) which is that with centrally generated private values s-s allows an outbound application layer gateway to decrypt and filter traffic before it leaves the "key generating" domain. With e-s and signing keys, which are the alternative, that is not possible. Some people would like exactly that as a feature. Others would consider it anathema. I think this ought be explicitly called out in the text so that someone who cares doesn't pick the scheme the don't like by accident. S. On 16/03/11 23:58, Sean Turner wrote: > On 3/10/11 4:02 PM, Herzog, Jonathan - 0668 - MITLL wrote: >> >> On Mar 9, 2011, at 5:49 PM, Stephen Farrell wrote: > > ..snip > >> Sean Turner has graciously agreed to step in and handle the IPR issues >> of this draft, so I'll let him address this. > > I submitted a 3rd party IPR statement at 6pm. I should have done it but > forgot. It's the same ol' Certicom IPR. I submitted the same 3rd party > earlier on another draft that mentioned EC algs. > > spt > From stephen.farrell@cs.tcd.ie Wed Mar 16 19:36:20 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D0403A6A0D; Wed, 16 Mar 2011 19:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKYGk58UyZG0; Wed, 16 Mar 2011 19:36:19 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id B45103A69F0; Wed, 16 Mar 2011 19:36:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 3FEFF3E4085; Thu, 17 Mar 2011 02:37:43 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1300329463; bh=nhqpg6XIODfi7K 2MedAMjZ7hSyFhFLFUbkmwhHlq+uo=; b=3+NJdUnUR7+UBRSY/fLmccaWwoTSnu Pd3UKypI/b9RE8u3BCKuOfAHgUTax3iteDHq7hP0VKznSwdaxgDpO8k56+LrL4Po rl2GO8dG1Rcvz/DEjUgjkDPWjHXjWrlTGB5HXTVb9CdEq6MjXq9vRX6WBU0gIegF PmCXhiLl5TxcfZaNDzdeTB/clvEgFzcw1WETU9EvYTPUfqRPgg/X/ldkLxjQZy2K p/j3ALd6IoyA9Lj7y0f/fbYGMrZZX2LQEEJvqwE5yvgDmXzuStJZvgAGVZfjmO7h Itpx3XU6Wuv7mUk+ELbCC0M5cJmSX6CtgtMsPW6EtNzOX9cUxNQPzPmw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Nx2hwllNglg2; Thu, 17 Mar 2011 02:37:43 +0000 (GMT) Received: from [10.87.48.6] (unknown [86.41.7.122]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id D13E63E4084; Thu, 17 Mar 2011 02:37:41 +0000 (GMT) Message-ID: <4D8173F5.4000704@cs.tcd.ie> Date: Thu, 17 Mar 2011 02:37:41 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: "Herzog, Jonathan - 0668 - MITLL" References: <552BBAA9-712F-49B4-8A5F-C671C3817C05@ll.mit.edu> <47CF9528-81A1-49D7-8D4B-B1DCC136581E@ll.mit.edu> <3E69AF7B-D325-4FC5-A003-FEBA1997D67E@cisco.com> <4D77E3AE.5060903@cs.tcd.ie> <4D780411.9060108@cs.tcd.ie> <7896C06F-C680-4794-9DB3-CDC84CA5579D@ll.mit.edu> <4D814E8B.5000809@ieca.com> <4D815774.6050301@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "draft-herzog-static-ecdh@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 02:36:20 -0000 On 17/03/11 01:23, Herzog, Jonathan - 0668 - MITLL wrote: > > I apologize-- when you mentioned this before, I thought you were merely curious about our motivations. I didn't realize that you were suggesting/requesting additional discussion of the topic in the Draft. But your point about this feature of static-static ECDH is well-taken. If you think that it would serve the reader for the document to discuss this, then it should clearly be discussed. I'm not exactly sure what the protocol is for making changes this close to the scheduled discussion, but we would be happy to add a paragraph to the Security Considerations along the lines of: > > > "When two parties are communicating using static-static ECDH as described in this document, and either party's asymmetric keys have been centrally generated, it is possible for that party's central infrastructure to decrypt the communication (for application-layer network monitoring or filtering, for example). By way of contrast: were ephemeral-static ECDH to be used instead, such decryption would not be possible by the sender's infrastructure (though it would remain possible for the infrastructure of any recipient.)" > > > Thoughts? Looks fine to me. With an addition like that I'd have no problem with this. Formally, I guess just wait and see what the IESG say about the doc and then update as appropriate. Adding a paragraph like the above shouldn't be an issue in any event I'd say. Thanks, S. > > On Mar 16, 2011, at 8:36 PM, Stephen Farrell wrote: > >> >> I had a quick look at the -06 version. >> >> It still doesn't call out what I think is the real functional >> difference between static-static (s-s) and ephemeral-static (e-s) >> which is that with centrally generated private values s-s allows >> an outbound application layer gateway to decrypt and filter >> traffic before it leaves the "key generating" domain. With e-s >> and signing keys, which are the alternative, that is not possible. >> >> Some people would like exactly that as a feature. Others would >> consider it anathema. I think this ought be explicitly called out >> in the text so that someone who cares doesn't pick the scheme >> the don't like by accident. >> >> S. >> >> On 16/03/11 23:58, Sean Turner wrote: >>> On 3/10/11 4:02 PM, Herzog, Jonathan - 0668 - MITLL wrote: >>>> >>>> On Mar 9, 2011, at 5:49 PM, Stephen Farrell wrote: >>> >>> ..snip >>> >>>> Sean Turner has graciously agreed to step in and handle the IPR issues >>>> of this draft, so I'll let him address this. >>> >>> I submitted a 3rd party IPR statement at 6pm. I should have done it but >>> forgot. It's the same ol' Certicom IPR. I submitted the same 3rd party >>> earlier on another draft that mentioned EC algs. >>> >>> spt >>> > > From turners@ieca.com Fri Mar 18 11:55:21 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C76773A6A08 for ; Fri, 18 Mar 2011 11:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjiTjUQAXiKv for ; Fri, 18 Mar 2011 11:55:21 -0700 (PDT) Received: from nm28.bullet.mail.ac4.yahoo.com (nm28.bullet.mail.ac4.yahoo.com [98.139.52.225]) by core3.amsl.com (Postfix) with SMTP id 03F9F3A6999 for ; Fri, 18 Mar 2011 11:55:20 -0700 (PDT) Received: from [98.139.52.192] by nm28.bullet.mail.ac4.yahoo.com with NNFMP; 18 Mar 2011 18:56:47 -0000 Received: from [98.139.52.173] by tm5.bullet.mail.ac4.yahoo.com with NNFMP; 18 Mar 2011 18:56:47 -0000 Received: from [127.0.0.1] by omp1056.mail.ac4.yahoo.com with NNFMP; 18 Mar 2011 18:56:47 -0000 X-Yahoo-Newman-Id: 283351.46397.bm@omp1056.mail.ac4.yahoo.com Received: (qmail 61857 invoked from network); 18 Mar 2011 18:56:42 -0000 Received: from thunderfish.local (turners@96.231.126.170 with plain) by smtp113.biz.mail.mud.yahoo.com with SMTP; 18 Mar 2011 11:56:41 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 7HTauIkVM1k3p.oOXgduD6TfBXGn.14pJd3zuZGSQaxPnlZ x_WFgHEH9pcNhtXC42Jvbh3Ybflm8HLin6IGM7Zi4LeVw8eS76TeurS_GazW wxq9ICnijpjJPn7hp2QsxoIeT5ny448rTdAbVsZVgBzIa2Vz2LJqg6D2AABP iLH5sPwhrEBomTLtuJLXbLMvKsHp09rvBWLnxqbgbY_CO8U8rnlyiX1mQBXz NSaiaTyJa4LjmXIw_ecELKW2ro6xjfbictryDSJ1K2xcrmu3yCsMQY1wT7sf mlL0BdK1FWfoJDBNmADN.g11lptZz0rjJ X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D83AAE8.3030007@ieca.com> Date: Fri, 18 Mar 2011 14:56:40 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] Tuesday Lunch Room X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 18:55:21 -0000 We've been assigned Tyrolka on Tuesday, March 29th (11:30-13:00) for our Security Directorate meeting. See you all there, spt From fred@cisco.com Fri Mar 18 13:40:04 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 232CA3A69B3 for ; Fri, 18 Mar 2011 13:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.527 X-Spam-Level: X-Spam-Status: No, score=-110.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2l9Xi3tDeyhp for ; Fri, 18 Mar 2011 13:40:03 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 027913A69A7 for ; Fri, 18 Mar 2011 13:40:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=615; q=dns/txt; s=iport; t=1300480893; x=1301690493; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=gGLag0MYnbHL7HOgf5CMEtdh2o1Wsw0Uq6bouG+pzmE=; b=MzYjC4uwpmv0YB+ywZ+YCzHKx3dMnNS4Uwuz+QawfUzQzo8nMvjmqB+S 5nskiMNtQSvthLcxv1dtNb4xlapgrU6nJEXW7CODfZy7Fiue1B+dNnDCg ZQQuuvSrcDpMKb3HFI5sZhdyUs7NNgWZ/Fr711WesOTG/z/5RlweLgH76 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHZgg02tJXG9/2dsb2JhbAClcneITZ5jnBmFYwSFMYcyg08 X-IronPort-AV: E=Sophos;i="4.63,207,1299456000"; d="scan'208";a="321964977" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-2.cisco.com with ESMTP; 18 Mar 2011 20:41:32 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2IKfRKI029106; Fri, 18 Mar 2011 20:41:31 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Fri, 18 Mar 2011 13:41:32 -0700 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Fri, 18 Mar 2011 13:41:32 -0700 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <20110303143242.8095.667.idtracker@localhost> Date: Fri, 18 Mar 2011 13:41:18 -0700 Message-Id: <3BCB1BE7-AD59-4043-AB71-E6D08928EFB3@cisco.com> References: <20110303143242.8095.667.idtracker@localhost> To: Tim Polk X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: David Meyer , pkix-chairs@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Tim Polk's Discuss on draft-baker-ietf-core-12: (with DISCUSS and COMMENT) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 20:40:04 -0000 On Mar 3, 2011, at 6:32 AM, Tim Polk wrote: > Actionable 1: Please add a brief section 3.1.5 Key Management = Infrastructures to cover PKI (PKIX) and Kerberos. > These are a very important building block in the security toolbox. I = would suggest mentioning the DANE work in this > section as well. >=20 > Actionable 2: Please add a brief section 3.1.6 secure shell. This is = another and widely used key building block. Repeat question. My recent update doesn't address these four questions (pkix, kerberos, = ssh, and whatever DANE is). Whom would you consider the best source for = text?= From scott@hyperthought.com Fri Mar 18 16:22:12 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACAC23A6A96 for ; Fri, 18 Mar 2011 16:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jY1MqV3PPNU6 for ; Fri, 18 Mar 2011 16:22:09 -0700 (PDT) Received: from smtp152.iad.emailsrvr.com (smtp152.iad.emailsrvr.com [207.97.245.152]) by core3.amsl.com (Postfix) with ESMTP id 8C7443A6A9F for ; Fri, 18 Mar 2011 16:22:05 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp55.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 2A1BD2E0315; Fri, 18 Mar 2011 19:23:35 -0400 (EDT) X-Virus-Scanned: OK Received: from dynamic14.wm-web.iad.mlsrvr.com (dynamic14.wm-web.iad1a.rsapps.net [192.168.2.221]) by smtp55.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id CB6F82E031E; Fri, 18 Mar 2011 19:23:34 -0400 (EDT) Received: from hyperthought.com (localhost [127.0.0.1]) by dynamic14.wm-web.iad.mlsrvr.com (Postfix) with ESMTP id 89F2D2E9802E; Fri, 18 Mar 2011 19:23:34 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Fri, 18 Mar 2011 16:23:34 -0700 (PDT) Date: Fri, 18 Mar 2011 16:23:34 -0700 (PDT) From: "Scott G. Kelly" To: draft-ietf-sipping-nat-scenarios.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain Message-ID: <1300490614.563813951@192.168.4.58> X-Mailer: webmail8 Subject: [secdir] secdir review of draft-ietf-sipping-nat-scenarios-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 23:22: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.=0A=0AThis draft is a summary of best practices/= recommendations for SIP session NAT traversal. It is well-written, although= to say it is easy to understand (especially for someone not steeped in SIP= NAT traversal lore) would be to significantly understate the ground it cov= ers.=0A=0AThe security considerations is among the most concise I've ever s= een, simply stating "There are no Security Considerations beyond the ones i= nherited by reference." My security geek hackles went up a little when I re= ad that, but after looking at some of the referenced RFCs and thinking abou= t it for a bit, I couldn't think of any attacks that aren't already covered= in the security considerations of those documents. So, I don't have any co= ncrete criticisms or concerns with this document.=0A=0A--Scott=0A From prvs=205554f640=jherzog@ll.mit.edu Tue Mar 15 14:06:40 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDBED3A6EDF; Tue, 15 Mar 2011 14:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.847 X-Spam-Level: X-Spam-Status: No, score=-5.847 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QT5PgFIZ19FB; Tue, 15 Mar 2011 14:06:40 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by core3.amsl.com (Postfix) with ESMTP id C67303A6EC5; Tue, 15 Mar 2011 14:06:39 -0700 (PDT) Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id p2FL81YI029488; Tue, 15 Mar 2011 17:08:01 -0400 From: "Herzog, Jonathan - 0668 - MITLL" To: David McGrew Date: Tue, 15 Mar 2011 17:07:59 -0400 Thread-Topic: [secdir] Secdir review of draft-herzog-static-ecdh-05 Thread-Index: AcvjVRFCCT07luIDT8uLmx35Y39lBQ== Message-ID: <9BD7FA82-120B-4433-9EB0-7249C06F6852@ll.mit.edu> References: <552BBAA9-712F-49B4-8A5F-C671C3817C05@ll.mit.edu> <47CF9528-81A1-49D7-8D4B-B1DCC136581E@ll.mit.edu> <3E69AF7B-D325-4FC5-A003-FEBA1997D67E@cisco.com> <65D56695-894D-458E-A9C4-6DCF6A38F196@cisco.com> <29C1F1D5-6EF0-4055-BA88-03F03E3F0A84@ll.mit.edu> <63667400-81DF-438E-869F-247222DECA18@ll.mit.edu> In-Reply-To: <63667400-81DF-438E-869F-247222DECA18@ll.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-56--206467168"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-15_03:2011-03-14, 2011-03-15, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=8 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1012030000 definitions=main-1103150154 X-Mailman-Approved-At: Mon, 21 Mar 2011 08:27:18 -0700 Cc: "secdir@ietf.org" , "draft-herzog-static-ecdh@tools.ietf.org" , "iesg@ietf.org IESG" Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 21:06:41 -0000 --Apple-Mail-56--206467168 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 10, 2011, at 3:41 PM, Herzog, Jonathan - 0668 - MITLL wrote: >=20 > From: "Herzog, Jonathan - 0668 - MITLL" > Date: March 10, 2011 3:41:52 PM EST > To: David McGrew > Cc: Brian Weis , = "draft-herzog-static-ecdh@tools.ietf.org" = , "iesg@ietf.org" = , "secdir@ietf.org" > Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05 >=20 >=20 >=20 > On Mar 10, 2011, at 1:12 PM, David McGrew wrote: >>=20 >>=20 >>>=20 >>> However, SP800-56A does define cofactor ECDH. So let me propose the =20= >>> following citation scheme: >>>=20 >>> * ECDH in general: RFC 6090 >>> * Standard ECDH: RFC 6090 >>> * Co-factor Diffie-Hellman: SP 800-56A, Section 5.7.1.2 >>> * Full public-key validation: SP800-56A, Section 5.6.2.5 >>> * Partial public-key validation: SP800-56A: Section 5.6.2.6 >>> * Key-derivation function... still working on it. >>>=20 >>> Thoughts? >>=20 >> That looks good to me. Let me know if I can help with the KDF. >=20 >=20 > I'd appreciate it, thanks. One of the goals of this draft is to remain = as compatible with RFC 5753 as possible, so as to impact implementations = as little as possible. RFC 5753, for its part, specifies the KDF in = SEC1. And the KDF in SEC1 is just the 'simple hash function construct = described in ANSI X9.63'. So, do you think I can cite X9.63 as the = normative reference? And if so, what are your thoughts on citing SEC1 as = an informative reference for this KDF? SEC1 is, after all, freely = available on the web. >=20 > (Note: I'm still chasing down the ANSI spec to ensure that it does, in = fact, match the description in SEC1.) Just to follow up on this: I got the X9.63 spec and checked its KDF. = It's the same as the one in SEC1. Some very very minor differences in = the description, but it's the same KDF. Thanks. --=20 Jonathan Herzog voice: = (781) 981-2356 Technical Staff fax: = (781) 981-7687 Cyber Systems and Technology Group email: = jherzog@ll.mit.edu MIT Lincoln Laboratory www: = http://www.ll.mit.edu/CST/ 244 Wood Street =20 Lexington, MA 02420-9185 --Apple-Mail-56--206467168 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJrzCCBNIw ggO6oAMCAQICChVM3JYAAAAAIh8wDQYJKoZIhvcNAQEFBQAwUTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwg Q0EtMTAeFw0xMDA1MjUyMDQ1MzhaFw0xMTA1MjUyMDQ1MzhaMGQxCzAJBgNVBAYTAlVTMR8wHQYD VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQZW9wbGUxIzAhBgNVBAMTGkhl cnpvZy5Kb25hdGhhbi5DLjUwMDExMzA1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 93mr5a6zq6EQsVtIX9BadxwzpjabF8pvDmoMSP/ZhbWrncNJ1j7xiBGcihYqsDaQz9+hJITxi7IM NUx5fnFtOQRHZgkOCLR1URFc0AlJ3Pknv6XoQ4fqPODmSMB882c9l/8AbO7N/27r8n/V0Ip4Rpw8 1qnrDXk6UH/1zHlssGmlVng0RSREuQy98xPxzbLr5cOMWLwHs5OLNYcGv0KlD6rp1DPzJ3qplU/+ 0P2jyYbGyXStJ/h+3Kx5mOWFLB4j8HDyLG90ZHlZjZXo9FrSoFubVJK/mdVzIuXd00Ldl1fCyxhR D9elkpTc7xOLJsEzCCi8Gqo6eQuvz1RH93u3PwIDAQABo4IBlzCCAZMwDgYDVR0PAQH/BAQDAgbA MB0GA1UdDgQWBBRPjG6+CxR6H/o9vyq5PgmW9vmuajAfBgNVHSMEGDAWgBSUWsZYybYmm6AJe6gv ZJDDiQJuKjAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xM Q0ExMGIGCCsGAQUFBwEBBFYwVDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dHRvL0xMQ0ExMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5sbC5taXQuZWR1LzAMBgNVHRMBAf8E AjAAMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH /4pzAgFkAgEFMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8w DQYLKoZIhvcSAgEDAQgwHQYDVR0RBBYwFIESamhlcnpvZ0BsbC5taXQuZWR1MA0GCSqGSIb3DQEB BQUAA4IBAQBI6aoe1c6Glzs3Hh/lIzf2TzmtZSQLl8UZaIFGi0zG0EjsO6wjX6bfv/WizE30OEef 6So76p0dNt7j21lrH+FGaH6r41ggikbkoazNkAePsQk0WPZhmpus1rByNUozK4KMPpzLAynHNd5m POtqoIwDiTEgktLuZ1nwU7bUHmv7BO14dkhLhMOFKRCIi3vqe9rDh9pTYt1YNhQe1fBme6Y5DWLA TxBBqErz05e7rVngKi6yk6j7cqWpiM6L93z2Zq5p9FqACsJHmMwxH/8XFeeXgFf/CKMAIuSZCGFU 29ouEZWL7LLu87SFGm3f/3sLS7xgXei7d/PlXte1HKKdKOCPMIIE1TCCA72gAwIBAgIKFU5e0QAA AAAiIDANBgkqhkiG9w0BAQUFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4g TGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xMB4XDTEwMDUyNTIw NDcxN1oXDTExMDUyNTIwNDcxN1owZDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xu IExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEjMCEGA1UEAxMaSGVyem9nLkpvbmF0aGFuLkMu NTAwMTEzMDUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtC8sNdkCteQagOVEnQQs4 5uLqsmaOfjqTywNWuvaVj0F8Jsek8bOcuK4rlB1PrBk0Q+s/N4FVcGEn6BEDWRIDFaETVr1jweTE yRUtqngTIvpbpeixV37BcFkVnbV2VrZC5oaa0c0bkxXkuE0lohQS5AIBXQRADEJVnfXIM44yvsmo T7J5rdGwjIg4QJ2YA07po0JkbndcylcjU0zW2Lv432MEZrX/o+T0rraFAhT8A+8De9CIo0LJkXCK cNwk6LwuNKQS0qeezDo5wRiqZaht3ftiAuOImOxN44hxnDa2cHVbOFQ+pevN08gH7d39CVHUbHMC PnuIBoQNu61I2+ItAgMBAAGjggGaMIIBljAOBgNVHQ8BAf8EBAMCBSAwHQYDVR0OBBYEFEuYUJcI JTs8b2SWTJN28DD/qqsNMB8GA1UdIwQYMBaAFJRaxljJtiaboAl7qC9kkMOJAm4qMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTEwYgYIKwYBBQUHAQEE VjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTEwIwYIKwYB BQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUH BDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0l BB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMB CDAdBgNVHREEFjAUgRJqaGVyem9nQGxsLm1pdC5lZHUwDQYJKoZIhvcNAQEFBQADggEBAAmf5m3W 0Di4aQhLS1e2xejG3MQPQJvWL3dHbnHYG+NDVFWcuqyE5t73eb7nV2UyGRVHDt6MyIquedAPPm86 FSPZ6CUGGj5imp9pAu7C+xESBMY4z0k5htK/h5vlSB9X/i3JbXI8KBOioH1QYenMfrvTISmk/+5A BHsMDOpK7//bX66DP+iopoIiWJktY+dfiak7uTZhuYEOmICq4QlP9dDqdPiQGje4Y8xZ45YL6+2I m5GIzuIac/r51YTBuCk+TxTZIITMx+Fr50Ur6s4dOnvApxMR7iZX6oKnmVfXrjFMMQxR1TN5ISUn IoMyID3yCiInqQh6G3WPCAhwa/qG/moxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYD VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExM IENBLTECChVM3JYAAAAAIh8wCQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTEwMzE1MjEwNzYwWjAjBgkqhkiG9w0BCQQxFgQUHHhDhJ++MzDx 3LOcCnwv/j6GE2kwbgYJKwYBBAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xAgoV Tl7RAAAAACIgMHAGCyqGSIb3DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xAgoV Tl7RAAAAACIgMA0GCSqGSIb3DQEBAQUABIIBABtcxKYiEufgdDFZHcf78g5SUIj+MKwgajeHHRJ3 YrK5h1VklQYkg6rn11nV27+3DLd7/Y8WsNfxzVbVMLKQaGXFtHvEqaDDTgpTI4cXNCKvboYkUd7X 5aUwVc/EOQK28moJ/TKZfjSTEGHJnfv+nTTGPR0R/0hgGNt22gjgiDKNN4gh2uS53qgVpblaqT7c uOGX2RbNmOtTB9j0UxRJWXFYL2Q4hWzbIkRKe/Q+CeNwR2A9nbb6Yi0KWkL4kRaLp6z2NeyU34Sm 128yqcYpELxbwMhJQNjkbAkVVZAg1PMbI8OFx5dDxNqqpqM7z6SoMv5X7xHADq6jta8+tDyJj9oA AAAAAAA= --Apple-Mail-56--206467168-- From prvs=2057df9d48=jherzog@ll.mit.edu Wed Mar 16 18:22:25 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9AB03A69D8; Wed, 16 Mar 2011 18:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.847 X-Spam-Level: X-Spam-Status: No, score=-5.847 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7mjaZAgKdRC; Wed, 16 Mar 2011 18:22:24 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by core3.amsl.com (Postfix) with ESMTP id A9C073A67EE; Wed, 16 Mar 2011 18:22:23 -0700 (PDT) Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id p2H1NlXf007339; Wed, 16 Mar 2011 21:23:47 -0400 From: "Herzog, Jonathan - 0668 - MITLL" To: Stephen Farrell Date: Wed, 16 Mar 2011 21:23:47 -0400 Thread-Topic: [secdir] Secdir review of draft-herzog-static-ecdh-05 Thread-Index: AcvkQfavi+/BdygjQYWi3zsqrD4YyQ== Message-ID: References: <552BBAA9-712F-49B4-8A5F-C671C3817C05@ll.mit.edu> <47CF9528-81A1-49D7-8D4B-B1DCC136581E@ll.mit.edu> <3E69AF7B-D325-4FC5-A003-FEBA1997D67E@cisco.com> <4D77E3AE.5060903@cs.tcd.ie> <4D780411.9060108@cs.tcd.ie> <7896C06F-C680-4794-9DB3-CDC84CA5579D@ll.mit.edu> <4D814E8B.5000809@ieca.com> <4D815774.6050301@cs.tcd.ie> In-Reply-To: <4D815774.6050301@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-125--104719926"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-17_01:2011-03-16, 2011-03-17, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=8 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1012030000 definitions=main-1103160174 X-Mailman-Approved-At: Mon, 21 Mar 2011 08:27:18 -0700 Cc: "draft-herzog-static-ecdh@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 01:22:26 -0000 --Apple-Mail-125--104719926 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I apologize-- when you mentioned this before, I thought you were merely = curious about our motivations. I didn't realize that you were = suggesting/requesting additional discussion of the topic in the Draft. = But your point about this feature of static-static ECDH is well-taken. = If you think that it would serve the reader for the document to discuss = this, then it should clearly be discussed. I'm not exactly sure what the = protocol is for making changes this close to the scheduled discussion, = but we would be happy to add a paragraph to the Security Considerations = along the lines of: "When two parties are communicating using static-static ECDH as = described in this document, and either party's asymmetric keys have been = centrally generated, it is possible for that party's central = infrastructure to decrypt the communication (for application-layer = network monitoring or filtering, for example). By way of contrast: were = ephemeral-static ECDH to be used instead, such decryption would not be = possible by the sender's infrastructure (though it would remain possible = for the infrastructure of any recipient.)" Thoughts? On Mar 16, 2011, at 8:36 PM, Stephen Farrell wrote: >=20 > I had a quick look at the -06 version. >=20 > It still doesn't call out what I think is the real functional > difference between static-static (s-s) and ephemeral-static (e-s) > which is that with centrally generated private values s-s allows > an outbound application layer gateway to decrypt and filter > traffic before it leaves the "key generating" domain. With e-s > and signing keys, which are the alternative, that is not possible. >=20 > Some people would like exactly that as a feature. Others would > consider it anathema. I think this ought be explicitly called out > in the text so that someone who cares doesn't pick the scheme > the don't like by accident. >=20 > S. >=20 > On 16/03/11 23:58, Sean Turner wrote: >> On 3/10/11 4:02 PM, Herzog, Jonathan - 0668 - MITLL wrote: >>>=20 >>> On Mar 9, 2011, at 5:49 PM, Stephen Farrell wrote: >>=20 >> ..snip >>=20 >>> Sean Turner has graciously agreed to step in and handle the IPR = issues >>> of this draft, so I'll let him address this. >>=20 >> I submitted a 3rd party IPR statement at 6pm. I should have done it = but >> forgot. It's the same ol' Certicom IPR. I submitted the same 3rd = party >> earlier on another draft that mentioned EC algs. >>=20 >> spt >>=20 --=20 Jonathan Herzog voice: = (781) 981-2356 Technical Staff fax: = (781) 981-7687 Cyber Systems and Technology Group email: = jherzog@ll.mit.edu MIT Lincoln Laboratory www: = http://www.ll.mit.edu/CST/ 244 Wood Street =20 Lexington, MA 02420-9185 --Apple-Mail-125--104719926 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJrzCCBNIw ggO6oAMCAQICChVM3JYAAAAAIh8wDQYJKoZIhvcNAQEFBQAwUTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwg Q0EtMTAeFw0xMDA1MjUyMDQ1MzhaFw0xMTA1MjUyMDQ1MzhaMGQxCzAJBgNVBAYTAlVTMR8wHQYD VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQZW9wbGUxIzAhBgNVBAMTGkhl cnpvZy5Kb25hdGhhbi5DLjUwMDExMzA1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 93mr5a6zq6EQsVtIX9BadxwzpjabF8pvDmoMSP/ZhbWrncNJ1j7xiBGcihYqsDaQz9+hJITxi7IM NUx5fnFtOQRHZgkOCLR1URFc0AlJ3Pknv6XoQ4fqPODmSMB882c9l/8AbO7N/27r8n/V0Ip4Rpw8 1qnrDXk6UH/1zHlssGmlVng0RSREuQy98xPxzbLr5cOMWLwHs5OLNYcGv0KlD6rp1DPzJ3qplU/+ 0P2jyYbGyXStJ/h+3Kx5mOWFLB4j8HDyLG90ZHlZjZXo9FrSoFubVJK/mdVzIuXd00Ldl1fCyxhR D9elkpTc7xOLJsEzCCi8Gqo6eQuvz1RH93u3PwIDAQABo4IBlzCCAZMwDgYDVR0PAQH/BAQDAgbA MB0GA1UdDgQWBBRPjG6+CxR6H/o9vyq5PgmW9vmuajAfBgNVHSMEGDAWgBSUWsZYybYmm6AJe6gv ZJDDiQJuKjAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xM Q0ExMGIGCCsGAQUFBwEBBFYwVDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dHRvL0xMQ0ExMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5sbC5taXQuZWR1LzAMBgNVHRMBAf8E AjAAMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH /4pzAgFkAgEFMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8w DQYLKoZIhvcSAgEDAQgwHQYDVR0RBBYwFIESamhlcnpvZ0BsbC5taXQuZWR1MA0GCSqGSIb3DQEB BQUAA4IBAQBI6aoe1c6Glzs3Hh/lIzf2TzmtZSQLl8UZaIFGi0zG0EjsO6wjX6bfv/WizE30OEef 6So76p0dNt7j21lrH+FGaH6r41ggikbkoazNkAePsQk0WPZhmpus1rByNUozK4KMPpzLAynHNd5m POtqoIwDiTEgktLuZ1nwU7bUHmv7BO14dkhLhMOFKRCIi3vqe9rDh9pTYt1YNhQe1fBme6Y5DWLA TxBBqErz05e7rVngKi6yk6j7cqWpiM6L93z2Zq5p9FqACsJHmMwxH/8XFeeXgFf/CKMAIuSZCGFU 29ouEZWL7LLu87SFGm3f/3sLS7xgXei7d/PlXte1HKKdKOCPMIIE1TCCA72gAwIBAgIKFU5e0QAA AAAiIDANBgkqhkiG9w0BAQUFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4g TGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xMB4XDTEwMDUyNTIw NDcxN1oXDTExMDUyNTIwNDcxN1owZDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xu IExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEjMCEGA1UEAxMaSGVyem9nLkpvbmF0aGFuLkMu NTAwMTEzMDUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtC8sNdkCteQagOVEnQQs4 5uLqsmaOfjqTywNWuvaVj0F8Jsek8bOcuK4rlB1PrBk0Q+s/N4FVcGEn6BEDWRIDFaETVr1jweTE yRUtqngTIvpbpeixV37BcFkVnbV2VrZC5oaa0c0bkxXkuE0lohQS5AIBXQRADEJVnfXIM44yvsmo T7J5rdGwjIg4QJ2YA07po0JkbndcylcjU0zW2Lv432MEZrX/o+T0rraFAhT8A+8De9CIo0LJkXCK cNwk6LwuNKQS0qeezDo5wRiqZaht3ftiAuOImOxN44hxnDa2cHVbOFQ+pevN08gH7d39CVHUbHMC PnuIBoQNu61I2+ItAgMBAAGjggGaMIIBljAOBgNVHQ8BAf8EBAMCBSAwHQYDVR0OBBYEFEuYUJcI JTs8b2SWTJN28DD/qqsNMB8GA1UdIwQYMBaAFJRaxljJtiaboAl7qC9kkMOJAm4qMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTEwYgYIKwYBBQUHAQEE VjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTEwIwYIKwYB BQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUH BDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0l BB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMB CDAdBgNVHREEFjAUgRJqaGVyem9nQGxsLm1pdC5lZHUwDQYJKoZIhvcNAQEFBQADggEBAAmf5m3W 0Di4aQhLS1e2xejG3MQPQJvWL3dHbnHYG+NDVFWcuqyE5t73eb7nV2UyGRVHDt6MyIquedAPPm86 FSPZ6CUGGj5imp9pAu7C+xESBMY4z0k5htK/h5vlSB9X/i3JbXI8KBOioH1QYenMfrvTISmk/+5A BHsMDOpK7//bX66DP+iopoIiWJktY+dfiak7uTZhuYEOmICq4QlP9dDqdPiQGje4Y8xZ45YL6+2I m5GIzuIac/r51YTBuCk+TxTZIITMx+Fr50Ur6s4dOnvApxMR7iZX6oKnmVfXrjFMMQxR1TN5ISUn IoMyID3yCiInqQh6G3WPCAhwa/qG/moxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYD VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExM IENBLTECChVM3JYAAAAAIh8wCQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTEwMzE3MDEyMzQ3WjAjBgkqhkiG9w0BCQQxFgQUvev4CrSebXqj FI5u5W7qMF6vWEwwbgYJKwYBBAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xAgoV Tl7RAAAAACIgMHAGCyqGSIb3DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xAgoV Tl7RAAAAACIgMA0GCSqGSIb3DQEBAQUABIIBAC/LnlMoKCn0DI+3MJq3uCXMpCGv+opZOgH0F1KE 48YvofwCjaZae1jZc8o4irSsYgYK4gZfuHcvffUKrbWKZO6rsUsSg3InpCr9rrNV4JUCTi2Z8iL9 rSAe8r2MezMCVOv3A5N697vHdK9yV47XCoIyVniYlmFBIldqeJXbUglz0AJiL6jxg5fqBh7OZb/e 9wYhSOzB2BLcQUF/TsA7lPeKus8AlXTMF4MGgyWTzmoAIcyP2/wdU6q/1e4mboJmdaV3OpHPqAHF JS5C5VEjcQjTjYitXLDi+smCGJKUTnlxbyH//sDicd/gczAd/LMukn6CB8PoDmvXjIherUr+7N8A AAAAAAA= --Apple-Mail-125--104719926-- From uri@mit.edu Mon Mar 21 08:32:03 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 538EE28C158 for ; Mon, 21 Mar 2011 08:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_OBFU_ALL=0.751] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEv-TV94mMU8 for ; Mon, 21 Mar 2011 08:32:01 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU [18.7.68.37]) by core3.amsl.com (Postfix) with ESMTP id 97ED928C0E7 for ; Mon, 21 Mar 2011 08:32:01 -0700 (PDT) X-AuditID: 12074425-b7be5ae000000a16-a3-4d876fcf51ad Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 78.BC.02582.FCF678D4; Mon, 21 Mar 2011 11:33:35 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id p2LFXWmV002851; Mon, 21 Mar 2011 11:33:32 -0400 Received: from Angmar.local (c-24-63-227-189.hsd1.ma.comcast.net [24.63.227.189]) (authenticated bits=0) (User authenticated as uri@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p2LFXS9w013709 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 21 Mar 2011 11:33:30 -0400 (EDT) Message-ID: <4D876FC8.9090601@mit.edu> Date: Mon, 21 Mar 2011 11:33:28 -0400 From: Uri Blumenthal Organization: MIT User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: secdir@ietf.org References: <552BBAA9-712F-49B4-8A5F-C671C3817C05@ll.mit.edu> <47CF9528-81A1-49D7-8D4B-B1DCC136581E@ll.mit.edu> <3E69AF7B-D325-4FC5-A003-FEBA1997D67E@cisco.com> <65D56695-894D-458E-A9C4-6DCF6A38F196@cisco.com> <29C1F1D5-6EF0-4055-BA88-03F03E3F0A84@ll.mit.edu> <63667400-81DF-438E-869F-247222DECA18@ll.mit.edu> <9BD7FA82-120B-4433-9EB0-7249C06F6852@ll.mit.edu> In-Reply-To: <9BD7FA82-120B-4433-9EB0-7249C06F6852@ll.mit.edu> X-Enigmail-Version: 1.1.1 Content-Type: multipart/alternative; boundary="------------090705020504090400040409" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIKsWRmVeSWpSXmKPExsUixG6nrns+v93XYO9rVYubbX9YLD4sfMji wOSxZMlPJo8vlz+zBTBFcdmkpOZklqUW6dslcGWsWTuLteCSaUXHxKXsDYw/tLsYOTkkBEwk LlzsY4awxSQu3FvP1sXIxSEksI9R4uyMxSwQzgZGiYX/nzJBOCeYJI7c3MUG0sIroCax/2A7 I4jNIqAq8XzfORYQm01ASaK5eQsriC0kICpxYW8zmM0vICjRsvAv2ApRgQZGiam909ghBglK nJz5BKxZREBY4vbBB2ANzALxErubv4MtEBZwkjh9bg0zxBVrWCSed9wAO5xTwE5i8o8p7BBP SEqcPn4E6FQOoOYwiU8r4yYwCs9CsmIWQmYW2AYdiXd9D5ghbHmJ7W/nQNnaEqt6zzIhiy9g ZFvFKJuSW6Wbm5iZU5yarFucnJiXl1qka6GXm1mil5pSuokRHDsuqjsYJxxSOsQowMGoxMN7 QLDNV4g1say4MvcQoyQHk5Io78rcdl8hvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIryNAUA53pTE yqrUonyYlDQHi5I473xJdV8hgfTEktTs1NSC1CKYrAwHh5IErxAwRQgJFqWmp1akZeaUIKSZ ODhBhvMADecHqeEtLkjMLc5Mh8ifYtTl+DJz815GIZa8/LxUKXFeeZAiAZCijNI8uDmwlPeK URzoLWFeAZAqHmC6hJv0CmgJE9CSvVtaQJaUJCKkpBoYrSTLxTtaOPeuPxYVNFlkxXfh3Q+a bNQmHFq4jOeOYwPH4vS/0YxBSiX+lfLf91g9a9/E+oBfR/zQtYNhu+cc0fu+0vH5pFXv7Ewu 1dnx+097ZucrZth4Iy6KafXRBAXfLuYbDx1vnY+MmXfJPshdhm0hi2ji6frSTc7Ltga98pPq mfiGk81NiaU4I9FQi7moOBEA4OT4I1QDAAA= Cc: draft-herzog-static-ecdh@tools.ietf.org, "Jonathan C. Herzog" Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: uri@MIT.EDU List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 15:32:03 -0000 This is a multi-part message in MIME format. --------------090705020504090400040409 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit In that case - since X9.63 and SEC1 turned out to be the same - would it make sense to reverse them in Normative/Informative status? My reasoning is - SEC1 is freely available, and X9.63 seems to be available only for a fee. Either way is OK with me. Thanks! On 3/15/11 17:07 PM, Herzog, Jonathan - 0668 - MITLL wrote: > On Mar 10, 2011, at 3:41 PM, Herzog, Jonathan - 0668 - MITLL wrote: >> From: "Herzog, Jonathan - 0668 - MITLL" >> Date: March 10, 2011 3:41:52 PM EST >> To: David McGrew >> Cc: Brian Weis , "draft-herzog-static-ecdh@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" >> Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05 >> >> >> >> On Mar 10, 2011, at 1:12 PM, David McGrew wrote: >>> >>>> However, SP800-56A does define cofactor ECDH. So let me propose the >>>> following citation scheme: >>>> >>>> * ECDH in general: RFC 6090 >>>> * Standard ECDH: RFC 6090 >>>> * Co-factor Diffie-Hellman: SP 800-56A, Section 5.7.1.2 >>>> * Full public-key validation: SP800-56A, Section 5.6.2.5 >>>> * Partial public-key validation: SP800-56A: Section 5.6.2.6 >>>> * Key-derivation function... still working on it. >>>> >>>> Thoughts? >>> That looks good to me. Let me know if I can help with the KDF. >> >> I'd appreciate it, thanks. One of the goals of this draft is to remain as compatible with RFC 5753 as possible, so as to impact implementations as little as possible. RFC 5753, for its part, specifies the KDF in SEC1. And the KDF in SEC1 is just the 'simple hash function construct described in ANSI X9.63'. So, do you think I can cite X9.63 as the normative reference? And if so, what are your thoughts on citing SEC1 as an informative reference for this KDF? SEC1 is, after all, freely available on the web. >> >> (Note: I'm still chasing down the ANSI spec to ensure that it does, in fact, match the description in SEC1.) > Just to follow up on this: I got the X9.63 spec and checked its KDF. It's the same as the one in SEC1. Some very very minor differences in the description, but it's the same KDF. > > Thanks. > > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir -- Regards, Uri --------------090705020504090400040409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit In that case - since X9.63 and SEC1 turned out to be the same - would it make sense to reverse them in Normative/Informative status? My reasoning is - SEC1 is freely available, and X9.63 seems to be available only for a fee.

Either way is OK with me.

Thanks!


On 3/15/11 17:07 PM, Herzog, Jonathan - 0668 - MITLL wrote: 
On Mar 10, 2011, at 3:41 PM, Herzog, Jonathan - 0668 - MITLL wrote:

From: "Herzog, Jonathan - 0668 - MITLL" <jherzog@ll.mit.edu>
Date: March 10, 2011 3:41:52 PM EST
To: David McGrew <mcgrew@cisco.com>
Cc: Brian Weis <bew@cisco.com>, "draft-herzog-static-ecdh@tools.ietf.org" <draft-herzog-static-ecdh@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05



On Mar 10, 2011, at 1:12 PM, David McGrew wrote:



However, SP800-56A does define cofactor ECDH. So let me propose the  
following citation scheme:

* ECDH in general: RFC 6090
* Standard ECDH: RFC 6090
* Co-factor Diffie-Hellman: SP 800-56A, Section 5.7.1.2
* Full public-key validation: SP800-56A, Section 5.6.2.5
* Partial public-key validation: SP800-56A: Section 5.6.2.6
* Key-derivation function... still working on it.

Thoughts?

That looks good to me.  Let me know if I can help with the KDF.


I'd appreciate it, thanks. One of the goals of this draft is to remain as compatible with RFC 5753 as possible, so as to impact implementations as little as possible. RFC 5753, for its part, specifies the KDF in SEC1. And the KDF in SEC1 is just the 'simple hash function construct described in ANSI X9.63'. So, do you think I can cite X9.63 as the normative reference? And if so, what are your thoughts on citing SEC1 as an informative reference for this KDF? SEC1 is, after all, freely available on the web.

(Note: I'm still chasing down the ANSI spec to ensure that it does, in fact, match the description in SEC1.)

Just to follow up on this: I got the X9.63 spec and checked its KDF. It's the same as the one in SEC1. Some very very minor differences in the description, but it's the same KDF.

Thanks.



_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir



-- 
Regards,
Uri
--------------090705020504090400040409-- From new-work-bounces@ietf.org Mon Mar 21 14:38:54 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6235F28C1A3; Mon, 21 Mar 2011 14:38:54 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id C82FB3A68EA; Mon, 21 Mar 2011 14:38:52 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20110321213852.C82FB3A68EA@core3.amsl.com> Date: Mon, 21 Mar 2011 14:38:52 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Tue, 22 Mar 2011 08:13:52 -0700 Subject: [secdir] [new-work] WG Review: Recharter of Recharter of Softwires (softwire) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 21:38:54 -0000 A modified charter has been submitted for the Softwires (softwire) working group in the Internet Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, March 29, 2011. Softwires (softwire) --------------------------------------------------- Current Status: Active Working Group Chairs: Alain Durand Yong Cui Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion: softwires@ietf.org To Subscribe: softwires-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/softwires/current/maillist.html Description of Working Group: The Softwires Working Group is specifying the standardization of discovery, control and encapsulation methods for connecting IPv4 networks across IPv6 networks and IPv6 networks across IPv4 networks in a way that will encourage multiple, inter-operable implementations. For various reasons, native IPv4 and/or IPv6 transport may not be available in all cases, and there is a need to tunnel IPv4 in IPv6 or IPv6 in IPv4 to cross a part of the network which is not IPv4 or IPv6 capable. The Softwire Problem Statement, RFC 4925, identifies two distinct topological scenarios that the WG will provide solutions for: "Hubs and Spokes" and "Mesh." In the former case, hosts or "stub" networks are attached via individual, point-to-point, IPv4 over IPv6 or IPv6 over IPv4 softwires to a centralized Softwire Concentrator. In the latter case (Mesh), network islands of one Address Family (IPv4 or IPv6) are connected over a network of another Address Family via point to multi-point softwires among Address family Border Routers (AFBRs). The WG will reuse existing technologies as much as possible and only when necessary, create additional protocol building blocks. For generality, all base Softwires encapsulation mechanisms should support all combinations of IP versions over one other (IPv4 over IPv6, IPv6 over IPv4, IPv4 over IPv4, IPv6 over IPv6). IPv4 to IPv6 translation mechanisms (NAT-PT), new addressing schemes, and block address assignments are out of scope. DHCP options developed in this working group will be reviewed jointly with the DHC WG. RADIUS attributes developed in this working group will be reviewed jointly with the RADEXT WG. The MIB Doctors directorate will be asked to review any MIB modules developed in the SOFTWIRE working group. BGP and other routing and signaling protocols developed in this group will be reviewed jointly with the proper working groups and other workings that may take interest (e.g. IDR, L3VPN, PIM, LDP, SAAG, etc). The specific work areas for this working group are: 1. Developments for Mesh softwires topology; the Mesh topology work will be reviewed in the l3vpn and idr WGs - multicast - MIB module 2. Developments for 6rd: - multicast - operational specification - RADIUS option for 6rd server - MIB module 3. Developments for Dual-Stack Lite (DS-Lite): - multicast - operational specification - RADIUS option for AFTR - proxy extensions; GI-DS-Lite; DS-Lite with no NAT or NAT on the B4 element - MIB module 4. Finalize discovery and configuration mechanisms for a gateway to use DS-Lite or 6rd; these discovery and configuration mechanisms must take into a account other operating environments such as dual-stack and tunneling mechanisms not defined by the softwire WG. Development of new mechanisms will involve the dhc and/or v6ops WGs as appropriate Other work items would require WG approval and rechartering. Goals and Milestones: Apr 2011 Submit DS-lite RADIUS option for Proposed Standard Apr 2011 Adopt DS-lite operational document as WG document Jul 2011 Submit 6rd RADIUS option for Proposed Standard Jul 2011 Submit GI DS-lite for Proposed Standard Jul 2011 Adopt B4NAT as WG document Aug 2011 Adopt 6rd operational document as WG document Aug 2011 Adopt Multicast extensions document as WG document Aug 2011 Submit DS-lite operational document for Informational Sep 2011 Submit B4NAT for Informational Nov 2011 Submit Multicast extensions document for Informational Nov 2011 Submit 6rd operational document for Informational Nov 2011 Adopt 6rd MIB module as WG document Nov 2011 Adopt DS-lite MIB module as WG document Nov 2011 Adopt Mesh topology MIB module as WG document Nov 2012 Submit 6rd MIB module for Proposed Standard Nov 2012 Submit DS-lite MIB module for Proposed Standard Nov 2012 Submit Mesh topology MIB module for Proposed Standard _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From tlyu@mit.edu Wed Mar 23 17:49:29 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D1D93A6452; Wed, 23 Mar 2011 17:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.539 X-Spam-Level: X-Spam-Status: No, score=-103.539 tagged_above=-999 required=5 tests=[AWL=-0.940, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBUaxvn2fiZg; Wed, 23 Mar 2011 17:49:28 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by core3.amsl.com (Postfix) with ESMTP id 26B793A63CB; Wed, 23 Mar 2011 17:49:27 -0700 (PDT) X-AuditID: 1209190c-b7b06ae000000ad9-70-4d8a9578fe10 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id DC.FD.02777.8759A8D4; Wed, 23 Mar 2011 20:51:04 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id p2O0p1NG008860; Wed, 23 Mar 2011 20:51:01 -0400 Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p2O0owZM021564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 Mar 2011 20:50:59 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id p2O0ov2u011173; Wed, 23 Mar 2011 20:50:57 -0400 (EDT) To: secdir@ietf.org, iesg@ietf.org, draft-ietf-sidr-signed-object.all@tools.ietf.org From: Tom Yu Date: Wed, 23 Mar 2011 20:50:57 -0400 Message-ID: Lines: 12 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJIsWRmVeSWpSXmKPExsUixG6nrlsxtcvX4OQHA4vzF/ktZvyZyGzx YeFDFgdmjyVLfjJ5fLn8mS2AKYrLJiU1J7MstUjfLoErY3/jM9aCsywVr7ZcZG9gfM3cxcjB ISFgIrFzUUoXIyeQKSZx4d56ti5GLg4hgX2MEmtmNjJDOBsYJR4sO84KUiUkcIVJoqmVFyLR xSjx5PIqRpCEiECsxJvDu9hBpgoLmEt8/+kNYrIJSEscXVwGUsEioCrx5NpDsL28AhYSE3Z5 gIR5BDgldk/ayg5i8woISpyc+YQFxGYW0JK48e8l0wRGvllIUrOQpBYwMq1ilE3JrdLNTczM KU5N1i1OTszLSy3SNdTLzSzRS00p3cQICjFOSZ4djG8OKh1iFOBgVOLh9eHt8hViTSwrrsw9 xCjJwaQkyus7ESjEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhLfXCCjHm5JYWZValA+TkuZgURLn nSGp7iskkJ5YkpqdmlqQWgSTleHgUJLgvTUFqFGwKDU9tSItM6cEIc3EwQkynAdouP0kkOHF BYm5xZnpEPlTjIpS4rxvQZoFQBIZpXlwvbAU8IpRHOgVYd5zIFU8wPQB1/0KaDAT0GA3DbDB JYkIKakGRt4c5d0/Q+8vVIhoVs9KUthjs+zxnRlmnPlcLRe2TU37yn40YOMW/dz1W9dnTS5M Uw6/vL5K938Jd7R0740Lisphd5MvzJP8NOf6koKvhwv0uvqPGmp1NWu6rDWuvWscGcRm0B7t mbDu4vtTTM1fNvG5hipazCgIjbj+9+GNC9emC64UWvb+jxJLcUaioRZzUXEiACgAMo7cAgAA Subject: [secdir] secdir review of draft-ietf-sidr-signed-object X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 00:49:29 -0000 This document defines a profile of the Cryptographic Message Syntax (CMS) signed-data object for use with the Resource Public Key Infrastructure (RPKI). I find Security Considerations section to be reasonable; it describes the expected security properties of RPKI signed objects (including a lack of confidentiality), and rightfully defers to the CMS specification for additional security considerations. Someone more familiar with CMS than I am should check whether the structure version numbers correspond to those specified in RFC 5652; they appear correct to me, though. From Kurt.Zeilenga@Isode.COM Thu Mar 24 11:30:58 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CC5928C10D for ; Thu, 24 Mar 2011 11:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-zWG6mPc2HZ for ; Thu, 24 Mar 2011 11:30:57 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 502D528C0F3 for ; Thu, 24 Mar 2011 11:30:57 -0700 (PDT) Received: from [192.168.42.5] (75-141-240-242.dhcp.reno.nv.charter.com [75.141.240.242]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 24 Mar 2011 18:32:30 +0000 From: Kurt Zeilenga Date: Thu, 24 Mar 2011 11:32:27 -0700 Message-Id: To: draft-ietf-sidr-ta@tools.ietf.org X-Mailer: Apple Mail (2.1084) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Security Area Directorate Subject: [secdir] SecDir Review of draft-ietf-sidr-ta-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 18:30:58 -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. I have reviewed this document and have no concerns. Regards, Kurt= From bew@cisco.com Sun Mar 27 13:36:02 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EB8B3A6946; Sun, 27 Mar 2011 13:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.224 X-Spam-Level: X-Spam-Status: No, score=-110.224 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ez5exKdhE-Oj; Sun, 27 Mar 2011 13:36:00 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 598063A6945; Sun, 27 Mar 2011 13:36:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=1472; q=dns/txt; s=iport; t=1301258257; x=1302467857; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=T8VJAxhiudyTcsm6gMbqpWzq6hQ7ChO8ZvlQ5PaXxaA=; b=Y6My4iDC8lLlYgbIwVGsxV1bXunapEBvkr5LF0goe1WXTRn9kqmsIXjS PRkAqf82C9mOcroadsWNTJcIUcIP/3vKzVeawr3nFEHcfW+z/U1ZfX0B7 JLPaGwzBzTYx+jnQATANq5z0g9A7AkQC5WuPhVHqoO5tawAmy9oAXCUy6 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEefj02rRDoH/2dsb2JhbAClUXelD5p3gxaCUwSFOoc9 X-IronPort-AV: E=Sophos;i="4.63,251,1299456000"; d="scan'208";a="325439373" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 27 Mar 2011 20:37:17 +0000 Received: from sjc-vpn3-943.cisco.com (sjc-vpn3-943.cisco.com [10.21.67.175]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2RKbGOG015048; Sun, 27 Mar 2011 20:37:17 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 27 Mar 2011 13:37:15 -0700 Message-Id: To: secdir@ietf.org, iesg@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Cc: sidr-chairs@tools.ietf.org, draft-ietf-sidr-rpki-algs@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-sidr-rpki-algs-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 20:36:02 -0000 I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. This document describes the algorithm suite used as part of the RPKI. = The suite specifies a single signature algorithm (RSA) with a single key = size, a single hashing algorithm (SHA-256), a single signature format, = and formats for describing the public key. Section 5 indicates that this = profile will be updated when the RPKI needs to adapt different choices. = I was glad to see such an algorithm agility plan, but this implies that = this will in fact never have a peer document describing another profile. = In such a case I would expect the document title to be more inclusive = (e.g., drop the first three words of the title). Alternatively, it might = be helpful to describe in Section 5 under what circumstance another = profile would be published instead of updating this one. The Security Considerations document refers the reader to the security = considerations described in several other documents. After reading those = sections, I agree this is appropriate. Brian --=20 Brian Weis Security Standards and Technology, SRTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From kent@bbn.com Mon Mar 28 00:46:09 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7910B3A68D2; Mon, 28 Mar 2011 00:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1AIJoHji3Dm; Mon, 28 Mar 2011 00:46:08 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id A40D03A6886; Mon, 28 Mar 2011 00:46:08 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:51200 helo=[130.129.71.125]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q47Av-000Ou4-NS; Mon, 28 Mar 2011 03:47:45 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 28 Mar 2011 03:47:29 -0400 To: Brian Weis From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr-chairs@tools.ietf.org, iesg@ietf.org, draft-ietf-sidr-rpki-algs@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-sidr-rpki-algs-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 07:46:09 -0000 At 1:37 PM -0700 3/27/11, Brian Weis wrote: >I have reviewed this document as part of the security directorate's >ongoing effort to review all IETF documents being processed by the >IESG. These comments were written primarily for the benefit of the >security area directors. Document editors and WG chairs should treat >these comments just like any other last call comments. > >This document describes the algorithm suite used as part of the >RPKI. The suite specifies a single signature algorithm (RSA) with a >single key size, a single hashing algorithm (SHA-256), a single >signature format, and formats for describing the public key. Section >5 indicates that this profile will be updated when the RPKI needs to >adapt different choices. I was glad to see such an algorithm agility >plan, but this implies that this will in fact never have a peer >document describing another profile. In such a case I would expect >the document title to be more inclusive (e.g., drop the first three >words of the title). Alternatively, it might be helpful to describe >in Section 5 under what circumstance another profile would be >published instead of updating this one. > >The Security Considerations document refers the reader to the >security considerations described in several other documents. After >reading those sections, I agree this is appropriate. > >Brian Brian, There will be another profile that will define two sets of algs, current and next. See daft-sidr-algorithm-agility-00.txt for the description of how alg migration is anticipated to work. I hesitate to put a (normative) reference to that doc in here, because it is not yet approved and might slow down the set of SIDR docs that rely, normatively, on the doc that you reviewed. Steve From bew@cisco.com Mon Mar 28 01:36:49 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39E063A6893; Mon, 28 Mar 2011 01:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.411 X-Spam-Level: X-Spam-Status: No, score=-110.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QudzvCRURlPj; Mon, 28 Mar 2011 01:36:48 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 281303A68B1; Mon, 28 Mar 2011 01:36:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=3304; q=dns/txt; s=iport; t=1301301505; x=1302511105; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=6lzDb2dBSNCWUf2dnPYQUZRhwHehVxy9RVmiv//c+CA=; b=BJ+5NfHDvP36+fvvChd8nFlutacd6qYboBfVsXG0B3qlJN0NR46zJ7kA 6EuKdKEIIX7YAxZlMXu94YHml/AXgHW6mP4G9PEQJJIUlqqg5m/+57Zls L7PB3IQHW+P78l5WzOwj62Cp+xwURNXt75pnOvR3qDKq7t8ebzSF8QWt6 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAElIkE2rRDoH/2dsb2JhbAClSneIa50RmyyDFoJTBIU6hz2DVA X-IronPort-AV: E=Sophos;i="4.63,253,1299456000"; d="scan'208";a="419277841" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 28 Mar 2011 08:38:25 +0000 Received: from [10.21.78.41] ([10.21.78.41]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2S8cNhD030311; Mon, 28 Mar 2011 08:38:24 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Brian Weis In-Reply-To: Date: Mon, 28 Mar 2011 01:38:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <18783D32-D6AD-48AF-853D-3A6B67B9F9FE@cisco.com> References: To: Stephen Kent X-Mailer: Apple Mail (2.1082) Cc: sidr-chairs@tools.ietf.org, iesg@ietf.org, draft-ietf-sidr-rpki-algs@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-sidr-rpki-algs-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 08:36:49 -0000 Hi Steve, On Mar 28, 2011, at 12:47 AM, Stephen Kent wrote: > At 1:37 PM -0700 3/27/11, Brian Weis wrote: >> I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. >>=20 >> This document describes the algorithm suite used as part of the RPKI. = The suite specifies a single signature algorithm (RSA) with a single key = size, a single hashing algorithm (SHA-256), a single signature format, = and formats for describing the public key. Section 5 indicates that this = profile will be updated when the RPKI needs to adapt different choices. = I was glad to see such an algorithm agility plan, but this implies that = this will in fact never have a peer document describing another profile. = In such a case I would expect the document title to be more inclusive = (e.g., drop the first three words of the title). Alternatively, it might = be helpful to describe in Section 5 under what circumstance another = profile would be published instead of updating this one. >>=20 >> The Security Considerations document refers the reader to the = security considerations described in several other documents. After = reading those sections, I agree this is appropriate. >>=20 >> Brian >=20 > Brian, >=20 > There will be another profile that will define two sets of algs, = current and next. See daft-sidr-algorithm-agility-00.txt for the = description of how alg migration is anticipated to work. I had looked through the algorithm-agility document before commenting = but didn't see that it declared that a new profile would be generated. = Your description of ("two sets of algs, current and next") seems to = match the intent of Section 5, such that it would be an update to this = same profile. Here's the text in question: "It is anticipated that the RPKI will require the adoption of updated key sizes and a different set of signature and hash algorithms over time, in order to maintain an acceptable level of cryptographic security to protect the integrity of signed products in the RPKI. This profile should be updated to specify such future requirements, as and when appropriate." When I read 'updated' I assume it means it adds to the same profile, and = the subsequent 'update' will be published under the same name as the = original. Is that your intent? > I hesitate to put a (normative) reference to that doc in here, because = it is not yet approved and might slow down the > set of SIDR docs that rely, normatively, on the doc that you reviewed. Understood, and I didn't mean to imply a normative reference was needed = -- just an informational explanation of why a different profile might be = needed rather than an update to this one. But if that isn't actually = expected, then I was questioning why the title implied there would in = fact be independent profiles. Thanks, Brian >=20 > Steve --=20 Brian Weis Security Standards and Technology, SRTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From turners@ieca.com Mon Mar 28 06:14:02 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40D943A6824 for ; Mon, 28 Mar 2011 06:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9m4CmZugoPS for ; Mon, 28 Mar 2011 06:14:01 -0700 (PDT) Received: from nm28.bullet.mail.ac4.yahoo.com (nm28.bullet.mail.ac4.yahoo.com [98.139.52.225]) by core3.amsl.com (Postfix) with SMTP id 379473A67DA for ; Mon, 28 Mar 2011 06:14:01 -0700 (PDT) Received: from [98.139.52.189] by nm28.bullet.mail.ac4.yahoo.com with NNFMP; 28 Mar 2011 13:15:34 -0000 Received: from [98.139.52.180] by tm2.bullet.mail.ac4.yahoo.com with NNFMP; 28 Mar 2011 13:15:34 -0000 Received: from [127.0.0.1] by omp1063.mail.ac4.yahoo.com with NNFMP; 28 Mar 2011 13:15:34 -0000 X-Yahoo-Newman-Id: 552472.22205.bm@omp1063.mail.ac4.yahoo.com Received: (qmail 66780 invoked from network); 28 Mar 2011 13:15:34 -0000 Received: from dhcp-1598.meeting.ietf.org (turners@198.180.150.234 with plain) by smtp114.biz.mail.mud.yahoo.com with SMTP; 28 Mar 2011 06:15:33 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: lViUPOwVM1ntSErYpxLNSPJU8S3eDy1vErM3UC.WiQAhTEa 5nEHv54vyPXgVW4EqhmJTpRhG4CHZyoM4_1FzE._.zyOkUby5wtJXWxope6F Y_fy3vdzrdOnUgLdqwNlG9fwrDsJIlkZojrhgf4GRw8iIgW0Vc4tg6g_C7Ux 9MmksBfFPWRh_Ei9wkwIAJ69cP58K78W9qJZy8wB2yYLmG5ZTKEU6HXmPTiw AIWxf_vqGrvMLOmxGHDRTj3RNl3uN_Qf7GUVS1Yx1MeaK0f6E.oboisv_Ga2 YaYzqlUBD2jHcrG6A1FCqGxkTjP39GbJQjNSf9g9551YO_2dSBns8DsxNNR_ TsQorAUbQFj5lj4gEtvMBK7jr0poJekA435Y1AHOlhVUB X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D9089F3.5070200@ieca.com> Date: Mon, 28 Mar 2011 15:15:31 +0200 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] Reminder X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 13:14:02 -0000 This is just a reminder to WG chairs to send a summary to their sessions to saag@ietf.org. This will save you getting up to talk at the mic during saag. spt From kent@bbn.com Mon Mar 28 09:18:28 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5A443A680D; Mon, 28 Mar 2011 09:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJVAPC4aKi31; Mon, 28 Mar 2011 09:18:27 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 94D993A67E5; Mon, 28 Mar 2011 09:18:27 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:44744 helo=[130.129.71.125]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q4FAi-0005qt-LZ; Mon, 28 Mar 2011 12:20:05 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <18783D32-D6AD-48AF-853D-3A6B67B9F9FE@cisco.com> References: <18783D32-D6AD-48AF-853D-3A6B67B9F9FE@cisco.com> Date: Mon, 28 Mar 2011 12:19:55 -0400 To: Brian Weis From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-910793292==_ma============" Cc: sidr-chairs@tools.ietf.org, iesg@ietf.org, draft-ietf-sidr-rpki-algs@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-sidr-rpki-algs-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 16:18:28 -0000 --============_-910793292==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 1:38 AM -0700 3/28/11, Brian Weis wrote: >.... > > > > There will be another profile that will define two sets of algs, >current and next. See daft-sidr-algorithm-agility-00.txt for the >description of how alg migration is anticipated to work. > >I had looked through the algorithm-agility document before >commenting but didn't see that it declared that a new profile would >be generated. Your description of ("two sets of algs, current and >next") seems to match the intent of Section 5, such that it would be >an update to this same profile. Here's the text in question: > > "It is anticipated that the RPKI will require the adoption of updated > key sizes and a different set of signature and hash algorithms over > time, in order to maintain an acceptable level of cryptographic > security to protect the integrity of signed products in the RPKI. > This profile should be updated to specify such future requirements, > as and when appropriate." > >When I read 'updated' I assume it means it adds to the same profile, >and the subsequent 'update' will be published under the same name as >the original. Is that your intent? yes, although "update" is the wrong RFC term. It should say "replace." we shoud make that change, to the text. > > I hesitate to put a (normative) reference to that doc in here, >because it is not yet approved and might slow down the >> set of SIDR docs that rely, normatively, on the doc that you reviewed. > >Understood, and I didn't mean to imply a normative reference was >needed -- just an informational explanation of why a different >profile might be needed rather than an update to this one. But if >that isn't actually expected, then I was questioning why the title >implied there would in fact be independent profiles. OK. And I agree that we probably should change the name to be "The Profile for Algorithms and Key Sizes ..." since we anticipate a replacement for this doc when we adopt new algs. Steve --============_-910793292==_ma============ Content-Type: text/html; charset="us-ascii" Re: [secdir] Secdir review of draft-ietf-sidr-rpki-algs-04
At 1:38 AM -0700 3/28/11, Brian Weis wrote:
....
>
> There will be another profile that will define two sets of algs, current and next.  See daft-sidr-algorithm-agility-00.txt for the description of how alg migration is anticipated to work.

I had looked through the algorithm-agility document before commenting but didn't see that it declared that a new profile would be generated. Your description of ("two sets of algs, current and next") seems to match the intent of Section 5, such that it would be an update to this same profile. Here's the text in question:

  "It is anticipated that the RPKI will require the adoption of updated
   key sizes and a different set of signature and hash algorithms over
   time, in order to maintain an acceptable level of cryptographic
   security to protect the integrity of signed products in the RPKI.
   This profile should be updated to specify such future requirements,
   as and when appropriate."

When I read 'updated' I assume it means it adds to the same profile, and the subsequent 'update' will be published under the same name as the original. Is that your intent?

yes, although "update" is the wrong RFC term. It should say "replace."  we shoud make that change, to the text.

> I hesitate to put a (normative) reference to that doc in here, because it is not yet approved and might slow down the
> set of SIDR docs that rely, normatively, on the doc that you reviewed.
Understood, and I didn't mean to imply a normative reference was needed -- just an informational explanation of why a different profile might be needed rather than an update to this one. But if that isn't actually expected, then I was questioning why the title implied there would in fact be independent profiles.

OK.  And I agree that we probably should change the name to be "The Profile for Algorithms and Key Sizes ..." since we anticipate a replacement for this doc when we adopt new algs.

Steve
--============_-910793292==_ma============-- From bew@cisco.com Mon Mar 28 14:18:36 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1CB828C118; Mon, 28 Mar 2011 14:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.473 X-Spam-Level: X-Spam-Status: No, score=-110.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktWUpP07Qy6B; Mon, 28 Mar 2011 14:18:35 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4EB113A6954; Mon, 28 Mar 2011 14:18:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=9454; q=dns/txt; s=iport; t=1301347213; x=1302556813; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=cMpfJyjkIuNKLIjW5z/9gXfQGPILP4l8hOrM+XqeBVI=; b=BfpJtokq1GKwlCVDtnugb3F2gcNcvIXlErGmKLDJrwOJh2g6TG2lLwDV hOEPQ1hn+yX4Lue+bG6ZwwBSwnZlHdcN2Vi5TR/nRQfycQIi182yensJk rFzHgIMsoUVdvMMLHABwErgxLXg0fLtWErXB9EyWuKRMEpoAAye33h0Ny M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOP6kE2rRDoI/2dsb2JhbACCYaJjd4hroBKcLoMWglMEhTqHPQ X-IronPort-AV: E=Sophos;i="4.63,257,1299456000"; d="scan'208,217";a="672062641" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 28 Mar 2011 21:20:12 +0000 Received: from sjc-vpn2-140.cisco.com (sjc-vpn2-140.cisco.com [10.21.112.140]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2SLJEAJ031612; Mon, 28 Mar 2011 21:20:10 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-32-917462481 From: Brian Weis In-Reply-To: Date: Mon, 28 Mar 2011 14:20:09 -0700 Message-Id: <90CFECDF-0291-49A3-87FE-B1BBC91CF399@cisco.com> References: <18783D32-D6AD-48AF-853D-3A6B67B9F9FE@cisco.com> To: Stephen Kent X-Mailer: Apple Mail (2.1082) Cc: sidr-chairs@tools.ietf.org, iesg@ietf.org, draft-ietf-sidr-rpki-algs@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-sidr-rpki-algs-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 21:18:36 -0000 --Apple-Mail-32-917462481 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 28, 2011, at 9:19 AM, Stephen Kent wrote: > At 1:38 AM -0700 3/28/11, Brian Weis wrote: >> .... >> > >> > There will be another profile that will define two sets of algs, = current and next. See daft-sidr-algorithm-agility-00.txt for the = description of how alg migration is anticipated to work. >>=20 >> I had looked through the algorithm-agility document before commenting = but didn't see that it declared that a new profile would be generated. = Your description of ("two sets of algs, current and next") seems to = match the intent of Section 5, such that it would be an update to this = same profile. Here's the text in question: >>=20 >> "It is anticipated that the RPKI will require the adoption of = updated >> key sizes and a different set of signature and hash algorithms = over >> time, in order to maintain an acceptable level of cryptographic >> security to protect the integrity of signed products in the RPKI. >> This profile should be updated to specify such future = requirements, >> as and when appropriate." >>=20 >> When I read 'updated' I assume it means it adds to the same profile, = and the subsequent 'update' will be published under the same name as the = original. Is that your intent? >=20 > yes, although "update" is the wrong RFC term. It should say "replace." = we shoud make that change, to the text. >=20 >> > I hesitate to put a (normative) reference to that doc in here, = because it is not yet approved and might slow down the >> > set of SIDR docs that rely, normatively, on the doc that you = reviewed. >> Understood, and I didn't mean to imply a normative reference was = needed -- just an informational explanation of why a different profile = might be needed rather than an update to this one. But if that isn't = actually expected, then I was questioning why the title implied there = would in fact be independent profiles. >=20 > OK. And I agree that we probably should change the name to be "The = Profile for Algorithms and Key Sizes ..." since we anticipate a = replacement for this doc when we adopt new algs. Sounds great. I had no other concerns. Thanks, Brian >=20 > Steve --=20 Brian Weis Security Standards and Technology, SRTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com --Apple-Mail-32-917462481 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Mar 28, 2011, at 9:19 AM, Stephen = Kent wrote:

At = 1:38 AM -0700 3/28/11, Brian Weis wrote:
> There will be = another profile that will define two sets of algs, current and = next.  See daft-sidr-algorithm-agility-00.txt for the description = of how alg migration is anticipated to work.

I had looked through = the algorithm-agility document before commenting but didn't see that it = declared that a new profile would be generated. Your description of = ("two sets of algs, current and next") seems to match the intent of = Section 5, such that it would be an update to this same profile. Here's = the text in question:

  "It is anticipated that the RPKI = will require the adoption of updated
   key sizes and a = different set of signature and hash algorithms over
   = time, in order to maintain an acceptable level of = cryptographic
   security to protect the integrity of = signed products in the RPKI.
   This profile should be = updated to specify such future requirements,
   as and when = appropriate."

When I read 'updated' I assume it means it adds to = the same profile, and the subsequent 'update' will be published under = the same name as the original. Is that your = intent?

yes, although "update" is the = wrong RFC term. It should say "replace."  we shoud make that = change, to the text.

> I = hesitate to put a (normative) reference to that doc in here, because it = is not yet approved and might slow down the
> set of SIDR docs = that rely, normatively, on the doc that you = reviewed.
Understood, and I = didn't mean to imply a normative reference was needed -- just an = informational explanation of why a different profile might be needed = rather than an update to this one. But if that isn't actually expected, = then I was questioning why the title implied there would in fact be = independent profiles.

OK.  And I = agree that we probably should change the name to be "The Profile for Algorithms and = Key Sizes ..." since we anticipate a replacement for this doc when we = adopt new algs.

Sounds = great. I had no other = concerns.

Thanks,
Brian

<= /div>
bew@cisco.com





= --Apple-Mail-32-917462481-- From william.polk@nist.gov Tue Mar 29 01:40:03 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BCFD3A68F1 for ; Tue, 29 Mar 2011 01:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.624 X-Spam-Level: X-Spam-Status: No, score=-6.624 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hV3T1ZvguG8 for ; Tue, 29 Mar 2011 01:40:00 -0700 (PDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by core3.amsl.com (Postfix) with ESMTP id 4B39C3A68A6 for ; Tue, 29 Mar 2011 01:40:00 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (wsxghub2.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id p2T8fTu3010431 for ; Tue, 29 Mar 2011 04:41:29 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Tue, 29 Mar 2011 04:40:50 -0400 From: "Polk, William T." To: "secdir@ietf.org" Date: Tue, 29 Mar 2011 04:38:37 -0400 Thread-Topic: [secdir] Tuesday Lunch Room Thread-Index: AcvlnkFpOal74LzuQJqBVcbuBfUTNgITnGgb Message-ID: References: <4D83AAE8.3030007@ieca.com> In-Reply-To: <4D83AAE8.3030007@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: william.polk@nist.gov Subject: [secdir] FW: Tuesday Lunch Room X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 08:40:04 -0000 Just a reminder... we did *not* arrange for box lunches or pizzas this time. See you all in Tyrolka in an hour or so! Tim ________________________________________ From: secdir-bounces@ietf.org [secdir-bounces@ietf.org] On Behalf Of Sean Turner [turners@ieca.com] Sent: Friday, March 18, 2011 2:56 PM To: secdir@ietf.org Subject: [secdir] Tuesday Lunch Room We've been assigned Tyrolka on Tuesday, March 29th (11:30-13:00) for our Security Directorate meeting. See you all there, spt _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From rbarnes@bbn.com Tue Mar 29 01:44:10 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EA163A6873 for ; Tue, 29 Mar 2011 01:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1RpeBIk1SZu for ; Tue, 29 Mar 2011 01:44:09 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 8F3D43A68CE for ; Tue, 29 Mar 2011 01:44:09 -0700 (PDT) Received: from [128.89.255.146] (port=52766 helo=[130.129.17.55]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q4UYc-000H99-Ur; Tue, 29 Mar 2011 04:45:47 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Tue, 29 Mar 2011 10:45:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <476562EB-66C0-46FF-AB9E-7AE0E1588E71@bbn.com> References: <4D83AAE8.3030007@ieca.com> To: "Polk, William T." X-Mailer: Apple Mail (2.1082) Cc: "secdir@ietf.org" Subject: Re: [secdir] FW: Tuesday Lunch Room X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 08:44:10 -0000 Lunch tip in case people haven't heard already: There's an "Albert" = supermarket across the street from the hotel, where you can get a much = broader diversity of food and much cheaper prices than at the hotel. To get there, just go through the revolving doors of the hotel on the = same level as the IETF registration desk and keep going straight until = you get to the next building. There's a shopping area in that building, = and the Albert is on the left just inside. --Richard On Mar 29, 2011, at 10:38 AM, Polk, William T. wrote: > Just a reminder... we did *not* arrange for box lunches or pizzas this = time. See you all in Tyrolka in an hour or so! >=20 > Tim > ________________________________________ > From: secdir-bounces@ietf.org [secdir-bounces@ietf.org] On Behalf Of = Sean Turner [turners@ieca.com] > Sent: Friday, March 18, 2011 2:56 PM > To: secdir@ietf.org > Subject: [secdir] Tuesday Lunch Room >=20 > We've been assigned Tyrolka on Tuesday, March 29th (11:30-13:00) > for our Security Directorate meeting. >=20 > See you all there, >=20 > spt > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir From shanna@juniper.net Tue Mar 29 02:35:25 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B2303A692D; Tue, 29 Mar 2011 02:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0jy4obSAsYd; Tue, 29 Mar 2011 02:35:24 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by core3.amsl.com (Postfix) with ESMTP id 3EAA73A68EC; Tue, 29 Mar 2011 02:35:24 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTZGoN7LVpH2SDNEI+zS3AeVQ94bqTDcl@postini.com; Tue, 29 Mar 2011 02:37:02 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 29 Mar 2011 02:29:39 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 29 Mar 2011 05:31:07 -0400 From: Stephen Hanna To: "secdir@ietf.org" , "iesg@ietf.org" Date: Tue, 29 Mar 2011 05:31:04 -0400 Thread-Topic: secdir review of draft-ietf-pwe3-fc-encap-15.txt Thread-Index: AcvR2J79mnoqbMWXRHiAcNAfdrQddAcGqTcA Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-pwe3-fc-encap@tools.ietf.org" Subject: [secdir] secdir review of draft-ietf-pwe3-fc-encap-15.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 09:35:25 -0000 This is a follow-up to my secdir review of draft-ietf-pwe3-fc-encap-14.txt, included below. I have reviewed the Security Considerations section in the latest version of this draft: draft-ietf-pwe3-fc-encap-15.txt. My concerns with the previous version have been resolved and I'm happy with the new version. It provides good guidance on the security issues related to the document. The new Security Considerations are still brief but they now point to several other documents that provide appropriate guidance. One security issue unique to this document is identified and mitigation measures are recommended. >From a security perspective, this document is now ready to go! Thanks to the document authors for addressing the concerns that I had raised in a prompt and proper manner. Take care, Steve > -----Original Message----- > From: Stephen Hanna > Sent: Monday, February 21, 2011 10:04 AM > To: 'secdir@ietf.org'; iesg@ietf.org > Cc: 'draft-ietf-pwe3-fc-encap@tools.ietf.org' > Subject: secdir review of draft-ietf-pwe3-fc-encap-14.txt >=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 > This document describes how Fibre Channel traffic can be carried > over MPLS networks using a Fibre Channel pseudowire (FC PW). I am > not an expert in Fibre Channel, MPLS, or pseudowires so I will not > venture any judgment on the content of the draft. I will focus > exclusively on the Security Considerations section. >=20 > The Security Considerations section is rather brief, only five > sentences long. While I support brevity, this section seems to > omit key information. For example, the text says "FC PW shares > susceptibility to a number of pseudowire-layer attacks and > implementations SHOULD use whatever mechanisms for confidentiality, > integrity, and authentication are developed for PWs in general. > These methods are beyond the scope of this document." That's too > brief. At least, the authors should add a reference to a document > that describes the attacks to which this protocol is susceptible > and the countermeasures that can be employed. If no such document > exists, either it should be written or this document should describe > the threats and countermeasures or this document should admit that > the threats and countermeasures are not understood at this time. > You can't just leave the analysis of threats and countermeasures > to the reader. >=20 > Thanks, >=20 > Steve Hanna From kent@bbn.com Tue Mar 29 03:38:32 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD03F28C108 for ; Tue, 29 Mar 2011 03:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdEfLbW1yIc6 for ; Tue, 29 Mar 2011 03:38:31 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 6120028C0F5 for ; Tue, 29 Mar 2011 03:38:31 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:55070 helo=[130.129.71.125]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q4WLI-000Hyk-Up for secdir@ietf.org; Tue, 29 Mar 2011 06:40:09 -0400 Mime-Version: 1.0 Message-Id: Date: Tue, 29 Mar 2011 06:40:05 -0400 To: secdir@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [secdir] PKIX summary X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 10:38:32 -0000 About 47 individuals attended the PKIX meeting on Monday. We reviewed document status (two in the RFC editors queue), and 5 in process in the WG. Jim Schaad described his S/MIME capabilities doc, which is ready for WGLC. He noted that the data structure defined therein might be a better choice for the OCSP algorithm offering description. if we elect to adopt this would require that we revise the OCSP agility doc, which is already in the RFC Editor's queue. Tim Polk suggested that if the WG wants to make this change, he can probably persuade the IESG to allow this as an Auth_48 change. Alexey Melinkov noted that the EAI WG is completing a revision RFC 5335bis and RFC 5336bis. These changes will allow UTF-8 characters on both sides of the "@" in an e-mail address. RFC 5280 defines an RFC822 address as an SAN, but does not define addresses relative to UTF-8 encoding. Thus Alexey would like to see an update to 5280 that extends these two SANs to allow for UTF-8 encoding. In the past we have seen a lack of widespread vendor support for UTF-8 in certificates (in DNs). Most recently it appeared that few RPs supported the matching rules that 5280 defines, in lieu of the simple, binary matching rules that were defined in 3280. This may argue for a return to the older, simple rules, if we want to support UTF-8 in these two SANs Paul argued that the alias issue is a red herring, since we may already have this problem, .e.g., foo.com and foo.net. So, we can bring to the list the topic of an update to 5280 that makes UTF-8 support a SHOULD in DNS and e-mail address SANs, and to revert to the simpler matching rules. The meeting ended with a presentation by Joe Salowey, discussing a proposal to pursue development of a lightweight cert management protocol, based on CMS. There was enthusiasm for this work, but also a lot of questions, e.g., what cert management functions will be supported and what are the primary use cases? Nonetheless, this is an interesting topic and it is likely that PKIX will pursue this effort. Steve Kent Stefan Santesson From tena@huawei.com Tue Mar 29 07:31:13 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EC673A682B for ; Tue, 29 Mar 2011 07:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.549 X-Spam-Level: X-Spam-Status: No, score=-105.549 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5MsVZQcI4Od for ; Tue, 29 Mar 2011 07:31:10 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id AA8FF3A6835 for ; Tue, 29 Mar 2011 07:31:10 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIT004GWPQOC8@usaga03-in.huawei.com> for secdir@ietf.org; Tue, 29 Mar 2011 09:32:48 -0500 (CDT) Received: from TingZousc1 ([130.129.19.214]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LIT00IMXPQMVB@usaga03-in.huawei.com> for secdir@ietf.org; Tue, 29 Mar 2011 09:32:48 -0500 (CDT) Date: Tue, 29 Mar 2011 16:31:56 +0200 From: Tina Tsou In-reply-to: <4D9089F3.5070200@ieca.com> To: 'Sean Turner' , secdir@ietf.org Message-id: <031d01cbee1e$2d8128e0$88837aa0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/mixed; boundary="Boundary_(ID_pW6JpCsgplH3L9ZXqyV3QA)" Content-language: en-us Thread-index: AcvtSj5fCN1Dung0Tz2uaWNeq8bp/QA04q+A References: <4D9089F3.5070200@ieca.com> Subject: Re: [secdir] Reminder X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 14:31:13 -0000 This is a multi-part message in MIME format. --Boundary_(ID_pW6JpCsgplH3L9ZXqyV3QA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Sean et al, Hokey's summary is attached. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: secdir-bounces@ietf.org [mailto:secdir-bounces@ietf.org] On Behalf Of Sean Turner Sent: Monday, March 28, 2011 3:16 PM To: secdir@ietf.org Subject: [secdir] Reminder This is just a reminder to WG chairs to send a summary to their sessions to saag@ietf.org. This will save you getting up to talk at the mic during saag. spt _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir --Boundary_(ID_pW6JpCsgplH3L9ZXqyV3QA) Content-type: text/plain; name="Hokey-80 meeting minutes.txt" Content-transfer-encoding: 7BIT Content-disposition: attachment; filename="Hokey-80 meeting minutes.txt" Glen and Tina presiding. NOTE WELL presented. Agenda accepted. Status ====== Glen Zorn. Chair noted that architecture document is moribund. Concerned that authors are acting as a design team rather than being driven by list discussion. Asked to bring issues to the list instead of just discussing internally. LDN discovery being discussed by IESG. 5296bis: IPSecme pressing for changes -- Chair feels this is not appropriate, but if members of HOKEY wished to create drafts on the subject that would be OK. RFC5296bis ========== Qin Wu presenting. Slides. History Changes Simplifying bootstrapping -- no comments on proposed resolution -- to the list -- if no comment thewre, go ahead with proposal MAY vs. SHOULD in sec. 5.3.1.1 -- Tom Taylor noted that SHOULD must be accompanied by text explaining under what circumstances the action would not be taken. Remove distinction between local and home -- Yoav Nir -- Should support cross-domain, IETF view -- Glen as Chair -- doesn't see that one WG would set policy for all -- Klaas, co-Chair of abfab -- agreed -- Glen as individual -- has never understood relevance of home vs. visited for ERP EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK) ============================================================ Zhen Cao Reviewed changes Proposed that draft is ready for WGLC -- Qin Wu -- supports move forward -- Glen -- will await any further comments on list to mid-April, if none received, go to WGLC --Boundary_(ID_pW6JpCsgplH3L9ZXqyV3QA)-- From fred@cisco.com Wed Mar 30 20:51:17 2011 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 693413A6BBE for ; Wed, 30 Mar 2011 20:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.524 X-Spam-Level: X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 792wrSXzZwfa for ; Wed, 30 Mar 2011 20:51:16 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id C19913A68DF for ; Wed, 30 Mar 2011 20:51:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=77414; q=dns/txt; s=iport; t=1301543573; x=1302753173; h=from:subject:date:references:to:message-id:mime-version; bh=4gd9G6RMNb5VslBSF8Bq2xvSQ/43K1bL1YRtgCl7LnE=; b=FzSEtOAfZrOzZoHPUcObB0WLDdP9rLT75uajdQt1ENtZ/oYlcYNUG1u3 LZ88529j7sC/eN61flkdmY1zSJXAM4pMc/PdD1tH4UX5XpDsMoGvTLIMU uaKu9F1g6HUAyJ1HUO5gYG+Lmr9ZPQPhagOI6vtNJzVhaW7fZfJJiI/UR k=; X-Files: T09-SG17-C-0454!!MSW-E.doc : 55808 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIEABL6k02Q/khLgWdsb2JhbAClVxQBARYmJYh5mWybfYVqBI0Gg1U X-IronPort-AV: E=Sophos;i="4.63,272,1299456000"; d="doc'32?scan'32,208,32";a="23872269" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 31 Mar 2011 03:52:52 +0000 Received: from dhcp-4213.meeting.ietf.org (dhcp-10-55-91-84.cisco.com [10.55.91.84]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2V3qlmB017709; Thu, 31 Mar 2011 03:52:52 GMT Received: from [127.0.0.1] by dhcp-4213.meeting.ietf.org (PGP Universal service); Thu, 31 Mar 2011 05:52:52 +0200 X-PGP-Universal: processed; by dhcp-4213.meeting.ietf.org on Thu, 31 Mar 2011 05:52:52 +0200 From: Fred Baker Date: Thu, 31 Mar 2011 05:52:37 +0200 References: <32850C9F-72A5-4E2A-BF15-FF6A236A6B77@cisco.com> To: secdir@ietf.org, Tim Polk Message-Id: <03BEA4A7-EE27-4961-B23D-9AD276797D09@cisco.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: multipart/mixed; boundary=Apple-Mail-231--1033672797 Subject: [secdir] Fwd: New SG17 proposed work items on IPv6 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 03:51:17 -0000 --Apple-Mail-231--1033672797 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The attached was passed to me, and I think it is something that would be = good for you to comment on to the IETF community. Begin forwarded message: > From: Hascall Sharp > Date: March 31, 2011 5:24:00 AM GMT+02:00 > To: "Fred Baker (fred)" > Subject: New SG17 proposed work items on IPv6 >=20 > This is probably not high on your list of things you'd like to see, = but I figured you should be aware of it. >=20 > "Technical security guideline on deploying IPv6"=20 >=20 >=20 --Apple-Mail-231--1033672797 Content-Disposition: attachment; filename=T09-SG17-C-0454!!MSW-E.doc Content-Type: application/msword; x-unix-mode=0644; name="T09-SG17-C-0454!!MSW-E.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAaAAAAAAAAAAA EAAAagAAAAEAAAD+////AAAAAGcAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAA4AJBAAA+BK/AAAAAAAAMAAAAAAACAAAhBoAAA4AYmpiarRWtFYAAAAAAAAAAAAAAAAAAAAA AAAJBBYANzgAANY8AQDWPAEA0g8AAAAAAACvAgAAAAAAAAAAAAAAAAAAAgAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAALcAAAAAACAgAAAAAAAAICAAAGMt AAAAAAAAYy0AAAAAAACzLQAAAAAAALMtAAAAAAAAsy0AABQAAAAAAAAAAAAAAP////8AAAAAxy0A AAAAAADHLQAAAAAAAMctAAA4AAAA/y0AACQAAAAjLgAAVAAAAMctAAAAAAAAuU4AALwBAAB3LgAA AAAAAHcuAAAWAAAAjS4AAAAAAACNLgAAAAAAAI0uAAAAAAAA5S8AAPQAAADZMAAAdAAAAE0xAAA8 AAAAXE4AAAIAAABeTgAAAAAAAF5OAAAAAAAAXk4AAAAAAABeTgAAAAAAAF5OAAAAAAAAXk4AAAAA AAB1UAAAogIAABdTAAAgAgAAXk4AABUAAAAAAAAAAAAAAAAAAAAAAAAAsy0AAAAAAAB2MgAAAAAA AAAAAAAAAAAAAAAAAAAAAADhLwAABAAAAOUvAAAAAAAAdjIAAAAAAAB2MgAAAAAAAF5OAAAAAAAA AAAAAAAAAABjLQAAAAAAAGMtAAAAAAAAjS4AAAAAAAAAAAAAAAAAAI0uAABUAQAAc04AABYAAADG NAAAAAAAAMY0AAAAAAAAxjQAAAAAAAB2MgAA0AAAAGMtAAA4AAAAjS4AAAAAAACzLQAAAAAAAI0u AAAAAAAAXE4AAAAAAAAAAAAAAAAAAMY0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAdjIAAAAAAABcTgAAAAAAAAAAAAAAAAAAxjQAAAAAAADGNAAA /gAAALhLAAAIAQAAmy0AABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7E0AABQAAACNLgAAAAAAAP////8AAAAAADv/NOPu ywEAAAAAAAAAAMctAAAAAAAARjMAABYAAADATAAAGAAAAAAAAAAAAAAASE4AABQAAACJTgAAMAAA ALlOAAAAAAAA2EwAABQBAAA3VQAAAAAAAFwzAAC+AAAAN1UAADAAAAAATgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAADdVAAAAAAAAAAAAAAAAAACzLQAAAAAAAABOAABIAAAAiTEAACIAAACrMQAAGAAAAMY0 AAAAAAAAwzEAABQAAADXMQAAnwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiTEA AAAAAACJMQAAAAAAAIkxAAAAAAAAXk4AAAAAAABeTgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAGjQAAKwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIkxAAAA AAAAiTEAAAAAAACJMQAAAAAAALlOAAAAAAAAdjIAAAAAAAB2MgAAAAAAAHYyAAAAAAAAdjIAAAAA AAAAAAAAAAAAAP////8AAAAA/////wAAAAD/////AAAAAAAAAAAAAAAA/////wAAAAD/////AAAA AP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA /////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAADdVAAAAAAAAiTEAAAAAAACJ MQAAAAAAAIkxAAAAAAAAiTEAAAAAAACJMQAAAAAAAIkxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACJMQAAAAAAAIkxAAAAAAAAiTEA AAAAAAAgIAAACQwAACksAAA6AQAABQASAQAACQQECAEEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEHSU5U RVJOQVRJT05BTCBURUxFQ09NTVVOSUNBVElPTiBVTklPTgdDT00gMTcgliBDIDQ1NCCWIEUHBwdU RUxFQ09NTVVOSUNBVElPTgtTVEFOREFSRElaQVRJT04gU0VDVE9SDVNUVURZIFBFUklPRCAyMDA5 LTIwMTIHTWFyY2ggMjAxMQcHBwdFbmdsaXNoIG9ubHkNT3JpZ2luYWw6IEVuZ2xpc2gHB1F1ZXN0 aW9uKHMpOgcyLzE3BwcHU1RVRFkgR1JPVVAgMTcgliBDT05UUklCVVRJT04gNDU0BwdTb3VyY2U6 B05hdGlvbmFsIEluc3RpdHV0ZSBvZiBJbmZvcm1hdGlvbiBhbmQgQ29tbXVuaWNhdGlvbnMgVGVj aG5vbG9neSwgSmFwYW4gKE5JQ1QpLCBLRERJIENvcnBvcmF0aW9uBwdUaXRsZToHUHJvcG9zYWwg b2YgdGhlIGNyZWF0aW9uIG9mIGEgbmV3IHdvcmsgaXRlbSCTdGVjaG5pY2FsIHNlY3VyaXR5IGd1 aWRlbGluZSBvbiBkZXBsb3lpbmcgSVB2NpQHBw1JbnRyb2R1Y3Rpb24NSW50ZXJuZXQgUHJvdG9j b2wgdmVyc2lvbiA2IChJUHY2KSBwcm92aWRlcyBhIG5ldyBlbmQtdG8tZW5kIGRhdGFncmFtIHRy YW5zbWlzc2lvbiBhY3Jvc3MgbXVsdGlwbGUgSVAgbmV0d29ya3MgdGhhdCB3aWxsIHJ1biBhbG9u Zy1zaWRlIEludGVybmV0IFByb3RvY29sIHZlcnNpb24gNCAoSVB2NCksIGFuZCBldmVudHVhbGx5 IHdpbGwgcmVwbGFjZSBpdC4gV2hpbGUgSVB2NiBpcyBpbnRlbmRlZCB0byBwcm92aWRlIG1hbnkg YnVpbHQtaW4gYmVuZWZpdHMgc3VjaCBhcyBsYXJnZSBhZGRyZXNzIHNwYWNlLCBtb2JpbGl0eSwg YW5kIHF1YWxpdHkgb2Ygc2VydmljZSAoUW9TKSwgYmVjYXVzZSBpdCBpcyBhIG5ldyBwcm90b2Nv bCBhbmQgb3BlcmF0ZXMgaW4gc29tZSBkaWZmZXJlbnQgd2F5cyB0aGFuIElQdjQsIGJvdGggZm9y ZXNlZWFibGUgYW5kIHVuZm9yZXNlZWFibGUgc2VjdXJpdHkgaXNzdWVzIHdpbGwgYXJpc2UuIEVz cGVjaWFsbHksIG1hbnkgbmV3IGZ1bmN0aW9ucyBvciByZXF1aXJlbWVudHMgb2YgSVB2NiwgaS5l LiwgYXV0b21hdGljIGNvbmZpZ3VyYXRpb24gb2YgaW50ZXJmYWNlcywgbWFuZGF0b3J5IElQc2Vj LCBtYW5kYXRvcnkgbXVsdGljYXN0LCBtdWx0aXBsZSBJUCBhZGRyZXNzZXMgYW5kIG1hbnkgbmV3 IHJ1bGVzIGZvciByb3V0aW5nLCBjYW4gYmUgYWJ1c2VkIGZvciBjb21wcm9taXNpbmcgY29tcHV0 ZXIgc3lzdGVtcyBvciBuZXR3b3Jrcy4gSW4gZmFjdCwgTmF0aW9uYWwgSW5zdGl0dXRlIG9mIElu Zm9ybWF0aW9uIGFuZCBDb21tdW5pY2F0aW9ucyBUZWNobm9sb2d5IChOSUNUKSBoYXMgaWRlbnRp ZmllZCBtb3JlIHRoYW4gNjAgc2VjdXJpdHkgdGhyZWF0cyBhbmQgdnVsbmVyYWJpbGl0aWVzIHRo YXQgbWF5IGJlIGNhdXNlZCBieSBuZXcgZnVuY3Rpb25zIG9yIHJlcXVpcmVtZW50cyBvZiBJUHY2 LiBBbHNvLCBOSUNUIGhhcyBpbXBsZW1lbnRlZCBhbiBJUHY2IHRlc3RiZWQgZm9yIGluc3BlY3Rp bmcgdnVsbmVyYWJpbGl0aWVzIGluIElQdjYtZW5hYmxlZCBwcm9kdWN0cyBhbmQgc29sdXRpb25z IChlLmcuLCByb3V0ZXIsIERIQ1Agc2VydmVyLCBJRFMsIGZpcmV3YWxsKSwgYW5kIGl0IGV4YW1p bmVkIDI3IHJlcHJlc2VudGF0aXZlIHZ1bG5lcmFiaWxpdGllcyB3aGV0aGVyIHBvdGVudGlhbCBj eWJlciBhdHRhY2tzIHVzaW5nIHRoZW0gY2FuIGJlIHN1Y2Nlc3Mgb3IgZmFpbHVyZSBpbiB0aGUg SVB2NiBuZXR3b3Jrcy4gVGhlIGV4cGVyaW1lbnRhbCByZXN1bHRzIHNob3cgdGhhdCAyMCB2dWxu ZXJhYmlsaXRpZXMgbGVkIHRvIHRoZSBzdWNjZXNzZnVsIGF0dGFja3MgYW5kIHRoZSBmb2xsb3dp bmcgdGhyZWUgZXhhbXBsZXMgZGVzY3JpYmUgYSBwYXJ0IG9mIHRoZSBhdHRhY2sgc2NlbmFyaW9z Lg0NSVB2NiBob3N0cyBjYW4gYXV0b21hdGljYWxseSBjb25maWd1cmUgdGhlaXIgYWRkcmVzc2Vz IChlLmcuLCBnbG9iYWwgYWRkcmVzc2VzKSB1c2luZyBJbnRlcm5ldCBDb250cm9sIE1lc3NhZ2Ug UHJvdG9jb2wgdmVyc2lvbiA2IChJQ01QdjYpIFJvdXRlciBBZHZlcnRpc2VtZW50IChSQSkgbWVz c2FnZXMuIFNpbmNlIHRoZXkgYWxzbyBjYW4gY2hvb3NlIGEgZGVmYXVsdCByb3V0ZXIgYmFzZWQg b24gUkEgbWVzc2FnZXMsIFJBIG1lc3NhZ2VzIGNhbiBiZSB1c2VkIGZvciBtYW4taW4tdGhlLW1p ZGRsZSBhdHRhY2suIEluIG90aGVyIHdvcmRzLCBpZiBhIG1hbGljaW91cyBub2RlIHNlbmRzIGEg Zm9yZ2VkIFJBIG1lc3NhZ2Ugd2hlcmUgdGhlIGRlZmF1bHQgcm91dGVyIGlzIHNldCB0byBpdHNl bGYgdG8gdmljdGltIGhvc3RzLCB0aGUgbWFsaWNpb3VzIG5vZGUgaXMgYWJsZSB0byBzdGVhbCBh bmQgd2F0Y2ggYWxsIHRyYWZmaWMgb2YgdGhlIHZpY3RpbSBob3N0cy4NV2hlbiBJUHY2IGhvc3Rz IGNvbmZpZ3VyZSB0aGVpciBhZGRyZXNzZXMgdXNpbmcgUkEgbWVzc2FnZXMsIHRoZXkgaGF2ZSB0 byBjb25kdWN0IER1cGxpY2F0ZSBBZGRyZXNzIERldGVjdGlvbiAoREFEKSBwcm9jZWR1cmUgdG8g dmVyaWZ5IHRoZSB1bmlxdWVuZXNzIG9mIHRoZSB0ZW50YXRpdmUgYWRkcmVzc2VzIG9uIGEgbGlu ay4gRHVyaW5nIHRoZSBwcm9jZWR1cmUgZm9yIGRldGVjdGluZyBkdXBsaWNhdGUgYWRkcmVzc2Vz LCBJUHY2IGhvc3RzIHRoYXQgaGF2ZSB0ZW50YXRpdmUgYWRkcmVzc2VzIHNlbmQgTmVpZ2hib3Ig U29saWNpdGF0aW9uIChOUykgbWVzc2FnZXMgb24gdGhlIGxpbmsgYW5kIGEgbm9kZSBhbHJlYWR5 IHVzaW5nIHRoZSB0ZW50YXRpdmUgYWRkcmVzcyByZXBsaWVzIHdpdGggYSBOZWlnaGJvciBBZHZl cnRpc2VtZW50IChOQSkgbWVzc2FnZS4gSWYgdGhlcmUgaXMgbm8gcmVzcG9uc2UsIHRoZSB0ZW50 YXRpdmUgYWRkcmVzcyBjYW4gYmUgYXNzaWduZWQgdG8gdGhlIGludGVyZmFjZSBvZiBJUHY2IGhv c3RzLiBIb3dldmVyLCBhIG1hbGljaW91cyBob3N0IG9uIHRoZSBsaW5rIGNhbiBwcmV2ZW50IElQ djYgaG9zdHMgZnJvbSBvYnRhaW5pbmcgdGhlaXIgYWRkcmVzc2VzOiBpZiBhIG1hbGljaW91cyBo b3N0IGFsd2F5cyByZXBsaWVzIE5BIG1lc3NhZ2VzIGFnYWluc3QgTlMgbWVzc2FnZXMgb2Ygb3Ro ZXIgSVB2NiBob3N0cywgdGhleSBhcmUgdW5hYmxlIHRvIG9idGFpbiB0aGVpciBhZGRyZXNzZXMu DUlQdjYgaG9zdHMgbWF5IGNvbmZpZ3VyZSB0aGVpciBhZGRyZXNzZXMgYnkgdXNpbmcgc3RhdGVm dWwgY29uZmlndXJhdGlvbiBwcm90b2NvbCBzdWNoIGFzIHRoZSBEeW5hbWljIEhvc3QgQ29uZmln dXJhdGlvbiBQcm90b2NvbCB2ZXJzaW9uIDYgKERIQ1B2NikgaWYgdGhleSBkaWRuknQgcmVjZWl2 ZSBhbnkgUkEgbWVzc2FnZXMgZnJvbSByb3V0ZXJzLiBEdXJpbmcgdGhlIHN0YXRlZnVsIGNvbmZp Z3VyYXRpb24sIElQdjYgaG9zdHMgc2VuZCBESENQdjYgc29saWNpdCBtZXNzYWdlcyB0byBhbGwg REhDUHY2IHNlcnZlcnMgdXNpbmcgREhDUCBtdWx0aWNhc3QgYWRkcmVzc2VzIHNvIHRoYXQgdGhl eSBhcmUgYWJsZSB0byBvYnRhaW4gYWRkcmVzc2VzIGFzIHdlbGwgYXMgb3RoZXIgY29uZmlndXJh dGlvbiBwYXJhbWV0ZXJzIChlLmcuLCBETlMgc2VydmVycykuIEluIHRoYXQgY2FzZSwgYSBtYWxp Y2lvdXMgaG9zdCBpcyBhYmxlIHRvIHByZXZlbnQgb3RoZXIgSVB2NiBob3N0cyBmcm9tIG9idGFp bmluZyBhZGRyZXNzZXMgYnkgZXhoYXVzdGluZyBhZGRyZXNzIHBvb2wgb2YgREhDUHY2IHNlcnZl cnMuIEluIG90aGVyIHdvcmRzLCBpZiBhIG1hbGljaW91cyBob3N0IGlzc3VlcyBhIGxhcmdlIGFt b3VudCBvZiBESENQdjYgc29saWNpdCBtZXNzYWdlcyB0byBvYnRhaW4gYWxsIGFkZHJlc3NlcyB0 aGF0IERIQ1B2NiBzZXJ2ZXJzIGhhdmUsIG90aGVyIElQdjYgaG9zdHMgYXJlIHVuYWJsZSB0byBv YnRhaW4gdGhlaXIgYWRkcmVzc2VzLg1Qcm9wb3NhbA1RMi8xNyBhcHByb3ZlcyBhIJN0ZWNobmlj YWwgZ3VpZGVsaW5lIG9uIGRlcGxveWluZyBJUHY2lCB3b3JrIGl0ZW0gdG8gYmUgdW5kZXJ0YWtl biBhbmQgcHJvZ3Jlc3NlZC4NVGhlIHByb3BvbmVudHMgb2YgdGhpcyB3b3JrIHByb3ZpZGUgYW4g ZWxhYm9yYXRlZCB2ZXJzaW9uIG9mIHRoZSBSZWNvbW1lbmRhdGlvbi4NDV9fX19fX19fX19fDQMN DQQNDQMNDQQNDS0gEyBQQUdFICBcKiBNRVJHRUZPUk1BVCAUMhUgLQ1DT00gMTcgliBDIDQ1NCCW IEUNDUlUVS1UXENPTS1UXENPTTE3XENcNDU0RS5ET0MNDUNvbnRhY3Q6B0p1bmdzdWsgU29uZw1O SUNUIA1KYXBhbgdUZWw6ICs4MSA0MiAzMjcgNjkwNg1GYXg6ICs4MSA0MiA0MjcgNjY0MA1FbWFp bDogc29uZ0BuaWN0LmdvLmpwBwdDb250YWN0OgdLb2ppIE5ha2FvDU5JQ1QvS0RESSANSmFwYW4H VGVsOiArODEgNDIgMzI3IDU4MjENRmF4OiArODEgNDIgNDI3IDY2NDANRW1haWw6IGtvLW5ha2Fv QG5pY3QuZ28uanAHB0F0dGVudGlvbjogVGhpcyBpcyBub3QgYSBwdWJsaWNhdGlvbiBtYWRlIGF2 YWlsYWJsZSB0byB0aGUgcHVibGljLCBidXQgYW4gaW50ZXJuYWwgSVRVLVQgRG9jdW1lbnQgaW50 ZW5kZWQgb25seSBmb3IgdXNlIGJ5IHRoZSBNZW1iZXIgU3RhdGVzIG9mIElUVSwgYnkgSVRVLVQg U2VjdG9yIE1lbWJlcnMgYW5kIEFzc29jaWF0ZXMsIGFuZCB0aGVpciByZXNwZWN0aXZlIHN0YWZm IGFuZCBjb2xsYWJvcmF0b3JzIGluIHRoZWlyIElUVSByZWxhdGVkIHdvcmsuIEl0IHNoYWxsIG5v dCBiZSBtYWRlIGF2YWlsYWJsZSB0bywgYW5kIHVzZWQgYnksIGFueSBvdGhlciBwZXJzb25zIG9y IGVudGl0aWVzIHdpdGhvdXQgdGhlIHByaW9yIHdyaXR0ZW4gY29uc2VudCBvZiBJVFUtVC4HBw0N DQ0NDQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAEIAAACCAAAKAgA ADoIAAA7CAAAPQgAAGYIAABzCAAAfAgAAH0IAACHCAAAiAgAAIoIAACLCAAAqQgAAKoIAACrCAAA uAgAALkIAAC8CAAAvwgAAOEIAADiCAAA6ggAAEsJAABRCQAAsAkAALEJAAC+CQAA6gkAABgKAADn 4NfQxuC617SqoZXguqGV4Ivgh+CL4Ivgi+B9dGVYAAAAAAAAAAAAAAAAAAAAAAAZFmhfb1gAbUgJ BG5IEQRvKAFzSAkEdEgRBBwVaFAVzgAWaF9vWABtSAkEbkgRBHNICQR0SBEEABEWaF9vWABuSBEE bygBdEgRBBIWaF9vWABCKgFvKAFwaAAAAAAABhZo3Ro9AAASFWjdGj0AFmjdGj0ANQiBXAiBABYV aN0aPQAWaN0aPQA1CIFDShwAXAiBABAWaN0aPQA1CIFDShwAXAiBABMVaN0aPQAWaN0aPQA6CIFD ShQAChZo3Ro9AENKFAAAFhVo3Ro9ABZo3Ro9ADUIgUNKGgBcCIEAExVo3Ro9ABZo3Ro9ADUIgUNK HAANFmjdGj0ANQiBQ0ocABAVaN0aPQAWaN0aPQBDShQAAAwVaN0aPQAWaN0aPQAALwNqAAAAABVo 5UU4ABZo5UU4ADUIgUNKJABVCAFtSAAEbkgABHNICQR0SAQIdQgBAB8ACAAAAggAACgIAAA7CAAA PAgAAD0IAABmCAAAfQgAAIgIAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAOoAAAAAAAAAAAAA AACHAAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA6gAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYgAAa2RiGAAAFiQBFyQBSWYBAAAAApY5AAM0AQjW RgADx/9QBXkZiiZgBokFAAAAAAAAAAAAAAAAAAAAAAAGKRQAAAAAAAAAAAAAAAAAAAAAAAYRDQAA AAAAAAAAAAAAAAAAAAAU9gPDJhf2AwAAGtYMAAAA/wAAAP8AAAD/G9YMAAAA/wAAAP8AAAD/HNYM AAAA/wAAAP8AAAD/HdYMAAAA/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEKAzkAYfYDAABmNAEMAAAD JAIWJAFJZgEAAABhJAJnZN0aPQAJAAAWJAFJZgEAAABnZN0aPQAACIgIAACJCAAAiggAAIsIAACY CAAAqggAAJoAAAAAAAAAAAAAAACRAAAAAAAAAAAAAAAAkQAAAAAAAAAAAAAAAIUAAAAAAAAAAAAA AACFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAyQCFiQBSWYBAAAAYSQCZ2TdGj0ACQAAFiQBSWYBAAAA Z2TdGj0AAGQAAGtk3RgAABYkARckAUlmAQAAAAKWOQADNAEHlGMBCNZGAAPH/1AFGBWKJiAGiQUA AAAAAAAAAAAAAAAAAAAAYAbIDwAAAAAAAAAAAAAAAAAAAAAABnIRAAAAAAAAAAAAAAAAAAAAABT2 A8MmF/YDAAAa1gwAAAD/AAAA/wAAAP8b1gwAAAD/AAAA/wAAAP8c1gwAAAD/AAAA/wAAAP8d1gwA AAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoDOQBh9gMAAGY0AQAFqggAAKsIAAC4CAAAvQgAAL4I AACaAAAAAAAAAAAAAAAAkQAAAAAAAAAAAAAAAJEAAAAAAAAAAAAAAACFAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAMAAADJAIWJAFJZgEAAABhJAJnZN0aPQAJAAAWJAFJZgEAAABn ZN0aPQAAZAAAa2RhGQAAFiQBFyQBSWYBAAAAApY5AAM0AQeUDAMI1kYAA8f/UAUYFYomIAaJBQAA AAAAAAAADAEAAAAAAAAgBsgPAAAAAAAAAAAMAQAAAAAAAIAGchEAAAAAAAAAAAwBAAAAAAAAFPYD wyYX9gMAABrWDAAAAP8AAAD/AAAA/xvWDAAAAP8AAAD/AAAA/xzWDAAAAP8AAAD/AAAA/x3WDAAA AP8AAAD/AAAA/zTWBgABBQMAADTWBgABCgM5AGH2AwAAZjQBAAS+CAAAvwgAAOEIAADiCAAA6ggA AEoJAACaAAAAAAAAAAAAAAAAjgAAAAAAAAAAAAAAAE8AAAAAAAAAAAAAAABGAAAAAAAAAAAAAAAA RgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAkAABYkAUlmAQAAAGdk3Ro9AAA+AABrZHMaAAAWJAEXJAFJZgEAAAACljkAAzQBB5Rl AQjWGgABx/+KJgAGwyYAAAAAAAAAAAAAAAAAAAAAFPYDwyYX9gMAABrWBAAAAP8b1gQAAAD/HNYE AAAA/x3WBAAAAP801gYAAQUDAAA01gYAAQoDOQBh9gMAAGY0AQwAAAMkARYkAUlmAQAAAGEkAWdk 3Ro9AABkAABrZPkZAAAWJAEXJAFJZgEAAAACljkAAzQBB5RlAQjWRgADx/8YBjgTiiYABlEGAAAA AAAAAAAAAAAAAAAAAAAGIA0AAAAAAAAAAAAAAAAAAAAAAAZSEwAAAAAAAAAAAAAAAAAAAAAU9gPD Jhf2AwAAGtYMAAAA/wAAAP8AAAD/G9YMAAAA/wAAAP8AAAD/HNYMAAAA/wAAAP8AAAD/HdYMAAAA /wAAAP8AAAD/NNYGAAEFAwAANNYGAAEKAzkAYfYDAABmNAEABUoJAABLCQAAUgkAAK8JAACwCQAA sQkAAL4JAACtAAAAAAAAAAAAAAAAogAAAAAAAAAAAAAAAKIAAAAAAAAAAAAAAABQAAAAAAAAAAAA AAAASAAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwEAAyQDCiYAC0YK AGEkA2dkX29YAAAHAAADJANhJANnZF9vWAAAUQAAa2QlGwAAFiQBFyQBSWYBAAAAApY5AAM0AQeU ZQEI1jAAAsf/GAaKJgAGUQYAAAAAAAAAAAwBAAAAAAAAAAZyIAAAAAAAAAAADAEAAAAAAAAU9gPD Jhf2AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP801gYAAQUD AAA01gYAAQoDOQBh9gMAAGY0AQsAABSkeAAWJAFJZgEAAABnZN0aPQAAUQAAa2TBGgAAFiQBFyQB SWYBAAAAApY5AAM0AQeUZQEI1jAAAsf/GAaKJgAGUQYAAAAAAAAAAAAAAAAAAAAAAAZyIAAAAAAA AAAAAAAAAAAAAAAU9gPDJhf2AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYI AAAA/wAAAP801gYAAQUDAAA01gYAAQoDOQBh9gMAAGY0AQAGGAoAACAKAAAsCgAAMgoAAEUKAABo CgAAawoAAIoKAACPCgAAkAoAAKQKAACxCgAAugoAAOoKAADuCgAABgsAAJELAACSCwAAmgwAAMEM AADgDAAAIQ0AACINAAAHDwAAJg8AACcPAAAoDwAATw8AAHcPAACtDwAA9xAAABYRAAAcEQAAJhEA ADUSAAA6EgAAXRIAAGkSAABvEgAAhRIAAIYSAACHEgAAkRIAAKgSAADDEgAAzRIAAOQSAADqEgAA 9BIAAPwSAAAqEwAAKxMAAPTn2PTY9Mz02PTY9Nj02PTY9MC3r8Cvp5ivja+Nr6evja+Cr4Kvgq+C r4Kvgq+Cr4KvggAUFWjQPKsAFmhfb1gAbkgRBHRIEQQAFBVoeH3gABZoX29YAG5IEQR0SBEEABwV aHAaEAAWaF9vWABtSAkEbkgRBHNICQR0SBEEAA4WaK1OpQBuSBEEdEgRBAAOFmhfb1gAbkgRBHRI EQQAERZoX29YAG5IEQRvKAF0SBEEFxVoX1eOABZoX29YAG5IEQRvKAF0SBEEFhZorU6lAG1ICQRu SBEEc0gJBHRIEQQAHBVoUBXOABZoX29YAG1ICQRuSBEEc0gJBHRIEQQAGRZoX29YAG1ICQRuSBEE bygBc0gJBHRIEQQWFmhfb1gAbUgJBG5IEQRzSAkEdEgRBDO+CQAAJw8AACgPAAAXEQAADBQAAAcX AAAQFwAAdBcAAMUXAADGFwAA0hcAANQXAADVFwAA1xcAANgXAADaFwAA2xcAAPEAAAAAAAAAAAAA AADZAAAAAAAAAAAAAAAAvQAAAAAAAAAAAAAAAL0AAAAAAAAAAAAAAAC9AAAAAAAAAAAAAAAAsgAA AAAAAAAAAAAAAKcAAAAAAAAAAAAAAACnAAAAAAAAAAAAAAAAmwAAAAAAAAAAAAAAAI8AAAAAAAAA AAAAAACNAAAAAAAAAAAAAAAAjQAAAAAAAAAAAAAAAI0AAAAAAAAAAAAAAACNAAAAAAAAAAAAAAAA jQAAAAAAAAAAAAAAAI0AAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAsAAAMkAQ+EaAFehGgBYSQBZ2Rf b1gAAAsAAAMkAw+EaAFehGgBYSQDZ2Rfb1gACwAAAyQDCiYAC0YMAGEkA2dkX29YAAsBAAMkAwom AAtGCgBhJANnZF9vWAAAGwAAAyQDCiYAC0YNAA3GCgQaA6cENAbBBwATpAAANSQBNyQBOCQBOUQE AEgkAWEkA2dkX29YABgAAAMkAw3GCgQaA6cENAbBBwATpAAANSQBNyQBOCQBOUQEAEgkAWEkA2dk X29YAAANAAADJAMRhPAAV0RkAGCE8ABhJANnZF9vWAAAECsTAADtEwAACxQAAAwUAAARFAAAZhQA AKAUAADVFAAA1hQAAAYXAAAHFwAAEBcAAHQXAADEFwAAxhcAANEXAADSFwAA0xcAANUXAADWFwAA 2BcAANkXAADbFwAA3BcAAN4XAADgFwAA4RcAAPcXAAD4FwAA+RcAAPoXAAAPGAAAEBgAABEYAAAu GAAALxgAADgYAAD48Ofc+Nz43PjR5/jG+Lqqop6inqKeop6XjJeMg4yXfHhrnl8AAAAAAAAWFWjd Gj0AFmjdGj0ANQiBQ0oWAFwIgQAYFWjdGj0AFmjdGj0AbUgABG5IAARzSAwQAAYWaF9vWAAADBVo 3Ro9ABZoX29YAAARFmjdGj0AbUgABG5IAAR1CAEVA2oAAAAAFWjdGj0AFmjdGj0AVQgBDBVo3Ro9 ABZo3Ro9AAAGFmjlRTgAAA8DagAAAAAWaOVFOABVCAEfFWiLUSUAFmhfb1gAbUgJBG5IEQRvKAFz SAkEdEgRBBYWaF9vWABtSAkEbkgRBHNICQR0SBEEABQVaBxi+gAWaF9vWABuSBEEdEgRBAAUFWgB IyoAFmhfb1gAbkgRBHRIEQQAFBVoQlXzABZoX29YAG5IEQR0SBEEABEWaF9vWABuSBEEbygBdEgR BA4WaK1OpQBuSBEEdEgRBAAOFmhfb1gAbkgRBHRIEQQk2xcAAN0XAADeFwAA/RcAABAYAAARGAAA LhgAAC8YAAA4GAAARRgAAEsYAABRGAAAZhgAAHsYAACSGAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD4AAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAOMAAAAAAAAAAAAAAADaAAAAAAAAAAAAAAAAzwAAAAAAAAAAAAAAAM8AAAAA AAAAAAAAAADjAAAAAAAAAAAAAAAAzwAAAAAAAAAAAAAAAM8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAE6QAABYk AUlmAQAAAGdk5UU4AAkAABYkAUlmAQAAAGdk3Ro9AAkAABYkAUlmAQAAAGdk5UU4AAAEKQBnZN0a PQAABjAAFKTwAGdk3Ro9AAAEMABnZN0aPQAAAQAAAA44GAAARRgAAEoYAABLGAAAUBgAAJMYAACc GAAAoRgAAKcYAACxGAAAshgAALcYAAC4GAAA8RgAAPwYAAD+GAAACBkAAEUZAABfGQAAfRoAAH4a AAB/GgAAgRoAAIMaAACEGgAA8+Xz5dzQuqa6prqZ3I3cgXiBeHF4bWlZAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHxVoi1ElABZoX29YAG1ICQRu SBEEbygBc0gJBHRIEQQGFmhfb1gAAAYWaOVFOAAADBVo3Ro9ABZo3Ro9AAAQFWjdGj0AFmjdGj0A Q0oSAAAWFWjdGj0AFmjdGj0ANQiBQ0oSAFwIgQAXFWjdGj0AFmjdGj0AQ0oWAFwIgWFKGAAYFWjd Gj0AFmjdGj0AQ0oWAG1IFQRzSBUEACcVaN0aPQAWaN0aPQBDShYAXAiBYUoYAG1IFQRuSBEEc0gV BHRIEQQqFWjdGj0AFmjdGj0AQ0oWAFwIgWFKGABtSBUEbkgRBG8oAXNIFQR0SBEEABYVaN0aPQAW aN0aPQA1CIFDShYAXAiBABAVaN0aPQAWaN0aPQBDShYAABsVaN0aPQAWaN0aPQBDShYAbkgRBG8o AXRIEQQYFWjdGj0AFmjdGj0AQ0oWAG5IEQR0SBEEGJIYAACTGAAAnBgAAKcYAACyGAAAuBgAAM0Y AADiGAAA/RgAAJUAAAAAAAAAAAAAAACMAAAAAAAAAAAAAAAAgwAAAAAAAAAAAAAAAHgAAAAAAAAA AAAAAABtAAAAAAAAAAAAAAAAjAAAAAAAAAAAAAAAAHgAAAAAAAAAAAAAAAB4AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAE6QAABYkAUlmAQAAAGdk3Ro9AAsAABOkAAAWJAFJZgEA AABnZOVFOAAJAAAWJAFJZgEAAABnZN0aPQAJAAAWJAFJZgEAAABnZOVFOAAAaQAAa2SXGwAAFiQB FyQBSWYBAAAAAFQBAAKWOQADNAEHlMwACNZGAAPH/xgGQheKJgAGUQYMAQAAAAAAAAAAAAAAAAAA AAYqEQwBAAAAAAAAAAAAAAAAAAAABkgPDAEAAAAAAAAAAAAAAAAAABT2A8MmF/YDAAAY9gMAABrW DAAAAP8AAAD/AAAA/xvWDAAAAP8AAAD/AAAA/xzWDAAAAP8AAAD/AAAA/x3WDAAAAP8AAAD/AAAA /zTWBgABCgM5AGH2AwAAZjQBeXTdGj0AilQBAAAI/RgAAP4YAAB9GgAAfhoAAH8aAACAGgAAlQAA AAAAAAAAAAAAAIoAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAOAAAAAAAAAAAAAAAADMAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAQpAGdk3Ro9AAAGAAATpAAAZ2TdGj0AAEoAAGtk1xwAABYkARck AUlmAQAAAABUAQAClmwAAzQBCNYaAAHH/4omAAbDJgQBAAAEAQAABAEAAAQBAAAU9gPDJhf2AwAA GPYDAAAa1gQAAAD/G9YEAAAA/xzWBAAAAP8d1gQAAAD/MtYGAAEKAzkANNYGAAEFAwAANNYGAAEK A2wAYfYDAABmNAF5dN0aPQCKVAEACwAAE6QAABYkAUlmAQAAAGdk3Ro9AABpAABrZDccAAAWJAEX JAFJZgEAAAAAVAEAApY5AAM0AQeUzAAI1kYAA8f/GAZCF4omAAZRBgwBAAAAAAAAAAAAAAAAAAAA BioRDAEAAAAAAAAAAAAAAAAAAAAGSA8MAQAAAAAAAAAAAAAAAAAAFPYDwyYX9gMAABj2AwAAGtYM AAAA/wAAAP8AAAD/G9YMAAAA/wAAAP8AAAD/HNYMAAAA/wAAAP8AAAD/HdYMAAAA/wAAAP8AAAD/ NNYGAAEKAzkAYfYDAABmNAF5dN0aPQCKVAEAAAWAGgAAgRoAAIIaAACDGgAAhBoAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL AAADJAEPhGgBXoRoAWEkAWdkX29YAAABAAAABDUACjABMZBGATpw3Ro9AB+wgy4gsMhBIbBuBCKw bgQjkIkFJJCJBSWwAAAXsNACGLDQAgyQ0AIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYhgAAEQAZAAAAAAAAAAIAAAAAAAAAAAAAAAAAEUG CAf1At0CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwjgAAALIECvAIAAAAAQQA AAAKAACTAAvwagAAAL8ABAAEAARBAQAAAAXBEAAAAD8BAAAGAL8BAAAQAP8BAAAIAIDDFAAAAIHD EAAAAL8DAAACAGkAdAB1AC0AbwBsAGQAAABQAGkAYwB0AHUAcgBlACAAMQAAAGkAdAB1AC0AbwBs AGQAAAAAABDwBAAAAAAAAIBiAAfwgBcAAAYGMgTfKi4nbASZFxoj5FYYTP8AXBcAAAEAAABEAAAA AAASAABuHvBUFwAAMgTfKi4nbASZFxoj5FYYTP+JUE5HDQoaCgAAAA1JSERSAAAAawAAAHgIAwAA AMIj/AsAAAMAUExURaLE2YeVxOzx8oq20sTW37zT3dzm6dXh5ZiEp2SOvKzK2pG61Rs3j/r6+qWy z+pnhfLF0ChElpajyeRUdnWlyLHN23eJu/Hz+DhTnml8tPT19sbZ4K1ojsPL4oejxs3d4mqXwe+x wNDe5J3B2Upgp7jS4+jt71lureTr7ODo6u2Rp4Szz+Tu9N7n6uvv8LO92OLq7FV+tOQmUvKfstjj 5tPY6csqV8ja4fP09cDW37rM2t0NPefX3rbQ3O/y8+br7aS30Ja91/b3+Oc/ZqQMS+MQQPvg5l11 r5qvyy5MmlyFt0NaoTldorPG18rU3+p+l051r9bk6r5GcGMcaOLl8Zm/2ERipt/r8n6Tvs+Zr8is vazD1rzH2kduq8aAncvc4+Pm7T9lp1Fqqc/g6tgYR5Kvzc7e5r03ZbvF1e/j59nf6rLA1cnc5cre 66m90p6tzMfc6c/a4/Hz86fH2v3w89HX56Ww0/3v8qfJ3ePs72BXmOEAM3+xzg4rif///wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAM25c8QAAACAdFJOU/////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////8AOAVLZwAAAAFiS0dEf0i/ceUAAAAMY21QUEpDbXAwNzEyAAAAA0gAc7wAABNNSURB VGhDvZrtQ9rYEsYDCFQgahDDiciLQImIICouUgsivTWGRCpdtdytrCu+tFddbXHXyhrCv37nJAES xLb3g3ewQgPyyzMzZ86ckxAd1bYmtBfP+ERo302ubD0jRf3qLqvz+h353LAeq/NuVn5mWJ+19ebb /40lv5t8Zi/2dXUm3q48rzAdSx5/+7y5qGN1vj08rxf1rM67h5XnzEUDa2v5Wb1oYMnzD2/+er78 MLA6W6cP88/nRSMLIvbwfEV4gPVt+TteJElvyvzHHlgq5ZVL/7OzB1jyysPD+DAvbmz4b0wMy3Is yzbwb5q+81/8b7gBVgeEPQwUYZK8WKxFBZY2uYuHn/2Vr5XDz5djbppuCNGa/2/ypyvbIKsz+/Cw rC8fqQs3y7Omy9WNmLnZNJvNsVgshX9a8UyFbgsCY7qY/jl9j1jf3jzoysfeIsu76Mp0qQDfD7Yx B5ZOx8GSNls8zrGHgUaUOyz8DO0RSwZhWuKX9kxRqs2uNpsqSKUBToEl062Y2SaYCvZX4GHTxo9d +YjVIUHYW5z4q6YowyB3qbS21lxrNpvw1GwWCqkUprViMf9YwBSouV61bEn7dkNw7/1I22NWZ2Id QvYt5UZM5VIYu6jcmGo0BwapV3OP+b9mzNPNpj0QRXAqDEtRDfoyvJApNpB7+vt1YAhLHgcvTtbZ Suyzi2KFKMvUgFEsKkzIvQZbKxYFdiwD8pLxMCDRgcmXDG4LDf93HTmE1dl6C7CZj7TgargvK3+Q MjxKJBi8aMYrn9200G7Tl/a5VMtmS28L9hGTgEzBqo9Gte85chiriYU9/GOihTmyNA0hAoNQNQv4 ZXO6VCoIpkM6KnA32dScLdOotWzBbXRwXQ1/FITK09KGsMia61/AWt6qu0uplFnhrCmGU6NgTk1f CxupZuzQ1EBc0WYuokomDKKo2tHJUY1ffLJ4PWbFuDb1Hgv7FK02VRRgpsG0RDSTNN2E1Dc3459p JAS+sjVbOFxtXYtMLngyhkzeJxLyEetCaDMjc5D3Dw/vSbOCmlZICg0rM8ucu4lHdTo9F7PfRAUB hVvBy+0A10Zso4HajdjwfBxkVXjqGurPLOT9w/pKCVBYU0k1DUbStWYspgzpdKw0d4Pa0Yag5CtP Bc4C26wwvIwMsCpUYzU1F2+ZlfRYnyiZdagujHSz00q5ipnTOwGucYDaLs5qD56fWAUanqycMNSN RtbfPB1vxePpdPo1zvuH5dekqgpnPEkqsLXC2ioKm1MF89wlLSDWdP01LNANFDgJZ893qMBVznpV HqrMwLrga7F4Elhzc+Z5zHp4kyr1URqsWSixtJw6pA8EZiycTKVtczRXdfONS3v2JICsOWsuxwqx xwmiZ8UEJh23KaxWSk2Ph3EcJ1VVV1izQFaQiUVMMW2GymHLZDJ+tJMcYaiaLzgi1M6t1nyeYx9P NDoW2UAZm01lzW14JxQvPrwraTVDVlil6TWStNdcbfdFszkH9d4GLLuNpW326jYSPlYDQi4HLIdg ejSo+yyZdh3GAZaEcM3NtRbU9ID5RVEkg6kw+YJG3CLLrKUwClgAs40hXzhYzTFU4JVwDaypfIRa HMz8PuuwTafhrzRWLDVdxNUDbEXHIhWSnyQziEmleqzMV2GsGswenQR4Ttj2AWsqH+BXB0LWY11Q VAWfYdeHqcJXFx5kkPmzWJEiSy6YEFcpkVCnKgKbTCm6wIf2FsPZg9ls1r5z0D67wizHSwYNZH6X RTIuJm3vs2Ix80bjvRqy0wnMwbhF1PDLJeg6UqlCkkOH5jnoBDArWRSywPL5gjsuqujL56cc9w6x ZhTWZRUFNGbrsj6YF6CJIQNLk6oX3yow+Q8OFUlyrQnlN5WKFVI1nrab4wrLHhaKYYW1LTDUmU9h nbn+NsA0VgGZDip2jdV6vTIx8fo///n8z2/QwanKQNQdojdkaAhwqccNyEbzsIFMmZgNs2wcUwUf BnOIPqnxtdyU4/b2fjRqqPkqS65x2w34C+xDWzKdWV4/XQZbP1WdiJUtcOizTE7D9K+xNuZgeI1F Ue1VJh2v2twH1XP7ybXQyPmyAVfNCiyCQHd6YSprj7cGmDBmASweX1CLht5O/6FTslZ8FRdC7YXi m0qOsahRu9mpvOKvX21zFJPz5ay+ABXKA+o+ZCgfCktmmBbNgC5FGIxlm+Y7PW0F+0+bLbELAYWb xLnYKzcnRBFy8dCXFo9GclawABWYIsAO3DphCmuP32kxNHa7logL0NY/snelkjIva9FSukSchsm0 7av18yuGtebOgyNQNaBsWGuugIOIEB6ka0AwS4bSaWPoKjhRg32wqdXQaOMFmM8wCmRBtNSRDG63 Z+xhOwQse+Tzaax8fpS33EYi+8d3/eqBWXvo8qha4+AP+sKUyXLQJl/DTK2herKUjA8H7R/RTo8F Q3lqF+0TkUhI6JdFYMl3bDBbNXHhsAJTym9yQauGRtzyBHQ7Sr4r0VJcqLFOXqHrI1UWlA2Hw0Gg OhHZd6LFXsSAZY6ehbN2d0NjYVg83no9JD2gXs2bvQva/G9ABY/sjUAQs3CVB9btvZMaJTb3y4ye tYpGYBDuIKsCU9Ie5pUhea9onHxtVpYPBlXhYPCoyjDBETVc4EIYXfc1Soo4JdQrwaCrRtt9vmxQ 2Aa3KxFTi31LK1CDQVteWVhQFyp9D4aDR1l7jVV0YVnAgoS/30WbTiffcyLRIaPbENPsCRQZnReT 8Q8Tp0PSQ5WmqeoGC6Oy4cABDC5NFmZFIk5+CVhct9wTHb+Qs0Gn4v16WGo2vbD68cYzMS+e+SdW htv8BFlKJZNmrT/1Fppes/kke42U0ZW3LbRarQ+KjYxVCdGV0iJGdIqcbwHPun3bsDeNB4b8b9pm KxkOV32v0A7UJ2veazjuOG53qz0hc4FcTHbjtb368Mtpe0F/oPtG/5l1y2uYVcP7AvjBVuTqiA8R mDVVInvHGxfyfd3VncaIvWhxZEFm2z27kdPhgv5A/63eqwawMtMy6h1YxCzhLItbjRLJ94775YAo cl0frjamrAsyM8jSHRjKamaABcswze7kTG4k6s7ihC+R/eOHcsNVRlrpIPwHVmtML+PuJ3SxcjNj N+qyj/gO3NDV5B0lsq/XL3MuSfSrwggT47O2jLriwYLMDVHTPySoLL0uO9alsfS6aJdUv9FYdMiX bxl1xY/M8g3LMhw8GKbv/DZilCMccyMX7IO6crloADc190ZdjXa5TGusRiAHLEO8MAuWxvgH/pn6 ckxKR6ocV1gGXVZg5aBk3Orj5Zfpulg2aazomXVqQJctOOe/S8E6D5qpkkzrWWuFC/dNjDQX0uGw MV4nGstx6zXEi/DwS6yaHAQq5oFl0GU7OkK0LYiLYzgm1/SsuP3rDaz57TaonWsGXSdWK+jCldCY h4QkHjeUKnVBIGLqkS67SQjDl+FSHDPqitvt6bAbaCM2+5phfJ3kgWWFtpAwxouQlvio0ggsYpYj btSVHEFuexCzwuGUUdcH3ABV7e4DxHw0xus8bz0IWGHeIryG8UVIIVdD2WhcBZYDWLq6cSeba4Iv CAao4ICu2eoJPgNbGFo1v0HXeT6PtvG8FTHqikiSS1A3NQkUcdwmjbqyKGDPHik0YBni9Wb8T4AF g+fV8KukIV7nU1N8ceoWWNNGXR4LxWss6sxxO6CLEUZgPsoeHR0FjzaM8XrzMFk5CcI78AGvMV65 InJAajyOV0JEGstVmyIGdEVRLugDGOCyrQFdsIT+fILPJOvzGnRdB2j+7CzgqbF7uuOHMuFJ1Lus dhmzDPGCRbcVpmoFlx7UBZsDv/2JVyS+gkEXLVKUANsqYn3POL4kYKkNKUEd30YGdF3mBAGUYZjv sS5YSPz7zyuFpa8bV1PcbsRZ3CegRunrIehaiqpdACG4nIO6qr4RUIZhPt8QXdBxjPuufCPGeH3J R0chWETEOVA3pESvbjDtEFE15qHd6oMNimvorjDLmIdauzP5+QvM5lHd/JUlUOAWms99YBl0SVLd pPbZBO2qR6rGeEFp811x/Fh4xDdi1EXCNRDVln/7op9haXnhTG3gnffyhat3DhekU0rsduv8HeKl AV1Q2qwjVzQVgJ45btSV+b0LW//9g24KcO3Jl8ebkf1N571XDvRQVKxkgdzozl8X4nH9g1EXlBuw KzdFj/iSxjy0+37vLSrGZX+/LHMl2XwCDXZSlg/7R1n5gyRJQndeXo2GqJfGeJ1PKTDfNTrYWTDq Osl9+a0LO93SJXdbOFRbtT1T34Ntt/xSkjy8tl1EeBsewW3UdTSVh9Va3urLc/yiUdc5bGx1F+wP 72S3vlMQaPeNiaV0hxBJWiRLudHto+TarmdsoB5CrcG4fC5XCxh1wb6W9cu1toRZ3vpBa7cof5Gk hKilBtwPsHjg/NOoK3vrwDRFXcao6wifgnVHW1aMy3t6GYPtkEk2Q2Z4+n0vrCo9A3noA5ZKm5qy GXVdYdZU3jGjpuOKvNd4quFyuWUSJpTEMdVdMsOaiC1XZd1f3Mg5AqYGjAOrGnVlMR/OI6+m4zps DtzoGi0dl1mVSwSgRttMd0MFWHfoBPbzXJRmd8AiMO1eZZl678CZ+rRTcNz/W10xjX+TS4cMr8s9 4LngQo4s2zYh3yW+vailBr5/Y4F/aVyI5CIqDMTdVgfegm0mxz2cB3F/84sCO53fgo9c3MEFxihY g6Pdfmj55A8OTAIP9ncdgFXiAt4F8/mqF+94XeyZzS8jGIbtlvgC6zFYX8FP0r/aJHPKKeBFI3F/ rVwxgLI/OT8xsGqyvYRIKShUp3ubDnjPoYKkhHOU8mw6N51iiNjfj4BpNFUflkiM8mItMgWlXDH4 xMeZ7rBef/tmfP5PvLqrfsk59hMKSEpIx7wHaUUD11745xXKiYSlzktOZ0IMRTY3N/dVXg+oaHRE aJ5fOru9h3KumaZM1ffLC6gR8OiaJcQjqXzQ32pT9oiu+YSUSIh8ArP2nU4dzcC7j3gOqIOQhbgn 4Fy2X3zqFmL1ef2TqQeSLNKuqy4l+DHjvk2nhEYBJomiJYEwC8M290FdRJXXM4jSWRnxx6HEvntm yNJ9/X1A9V5CWqL4kCVR1m3bqPcRyXe84l5elMSQ02IBmsrDzhywyH1E4tCvv/TKvVHb6UwAohWq U/wofGEC6mk347v3LJEQMYB5EEKYBTQdr89U2E73zLCNsR7ydIYTqeMQ1mYpi/pNem1fdJGCs8Bu bIeckCeqKfIMtul+8f4pRX1967/WLGoq8od9Vb17sWS2blHdSIGXe7RB3OZMd1PW6LmB/52+wF8G EzI3ZL8XFixUCJ8KjHNqFE4K47ryFI8qD0C/eGozRyfrPQ4ZLoW88Uppd89cDuD0gMmmXKZ2sT8x TidQc6vFeWYYU4/lrb9/AZFSfeQ2XuXoXXcoNbAXLfW6M0SJCgx/XAWqTOUZjvSqxRA/rr83aUUD XNQYuHrTv56yR5Vhwt49hnQU+VHF4X1TOZqZ1Kr72E5nXvQ+ZCnz3X0oXZ3XXsp+CBlkKZazhIe8 kaYHS8Ok/fIealTPLCHKkINKL9pPStnNe6CGeQBi8fAg7WmaNFCe1j/NvDCcXMLDBx5djNVf1yvR IIpX81HapeqeAUcapRkS8sXgiVH9qaSnxnC90sscW8QlLS9CIrX0PUcGDAk5Y4iuhJghl+oNLNhm FpdETU0iMUqhMtTrp8zyj74mflKrrpq+Yq/HGFI3uoe8LE/1ZiBcrGEGeCJsliVqVF/rT7s5CAOL /onryx25wLSXnP1s8uxSYhmX0UFLJJZcoUTCpMvIddWPCQ81VJUhD1VtJRoqYt8dFs8STMaewdAn ErsUzHlgpvd9T/4CAxkyufbEnQ7GeCmwOxe0BH0d4EkEc4RuLCudBNXN0oSpnySnM9Iu737qDo7H rA5cqT42pLtFCh1T/G5IgjKlnAMefngYdnNBp+1f/zwawsNzvnv0ghlIiYTFUz7m0e4o4CB6owNl JSEFtMuo0C++e/JG0CG6sB/HQJoxIyyAE3lK3PV46lTZiSVq5VwpzFLtk3Y5+mF54gnacBbMZzS/ OzC2EpAyoSWx7WqjpdFRDx4aUPyhT/OEynVRpFy/vtFm0smJoXdMPsXqkH4WT2TGbE9YQsd8ubwr QmPCg4miCL8RL9Z3RZ67ImfHVdryUEc+yerIXriku+TBaro5kPAc4yqJ1XhATWh0aakcCoHC0K7I LpbkDklOvFtWxgC0+fqSobx+moUb4kNOEKH3wurgF2RjP4raPIpDNSqKjL9XKbZmJ5WyvDw7SPsu C2h/wybo7ijExgOjrA6jTDfwICckz2idj5r29KOX/LaliHv7ZpY0zCs/YIE4smKKHoh8G6IH3Y2u J5BC5WPxIGq6GHILCojDTeTkrP5+8h+zAGdeLdKsyIvHu+XyaAjiVF7aPYaMYN03F0/dVLa1Na/c FzdruDb6KIbDDsDNKYdwxyjNNKLRA5ZmTHeHF96S/L175Uhyax5GQX8A/JSunzqboR/agrx8Oz6h evKZWZ3OX3/Nji+Pz/4FWfLsLCwIMmUesuT/wgJ1W7Ozf/0XvHEVdKRHia0AAAAASUVORK5CYIJ5 ABYkARckAUlmAQAAAAGWAAAhdgADaAE11gUAAQOJBTXWBQECAykUNdYFAgMDEQ0jdgABiQUjdgEC KRQjdgIDEQ06VgsAApY5AAM0ART2A8MmK9YCAAM11gUAAQOJBTXWBQECAykUNdYFAgMDEQ001gYA AQoDOQBmNAGCABYkARckAUlmAQAAAAGWAAAhdgADaAE11gUAAQOJBTXWBQECA8gPNdYFAgMDchEj dgABiQUjdgECyA8jdgIDchE6VgsAApY5AAM0AQeUYwEU9gPDJivWAgABK9YCAQM11gUAAQOJBTXW BQECA8gPNdYFAgMDchE01gYAAQoDOQBmNAGWABYkARckAUlmAQAAAAGWAAAhdgADaAE11gUAAQOJ BTXWBQECA8gPNdYFAgMDchEjdgABiQUjdgECyA8jdgIDchE6VgsAApY5AAM0AQeUDAMU9gPDJivW AgABK9YCAQEs1gMCAwE11gUAAQOJBTXWBQECA8gPNdYFAgMDchEv1gsAAwQAAAD/DAEAADTWBgAB CgM5AGY0AXgAFiQBFyQBSWYBAAAAAZYAACF2AANoATXWBQABA1EGNdYFAQIDIA011gUCAwNSEyN2 AAFRBiN2AQIgDSN2AgNSEzpWCwACljkAAzQBB5RlART2A8MmNdYFAAEDUQY11gUBAgMgDTXWBQID A1ITNNYGAAEKAzkAZjQBTAAWJAEXJAFJZgEAAAABlgAAIXYAAWgBNdYFAAEDwyYjdgABwyY6VgsA ApY5AAM0AQeUZQEU9gPDJjXWBQABA8MmNNYGAAEKAzkAZjQBYgAWJAEXJAFJZgEAAAABlgAAIXYA AmgBNdYFAAEDUQY11gUBAgNyICN2AAFRBiN2AQJyIDpWCwACljkAAzQBB5RlART2A8MmNdYFAAED UQY11gUBAgNyIDTWBgABCgM5AGY0AXAAFiQBFyQBSWYBAAAAAZYAACF2AAJoATXWBQABA1EGNdYF AQIDciAjdgABUQYjdgECciA6VgsAApY5AAM0AQeUZQEU9gPDJjXWBQABA1EGNdYFAQIDciAv1gsA AgQAAAD/DAEAADTWBgABCgM5AGY0AZ4AFiQBFyQBSWYBAAAAAZYAACF2AANoATXWBQABA1EGNdYF AQIDKhE11gUCAwNIDyN2AAFRBiN2AQIqESN2AgNIDzpWCwACljkAAzQBB5TMABT2A8MmGPYDAAA1 1gUAAQNRBjXWBQECAyoRNdYFAgMDSA8v1gsAAwEAAAD/DAEAADTWBgABBQAAADTWBgABCgM5AGY0 AXl03Ro9AIpUAQCeABYkARckAUlmAQAAAAGWAAAhdgADaAE11gUAAQNRBjXWBQECAyoRNdYFAgMD SA8jdgABUQYjdgECKhEjdgIDSA86VgsAApY5AAM0AQeUzAAU9gPDJhj2AwAANdYFAAEDUQY11gUB AgMqETXWBQIDA0gPL9YLAAMBAAAA/wwBAAA01gYAAQUAAAA01gYAAQoDOQBmNAF5dN0aPQCKVAEA ZQAWJAEXJAFJZgEAAAABljMAIXYAAWgBNdYFAAEDwyYjdgABwyY6VgsAApZsAAM0ART2A8MmGPYD AAA11gUAAQPDJi/WCwABDwAAAP8EAQAAMtYGAAEKAzkAZjQBeXTdGj0AilQBAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAYgRuABIAAQALAQ8ABwAAAAMAAAAAAAQACAAAAAgAAAAIAAAACAAAAAgAAAAI AAAACAAAAAgAAAAIAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAgAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMgYAABgAAADAAwAA0AMAAOADAADwAwAA AAQAABAEAAAgBAAAMAQAAEAEAABQBAAAYAQAAHAEAACABAAAkAQAAMADAADQAwAA4AMAAPADAAAA BAAAEAQAADIGAAAoAgAA2AEAAOgBAAAgBAAAMAQAAEAEAABQBAAAYAQAAHAEAACABAAAkAQAAMAD AADQAwAA4AMAAPADAAAABAAAEAQAACAEAAAwBAAAQAQAAFAEAABgBAAAcAQAAIAEAACQBAAAwAMA ANADAADgAwAA8AMAAAAEAAAQBAAAIAQAADAEAABABAAAUAQAAGAEAABwBAAAgAQAAJAEAADAAwAA 0AMAAOADAADwAwAAAAQAABAEAAAgBAAAMAQAAEAEAABQBAAAYAQAAHAEAACABAAAkAQAAMADAADQ AwAA4AMAAPADAAAABAAAEAQAACAEAAAwBAAAQAQAAFAEAABgBAAAcAQAAIAEAACQBAAAwAMAANAD AADgAwAA8AMAAAAEAAAQBAAAIAQAADAEAABABAAAUAQAAGAEAABwBAAAgAQAAJAEAAA4AQAAWAEA APgBAAAIAgAAGAIAAFYCAAB+AgAAGAAAAFBKAwBfSAEEbUgJBG5IBAhzSAkEdEgECAAAAABiAABg 8f8CAGIADBAAAAAAAAAAAAYATgBvAHIAbQBhAGwAAAAnAAAADcYOAAQaA6cENAbBB8DAwMATpHgA NSQANyQAOCQAOUQCAEgkAAAUAENKGABfSAEEbUgJCHNICQh0SAkEUAABQAEAAgBQAAwQbQAAAAAA AAAJAEgAZQBhAGQAaQBuAGcAIAAxAAAAHwABAAUkAQYkAQ+EGgMRhOb8E6RoAUAmAF6EGgNghOb8 AAMANQiBADYAAgARAAIANgAMEAAAAAAAAAAACQBIAGUAYQBkAGkAbgBnACAAMgAAAAkAAgATpPAA QCYBAAAANgADABEAAgA2AAwQAAAAAAAAAAAJAEgAZQBhAGQAaQBuAGcAIAAzAAAACQADABOkoABA JgIAAABMAAQAMQACAEwADBAAAAAAAAAAAAkASABlAGEAZABpAG4AZwAgADQAAAAfAAQADcYHARoD Af0DwA+E/QMRhAP8QCYDXoT9A2CEA/wAAAAyAAUAQQACADIADBAAAAAAAAAAAAkASABlAGEAZABp AG4AZwAgADUAAAAFAAUAQCYEAAAASgAGAEEAAgBKAAwQAAAAAAAAAAAJAEgAZQBhAGQAaQBuAGcA IAA2AAAAHgAGAA3GBgL9A6cEAA+ENAYRhMz5QCYFXoQ0BmCEzPkAADIABwBhAAIAMgAMEAAAAAAA AAAACQBIAGUAYQBkAGkAbgBnACAANwAAAAUABwBAJgYAAAAyAAgAYQACADIADBAAAAAAAAAAAAkA SABlAGEAZABpAG4AZwAgADgAAAAFAAgAQCYHAAAAMgAJAGEAAgAyAAwQAAAAAAAAAAAJAEgAZQBh AGQAaQBuAGcAIAA5AAAABQAJAEAmCAAAAEQAQSDy/6EARAAMAQAAAAAAAAAAFgBEAGUAZgBhAHUA bAB0ACAAUABhAHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAABWAGlA8/+zAFYADAUAAAAAAAAA AAwAVABhAGIAbABlACAATgBvAHIAbQBhAGwAAAAgADpWCwAX9gMAADTWBgABBQMAADTWBgABCgNs AGH2AwAAAgALAAAAKABrIPT/wQAoAAAFAAAAAAAAAAAHAE4AbwAgAEwAaQBzAHQAAAACAAwAAAAA AFQA/g8BAAIAVAAMAAAAAAAAAAAAEABBAG4AbgBlAHgAXwBOAG8AIAAmACAAdABpAHQAbABlAAAA EgAPAAMkAQUkAQYkAROk4AFhJAEHADUIgUNKHAAANgD+D6IAAQE2AAwAAAAAAAAAAAAHAEEAcABw AF8AZABlAGYAAAAPADUIgU9KAABRSgAAa0jkBAAmAP4PogARASYADAAAAAAAAAAAAAcAQQBwAHAA XwByAGUAZgAAAAAAQgD+D/EAAgBCAAwAAAAAAAAAAAATAEEAcABwAGUAbgBkAGkAeABfAE4AbwAg ACYAIAB0AGkAdABsAGUAAAACABIAAAA2AP4PogAxATYADAAAAAAAAAAAAAcAQQByAHQAXwBkAGUA ZgAAAA8ANQiBT0oAAFFKAABrSOQEAEQA/g8BAAIARAAMAAAAAAAAAAAACwBBAHIAdABfAGgAZQBh AGQAaQBuAGcAAAAMABQAAyQBE6TgAWEkAQcANQiBQ0ocAABAAP4PAQACAEAADAAAAAAAAAAAAAYA QQByAHQAXwBOAG8AAAASABUAAyQBBSQBBiQBE6TgAWEkAQcAOwiBQ0ocAAAmAP4PogBhASYADAAA AAAAAAAAAAcAQQByAHQAXwByAGUAZgAAAAAARgD+DwEAAgBGAAwAAAAAAAAAAAAJAEEAcgB0AF8A dABpAHQAbABlAAAAEgAXAAMkAQUkAQYkAROk8ABhJAEHADUIgUNKHAAAcAD+DwEAggFwAAQAAAAA AAAAAAAFAEEAUwBOAC4AMQAAADEAGAANxigEGgOnBDQGwQcKNwJuBKUG3AgTC0oNgQ+4Ee8TJhYA AAAAAAAAAAAAE6QAAAAaADUIgUNKFABPSgQAUUoEAG1IAARuSAAEdQgBOgD+DwEAAgA6AAwAAAAA AAAAAAAEAEMAYQBsAGwAAAAUABkABSQBBiQBD4QaAxOkoABehBoDAwA2CIEAVgD+DwEAAgBWAAwA AAAAAAAAAAAHAEMAaABhAHAAXwBOAG8AAAAjABoAAyQBBSQBBiQBDcYOAAQaA6cENAbBBwAAAAAT pOABYSQBAAoANQiBOwiBQ0ocAEgA/g8BAAIASAAMAAAAAAAAAAAACgBDAGgAYQBwAF8AdABpAHQA bABlAAAAEgAbAAMkAQUkAQYkAROk8ABhJAEHADUIgUNKHAAAPgAqAKIAwQE+AAwBAAAAAAAAAAAR AEUAbgBkAG4AbwB0AGUAIABSAGUAZgBlAHIAZQBuAGMAZQAAAAMASCoBAEAA/g8BANIBQAAMAAAA AAAAAAAACABlAG4AdQBtAGwAZQB2ADEAAAAWAB0AD4QaAxGE5vwTpFAAXoQaA2CE5vwAADwA/g/R AeIBPAAMAAAAAAAAAAAACABlAG4AdQBtAGwAZQB2ADIAAAASAB4AD4SnBBGEc/5ehKcEYIRz/gAA NAD+D+EB8gE0AAwAAAAAAAAAAAAIAGUAbgB1AG0AbABlAHYAMwAAAAoAHwAPhDQGXoQ0BgAAPgD+ DwEAAgI+AAwAAAAAAAAAAAAIAEUAcQB1AGEAdABpAG8AbgAAABMAIAANxg4DpwQ0BsEHAtQSpyXB wgAAAFwA/g8BABICXAAMAAAAAAAAAAAADwBFAHEAdQBhAHQAaQBvAG4AXwBsAGUAZwBlAG4AZAAA ACQAIQANxgsDGgOnBDQGARYHwg+EwQcRhD/4E6RQAF6EwQdghD/4AAA8AP4PAQACADwADAAAAAAA AAAAAAYARgBpAGcAdQByAGUAAAAWACIAAyQBBSQBBiQBE6TwABSkeABhJAEAAFYA/g8BADICVgAM AAAAAAAAAAAADQBGAGkAZwB1AHIAZQBfAGwAZQBnAGUAbgBkAAAAHQAjAAUkAQYkAQ3GCgQaA6cE NAbBBwATpBQAFKQUAAAEAENKEgBUAP4PAQACAFQADAAAAAAAAAAAABEARgBpAGcAdQByAGUAXwBO AG8AIAAmACAAdABpAHQAbABlAAAAEwAkAAMkAQUkAROk8AAUpHgAYSQBAAMANQiBAEwA/g8BAAIA TAAMAAAAAAAAAAAADABGAGkAZwB1AHIAZQBfAE4AbwBfAEIAUgAAABYAJQADJAEFJAEGJAETpOAB FKR4AGEkAQMAOwiBAFAA/g8BAAIAUAAMAAAAAAAAAAAADgBUAGEAYgBsAGUAXwB0AGkAdABsAGUA XwBCAFIAAAAWACYAAyQBBSQBBiQBE6QAABSkeABhJAEDADUIgQBCAP4PYQICAEIADAAAAAAAAAAA AA8ARgBpAGcAdQByAGUAXwB0AGkAdABsAGUAXwBCAFIAAAAJACcABiQAFKTgAQAAAFYA/g8BAAIA VgAMAAAAAAAAAAAAFABGAGkAZwB1AHIAZQBfAHcAaQB0AGgAbwB1AHQAXwB0AGkAdABsAGUAAAAT ACgAAyQBBSQBE6TwABSkeABhJAEAAABSACBAAQCSAlIABAAAAAAAAAAAAAYARgBvAG8AdABlAHIA AAAZACkADcYQBBoDpwQ0BsEHAkIXpyUAAhOkAAAAEgA7CIFDShAAbUgABG5IAAR1CAFWAP4PkQKi AlYADAAAAAAAAAAAAAsARgBpAHIAcwB0AEYAbwBvAHQAZQByAAAAHwAqAA3GBgJCF6clABOkKAA1 JAE3JAE4JAE5RAQASCQBAAYAOwiBdQgAUAD+DwEAsgJQAAwAAAAAAAAAAAAJAEYAbwBvAHQAZQBy AF8AUQBQAAAAHAArAA3GEwQaA6cENAbBBwOLA1UipyXAwsITpAAABwA1CIFDShYAAEQAJgCiAMEC RAAMAQAAAAAAAAAAEgBGAG8AbwB0AG4AbwB0AGUAIABSAGUAZgBlAHIAZQBuAGMAZQAAAAgAQ0oS AEVIBgA6AP4PAQDSAjoADAAAAAAAAAAAAAQATgBvAHQAZQAAABcALQANxg4ABBoDpwQ0BsEHAAAA ABOkUAAAAABSAB0A0QLiAlIADAEAAAAAAAAAAA0ARgBvAG8AdABuAG8AdABlACAAVABlAHgAdAAA AB0ALgAFJAENxgUAAf8AAA+E/wARhAH/XoT/AGCEAf8AAABQAP4PgQHyAlAABAAAAAAAAAAAAAYA RgBvAHIAbQBhAGwAAAAlAC8ADcYgAAo3Am4EpQbcCBMLSg2BD7gR7xMmFsDAwMDAwMDAwMAAAwA1 CIEARAAfQAEAAgNEAAwAAAAAAAAAAAAGAEgAZQBhAGQAZQByAAAAGQAwAAMkAQ3GCgQaA6cENAbB BwATpAAAYSQBAAQAQ0oSADoA/g8BAAIAOgAMAAAAAAAAAAAACQBIAGUAYQBkAGkAbgBnAF8AYgAA AAkAMQAGJAETpKAAAAMANQiBADoA/g8BAAIAOgAMAAAAAAAAAAAACQBIAGUAYQBkAGkAbgBnAF8A aQAAAAkAMgAGJAETpKAAAAMANgiBACoACgABAAIAKgAMAQAAAAAAAAAABwBJAG4AZABlAHgAIAAx AAAAAgAzAAAAMgALAAEAAgAyAAwBAAAAAAAAAAAHAEkAbgBkAGUAeAAgADIAAAAKADQAD4QbAV6E GwEAADIADAABAAIAMgAMAQAAAAAAAAAABwBJAG4AZABlAHgAIAAzAAAACgA1AA+ENgJehDYCAABE AP4PAQACAEQADAAAAAAAAAAAABIATgBvAHIAbQBhAGwAXwBhAGYAdABlAHIAXwB0AGkAdABsAGUA AAAGADYAE6RoAQAALgApAKIAcQMuAAwAAAAAAAAAAAALAFAAYQBnAGUAIABOAHUAbQBiAGUAcgAA AAAARgD+DwEAAgBGAAwAAAAAAAAAAAAHAFAAYQByAHQAXwBOAG8AAAAWADgAAyQBBSQBBiQBE6Tg ARSkUABhJAEHADsIgUNKHAAAPAD+DwEAAgA8AAwAAAAAAAAAAAAIAFAAYQByAHQAXwByAGUAZgAA ABIAOQADJAEFJAEGJAETpBgBYSQBAABMAP4PAQBiA0wADAAAAAAAAAAAAAoAUABhAHIAdABfAHQA aQB0AGwAZQAAABYAOgADJAEFJAEGJAETpPAAFKQYAWEkAQcANQiBQ0ocAABOAP4PAQBiA04ADAAA AAAAAAAAAAgAUgBlAGMAXwBkAGEAdABlAAAAGwA7AAMkAgUkAQYkAQ3GCgQaA6cENAbBBwBhJAIA BwA2CIFDShYAADYA/g+xA2IDNgAMAAAAAAAAAAAADQBRAHUAZQBzAHQAaQBvAG4AXwBkAGEAdABl AAAAAgA8AAAAOgD+DwEAAgA6AAwAAAAAAAAAAAAGAFIAZQBjAF8ATgBvAAAADAA9AAUkAQYkAROk AAAHADUIgUNKHAAAMgD+D9EDAgAyAAwAAAAAAAAAAAALAFEAdQBlAHMAdABpAG8AbgBfAE4AbwAA AAIAPgAAAEYA/g8BAAIARgAMAAAAAAAAAAAACQBSAGUAYwBfAE4AbwBfAEIAUgAAABIAPwADJAEF JAEGJAETpOABYSQBBwA7CIFDShwAADgA/g/xAwIAOAAMAAAAAAAAAAAADgBRAHUAZQBzAHQAaQBv AG4AXwBOAG8AXwBCAFIAAAACAEAAAABIAP4PAQCyA0gADAAAAAAAAAAAAAcAUgBlAGMAXwByAGUA ZgAAABsAQQADJAEFJAEGJAENxgoEGgOnBDQGwQcAYSQBAAMANgiBADQA/g8RBMIDNAAMAAAAAAAA AAAADABRAHUAZQBzAHQAaQBvAG4AXwByAGUAZgAAAAIAQgAAAEYA/g8BAGIDRgAMAAAAAAAAAAAA CQBSAGUAYwBfAHQAaQB0AGwAZQAAABIAQwADJAEFJAEGJAETpGgBYSQBBwA1CIFDShwAADgA/g8x BCIEOAAMAAAAAAAAAAAADgBRAHUAZQBzAHQAaQBvAG4AXwB0AGkAdABsAGUAAAACAEQAAAAqAP4P ogBRBCoADAAAAAAAAAAAAAcAUgBlAGMAXwBkAGUAZgAAAAMANQiBADwA/g8BAGIEPAAMAAAAAAAA AAAACABSAGUAZgBfAHQAZQB4AHQAAAASAEYAD4QaAxGE5vxehBoDYITm/AAAPAD+DwEAYgQ8AAwA AAAAAAAAAAAJAFIAZQBmAF8AdABpAHQAbABlAAAADABHAAMkAROk4AFhJAEDADUIgQAsAP4PsQNi AywADAAAAAAAAAAAAAgAUgBlAHAAXwBkAGEAdABlAAAAAgBIAAAAKAD+D9EDAgAoAAwAAAAAAAAA AAAGAFIAZQBwAF8ATgBvAAAAAgBJAAAALgD+D/EDAgAuAAwAAAAAAAAAAAAJAFIAZQBwAF8ATgBv AF8AQgBSAAAAAgBKAAAAKgD+DxEEggQqAAwAAAAAAAAAAAAHAFIAZQBwAF8AcgBlAGYAAAACAEsA AAAuAP4PMQSyBC4ADAAAAAAAAAAAAAkAUgBlAHAAXwB0AGkAdABsAGUAAAACAEwAAAAsAP4PsQNi AywADAAAAAAAAAAAAAgAUgBlAHMAXwBkAGEAdABlAAAAAgBNAAAANgD+D6IA4QQ2AAwAAAAAAAAA AAAHAFIAZQBzAF8AZABlAGYAAAAPADUIgU9KAABRSgAAa0jkBAAoAP4P0QMCACgADAAAAAAAAAAA AAYAUgBlAHMAXwBOAG8AAAACAE8AAAAuAP4P8QMCAC4ADAAAAAAAAAAAAAkAUgBlAHMAXwBOAG8A XwBCAFIAAAACAFAAAAAqAP4PEQTSBCoADAAAAAAAAAAAAAcAUgBlAHMAXwByAGUAZgAAAAIAUQAA AC4A/g8xBBIFLgAMAAAAAAAAAAAACQBSAGUAcwBfAHQAaQB0AGwAZQAAAAIAUgAAAEoA/g8BAAIA SgAMAAAAAAAAAAAACQBTAGUAYwB0AGkAbwBuAF8AMQAAABkAUwADJAENxgoEGgOnBDQGwQcAE6Rw AmEkAQADADUIgQBKAP4PAQACAEoADAAAAAAAAAAAAAkAUwBlAGMAdABpAG8AbgBfADIAAAAZAFQA AyQBDcYKBBoDpwQ0BsEHABOk8ABhJAEAAwA2CIEATAD+DwEAAgBMAAwAAAAAAAAAAAAKAFMAZQBj AHQAaQBvAG4AXwBOAG8AAAAWAFUAAyQBBSQBBiQBE6TgARSkUABhJAEHADsIgUNKHAAAUgD+DwEA YgNSAAwAAAAAAAAAAAANAFMAZQBjAHQAaQBvAG4AXwB0AGkAdABsAGUAAAAWAFYAAyQBBSQBBiQB E6TgARSkGAFhJAEHADUIgUNKHAAAPgD+DwEAYgM+AAwAAAAAAAAAAAAGAFMAbwB1AHIAYwBlAAAA EABXAAMkAROkSAMUpMgAYSQBBwA1CIFDShwAAFgA/g+RAoIFWAAMAAAAAAAAAAAADgBTAHAAZQBj AGkAYQBsACAARgBvAG8AdABlAHIAAAAcAFgAAyQDDcYRAAU3Am4EpQbcCBMLwMDAwMBhJAMGADsI gXUIADgA/g+iAJEFOAAMAAAAAAAAAAAACgBUAGEAYgBsAGUAXwBmAHIAZQBxAAAADAA1CIFCKgBw aAAAAP98AP4PAQACAHwADAAAAAAAAAAAAAoAVABhAGIAbABlAF8AaABlAGEAZAAAAEUAWgADJAEG JAENxi8DGgOnBDQGDRwBNwJTA24EigWlBtwI+AkTCy8MSg1mDoEPwMDAwMDAwMDAwMDAwBOkUAAU pFAAYSQBAAcANQiBQ0oWAABuAP4PAQCyBW4ADAAAAAAAAAAAAAwAVABhAGIAbABlAF8AbABlAGcA ZQBuAGQAAAA4AFsADcYvAxoDpwQ0Bg0cATcCUwNuBIoFpQbcCPgJEwsvDEoNZg6BD8DAwMDAwMDA wMDAwMAUpCgABABDShYAVAD+DwEAogVUAAwAAAAAAAAAAAAQAFQAYQBiAGwAZQBfAE4AbwAgACYA IAB0AGkAdABsAGUAAAAWAFwAAyQBBSQBBiQBE6RoARSkeABhJAEDADUIgQBIAP4PAQBiAkgADAAA AAAAAAAAAAsAVABhAGIAbABlAF8ATgBvAF8AQgBSAAAAEwBdAAMkAQYkAROkMAIUpHgAYSQBAAMA OwiBAEAA/g8BAGICQAAMAAAAAAAAAAAACQBUAGEAYgBsAGUAXwByAGUAZgAAABMAXgADJAEGJAET pAAAFKR4AGEkAQAAAHIA/g8BAPIFcgAMAAAAAAAAAAAACgBUAGEAYgBsAGUAXwB0AGUAeAB0AAAA PwBfAA3GMgMaA6cENAYOHAE3AlMDbgSKBaUGwQfcCPgJEwsvDEoNZg6BD0BAQEBAQEBAQEBAQEBA E6QoABSkKAAABABDShYAVAD+D3EFAgBUAAwAAAAAAAAAAAAHAFQAaQB0AGwAZQAgADEAAAAmAGAA DcYZBBoDpwQ0BsEHBTcCbgSlBtwIEwvAwMDAwBOk8AAUpAAABgA1CIE7CIEqAP4PAQYCACoADAAA AAAAAAAAAAcAVABpAHQAbABlACAAMgAAAAIAYQAAAC4A/g8RBgIALgAMAAAAAAAAAAAABwBUAGkA dABsAGUAIAAzAAAAAgBiAAMAOwiBAC4A/g8hBhIALgAMAAAAAAAAAAAABwBUAGkAdABsAGUAIAA0 AAAAAgBjAAMANQiBADoA/g8BAFIGOgAMAAAAAAAAAAAABQB0AG8AYwAgADAAAAASAGQADcYNBBoD pwQ0BsEHAaclAgMANQiBAFwAEwABAFIGXAAMAQAAAAAAAAAABQBUAE8AQwAgADEAAAA3AGUABSQB DcYTBBoDpwQ0BsEHA8QDVSKnJQAIAg6EUwMPhKgCEYRY/ROk8ABdhFMDXoSoAmCEWP0AAAA6ABQA UQZiBjoADAEAAAAAAAAAAAUAVABPAEMAIAAyAAAAFgBmAA+E+wURhK38E6RQAF6E+wVghK38AAAm ABUAYQZyBiYADAEAAAAAAAAAAAUAVABPAEMAIAAzAAAAAgBnAAAAJgAWAHEGggYmAAwBAAAAAAAA AAAFAFQATwBDACAANAAAAAIAaAAAACYAFwCBBpIGJgAMAQAAAAAAAAAABQBUAE8AQwAgADUAAAAC AGkAAAAmABgAgQaiBiYADAEAAAAAAAAAAAUAVABPAEMAIAA2AAAAAgBqAAAAJgAZAIEGsgYmAAwB AAAAAAAAAAAFAFQATwBDACAANwAAAAIAawAAACYAGgCBBsIGJgAMAQAAAAAAAAAABQBUAE8AQwAg ADgAAAACAGwAAABIAP4PogDRBkgADAABADojAQAAAA4ASABlAGEAZABpAG4AZwAgADEAIABDAGgA YQByAAAAEwA1CAFDShgAbUgJCHNICQh0SAkEAFBLAwQUAAYACAAAACEAgoq8E/oAAAAcAgAAEwAA AFtDb250ZW50X1R5cGVzXS54bWyskctqwzAQRfeF/oPQtthyuiil2M6iSXd9LNIPGOSxLWqPhDQJ yd937LhQuggtdCMQYs6Ze1Wuj+OgDhiT81TpVV5ohWR946ir9PvuKbvXKjFQA4MnrPQJk17X11fl 7hQwKZmmVOmeOTwYk2yPI6TcByR5aX0cgeUaOxPAfkCH5rYo7oz1xEic8cTQdfkqC0TXoHqDyC8w isewoPD7+QwkgJgLWKvHM2FaotIQwuAssEQwB2p+6DPfts5i4+1+FGk+gxfYzQQzv1xg9T/qL+cG W9gPrLZH6eJcf8Qh/S3bUmsuk3P+1LuQLhgul7e0Yea/rT8BAAD//wMAUEsDBBQABgAIAAAAIQCl 1qfnwAAAADYBAAALAAAAX3JlbHMvLnJlbHOEj89qwzAMh++FvYPRfVHSwxgldi+lkEMvo30A4Sh/ aCIb2xvr20/HBgq7CISk7/epPf6ui/nhlOcgFpqqBsPiQz/LaOF2Pb9/gsmFpKclCFt4cIaje9u1 X7xQ0aM8zTEbpUi2MJUSD4jZT7xSrkJk0ckQ0kpF2zRiJH+nkXFf1x+YnhngNkzT9RZS1zdgro+o yf+zwzDMnk/Bf68s5UUEbjeUTGnkYqGoL+NTvZCoZarUHtC1uPnW/QEAAP//AwBQSwMEFAAGAAgA AAAhAGt5lhaDAAAAigAAABwAAAB0aGVtZS90aGVtZS90aGVtZU1hbmFnZXIueG1sDMxNCsMgEEDh faF3kNk3Y7soRWKyy6679gBDnBpBx6DSn9vX5eODN87fFNWbSw1ZLJwHDYplzS6It/B8LKcbqNpI HMUsbOHHFebpeBjJtI0T30nIc1F9I9WQha213SDWtSvVIe8s3V65JGo9i0dX6NP3KeJF6ysmCgI4 /QEAAP//AwBQSwMEFAAGAAgAAAAhAJa1reKWBgAAUBsAABYAAAB0aGVtZS90aGVtZS90aGVtZTEu eG1s7FlPb9s2FL8P2HcgdG9jJ3YaB3WK2LGbLU0bxG6HHmmJlthQokDSSX0b2uOAAcO6YYcV2G2H YVuBFtil+zTZOmwd0K+wR1KSxVhekjbYiq0+JBL54/v/Hh+pq9fuxwwdEiEpT9pe/XLNQyTxeUCT sO3dHvYvrXlIKpwEmPGEtL0pkd61jfffu4rXVURigmB9Itdx24uUSteXlqQPw1he5ilJYG7MRYwV vIpwKRD4COjGbGm5VltdijFNPJTgGMjeGo+pT9BQk/Q2cuI9Bq+JknrAZ2KgSRNnhcEGB3WNkFPZ ZQIdYtb2gE/Aj4bkvvIQw1LBRNurmZ+3tHF1Ca9ni5hasLa0rm9+2bpsQXCwbHiKcFQwrfcbrStb BX0DYGoe1+v1ur16Qc8AsO+DplaWMs1Gf63eyWmWQPZxnna31qw1XHyJ/sqczK1Op9NsZbJYogZk Hxtz+LXaamNz2cEbkMU35/CNzma3u+rgDcjiV+fw/Sut1YaLN6CI0eRgDq0d2u9n1AvImLPtSvga wNdqGXyGgmgookuzGPNELYq1GN/jog8ADWRY0QSpaUrG2Ico7uJ4JCjWDPA6waUZO+TLuSHNC0lf 0FS1vQ9TDBkxo/fq+fevnj9Fxw+eHT/46fjhw+MHP1pCzqptnITlVS+//ezPxx+jP55+8/LRF9V4 Wcb/+sMnv/z8eTUQ0mcmzosvn/z27MmLrz79/btHFfBNgUdl+JDGRKKb5Ajt8xgUM1ZxJScjcb4V wwjT8orNJJQ4wZpLBf2eihz0zSlmmXccOTrEteAdAeWjCnh9cs8ReBCJiaIVnHei2AHucs46XFRa YUfzKpl5OEnCauZiUsbtY3xYxbuLE8e/vUkKdTMPS0fxbkQcMfcYThQOSUIU0nP8gJAK7e5S6th1 l/qCSz5W6C5FHUwrTTKkIyeaZou2aQx+mVbpDP52bLN7B3U4q9J6ixy6SMgKzCqEHxLmmPE6nigc V5Ec4piVDX4Dq6hKyMFU+GVcTyrwdEgYR72ASFm15pYAfUtO38FQsSrdvsumsYsUih5U0byBOS8j t/hBN8JxWoUd0CQqYz+QBxCiGO1xVQXf5W6G6HfwA04WuvsOJY67T68Gt2noiDQLED0zEdqXUKqd ChzT5O/KMaNQj20MXFw5hgL44uvHFZH1thbiTdiTqjJh+0T5XYQ7WXS7XAT07a+5W3iS7BEI8/mN 513JfVdyvf98yV2Uz2cttLPaCmVX9w22KTYtcrywQx5TxgZqysgNaZpkCftE0IdBvc6cDklxYkoj eMzquoMLBTZrkODqI6qiQYRTaLDrniYSyox0KFHKJRzszHAlbY2HJl3ZY2FTHxhsPZBY7fLADq/o 4fxcUJAxu01oDp85oxVN4KzMVq5kREHt12FW10KdmVvdiGZKncOtUBl8OK8aDBbWhAYEQdsCVl6F 87lmDQcTzEig7W733twtxgsX6SIZ4YBkPtJ6z/uobpyUx4q5CYDYqfCRPuSdYrUSt5Ym+wbczuKk MrvGAna5997ES3kEz7yk8/ZEOrKknJwsQUdtr9VcbnrIx2nbG8OZFh7jFLwudc+HWQgXQ74SNuxP TWaT5TNvtnLF3CSowzWFtfucwk4dSIVUW1hGNjTMVBYCLNGcrPzLTTDrRSlgI/01pFhZg2D416QA O7quJeMx8VXZ2aURbTv7mpVSPlFEDKLgCI3YROxjcL8OVdAnoBKuJkxF0C9wj6atbabc4pwlXfn2 yuDsOGZphLNyq1M0z2QLN3lcyGDeSuKBbpWyG+XOr4pJ+QtSpRzG/zNV9H4CNwUrgfaAD9e4AiOd r22PCxVxqEJpRP2+gMbB1A6IFriLhWkIKrhMNv8FOdT/bc5ZGiat4cCn9mmIBIX9SEWCkD0oSyb6 TiFWz/YuS5JlhExElcSVqRV7RA4JG+oauKr3dg9FEOqmmmRlwOBOxp/7nmXQKNRNTjnfnBpS7L02 B/7pzscmMyjl1mHT0OT2L0Ss2FXterM833vLiuiJWZvVyLMCmJW2glaW9q8pwjm3Wlux5jRebubC gRfnNYbBoiFK4b4H6T+w/1HhM/tlQm+oQ74PtRXBhwZNDMIGovqSbTyQLpB2cASNkx20waRJWdNm rZO2Wr5ZX3CnW/A9YWwt2Vn8fU5jF82Zy87JxYs0dmZhx9Z2bKGpwbMnUxSGxvlBxjjGfNIqf3Xi o3vg6C24358wJU0wwTclgaH1HJg8gOS3HM3Sjb8AAAD//wMAUEsDBBQABgAIAAAAIQAN0ZCftgAA ABsBAAAnAAAAdGhlbWUvdGhlbWUvX3JlbHMvdGhlbWVNYW5hZ2VyLnhtbC5yZWxzhI9NCsIwFIT3 gncIb2/TuhCRJt2I0K3UA4TkNQ02PyRR7O0NriwILodhvplpu5edyRNjMt4xaKoaCDrplXGawW24 7I5AUhZOidk7ZLBggo5vN+0VZ5FLKE0mJFIoLjGYcg4nSpOc0IpU+YCuOKOPVuQio6ZByLvQSPd1 faDxmwF8xSS9YhB71QAZllCa/7P9OBqJZy8fFl3+UUFz2YUFKKLGzOAjm6pMBMpburrE3wAAAP// AwBQSwECLQAUAAYACAAAACEAgoq8E/oAAAAcAgAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRf VHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCl1qfnwAAAADYBAAALAAAAAAAAAAAAAAAAACsBAABf cmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBreZYWgwAAAIoAAAAcAAAAAAAAAAAAAAAAABQCAAB0 aGVtZS90aGVtZS90aGVtZU1hbmFnZXIueG1sUEsBAi0AFAAGAAgAAAAhAJa1reKWBgAAUBsAABYA AAAAAAAAAAAAAAAA0QIAAHRoZW1lL3RoZW1lL3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEADdGQ n7YAAAAbAQAAJwAAAAAAAAAAAAAAAACbCQAAdGhlbWUvdGhlbWUvX3JlbHMvdGhlbWVNYW5hZ2Vy LnhtbC5yZWxzUEsFBgAAAAAFAAUAXQEAAJYKAAAAADw/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rp bmc9IlVURi04IiBzdGFuZGFsb25lPSJ5ZXMiPz4NCjxhOmNsck1hcCB4bWxuczphPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvZHJhd2luZ21sLzIwMDYvbWFpbiIgYmcxPSJsdDEi IHR4MT0iZGsxIiBiZzI9Imx0MiIgdHgyPSJkazIiIGFjY2VudDE9ImFjY2VudDEiIGFjY2VudDI9 ImFjY2VudDIiIGFjY2VudDM9ImFjY2VudDMiIGFjY2VudDQ9ImFjY2VudDQiIGFjY2VudDU9ImFj Y2VudDUiIGFjY2VudDY9ImFjY2VudDYiIGhsaW5rPSJobGluayIgZm9sSGxpbms9ImZvbEhsaW5r Ii8+AAAAAAEAAACEEgAA/////wAAAAABAP////8AAAAAAAAAAAAAAAABAAAAAAD/////AAAAAFAB AAAAAAAAAQAAAAQAAAAAAAAAAAD//wAAAAAAAAAAhBIAABEAADgAAAAA/////wAAAAADAAAABgAA AAYAAAAJAAAADAAAAAwAAAAMAAAAPwAAAD8AAABdAAAAXQAAAK4CAACxAgAAAAgAABgKAAArEwAA OBgAAIQaAAAOAAAAFAAAABYAAAAYAAAAAAgAAIgIAACqCAAAvggAAEoJAAC+CQAA2xcAAJIYAAD9 GAAAgBoAAIQaAAAPAAAAEAAAABEAAAASAAAAEwAAABUAAAAXAAAAGQAAABoAAAAbAAAADgAAACUA AAAnAAAAsQIAABMh9P+VgA8AAPBgAAAAAAAG8CAAAAACDAAAAwAAAAUAAAACAAAAAQAAAAUAAAAC AAAAAQAAAEMAC/AYAAAAgQA3IgEAggC6IgAAgwA3IgEAhAC6IgAAQAAe8RAAAAD//wAAAAD/AICA gAD3AAAQAQ8AAvBIAAAAIAAI8AgAAAABAAAAAAgAAA8AA/AwAAAADwAE8CgAAAABAAnwEAAAAAAA AAAAAAAAAAAAAAAAAAACAArwCAAAAAAIAAAFAAAAAA8AAvCSAAAAEAAI8AgAAAABAAAABAQAAA8A A/AwAAAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAEAAAFAAAADwAE 8EIAAAASAArwCAAAAAEEAAAADgAAUwAL8B4AAAC/AQAAEADLAQAAAAD/AQAACAAEAwkAAAA/AwEA AQAAABHwBAAAAAEAAACEEgAA//8OAAAACgBJAG4AcwBlAHIAdABMAG8AZwBvAAQAZABuAHUAbQAI AGQAdABhAGIAbABlAGEAdQAFAGQAZABhAHQAZQAHAGQAbwByAGwAYQBuAGcACABkAG0AZQBlAHQA aQBuAGcACQBkAGIAbAB1AGUAcABpAG4AawAGAGQAdABpAHQAbABlAAcAZABzAG8AdQByAGMAZQAH AGQAdABpAHQAbABlADEACABkAGMAbwBuAHQAYQBjAHQACQBkAGMAbwBuAHQAZQBuAHQAMQAIAGQA YwBvAG4AdABlAG4AdAAJAGQAYwBvAG4AdABlAG4AdAAyAAAAAAAAAAAAAAAAADwAAACJAAAAqwAA AKsAAAC/AAAA4gAAAEsBAAAvEAAALxAAAJMQAACTEAAAhRIAAAAAAAABAAKDCAAAAAIAAoMDAAKD BAACgwUAAYIGAACBBwABggkAAYIKAAAACwABggwAAYINAAGCAAAAADwAAACJAAAAqwAAAL8AAAC/ AAAA4gAAAEsBAACwAQAAsAEAAJMQAACTEAAA/hAAAP4QAACFEgAA//8CAAAABgCthvYEEAABAFy5 IgAGAK6G9gQRAAEAhJUjAEsQAABLEAAAhRIAAAAAAAACAAEAAAACAFAQAABQEAAAhRIAAAAAAAAB AAAAAgAAADkAAAACAAAAKoB1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRh Z3MFgHBsYWNlAIBCAAAAAQAAACqAdXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21h cnR0YWdzDoBjb3VudHJ5LXJlZ2lvbgCADAAAASgvCgkAAAAAAgAAAAAAAQAAAAAAAAAAAAIDAAAF AwAAAgQAAAcEAACCBQAAiQUAADoKAABCCgAAqAoAALAKAAA+DAAARgwAAOEMAADpDAAA0g8AANQP AADVDwAA1w8AANgPAADaDwAA2w8AAN0PAADeDwAAOBAAAD8QAACcEAAAoRAAAKcQAACrEAAAshAA ALcQAACAEgAAgRIAAIUSAAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAHAAIABwACAAcA AgAHAAIABwAcAAcABQAHAAUABwAFAAcAAgAHAAAAAACwAQAA0Q8AAIUSAAAEAAMABwAAAAAAAgAA AD0AAAB9AAAA6gAAAEsBAABSAQAAsQEAAL4BAAAHDwAAEA8AAMYPAADRDwAA0g8AANQPAADVDwAA 1w8AANgPAADaDwAA2w8AAN0PAADeDwAA4A8AAPoPAAAPEAAALxAAALcQAAC4EAAA/hAAAIASAACB EgAAhRIAAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABwACAAcAAgAHAAIABwACAAUABwAFAAcA BQAHAAUABwACAAcAAAAAALABAACKAgAAigIAACYHAAAmBwAAFgkAABYJAAALDAAACwwAANIPAADS DwAA1A8AANUPAADVDwAA1w8AANgPAADaDwAA2w8AAN0PAADeDwAA4A8AAPoPAAAPEAAAERAAAC4Q AACAEgAAgRIAAIUSAAAEAAcABAAHAAQABwAEAAcABAAHAAQABwACAAQABwACAAcAAgAHAAIABAAH AAQABwADAAQAAgAHAAkA+////y7AbOr/D/8P/w//DwUABgAHAAgACQAAAMMXsxlwACaX/w//D/8P /w//D/8P/w//D/8PEAB2Nn0jrFe+Sf8P/w//D/8P/w//D/8P/w//DxAAYUDeI9IQXiD/D/8P/w// D/8P/w//D/8P/w8QAGtInjEol+zp/w//D/8P/w//D/8P/w//D/8PEABxdRdEYGjcpf8P/w//D/8P /w//D/8P/w//DxAAQXR7UoZbsi3/D/8P/w//D/8P/w//D/8P/w8QAGsBX2rGpcwC/w//D/8P/w// D/8P/w//D/8PEAB+Hal1lno4Qf8P/w//D/8P/w//D/8P/w//DwAAAQAAAAAAAQAAAAAAAAAAAAAA AAAAAAAAAxgAAA+EsAERhFD+FcYFAAGwAQZehLABYIRQ/m8oAAEAAAABAAAAAAABAwAAAAAAAAAA AAAAAAAAAAADGAEAD4RAAhGEwP0VxgUAAUACBl6EQAJghMD9bygAAwAAAC4AAQABAAAAAAABAwUA AAAAAAAAAAAAAAAAAAADGAIAD4TQAhGEMP0VxgUAAdACBl6E0AJghDD9bygABQAAAC4AAQAuAAIA AQAAAAAAAQMFBwAAAAAAAAAAAAAAAAAAAxgDAA+EYAMRhKD8FcYFAAFgAwZehGADYISg/G8oAAcA AAAuAAEALgACAC4AAwABAAAAAAABAwUHCQAAAAAAAAAAAAAAAAADGAQAD4TwAxGEEPwVxgUAAfAD Bl6E8ANghBD8bygACQAAAC4AAQAuAAIALgADAC4ABAABAAAAAAABAwUHCQsAAAAAAAAAAAAAAAAD GAUAD4SABBGEgPsVxgUAAYAEBl6EgARghID7bygACwAAAC4AAQAuAAIALgADAC4ABAAuAAUAAQAA AAAAAQMFBwkLDQAAAAAAAAAAAAAAAxgGAA+EEAURhPD6FcYFAAEQBQZehBAFYITw+m8oAA0AAAAu AAEALgACAC4AAwAuAAQALgAFAC4ABgABAAAAAAABAwUHCQsNDwAAAAAAAAAAAAADGAcAD4SgBRGE YPoVxgUAAaAFBl6EoAVghGD6bygADwAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwABAAAA AAABAwUHCQsNDxEAAAAAAAAAAAADGAgAD4QwBhGE0PkVxgUAATAGBl6EMAZghND5bygAEQAAAC4A AQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwAuAAgAAQAAABcQAAAAAAAAAAAAAAAAAAAAAAAAFRgA AA+EaAERhJj+FcYFAAFoAQZehGgBYISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/ABAAAAF5AA AAAAAAAAAAAAAAAAAAAAAAAZGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+T0oEAFFKBABeSgMA bygAh2gAAAAAiEgAAAEAbwABAAAAF5AAAAAAAAAAAAAAAAAAAAAAAAAVGAAAD4RwCBGEmP4VxgUA AXAIBl6EcAhghJj+T0oFAFFKBQBvKACHaAAAAACISAAAAQCn8AEAAAAXkAAAAAAAAAAAAAAAAAAA AAAAABUYAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP5PSgEAUUoBAG8oAIdoAAAAAIhIAAABALfw AQAAABeQAAAAAAAAAAAAAAAAAAAAAAAAGRgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/k9KBABR SgQAXkoDAG8oAIdoAAAAAIhIAAABAG8AAQAAABeQAAAAAAAAAAAAAAAAAAAAAAAAFRgAAA+E4BAR hJj+FcYFAAHgEAZehOAQYISY/k9KBQBRSgUAbygAh2gAAAAAiEgAAAEAp/ABAAAAF5AAAAAAAAAA AAAAAAAAAAAAAAAVGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+T0oBAFFKAQBvKACHaAAAAACI SAAAAQC38AEAAAAXkAAAAAAAAAAAAAAAAAAAAAAAABkYAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCE mP5PSgQAUUoEAF5KAwBvKACHaAAAAACISAAAAQBvAAEAAAAXkAAAAAAAAAAAAAAAAAAAAAAAABUY AAAPhFAZEYSY/hXGBQABUBkGXoRQGWCEmP5PSgUAUUoFAG8oAIdoAAAAAIhIAAABAKfwBgAAAAAA AQAAAAAAAAAAAAAAAAAAAAAAAxgAAA+EIAMRhOD8FcYFAAEgAwZehCADYITg/G8oAAEAAAABAAAA FAACAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4TAAxGEIP4VxgUAAcADBl6EwANghCD+h2gAAAAAiEgA AAMAKAABACkAAQAAABIAAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+EoAURhCD+FcYFAAGgBQZehKAF YIQg/odoAAAAAIhIAAABAAIAAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+EgAcRhCD+FcYF AAGABwZehIAHYIQg/odoAAAAAIhIAAACAAMALgABAAAAFAACAAAAAAAAAAAAAAAAAAAAAAAKGAAA D4RgCRGEIP4VxgUAAWAJBl6EYAlghCD+h2gAAAAAiEgAAAMAKAAEACkAAQAAABIAAQAAAAAAAAAA AAAAAAAAAAAAChgAAA+EQAsRhCD+FcYFAAFACwZehEALYIQg/odoAAAAAIhIAAABAAUAAQAAAAAA AQAAAAAAAAAAAAAAAAAAAAAAChgAAA+EIA0RhCD+FcYFAAEgDQZehCANYIQg/odoAAAAAIhIAAAC AAYALgABAAAAFAACAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4QADxGEIP4VxgUAAQAPBl6EAA9ghCD+ h2gAAAAAiEgAAAMAKAAHACkAAQAAABIAAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+E4BARhCD+FcYF AAHgEAZehOAQYIQg/odoAAAAAIhIAAABAAgAAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxgAAA+E aAERhJj+FcYFAAFoAQZehGgBYISY/m8oAAIAAAApAAEAAAAUgAIAAAAAAAAAAAAAAAAAAAAAAAoY AAAPhEgDEYRc/hXGBQABSAMGXoRIA2CEXP6HaAAAAACISAAAAwAoAAEAKQABAAAAEoABAAAAAAAA AAAAAAAAAAAAAAAKGAAAD4TsBBGEXP4VxgUAAewEBl6E7ARghFz+h2gAAAAAiEgAAAEAAgABAAAA AIABAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4SQBhGEXP4VxgUAAZAGBl6EkAZghFz+h2gAAAAAiEgA AAIAAwAuAAEAAAAUgAIAAAAAAAAAAAAAAAAAAAAAAAoYAAAPhDQIEYRc/hXGBQABNAgGXoQ0CGCE XP6HaAAAAACISAAAAwAoAAQAKQABAAAAEoABAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4TYCRGEXP4V xgUAAdgJBl6E2AlghFz+h2gAAAAAiEgAAAEABQABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAKGAAA D4R8CxGEXP4VxgUAAXwLBl6EfAtghFz+h2gAAAAAiEgAAAIABgAuAAEAAAAUgAIAAAAAAAAAAAAA AAAAAAAAAAoYAAAPhCANEYRc/hXGBQABIA0GXoQgDWCEXP6HaAAAAACISAAAAwAoAAcAKQABAAAA EoABAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4TEDhGEXP4VxgUAAcQOBl6ExA5ghFz+h2gAAAAAiEgA AAEACAABAAAADgABAAAAAAAAAAAAAAAAAAAAAAANEAAAD4TgARGEIP5ehOABYIQg/m8oAYdoAAAA AIhIAAACAAAAKQABAAAAFIACAAAAAAAAAAAAAAAAAAAAAAAKEAAAD4TAAxGEIP5ehMADYIQg/odo AAAAAIhIAAADACgAAQApAAEAAAASgAEAAAAAAAAAAAAAAAAAAAAAAAoQAAAPhKAFEYQg/l6EoAVg hCD+h2gAAAAAiEgAAAEAAgABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAKEAAAD4SABxGEIP5ehIAH YIQg/odoAAAAAIhIAAACAAMALgABAAAAFIACAAAAAAAAAAAAAAAAAAAAAAAKEAAAD4RgCRGEIP5e hGAJYIQg/odoAAAAAIhIAAADACgABAApAAEAAAASgAEAAAAAAAAAAAAAAAAAAAAAAAoQAAAPhEAL EYQg/l6EQAtghCD+h2gAAAAAiEgAAAEABQABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAKEAAAD4Qg DRGEIP5ehCANYIQg/odoAAAAAIhIAAACAAYALgABAAAAFIACAAAAAAAAAAAAAAAAAAAAAAAKEAAA D4QADxGEIP5ehAAPYIQg/odoAAAAAIhIAAADACgABwApAAEAAAASgAEAAAAAAAAAAAAAAAAAAAAA AAoQAAAPhOAQEYQg/l6E4BBghCD+h2gAAAAAiEgAAAEACAABAAAAAAABAAAAAAAAAAAAAAAAAAAA AAADGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+bygAAgAAAC4AAQAAAAAAAgAAAAAAAAAAAPAA AAAAAAAAAxgAAA+EzwMRhNX9FcYFAAHPAwZehM8DYITV/W8oAAMAKAABACkAAQAAABKAAQAAAAAA AAAAAAAAAAAAAAAAChgAAA+E7AQRhFz+FcYFAAHsBAZehOwEYIRc/odoAAAAAIhIAAABAAIAAQAA AACAAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+EkAYRhFz+FcYFAAGQBgZehJAGYIRc/odoAAAAAIhI AAACAAMALgABAAAAFIACAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4Q0CBGEXP4VxgUAATQIBl6ENAhg hFz+h2gAAAAAiEgAAAMAKAAEACkAAQAAABKAAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+E2AkRhFz+ FcYFAAHYCQZehNgJYIRc/odoAAAAAIhIAAABAAUAAQAAAACAAQAAAAAAAAAAAAAAAAAAAAAAChgA AA+EfAsRhFz+FcYFAAF8CwZehHwLYIRc/odoAAAAAIhIAAACAAYALgABAAAAFIACAAAAAAAAAAAA AAAAAAAAAAAKGAAAD4QgDRGEXP4VxgUAASANBl6EIA1ghFz+h2gAAAAAiEgAAAMAKAAHACkAAQAA ABKAAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+ExA4RhFz+FcYFAAHEDgZehMQOYIRc/odoAAAAAIhI AAABAAgAAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxgAAA+E4AERhJj+FcYFAAHgAQZehOABYISY /m8oAAIAAAApAAEAAAAUgAIAAAAAAAAAAAAAAAAAAAAAAAoYAAAPhMADEYRc/hXGBQABwAMGXoTA A2CEXP6HaAAAAACISAAAAwAoAAEAKQABAAAAEoABAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4RkBRGE XP4VxgUAAWQFBl6EZAVghFz+h2gAAAAAiEgAAAEAAgABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAK GAAAD4QIBxGEXP4VxgUAAQgHBl6ECAdghFz+h2gAAAAAiEgAAAIAAwAuAAEAAAAUgAIAAAAAAAAA AAAAAAAAAAAAAAoYAAAPhKwIEYRc/hXGBQABrAgGXoSsCGCEXP6HaAAAAACISAAAAwAoAAQAKQAB AAAAEoABAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4RQChGEXP4VxgUAAVAKBl6EUApghFz+h2gAAAAA iEgAAAEABQABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4T0CxGEXP4VxgUAAfQLBl6E9Atg hFz+h2gAAAAAiEgAAAIABgAuAAEAAAAUgAIAAAAAAAAAAAAAAAAAAAAAAAoYAAAPhJgNEYRc/hXG BQABmA0GXoSYDWCEXP6HaAAAAACISAAAAwAoAAcAKQABAAAAEoABAAAAAAAAAAAAAAAAAAAAAAAK GAAAD4Q8DxGEXP4VxgUAATwPBl6EPA9ghFz+h2gAAAAAiEgAAAEACAAKAAAAFwAAAAAAAAAAAAAB AAAAAAAAAAATEAAAD4SsAxGEdP9ehKwDYIR0/09KAABQSgMAUUoAAFJKAABvKAABAC0AAQAAABeA AAAAAAAAAAAAAAAAAAAAAAAAFRgAAA+E4AYRhCD+FcYFAAHgBgZehOAGYIQg/k9KBQBRSgUAbygA h2gAAAAAiEgAAAEA2PABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAVGAAAD4TACBGEIP4VxgUAAcAI Bl6EwAhghCD+T0oFAFFKBQBvKACHaAAAAACISAAAAQCy8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAA ABUYAAAPhKAKEYQg/hXGBQABoAoGXoSgCmCEIP5PSgUAUUoFAG8oAIdoAAAAAIhIAAABAGzwAQAA ABeAAAAAAAAAAAAAAAAAAAAAAAAAFRgAAA+EgAwRhCD+FcYFAAGADAZehIAMYIQg/k9KBQBRSgUA bygAh2gAAAAAiEgAAAEA2PABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAVGAAAD4RgDhGEIP4VxgUA AWAOBl6EYA5ghCD+T0oFAFFKBQBvKACHaAAAAACISAAAAQCy8AEAAAAXgAAAAAAAAAAAAAAAAAAA AAAAABUYAAAPhEAQEYQg/hXGBQABQBAGXoRAEGCEIP5PSgUAUUoFAG8oAIdoAAAAAIhIAAABAGzw AQAAABeAAAAAAAAAAAAAAAAAAAAAAAAAFRgAAA+EIBIRhCD+FcYFAAEgEgZehCASYIQg/k9KBQBR SgUAbygAh2gAAAAAiEgAAAEA2PABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAVGAAAD4QAFBGEIP4V xgUAAQAUBl6EABRghCD+T0oFAFFKBQBvKACHaAAAAACISAAAAQCy8AYAAAAAAAEAAAAAAAAAAAEA AAAAAAAAAAMQAAAPhCwBEYTU/l6ELAFghNT+bygAAQAAAAEAAAAAAAEDAAAAAAAAAAEAAAAAAAAA AAMQAAAPhCwBEYTU/l6ELAFghNT+bygAAwAAAC4AAQABAAAAAAABAwUAAAAAAAABAAAAAAAAAAAD EAAAD4QsARGE1P5ehCwBYITU/m8oAAUAAAAuAAEALgACAAEAAAAAAAEDBQcAAAAAAAEAAAAAAAAA AAMQAAAPhCwBEYTU/l6ELAFghNT+bygABwAAAC4AAQAuAAIALgADAAEAAAAAAAEDBQcJAAAAAAEA AAAAAAAAAAMQAAAPhCwBEYTU/l6ELAFghNT+bygACQAAAC4AAQAuAAIALgADAC4ABAABAAAAAAAB AwUHCQsAAAABAAAAAAAAAAADEAAAD4QsARGE1P5ehCwBYITU/m8oAAsAAAAuAAEALgACAC4AAwAu AAQALgAFAAEAAAAAAAEDBQcJCw0AAAEAAAAAAAAAAAMQAAAPhCwBEYTU/l6ELAFghNT+bygADQAA AC4AAQAuAAIALgADAC4ABAAuAAUALgAGAAEAAAAAAAEDBQcJCw0PAAEAAAAAAAAAAAMQAAAPhCwB EYTU/l6ELAFghNT+bygADwAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwABAAAAAAABAwUH CQsNDxEBAAAAAAAAAAADEAAAD4QsARGE1P5ehCwBYITU/m8oABEAAAAuAAEALgACAC4AAwAuAAQA LgAFAC4ABgAuAAcALgAIAA0AAAD7////AAAAAAAAAAAAAAAA+////wAAAAAAAAAAAAAAAPv///8A AAAAAAAAAAAAAAD7////AAAAAAAAAAAAAAAA+////wAAAAAAAAAAAAAAAMMXsxkAAAAAAAAAAAAA AABrAV9qAAAAAAAAAAAAAAAAdjZ9IwAAAAAAAAAAAAAAAH4dqXUAAAAAAAAAAAAAAABxdRdEAAAA AAAAAAAAAAAAQXR7UgAAAAAAAAAAAAAAAGFA3iMAAAAAAAAAAAAAAABrSJ4xAAAAAAAAAAAAAAAA ////////////////////////////////////////////////////////////////////////CQAA AAAAAAAAAAAAAAAAAAAAAAAAAP//CQAAAAAAEgCS4ZDpAwAJBAUACQQBAAkEAwAJBAUACQQBAAkE AwAJBAUACQQSAOpXhEgJBBcACQQRAAkEDwAJBBcACQQRAAkEDwAJBBcACQQRABIA7r4W4RcACQQR AAkEDwAJBBcACQQRAAkEDwAJBBcACQQRAAkEEgDygzIzFwAJBBEACQQPAAkEFwAJBBEACQQPAAkE FwAJBBEACQQSAJQRZEEQauBZEQAJBA8ACQQXAAkEEQAJBA8ACQQXAAkEEQAJBBIAvpUW3hcACQQR AAkEDwAJBBcACQQRAAkEDwAJBBcACQQRAAkEEgC86yoqCQQLAAkEDQAJBAEACQQLAAkEDQAJBAEA CQQLAAkEDQAAAAIAAAAAAAcEAAIJAAEADAQCAkEADAAAAAQAAAAIAAAA5QAAAAAAAAALAAAA3RcK AOVFOADdGj0AQFxEAPYzTwCOMVcAX29YAAokZQBnU3sArU6lAFx2swDuYscAAAAAANIPAADUDwAA AAAAAAEAAAD/QAIQAAAAAAAAAIQSAACIAAAQAEAAAP//AQAAAAcAVQBuAGsAbgBvAHcAbgD//wEA CAAAAAAAAAAAAAAA//8BAAAAAAD//wAAAgD//wAAAAD//wAAAgD//wAAAAAHAAAARx6QAQAAAgIG AwUEBQIDBIcqACAAAACACAAAAAAAAAD/AQAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0A YQBuAAAANR6QAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBs AAAAMy6QAQAAAgsGBAICAgICBIcqACAAAACACAAAAAAAAAD/AQAAAAAAAEEAcgBpAGEAbAAAAEc1 kAGACgICBgkEAgUIAwS/AgCg+/zHaBAAAAAAAAAAnwACAAAAAABNAFMAIABNAGkAbgBjAGgAbwAA AC3/M/8gAA5mHWcAAD89kAEAAAIHAwkCAgUCBASHKgAgAAAAgAgAAAAAAAAA/wEAAAAAAABDAG8A dQByAGkAZQByACAATgBlAHcAAAA7DpABAgAFAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAIAA AAAAVwBpAG4AZwBkAGkAbgBnAHMAAABBHpABAAACBAUDBQQGAwIE7wIAoOsgAEIAAAAAAAAAAJ8A AAAAAAAAQwBhAG0AYgByAGkAYQAgAE0AYQB0AGgAAAAiAAQAQwAMGFb8NwIAAKkBAAAAAAL082YD 9PNmWzXrxgMAAQAAAGgCAABqDQAAAgAaAAAABACDAEYAAABoAgAAag0AAAIAGgAAAEYAAAAAAAAA uSRW/BAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbgSJBXgAtACAgBI0AAAQABkAZAAAABkA AAC4DwAAuA8AAAAAAABNM/wkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD AAAAAwAAAAAAAAAAAAIAAADJBAAAAAANM4NxVvwQBN/f//0BAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAACEhYAAAAAAnw/w8BCAE/AADkBAAA////f////3////9/////f////3////9/////f5hmKwAA BAAAMgAAAAAAAAAAAAAAAAAAAAAAAAAAACEEAAAAAAAAAAAAAAAAAAAAAAAAEBwAAAYAAAAAAAAA AAB4AAAAeAAAAAAAAAAAAAAAoAUAAP//EgAAAAAAOQBDADoAXABUAHIAYQB2AGEAaQBsAFwAVwBv AHIAZABcAFMAYQB1AHYAZQBHAGEAcgBkAGUAXABBAG4AZwBsAGEAaQBzAFwASQB0AHUAdABCAGEA cwBpAGMALQBUAGUAbQBwAGwAYQB0AGUALgBkAG8AdABcAFAAcgBvAHAAbwBzAGEAbAAgAG8AZgAg AHQAaABlACAAYwByAGUAYQB0AGkAbwBuACAAbwBmACAAYQAgAG4AZQB3ACAAdwBvAHIAawAgAGkA dABlAG0AIAAcIHQAZQBjAGgAbgBpAGMAYQBsACAAcwBlAGMAdQByAGkAdAB5ACAAZwB1AGkAZABl AGwAaQBuAGUAIABvAG4AIABkAGUAcABsAG8AeQBpAG4AZwAgAEkAUAB2ADYAHSAAAAEAMgAAAF8A TgBhAHQAaQBvAG4AYQBsACAASQBuAHMAdABpAHQAdQB0AGUAIABvAGYAIABJAG4AZgBvAHIAbQBh AHQAaQBvAG4AIABhAG4AZAAgAEMAbwBtAG0AdQBuAGkAYwBhAHQAaQBvAG4AcwAgAFQAZQBjAGgA bgBvAGwAbwBnAHkALAAgAEoAYQBwAGEAbgAgACgATgBJAEMAVAApACwAIABLAEQARABJACAAQwBv AHIAcABvAHIAYQB0AGkAbwBuAAYAbgBvAHIAdABvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAA BgAAAAkAAAAAAAwAAQAMAAIADAADAAwABAAMAAUADAAGAAwABwAMAAgADAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf 8vlPaBCrkQgAKyez2TAAAACgAgAAEgAAAAEAAACYAAAAAgAAAKAAAAADAAAACAEAAAQAAAAUAQAA BQAAAHwBAAAGAAAAiAEAAAcAAAD0AQAACAAAABQCAAAJAAAAJAIAABIAAAAwAgAACgAAAFACAAAL AAAAXAIAAAwAAABoAgAADQAAAHQCAAAOAAAAgAIAAA8AAACIAgAAEAAAAJACAAATAAAAmAIAAAIA AADkBAAAHgAAAGAAAABQcm9wb3NhbCBvZiB0aGUgY3JlYXRpb24gb2YgYSBuZXcgd29yayBpdGVt IJN0ZWNobmljYWwgc2VjdXJpdHkgZ3VpZGVsaW5lIG9uIGRlcGxveWluZyBJUHY2lAAAAAAeAAAA BAAAAAAAAAAeAAAAYAAAAE5hdGlvbmFsIEluc3RpdHV0ZSBvZiBJbmZvcm1hdGlvbiBhbmQgQ29t bXVuaWNhdGlvbnMgVGVjaG5vbG9neSwgSmFwYW4gKE5JQ1QpLCBLRERJIENvcnBvcmF0aW9uAB4A AAAEAAAAMgAAAB4AAABkAAAAQ09NIDE3IJYgQyA0NTQgliBFICBGb3I6IA1Eb2N1bWVudCBkYXRl OiBNYXJjaCAyMDExDVNhdmVkIGJ5IEVOVjEwNjg4NyBhdCAxNjowMjo0NSBvbiAzMC8wMy8yMDEx AAAAAB4AAAAYAAAASXR1dEJhc2ljLVRlbXBsYXRlLmRvdAAAHgAAAAgAAABub3J0b24AAB4AAAAE AAAAMwAAAB4AAAAYAAAATWljcm9zb2Z0IE9mZmljZSBXb3JkAAAAQAAAAABGwyMAAAAAQAAAAADa PpXofcsBQAAAAAD80gnj7ssBQAAAAABCli3j7ssBAwAAAAIAAAADAAAAaAIAAAMAAABqDQAAAwAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cI ACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rogBAABEAQAADgAAAAEAAAB4AAAADgAAAIAAAAAPAAAA kAAAAAQAAADEAAAABQAAAMwAAAAGAAAA1AAAABEAAADcAAAAFwAAAOQAAAALAAAA7AAAABAAAAD0 AAAAEwAAAPwAAAAWAAAABAEAAA0AAAAMAQAADAAAACUBAAACAAAA5AQAAB4AAAAIAAAASVRVLVQA AAAeAAAALAAAAEludGVybmF0aW9uYWwgVGVsZWNvbW11bmljYXRpb24gVW5pb24gKElUVSkAAwAA AADCAAADAAAARgAAAAMAAAAaAAAAAwAAALgPAAADAAAAAAAMAAsAAAAAAAAACwAAAAAAAAALAAAA AAAAAAsAAAAAAAAAHhAAAAEAAAANAAAAUXVlc3Rpb24ocyk6AAwQAAACAAAAHgAAAAYAAABUaXRs ZQADAAAAAQAAAACUAQAACAAAAAAAAABIAAAAAQAAALMAAAACAAAAuwAAAAMAAADXAAAABAAAAOsA AAAFAAAAEwEAAAYAAAAfAQAABwAAACsBAAAGAAAAAgAAAAcAAABEb2NudW0AAwAAAAgAAABEb2Nk YXRlAAQAAAAKAAAARG9jb3JsYW5nAAUAAAAMAAAARG9jYmx1ZXBpbmsABgAAAAgAAABEb2NkZXN0 AAcAAAAKAAAARG9jYXV0aG9yAAIAAADkBAAAHgAAABQAAABDT00gMTcgliBDIDQ1NCCWIEUAAB4A AAAMAAAATWFyY2ggMjAxMQAAHgAAACAAAABFbmdsaXNoIG9ubHkgT3JpZ2luYWw6IEVuZ2xpc2gA AB4AAAAEAAAAMgAAAB4AAAAEAAAAAAAAAB4AAABgAAAATmF0aW9uYWwgSW5zdGl0dXRlIG9mIElu Zm9ybWF0aW9uIGFuZCBDb21tdW5pY2F0aW9ucyBUZWNobm9sb2d5LCBKYXBhbiAoTklDVCksIEtE REkgQ29ycG9yYXRpb24AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAA AA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAA GwAAABwAAAD+////HgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAAp AAAAKgAAACsAAAD+////LQAAAC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAADcA AAA4AAAAOQAAADoAAAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAAAEMAAABEAAAARQAA AEYAAABHAAAASAAAAEkAAABKAAAASwAAAEwAAABNAAAATgAAAE8AAABQAAAAUQAAAFIAAABTAAAA VAAAAFUAAABWAAAA/v///1gAAABZAAAAWgAAAFsAAABcAAAAXQAAAF4AAAD+////YAAAAGEAAABi AAAAYwAAAGQAAABlAAAAZgAAAP7////9////aQAAAP7////+/////v////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAAAAAAAA AAAAwJcUNePuywFrAAAAgAAAAAAAAABEAGEAdABhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgACAf///////////////wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB0AAAA+HQAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIBAQAAAAYAAAD/ ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALAAAAGdVAAAAAAAAVwBvAHIA ZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ABoAAgECAAAABQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA NzgAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAKAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAFcAAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBu AGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIBBAAAAP//////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXwAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgD///////////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAeQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAEAAAD+//////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////AQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAARicAAABNaWNyb3NvZnQgT2ZmaWNlIFdv cmQgOTctMjAwMyBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9Dmy cQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAA= --Apple-Mail-231--1033672797 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > --Apple-Mail-231--1033672797--