From salvatore.dantonio@uniparthenope.it Mon Dec 3 09:15:24 2012 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 3803721F85A8; Mon, 3 Dec 2012 09:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.73 X-Spam-Level: X-Spam-Status: No, score=0.73 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MSGID_MULTIPLE_AT=1.449] 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 ShmgJVv2guqy; Mon, 3 Dec 2012 09:15:23 -0800 (PST) Received: from mail.uniparthenope.it (mail.uniparthenope.it [192.167.9.244]) by ietfa.amsl.com (Postfix) with ESMTP id 18B7A21F84F2; Mon, 3 Dec 2012 09:15:23 -0800 (PST) Received: from mail2.uniparthenope.it (unknown [10.1.2.108]) by mail.uniparthenope.it (Postfix) with SMTP id B5AD817B27; Mon, 3 Dec 2012 17:15:16 +0000 (UTC) Received: from (unknown [192.168.241.108]) by mail2.uniparthenope.it with smtp id 1dea_01c2a350_3d6d_11e2_9101_001372515a5c; Mon, 03 Dec 2012 18:15:15 +0100 Received: from spamk.uniparthenope.it (localhost [127.0.0.1]) by spamk.uniparthenope.it (Postfix) with ESMTP id E4C33C4321; Mon, 3 Dec 2012 19:10:41 +0100 (CET) Received: by spamk.uniparthenope.it (Postfix, from userid 500) id DFB39C432A; Mon, 3 Dec 2012 19:10:41 +0100 (CET) Received: from mail.uniparthenope.it (mail.uniparthenope.it [192.167.9.244]) by spamk.uniparthenope.it (Postfix) with ESMTP id 58D8FC4321; Mon, 3 Dec 2012 19:10:40 +0100 (CET) Received: from saldantoPC (unknown [10.100.8.114]) (Authenticated sender: salvatore.dantonio@uniparthenope.it) by mail.uniparthenope.it (Postfix) with ESMTPA id A57F317B27; Mon, 3 Dec 2012 18:15:14 +0100 (CET) From: "Salvatore D'Antonio" To: "'Dan Harkins'" , , , References: <8b9118710c0f73581afe12789d16ae07.squirrel@www.trepanning.net> In-Reply-To: <8b9118710c0f73581afe12789d16ae07.squirrel@www.trepanning.net> Date: Mon, 3 Dec 2012 18:15:11 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0XeuKsveHPkm4QR9GS45mvKevCKi5+4HJw Content-Language: it Message-ID: <004601cdd179$c328c750$497a55f0$@dantonio@uniparthenope.it> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.42/RELEASE, bases: 20121203 #8605173, check: 20121203 clean X-Mailman-Approved-At: Mon, 03 Dec 2012 09:35:07 -0800 Subject: [secdir] R: secdir review of draft-ietf-ipfix-flow-selection-tech 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, 03 Dec 2012 17:15:24 -0000 Dear Dan, I apologise for my late answer to your comment. I agree with you. In order to address your comment I modified the new version of the Internet Draft by proposing that an input to the = encryption process, like the Initialization Vector of the CBC mode, should be used = to prevent that an advisory can predict the selection decision. I have also replaced the old reference "[GoRe07]" with a reference to = "Recommendation for Block Cipher Modes of Operation, Methods and Techniques", NIST = Special Publication 800-38A 2001 Edition. Looking forward to your feedback. Best regards, Salvatore -----Messaggio originale----- Da: Dan Harkins [mailto:dharkins@lounge.org]=20 Inviato: mercoled=EC 11 aprile 2012 02:00 A: iesg@ietf.org; secdir@ietf.org; draft-ietf-ipfix-flow-selection-tech.all@tools.ietf.org Oggetto: secdir review of draft-ietf-ipfix-flow-selection-tech Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft describes techniques to select flows which are sets of packets with some common characteristics. The authors have accurately identified what constitutes an attack-- an adversary having the ability to influence flow selection-- and the Security Considerations give a couple examples of this. They seem fine. There is reference to a paper "[GoRe07]" which does not appear in the References and seems to give advice that I think is wrong: use a strong cryptographically strong random number generator to thwart an attack in which parameters of time-based sampling are discovered to predict the selection decision. This attack can be thwarted by using a value that the adversary cannot predict (sort of like an IV for CBC mode) instead of a cryptographically strong random number. That leaves the random number pool to applications that really need it (like a key exchange that does a Diffie-Hellman). I suggest removing the reference to the un-referenced paper and mention a weaker requirement to thwart that attack. regards, Dan. ----- Nessun virus nel messaggio. Controllato da AVG - www.avg.com Versione: 2012.0.1913 / Database dei virus: 2411/4926 - Data di = rilascio: 10/04/2012 From jiangsheng@huawei.com Mon Dec 3 19:02:45 2012 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 BAA8721F8920; Mon, 3 Dec 2012 19:02:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 vQy6p7FCp0TR; Mon, 3 Dec 2012 19:02:45 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9D27F21F8879; Mon, 3 Dec 2012 19:02:42 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANL52401; Tue, 04 Dec 2012 03:02:39 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 4 Dec 2012 03:02:12 +0000 Received: from SZXEML443-HUB.china.huawei.com (10.82.67.181) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 4 Dec 2012 11:02:38 +0800 Received: from SZXEML545-MBS.china.huawei.com ([169.254.2.174]) by SZXEML443-HUB.china.huawei.com ([10.82.67.181]) with mapi id 14.01.0323.003; Tue, 4 Dec 2012 11:02:35 +0800 From: Sheng Jiang To: "aaa-doctors@ietf.org" , "softwires@ietf.org" , "secdir@ietf.org" Thread-Topic: proposed text for packet flow in draft-ietf-softwire-6rd-radius-attrib-08 Thread-Index: Ac3Ry85QaXs3BN28SU6EM6WO6V/3XA== Date: Tue, 4 Dec 2012 03:02:33 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239FCBEFE@szxeml545-mbs.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.140] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Dave Nelson , Bernard Aboba , "Benoit Claise \(bclaise\)" , "draft-ietf-softwire-6rd-radius-attrib@tools.ietf.org" , Ralph Droms , Barry Leiba Subject: [secdir] proposed text for packet flow in draft-ietf-softwire-6rd-radius-attrib-08 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, 04 Dec 2012 03:02:45 -0000 RGVhciBBQUEgZG9jdG9ycyBhbmQgU2VjZGlyIG1lbWJlcnMsDQoNCkZvbGxvd2luZyB5b3VyIGNv bW1lbnRzIG9uIGRyYWZ0LWlldGYtc29mdHdpcmUtNnJkLXJhZGl1cy1hdHRyaWItMDYgYW5kIDA3 IHZlcnNpb25zLCB0aGUgYXV0aG9ycyBoYXMgcmVmaW5lZCB0aGUgcGFja2V0IGZsb3cgZm9yIHRo ZSBjb29wZXJhdGlvbiBiZXR3ZWVuIERIQ1AgYW5kIFJBRElVUy4gVGhlIGJsb3cgaXMgdGhlIHBy b3Bvc2VkIHRleHQgZm9yIDA4IHZlcnNpb24uIENvdWxkIHlvdSBwbGVhc2UgcmV2aWV3IGl0IGFu ZCBjb21tZW50IHdoZXRoZXIgeW91ciBlYXJseSBjb21tZW50cyBoYXZlIGJlZW4gcHJvcGVybHkg c29sdmVkPyBJZiB5b3UgaGF2ZSBhbnkgZnVydGhlciBtb2RpZmljYXRpb24gc3VnZ2VzdGlvbnMs IHdlIGFyZSB3aWxsaW5nIHRvIGZvbGxvdy4gTWFueSB0aGFua3MuDQoNClRoZSBiZWxvdyBGaWd1 cmUgMSBpbGx1c3RyYXRlcyBob3cgdGhlIFJBRElVUyBwcm90b2NvbCBhbmQgREhDUCBjb29wZXJh dGUgdG8gcHJvdmlkZSA2cmQgQ0Ugd2l0aCA2cmQgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbi4N CiANCjZyZCBDRSAgICAgICAgICAgICAgICAgICAgQk5HICAgICAgICAgICAgICBBQUEgU2VydmVy DQogICB8ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8DQog ICB8LS0tLS0tLURIQ1BESVNDT1ZFUi0tLS0tLT58ICAgICAgICAgICAgICAgICAgICAgICB8DQog ICB8KFBhcmFtZXRlciBSZXF1ZXN0IHcvIDZyZCBvcHRpb24pICAgICAgICAgICAgICAgICAgfA0K ICAgfCAgICAgICAgICAgICAgICAgICAgICB8LS1BY2Nlc3MtUmVxdWVzdCg2cmQgQXR0ciktLT58 DQogICB8ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8DQog ICB8ICAgICAgICAgICAgICAgICAgICAgIHw8LS1BY2Nlc3MtQWNjZXB0KDZyZCBBdHRyKS0tLXwN CiAgIHw8LS0tLS0tLURIQ1BPRkZFUi0tLS0tLS0tLXwgICAgICAgICAgICAgICAgICAgICAgICB8 DQogICB8ICAgICAgKDZyZCBvcHRpb24pICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgfA0K ICAgfCAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAg ICAgICAgICAgICAgREhDUCAgICAgICAgICAgICAgICAgICAgICBSQURJVVMgDQogICAgICBGaWd1 cmUgMTogdGhlIGNvb3BlcmF0aW9uIGJldHdlZW4gREhDUCBhbmQgUkFESVVTDQogICAgICAgICAg ICAgIGNvbWJpbmluZyB3aXRoIFJBRElVUyBhdXRoZW50aWNhdGlvbg0KDQpUaGUgQk5HIGFjdHMg YXMgYSBjbGllbnQgb2YgUkFESVVTIGFuZCBhcyBhIERIQ1Agc2VydmVyIGZvciBESENQIHByb3Rv Y29sLiBGaXJzdCwgdGhlIDZyZCBDRSBpbml0aWF0ZXMgYSBESENQRElTQ09WRVIgbWVzc2FnZSB0 aGF0IGluY2x1ZGVzIGEgUGFyYW1ldGVyIFJlcXVlc3Qgb3B0aW9uICg1NSkgW1JGQzIxMzJdIHdp dGggNnJkIG9wdGlvbiBbUkZDNTk2OV0uIFdoZW4gdGhlIEJORyByZWNlaXZlcyB0aGUgREhDUERJ U0NPVkVSLCBpdCBpbml0aWF0ZXMgYSBSYWRpdXMgQWNjZXNzLVJlcXVlc3QgbWVzc2FnZSB0byB0 aGUgUmFkaXVzIHNlcnZlciwgcmVxdWVzdGluZyBub3JtYWwgYXV0aGVudGljYXRpb24gYXMgZGVm aW5lZCBpbiBbUkZDMjg2NV0gYW5kIElQdjYtNnJkLUNvbmZpZ3VyYXRpb24gYXR0cmlidXRlLCBk ZWZpbmVkIGluIHRoZSBuZXh0IFNlY3Rpb24sIGluIHRoZSBkZXNpcmVkIGF0dHJpYnV0ZSBsaXN0 LiBJZiB0aGUgYXV0aGVudGljYXRpb24gcmVxdWVzdCBpcyBhcHByb3ZlZCBieSB0aGUgQUFBIHNl cnZlciwgYW4gQWNjZXNzLUFjY2VwdCBtZXNzYWdlIGlzIGFja25vd2xlZGdlZCB3aXRoIHRoZSBJ UHY2LTZyZC1Db25maWd1cmF0aW9uIEF0dHJpYnV0ZS4gVGhlbiwgdGhlIEJORyByZXNwb25kcyB0 byB0aGUgNnJkIENFIHdpdGggYSBESENQT0ZGRVIgbWVzc2FnZSwgd2hpY2ggY29udGFpbnMgREhD UCA2cmQgb3B0aW9uLg0KDQpGaWd1cmUgMiBkZXNjcmliZXMgYW5vdGhlciBzY2VuYXJpbyAtIGxh dGVyIHJlLWF1dGhvcml6ZSwgaW4gd2hpY2ggdGhlIGF1dGhvcml6YXRpb24gb3BlcmF0aW9uIGlz IG5vdCBjb3VwbGVkIHdpdGggYXV0aGVudGljYXRpb24uIDZyZCByZWxldmFudCBhdXRob3JpemF0 aW9uIGlzIGRvbmUgaW5kZXBlbmRlbnRseSBhZnRlciB0aGUgYXV0aGVudGljYXRpb24gcHJvY2Vz cy4NCg0KNnJkIENFICAgICAgICAgICAgICAgICAgICBCTkcgICAgICAgICAgICAgICBBQUEgU2Vy dmVyDQogICB8ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8 DQogICB8LS0tLS0tLS1ESENQUkVRVUVTVC0tLS0tLT58ICAgICAgICAgICAgICAgICAgICAgICB8 DQogICB8KFBhcmFtZXRlciBSZXF1ZXN0IHcvIDZyZCBvcHRpb24pICAgICAgICAgICAgICAgICAg IHwNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgfC0tQWNjZXNzLVJlcXVlc3QoNnJkIEF0dHIp LS0+fA0KICAgfCAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg fA0KICAgfCAgICAgICAgICAgICAgICAgICAgICB8PC0tQWNjZXNzLUFjY2VwdCg2cmQgQXR0cikt LS18DQogICB8ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8 DQogICB8PC0tLS0tLS0tLURIQ1BBQ0stLS0tLS0tLS18ICAgICAgICAgICAgICAgICAgICAgICAg IHwNCiAgIHwgICAgICAoNnJkIG9wdGlvbikgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg fA0KICAgfCAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfA0K ICAgICAgICAgICBESENQICAgICAgICAgICAgICAgICAgICAgICBSQURJVVMNCiAgICBGaWd1cmUg MjogdGhlIGNvb3BlcmF0aW9uIGJldHdlZW4gREhDUCBhbmQgUkFESVVTDQogICAgICAgICAgICAg ICBkZWNvdXBsZWQgd2l0aCBSQURJVVMgYXV0aGVudGljYXRpb24NCg0KSW4gdGhlIGFib3ZlbWVu dGlvbmVkIHNjZW5hcmlvLCB0aGUgQWNjZXNzLVJlcXVlc3QgcGFja2V0IGNvbnRhaW5zIGEgU2Vy dmljZS1UeXBlIGF0dHJpYnV0ZSB3aXRoIHRoZSB2YWx1ZSBBdXRob3JpemUgT25seSAoMTcpOyB0 aHVzLCBhY2NvcmRpbmcgdG8gW1JGQzUwODBdLCB0aGUgQWNjZXNzLVJlcXVlc3QgcGFja2V0IE1V U1QgY29udGFpbiBhIFN0YXRlIGF0dHJpYnV0ZSB0aGF0IHN1Y2NlZWRzIGZyb20gdGhlIHByZXZp b3VzIGF1dGhlbnRpY2F0aW9uIHByb2Nlc3MuDQoNCk1hbnkgdGhhbmtzIGFuZCBiZXN0IHJlZ2Fy ZHMsDQoNClNoZW5nICYgRGF5b25nDQo= From new-work-bounces@ietf.org Wed Dec 5 08:33:22 2012 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 D906C21F8CF0; Wed, 5 Dec 2012 08:33:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1354725202; bh=wn/2KlfF6c+mFGtlf6uiZ8nbkryOC8XoiyYb0Dr+fro=; h=From:To:Date:Message-ID:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=U16nzbJ07Iwt5T31Au2ignlyD2Zqp4Q0oFo17UUBz42XcnF1s6XaYT9gGx2eArwZN hGfLpxpBbAFB+SNKHoXLvDw/A36LVfzs8EIJ7HY8GO1I29HFcFPQizuG8ps6AOGO3q ySaLdlEuDJHteiKFsFRGfyX0D+JJWsztIAqeN3I8= 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 F3F0A21F8A87 for ; Tue, 4 Dec 2012 17:57:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 B0bDH3rw-bKH for ; Tue, 4 Dec 2012 17:57:38 -0800 (PST) Received: from ausc60ps301.us.dell.com (ausc60ps301.us.dell.com [143.166.148.206]) by ietfa.amsl.com (Postfix) with ESMTP id 2C29C21F8A73 for ; Tue, 4 Dec 2012 17:57:37 -0800 (PST) X-Loopcount0: from 10.170.28.39 X-IronPort-AV: E=Sophos; i="4.84,219,1355119200"; d="scan'208,217"; a="30079526" From: To: Date: Tue, 4 Dec 2012 19:49:41 -0600 Thread-Topic: Status of Study Groups per November 2012 IEEE 802 Plenary Thread-Index: Ac3Si6HM/8ouEf1+RNWVX/PbOfDvRQ== Message-ID: <93720FE55DA3044C9F74B2962338F7DE8A341C3449@AUSX7MCPC109.AMER.DELL.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 05 Dec 2012 08:33:22 -0800 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: multipart/mixed; boundary="===============1436257096661463571==" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Wed, 05 Dec 2012 08:35:19 -0800 Subject: [secdir] [new-work] Status of Study Groups per November 2012 IEEE 802 Plenary X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 16:33:23 -0000 --===============1436257096661463571== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_93720FE55DA3044C9F74B2962338F7DE8A341C3449AUSX7MCPC109A_" --_000_93720FE55DA3044C9F74B2962338F7DE8A341C3449AUSX7MCPC109A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Colleagues, The following Study Groups were approved at the November 2012 IEEE 802 Plen= ary - 1. IEEE 802, "OmniRAN" EC Study Group 2. IEEE 802.1 "802.11 Bridging" Study Group 3. IEEE 802.3 "Reduced Twisted Pair Gigabit Ethernet" Study Group 4. IEEE 802.3 "Next Generation BASE-T" Study Group 5. IEEE 802.3 "Distinguished Minimum Latency Traffic in a Converged Traff= ic Environment" Study Group 6. IEEE 802.11 "Pre-association Discovery (PAD)" Study Group 7. IEEE 802.11 "General Link (GLK)" Study Group 8. IEEE 802.15 "Ultra Low Power" Study Group 9. IEEE 802.15 "Layer 2 Routing" Study Group Please note, per the IEEE 802 LMSC Policies and Procedures that a Study Gro= up is chartered plenary session-to-plenary session. Therefore, the Study G= roups, listed above and found at http://www.ieee802.org/StudyGroups.shtml, = are chartered until the IEEE 802 March 2013 Plenary Session. Please note that IEEE meetings are open and may be attended by any individu= als who register and fulfill any registration fees. Details regarding futu= re IEEE 802 plenary meeting schedules may be found at http://www.ieee802.or= g/PARs.shtml. Please refer to individual working groups for their interim = meeting schedules. A listing of all working groups may be found at http://= www.ieee802.org/. Best Regards, John D'Ambrosia IEEE 802 LMSC Recording Secretary Note - This email solely represents the views of the IEEE 802 LMSC and do= es not necessarily represent a position of the IEEE or the IEEE Standards A= ssociation. --_000_93720FE55DA3044C9F74B2962338F7DE8A341C3449AUSX7MCPC109A_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Colleagues,

