From weiler+secdir@watson.org Mon Aug 1 09:16:29 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDC7C11E80E4 for ; Mon, 1 Aug 2011 09:16:29 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MI-enzPWbp5d for ; Mon, 1 Aug 2011 09:16:29 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDCD11E8077 for ; Mon, 1 Aug 2011 09:16:29 -0700 (PDT) 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 p71GGZqR037828 for ; Mon, 1 Aug 2011 12:16:35 -0400 (EDT) (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 p71GGZ1Z037824 for ; Mon, 1 Aug 2011 12:16:35 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 1 Aug 2011 12:16:35 -0400 (EDT) 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]); Mon, 01 Aug 2011 12:16:35 -0400 (EDT) Subject: [secdir] assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 01 Aug 2011 16:16:30 -0000 The last assignment message was well before the Quebec meeting. Russ Mundy is next in the rotation. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2011-08-11 Reviewer LC end Draft Derek Atkins T 2011-07-04 draft-ietf-roll-of0-15 Rob Austein T 2011-07-18 draft-shiomoto-ccamp-switch-programming-05 Alan DeKok T 2011-07-11 draft-ietf-mpls-mldp-recurs-fec-04 Sam Hartman TR2011-07-19 draft-ietf-msec-gdoi-update-09 Love Hornquist-Astrand T 2011-07-15 draft-ietf-softwire-dslite-radius-ext-04 Joe Salowey T 2011-05-30 draft-ietf-mpls-lsp-ping-enhanced-dsmap-10 Carl Wallace T 2011-07-21 draft-forte-lost-extensions-07 Sam Weiler T 2011-07-20 draft-gutmann-cms-hmac-enc-05 For telechat 2011-08-25 Reviewer LC end Draft Chris Lonvick T 2011-08-12 draft-ietf-pim-hello-intid-01 Ondrej Sury T 2011-06-30 draft-ietf-sidr-rescerts-provisioning-10 Last calls and special requests: Reviewer LC end Draft Tobias Gondrom 2011-08-04 draft-doria-genart-experience-04 Jeffrey Hutzelman 2011-07-22 draft-ietf-p2psip-base-17 Charlie Kaufman 2011-07-19 draft-ietf-dane-use-cases-05 Scott Kelly 2011-08-22 draft-dijkstra-urn-ogf-06 Stephen Kent 2011-08-15 draft-ietf-karp-threats-reqs-03 Tero Kivinen 2011-08-26 draft-gundavelli-v6ops-pmipv6-address-reservations-00 Warren Kumari 2011-08-12 draft-ietf-krb-wg-clear-text-cred-01 Julien Laganier 2011-08-12 draft-ietf-lisp-lig-03 Barry Leiba 2011-08-12 draft-ietf-mpls-rsvp-te-no-php-oob-mapping-08 Matt Lepinski 2011-08-16 draft-ietf-ospf-auth-trailer-ospfv3-05 David McGrew 2011-08-24 draft-kivinen-ipsecme-secure-password-framework-01 Catherine Meadows R2011-04-13 draft-ietf-speechsc-mrcpv2-25 Catherine Meadows 2011-08-09 draft-yevstifeyev-ion-report-06 Kathleen Moriarty - draft-ietf-hybi-thewebsocketprotocol-10 Russ Mundy 2011-06-30 draft-ietf-karp-design-guide-02 Tim Polk 2011-05-11 draft-ietf-vrrp-unified-mib-09 Tina TSOU 2011-04-23 draft-shin-augmented-pake-08 Glen Zorn 2011-06-28 draft-li-pwe3-ms-pw-pon-04 From new-work-bounces@ietf.org Mon Aug 1 06:39:35 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3546011E80BB; Mon, 1 Aug 2011 06:39:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1312205975; bh=mOy38YlhHycvvMPk2ZkGlp9UkFb4Rmc6gz91Z+2B3eE=; h=From:Date:To:Message-Id:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=XCVVAgfYYRr6jSChgYnLX4u9jTtynXx0zZIjJf5cYDGprYkyvUOxVo6GpmahvAjOf AZSNF7IEGTlRAwIdN9+YUBhn0gbdfn/3ILnaoPFevBE0N2BpHA9wwibJvhKpM7oWBg EB/pnvtuq6/+RO8pfYCa56wcwbx4xl2Fm/Pw+JHk= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D9D11E8090 for ; Mon, 1 Aug 2011 06:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.669 X-Spam-Level: X-Spam-Status: No, score=-9.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H63MTd1+VNE8 for ; Mon, 1 Aug 2011 06:39:31 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9B621F8BAB for ; Mon, 1 Aug 2011 06:39:31 -0700 (PDT) Received: from localhost ([127.0.0.1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1QnsiV-0006sl-Ov; Mon, 01 Aug 2011 09:39:35 -0400 From: Ian Jacobs Date: Mon, 1 Aug 2011 09:39:35 -0400 To: new-work@ietf.org Message-Id: <1CD4A8C5-37F1-43F7-ABE7-6BAD6399AD95@w3.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 01 Aug 2011 09:27:56 -0700 Subject: [secdir] [new-work] Proposed W3C Charters: Tracking Protection Working Group, Privacy Interest Group (until 2011-08-29) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 13:39:35 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Privacy Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes draft charters for two groups: Tracking Protection Working Group http://www.w3.org/2011/tracking-protection/charter-draft Privacy Interest Group: http://www.w3.org/2011/07/privacy-ig-charter 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-08-29 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [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 Nick Doty, Privacy Analyst . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/Privacy/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 new-work-bounces@ietf.org Mon Aug 1 06:42:15 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E3911E80BB; Mon, 1 Aug 2011 06:42:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1312206135; bh=IF1+o8F49Y035JA4reDZojU0/+XrNrZBC/BK0yOo/sI=; h=From:Date:To:Message-Id:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=ghs8+xOpJJ+Yp4vJv1X8Ke+naT9Z3AhRQIZnpmzCwa/KM9+xAfkVH8l+Y4dLDC2jH nMH3WL5FMfdfEYvc8j+I5r4COaK+G7qz5veKHf6VqQ8KmZmdKsnDhHk+470Mqe+eCH nhE2B6sX+72mf7A3HU8DD/bzP+FCOE+REKviEfBU= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A5411E80CF for ; Mon, 1 Aug 2011 06:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.834 X-Spam-Level: X-Spam-Status: No, score=-9.834 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdNWjrH138EH for ; Mon, 1 Aug 2011 06:42:13 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 8459711E809D for ; Mon, 1 Aug 2011 06:42:13 -0700 (PDT) Received: from localhost ([127.0.0.1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Qnsl9-00074f-N4; Mon, 01 Aug 2011 09:42:19 -0400 From: Ian Jacobs Date: Mon, 1 Aug 2011 09:42:19 -0400 To: new-work@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 01 Aug 2011 09:27:56 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Semantic Web Health Care and Life Sciences Interest Group (until 2011-08-29) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 13:42:15 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Semantic Web Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Semantic Web Health Care and Life Sciences Interest Group: http://www.w3.org/2011/05/HCLSIGCharter-proposal 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-08-29 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [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 Eric Prud'hommeaux, Team Contact . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/2001/sw/ [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 hartmans@mit.edu Mon Aug 1 09:51:09 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A365D21F8ED0; Mon, 1 Aug 2011 09:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.126 X-Spam-Level: X-Spam-Status: No, score=-104.126 tagged_above=-999 required=5 tests=[AWL=-1.861, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VH7KF+vc6MiK; Mon, 1 Aug 2011 09:51:09 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 35A5521F8ECC; Mon, 1 Aug 2011 09:51:09 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 5CE6A202B2; Mon, 1 Aug 2011 12:54:00 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2A3E3422B; Mon, 1 Aug 2011 12:51:11 -0400 (EDT) From: Sam Hartman To: ietf@ietf.org,secdir@ietf.org Date: Mon, 01 Aug 2011 12:51:11 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: draft-ietf-msec-gdoi-update@tools.ietf.org Subject: [secdir] secdir review of draft-ietf-msec-gdoi-update X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 16:51:09 -0000 This update to the GDOI specification significantly improves clarity and readability. However, there is one issue that I think should be addressed prior to publication: At the top of page 11, the spec claims that a seq payload protects against group members responding to groupkey-pull messages sent prior to joining the group. I'm reasonably sure that should be groupkey-push messages; I believe the nonce payloads provide replay protection for the pull exchange. Actually, it's more complicated than that. Section 3.3 also seems to believe the sequence number is about pull exchanges. However it says that a GM should always expect the push message sequence number to be reset to 1. Why is that reasonable? If a group is ongoing, don't we want to tell new members what the sequence number currently is rather than having them assume it is 1? The push message is multicast, so we cannot maintain a separate sequence number for each member. I think either there is some sort of error with the description of the replay mechanisms or it requires significantly more explanation. From charliek@microsoft.com Mon Aug 1 11:23:24 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7555521F8C1E; Mon, 1 Aug 2011 11:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMSIUwYO8DeM; Mon, 1 Aug 2011 11:23:23 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id C793521F8C1D; Mon, 1 Aug 2011 11:23:23 -0700 (PDT) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 1 Aug 2011 11:23:30 -0700 Received: from TK5EX14MBXC110.redmond.corp.microsoft.com ([169.254.1.232]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.01.0323.007; Mon, 1 Aug 2011 11:23:29 -0700 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-dane-use-cases.all@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-dane-use-cases-05 Thread-Index: AcxQbxWROXeC/GIUT5izxUdoB44tOQ== Date: Mon, 1 Aug 2011 18:23:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] secdir review of draft-ietf-dane-use-cases-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 18:23:24 -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.=A0 These = comments were written primarily for the benefit of the security area direct= ors.=A0 Document editors and WG chairs should treat these comments just lik= e any other last call comments. DANE is the latest in a long series of attempts to use DNSSEC to securely d= istribute the public keys corresponding to DNS names as an alternative/supp= lement to the PKIX based PKI that has evolved to be both not very secure an= d not very convenient. Using DNSSEC as an alternative/supplement is a great= idea, but it has failed many times in the past both for political reasons = and because DNSSEC wasn't really there yet. This document is a requirements= document, which gives it license to leave out a few of the more controvers= ial details of the design. I am strongly supportive of this effort, and have no complaints with any of= the contents of this document. There are a few issues that I think could h= ave been addressed more clearly, but presumably that will come in future do= cuments. DANE is primarily pitched in this document as a supplement to the existing = PKIX based PKI, and also it is stated that the keys are only intended to be= used in the context of TLS (mostly for server authentication, but optional= ly also for client authentication if the client is identified by a DNS name= ). This means that having DANE information posted in DNS could cause a conn= ection that succeeded without DANE to fail, but it could not cause a connec= tion that failed without DANE to succeed. In this context, it helps address= the security problems with the de facto Internet PKI, but not the convenie= nce problems. It does permit, however, (in scenario #3) the DANE informatio= n to replace the Internet PKI (in the sense of supporting TLS connections t= o servers that don't have certificates from configured trust roots). It is = left to endnode configuration to decide whether to trust such information, = and the single biggest issue that will face people deploying DANE is whethe= r to trust such information or not. DANE will permit different kinds of information to be posted in DNS concern= ing how to authenticate entities claiming to represent a particular DNS nam= e. This document doesn't say whether one of them will be a raw public key. = That would be the most straightforward thing to do, but also the most contr= oversial. What it emphasizes is the ability to specify which CA or CAs are = allowed to issue certificates for a particular DNS name. This would close t= he biggest single security gap in the de facto Internet PKI - that any trus= t root can generate bogus certificates for any DNS name, and many of the tr= ust roots are under the control of dubious entities. The document was not c= lear as to whether the CAs are identified by name or by public key, but ref= erences to its certificate imply they will be identified by both. Interesting details: The document calls for being able to co-locate multiple servers on a single= physical host distinguished by different ports where different certificate= s are required to authenticate the services on the different ports. I don't= know that PKIX supports that functionality, so this would be an extension. The document does not mention co-locating multiple servers on a single phys= ical host distinguished by different DNS names supplied in header fields, b= ut that would fall out of any reasonable design. The document calls for being able to work when the application service name= is the result of following a DNS redirection chain (e.g., via CNAME or DNA= ME), but does not suggest a mechanism. There may be technical options with = different security semantics... this will be an interesting area to watch. There is a suggestion on page 8 (ref: "a downgrade attack") that DANE infor= mation can be used to inform a client that a service is capable of acceptin= g TLS connections and that a client might (based on that information) refus= e to connect not over TLS, but no mention of this important feature elsewhe= re in the document. Typos: P2: "ciertificate" -> "certificate" P10: "Opportunistic Security" -> "Opportunistic Security:" From tobias.gondrom@gondrom.org Mon Aug 1 19:51:14 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C705D11E8158 for ; Mon, 1 Aug 2011 19:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.761 X-Spam-Level: X-Spam-Status: No, score=-94.761 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fspVXS8GsRfa for ; Mon, 1 Aug 2011 19:51:02 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBD011E8156 for ; Mon, 1 Aug 2011 19:50:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=uieixYzsKwwSYum7uVEjGjEq6ESa+VliL0hR9JwVtMUuPn8pYGx9wNvB97NwTBQhWm4F2VzxHFDN8nTNaBLljV6toPs5ZuBrJULCeuXviloM4+LJcS6c/AVm2YeRO6t4; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type; Received: (qmail 7641 invoked from network); 2 Aug 2011 04:50:45 +0200 Received: from ip-64-119-211-105.static.fibrenoire.ca (HELO ?172.16.52.23?) (64.119.211.105) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 2 Aug 2011 04:50:44 +0200 Message-ID: <4E376603.8090009@gondrom.org> Date: Tue, 02 Aug 2011 03:50:43 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110627 Thunderbird/5.0 MIME-Version: 1.0 To: ietf@ietf.org, secdir@ietf.org, iesg@ietf.org, draft-doria-genart-experience.all@tools.ietf.org, gen-art@ietf.org Content-Type: multipart/alternative; boundary="------------070603010908060305070700" Subject: [secdir] Secdir review of draft-doria-genart-experience-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 02:51:15 -0000 This is a multi-part message in MIME format. --------------070603010908060305070700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is informational and covers the experiences of the General Area Review Team. The Security Considerations of the draft are sufficient. The following three comments: 1. minor editorial in section 4.3Form of Review => maybe replace the word "stole" with "derived" or any other word. "Rather than invent new guidelines, the Gen-ART requirements for the form of a review stole liberally from" / "Rather than invent new guidelines, the Gen-ART requirements for the form of a review derived liberally from" 2. Section 12: is it beneficial to list all current members of the Gen-ART per name in the draft? - first are there any privacy issues with that? - when adding or removing people from the team,the list in the I-D might become outdated and give false information on the current status. Would it be more appropriate/easier to update the draft to reference the current list of reviewers (e.g. on a tools web page) instead of listing them in the I-D? 3. Section 10 Security Considerations: is ok so far. On a personal comment/addition: But maybe worth considering is that availability and integrity of sent reviews is also important: I noticed that recently some emails to mail-aliases did not get delivered to the respective lists and therefore reviews and/or answers to reviews might not be received by the individuals on these lists. Unfortunately this happens in some random fashion (for the same sender email and ietf tools aliases within a short time frame, some times it happens some times it doesn't), without a timely warning (but usually with a failure message 3-5 days after the email message has been posted). First investigations may suggest that this could be due to some spam filter or mail server configuration issues, however other reasons might also apply. This can obviously impair the quality of the public review process if individual comments and reviews will not be delivered. Kind regards, Tobias --------------070603010908060305070700 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document is informational and covers the experiences of the General Area Review Team.
The Security Considerations of the draft are sufficient.

The following three comments:
1. minor editorial in section 4.3 Form of Review
=> maybe replace the word "stole" with "derived" or any other word.
"Rather than invent new guidelines, the Gen-ART requirements for the form of a review stole liberally from" / "Rather than invent new guidelines, the Gen-ART requirements for the form of a review derived liberally from"

2. Section 12:
is it beneficial to list all current members of the Gen-ART per name in the draft?
- first are there any privacy issues with that?
- when adding or removing people from the team, the list in the I-D might become outdated and give false information on the current status. Would it be more appropriate/easier to update the draft to reference the current list of reviewers (e.g. on a tools web page) instead of listing them in the I-D?

3. Section 10 Security Considerations:  is ok so far.
On a personal comment/addition:
But maybe worth considering is that availability and integrity of sent reviews is also important:
I noticed that recently some emails to mail-aliases did not get delivered to the respective lists and therefore reviews and/or answers to reviews might not be received by the individuals on these lists.
Unfortunately this happens in some random fashion (for the same sender email and ietf tools aliases within a short time frame, some times it happens some times it doesn't), without a timely warning (but usually with a failure message 3-5 days after the email message has been posted). First investigations may suggest that this could be due to some spam filter or mail server configuration issues, however other reasons might also apply.
This can obviously impair the quality of the public review process if individual comments and reviews will not be delivered.

Kind regards, Tobias




 --------------070603010908060305070700-- From meadows@itd.nrl.navy.mil Mon Aug 1 13:57:49 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158AB1F0C47; Mon, 1 Aug 2011 13:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZvPXGNQ5Zho; Mon, 1 Aug 2011 13:57:48 -0700 (PDT) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4271F0C39; Mon, 1 Aug 2011 13:57:47 -0700 (PDT) Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id p71KvpYm012836; Mon, 1 Aug 2011 16:57:52 -0400 (EDT) Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id p71Kvo3R006886; Mon, 1 Aug 2011 16:57:50 -0400 (EDT) Received: from siduri.fw5540.net ([10.0.3.73]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2011080116574930976 ; Mon, 01 Aug 2011 16:57:49 -0400 From: Catherine Meadows Content-Type: multipart/alternative; boundary=Apple-Mail-12-1065674257 Date: Mon, 1 Aug 2011 17:07:19 -0400 Message-Id: <13293658-6CBF-44D9-8D85-4838FBCDF53C@itd.nrl.navy.mil> To: iesg@ietf.org, secdir@ietf.org, draft-yevstifeyev-ion-report.all@tools.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Tue, 02 Aug 2011 07:31:53 -0700 Cc: Catherine Meadows Subject: [secdir] secdir review of draft-yevstifeyev-ion-report-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 20:57:49 -0000 --Apple-Mail-12-1065674257 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. This draft reports on the IETF Operational Notes Process (ION) process = experiment, which was intended to provide a repository for operational documents = that were intended to stand somewhere between RFC's and Internet Drafts by being less permanent than = RFC's but easier to reference than Internet Drafts. This document describes the RFC's related to this = experiment, and the IONs that were published. It also formally notes the termination of the experiment, and the reason = for its termination: namely that IESG statements and web pages already fulfilled the purpose which IONs were designed for. The = document also gives a description of the subsequent history of the IONs, = all except one of which were re-published in another form. This document does not have much to do with security, since it merely = records the history of the of an experimental method of publishing = documents, and the only issue was that an acceptable method of publishing the = documents already existed. However, I have a little problem with the = statement in the security considerations section that=20 IONs did not include protocol specifications and therefore terminating this series is not believed to have any impact on security of the Internet. I can think of plenty of IETF documents that don't have include protocol = specifications but do have an impact on security, e.g. informational RFC's on best security = practices. I would recommend that the authors instead say that since the it was determined that the = information in IONs could be distributed by other means, terminating this series should not have any impact on security. Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil --Apple-Mail-12-1065674257 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 
I have reviewed =
this document as part of the security directorate's=20
ongoing effort to review all IETF documents being processed by the=20
IESG.  These comments were written primarily for the benefit of the=20
security area directors.  Document editors and WG chairs should treat=20
these comments just like any other last call comments.
  =
This draft reports on the IETF Operational Notes Process (ION) process =
experiment,
which was intended to provide a repository for =
operational documents that were intended to stand
somewhere =
between RFC's and Internet Drafts by being less permanent than RFC's but =
easier to reference
than Internet Drafts.  This document =
describes the RFC's related to this experiment, and the IONs that were =
published.
It also formally notes the termination of the =
experiment, and the reason for its termination: namely that IESG =
statements and web pages
already fulfilled the purpose which =
IONs were designed for.  The document also gives a description of =
the subsequent history of the IONs, all except one of =
which
were re-published in another =
form.

This document does not have much to do =
with security, since it  merely records the history of the of an =
experimental method of publishing documents,
and the only =
issue was that an acceptable method of publishing the documents already =
existed.  However, I have a little problem with the statement in =
the security
considerations section =
that 

IONs did not include protocol =
specifications and therefore
   terminating this =
series is not believed to have any impact on
  =
 security of the Internet.

I can =
think of plenty of IETF documents that don't have include protocol =
specifications but do
have an impact on security, e.g. =
informational RFC's on best security practices.  I would =
recommend
that the authors instead say that since the it was =
determined that the information in IONs could be distributed by other =
means,
terminating this series should not have any impact on =
security.




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

= --Apple-Mail-12-1065674257-- From meadows@itd.nrl.navy.mil Mon Aug 1 14:12:01 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3241C21F8B81; Mon, 1 Aug 2011 14:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8GGwtF4NtFH; Mon, 1 Aug 2011 14:11:59 -0700 (PDT) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by ietfa.amsl.com (Postfix) with ESMTP id 62FDF21F8B80; Mon, 1 Aug 2011 14:11:59 -0700 (PDT) Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id p71LC6tv014464; Mon, 1 Aug 2011 17:12:06 -0400 (EDT) Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id p71LC5jD007688; Mon, 1 Aug 2011 17:12:05 -0400 (EDT) Received: from siduri.fw5540.net ([10.0.3.73]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2011080117120430994 ; Mon, 01 Aug 2011 17:12:04 -0400 From: Catherine Meadows Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-13-1066529069 Date: Mon, 1 Aug 2011 17:21:34 -0400 References: <201108012057.p71KvxYm012838@fw5540.nrl.navy.mil> To: draft-yevstifeyev-ion-report.all@tools.ietf.org, secdir@ietf.org, iesg@ietf.org Message-Id: <379B79DC-4F5E-48CD-979A-AC6CE7C7BF9B@itd.nrl.navy.mil> X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Tue, 02 Aug 2011 07:31:53 -0700 Cc: Catherine Meadows Subject: [secdir] secdir review of draft-yevstifeyev-ion-report-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 21:12:01 -0000 --Apple-Mail-13-1066529069 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Resend of my previous message: I mistyped the tools email address. Cathy I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. This draft reports on the IETF Operational Notes Process (ION) process = experiment, which was intended to provide a repository for operational documents = that were intended to stand somewhere between RFC's and Internet Drafts by being less permanent than = RFC's but easier to reference than Internet Drafts. This document describes the RFC's related to this = experiment, and the IONs that were published. It also formally notes the termination of the experiment, and the reason = for its termination: namely that IESG statements and web pages already fulfilled the purpose which IONs were designed for. The = document also gives a description of the subsequent history of the IONs, = all except one of which were re-published in another form. This document does not have much to do with security, since it merely = records the history of the of an experimental method of publishing = documents, and the only issue was that an acceptable method of publishing the = documents already existed. However, I have a little problem with the = statement in the security considerations section that=20 IONs did not include protocol specifications and therefore terminating this series is not believed to have any impact on security of the Internet. I can think of plenty of IETF documents that don't have include protocol = specifications but do have an impact on security, e.g. informational RFC's on best security = practices. I would recommend that the authors instead say that since the it was determined that the = information in IONs could be distributed by other means, terminating this series should not have any impact on security. Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil Begin forwarded message: > From: Mail Delivery Subsystem > Date: August 1, 2011 4:57:59 PM EDT > To: > Subject: Returned mail: see transcript for details >=20 > The original message was received at Mon, 1 Aug 2011 16:57:52 -0400 = (EDT) > from sun1.fw5540.net [10.0.0.11] >=20 > ----- The following addresses had permanent fatal errors ----- > > (reason: 550 5.1.1 ... = User unknown) >=20 > ----- Transcript of session follows ----- > ... while talking to mail.medispecialty.com.: >>>> RCPT To: > <<< 550 5.1.1 ... User = unknown > 550 5.1.1 ... User unknown > Reporting-MTA: dns; fw5540.nrl.navy.mil > Received-From-MTA: DNS; sun1.fw5540.net > Arrival-Date: Mon, 1 Aug 2011 16:57:52 -0400 (EDT) >=20 > Final-Recipient: RFC822; draft-yevstifeyev-ion-report.all@tools.org > Action: failed > Status: 5.1.1 > Remote-MTA: DNS; mail.medispecialty.com > Diagnostic-Code: SMTP; 550 5.1.1 = ... User unknown > Last-Attempt-Date: Mon, 1 Aug 2011 16:57:59 -0400 (EDT) >=20 > From: Catherine Meadows > Date: August 1, 2011 5:07:19 PM EDT > To: iesg@ietf.org, secdir@ietf.org, = draft-yevstifeyev-ion-report.all@tools.org > Cc: Catherine Meadows > Subject: secdir review of draft-yevstifeyev-ion-report-06 >=20 >=20 --Apple-Mail-13-1066529069 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii catherine.meadows@nrl.navy.= mil





Begin forwarded = message:

From: Mail Delivery Subsystem = <MAILER-DAEMON@fw5540.nrl.navy.mil>
Date: August 1, 2011 = 4:57:59 PM EDT
To: <meadows@itd.nrl.navy.mil>
Subject: Returned mail: = see transcript for details

The original message = was received at Mon, 1 Aug 2011 16:57:52 -0400 (EDT)
from = sun1.fw5540.net [10.0.0.11]

  ----- The following = addresses had permanent fatal errors = -----
<draft-yevstifeyev-ion-report.all@tools.org>
=    (reason: 550 5.1.1 = <draft-yevstifeyev-ion-report.all@tools.org>... User = unknown)

  ----- Transcript of session follows = -----
... while talking to mail.medispecialty.com.:
RCPT = To:<draft-yevstifeyev-ion-report.all@tools.org>
<<< 550 5.1.1 = <draft-yevstifeyev-ion-report.all@tools.org>... User = unknown
550 5.1.1 = <draft-yevstifeyev-ion-report.all@tools.org>... User = unknown
Reporting-MTA: dns; fw5540.nrl.navy.mil
Received-From-MTA: = DNS; sun1.fw5540.net
Arrival-Date: Mon, 1 Aug 2011 16:57:52 -0400 = (EDT)

Final-Recipient: RFC822; = draft-yevstifeyev-ion-report.all@tools.org
Action: failed
Status: = 5.1.1
Remote-MTA: DNS; mail.medispecialty.com
Diagnostic-Code: = SMTP; 550 5.1.1 <draft-yevstifeyev-ion-report.all@tools.org>... = User unknown
Last-Attempt-Date: Mon, 1 Aug 2011 16:57:59 -0400 = (EDT)

From: Catherine Meadows = <meadows@itd.nrl.navy.mil>
Date: August 1, 2011 5:07:19 PM EDT
To: = iesg@ietf.org, secdir@ietf.org, = draft-yevstifeyev-ion-report.all@tools.org
Cc: = Catherine Meadows = <meadows@itd.nrl.navy.mil>
Subject: secdir review of = draft-yevstifeyev-ion-report-06



= --Apple-Mail-13-1066529069-- From jsalowey@cisco.com Tue Aug 2 10:25:58 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94FB411E807F; Tue, 2 Aug 2011 10:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.099 X-Spam-Level: X-Spam-Status: No, score=-105.099 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUFAyJnOPcsJ; Tue, 2 Aug 2011 10:25:58 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id DDEFE11E807B; Tue, 2 Aug 2011 10:25:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=830; q=dns/txt; s=iport; t=1312305968; x=1313515568; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=/wuhDS+q0Pjfif7BxO55hh0Z4HycIMVcnxPOZ0KOOng=; b=HS8cCBLPWOCoRbrTS1+lRwVa2wZHsukD+jkW/8PGefocSc/DQR7WXqd6 8nFFAG7hwfp9WIVn2rXLD/jmZh7wj7aeH42GHBzxQon/nWiF+St+3Dd/O WVqOh4aipHv6Vl2uVZ9n2BemjR7/bhhuTChm3xKj4nVPdvSQznk6px++n 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAGsyOE6rRDoJ/2dsb2JhbABCp2V3gVkBJ4F9ATSoaQGedIVjXwSHWoshhQeLfQ X-IronPort-AV: E=Sophos;i="4.67,307,1309737600"; d="scan'208";a="8886544" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-5.cisco.com with ESMTP; 02 Aug 2011 17:26:07 +0000 Received: from [10.33.249.202] ([10.33.249.202]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p72HQ6uv030845; Tue, 2 Aug 2011 17:26:06 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Aug 2011 10:26:02 -0700 Message-Id: <6B1C78CB-B687-45B1-BA74-1B02FDFCB86D@cisco.com> To: secdir@ietf.org, The IESG , draft-ietf-mpls-lsp-ping-enhanced-dsmap.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [secdir] secdir review of draft-ietf-mpls-lsp-ping-enhanced-dsmap-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 17:25:58 -0000 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. This document describes modifications to LSP Ping to allow it to work = with MPLS tunnels. It is possible that in some cases a provider may not = want to disclose information about tunnels. The security considerations = in the document describe mechanisms to keep this information private. = In addition the security considerations reference RFC 4379 which seems = sufficient. =20 One nit: the first sentence in section 1 is missing a closing = parenthesis.=20 Joe= From ietfdbh@comcast.net Wed Aug 3 13:45:28 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D8B11E8096 for ; Wed, 3 Aug 2011 13:45:28 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZ3yq6ud+RsD for ; Wed, 3 Aug 2011 13:45:27 -0700 (PDT) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by ietfa.amsl.com (Postfix) with ESMTP id DF48711E8090 for ; Wed, 3 Aug 2011 13:45:26 -0700 (PDT) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta11.emeryville.ca.mail.comcast.net with comcast id FwkH1h0071zF43QABwlcRA; Wed, 03 Aug 2011 20:45:36 +0000 Received: from davidPC ([67.189.235.106]) by omta24.emeryville.ca.mail.comcast.net with comcast id FwkW1h00Y2JQnJT8kwkXwY; Wed, 03 Aug 2011 20:44:35 +0000 From: "David Harrington" To: , "'Stephen Hanna'" References: <20110726104135.13472eudbij0eaqs@portland.eukhosting.net> <20110726112346.35893ibie0kwerqc@portland.eukhosting.net> In-Reply-To: <20110726112346.35893ibie0kwerqc@portland.eukhosting.net> Date: Wed, 3 Aug 2011 16:45:24 -0400 Message-ID: <72EB8D918E1340B78140B407CFDF8BAE@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 Thread-index: AcxLhz1rdtZ6yE5iS46ImQV7TaxW6gGgZf0Q Cc: lionel.morand@orange-ftgroup.com, draft-ietf-dime-priority-avps.all@tools.ietf.org, ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-dime-priority-avps-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 20:45:28 -0000 Hi, Documents containing MIB modules must include a discussion of the sensitivity of the tables/objects in the MIB module. This includes the possible impact to the managed technologies that could be caused by an unauthorized or misguided change to a configuration, for example. Certainly the potential impact of using MIB objects to change the relative priority of a managed technology's sessions would need to be included in the read-write security considerations of the MIB module. See https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security Using AVPs in Diameter to affect a similar change to the relative priority of a managed technology's sessions warrants a similar consideration of the sensitivity of the specific AVPs. David Harrington Director, IETF Transport Area Member of SECDIR, OPSDIR, and MIB Doctors directorates ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) > -----Original Message----- > From: secdir-bounces@ietf.org > [mailto:secdir-bounces@ietf.org] On Behalf Of carlberg@g11.org.uk > Sent: Tuesday, July 26, 2011 7:24 AM > To: Stephen Hanna > Cc: lionel.morand@orange-ftgroup.com; > draft-ietf-dime-priority-avps.all@tools.ietf.org; > ietf@ietf.org; secdir@ietf.org > Subject: Re: [secdir] secdir review of > draft-ietf-dime-priority-avps-04 > > Steve, > > > Quoting Stephen Hanna : > > > Thanks for your response, Ken. > > > > Removing the last sentence that you quoted would make things worse. > > Readers of this draft should definitely familiarize themselves with > > the security considerations related to priority. We should make that > > easier, not harder. The fact that those considerations also apply to > > other RFCs does not remove the fact that they apply to this > one also. > > but those considerations do not directly apply to DIAMETER. > > > You cannot publish a document whose security considerations section > > says (as this one effectively does today), "There are lots > of security > > considerations related to this document. To understand them, please > > dig through all the referenced documents and figure it out > yourself." > > Doing that digging and analysis is the job of the document editors. > > agreed, speaking in the general sense. But again, the security > considerations of these other protocols do not apply to the > operation > of Diameter. > > > In order to ease the burden on you, I think a reasonable compromise > > would be for YOU to review the documents referenced and decide which > > have the most relevant security considerations. Then you could list > > those explicitly in the last paragraph of the Security > Considerations. > > I'm concerned about the implications of your recommendation. If we > extend this position to other work in the IETF, then efforts like > defining MIBs would mean that each MIB draft would need to perform a > security considerations analysis of each protocol that an objects > refers to in the context of SNMP. And one can extend the argument > that each protocol operating on top of TCP (and/or UDP) and IP would > need to perform an analysis on how TCP/UDP and IP may affect > the upper > layer protocol. We don't do that today. > > cheers, > > -ken > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > From bew@cisco.com Wed Aug 3 17:33:19 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D87211E80AD for ; Wed, 3 Aug 2011 17:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NVIPwxpuXBw for ; Wed, 3 Aug 2011 17:33:18 -0700 (PDT) Received: from nm14-vm0.access.bullet.mail.sp2.yahoo.com (nm14-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.162]) by ietfa.amsl.com (Postfix) with SMTP id B136121F8A1A for ; Wed, 3 Aug 2011 17:33:18 -0700 (PDT) Received: from [98.139.44.98] by nm14.access.bullet.mail.sp2.yahoo.com with NNFMP; 04 Aug 2011 00:33:31 -0000 Received: from [98.139.44.89] by tm3.access.bullet.mail.sp2.yahoo.com with NNFMP; 04 Aug 2011 00:33:31 -0000 Received: from [127.0.0.1] by omp1026.access.mail.sp2.yahoo.com with NNFMP; 04 Aug 2011 00:33:31 -0000 X-Yahoo-Newman-Id: 856812.12373.bm@omp1026.access.mail.sp2.yahoo.com Received: (qmail 66807 invoked from network); 4 Aug 2011 00:33:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1312418011; bh=GO+MhJKahbyAlZaMN6o650wDPcm8Hxt7fWE34ftbTvU=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=GzD49y8CA//jhUxDfxBjaxuKahbVIMQohep/89w6G7OXEgygR69zkMQItn4lf6gEY6tntbLNJsudPprY/WOVMs42KbMT0VT9hJYeWqF/37k9JFM9dQq5n81KWIHJ6lzx7qCBkYj7i+VxZw8vjgchwViHX2hITVRnotIVXAoYl9E= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: uPaRxfIVM1kn_E6BO_MeaKKbxbVIIvaKDXCh3BAkR3eVE7K a82unTc2oaj5eR6Va01SF.eshziem6PXt0p0mO6DLVZxiE7z1hrgfHWl6TR8 mvSU8YVCS1awmZn0S2CWxV3UiSKD8rejx.8SoAL6DoLsMvgSh2t.L0R59ePQ vdMjbUC7aVa4t7bFgOSxzNOLwk2Zha_yqSvTNdKMRB7c4lLVA4hZ81X6ISNu G3efVCiq64sY_4Xxu36sQufVm13jR1bbYRO7IRGVduVsDq3TSLHneTjFFdVx BEbcSCEGP1RLLucTGUZg2IDWJ7BPKAhOKoHv5y0uXck6q2a9iu0309itIFo6 5PljGxjOE9XWYIvdHHHpIjvi3PYT7bjlaSFwQP0GfDmyWz_z2oTnr5I378g0 59EuhWrc.3PVAHDXgYj3qxDAoK8mE33w93U0US9psQNL_ X-Yahoo-SMTP: 32nDaXmswBB_JniSOQ0NY72Nq.3.ushdrbBADol90kQ- Received: from stealth-10-32-244-210.cisco.com (bew@70.239.230.164 with plain) by smtp107.sbc.mail.gq1.yahoo.com with SMTP; 03 Aug 2011 17:33:31 -0700 PDT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Weis In-Reply-To: Date: Wed, 3 Aug 2011 17:33:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8B61042D-0BB4-42EA-970B-DDA36A659DA9@cisco.com> References: To: Sam Hartman X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-msec-gdoi-update@tools.ietf.org, ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-msec-gdoi-update X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 00:33:19 -0000 Hi Sam, Thanks for your review. Your first comment is pointing out a typo (groupkey-pull should be = groupkey-push), which I've fixed. The anti-replay description in Section 3.3 should not say that the push = message sequence number will be reset to 1. Text earlier in this section = says that the SEQ payload carries the next expected sequence number, and = so when the KEK is installed that is the number that should be = installed. I've adjusted the text to say this: "If this group has a KEK, = the KEK policy and keys are marked as ready for use and the GM knows to = expect a sequence number not less than the one distributed in the SEQ = payload." Let me know if that change sufficiently clears up the = confusion. Thanks, Brian On Aug 1, 2011, at 9:51 AM, Sam Hartman wrote: >=20 > This update to the GDOI specification significantly improves clarity = and > readability. > However, there is one issue that I think should be addressed prior to > publication: >=20 >=20 > At the top of page 11, the spec claims that a seq payload protects > against group members responding to groupkey-pull messages sent prior = to > joining the group. > I'm reasonably sure that should be groupkey-push messages; I believe = the > nonce payloads provide replay protection for the pull exchange. >=20 > Actually, it's more complicated than that. Section 3.3 also seems to > believe the sequence number is about pull exchanges. However it says > that a GM should always expect the push message sequence number to be > reset to 1. > Why is that reasonable? If a group is ongoing, don't we want to tell = new > members what the sequence number currently is rather than having them > assume it is 1? The push message is multicast, so we cannot maintain a > separate sequence number for each member. >=20 > I think either there is some sort of error with the description of the > replay mechanisms or it requires significantly more explanation. > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --=20 Brian Weis Security Standards and Technology, SRTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From hartmans@mit.edu Thu Aug 4 06:25:19 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AAC121F8A1A; Thu, 4 Aug 2011 06:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.985 X-Spam-Level: X-Spam-Status: No, score=-103.985 tagged_above=-999 required=5 tests=[AWL=-1.720, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id po6YCBo4zDpF; Thu, 4 Aug 2011 06:25:19 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id F1AFA21F89C2; Thu, 4 Aug 2011 06:25:18 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 19301201C7; Thu, 4 Aug 2011 09:28:14 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 461134234; Thu, 4 Aug 2011 09:25:22 -0400 (EDT) From: Sam Hartman To: Brian Weis References: <8B61042D-0BB4-42EA-970B-DDA36A659DA9@cisco.com> Date: Thu, 04 Aug 2011 09:25:22 -0400 In-Reply-To: <8B61042D-0BB4-42EA-970B-DDA36A659DA9@cisco.com> (Brian Weis's message of "Wed, 3 Aug 2011 17:33:30 -0700") 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-msec-gdoi-update@tools.ietf.org, Sam Hartman , ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-msec-gdoi-update X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 13:25:19 -0000 >>>>> "Brian" == Brian Weis writes: Brian> Hi Sam, Thanks for your review. Brian> Your first comment is pointing out a typo (groupkey-pull Brian> should be groupkey-push), which I've fixed. Brian> The anti-replay description in Section 3.3 should not say Brian> that the push message sequence number will be reset to Brian> 1. Text earlier in this section says that the SEQ payload Brian> carries the next expected sequence number, and so when the Brian> KEK is installed that is the number that should be Brian> installed. I've adjusted the text to say this: "If this group Brian> has a KEK, the KEK policy and keys are marked as ready for Brian> use and the GM knows to expect a sequence number not less Brian> than the one distributed in the SEQ payload." Let me know if Brian> that change sufficiently clears up the confusion. Yes, all looks good. The typo plus the text in 3e.3 caused me to wonder whether something more complex than I had anticipated was going on with replay. The new text is quite clear. From nitinb@juniper.net Tue Aug 2 10:43:40 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F83311E80AC; Tue, 2 Aug 2011 10:43:40 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+H8hBHkwU71; Tue, 2 Aug 2011 10:43:39 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5D77811E807F; Tue, 2 Aug 2011 10:43:35 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTjg3TwakdAT6qWBFxpwv0sxuc8oxbgWq@postini.com; Tue, 02 Aug 2011 10:43:49 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 2 Aug 2011 10:42:39 -0700 From: Nitin Bahadur To: Joe Salowey , "secdir@ietf.org" , The IESG , "draft-ietf-mpls-lsp-ping-enhanced-dsmap.all@tools.ietf.org" Date: Tue, 2 Aug 2011 10:42:37 -0700 Thread-Topic: secdir review of draft-ietf-mpls-lsp-ping-enhanced-dsmap-10 Thread-Index: AcxROUtATAhp5ZDQQ3KcFelWnqIRjQAAkYTr Message-ID: In-Reply-To: <6B1C78CB-B687-45B1-BA74-1B02FDFCB86D@cisco.com> Accept-Language: en-US Content-Language: en 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: Thu, 04 Aug 2011 08:03:41 -0700 Subject: Re: [secdir] secdir review of draft-ietf-mpls-lsp-ping-enhanced-dsmap-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 17:43:40 -0000 Thanks Joe for your review. I will address the nit. Nitin On 8/2/11 10:26 AM, "Joe Salowey" 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 modifications to LSP Ping to allow it to work with = MPLS tunnels. It is possible that in some cases a provider may not want to= disclose information about tunnels. The security considerations in the do= cument describe mechanisms to keep this information private. In addition = the security considerations reference RFC 4379 which seems sufficient. One nit: the first sentence in section 1 is missing a closing parenthesis. Joe From new-work-bounces@ietf.org Wed Aug 3 09:17:51 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA07C21F873D; Wed, 3 Aug 2011 09:17:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1312388271; bh=UtGtFUDoXUwN5V7mSc6/vQGk3ditmAtt65QkAoLCbsA=; h=From:Date:To:Message-Id:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=KiUnMV6DqgsqpEPnmFQNqpak6lAaTVQOXJYwLT7g+0fWuJZc2t2h+pdnHhqvKQG03 qi8Q+TRbNbzNawWdMDH9zlC1axzUo8/oWjBiJ7XXXE0qKxnkUzwF0iUpjTOk4ECRFF 8QhRxvGrrzSIIlYgJj6TjqZ+uCfZaqDMunDZm9xs= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67CC021F873D for ; Wed, 3 Aug 2011 09:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.189 X-Spam-Level: X-Spam-Status: No, score=-10.189 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwA+JYP5dHeI for ; Wed, 3 Aug 2011 09:17:50 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id E38FC21F86B6 for ; Wed, 3 Aug 2011 09:17:49 -0700 (PDT) Received: from localhost ([127.0.0.1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Qoe8v-0002Y4-ER; Wed, 03 Aug 2011 12:18:01 -0400 From: Ian Jacobs Date: Wed, 3 Aug 2011 11:18:01 -0500 To: new-work@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 04 Aug 2011 08:03:41 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Model-Based UI Working Group (until 2011-08-31) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 16:17:52 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Ubiquitous Web Applications Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Model-Based UI Working Group: http://www.w3.org/2011/01/mbui-wg-charter 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-08-31 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 Dave Raggett, Team Contact . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/2007/uwa/Activity.html [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 weiler@watson.org Fri Aug 5 07:45:25 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B4421F8C06 for ; Fri, 5 Aug 2011 07:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3cz5XRIMHGJ for ; Fri, 5 Aug 2011 07:45:25 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE2F21F8B8D for ; Fri, 5 Aug 2011 07:45:25 -0700 (PDT) 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 p75EjgQH003922 for ; Fri, 5 Aug 2011 10:45:42 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p75EjfxQ003918 for ; Fri, 5 Aug 2011 10:45:42 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 5 Aug 2011 10:45:41 -0400 (EDT) From: Samuel Weiler 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, 05 Aug 2011 10:45:42 -0400 (EDT) Subject: [secdir] assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 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, 05 Aug 2011 14:45:25 -0000 One new assignment (to Russ Mundy), and one doc added to the telehcat agenda (assigned to J. Hutz). Otherwise, things are pretty much unchanged from Monday. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Sandy Murphy is next in the rotation. For telechat 2011-08-11 Reviewer LC end Draft Derek Atkins T 2011-07-04 draft-ietf-roll-of0-15 Rob Austein T 2011-07-18 draft-shiomoto-ccamp-switch-programming-05 Alan DeKok T 2011-07-11 draft-ietf-mpls-mldp-recurs-fec-04 Love Hornquist-Astrand T 2011-07-15 draft-ietf-softwire-dslite-radius-ext-04 Jeffrey Hutzelman T 2011-07-22 draft-ietf-p2psip-base-18 Stephen Kent TR2011-08-01 draft-ietf-tsvwg-rsvp-security-groupkeying-10 Matt Lepinski TR2011-07-13 draft-burgin-ipsec-suiteb-profile-01 Carl Wallace T 2011-07-21 draft-forte-lost-extensions-07 Sam Weiler T 2011-07-20 draft-gutmann-cms-hmac-enc-05 For telechat 2011-08-25 Reviewer LC end Draft Chris Lonvick T 2011-08-12 draft-ietf-pim-hello-intid-01 Russ Mundy T 2011-08-15 draft-ietf-v6ops-3gpp-eps-03 Ondrej Sury T 2011-06-30 draft-ietf-sidr-rescerts-provisioning-10 Last calls and special requests: Reviewer LC end Draft Scott Kelly 2011-08-22 draft-dijkstra-urn-ogf-06 Stephen Kent 2011-08-15 draft-ietf-karp-threats-reqs-03 Tero Kivinen 2011-08-26 draft-gundavelli-v6ops-pmipv6-address-reservations-00 Warren Kumari 2011-08-12 draft-ietf-krb-wg-clear-text-cred-01 Julien Laganier 2011-08-12 draft-ietf-lisp-lig-03 Barry Leiba 2011-08-12 draft-ietf-mpls-rsvp-te-no-php-oob-mapping-08 Matt Lepinski 2011-08-16 draft-ietf-ospf-auth-trailer-ospfv3-05 David McGrew 2011-08-24 draft-kivinen-ipsecme-secure-password-framework-01 Catherine Meadows R2011-04-13 draft-ietf-speechsc-mrcpv2-25 Kathleen Moriarty - draft-ietf-hybi-thewebsocketprotocol-10 Russ Mundy 2011-06-30 draft-ietf-karp-design-guide-03 Tim Polk 2011-05-11 draft-ietf-vrrp-unified-mib-09 Tina TSOU 2011-04-23 draft-shin-augmented-pake-08 Glen Zorn 2011-06-28 draft-li-pwe3-ms-pw-pon-04 From carl@redhoundsoftware.com Fri Aug 5 13:28:22 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2F611E80BB; Fri, 5 Aug 2011 13:28:22 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWacSnKZN3nI; Fri, 5 Aug 2011 13:28:21 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 00C4111E80B2; Fri, 5 Aug 2011 13:28:20 -0700 (PDT) Received: by yxp4 with SMTP id 4so2293529yxp.31 for ; Fri, 05 Aug 2011 13:28:39 -0700 (PDT) Received: by 10.90.241.5 with SMTP id o5mr9935agh.187.1312576119129; Fri, 05 Aug 2011 13:28:39 -0700 (PDT) Received: from [192.168.1.42] (cpe-67-242-104-93.stny.res.rr.com [67.242.104.93]) by mx.google.com with ESMTPS id s13sm2420778anm.6.2011.08.05.13.28.37 (version=SSLv3 cipher=OTHER); Fri, 05 Aug 2011 13:28:38 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Fri, 05 Aug 2011 16:28:33 -0400 From: Carl Wallace To: "secdir@ietf.org" , "iesg@ietf.org" Message-ID: Thread-Topic: secdir review of draft-forte-lost-extensions-06.txt Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: draft-forte-lost-extensions.all@tools.ietf.org Subject: [secdir] secdir review of draft-forte-lost-extensions-06.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 20:28: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 draft defines extensions to the LoST protocol defined in RFC 5222. Where RFC 5222 focuses on emergency services. This draft addresses usage of the protocol for non-emergency services. The draft adds three new types of queries: N nearest, within distance X and servedBy. The security considerations section is very brief and primarily addresses potential problems with a LOST server that provides emergency and non-emergency service support being over loaded by non-emergency requests. A few additional concerns that may warrant mention in the document are below. Privacy is not mentioned in this draft at all. RFC 5222 mentions using HTTP over TLS. Queries for some types of non-emergency services may raise privacy concerns not associated with seeking emergency services. Similarly, the draft does not mention integrity. The lack of privacy or integrity for responses residing in a cache may be worth mentioning as well. The draft does not discuss error handling at all. Some types of errors associated with the extensions do not seem to fit into the errors described in RFC 5222. For example, could a server return an error when a requested area was too large for a query? Is the server allowed to place its own limits less than a client requests? These concerns may not arise in the 5222 context, where non-overlapping service regions are a mitigation. Given the commercial focus of the draft, the potential for stale information to be returned by a server seems high and probably worth a mention. For example, a pizza service may have closed. Services are identified by URN. RFC 5222 uses URNs defined in RFC 5031, which does not apply here. Who manages the URNs for this draft? It's worth noting the examples within this draft use different URNs to reference the important pizza service. A few nits, on page 11 correct "consinstent". Also the next to last paragraph on page 11 is a little difficult to parse. From kivinen@iki.fi Sun Aug 7 12:41:40 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB94C21F87C9; Sun, 7 Aug 2011 12:41:40 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gh1Q7Hhjhkl; Sun, 7 Aug 2011 12:41:40 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1898C21F8752; Sun, 7 Aug 2011 12:41:39 -0700 (PDT) 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 p77JfsXU012836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Aug 2011 22:41:54 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p77Jfr0B018012; Sun, 7 Aug 2011 22:41:53 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20030.60033.707219.106399@fireball.kivinen.iki.fi> Date: Sun, 7 Aug 2011 22:41:53 +0300 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 5 min Cc: draft-gundavelli-v6ops-pmipv6-address-reservations.all@tools.ietf.org Subject: [secdir] Review of draft-gundavelli-v6ops-pmipv6-address-reservations-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2011 19:41:41 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document does two IANA allocations, one for the reserved IPv6 interface identifier for Proxy Mobile IPv6 and another for the reserved IANA Ethernet unicast address for the Proxy Mobile IPv6. The security considerations section points to the Proxy Mobile IPv6 RFC (RFC5213) and Reserved IPv6 Interface Identifiers RFC (RFC 5453) saying there is no additional security considerations known at this point of time beyond them. Only thing that seems bit odd, that there is no obvious point where the allocated reserved IANA values would be inserted, so I do not know whether the final values will be put to the RFC or whether users of them need to go to the IANA registries to find the values. If users are required to find the values from the IANA registries, adding direct pointer to the registry might be useful. -- kivinen@iki.fi From kivinen@iki.fi Mon Aug 8 00:24:43 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2472C21F8749; Mon, 8 Aug 2011 00:24:43 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odupWkNbpQB1; Mon, 8 Aug 2011 00:24:42 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5354321F8747; Mon, 8 Aug 2011 00:24:41 -0700 (PDT) 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 p787OvGn026559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Aug 2011 10:24:57 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p787Ouju029088; Mon, 8 Aug 2011 10:24:56 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20031.36679.939388.184818@fireball.kivinen.iki.fi> Date: Mon, 8 Aug 2011 10:24:55 +0300 From: Tero Kivinen To: Sri Gundavelli In-Reply-To: References: <20030.60033.707219.106399@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 1 min Cc: draft-gundavelli-v6ops-pmipv6-address-reservations.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-gundavelli-v6ops-pmipv6-address-reservations-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 07:24:43 -0000 Sri Gundavelli writes: > Thanks for your review. This document upon getting published should stand as > the reference for the assigned/reserved values. The below IANA section > should reflect the assigned/reserved values. It also identifies the > registries from which the value will be assigned. I would have assume those actions items to have disappear from the final document after they been done. > Probably, the main section of the document can also reflect the assigned > value. It currently says, the values will be assigned, but the following > rewording should make it more clear. > > ---- > OLD: > This specification reserves an IPv6 interface identifier for Proxy Mobile > IPv6 [RFC5213]. > > NEW: > This specification reserves the IPv6 interface identifier, , for the > use of Proxy Mobile IPv6 [RFC5213]. > --- > OLD: > Furthermore, this specification also reserves a IANA Ethernet unicast > address for Proxy Mobile IPv6 use. > > NEW: > Furthermore, this specification also reserves the Ethernet unicast address, > IANA-2, for the use of Proxy Mobile IPv6. > ---- > > Does this help ? Yes. -- kivinen@iki.fi From mlepinski@bbn.com Mon Aug 8 06:33:08 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A49E221F8A69 for ; Mon, 8 Aug 2011 06:33:08 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FiIzY+NkVPnr for ; Mon, 8 Aug 2011 06:33:08 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1FB21F86AB for ; Mon, 8 Aug 2011 06:33:07 -0700 (PDT) Received: from [128.89.254.201] (port=4693) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QqPxV-000LSR-J8 for secdir@ietf.org; Mon, 08 Aug 2011 09:33:33 -0400 Message-ID: <4E3FE5C8.10107@bbn.com> Date: Mon, 08 Aug 2011 09:34:00 -0400 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: secdir@ietf.org References: <4E209E78.9040804@bbn.com> In-Reply-To: <4E209E78.9040804@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [secdir] Secdir review of draft-burgin-ipsec-suiteb-profile X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 13:33:08 -0000 I just read the -01 version of this draft, and the changes have addressed the comments I made in the review of the -00 version. - Matt Lepinski On 7/15/2011 4:09 PM, Matt Lepinski 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 informational document defines a profile of behavior that IPsec > implementations must adhere in order to be Suite B compliant. The > authors claim that this profile does not introduce any new security > concerns that are not already covered in existing RFCs on IPsec, IKE, > and their use with ECDSA (i.e., RFCs 4303, 4754, 5759, 5996). After > reviewing this document, I would agree with this assessment. > > --------------------- > > The following are specific comments based on my review of the document: > > In Section 3, there is a table that includes the heading "IANA > assigned DH group #", which is a bit unclear. I would recommend > inserting text below the table that indicates the specific IANA > registry to which the table refers. In this case, it is the IANA > registry of IKEv2 Diffie-Hellman Group Transform IDs (Transform Type > 4) ... see http://www.iana.org/assignments/ikev2-parameters > > In the second paragraph of Section 5, in the context of > implementations that are configured with a minimum level of security > of 128 bits, the draft has the following text: "Suite-B-GCM-128 and > Suite-B-GMAC-128, if offered, must appear in the IKEv2 and IPsec SA > payloads before any offerings of Suite-B-GCM-256 and > Suite-B-GMAC-256". This appears to be the only lower-case "must" in > the document, and lower-case "must" in this type of specification can > be confusing to implementers. There seems to be no security or > interoperability reason why one would place the 128 suites first. > Indeed, the reason for this requirement seems to be to prevent systems > with a minimum security level of 128 bits from agreeing on a 256 suite > (which I would suppose is for efficiency reasons???). Therefore, I > would suggest that the authors replace the lower-case "must" with a > capital "SHOULD". Alternatively, if the authors believe that the use > of normative language here is inappropriate, then I would recommend > rephrasing the sentence so as to avoid the use of the word "must". > > Since Suite B compliant IPsec implementations use Elliptic Curve > Diffe-Hellman for key exchange within IKE, the authors should consider > adding a reference to RFC 5903. > > The IANA considerations section is currently listed as "TBD". I would > recommend the authors include a sentence indicating that this document > makes no requests of IANA (or else remove the section completely). > > > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > From sgundave@cisco.com Sun Aug 7 18:43:31 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0128B21F87FA; Sun, 7 Aug 2011 18:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.069 X-Spam-Level: X-Spam-Status: No, score=-3.069 tagged_above=-999 required=5 tests=[AWL=-0.470, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPAxzgjoPF7r; Sun, 7 Aug 2011 18:43:30 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5519A21F87F0; Sun, 7 Aug 2011 18:43:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=3186; q=dns/txt; s=iport; t=1312767835; x=1313977435; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=mhsRD6htGvGaJ8QMZP1mhT8PadmV7k0qmUtxgPxK+Gc=; b=lFAnHBVEZ5ffcJMQUamtv5lPEY7xXEfmBAMfyEDFhsXLwjeRLE59ByTf EAw0bAVcwVbLxJYARg0/CLN3AxU/72Xqk2+UzbhPA8uPl840eqZfNywAk 5c0wYXMdL/IxrrOpkK/VzZmHkDNBIkkjdLR33kyBu1egzG0iRpiSS23yP U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAAg/P06rRDoI/2dsb2JhbABCpzV3gUABAQEBAgESAScCATwFDQEIgR0BAQQBDQUih0ucUAGdTIZGBIdciyaFEYt3 X-IronPort-AV: E=Sophos;i="4.67,334,1309737600"; d="scan'208";a="10639075" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-4.cisco.com with ESMTP; 08 Aug 2011 01:43:53 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p781hrA4002617; Mon, 8 Aug 2011 01:43:53 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 7 Aug 2011 18:43:53 -0700 Received: from 10.32.246.212 ([10.32.246.212]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Mon, 8 Aug 2011 01:43:52 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Sun, 07 Aug 2011 18:43:54 -0700 From: Sri Gundavelli To: Tero Kivinen , , Message-ID: Thread-Topic: Review of draft-gundavelli-v6ops-pmipv6-address-reservations-00 Thread-Index: AcxVbKFsELdODFTpp0+9wSeQYlI+Uw== In-Reply-To: <20030.60033.707219.106399@fireball.kivinen.iki.fi> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 08 Aug 2011 01:43:53.0093 (UTC) FILETIME=[A0E28350:01CC556C] X-Mailman-Approved-At: Mon, 08 Aug 2011 08:47:26 -0700 Cc: draft-gundavelli-v6ops-pmipv6-address-reservations.all@tools.ietf.org Subject: Re: [secdir] Review of draft-gundavelli-v6ops-pmipv6-address-reservations-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 01:43:31 -0000 Hi Tero: > Only thing that seems bit odd, that there is no obvious point where > the allocated reserved IANA values would be inserted, so I do not know > whether the final values will be put to the RFC or whether users of > them need to go to the IANA registries to find the values. If users > are required to find the values from the IANA registries, adding > direct pointer to the registry might be useful. Thanks for your review. This document upon getting published should stand as the reference for the assigned/reserved values. The below IANA section should reflect the assigned/reserved values. It also identifies the registries from which the value will be assigned. " This document requires the following two IANA actions. o Action-1: This specification reserves an IPv6 interface identifier for Proxy Mobile IPv6 [RFC5213]. This fixed identifier needs to be reserved from the registry, "Reserved IPv6 Interface Identifiers". o Action-2: This specification reserves a IANA Ethernet unicast address for Proxy Mobile IPv6. This address needs to be reserved from the block. "IANA Ethernet Address block - Unicast Use". " Probably, the main section of the document can also reflect the assigned value. It currently says, the values will be assigned, but the following rewording should make it more clear. ---- OLD: This specification reserves an IPv6 interface identifier for Proxy Mobile IPv6 [RFC5213]. NEW: This specification reserves the IPv6 interface identifier, , for the use of Proxy Mobile IPv6 [RFC5213]. --- OLD: Furthermore, this specification also reserves a IANA Ethernet unicast address for Proxy Mobile IPv6 use. NEW: Furthermore, this specification also reserves the Ethernet unicast address, IANA-2, for the use of Proxy Mobile IPv6. ---- Does this help ? Regards Sri On 8/7/11 12:41 PM, "Tero Kivinen" 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 does two IANA allocations, one for the reserved IPv6 > interface identifier for Proxy Mobile IPv6 and another for the > reserved IANA Ethernet unicast address for the Proxy Mobile IPv6. The > security considerations section points to the Proxy Mobile IPv6 RFC > (RFC5213) and Reserved IPv6 Interface Identifiers RFC (RFC 5453) > saying there is no additional security considerations known at this > point of time beyond them. > > Only thing that seems bit odd, that there is no obvious point where > the allocated reserved IANA values would be inserted, so I do not know > whether the final values will be put to the RFC or whether users of > them need to go to the IANA registries to find the values. If users > are required to find the values from the IANA registries, adding > direct pointer to the registry might be useful. From clonvick@cisco.com Mon Aug 8 13:52:14 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF4B21F884E; Mon, 8 Aug 2011 13:52:14 -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=[AWL=-4.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTNQUq14HcwA; Mon, 8 Aug 2011 13:52:13 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id A1BA821F8841; Mon, 8 Aug 2011 13:52:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=clonvick@cisco.com; l=1177; q=dns/txt; s=iport; t=1312836760; x=1314046360; h=date:from:to:subject:message-id:mime-version; bh=ER2mIDbbrPIIYo6NmfFrz+PeqKnpGSjR6KI/YekfhNY=; b=DcqoVjw5a1EuiUgqw6EcQEc1XvA9PSteW9CKwHBB36kiW1g0AiP3hEYj OA0uhYcow5ezUqK37Ss6Q02kBMD2jxvtzZilljdhx0+5ftvEZidMW50JZ MutyAunB6n1+JHuTmiQIZlXInKNhkipKds7ZwuSVKfYEaEUycrsrw/+NB 4=; X-IronPort-AV: E=Sophos;i="4.67,339,1309737600"; d="scan'208";a="10981856" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-5.cisco.com with ESMTP; 08 Aug 2011 20:52:40 +0000 Received: from sjc-cde-021.cisco.com (sjc-cde-021.cisco.com [171.69.20.56]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p78Kqdqw009359; Mon, 8 Aug 2011 20:52:39 GMT Date: Mon, 8 Aug 2011 13:52:39 -0700 (PDT) From: Chris Lonvick To: iesg@ietf.org, secdir@ietf.org, draft-ietf-pim-hello-intid-01.all@tools.ietf.org, Michael McBride Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [secdir] SecDir review of draft-ietf-pim-hello-intid-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 20:52:14 -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. Overall I find the document to be of good quality and I agree that the security considerations section is adequate. While PIM is certainly not my strong suit the document is understandable except for the following paragraph from Section 2.1: The Local Interface Identifier MUST be non-zero. The reason for this, is that some protocols may want to only optionally refer to an Interface using the Interface Identifier Hello option, and use the value of 0 to show that it is not referred to. Note that the value of 0 is not a valid ifIndex as defined in [RFC1213]. This seems to be saying that the Local Interface Identifier must not be 0, except when some protocol wants to use the Interface Identifier Hello to not refer to any actual interface. Which leaves me confused. Regards, Chris From clonvick@cisco.com Mon Aug 8 13:58:58 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F78311E80B4; Mon, 8 Aug 2011 13:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adBUiUwSD-Fv; Mon, 8 Aug 2011 13:58:57 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id BB55F11E80AE; Mon, 8 Aug 2011 13:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=clonvick@cisco.com; l=1605; q=dns/txt; s=iport; t=1312837165; x=1314046765; h=date:from:to:subject:in-reply-to:message-id:references: mime-version; bh=oprCJ30nEMsOIenroh/j/jelL9PpgFIgSSPXXutWYD8=; b=AdpHar2DDx7kTSu2S/p5u8KhpguZ1nAKA7d/eq+JCVWMDQy1ad+h0+vx wOraeX/b2pI4+VmuUXBBpO7J2dEPog0fgWCg/NYEXkN7+FqeKnHBeMAiz taszB9hKEkUxkylenyatliL6fxwV7xH23r+IWpV17o9blss1Lu0sAaCsV 4=; X-IronPort-AV: E=Sophos;i="4.67,339,1309737600"; d="scan'208";a="10984562" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-5.cisco.com with ESMTP; 08 Aug 2011 20:59:24 +0000 Received: from sjc-cde-021.cisco.com (sjc-cde-021.cisco.com [171.69.20.56]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p78KxNeG029466; Mon, 8 Aug 2011 20:59:23 GMT Date: Mon, 8 Aug 2011 13:59:23 -0700 (PDT) From: Chris Lonvick To: iesg@ietf.org, secdir@ietf.org, draft-ietf-pim-hello-intid.all@tools.ietf.org, Michael McBride In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [secdir] SecDir review of draft-ietf-pim-hello-intid-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 20:58:58 -0000 Hi, Resending because I keep forgetting to remove the "-xx" from the document title to make the mailer happy. Thanks, Chris On Mon, 8 Aug 2011, Chris Lonvick wrote: > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > Overall I find the document to be of good quality and I agree that the > security considerations section is adequate. > > While PIM is certainly not my strong suit the document is understandable > except for the following paragraph from Section 2.1: > > The Local Interface Identifier MUST be non-zero. The reason for > this, is that some protocols may want to only optionally refer to an > Interface using the Interface Identifier Hello option, and use the > value of 0 to show that it is not referred to. Note that the value > of 0 is not a valid ifIndex as defined in [RFC1213]. > > This seems to be saying that the Local Interface Identifier must not be 0, > except when some protocol wants to use the Interface Identifier Hello to not > refer to any actual interface. Which leaves me confused. > > Regards, > Chris > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > From warren@kumari.net Mon Aug 8 20:06:38 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953E211E808F; Mon, 8 Aug 2011 20:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OteLJ7j7UFb7; Mon, 8 Aug 2011 20:06:38 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED2211E8070; Mon, 8 Aug 2011 20:06:37 -0700 (PDT) Received: from [192.168.1.4] (24-104-73-2-ip-static.hfc.comcastbusiness.net [24.104.73.2]) by vimes.kumari.net (Postfix) with ESMTPSA id 3ED961B40CC6; Mon, 8 Aug 2011 23:07:04 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Aug 2011 20:07:02 -0700 Message-Id: To: secdir@ietf.org, iesg@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: draft-yount-krb-cred-clear-text.all@tools.ietf.org Subject: [secdir] secdir review of draft-yount-krb-cred-clear-text-01.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 03:06:38 -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 formalizes the unencrypted form of the KRB-CRED message. I am not a Kerberos expert (nor do I play one on TV) so this review is = going to have limited value. I am unclear as to whether there is a need for this facility -- there = could be additional explanation and justification for why this is = needed. Assuming that there is a need for this, the document seems well = written. The Security Considerations section outlines risks incurred by not = having encryption, and specifies that this must only be used with a = transport such as TLS that provides integrity and confidentiality. What = is unclear from the security considerations section is that this = transport must provide end to end security -- for example an IPSec VPN = provides "a transport where sender and recipient identities can been = established be known to each other and provides confidentiality and = integrity.", but presumably the intent is that the encryption be between = the applications -- IMO this should be clarified.=20 I feel that there should advice provided regarding under what conditions = use of this is appropriate -- but, than again, maybe this is obvious to = someone who actually understands Kerberos :-P Nit: Section 3: s/MUST BE/MUST be/ W From kathleen.moriarty@emc.com Tue Aug 9 06:43:39 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B8B21F8A7B for ; Tue, 9 Aug 2011 06:43:39 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYn+p-vpT6lv for ; Tue, 9 Aug 2011 06:43:39 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id D510B21F8A62 for ; Tue, 9 Aug 2011 06:43:38 -0700 (PDT) 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 p79Di3Pn011147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Aug 2011 09:44:04 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Tue, 9 Aug 2011 09:40:51 -0400 Received: from mxhub18.corp.emc.com (mxhub18.corp.emc.com [10.254.93.47]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p79DejYK009416; Tue, 9 Aug 2011 09:40:50 -0400 Received: from mx06a.corp.emc.com ([169.254.1.199]) by mxhub18.corp.emc.com ([10.254.93.47]) with mapi; Tue, 9 Aug 2011 09:40:49 -0400 From: To: , Date: Tue, 9 Aug 2011 09:40:48 -0400 Thread-Topic: Review of draft-ietf-hybi-thewebsocketprotocol-10 Thread-Index: AcxWmfJhGmz5s5NJRjOvSfjSk3FwEA== 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 Cc: ifette+ietf@google.com Subject: [secdir] Review of draft-ietf-hybi-thewebsocketprotocol-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 13:43: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. Description: The WebSocket protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g. using XMLHttpRequest or