The following Study Groups were approved at the No= vember 2012 IEEE 802 Plenary –

  1. IEEE 802, "OmniRAN" EC Study Group<= /span> =
  2. IEEE 802.1 "802.11 Bridgin= g" Study Group
  3. IEEE 802.3 = "Reduced Twisted Pair Gigabit Ethernet" Study Group
  4. IEEE 802.3 "Next Generation BASE-T"= ; Study Group
  5. IEEE 802.3 "= Distinguished Minimum Latency Traffic in a Converged Traffic Environment&qu= ot; Study Group
  6. IEEE 802.11 &qu= ot;Pre-association Discovery (PAD)" Study Group
    7. <= li class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt= :auto;mso-list:l0 level1 lfo1'>IEEE 802.11  "General Link (GLK)" Stud= y Group
  7. IEEE 802.15  "= ;Ultra Low Power" Study Group
  8. IEEE 802.15  "Layer 2 Routing" Study Group

Please note, per the IEEE 802 LMSC Policies and P= rocedures that a Study Group is chartered plenary session-to-plenary sessio= n.  Therefore, the Study Groups, listed above and found at http:/= /www.ieee802.org/StudyGroups.shtml, are chartered until the IEEE= 802 March 2013 Plenary Session.

= Please no= te that IEEE meetings are open and may be attended by any individuals who r= egister and fulfill any registration fees.  Details regarding future I= EEE 802 plenary meeting schedules may be found at http://www.ieee802.org/PARs= .shtml.  Please refer to individual working groups for thei= r interim meeting schedules.  A listing of all working groups may be f= ound at http= ://www.ieee802.org/.

= &nbs= p;

Best Regards,

John D’Ambrosia

IEEE 802 LMSC Re= cording Secretary

 =

Note -   = This email solely represents the views of the IEEE 802 LMSC and does not ne= cessarily represent a position of the IEEE or the IEEE Standards Associatio= n. 

 

= --_000_93720FE55DA3044C9F74B2962338F7DE8A341C3449AUSX7MCPC109A_-- --===============1436257096661463571== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --===============1436257096661463571==-- From kivinen@iki.fi Fri Dec 7 03:48:04 2012 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 7700021F8635 for ; Fri, 7 Dec 2012 03:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSSXWToplF+V for ; Fri, 7 Dec 2012 03:48:04 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9526421F8513 for ; Fri, 7 Dec 2012 03:48:03 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qB7Bm0xg025864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Dec 2012 13:48:00 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qB7BlxQg023043; Fri, 7 Dec 2012 13:47:59 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20673.55151.261352.224028@fireball.kivinen.iki.fi> Date: Fri, 7 Dec 2012 13:47:59 +0200 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 1 min 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, 07 Dec 2012 11:48:04 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Alan DeKok is next in the rotation. For telechat 2012-12-13 Reviewer LC end Draft Leif Johansson T 2012-11-26 draft-ietf-mediactrl-mrb-16 Sandy Murphy T 2012-11-26 draft-nir-ipsecme-erx-09 David Waltermire T 2012-12-10 draft-ietf-tcpm-initcwnd-06 Glen Zorn T 2012-10-25 draft-leiba-3777upd-eligibility-05 For telechat 2012-12-20 Carl Wallace T 2012-12-13 draft-ietf-tcpm-experimental-options-03 For telechat 2013-01-10 Dave Cridland T 2013-01-02 draft-schaad-pkix-rfc2875-bis-03 Sam Weiler T 2012-12-26 draft-salgueiro-vcarddav-kind-device-06 Nico Williams T - draft-bonica-special-purpose-03 Last calls and special requests: Derek Atkins 2012-12-17 draft-ietf-bliss-call-completion-18 Rob Austein 2012-12-19 draft-ietf-mboned-auto-multicast-14 Richard Barnes 2012-12-17 draft-ietf-sipclf-format-09 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-03 Jeffrey Hutzelman 2012-10-22 draft-ietf-fecframe-simple-rs-05 Julien Laganier 2012-11-19 draft-ietf-karp-routing-tcp-analysis-06 Russ Mundy 2012-11-12 draft-ietf-mmusic-sdp-media-capabilities-15 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-10 Eric Rescorla 2012-11-27 draft-ietf-lisp-eid-block-03 Yaron Sheffer 2012-12-12 draft-ietf-6renum-enterprise-04 Ondrej Sury 2012-12-12 draft-ietf-6renum-static-problem-02 Tina TSOU 2012-12-11 draft-ietf-avt-rtp-evrc-nw-08 Brian Weis 2012-12-14 draft-ietf-sidr-algorithm-agility-08 Klaas Wierenga 2012-12-14 draft-ietf-sidr-usecases-05 Nico Williams - draft-ietf-httpbis-p5-range-21 Tom Yu 2012-12-27 draft-hanes-dispatch-fax-capability-06 Glen Zorn 2012-06-27 draft-hoffman-tao4677bis-16 Glen Zorn 2012-12-20 draft-ietf-v6ops-icp-guidance-04 -- kivinen@iki.fi From glenzorn@gmail.com Mon Dec 10 00:07:54 2012 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 3240121F8F88; Mon, 10 Dec 2012 00:07:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.382 X-Spam-Level: X-Spam-Status: No, score=-3.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 WuNB-wsegq7E; Mon, 10 Dec 2012 00:07:53 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 88B2F21F8F87; Mon, 10 Dec 2012 00:07:53 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so1640250pbc.31 for ; Mon, 10 Dec 2012 00:07:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=VNesiRZqKRoJQQ4L6GZGgzulnRBQi2xcSIZOxy4CAg0=; b=R0IS+iBdlUvQ5EcRl1vh61SJHECpoYnJI1hFXUE6FNcesTHUksStTo49Zi6Nn6EzWi we+Dd6TmdiF4sXIaNf+Tiy0fE/kDKBpoIYBVTbg1+V66FR3OMn/ItqY0hD4OCN81MuPm iwGN5bmJ6UCwu7J81ePyd3PBI8kkhIzfIInNuRqHbtWHcmCbrrnyyjvponP+vcWqaO9+ td+C2HSH05nSuuu1ycX8U0DknPEfg9HQAOOIUl+HZh2PJfFImo8mMsl1+hYiIFfQV688 NU9ZOXNTmx8QIZTUtxsiWsuc8Xg6FSG3T5xZOdYVgtYpSI/IzmX2DgDBUBODh0xirHeT imJQ== Received: by 10.66.81.37 with SMTP id w5mr33906876pax.81.1355126873244; Mon, 10 Dec 2012 00:07:53 -0800 (PST) Received: from [192.168.0.102] (ppp-171-96-12-38.revip8.asianet.co.th. [171.96.12.38]) by mx.google.com with ESMTPS id ug6sm11455088pbc.4.2012.12.10.00.07.50 (version=SSLv3 cipher=OTHER); Mon, 10 Dec 2012 00:07:52 -0800 (PST) Message-ID: <50C59852.30009@gmail.com> Date: Mon, 10 Dec 2012 15:07:46 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: Vincent Roca References: <5DE1DFCC-00A7-4F54-BF14-75878273895C@inria.fr> In-Reply-To: <5DE1DFCC-00A7-4F54-BF14-75878273895C@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IESG IESG , draft-ietf-dime-erp.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-dime-erp-14 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, 10 Dec 2012 08:07:54 -0000 On 11/05/2012 04:55 AM, Vincent Roca wrote: > Hello, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. Thank you for taking the time to review the draft. > > -- > > The security section of this document is pretty simple as it refers to > the security section of 4 related documents and that's all. On the > opposite, each of these 4 documents includes a very detailed security > analysis. The contrast is extremely important! Why? > > This is all the more annoying as draft-ietf-dime-erp-14 introduces new > mechanisms, and thereby new potential threats and issues (it's usually > the case). From a Diameter POV, a Diameter ERP "server" is actually just a form of Diameter agent and the Diameter ERP client is just a standard Diameter client; a new application is only required to ensure the correct routing of Diameter messages. So I'm not sure what the new mechanisms you refer to are; perhaps you can elucidate? > > What should I understand? Is the proposal guaranteed to be secure? There are no guarantees in life, let alone security ;-). > Or have all the potential weaknesses been already addressed in the > 4 related documents? It would seem that that is the very strong implication. > I can not conclude after reading this security section > and this is a problem. It seems as if the big problem is that the draft doesn't tell you what to think about the security properties of the protocol but I don't think that is really a problem with the document. As I mentioned above, it appears to me that the authors believe that security-related issues are dealt with in the Security Considerations sections of RFCs 4072, 6696, 6733 and 6734. Is that the case? If not, please point out a security problem with this protocol that is not covered by those texts. > > So, I'd like that the authors clarify this, and if need be, I'd like > the authors > explicitly mention which items in each of the 4 related documents apply. > It would be helpful IMHO. Only if you believe our conclusions ;-). > > > Cheers, > > Vincent > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From glenzorn@gmail.com Tue Dec 11 00:19:07 2012 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 069DE21F8778; Tue, 11 Dec 2012 00:19:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_SEX=2.3, 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 Tn3usd3PYd+y; Tue, 11 Dec 2012 00:19:06 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 65CDC21F8752; Tue, 11 Dec 2012 00:19:06 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so2441571pbc.31 for ; Tue, 11 Dec 2012 00:19:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=zqD16MHUeOMOhpnFnoTW2E6kXIM3gHlMrWI5miqT7jE=; b=kOz4wA5dMx8TGwhrtnnIajGCvYjoPtuomjE7gmm4bW3ECtBklCVuRMGIzwlvqsrBDq NTW5tleDfONT+EwBajABhRjzrDcYIbV87sz9zAQc6/2BxSXaemWmJ5itV6/kt4Fia1Pz g9wFU3vxqqpP4z4HpmkJjcaTWrxn/uULuUTh1MIGnbDgDczDn1pDRWTj0lQqRm2Ay0xB uYECsfClYz2YWg7VtF34KkKXq23J7b6BgmNru6bC/mQf6vbythIgcfQ6Cdau9g91WkF6 dXAwHuRsMJ2ruMUKCx3lIg0Wlo/+b90+bGvjKI53tMW2sXOxymmZ39Wa3U787koZoQgK Krqw== Received: by 10.68.209.133 with SMTP id mm5mr46755998pbc.42.1355213946027; Tue, 11 Dec 2012 00:19:06 -0800 (PST) Received: from [192.168.0.102] (ppp-115-87-71-254.revip4.asianet.co.th. [115.87.71.254]) by mx.google.com with ESMTPS id j9sm13485535paw.2.2012.12.11.00.19.03 (version=SSLv3 cipher=OTHER); Tue, 11 Dec 2012 00:19:05 -0800 (PST) Message-ID: <50C6EC73.9020505@gmail.com> Date: Tue, 11 Dec 2012 15:18:59 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: The IESG , "secdir@ietf.org" , draft-leiba-3777upd-eligibility.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] secdir review of draft-leiba-3777upd-eligibility-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: Tue, 11 Dec 2012 08:19:07 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. *Editorial Comments* _Section 1_ s/to understand of the IETF process/to understand the IETF process/ s/ex-officio members liaisons/ex-officio members, liaisons/ From barryleiba.mailing.lists@gmail.com Tue Dec 11 00:52:54 2012 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 6165221F8717; Tue, 11 Dec 2012 00:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.962 X-Spam-Level: X-Spam-Status: No, score=-101.962 tagged_above=-999 required=5 tests=[AWL=-1.285, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_SEX=2.3, RCVD_IN_DNSWL_LOW=-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 dw+cNlZnSQ8z; Tue, 11 Dec 2012 00:52:53 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0256321F8797; Tue, 11 Dec 2012 00:52:51 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so2942720lah.31 for ; Tue, 11 Dec 2012 00:52:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=EZPL+aVw/fTTJStYtFw75yM+Vn91sz86IV+jwSR9QB0=; b=gdglrqxGOui1nLQTnhFozat4yGVyosJZCxixjxIxZ/snX2jvLK0SMa5+e57myXF+hq P6+dmVOcILqoH0pnx8HPuHQiG15AgTvosrg8bHseBcxWn6hTrnx892jZpy79nZoih0xG Azzk+xZr0SbhDTRLhztBnNcXB5L9A119y8wZSawWZ+VZhsIo+mS4ielHNGNksx6Ng41g hNKHbOOQaAx/E1TxCvZylFFD4W+SYSZ3NV2NWgnI9WZYn4ifPTMEhXHxwSypatt8Vtl5 XV5EgoH59E7vrmLx55w09e2mSUuah1p9NPOMF+C1hi/Vf8qdNQBd0Ia1x708+k0M3jQg 3QTg== MIME-Version: 1.0 Received: by 10.112.82.166 with SMTP id j6mr7309227lby.25.1355215970650; Tue, 11 Dec 2012 00:52:50 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.12.166 with HTTP; Tue, 11 Dec 2012 00:52:50 -0800 (PST) In-Reply-To: <50C6EC73.9020505@gmail.com> References: <50C6EC73.9020505@gmail.com> Date: Tue, 11 Dec 2012 03:52:50 -0500 X-Google-Sender-Auth: d0fGLPAaS5vZbVAt0PtuvwmFej4 Message-ID: From: Barry Leiba To: Glen Zorn Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-leiba-3777upd-eligibility.all@tools.ietf.org, The IESG , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-leiba-3777upd-eligibility-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: Tue, 11 Dec 2012 08:52:55 -0000 > s/to understand of the IETF process/to understand the IETF process/ > s/ex-officio members liaisons/ex-officio members, liaisons/ Thanks for the review, Glen. I'd already found the first typo, but not the second. Fixed now, for -06. Barry From Tina.Tsou.Zouting@huawei.com Tue Dec 11 16:19:43 2012 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 765AF1F0CB5; Tue, 11 Dec 2012 16:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 xx+IovnlFx+b; Tue, 11 Dec 2012 16:19:43 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 658BD1F0CB0; Tue, 11 Dec 2012 16:19:42 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANT06832; Wed, 12 Dec 2012 00:19:41 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 12 Dec 2012 00:18:55 +0000 Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 12 Dec 2012 00:19:40 +0000 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.39]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Tue, 11 Dec 2012 16:19:34 -0800 From: Tina TSOU To: The IESG , "secdir@ietf.org" , "draft-ietf-avt-rtp-evrc-nw@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-avt-rtp-evrc-nw-08 Thread-Index: AQHN1/5c/yyg2dDpA0eWwHiqaZjy0w== Date: Wed, 12 Dec 2012 00:19:33 +0000 Message-ID: References: <50C6EC73.9020505@gmail.com> In-Reply-To: <50C6EC73.9020505@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.34.95] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [secdir] Secdir review of draft-ietf-avt-rtp-evrc-nw-08 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, 12 Dec 2012 00:19:43 -0000 Dear all, I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like any= other last call comments. I see nothing to add from a security point of view. The document appears to be ready to go. Thank you, Tina From kivinen@iki.fi Thu Dec 13 03:45:51 2012 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 01CA021F8A81 for ; Thu, 13 Dec 2012 03:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 VpCx+1ktIH-6 for ; Thu, 13 Dec 2012 03:45:47 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA9C21F8A7B for ; Thu, 13 Dec 2012 03:45:46 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qBDBjekJ021560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Dec 2012 13:45:40 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qBDBjeAf008065; Thu, 13 Dec 2012 13:45:40 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20681.49123.977133.777486@fireball.kivinen.iki.fi> Date: Thu, 13 Dec 2012 13:45:39 +0200 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 1 min 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: Thu, 13 Dec 2012 11:45:51 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Dan Harkins is next in the rotation. For telechat 2012-12-13 Reviewer LC end Draft Leif Johansson T 2012-11-26 draft-ietf-mediactrl-mrb-16 Sandy Murphy T 2012-11-26 draft-nir-ipsecme-erx-09 Ondrej Sury T 2012-12-12 draft-ietf-6renum-static-problem-02 David Waltermire T 2012-12-10 draft-ietf-tcpm-initcwnd-06 For telechat 2012-12-20 Richard Barnes T 2012-12-17 draft-ietf-sipclf-format-09 Jeffrey Hutzelman T 2012-10-22 draft-ietf-fecframe-simple-rs-05 Carl Wallace T 2012-12-13 draft-ietf-tcpm-experimental-options-03 For telechat 2013-01-10 Dave Cridland T 2013-01-02 draft-schaad-pkix-rfc2875-bis-03 Alan DeKok T 2012-12-25 draft-ietf-appsawg-json-patch-08 Donald Eastlake T 2012-12-25 draft-ietf-appsawg-json-pointer-07 Tobias Gondrom T 2013-01-03 draft-ietf-trill-oam-req-04 Sam Weiler T 2012-12-26 draft-salgueiro-vcarddav-kind-device-06 Nico Williams T - draft-bonica-special-purpose-03 Last calls and special requests: Derek Atkins 2012-12-17 draft-ietf-bliss-call-completion-18 Rob Austein 2012-12-19 draft-ietf-mboned-auto-multicast-14 Shawn Emery 2012-12-24 draft-ietf-oauth-assertions-08 Phillip Hallam-Baker 2013-01-03 draft-ietf-roll-p2p-rpl-15 Steve Hanna 2012-12-21 draft-ietf-v6ops-464xlat-08 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-03 Julien Laganier 2012-11-19 draft-ietf-karp-routing-tcp-analysis-06 Russ Mundy 2012-11-12 draft-ietf-mmusic-sdp-media-capabilities-16 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-10 Eric Rescorla 2012-11-27 draft-ietf-lisp-eid-block-03 Yaron Sheffer 2012-12-12 draft-ietf-6renum-enterprise-04 Brian Weis 2012-12-14 draft-ietf-sidr-algorithm-agility-08 Klaas Wierenga 2012-12-14 draft-ietf-sidr-usecases-05 Nico Williams - draft-ietf-httpbis-p5-range-21 Tom Yu 2012-12-27 draft-hanes-dispatch-fax-capability-06 Glen Zorn 2012-06-27 draft-hoffman-tao4677bis-16 Glen Zorn 2012-12-20 draft-ietf-v6ops-icp-guidance-04 -- kivinen@iki.fi From leifj@sunet.se Thu Dec 13 06:14:22 2012 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 0698521F89A7 for ; Thu, 13 Dec 2012 06:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZukndA3mGZVZ for ; Thu, 13 Dec 2012 06:14:21 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5FB21F88BB for ; Thu, 13 Dec 2012 06:14:21 -0800 (PST) Received: from [77.72.227.187] (dyn-fg-guest187.sth.netnod.se [77.72.227.187]) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id qBDEEGQ1019031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Dec 2012 15:14:19 +0100 (CET) Message-ID: <50C9E2B7.3010907@sunet.se> Date: Thu, 13 Dec 2012 15:14:15 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: secdir@ietf.org References: <20681.49123.977133.777486@fireball.kivinen.iki.fi> In-Reply-To: <20681.49123.977133.777486@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [secdir] Assignments 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, 13 Dec 2012 14:14:22 -0000 On 12/13/2012 12:45 PM, Tero Kivinen wrote: > Review instructions and related resources are at: > http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > Dan Harkins is next in the rotation. > > For telechat 2012-12-13 > > Reviewer LC end Draft > Leif Johansson T 2012-11-26 draft-ietf-mediactrl-mrb-16 > Darnit. I've missed this completely! Will produce some kind of review late tonight if its still interesting. From paul.hoffman@vpnc.org Thu Dec 13 07:07:27 2012 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 AD49B21F8B44 for ; Thu, 13 Dec 2012 07:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 cyXx9S9wQQTu for ; Thu, 13 Dec 2012 07:07:27 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3F70721F8B55 for ; Thu, 13 Dec 2012 07:07:27 -0800 (PST) Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qBDF7Pvr030776 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Dec 2012 08:07:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <50C9E2B7.3010907@sunet.se> Date: Thu, 13 Dec 2012 07:07:25 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20681.49123.977133.777486@fireball.kivinen.iki.fi> <50C9E2B7.3010907@sunet.se> To: Leif Johansson X-Mailer: Apple Mail (2.1499) Cc: secdir@ietf.org Subject: Re: [secdir] Assignments 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, 13 Dec 2012 15:07:27 -0000 On Dec 13, 2012, at 6:14 AM, Leif Johansson wrote: > On 12/13/2012 12:45 PM, Tero Kivinen wrote: >> Review instructions and related resources are at: >> http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >>=20 >> Dan Harkins is next in the rotation. >>=20 >> For telechat 2012-12-13 >>=20 >> Reviewer LC end Draft >> Leif Johansson T 2012-11-26 draft-ietf-mediactrl-mrb-16 >>=20 > Darnit. I've missed this completely! Will produce some kind of review > late tonight if its still interesting. Most of the IESG voting has already happened, and Stephen already a = DISCUSS for the document. --Paul Hoffman= From leifj@sunet.se Thu Dec 13 07:25:30 2012 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 7042521F8B61 for ; Thu, 13 Dec 2012 07:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HshFOimsUf6t for ; Thu, 13 Dec 2012 07:25:30 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id B7A4921F8B5D for ; Thu, 13 Dec 2012 07:25:29 -0800 (PST) Received: from [77.72.227.187] (dyn-fg-guest187.sth.netnod.se [77.72.227.187]) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id qBDFPO8a017554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Dec 2012 16:25:27 +0100 (CET) Message-ID: <50C9F364.60407@sunet.se> Date: Thu, 13 Dec 2012 16:25:24 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Paul Hoffman References: <20681.49123.977133.777486@fireball.kivinen.iki.fi> <50C9E2B7.3010907@sunet.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: secdir@ietf.org Subject: Re: [secdir] Assignments 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, 13 Dec 2012 15:25:30 -0000 On 12/13/2012 04:07 PM, Paul Hoffman wrote: > On Dec 13, 2012, at 6:14 AM, Leif Johansson wrote: > >> On 12/13/2012 12:45 PM, Tero Kivinen wrote: >>> Review instructions and related resources are at: >>> http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >>> >>> Dan Harkins is next in the rotation. >>> >>> For telechat 2012-12-13 >>> >>> Reviewer LC end Draft >>> Leif Johansson T 2012-11-26 draft-ietf-mediactrl-mrb-16 >>> >> Darnit. I've missed this completely! Will produce some kind of review >> late tonight if its still interesting. > Most of the IESG voting has already happened, and Stephen already a DISCUSS for the document. > > --Paul Hoffman Feel free to give me addl work in the next round. From david.waltermire@nist.gov Thu Dec 13 08:59:08 2012 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 C6CD221F8AF3; Thu, 13 Dec 2012 08:59:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.43 X-Spam-Level: X-Spam-Status: No, score=-5.43 tagged_above=-999 required=5 tests=[AWL=-0.585, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 gSo5mKPPwxbY; Thu, 13 Dec 2012 08:59:06 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 1726921F8422; Thu, 13 Dec 2012 08:59:04 -0800 (PST) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 13 Dec 2012 11:58:33 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Thu, 13 Dec 2012 11:58:37 -0500 From: "Waltermire, David A." To: "'iesg@ietf.org'" , "'secdir@ietf.org'" , "draft-ietf-tcpm-initcwnd-06.all@tools.ietf.org" Date: Thu, 13 Dec 2012 11:58:36 -0500 Thread-Topic: SecDir review of draft-ietf-tcpm-initcwnd-06 Thread-Index: Ac3ZS4cWJaBHYgpjRj2+t+yrpmW8gw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D7A0423E5E193F40BE6E94126930C4930BAD85C5D8MBCLUSTERxcha_" MIME-Version: 1.0 Subject: [secdir] SecDir review of draft-ietf-tcpm-initcwnd-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: Thu, 13 Dec 2012 16:59:08 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930BAD85C5D8MBCLUSTERxcha_ Content-Type: text/plain; charset="us-ascii" I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: This document captures a proposal to raise the upper bound on the TCP's initial window to 10 segments to address the evolving scale of the internet improving the performance of many web services. It presents the advantages and disadvantages of increasing the initial window size based on large-scale experimental findings. In general I found this draft to be very clear on the basis for this change and the protocol implications. I see no additional security-related concerns. Sincerely, David Waltermire --_000_D7A0423E5E193F40BE6E94126930C4930BAD85C5D8MBCLUSTERxcha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXVzLWFzY2lpIj48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250 ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4 dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQg Q2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1h aWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uUGxh aW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRp diBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PkkgaGF2ZSByZXZpZXdl ZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3MmbmJz cDsgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9j ZXNzZWQgYnkgdGhlIElFU0cuJm5ic3A7IFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmlt YXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4mbmJz cDsgRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21t ZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy48bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNv UGxhaW5UZXh0PlN1bW1hcnk6PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0Pjxv OnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5UaGlzIGRvY3VtZW50IGNh cHR1cmVzIGEgcHJvcG9zYWwgdG8gcmFpc2UgdGhlIHVwcGVyIGJvdW5kIG9uIHRoZSBUQ1AmIzgy MTc7cyBpbml0aWFsIHdpbmRvdyB0byAxMCBzZWdtZW50cyB0byBhZGRyZXNzIHRoZSBldm9sdmlu ZyBzY2FsZSBvZiB0aGUgaW50ZXJuZXQgaW1wcm92aW5nIHRoZSBwZXJmb3JtYW5jZSBvZiBtYW55 IHdlYiBzZXJ2aWNlcy4mbmJzcDsgSXQgcHJlc2VudHMgdGhlIGFkdmFudGFnZXMgYW5kIGRpc2Fk dmFudGFnZXMgb2YgaW5jcmVhc2luZyB0aGUgaW5pdGlhbCB3aW5kb3cgc2l6ZSBiYXNlZCBvbiBs YXJnZS1zY2FsZSBleHBlcmltZW50YWwgZmluZGluZ3MuPG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5J biBnZW5lcmFsIEkgZm91bmQgdGhpcyBkcmFmdCB0byBiZSB2ZXJ5IGNsZWFyIG9uIHRoZSBiYXNp cyBmb3IgdGhpcyBjaGFuZ2UgYW5kIHRoZSBwcm90b2NvbCBpbXBsaWNhdGlvbnMuJm5ic3A7IEkg c2VlIG5vIGFkZGl0aW9uYWwgc2VjdXJpdHktcmVsYXRlZCBjb25jZXJucy48bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNv UGxhaW5UZXh0PlNpbmNlcmVseSw8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ RGF2aWQgV2FsdGVybWlyZTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpw PiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+ PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_D7A0423E5E193F40BE6E94126930C4930BAD85C5D8MBCLUSTERxcha_-- From jhutz@cmu.edu Thu Dec 13 11:04:31 2012 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 509CD21F8A32 for ; Thu, 13 Dec 2012 11:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.953 X-Spam-Level: X-Spam-Status: No, score=-105.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, 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 pFah3L4VkV49 for ; Thu, 13 Dec 2012 11:04:30 -0800 (PST) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by ietfa.amsl.com (Postfix) with ESMTP id BE1E521F8623 for ; Thu, 13 Dec 2012 11:04:30 -0800 (PST) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id qBDJ4Soq007638 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 13 Dec 2012 14:04:28 -0500 (EST) Message-ID: <1355425468.2312.68.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman Date: Thu, 13 Dec 2012 14:04:28 -0500 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Cc: draft-ietf-fecframe-simple-rs.all@tools.ietf.org, secdir@ietf.org, jhutz@cmu.edu Subject: [secdir] secdir review of draft-ietf-fecframe-simple-rs-05.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: Thu, 13 Dec 2012 19:04:31 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines a forward error correction scheme for use with the FECFRAME framework, based on Reed-Solomon codes over finite fields of order 2^m. However, this is mostly a protocol document; the actual FEC code is defined in RFC5510. In discussing security considerations, this document relies heavily on the security discussion in the already-published FEC framework document (RFC6363). It also contains a reasonably complete discussion of issues that can arise if an attacker can modify the encoding parameters. These generally amount to resource exhaustion if a receiver accepts an overly large parameter, or denial of service as a result of a receiver being unable to recover data due to misinterpretation of the code. I found that this document, especially the introduction, did not read very smoothly. However, the technical content was entirely understandable, despite my abstract algebra being a bit rusty. -- Jeff From bew@cisco.com Thu Dec 13 18:00:41 2012 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 8F54E21F8A96; Thu, 13 Dec 2012 18:00:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 HCwfLeV54kp2; Thu, 13 Dec 2012 18:00:41 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id F3D7E21F8A6F; Thu, 13 Dec 2012 18:00:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1636; q=dns/txt; s=iport; t=1355450441; x=1356660041; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=xhLFq78Q3wr4xjx3Qu9jApflqjBD6qbHk983q+Md+mc=; b=CFtazoSnyX13F/dNRhOSICLfGGO3ZAvj5X7/Scn0SnlNwe6a814uX3UE 1ZtjRV6QQgvVEk1rPxpcJ74mwzlGjqy+CPLp5bzmbDoNt40qfItHYFgOJ qFDDjGkN8jg0JOGywwz4oYYdgG4NpBhOFLiuAzkjAWaHeJE5rd+4IlelT o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYHAC2HylCrRDoI/2dsb2JhbABFg0i7KxZzgl86BYE+ASuHeQG9I5A5YQOIYI0pkEiDFIFDAh4CBA X-IronPort-AV: E=Sophos;i="4.84,277,1355097600"; d="scan'208";a="66514452" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 14 Dec 2012 02:00:41 +0000 Received: from dhcp-128-107-147-77.cisco.com (dhcp-128-107-147-77.cisco.com [128.107.147.77]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qBE20e0u015616 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Dec 2012 02:00:40 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Dec 2012 18:00:41 -0800 Message-Id: <2D9BAC01-1B3C-4D5A-84AD-CD8CA8FCCAE3@cisco.com> To: "secdir@ietf.org" , The IESG Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Cc: draft-ietf-sidr-algorithm-agility.all@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-sidr-algorithm-agility-08 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, 14 Dec 2012 02:00: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 describes a mandatory algorithm transition procedure for = the RPKI. It describes a single method, comprised of four phases and six = milestones. Each phase discusses a strategy for rollback of the new = algorithm. The algorithm transition procedure seems complete, and the = security considerations section is adequate. One statement in the discussion of Phase 4 is confusing (Section 4.7). = It first states: "RPs MAY validate signed product sets using Suite C. However, RPs SHOULD NOT assume that the collection of Suite C product sets is complete." Later it notes that Suite A could be deprecated, and states: "At this stage, RPs are still capable of processing Suite C signed products, so the RPKI is still viable." But if the Suite C product sets may be incomplete, how is the RPKI still = viable? This should be clarified. Nits: - Section 3, "Corresponds" definition: s/Resoureces/Resources/ - Section 4.1, "End Of Life (EOL) Date definition: s/is MUST/MUST/ - Section 7, last paragraph. The final sentence would be clearer if it = read "Since Suite C products are being deprecated during Phase 4, a CA = may revoke certificates issued under Suite C without revoking them under = Suite A." Ignore if you don't agree. Brian= From yaronf.ietf@gmail.com Fri Dec 14 02:34:11 2012 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 1EF4A21F874B; Fri, 14 Dec 2012 02:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.466 X-Spam-Level: X-Spam-Status: No, score=-103.466 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 9Ieg5SZQe7IJ; Fri, 14 Dec 2012 02:34:10 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAF921F8746; Fri, 14 Dec 2012 02:34:09 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2624398lbk.31 for ; Fri, 14 Dec 2012 02:34:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=xTIPvcDY0NQOmgPtOLC3JlODV7L3cPJqFuTQsLWHFdk=; b=cfw212J3D3WQvXecZ0jMY+ODtvft2iyZ1b9jqIPk/llT3ak3Av2Z0B1V0vNkwWEurC l7U4dfWN1KtOIojdmMHZj8nVgqe+EXXGEpU9nQ7HYOj6KVEN8YLmVte2C2+tibujMQTl kT94TuI0Xf17i70zphwisqeCvlPao3MdiY09u3rfJ+nWku/Qo0cj+8ksPswVV/FBkofw PE14NG4qYEI2W/af4jT56Z5nQER9XPQWWmqOK5N0oIwefiIDM1CFPUv37tEYph5ySHjv NH4EN44YgFn3LllQkgOOpTHGgOO4Z+dFaABSHRp5BR/vVBV5qY3+/f2qcO62tpZhup+2 fl5Q== Received: by 10.112.14.107 with SMTP id o11mr2140035lbc.98.1355481248884; Fri, 14 Dec 2012 02:34:08 -0800 (PST) Received: from [10.0.0.3] (bzq-79-179-146-198.red.bezeqint.net. [79.179.146.198]) by mx.google.com with ESMTPS id v6sm1718441lbf.11.2012.12.14.02.34.06 (version=SSLv3 cipher=OTHER); Fri, 14 Dec 2012 02:34:07 -0800 (PST) Message-ID: <50CB009A.80908@gmail.com> Date: Fri, 14 Dec 2012 12:34:02 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "secdir@ietf.org" , draft-ietf-6renum-enterprise.all@tools.ietf.org, The IESG References: <4FBFAE5F.8010305@gmail.com> In-Reply-To: <4FBFAE5F.8010305@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] SecDir review of draft-ietf-6renum-enterprise-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: Fri, 14 Dec 2012 10:34:11 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document reviews best practices in renumbering IPv6 enterprise networks. I apologize for my belated review, and hope it is still useful to the authors and document reviewers. Summary The Security Considerations section appears appropriate for this type of document. I do not see any issues that should block the document from advancing. Details - Usage of FQDN: I don't understand why RFC 5996 (IKEv2) is cited, I suspect this is a typo. Otherwise, please clarify. - The "Security" subsection of 4.1 overlaps with the Security Considerations section, and I would recommend to consolidate them. - 4.1, "Miscellaneous": I accept the recommendation to use FQDNs instead of IP addresses. But saying "connections can survive" implies to me that live TCP connections will survive an IP renumbering event, which is not the case. I would say "connectivity to the remote side can survive" instead. - 4.3: RFC 2230 is mentioned as a way to deal with naming of IPsec endpoints. I am not aware of current implementations of this RFC (in fact it is not even mentioned in the current IPsec Roadmap document, RFC 6071). Moreover, there is community consensus that IPsec should not be used in the absence of a key management protocol. And IKE/IKEv2 certainly supports naming/identifying endpoints by FQDN. - The Security Considerations are sufficient IMO. The first point (using renumbering to escape blacklisting) is appropriate in the context, even if per Martin Stiemerling's comment, this strategy may not be very effective. This is not a recommendation on how to bypass blacklisting, just a description of a potential vulnerability. Thanks, Yaron From rogaglia@cisco.com Fri Dec 14 03:25:40 2012 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 2A0D221F858C; Fri, 14 Dec 2012 03:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 VUmQTA7e6vR0; Fri, 14 Dec 2012 03:25:39 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3A221F8541; Fri, 14 Dec 2012 03:25:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6924; q=dns/txt; s=iport; t=1355484338; x=1356693938; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zOVe0u+zc5jrRs8p1VH/vUz4LTnOyaQzNUI+/8T6aeo=; b=LJfkNlsMS5qBmpWgoCLbM2QNoypEIiRiOdfWCwqkem6SwnlZBLOZqR3y pHjI9Lhwh7/+KNHcYdeDtYmzLHd9pOkijgMeuvWtbAFdo8YE6Kl3jzS2e FkZKiPbqbFqzRhFb0yXue6UJ0aXSBKmlTN2LqVGzAOetwcSppdzoYlF5z E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFADsMy1CtJXHB/2dsb2JhbABFtWUBiR0Wc4IfAQEEdAUQAgEIIiQyJQIEDg0Rh3oMvXCMV4NiYQOXJY8sgnOBZAICHAIEGA X-IronPort-AV: E=Sophos;i="4.84,280,1355097600"; d="scan'208,217";a="152940363" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 14 Dec 2012 11:25:38 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qBEBPbrB029048 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Dec 2012 11:25:37 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.93]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Fri, 14 Dec 2012 05:25:37 -0600 From: "Roque Gagliano (rogaglia)" To: "Brian Weis (bew)" Thread-Topic: Secdir review of draft-ietf-sidr-algorithm-agility-08 Thread-Index: AQHN2Z7mAg8yZfnng0akBXDnVBP64pgYjNAA Date: Fri, 14 Dec 2012 11:25:37 +0000 Message-ID: References: <2D9BAC01-1B3C-4D5A-84AD-CD8CA8FCCAE3@cisco.com> In-Reply-To: <2D9BAC01-1B3C-4D5A-84AD-CD8CA8FCCAE3@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.20.190] Content-Type: multipart/alternative; boundary="_000_EF4348D391D0334996EE9681630C83F021FEC7B8xmbrcdx02ciscoc_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 14 Dec 2012 04:24:14 -0800 Cc: "" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-sidr-algorithm-agility-08 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, 14 Dec 2012 11:25:40 -0000 --_000_EF4348D391D0334996EE9681630C83F021FEC7B8xmbrcdx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Brian, Thanks for your review. See my answers inline. Cheers! Roque On Dec 14, 2012, at 3:00 AM, Brian Weis wrote: I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the security area directors= . Document editors and WG chairs should treat these comments just like any = other last call comments. This document describes a mandatory algorithm transition procedure for the = RPKI. It describes a single method, comprised of four phases and six milest= ones. Each phase discusses a strategy for rollback of the new algorithm. Th= e algorithm transition procedure seems complete, and the security considera= tions section is adequate. One statement in the discussion of Phase 4 is confusing (Section 4.7). It f= irst states: "RPs MAY validate signed product sets using Suite C. However, RPs SHOULD NOT assume that the collection of Suite C product sets is complete." Later it notes that Suite A could be deprecated, and states: "At this stage, RPs are still capable of processing Suite C signed products, so the RPKI is still viable." But if the Suite C product sets may be incomplete, how is the RPKI still vi= able? This should be clarified. One clarification is that the first piece of text that you quoted is the no= rmal agility process while the second quoted sentence refers to what to do = when the new algorithm suite is deemed unsuitable and the algorithm change = process needs to be canceled. That said, what about this clarification text? If the Algorithm Suite A (former Algorithm Suite B) is deemed unsuitable, the algorithm transition timeline and the algorithm specification documents MUST be replaced, the Algorithm Suite A MUST be deprecated using the process described in Section 10 and CAs MUST NOT remove Suite C product sets. At this stage,= RPs are still capable of processing Suite C signed products, so the RPKI i= s still viable. Nits: - Section 3, "Corresponds" definition: s/Resoureces/Resources/ - Section 4.1, "End Of Life (EOL) Date definition: s/is MUST/MUST/ - Section 7, last paragraph. The final sentence would be clearer if it read= "Since Suite C products are being deprecated during Phase 4, a CA may revo= ke certificates issued under Suite C without revoking them under Suite A." = Ignore if you don't agree. Thanks! Will Change for next version. Brian --_000_EF4348D391D0334996EE9681630C83F021FEC7B8xmbrcdx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Brian,

Thanks for your review. See my answers inline.

Cheers!
Roque

On Dec 14, 2012, at 3:00 AM, Brian Weis wrote:

I have reviewed this document as part of the security directorate's on= going effort to review all IETF documents being processed by the IESG. Thes= e comments were written primarily for the benefit of the security area dire= ctors. Document editors and WG chairs should treat these comments just like any other last call comments.

This document describes a mandatory algorithm transition procedure for the = RPKI. It describes a single method, comprised of four phases and six milest= ones. Each phase discusses a strategy for rollback of the new algorithm. Th= e algorithm transition procedure seems complete, and the security considerations section is adequate.

One statement in the discussion of Phase 4 is confusing (Section 4.7). It f= irst states:

 "RPs MAY validate signed product sets
  using Suite C. However, RPs SHOULD NOT assume that the collecti= on of
  Suite C product sets is complete."

Later it notes that Suite A could be deprecated, and states:

 "At this stage, RPs are still capable of processing Suite
  C signed products, so the RPKI is still viable."

But if the Suite C product sets may be incomplete, how is the RPKI sti= ll viable? This should be clarified.

One clarification is that the first piece of text that you quoted is t= he normal agility process while the second quoted sentence refers to what t= o do when the new algorithm suite is deemed unsuitable and the algorithm ch= ange process needs to be canceled.

That said, what about this clarification text?
If t=
he Algorithm Suite A (former Algorithm
   Suite B) is deemed unsuitable, the algorithm transition timeline and
   the algorithm specification documents MUST be replaced, the
   Algorithm Suite A MUST be deprecated using the process described in
   Section 10 and CAs MUST NOT remove Suite C product sets. At this stage, =
RPs are still capable of processing Suite C signed products, so the RPKI is=
 still viable.

Nits:
- Section 3, "Corresponds" definition: s/Resoureces/Resource= s/
- Section 4.1, "End Of Life (EOL) Date definition: s/is MUST/MUST/
- Section 7, last paragraph. The final sentence would be clearer if it read= "Since Suite C products are being deprecated during Phase 4, a CA may= revoke certificates issued under Suite C without revoking them under Suite= A." Ignore if you don't agree.


Thanks! Will Change for next version.



Brian

--_000_EF4348D391D0334996EE9681630C83F021FEC7B8xmbrcdx02ciscoc_-- From bew@cisco.com Fri Dec 14 11:36:50 2012 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 3812C21F8B4C; Fri, 14 Dec 2012 11:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.398 X-Spam-Level: X-Spam-Status: No, score=-110.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfxz9FmQElGo; Fri, 14 Dec 2012 11:36:49 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBBA21F8B44; Fri, 14 Dec 2012 11:36:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8147; q=dns/txt; s=iport; t=1355513809; x=1356723409; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=MmHNeSD3Cyc6Etfev7k5YV+2rb8T5WKJH1hVu+BbktM=; b=jW9dOmO+nBoHE4hBu3yHSn1/deEQUod3smVVfCx+566y1DzyLg1wZnHT 2DUk5P0MfWSMMifkwres5oydymHHzUiylEAViNy0JE0Ra4tE3xKdyPYth iqckdPCOfKAY3Yd+y/ry/cK2jOoZbiLv1CjILPxwb5kDYZUUdLqI+wP30 k=; X-IronPort-AV: E=Sophos;i="4.84,282,1355097600"; d="scan'208,217";a="63479364" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 14 Dec 2012 19:36:48 +0000 Received: from dhcp-128-107-147-77.cisco.com (dhcp-128-107-147-77.cisco.com [128.107.147.77]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qBEJa4hn013902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Dec 2012 19:36:48 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_D0D40E2E-AC02-4845-9D80-276D85ECDA58" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Weis In-Reply-To: Date: Fri, 14 Dec 2012 10:05:00 -0800 Message-Id: <1BC70302-9D09-479C-B9A6-01F9C70F70DF@cisco.com> References: <2D9BAC01-1B3C-4D5A-84AD-CD8CA8FCCAE3@cisco.com> To: Roque Gagliano (rogaglia) X-Mailer: Apple Mail (2.1499) Cc: "" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-sidr-algorithm-agility-08 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, 14 Dec 2012 19:36:50 -0000 --Apple-Mail=_D0D40E2E-AC02-4845-9D80-276D85ECDA58 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Roque, Replies are inline below. On Dec 14, 2012, at 3:25 AM, Roque Gagliano (rogaglia) = wrote: > Hi Brian, >=20 > Thanks for your review. See my answers inline. >=20 > Cheers! > Roque >=20 > On Dec 14, 2012, at 3:00 AM, Brian Weis wrote: >=20 >> I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. >>=20 >> This document describes a mandatory algorithm transition procedure = for the RPKI. It describes a single method, comprised of four phases and = six milestones. Each phase discusses a strategy for rollback of the new = algorithm. The algorithm transition procedure seems complete, and the = security considerations section is adequate. >>=20 >> One statement in the discussion of Phase 4 is confusing (Section = 4.7). It first states: >>=20 >> "RPs MAY validate signed product sets >> using Suite C. However, RPs SHOULD NOT assume that the collection = of >> Suite C product sets is complete." >>=20 >> Later it notes that Suite A could be deprecated, and states: >>=20 >> "At this stage, RPs are still capable of processing Suite >> C signed products, so the RPKI is still viable." >>=20 >> But if the Suite C product sets may be incomplete, how is the RPKI = still viable? This should be clarified. >=20 > One clarification is that the first piece of text that you quoted is = the normal agility process while the second quoted sentence refers to = what to do when the new algorithm suite is deemed unsuitable and the = algorithm change process needs to be canceled. >=20 > That said, what about this clarification text? > If the Algorithm Suite A (former Algorithm > Suite B) is deemed unsuitable, the algorithm transition timeline = and > the algorithm specification documents MUST be replaced, the > Algorithm Suite A MUST be deprecated using the process described in > Section 10 and CAs MUST NOT remove Suite C product sets. At this = stage, RPs are still capable of processing Suite C signed products, so = the RPKI is still viable. This sounds like a good clarification. Whereas Suite C product sets may = be incomplete (due to expiration of certificates) they are still = considered valid until Phase 4 has completed. The only suggestion I = might have is to change "remove" to "remove or revoke". Thanks, Brian >> Nits: >> - Section 3, "Corresponds" definition: s/Resoureces/Resources/ >> - Section 4.1, "End Of Life (EOL) Date definition: s/is MUST/MUST/ >> - Section 7, last paragraph. The final sentence would be clearer if = it read "Since Suite C products are being deprecated during Phase 4, a = CA may revoke certificates issued under Suite C without revoking them = under Suite A." Ignore if you don't agree. >>=20 >=20 > Thanks! Will Change for next version. >=20 >=20 >=20 >> Brian >=20 --Apple-Mail=_D0D40E2E-AC02-4845-9D80-276D85ECDA58 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi Roque,

Replies are inline below.

On Dec 14, 2012, at 3:25 AM, Roque Gagliano (rogaglia) <rogaglia@cisco.com> wrote:

Hi Brian,

Thanks for your review. See my answers inline.

Cheers!
Roque

On Dec 14, 2012, at 3:00 AM, Brian Weis wrote:

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

This document describes a mandatory algorithm transition procedure for the RPKI. It describes a single method, comprised of four phases and six milestones. Each phase discusses a strategy for rollback of the new algorithm. The algorithm transition procedure seems complete, and the security considerations section is adequate.

One statement in the discussion of Phase 4 is confusing (Section 4.7). It first states:

 "RPs MAY validate signed product sets
  using Suite C. However, RPs SHOULD NOT assume that the collection of
  Suite C product sets is complete."

Later it notes that Suite A could be deprecated, and states:

 "At this stage, RPs are still capable of processing Suite
  C signed products, so the RPKI is still viable."

But if the Suite C product sets may be incomplete, how is the RPKI still viable? This should be clarified.

One clarification is that the first piece of text that you quoted is the normal agility process while the second quoted sentence refers to what to do when the new algorithm suite is deemed unsuitable and the algorithm change process needs to be canceled.

That said, what about this clarification text?
If the Algorithm Suite A (former Algorithm
   Suite B) is deemed unsuitable, the algorithm transition timeline and
   the algorithm specification documents MUST be replaced, the
   Algorithm Suite A MUST be deprecated using the process described in
   Section 10 and CAs MUST NOT remove Suite C product sets. At this stage, RPs are still capable of processing Suite C signed products, so the RPKI is still viable.

This sounds like a good clarification. Whereas Suite C product sets may be incomplete (due to expiration of certificates) they are still considered valid until Phase 4 has completed. The only suggestion I might have is to change "remove" to "remove or revoke".

Thanks,
Brian

Nits:
- Section 3, "Corresponds" definition: s/Resoureces/Resources/
- Section 4.1, "End Of Life (EOL) Date definition: s/is MUST/MUST/
- Section 7, last paragraph. The final sentence would be clearer if it read "Since Suite C products are being deprecated during Phase 4, a CA may revoke certificates issued under Suite C without revoking them under Suite A." Ignore if you don't agree.


Thanks! Will Change for next version.



Brian


--Apple-Mail=_D0D40E2E-AC02-4845-9D80-276D85ECDA58-- From derek@ihtfp.com Mon Dec 17 07:55:04 2012 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 225BE21F8B23; Mon, 17 Dec 2012 07:55:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.452 X-Spam-Level: X-Spam-Status: No, score=-101.452 tagged_above=-999 required=5 tests=[AWL=1.148, 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 PKBQw4TM5zTT; Mon, 17 Dec 2012 07:55:03 -0800 (PST) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) by ietfa.amsl.com (Postfix) with ESMTP id 62BAA21F8B1E; Mon, 17 Dec 2012 07:55:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 4A8822602B2; Mon, 17 Dec 2012 10:55:00 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 16904-06; Mon, 17 Dec 2012 10:54:58 -0500 (EST) Received: from mocana.ihtfp.org (unknown [IPv6:fe80::224:d7ff:fee7:8924]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 25D932602A4; Mon, 17 Dec 2012 10:54:58 -0500 (EST) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id qBHFstMv005771; Mon, 17 Dec 2012 10:54:55 -0500 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Date: Mon, 17 Dec 2012 10:54:54 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: r.jesske@telekom.de, worley@ariadne.com, martin.huelsemann@telekom.de, bliss-chairs@tools.ietf.org, alexeitsev@teleflash.com Subject: [secdir] sec-dir review of draft-ietf-bliss-call-completion-18 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, 17 Dec 2012 15:55:04 -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. The call completion feature defined in this specification allows the caller of a failed call to be notified when the callee becomes available to receive a call. The Security Considerations section mentions 'SPIT' but nowhere does the document define the term. What does it mean? The SC section also mentions a "DoD" attack -- is the US Department of Defence actually going to attack something? Or does DoD mean something else? It's never defined. Was this perhaps a typo of "DoS", Denial of Service? If so, I recommend you fix the typo but also expand the acronym for those not necessarily familiar with the term "DoS". -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From rogaglia@cisco.com Mon Dec 17 08:03:00 2012 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 E9EDB21F8B49; Mon, 17 Dec 2012 08:02:59 -0800 (PST) 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 5qnZ8iEvf1XP; Mon, 17 Dec 2012 08:02:59 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id BC09F21F8B4A; Mon, 17 Dec 2012 08:02:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1113; q=dns/txt; s=iport; t=1355760179; x=1356969779; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zNtCee6wucENO8WJssYL9JOA1qFIigbbbO3y4hTzrzw=; b=Olkn6loFzwPFjYIzvOy0w86npMlVcu8P70UMT7jClOyumohmAPZEcRKv WnJysFAI+tTi+sNY8g4yAiiJyvB4OFRujo9ZITq4DNYTXC4+7wiOzPyCQ IjdcZos8Ygyu8SniIQ340f/rj9VzQXvvRZVK/dE5V84+Yo/8yylwGh/ub 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJFBz1CtJV2b/2dsb2JhbABFvjUWc4IeAQEBAwE6PwULAgEIIhQQMiUCBA4NEYd0BroEkD9hA6ZSgnOBZCIc X-IronPort-AV: E=Sophos;i="4.84,302,1355097600"; d="scan'208";a="153789135" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 17 Dec 2012 16:02:58 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qBHG2wQf010027 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Dec 2012 16:02:58 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.222]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Mon, 17 Dec 2012 10:02:58 -0600 From: "Roque Gagliano (rogaglia)" To: "Brian Weis (bew)" Thread-Topic: Secdir review of draft-ietf-sidr-algorithm-agility-08 Thread-Index: AQHN2Z7mAg8yZfnng0akBXDnVBP64pgYjNAAgABvmACABJTigA== Date: Mon, 17 Dec 2012 16:02:57 +0000 Message-ID: References: <2D9BAC01-1B3C-4D5A-84AD-CD8CA8FCCAE3@cisco.com> <1BC70302-9D09-479C-B9A6-01F9C70F70DF@cisco.com> In-Reply-To: <1BC70302-9D09-479C-B9A6-01F9C70F70DF@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.86.205] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-sidr-algorithm-agility-08 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, 17 Dec 2012 16:03:00 -0000 Hi Brian, > This sounds like a good clarification. Whereas Suite C product sets may b= e incomplete (due to expiration of certificates) they are still considered = valid until Phase 4 has completed. The only suggestion I might have is to c= hange "remove" to "remove or revoke". We normally use the term "remove" only as there are too many combinations f= or revocation in this case. Please note that Algorithm C will only be depre= cated at the next phase, so we are not even asking for the revocation of th= e material anyways. Regards, Roque > Thanks, > Brian >=20 >>> Nits: >>> - Section 3, "Corresponds" definition: s/Resoureces/Resources/ >>> - Section 4.1, "End Of Life (EOL) Date definition: s/is MUST/MUST/ >>> - Section 7, last paragraph. The final sentence would be clearer if it = read "Since Suite C products are being deprecated during Phase 4, a CA may = revoke certificates issued under Suite C without revoking them under Suite = A." Ignore if you don't agree. >>>=20 >>=20 >> Thanks! Will Change for next version. >>=20 >>=20 >>=20 >>> Brian >>=20 >=20 From bew@cisco.com Mon Dec 17 10:20:55 2012 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 A72D621F8B48; Mon, 17 Dec 2012 10:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.359 X-Spam-Level: X-Spam-Status: No, score=-110.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 dO4k3lJ+LZKJ; Mon, 17 Dec 2012 10:20:51 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6F68B21F8B16; Mon, 17 Dec 2012 10:20:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1406; q=dns/txt; s=iport; t=1355768448; x=1356978048; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=YdoBTJNzqdxlVq6V8tdL5aaaBRkyGP3zO+ibORKnZe4=; b=WzjkHb2ZzNnQDeYQi3Bh38+/2rpvZk6hpZjDAw4KKgUe3MrHR8NBA25k xXc+6RZ0K/QR/geYDrxYN0JTTomnA7Y5EhZA3zwpMu6bptnrp5MYZ6DQD 6ul7sxS3/2GVBH/Puttoi1HsnmBwQNNaLFwPxiBTT/0Kiwg55KrnOAGLR s=; X-IronPort-AV: E=Sophos;i="4.84,303,1355097600"; d="scan'208";a="64222292" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 17 Dec 2012 18:20:48 +0000 Received: from dhcp-128-107-147-77.cisco.com (dhcp-128-107-147-77.cisco.com [128.107.147.77]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBHIKmnc002190 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Dec 2012 18:20:48 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Weis In-Reply-To: Date: Mon, 17 Dec 2012 10:20:52 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <53C93463-26E2-450C-855C-397DE3247317@cisco.com> References: <2D9BAC01-1B3C-4D5A-84AD-CD8CA8FCCAE3@cisco.com> <1BC70302-9D09-479C-B9A6-01F9C70F70DF@cisco.com> To: "Roque Gagliano (rogaglia)" X-Mailer: Apple Mail (2.1499) Cc: "" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-sidr-algorithm-agility-08 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, 17 Dec 2012 18:20:55 -0000 Hi Roque, On Dec 17, 2012, at 8:02 AM, "Roque Gagliano (rogaglia)" = wrote: > Hi Brian, >=20 >> This sounds like a good clarification. Whereas Suite C product sets = may be incomplete (due to expiration of certificates) they are still = considered valid until Phase 4 has completed. The only suggestion I = might have is to change "remove" to "remove or revoke". >=20 > We normally use the term "remove" only as there are too many = combinations for revocation in this case. Please note that Algorithm C = will only be deprecated at the next phase, so we are not even asking for = the revocation of the material anyways. I take your point that Algorithm C isn't deprecated until the next phase = ... your original wording is fine. Thanks, Brian >=20 > Regards, > Roque >=20 >=20 >=20 >> Thanks, >> Brian >>=20 >>>> Nits: >>>> - Section 3, "Corresponds" definition: s/Resoureces/Resources/ >>>> - Section 4.1, "End Of Life (EOL) Date definition: s/is MUST/MUST/ >>>> - Section 7, last paragraph. The final sentence would be clearer if = it read "Since Suite C products are being deprecated during Phase 4, a = CA may revoke certificates issued under Suite C without revoking them = under Suite A." Ignore if you don't agree. >>>>=20 >>>=20 >>> Thanks! Will Change for next version. >>>=20 >>>=20 >>>=20 >>>> Brian >>>=20 >>=20 >=20 From carl@redhoundsoftware.com Mon Dec 17 15:24:50 2012 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 833B71F0CE3 for ; Mon, 17 Dec 2012 15:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9nmNuJe2cwn for ; Mon, 17 Dec 2012 15:24:49 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9332C1F0CB2 for ; Mon, 17 Dec 2012 15:24:49 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so7989268vbb.31 for ; Mon, 17 Dec 2012 15:24:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=cnInBUjcQ6s09b9iWQNycIV6v6F4VMLns12Gu+WBn88=; b=mA8a5yJ8EmKJUgfreynaOT2swERw8DvcmNOKQD3ZozZi6FTfpepRRyR9dhqp0q5CSA X/XPP663p784Gp70Fu20yF2B0f+xqR091TfNtLy69Q7EhGCnSQFh2r2zLSZKiqmRF+aE /kSF2NdI3knzA+PTFFpfK2qWJIrmHFj71ve/3DZgZHAuifjOJUykiW5ik0mz0ed34Sxj dCEaGLt7yJf4oq0Ql3JJpY2Om7TDJ/mou0MgmVQJ2BSN+gybPn38IiPPsXV82Ye0DCTZ 79czcDqS8vWo8489wSUtz7gUXbthL8NQEBkwNBSihpdR9WzL5C2CF6NAdNDEWYAVeqTp 2KKA== Received: by 10.52.175.106 with SMTP id bz10mr22392682vdc.125.1355786689012; Mon, 17 Dec 2012 15:24:49 -0800 (PST) Received: from [192.168.2.3] (pool-173-79-110-220.washdc.fios.verizon.net. [173.79.110.220]) by mx.google.com with ESMTPS id j3sm13018811vdv.0.2012.12.17.15.24.46 (version=SSLv3 cipher=OTHER); Mon, 17 Dec 2012 15:24:47 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Mon, 17 Dec 2012 18:24:43 -0500 From: Carl Wallace To: The IESG , , Message-ID: Thread-Topic: secdir review of draft-ietf-tcpm-experimental-options-03 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQlgSNRNRgrU88B6i4ZNcCts1yaG/L7IY5UbSG0XaNb/eaZHJdAqTaXUcHqouU9k+TwORvEn Subject: [secdir] secdir review of draft-ietf-tcpm-experimental-options-03 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, 17 Dec 2012 23:24:50 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes how the experimental TCP option code points can support concurrent use through the use of a magic number. It states it does not intend to provide security for TCP option processing and that it does not weaken security for TCP option processing. This seems right to me. I found no issues with this document. From Martin.Huelsemann@telekom.de Wed Dec 19 01:44:35 2012 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 14A6321F893E; Wed, 19 Dec 2012 01:44:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 NSggN7yyDrIa; Wed, 19 Dec 2012 01:44:34 -0800 (PST) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id A724021F8939; Wed, 19 Dec 2012 01:44:33 -0800 (PST) Received: from he101250.emea1.cds.t-internal.com ([10.125.92.153]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 19 Dec 2012 10:43:35 +0100 Received: from HE111543.emea1.cds.t-internal.com ([10.125.90.96]) by HE101250.emea1.cds.t-internal.com ([fe80::e439:4046:12e2:e37%14]) with mapi; Wed, 19 Dec 2012 10:43:34 +0100 From: To: , , Date: Wed, 19 Dec 2012 10:43:33 +0100 Thread-Topic: sec-dir review of draft-ietf-bliss-call-completion-18 Thread-Index: Ac3cbuD0owUaajulTFqTTNJce6lX1ABW2MnA Message-ID: <9762ACF04FA26B4388476841256BDE02011696144E34@HE111543.emea1.cds.t-internal.com> References: In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 19 Dec 2012 08:00:58 -0800 Cc: worley@ariadne.com, R.Jesske@telekom.de, bliss-chairs@tools.ietf.org, alexeitsev@teleflash.com Subject: Re: [secdir] sec-dir review of draft-ietf-bliss-call-completion-18 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, 19 Dec 2012 09:44:35 -0000 Hi Derek, thanks for the review. 'SPIT' is an acronym for 'Spam over Internet Telephony', which Wikipedia de= fines as 'bulk unsolicited, automatically dialled, pre-recorded phone calls= using the Voice over Internet Protocol (VoIP)'. (http://en.wikipedia.org/w= iki/VoIP_spam) We will add a proper definition for SPIT. For the DoD attack: 'DoD' actually does mean 'Department of Defence', the a= uthors of the draft have received information that the Department of Defenc= e plans to attack something, but because of secrecy reasons we cannot give = more information at this time. ;-) Joking apart, yes, this is a typo of 'DoS' (Denial of Service), a proper de= finition will be added. Thanks for your support. Regards, Martin > -----Urspr=FCngliche Nachricht----- > Von: Derek Atkins [mailto:derek@ihtfp.com] > Gesendet: Montag, 17. Dezember 2012 16:55 > An: iesg@ietf.org; secdir@ietf.org > Cc: bliss-chairs@tools.ietf.org; worley@ariadne.com; > H=FClsemann, Martin; Jesske, Roland; alexeitsev@teleflash.com > Betreff: sec-dir review of draft-ietf-bliss-call-completion-18 > > 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. > > The call completion feature defined in this specification > allows the > caller of a failed call to be notified when the callee becomes > available to receive a call. > > The Security Considerations section mentions 'SPIT' but > nowhere does the document define the term. What does it mean? > > The SC section also mentions a "DoD" attack -- is the US > Department of Defence actually going to attack something? Or > does DoD mean something else? It's never defined. Was this > perhaps a typo of "DoS", Denial of Service? If so, I > recommend you fix the typo but also expand the acronym for > those not necessarily familiar with the term "DoS". > > -derek > > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > From rjsparks@nostrum.com Wed Dec 19 08:34:02 2012 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 C00CA21F858C; Wed, 19 Dec 2012 08:33:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, SPF_PASS=-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 xCBYYXIiwcn1; Wed, 19 Dec 2012 08:33:55 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDBB21F8436; Wed, 19 Dec 2012 08:33:55 -0800 (PST) Received: from unnumerable.local (pool-173-71-45-100.dllstx.fios.verizon.net [173.71.45.100]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qBJGUH1b070265 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 19 Dec 2012 10:30:18 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <50D1EB99.1020801@nostrum.com> Date: Wed, 19 Dec 2012 10:30:17 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Martin.Huelsemann@telekom.de References: <9762ACF04FA26B4388476841256BDE02011696144E34@HE111543.emea1.cds.t-internal.com> In-Reply-To: <9762ACF04FA26B4388476841256BDE02011696144E34@HE111543.emea1.cds.t-internal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 173.71.45.100 is authenticated by a trusted mechanism) Cc: secdir@ietf.org, R.Jesske@telekom.de, worley@ariadne.com, iesg@ietf.org, bliss-chairs@tools.ietf.org, alexeitsev@teleflash.com Subject: Re: [secdir] sec-dir review of draft-ietf-bliss-call-completion-18 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, 19 Dec 2012 16:34:02 -0000 On 12/19/12 3:43 AM, Martin.Huelsemann@telekom.de wrote: > Hi Derek, > > thanks for the review. > > 'SPIT' is an acronym for 'Spam over Internet Telephony', which Wikipedia defines as 'bulk unsolicited, automatically dialled, pre-recorded phone calls using the Voice over Internet Protocol (VoIP)'. (http://en.wikipedia.org/wiki/VoIP_spam) > > We will add a proper definition for SPIT. Defining the term in place is sufficient. If you decide you need a reference, consider RFC5039 ("The Session Initiation Protocol (SIP) and Spam"). RjS > > > For the DoD attack: 'DoD' actually does mean 'Department of Defence', the authors of the draft have received information that the Department of Defence plans to attack something, but because of secrecy reasons we cannot give more information at this time. > > ;-) > > Joking apart, yes, this is a typo of 'DoS' (Denial of Service), a proper definition will be added. > > > Thanks for your support. > > > Regards, Martin > > > > > >> -----Ursprüngliche Nachricht----- >> Von: Derek Atkins [mailto:derek@ihtfp.com] >> Gesendet: Montag, 17. Dezember 2012 16:55 >> An: iesg@ietf.org; secdir@ietf.org >> Cc: bliss-chairs@tools.ietf.org; worley@ariadne.com; >> Hülsemann, Martin; Jesske, Roland; alexeitsev@teleflash.com >> Betreff: sec-dir review of draft-ietf-bliss-call-completion-18 >> >> 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. >> >> The call completion feature defined in this specification >> allows the >> caller of a failed call to be notified when the callee becomes >> available to receive a call. >> >> The Security Considerations section mentions 'SPIT' but >> nowhere does the document define the term. What does it mean? >> >> The SC section also mentions a "DoD" attack -- is the US >> Department of Defence actually going to attack something? Or >> does DoD mean something else? It's never defined. Was this >> perhaps a typo of "DoS", Denial of Service? If so, I >> recommend you fix the typo but also expand the acronym for >> those not necessarily familiar with the term "DoS". >> >> -derek >> >> -- >> Derek Atkins 617-623-3745 >> derek@ihtfp.com www.ihtfp.com >> Computer and Internet Security Consultant >> From derek@ihtfp.com Wed Dec 19 09:25:44 2012 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 3FCB121F87AE; Wed, 19 Dec 2012 09:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.141 X-Spam-Level: X-Spam-Status: No, score=-102.141 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, 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 tlve-pJqc7IM; Wed, 19 Dec 2012 09:25:43 -0800 (PST) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 823AA21F878F; Wed, 19 Dec 2012 09:25:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 3E2BC2602B2; Wed, 19 Dec 2012 12:25:40 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 01247-06; Wed, 19 Dec 2012 12:25:37 -0500 (EST) Received: from mocana.ihtfp.org (unknown [IPv6:fe80::224:d7ff:fee7:8924]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id D0B862602A4; Wed, 19 Dec 2012 12:25:37 -0500 (EST) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id qBJHPY1l009167; Wed, 19 Dec 2012 12:25:34 -0500 From: Derek Atkins To: References: <9762ACF04FA26B4388476841256BDE02011696144E34@HE111543.emea1.cds.t-internal.com> Date: Wed, 19 Dec 2012 12:25:32 -0500 In-Reply-To: <9762ACF04FA26B4388476841256BDE02011696144E34@HE111543.emea1.cds.t-internal.com> (Martin Huelsemann's message of "Wed, 19 Dec 2012 10:43:33 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: secdir@ietf.org, R.Jesske@telekom.de, worley@ariadne.com, iesg@ietf.org, bliss-chairs@tools.ietf.org, alexeitsev@teleflash.com Subject: Re: [secdir] sec-dir review of draft-ietf-bliss-call-completion-18 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, 19 Dec 2012 17:25:44 -0000 writes: > Hi Derek, > > thanks for the review. > > 'SPIT' is an acronym for 'Spam over Internet Telephony', which Wikipedia = defines as 'bulk unsolicited, automatically dialled, pre-recorded phone cal= ls using the Voice over Internet Protocol (VoIP)'. (http://en.wikipedia.org= /wiki/VoIP_spam) > > We will add a proper definition for SPIT. I don't think you necessarily need a proper definition. Just expanding the acronym in-place would be sufficient. E.g., "Spam over Internet Telephony (SPIT)" > For the DoD attack: 'DoD' actually does mean 'Department of Defence', the= authors of the draft have received information that the Department of Defe= nce plans to attack something, but because of secrecy reasons we cannot giv= e more information at this time. > > ;-) :-) > Joking apart, yes, this is a typo of 'DoS' (Denial of Service), a proper = definition will be added. Again, no need to add a definition, just expand in-place: "Denial of Service (DoS)" > Thanks for your support. > > > Regards, Martin Thanks! -derek > >> -----Urspr=C3=BCngliche Nachricht----- >> Von: Derek Atkins [mailto:derek@ihtfp.com] >> Gesendet: Montag, 17. Dezember 2012 16:55 >> An: iesg@ietf.org; secdir@ietf.org >> Cc: bliss-chairs@tools.ietf.org; worley@ariadne.com; >> H=C3=BClsemann, Martin; Jesske, Roland; alexeitsev@teleflash.com >> Betreff: sec-dir review of draft-ietf-bliss-call-completion-18 >> >> 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. >> >> The call completion feature defined in this specification >> allows the >> caller of a failed call to be notified when the callee becomes >> available to receive a call. >> >> The Security Considerations section mentions 'SPIT' but >> nowhere does the document define the term. What does it mean? >> >> The SC section also mentions a "DoD" attack -- is the US >> Department of Defence actually going to attack something? Or >> does DoD mean something else? It's never defined. Was this >> perhaps a typo of "DoS", Denial of Service? If so, I >> recommend you fix the typo but also expand the acronym for >> those not necessarily familiar with the term "DoS". >> >> -derek >> >> -- >> Derek Atkins 617-623-3745 >> derek@ihtfp.com www.ihtfp.com >> Computer and Internet Security Consultant >> > > --=20 Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From kivinen@iki.fi Thu Dec 20 01:58:58 2012 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 C0EED21F874B for ; Thu, 20 Dec 2012 01:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 LsoLw1dHlS0s for ; Thu, 20 Dec 2012 01:58:58 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id DB24221F873E for ; Thu, 20 Dec 2012 01:58:56 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qBK9woYm024720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 20 Dec 2012 11:58:50 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qBK9wlBm013778; Thu, 20 Dec 2012 11:58:47 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20690.57687.684598.632735@fireball.kivinen.iki.fi> Date: Thu, 20 Dec 2012 11:58:47 +0200 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 0 min 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: Thu, 20 Dec 2012 09:58:58 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Jeffrey Hutzelman is next in the rotation. For telechat 2012-12-20 Reviewer LC end Draft Richard Barnes T 2012-12-17 draft-ietf-sipclf-format-09 Russ Mundy T 2012-11-12 draft-ietf-mmusic-sdp-media-capabilities-16 Klaas Wierenga T 2012-12-14 draft-ietf-sidr-usecases-05 For telechat 2013-01-10 Rob Austein T 2012-12-19 draft-ietf-mboned-auto-multicast-14 Dave Cridland T 2013-01-02 draft-schaad-pkix-rfc2875-bis-03 Alan DeKok T 2012-12-25 draft-ietf-appsawg-json-patch-08 Donald Eastlake T 2012-12-25 draft-ietf-appsawg-json-pointer-07 Tobias Gondrom T 2013-01-03 draft-ietf-trill-oam-req-04 Steve Hanna T 2012-12-21 draft-ietf-v6ops-464xlat-08 Julien Laganier T 2012-11-19 draft-ietf-karp-routing-tcp-analysis-06 Sam Weiler T 2012-12-26 draft-salgueiro-vcarddav-kind-device-06 Nico Williams T - draft-bonica-special-purpose-03 Glen Zorn T 2012-12-20 draft-ietf-v6ops-icp-guidance-04 Last calls and special requests: Shawn Emery 2012-12-24 draft-ietf-oauth-assertions-08 Phillip Hallam-Baker 2013-01-03 draft-ietf-roll-p2p-rpl-15 Dan Harkins 2013-01-04 draft-ietf-mpls-tp-itu-t-identifiers-06 Sam Hartman 2013-01-07 draft-ietf-sipcore-priority-00 Paul Hoffman 2013-01-14 draft-ietf-sidr-rpki-rtr-protocol-mib-04 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-03 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-10 Eric Rescorla 2012-11-27 draft-ietf-lisp-eid-block-03 Nico Williams - draft-ietf-httpbis-p5-range-21 Tom Yu 2012-12-27 draft-hanes-dispatch-fax-capability-06 Glen Zorn 2012-06-27 draft-hoffman-tao4677bis-16 -- kivinen@iki.fi From shanna@juniper.net Fri Dec 21 17:41:56 2012 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 9FF4B21E804B; Fri, 21 Dec 2012 17:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, 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 dAjGi4glHDEo; Fri, 21 Dec 2012 17:41:55 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id C495121E803A; Fri, 21 Dec 2012 17:41:51 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUNUP3itrLx2v4MkGnuTZdb7n6OOW7dtJ@postini.com; Fri, 21 Dec 2012 17:41:51 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 21 Dec 2012 17:39:23 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 21 Dec 2012 17:39:23 -0800 Received: from CO9EHSOBE042.bigfish.com (207.46.163.25) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 21 Dec 2012 17:42:13 -0800 Received: from mail192-co9-R.bigfish.com (10.236.132.252) by CO9EHSOBE042.bigfish.com (10.236.130.105) with Microsoft SMTP Server id 14.1.225.23; Sat, 22 Dec 2012 01:39:22 +0000 Received: from mail192-co9 (localhost [127.0.0.1]) by mail192-co9-R.bigfish.com (Postfix) with ESMTP id 42F414C01D4; Sat, 22 Dec 2012 01:39:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 0 X-BigFish: PS0(zzzz1de0h1202h1e76h1d1ah1d2ahzzz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail192-co9 (localhost.localdomain [127.0.0.1]) by mail192-co9 (MessageSwitch) id 1356140360445682_2968; Sat, 22 Dec 2012 01:39:20 +0000 (UTC) Received: from CO9EHSMHS014.bigfish.com (unknown [10.236.132.229]) by mail192-co9.bigfish.com (Postfix) with ESMTP id 6A47332004C; Sat, 22 Dec 2012 01:39:20 +0000 (UTC) Received: from SN2PRD0510HT001.namprd05.prod.outlook.com (157.56.234.117) by CO9EHSMHS014.bigfish.com (10.236.130.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 22 Dec 2012 01:39:17 +0000 Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.9.132]) by SN2PRD0510HT001.namprd05.prod.outlook.com ([10.255.116.36]) with mapi id 14.16.0245.002; Sat, 22 Dec 2012 01:39:00 +0000 From: Stephen Hanna To: The IESG , "secdir@ietf.org" , "draft-ietf-v6ops-464xlat.all@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-v6ops-464xlat-08 Thread-Index: AQHN3+UdOvamVaV7306lbsOJnuymOQ== Date: Sat, 22 Dec 2012 01:38:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: [secdir] secdir review of draft-ietf-v6ops-464xlat-08 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: Sat, 22 Dec 2012 01:41:56 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes an architecture for providing IPv4 connectivity across an IPv6-only network. I'm not a fan of documents where the Security Considerations section just says "See these other two specs for the Security Considerations" but in this case it seems that this is adequate. This document is effectively recommends a concatenation stateless v4/v6 translation on the customer side and stateful v6/v4 translation in the provider so it does make sense that the combination of the RFC 6145 and RFC 6146 Security Considerations would do it. And a review of those documents shows that their Security Considerations are thoughtful and well-considered. I did find a few minor typos in section 8.2. In the first paragraph: "a explanation" should be "an explanation" "using combination" should be "using a combination" "is delegated IPv6 prefix" should be "is delegated an IPv6 prefix" Those were the only typos or errors that I found. Note that I am not an expert in address translation or IPv6 operations so there could be hidden security issues here that I didn't find. From joelja@bogus.com Sun Dec 23 10:03:37 2012 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 1674721F8561; Sun, 23 Dec 2012 10:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Np37POd680aG; Sun, 23 Dec 2012 10:03:36 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7F71D21F8551; Sun, 23 Dec 2012 10:03:36 -0800 (PST) Received: from joels-MacBook-Air.local (c-71-193-176-225.hsd1.wa.comcast.net [71.193.176.225]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id qBNI3YOU024143 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 23 Dec 2012 18:03:35 GMT (envelope-from joelja@bogus.com) Message-ID: <50D74775.9070701@bogus.com> Date: Sun, 23 Dec 2012 10:03:33 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: Stephen Hanna References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 23 Dec 2012 18:03:35 +0000 (UTC) Cc: "draft-ietf-v6ops-464xlat.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-v6ops-464xlat-08 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, 23 Dec 2012 18:03:37 -0000 On 12/21/12 5:38 PM, Stephen Hanna 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 an architecture for providing IPv4 connectivity > across an IPv6-only network. I'm not a fan of documents where the > Security Considerations section just says "See these other two specs > for the Security Considerations" but in this case it seems that this > is adequate. This document is effectively recommends a concatenation > stateless v4/v6 translation on the customer side and stateful v6/v4 > translation in the provider so it does make sense that the combination > of the RFC 6145 and RFC 6146 Security Considerations would do it. And > a review of those documents shows that their Security Considerations > are thoughtful and well-considered. I'm in general agreeement with you here. fundamentally 464xlate is a deployment of 6145/6 with specific considerations. I don't believe that any new issues are introduced by deploying them in this fashion. > I did find a few minor typos in section 8.2. In the first paragraph: > > "a explanation" should be "an explanation" > "using combination" should be "using a combination" > "is delegated IPv6 prefix" should be "is delegated an IPv6 prefix" > > Those were the only typos or errors that I found. > > Note that I am not an expert in address translation or IPv6 operations > so there could be hidden security issues here that I didn't find. > > > From tlyu@mit.edu Wed Dec 26 20:37:57 2012 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 9E7E521F8C68; Wed, 26 Dec 2012 20:37:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-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 GChSocWGkc4Z; Wed, 26 Dec 2012 20:37:57 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by ietfa.amsl.com (Postfix) with ESMTP id B1CD321F8BF1; Wed, 26 Dec 2012 20:37:55 -0800 (PST) X-AuditID: 12074424-b7f4e6d0000004ca-86-50dbd0a272a9 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 9E.B7.01226.2A0DBD05; Wed, 26 Dec 2012 23:37:54 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id qBR4brgA003567; Wed, 26 Dec 2012 23:37:54 -0500 Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id qBR4boYi020177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Dec 2012 23:37:52 -0500 (EST) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id qBR4bos2009438; Wed, 26 Dec 2012 23:37:50 -0500 (EST) To: iesg@ietf.org, secdir@ietf.org, draft-hanes-dispatch-fax-capability.all@tools.ietf.org From: Tom Yu Date: Wed, 26 Dec 2012 23:37:50 -0500 Message-ID: Lines: 16 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsUixG6norvowu0Ag5WTZC2Ove5jt5jxZyKz xYeFD1kcmD2WLPnJ5PHl8me2AKYoLpuU1JzMstQifbsEroxJhz4xFTxjq7h16BNjA+MZ1i5G Tg4JAROJ7XueskDYYhIX7q1n62Lk4hAS2Mco8ezLHUYIZwOjROver0wgVUICV5gkXsw2h0h0 MUosWPadHSQhIpAscfzcazBbWMBB4s7HBiCbg4NNQFri6OIykDCLgKrE0hMtzCA2r4CFxPon P5hASngEOCVuv3aECAtKnJz5BOwgZgEtiRv/XjJNYOSbhSQ1C0lqASPTKkbZlNwq3dzEzJzi 1GTd4uTEvLzUIl1zvdzMEr3UlNJNjOBAc1HZwdh8SOkQowAHoxIPr4L17QAh1sSy4srcQ4yS HExKoryTDwOF+JLyUyozEosz4otKc1KLDzFKcDArifBO3wyU401JrKxKLcqHSUlzsCiJ815P uekvJJCeWJKanZpakFoEk5Xh4FCS4H1+HqhRsCg1PbUiLTOnBCHNxMEJMpwHaDjbBZDhxQWJ ucWZ6RD5U4yKUuK8x0CaBUASGaV5cL2wRPCKURzoFWHeOyBVPMAkAtf9CmgwE9DgWL4bIINL EhFSUg2MjnL6z5VSTK6IVGrxr7F0nf7iXmrwok6poE8CTVqCXHvrp7xPXWjE2a2Qm7F5hkns JpW/q1ZG89mZ851m/nr61hErhsO9llmaE/0ijmq+9au7IhUi4rnr8ey+XXYl/pP/lFxWfqEt 1XBG7Nn91AU9v1sm1n34Gjb35o6ddhsE4itCPHtfb01XYinOSDTUYi4qTgQAwg28Z98CAAA= Subject: [secdir] secdir review of draft-hanes-dispatch-fax-capability-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: Thu, 27 Dec 2012 04:37:57 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes a SIP media feature tag for indicating support for fax calls. The Security Considerations section of this document refers to the Security Considerations documented in Section 11.1 of RFC 3840. This seems mostly adequate. One additional question (which might be irrelevant because of my unfamiliarity with SIP) is whether an explicit indication of fax content would make it easier for an eavesdropper to target fax image data (which might contain sensitive information such as credit card numbers). From shawn.emery@oracle.com Sat Dec 29 23:08:24 2012 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 72C0021F882B; Sat, 29 Dec 2012 23:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 sD0g3Kkr2ixI; Sat, 29 Dec 2012 23:08:23 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id A2A4521F8781; Sat, 29 Dec 2012 23:08:23 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qBU78Ms1007220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 30 Dec 2012 07:08:22 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qBU78K5N023612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Dec 2012 07:08:20 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qBU78Kb8025605; Sun, 30 Dec 2012 01:08:20 -0600 Received: from [10.159.67.241] (/10.159.67.241) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 29 Dec 2012 23:08:20 -0800 Message-ID: <50DFE815.2020501@oracle.com> Date: Sun, 30 Dec 2012 00:07:01 -0700 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:10.0.7) Gecko/20121011 Thunderbird/10.0.7 MIME-Version: 1.0 To: secdir@ietf.org References: <50A9523F.9070607@oracle.com> In-Reply-To: <50A9523F.9070607@oracle.com> X-Forwarded-Message-Id: <50A9523F.9070607@oracle.com> Content-Type: multipart/alternative; boundary="------------040106080708040601010101" X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: draft-ietf-oauth-assertions.all@tools.ietf.org, iesg@ietf.org Subject: [secdir] Review of draft-ietf-oauth-assertions-09 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, 30 Dec 2012 07:08:24 -0000 This is a multi-part message in MIME format. --------------040106080708040601010101 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 internet-draft describes an assertion framework for the OAuth 2.0 protocol. Given that that this is a framework, subsequent drafts would be needed for a deployed mechanism. The security considerations section does exist and outlines various issues including impersonation, replay, and privacy. The section then suggests ways of mitigating these threats. This seems sufficient, but can there be more guidance on the Assertion ID to avoid collision or replay (e.g. length, roll-over, etc.)? General comments: None. Editorial comments: Redundant wordings, suggested fix: Old: An IEFT URN for use as the "XXXX" value can be requested using the template in An IETF URN Sub-Namespace for OAuth [RFC6755 ]. New: An IEFT URN for use as the "XXXX" value can be requested using the template in [RFC6755 ]. Shouldn't urn:ietf:params:oauth:grant_type:* be urn:ietf:params:oauth:grant-type:*? s/included yet all/included, yet all/ Shawn. -- --------------040106080708040601010101 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 internet-draft describes an assertion framework for the OAuth 2.0 protocol.  Given that
that this is a framework, subsequent drafts would be needed for a deployed mechanism.

The security considerations section does exist and outlines various issues including
impersonation, replay, and privacy.  The section then suggests ways of mitigating these
threats.  This seems sufficient, but can there be more guidance on the Assertion ID to
avoid collision or replay (e.g. length, roll-over, etc.)?

General comments:

None.

Editorial comments:

Redundant wordings, suggested fix:

Old:

 An IEFT URN for use as the "XXXX" value can be requested using
 the template in An IETF URN Sub-Namespace for OAuth [RFC6755].

New:

 An IEFT URN for use as the "XXXX" value can be requested using
 the template in [RFC6755].

Shouldn't urn:ietf:params:oauth:grant_type:* be 
urn:ietf:params:oauth:grant-type:*?

s/included yet all/included, yet all/

Shawn.
--
--------------040106080708040601010101-- From d3e3e3@gmail.com Sun Dec 30 19:11:27 2012 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 8D33A21F8C11; Sun, 30 Dec 2012 19:11:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.367 X-Spam-Level: X-Spam-Status: No, score=-103.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 supmuIQ9N4C0; Sun, 30 Dec 2012 19:11:27 -0800 (PST) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0106321F8BC2; Sun, 30 Dec 2012 19:11:26 -0800 (PST) Received: by mail-oa0-f48.google.com with SMTP id h2so11157020oag.7 for ; Sun, 30 Dec 2012 19:11:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=tyvxrdVk4piOjHOS55NFIIqj0km72my/XkmybMZfgTo=; b=cZqNab6x6YZtlaaHRL8Vb5nsxczbrX3QloncvidYWpyon7FZ7/L2hGX906ubwrdyMk gfm1cqDHYSGKnN5IrLdtdVAUBi1W2YgAoe5Pw/SoBNC3pPgrUvTp7C+mxMyDl2Y1wNBt bN0GqEFYPMr5uyhdPsQddK8D6NksBbHe5/Wxamx4zV3GN2tqZuzJ9ImONBNt1C2Qvi2n O1whRgjujo+oAezA6E0hGdlXzqDqXPVn7JJOUCW1VjAtA/WNeHhhksLJf4y4wIC9V8l+ wSSHuCmqVOV0Yfe2sYu0+oxD1JXljK9Z7HR6CFXZF282nKeSAKKhd+Ad0+FB2+hl9Irk sGog== Received: by 10.182.185.12 with SMTP id ey12mr33484314obc.7.1356923486452; Sun, 30 Dec 2012 19:11:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.144.105 with HTTP; Sun, 30 Dec 2012 19:11:05 -0800 (PST) From: Donald Eastlake Date: Sun, 30 Dec 2012 22:11:05 -0500 Message-ID: To: iesg@ietf.org, secdir@ietf.org, draft-ietf-appsawg-json-pointer.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] draft-ietf-appsawg-json-pointer-07 SECDIR Review 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, 31 Dec 2012 03:11:27 -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. Document editors and WG chairs should treat these comments just like any other last call comments. This draft describes two closely related syntaxes for pointers to objects within a JSON (JavaScript Object Notation) document. One is a JSON string syntax, the other is a URI fragment identifier for URIs defined to take such a fragment identifier. Security: I do not see any security problems with this document. The syntax appears to be unambiguously specified, including ABNF, and the Security Considerations Section is adequate and touches on the potential pit-falls that JSON pointers can contain NULs. Miscellaneous: I found significant ambiguity in the semantics of a JSON pointer string. Is the result of the successful evaluation ("evaluation" is a term used in the draft) of such a pointer string a structure that points into a JSON document or is it the objection pointed to? It mostly seems to be an object but it is specifically provided that array references could point beyond the end of an array and at least in that case perhaps some sort of pointer structure would be returned with the error condition. It probably doesn't matter, because these syntaxes are intended to be used in a variety of applications and it will be up to the application to clarify the semantics. Minor: The expansion for the acronym JSON should be given in the title and abstract. In the first line of the second paragraph of Section 6, I found the word "nominate" kind of odd. Why not "specify" or "select" or "use"? None of the Authors Addresses given includes a postal address. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com