From weiler@watson.org Thu Apr 1 11:01:25 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D0383A6AF4 for ; Thu, 1 Apr 2010 11:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.135 X-Spam-Level: * X-Spam-Status: No, score=1.135 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-QNvAzYDWD4 for ; Thu, 1 Apr 2010 11:01:24 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 4E5A63A67B0 for ; Thu, 1 Apr 2010 11:01:22 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o31I1sXY099073 for ; Thu, 1 Apr 2010 14:01:54 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o31I1sqM099070 for ; Thu, 1 Apr 2010 14:01:54 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 1 Apr 2010 14:01:54 -0400 (EDT) From: Samuel Weiler To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 01 Apr 2010 14:01:54 -0400 (EDT) Subject: [secdir] draft-ietf-netmod-yang-types X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 18:01:25 -0000 I think this review was for draft-ietf-netmod-yang-types. Resending for ease of searching. -- Sam ---------- Forwarded message ---------- Date: Mon, 22 Mar 2010 02:48:41 -0400 From: Donald Eastlake To: iesg@ietf.org, secdir@ietf.org, draft-ietf-netmod-yang.all@tools.ietf.org Subject: [secdir] draft-ietf-netmod-yang-11.txt I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. This document is essentially data type definitions in YANG for use in NETCONF. As such, the Security Considerations section seems quite adequate. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street +1-508-634-2066 (home) Milford, MA 01757 USA d3e3e3@gmail.com _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From weiler@watson.org Thu Apr 1 11:11:22 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E6EB3A69F6 for ; Thu, 1 Apr 2010 11:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.215 X-Spam-Level: * X-Spam-Status: No, score=1.215 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUlLpTfSZbvO for ; Thu, 1 Apr 2010 11:11:21 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 84B513A68C0 for ; Thu, 1 Apr 2010 11:11:21 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o31IBrZ8000362 for ; Thu, 1 Apr 2010 14:11:53 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o31IBrHX000359 for ; Thu, 1 Apr 2010 14:11:53 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 1 Apr 2010 14:11:53 -0400 (EDT) From: Samuel Weiler To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 01 Apr 2010 14:11:53 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 18:11:22 -0000 No relevant changes to the telechat agenda for next week. (Docs have been added, but all of those reviews are in.) Have a happy April 1st. Russ Mundy is next in the rotation. -- Sam For telechat 2010-04-08 Reviewer Deadline Draft Love Hornquist-Astrand T 2010-04-06 draft-ietf-ccamp-gmpls-mef-uni-03 Chris Newman T 2010-04-06 draft-ietf-krb-wg-preauth-framework-16 Chris Newman T 2010-04-06 draft-ietf-pce-pcep-svec-list-04 For telechat 2010-04-22 Reviewer Deadline Draft Love Hornquist-Astrand T 2010-04-20 draft-ietf-opsawg-smi-datatypes-in-xsd-06 Julien Laganier T 2010-04-20 draft-ietf-dhc-dhcpv6-opt-netboot-08 Barry Leiba T 2010-04-20 draft-ietf-pce-pcep-p2mp-extensions-09 Nico Williams T 2010-04-20 draft-haberman-rpsl-reachable-test-03 Last calls and special requests: Reviewer Deadline Draft Rob Austein 2010-03-29 draft-denenberg-mods-etc-media-types-01 Dave Cridland 2010-03-22 draft-ietf-isms-dtls-tm-09 Alan DeKok 2009-10-01 draft-ietf-enum-enumservices-transition-04 Alan DeKok 2010-03-24 draft-ietf-netmod-yang-11 Stephen Farrell 2010-03-29 draft-ietf-sipcore-info-events-07 Tobias Gondrom 2010-03-24 draft-mattsson-mikey-ticket-02 Phillip Hallam-Baker 2010-03-29 draft-ietf-radext-status-server-06 Steve Hanna None draft-ietf-tsvwg-ecn-tunnel-08 Paul Hoffman 2010-04-05 draft-housley-cms-content-constraints-extn-04 Love Hornquist-Astrand 2010-04-07 draft-ietf-eai-mailinglist-06 Jeffrey Hutzelman 2010-04-06 draft-lawrence-sipforum-user-agent-config-00 Charlie Kaufman 2010-04-05 draft-turner-additional-cms-ri-choices-03 Scott Kelly 2010-04-05 draft-turner-asymmetrickeyformat-algs-01 Stephen Kent 2010-04-05 draft-wallace-using-ta-constraints-02 Tero Kivinen 2010-04-08 draft-freed-sieve-notary-07 Chris Lonvick 2010-04-14 draft-turner-encryptedkeypackagecontenttype-01 David McGrew 2010-03-10 draft-ietf-ecrit-framework-10 David McGrew 2010-04-14 draft-turner-encryptedkeypackagecontenttype-algs-01 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Catherine Meadows None draft-ietf-tsvwg-dtls-for-sctp-05 Vidya Narayanan 2008-11-21 draft-ietf-sip-saml-07 Sam Weiler 2008-08-13 draft-chown-v6ops-rogue-ra-03 Brian Weis 2010-03-15 draft-ietf-nsis-rmd-18 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-04 Tom Yu 2010-03-18 draft-ietf-ipsecme-ikev2bis-08 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-06 Larry Zhu 2010-03-20 draft-ietf-sip-domain-certs-06 From julienl@qualcomm.com Thu Apr 1 11:32:59 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BE943A6817; Thu, 1 Apr 2010 11:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.237 X-Spam-Level: X-Spam-Status: No, score=-105.237 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqE4iwuPJ1cB; Thu, 1 Apr 2010 11:32:58 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id EAAF63A692C; Thu, 1 Apr 2010 11:32:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1270146811; x=1301682811; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20"secdir@ietf.org"=20,=20"iesg@iet f.org"=20|CC:=20"draft-ietf-dhc-dhcpv6-opt -netboot@tools.ietf.org"=0D=0A=09,=0D=0A=09"dhc-chairs@tools.iet f.org"=20|Date:=20Thu,=201=20A pr=202010=2011:33:26=20-0700|Subject:=20SecDir=20review =20of=20draft-ietf-dhc-dhcpv6-opt-netboot-08 |Thread-Topic:=20SecDir=20review=20of=20draft-ietf-dhc-dh cpv6-opt-netboot-08|Thread-Index:=20AcrRydFxSa5l9ppOQnGpk w22tuQLvQ=3D=3D|Message-ID:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=8gFHHYNtQzMk+4sllyVXPGPW3PdsEA4Ioec3lWRsLnI=; b=wwJiyyMh+0+PZxyDmsrJkFMrj/VvRngW2kKTsOHz+HsHGGpOA3nbIhrz 7WNtzgSq/uKxeuPc+RNMNmJLUw9aCUrQRvfBbroHO2184UjaJqAlQIIsS buO8GxAdOybZakbZ3+4AJEYDRsPFXsFrZYTYuLr6lsiZFFj2L/r8QjOu6 s=; X-IronPort-AV: E=McAfee;i="5400,1158,5937"; a="37792519" Received: from ironmsg01-r.qualcomm.com ([172.30.46.15]) by wolverine01.qualcomm.com with ESMTP; 01 Apr 2010 11:33:28 -0700 X-IronPort-AV: E=Sophos;i="4.51,346,1267430400"; d="scan'208";a="4585229" Received: from nasanexhub03.na.qualcomm.com ([10.46.93.98]) by ironmsg01-r.qualcomm.com with ESMTP/TLS/RC4-MD5; 01 Apr 2010 11:33:29 -0700 Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.2.234.1; Thu, 1 Apr 2010 11:33:28 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Thu, 1 Apr 2010 11:33:28 -0700 From: "Laganier, Julien" To: "secdir@ietf.org" , "iesg@ietf.org" Date: Thu, 1 Apr 2010 11:33:26 -0700 Thread-Topic: SecDir review of draft-ietf-dhc-dhcpv6-opt-netboot-08 Thread-Index: AcrRydFxSa5l9ppOQnGpkw22tuQLvQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhc-chairs@tools.ietf.org" , "draft-ietf-dhc-dhcpv6-opt-netboot@tools.ietf.org" Subject: [secdir] SecDir review of draft-ietf-dhc-dhcpv6-opt-netboot-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 18:32:59 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. Document Abstract: The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a framework for passing configuration information to nodes on a network. This document describes new options for DHCPv6 which are required for booting a node from the network. Summary: This is a simple and straightforward DHCPv6 extensions. The Security con= siderations section is appropriate. Authors may consider highlighting the f= act that downloading the wrong operating system could lead to compromise of= data on local storage: 7. Security considerations In untrusted networks, a rogue DHCPv6 server could send the new DHCPv6 options described in this document. The booting clients could then be provided with a wrong URL so that the boot either fails, or even worse, the client boots the wrong operating system which has been provided by a malicious file server. To prevent this kind of attack, clients can use authentication of DHCPv6 messages (see chapter 21. in [RFC3315]). --julien From simon.perreault@viagenie.ca Tue Apr 6 17:27:55 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 669613A672F; Tue, 6 Apr 2010 17:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5rgBMB3Rv4c; Tue, 6 Apr 2010 17:27:54 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by core3.amsl.com (Postfix) with ESMTP id 2CD803A62C1; Tue, 6 Apr 2010 17:27:54 -0700 (PDT) Received: from balaise.nomis80.org (modemcable245.152-21-96.mc.videotron.ca [96.21.152.245]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 37B7E21C38; Tue, 6 Apr 2010 20:27:50 -0400 (EDT) Message-ID: <4BBBD185.7090606@viagenie.ca> Date: Tue, 06 Apr 2010 20:27:49 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc12 Thunderbird/3.0.3 MIME-Version: 1.0 To: Richard Barnes References: <188D3671-05E9-40A2-9498-24BAE91B269E@bbn.com> In-Reply-To: <188D3671-05E9-40A2-9498-24BAE91B269E@bbn.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 07 Apr 2010 05:39:12 -0700 Cc: draft-ietf-behave-turn-ipv6@tools.ietf.org, "behave@ietf.org" , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-behave-turn-ipv6-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 00:27:55 -0000 On 03/29/2010 05:45 PM, Richard Barnes wrote: > My only significant concern that is not addressed in the > document is how this mechanism relates to the routing loop attacks > introduced by other forms of v4/v6 translation and tunneling, e.g., as > discussed in this paper: > > It's not immediately obvious to me that extending TURN in this way makes > these (currently non-TURN-related) attacks viable, but I would encourage > the authors to consider the issue and add some text to the document > explaining how the attacks do or do not apply here. (See bottom of this email.) > S.3, Paragraph "Assuming the request..." > The server doesn't "assume" that the request is authenticated. Suggest > rephrasing as "After the request has been successfully authenticated, ..." Agreed, fixed. > S4.1.1 > Why not just make this option one byte long? If you're already > anticipating a usage for the reserved space, you should just specify it. STUN attributes must be padded to a multiple of 4 bytes. (Reference: RFC 5389, section 15.) > S4.2, First paragraph > As above, suggest rephrasing as "Once a server has verified that the > request is authenticated and has not been tampered with, ..." Agreed, fixed. > S4.3 > Why is this a SHOULD NOT and not a MUST NOT? What's the exceptional case? I have no idea. I'll change it to a MUST NOT unless I receive more info from my co-authors. > Section 9, First para > It seems overly broad to say that "an IPv4-only client having access to > ... this specifictation is now able to access the IPv6 Internet". The > client can't just send/receive traffic with any node, right? Explain > the restrictions in place here. The client can indeed send/receive traffic with any node (as long as it is allowed by local security policy). Could you please explain the restrictions you have in mind? > Section 9, > Might some of the Teredo / 6to4 loop attacks apply as well? If not, why > not? > -- Spoof 4-to-6 allocate request from relay's v4 address > -- Spoof authorization relay's v6 address > -- Spoof packet from either of relay's addresses Sure, these are ways of spoofing IPv6 packets that are enabled by Teredo and 6to4. There are many others. Is there a reference we can cite? Would citing the Usenix paper be OK? > If there is some risk here, you might consider saying something like > "Server MUST NOT allocate 6to4 or Teredo addresses or accept them as > peers"? I have no idea if that would be right or not. Can somebody with a clue please weigh in? Thanks, Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From weiler@watson.org Fri Apr 9 14:52:43 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B66533A6A1C for ; Fri, 9 Apr 2010 14:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lne32voisorK for ; Fri, 9 Apr 2010 14:52:42 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 993B33A6A1F for ; Fri, 9 Apr 2010 14:52:36 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o39LqVlA004854 for ; Fri, 9 Apr 2010 17:52:31 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o39LqVWr004851 for ; Fri, 9 Apr 2010 17:52:31 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 9 Apr 2010 17:52:31 -0400 (EDT) From: Samuel Weiler To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Fri, 09 Apr 2010 17:52:31 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 21:52:43 -0000 Documents on the telechat agenda typically have a last call end date before the date shown below; reviews by the end of last call are typically more appreciated by the doc editors. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Hilarie Orman is next in the rotation. -- Sam For telechat 2010-04-22 Stephen Farrell T 2010-04-20 draft-ietf-sipcore-info-events-07 Love Hornquist-Astrand T 2010-04-20 draft-ietf-opsawg-smi-datatypes-in-xsd-06 Tero Kivinen T 2010-04-20 draft-freed-sieve-notary-07 Russ Mundy T 2010-04-20 draft-ietf-pce-pcep-p2mp-extensions-09 Sandy Murphy T 2010-04-20 draft-ietf-avt-register-srtp-01 Nico Williams T 2010-04-20 draft-haberman-rpsl-reachable-test-03 Last calls and special requests: Rob Austein 2010-03-29 draft-denenberg-mods-etc-media-types-01 Dave Cridland 2010-03-22 draft-ietf-isms-dtls-tm-09 Alan DeKok 2009-10-01 draft-ietf-enum-enumservices-transition-04 Alan DeKok 2010-03-24 draft-ietf-netmod-yang-11 Phillip Hallam-Baker 2010-03-29 draft-ietf-radext-status-server-06 Steve Hanna None draft-ietf-tsvwg-ecn-tunnel-08 Paul Hoffman 2010-04-05 draft-housley-cms-content-constraints-extn-04 Love Hornquist-Astrand 2010-04-07 draft-ietf-eai-mailinglist-06 Jeffrey Hutzelman 2010-04-06 draft-lawrence-sipforum-user-agent-config-00 Charlie Kaufman 2010-04-05 draft-turner-additional-cms-ri-choices-03 Scott Kelly 2010-04-05 draft-turner-asymmetrickeyformat-algs-01 Stephen Kent 2010-04-05 draft-wallace-using-ta-constraints-02 Barry Leiba 2010-04-16 draft-moriarty-post-inch-rid-transport-02 Chris Lonvick 2010-04-14 draft-turner-encryptedkeypackagecontenttype-01 David McGrew 2010-03-10 draft-ietf-ecrit-framework-10 David McGrew 2010-04-14 draft-turner-encryptedkeypackagecontenttype-algs-01 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Catherine Meadows None draft-ietf-tsvwg-dtls-for-sctp-05 Chris Newman 2010-04-19 draft-ietf-ipsecme-aes-ctr-ikev2-07 Magnus Nystrom 2010-04-21 draft-ietf-mpls-tp-framework-11 Sam Weiler 2008-08-13 draft-chown-v6ops-rogue-ra-03 Brian Weis 2010-03-15 draft-ietf-nsis-rmd-19 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-04 Tom Yu 2010-03-18 draft-ietf-ipsecme-ikev2bis-09 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-06 Larry Zhu 2010-03-20 draft-ietf-sip-domain-certs-06 From paul.hoffman@vpnc.org Fri Apr 9 17:17:46 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6E743A6A50 for ; Fri, 9 Apr 2010 17:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.87 X-Spam-Level: X-Spam-Status: No, score=-5.87 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilxesfNiV7Po for ; Fri, 9 Apr 2010 17:17:44 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id A379A3A69E3 for ; Fri, 9 Apr 2010 17:17:42 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o3A0Hbs5000790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Apr 2010 17:17:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Fri, 9 Apr 2010 17:17:35 -0700 To: secdir@ietf.org, draft-housley-cms-content-constraints-extn@tools.ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [secdir] Secdir review of draft-housley-cms-content-constraints-extn X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 00:17:46 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines an extension to CMS that gives content constraints. It does this in an admittedly-limited way, not trying to deal with all types of constraints or all types of content. This extension is certainly security-related, affecting the CMS processing rules, but only for CMS implementations that know about the extension. The Security Considerations section lists some significant implementation choices made by the authors that could trip up an implementer, but these are also called out reasonably well in the body of the document as well. --Paul Hoffman, Director --VPN Consortium From clonvick@cisco.com Sat Apr 10 18:26:12 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 916803A67D7; Sat, 10 Apr 2010 18:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXvP-VIP0er6; Sat, 10 Apr 2010 18:26:11 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 33F353A690A; Sat, 10 Apr 2010 18:24:15 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8FAAbCwEurRN+K/2dsb2JhbACPcwGLVHGecphChQwEgyU X-IronPort-AV: E=Sophos;i="4.52,183,1270425600"; d="scan'208";a="512733512" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 11 Apr 2010 01:24:11 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o3B1OAwX028846; Sun, 11 Apr 2010 01:24:10 GMT Date: Sat, 10 Apr 2010 18:24:10 -0700 (PDT) From: Chris Lonvick To: iesg@ietf.org, secdir@ietf.org, draft-turner-encryptedkeypackagecontenttype-01.all@tools.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cwallace@cygnacom.com Subject: [secdir] SECDIR review of draft-turner-encryptedkeypackagecontenttype-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 01:26:12 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Overall, I do not see any particular security concerns. The document appears to be in good shape and ready for publication. Not finding anything of particular importance to note about the concepts, I started looking at the nits. Section 1 - The following is an awkward sentence: The Cryptographic Message Syntax (CMS) specification [RFC5652] defines means to... Perhaps: The Cryptographic Message Syntax (CMS) specification [RFC5652] defines mechanisms to... (Means means so many different things.) Section 1 also says: This document also defines an unprotected attribute for use with one of the key management options supported by the encrypted key package content type. Not being a crypto geek, I'm left guessing which this is. It's not specifically called out in the document, and the implications of using it are not called out in the Security Considerations section. Why are you asking the RFC Editor to remove the IANA Considerstions section? Maybe I missed it, but I havn't seen any discussion about not having an IANA Considerations section if you don't have anything for the IANA to do. I can see Informational and Experimental RFCs not having anything, but IMHO a Standards Track document should have an IANA Considerations ection even if it is just to say that nothing needs to be done. Regards, Chris From clonvick@cisco.com Sat Apr 10 18:34:53 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BEB93A683F; Sat, 10 Apr 2010 18:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxZTzyAfy2WK; Sat, 10 Apr 2010 18:34:50 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 11EB63A67D7; Sat, 10 Apr 2010 18:34:50 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8FAGPEwEurR7Hu/2dsb2JhbACPcwGLVHGefpg/hQwEgyU X-IronPort-AV: E=Sophos;i="4.52,183,1270425600"; d="scan'208";a="512736014" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 11 Apr 2010 01:34:45 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o3B1YjVR013949; Sun, 11 Apr 2010 01:34:45 GMT Date: Sat, 10 Apr 2010 18:34:45 -0700 (PDT) From: Chris Lonvick To: iesg@ietf.org, secdir@ietf.org, cwallace@cygnacom.com, turners@ieca.com, housley@vigilsec.com, cwallace@cygnacom.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [secdir] SECDIR review of draft-turner-encryptedkeypackagecontenttype-01 (fwd) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 01:34:53 -0000 So, this didn't make it to draft-turner-encryptedkeypackagecontenttype-01.all@tools.ietf.org so I'm sending it again to all of the proper recipients. Please respond to this message. Apologies. Regards, Chris ---------- Forwarded message ---------- Date: Sat, 10 Apr 2010 18:24:10 -0700 (PDT) From: Chris Lonvick To: iesg@ietf.org, secdir@ietf.org, draft-turner-encryptedkeypackagecontenttype-01.all@tools.ietf.org Cc: cwallace@cygnacom.com Subject: [secdir] SECDIR review of draft-turner-encryptedkeypackagecontenttype-01 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Overall, I do not see any particular security concerns. The document appears to be in good shape and ready for publication. Not finding anything of particular importance to note about the concepts, I started looking at the nits. Section 1 - The following is an awkward sentence: The Cryptographic Message Syntax (CMS) specification [RFC5652] defines means to... Perhaps: The Cryptographic Message Syntax (CMS) specification [RFC5652] defines mechanisms to... (Means means so many different things.) Section 1 also says: This document also defines an unprotected attribute for use with one of the key management options supported by the encrypted key package content type. Not being a crypto geek, I'm left guessing which this is. It's not specifically called out in the document, and the implications of using it are not called out in the Security Considerations section. Why are you asking the RFC Editor to remove the IANA Considerstions section? Maybe I missed it, but I havn't seen any discussion about not having an IANA Considerations section if you don't have anything for the IANA to do. I can see Informational and Experimental RFCs not having anything, but IMHO a Standards Track document should have an IANA Considerations ection even if it is just to say that nothing needs to be done. Regards, Chris _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From turners@ieca.com Mon Apr 12 10:22:16 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C52C93A6AB6 for ; Mon, 12 Apr 2010 10:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5ZSw19chxUN for ; Mon, 12 Apr 2010 10:22:14 -0700 (PDT) Received: from smtp112.biz.mail.re2.yahoo.com (smtp112.biz.mail.re2.yahoo.com [66.196.116.97]) by core3.amsl.com (Postfix) with SMTP id D5E7C3A6A99 for ; Mon, 12 Apr 2010 10:20:47 -0700 (PDT) Received: (qmail 32525 invoked from network); 12 Apr 2010 17:20:40 -0000 Received: from thunderfish.local (turners@96.231.117.128 with plain) by smtp112.biz.mail.re2.yahoo.com with SMTP; 12 Apr 2010 10:20:39 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: CWZzMC4VM1k3EV_CjP0S4miFCOb_f3qMf6MKVwzqBSeoS25_Q0sac51IuodChK3lALsmj5vIHIs9MBcV8pBQtnSqXrnBaEf9kwWuQuuBLiyxA6DOQFJbbTPJPRdA8b.BZ_KcamU68NqjGkHfJzzRv8zE_6z.tbR_DX3lNyPA8kaIPfL_euA34EB95i7B_J1ap397TuPpK0VMq8UULevQScseI1Atn8KrmBOhWyUJwNl44Z6ZvHN3PIijjiSbpoezzXhk4jf7j.qCJOPJxwRfMQ9IZwa6r2MZGYLCV8y8QXQGb1IxQ_AC6dES2oDSBUbfZBSWx258b4Io9HURrg_EjqXfu_qn1RVd1N92Zm9SDorByf.lQTgn1DQuh6cZp7tofP6SP9WfpB0MIUiriVV4CSazzpdlI0b5aMu1WxtqTY0RnM7na1LP X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BC35666.60300@ieca.com> Date: Mon, 12 Apr 2010 13:20:38 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Chris Lonvick References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: cwallace@cygnacom.com, draft-turner-encryptedkeypackagecontenttype-01.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-turner-encryptedkeypackagecontenttype-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 17:22:17 -0000 Chris, Thanks for your review. Responses inline. spt Chris Lonvick wrote: > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. > > Overall, I do not see any particular security concerns. The document > appears to be in good shape and ready for publication. > > Not finding anything of particular importance to note about the > concepts, I started looking at the nits. > > Section 1 - The following is an awkward sentence: > The Cryptographic Message Syntax (CMS) specification [RFC5652] > defines means to... > Perhaps: > The Cryptographic Message Syntax (CMS) specification [RFC5652] > defines mechanisms to... > (Means means so many different things.) I'll r/means/mechanisms > Section 1 also says: > This document also defines an unprotected attribute for use with one > of the key management options supported by the encrypted key package > content type. > Not being a crypto geek, I'm left guessing which this is. It's not > specifically called out in the document, and the implications of using > it are not called out in the Security Considerations section. How about I replace that sentence with: This document also defines an unprotected attribute, Content Decryption Key Identifier, for use with EncryptedData. WRT the use of the unprotected attribute: The attribute is used to identify a key that was previously distributed. This kind of mechanism is used in EcnryptedData as well as in certificates (e.g., subject key and authority key identifiers). I looked for some wording from other RFCs that used this kind of mechanism that I could use in a security consideration. But, I couldn't find any. I'm thinking there's isn't any text because as long as people don't do something utterly stupid like use the actual key as the identifier there is no security consideration. > Why are you asking the RFC Editor to remove the IANA Considerstions > section? Maybe I missed it, but I havn't seen any discussion about not > having an IANA Considerations section if you don't have anything for the > IANA to do. I can see Informational and Experimental RFCs not having > anything, but IMHO a Standards Track document should have an IANA > Considerations ection even if it is just to say that nothing needs to be > done. I'll delete the second sentence. From clonvick@cisco.com Mon Apr 12 10:42:50 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C48B3A6A48; Mon, 12 Apr 2010 10:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.289 X-Spam-Level: X-Spam-Status: No, score=-10.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItRJk+WPB9w3; Mon, 12 Apr 2010 10:42:49 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 3C6383A6990; Mon, 12 Apr 2010 10:42:48 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAv4wkurRN+J/2dsb2JhbACbOnGjT5h4gleCNQSDJQ X-IronPort-AV: E=Sophos;i="4.52,191,1270425600"; d="scan'208";a="181822603" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 12 Apr 2010 17:42:43 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o3CHgh8p012268; Mon, 12 Apr 2010 17:42:43 GMT Date: Mon, 12 Apr 2010 10:42:42 -0700 (PDT) From: Chris Lonvick To: Sean Turner In-Reply-To: <4BC35666.60300@ieca.com> Message-ID: References: <4BC35666.60300@ieca.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cwallace@cygnacom.com, draft-turner-encryptedkeypackagecontenttype-01.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-turner-encryptedkeypackagecontenttype-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 17:42:50 -0000 Hi Sean, All looks good. One comment in-line. On Mon, 12 Apr 2010, Sean Turner wrote: > WRT the use of the unprotected attribute: The attribute is used to > identify a key that was previously distributed. This kind of mechanism is > used in EcnryptedData as well as in certificates (e.g., subject key and > authority key identifiers). I looked for some wording from other RFCs that > used this kind of mechanism that I could use in a security consideration. > But, I couldn't find any. I'm thinking there's isn't any text because as > long as people don't do something utterly stupid like use the actual key as > the identifier there is no security consideration. You're on the same track as I was thinking, but I was thinking of something VERY much more generic. From RFCs 2797 and 5273, Implementers of this protocol are strongly encouraged to consider generally accepted principles of secure key management when integrating this capability within an overall security architecture. (Which is a nice way of saying, "Don't be utterly stoopid!" :-) Thanks, Chris From turners@ieca.com Mon Apr 12 11:16:43 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66C913A6ABD for ; Mon, 12 Apr 2010 11:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDHzKiPRCH94 for ; Mon, 12 Apr 2010 11:16:42 -0700 (PDT) Received: from smtp115.biz.mail.re2.yahoo.com (smtp115.biz.mail.re2.yahoo.com [66.196.116.35]) by core3.amsl.com (Postfix) with SMTP id 760B43A6A95 for ; Mon, 12 Apr 2010 11:16:42 -0700 (PDT) Received: (qmail 3280 invoked from network); 12 Apr 2010 18:16:37 -0000 Received: from thunderfish.local (turners@96.231.117.128 with plain) by smtp115.biz.mail.re2.yahoo.com with SMTP; 12 Apr 2010 11:16:37 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: h0DSU1AVM1nBMXCBxHdNCjiwGkdZU18qK2bFN.2u6g88o_KezUwS_nrqoID4dkyXtkw_XK9ivUJPYVNYgFzDvxU_bATpwisf4cW1Y4sYbZ0xLylsJF7cb5XwPucbEYI9wcWazDeQojMrqUk6ArA7e8WrmGFZvgSDB3dhQasqGH50WSPM2vReMAR.pMElSof0py5.74TTKSK6nCAIv.t97rZcBjuSPznwPcjyvORWlMwVWyEqm9mCZ5hiLvl2e_bVp_JLZIFZlc6u6jtXQWD6KmaXyWvUH.1prxbX1A6iOKntjTACXzIAXZk2D6TxdroR_EUDiCoxQqxmf.yi9H8069SvQJGVlPNUy4OJQN.PCBtOF9nu5cYIwnCUl7qskPIdcdNKEsQPCrbYWercZGHrMGiPjo6aS8jMF5LTedza7pztvCtY734v X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BC36385.4060506@ieca.com> Date: Mon, 12 Apr 2010 14:16:37 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Chris Lonvick References: <4BC35666.60300@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: cwallace@cygnacom.com, draft-turner-encryptedkeypackagecontenttype-01.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-turner-encryptedkeypackagecontenttype-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 18:16:43 -0000 Chris Lonvick wrote: > Hi Sean, > > All looks good. One comment in-line. > > On Mon, 12 Apr 2010, Sean Turner wrote: >> WRT the use of the unprotected attribute: The attribute is used to >> identify a key that was previously distributed. This kind of >> mechanism is used in EcnryptedData as well as in certificates (e.g., >> subject key and authority key identifiers). I looked for some wording >> from other RFCs that used this kind of mechanism that I could use in a >> security consideration. But, I couldn't find any. I'm thinking >> there's isn't any text because as long as people don't do something >> utterly stupid like use the actual key as the identifier there is no >> security consideration. > > You're on the same track as I was thinking, but I was thinking of > something VERY much more generic. From RFCs 2797 and 5273, > > Implementers of this protocol are strongly encouraged to consider > generally accepted principles of secure key management when > integrating this capability within an overall security architecture. > > (Which is a nice way of saying, "Don't be utterly stoopid!" :-) I'll add this to the beginning of the considerations. spt From kivinen@iki.fi Tue Apr 13 06:31:16 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4992E3A6A22; Tue, 13 Apr 2010 06:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WS1v1ARKaxY2; Tue, 13 Apr 2010 06:31:15 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id E9C8A3A6827; Tue, 13 Apr 2010 06:31:14 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o3DDV3wP012475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Apr 2010 16:31:03 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o3DDV2io012097; Tue, 13 Apr 2010 16:31:02 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19396.29206.787824.69029@fireball.kivinen.iki.fi> Date: Tue, 13 Apr 2010 16:31:02 +0300 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 20 min X-Total-Time: 19 min Cc: draft-freed-sieve-notary.all@tools.ietf.org Subject: [secdir] Review of draft-freed-sieve-notary-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 13:31:16 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft provides two things. Firstly it will provide ability for sieve email filtering program to see the delivery status notification and deliver by information from the envelope. Secondly it allows setting those same parameters when using sieve redirect action. The first part does not have security issues, but the second might have, as it causes delivery notify emails to be sent which were not originally requested by the original author. This can cause problems for the original sender, as he is now getting the deliver status notifications which he has not requested. The draft does not explictly specify, but I do assume that the sieve redirect keeps the original sender intact, so the deliver status notification messages are sent to the original author, not to the user doing the redirect. The number of delivery status notifications can be quite large, especially if the ":bytrace" option of the redirect is used, as then every single future step for email processing, will send "relayed" status notification, and if there is for example mail loop or similar, this can be several dozen of status notifications. This should most likely be mentioned in the security considerations section more clearly. The security considerations section do warn about generating status notification, and says that "Sites which limit the ability to request success notifications will also need to restrict the ability to request them using the redirect-dsn extension." but that does not help at all, as if the original senders site limits the ability to request notifications, the host running sieve email filter of the receiver might not have such restrictions, thus receiver can enable them even when they were forbidden from the sender. Also in section 5, it should be made clear that the "bytime" can also be negative, if the bymode is "notify" and the message is already pasts is notification time. Section 5 also says that the "bytime" is "the initial integer part of the delive-by extension", but then comments that deliver-by by-time is decremented as message passes through the transport infrastructure. This does not make it clear whether the sieve filtering system should also decrement the number while message is waiting to be processed. I.e. if message was received earlier, but it took some time before the sieve email filter could be run on the message, should the "bytime" be the original time from the smtp MAIL FROM BY= part, or whether it is decremented. Also the example in 5.1 is wrong, as it is only true if the sieve filter is run exactly when the deliver-by expired. It should compare whether the "bytime" is <= 0, not whether it is equal to 0 (note, that if tye bymode is "return" then the "bytime" never should reach 0, as at that point mail is returned to the sender. In section 7 it should be made clear that ":bytime" parameter "" can be negative too, but it seems that RFC 5228 specifies that numbers can only be non-negative so I am not sure whether the usage is correct or not. -- kivinen@iki.fi From new-work-bounces@ietf.org Tue Apr 13 11:00:06 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF5873A6A8D; Tue, 13 Apr 2010 11:00:06 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D7CC73A6855; Tue, 13 Apr 2010 11:00:01 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20100413180001.D7CC73A6855@core3.amsl.com> Date: Tue, 13 Apr 2010 11:00:01 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Tue, 13 Apr 2010 12:18:04 -0700 Subject: [secdir] [New-work] WG Review: DECoupled Application Data Enroute (decade) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 18:00:06 -0000 A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, April 20, 2010. DECoupled Application Data Enroute (decade) -------------------------------------------------- Current Status: Proposed Working Group Last modified: 2010-03-26 Chair(s): TBD Applications Area Director(s): * Alexey Melnikov * Peter Saint-Andre Applications Area Advisor: * Alexey Melnikov Mailing Lists: General Discussion: decade@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/decade Archive: http://www.ietf.org/mail-archive/web/decade/current/maillist.html Description of Working Group: Peer-to-Peer (P2P) applications, including both P2P streaming and P2P file-sharing applications, make up a large fraction of traffic in the Internet today. One way to reduce access network and/or cross-domain bandwidth usage by P2P applications is to introduce storage capabilities in the networks. Allowing P2P applications to store and retrieve data from inside networks can reduce traffic on the last-mile uplink, as well as backbone and transit links. Existing P2P caches often implement the specific P2P application protocols to operate transparently or act as super peers to provide in-network storage. However, it is challenging for P2P cache vendors to support a variety of evolving protocols. Also, for P2P applications, closed P2P caching systems limit effective utilization of in-network storage. Some P2P protocols may be entirely unsupported by a particular caching system. Additionally, applications may be better-equipped to decide how in-network storage is used to meet their specific requirements (e.g., data placement, access control and resource control). Both of these challenges can be effectively addressed by using an open, standard protocol to access in-network storage. P2P applications can store and retrieve content in the in-network storage, as well as control resources (e.g., bandwidth, connections) consumed by peers in a P2P application. As a simple example, a peer can choose to store content in the in-network storage, and direct other peers to retrieve from that location, reducing last-mile link usage. Furthermore, since a P2P client may have multiple peers, it can control resources used by each peer to store and retrieve content. Though there are existing data access protocols (e.g., HTTP, NFS, WebDAV), they might be lacking capabilities for fine-grained access and resource control (e.g., bandwidth and connections) that are essential for today's advanced P2P applications. The Working Group (WG) will have three primary tasks. First, the WG will identify target applications to appropriately scope the problem and requirements. P2P applications are the primary target, but suitability to other applications with similar requirements may be considered depending on additional complexity required to support such applications. Second, the WG will identify the requirements to enable target applications to utilize in-network storage. Requirements will include the ability for an application to (1) store, retrieve, and manage data, (2) indicate access control policies for storing and retrieving data suitable to an environment with users across multiple administrative and security domains (e.g., in a P2P environment), and (3) indicate resource control policies for storing and retrieving data. Third, the WG will develop an architecture within which the DECADE protocol can be specified. This architecture will identify DECADE's relationship to existing IETF protocols and where (if any) new protocol is needed or extensions to existing protocols need to be made. The architecture will not specify a protocol or extension; if development of a new protocol is needed, the WG will seek to recharter for this purpose or might ask an existing WG to work on such extensions. The WG will focus on the following work items: - A "problem statement" document. This document provides a description of the problem and common terminology. - A requirements document. This document lists the requirements for the in-network storage service (e.g., supported operations) and the protocol to support it. The service will include storing, retrieving, and managing data as well as specifying both access control and resource control policies in the in-network storage pertaining to that data. - A survey document. This document will survey existing related mechanisms and protocols (e.g., HTTP, NFS, and WebDAV), and evaluate their applicability to DECADE. - An architecture document. This document will identify DECADE's relationship with existing IETF protocols. Existing protocols will be used wherever possible and appropriate to support DECADE's requirements. In particular, data storage, retrieval, and management may be provided by an existing IETF protocols. The WG will not limit itself to a single data transport protocol since different protocols may have varying implementation costs and performance tradeoffs. However, to keep interoperability manageable, a small number of specific, targeted, data transport protocols will be identified and used. - An document describing the integration of DECADE with existing P2P applications (e.g., integration with BitTorrent). If new protocol development (and hence, rechartering) is deemed necessary, it is not expected that all work items will be ready for IESG review by that point. However, WG consensus must show that documents directing eventual protocol development (Requirements and Architecture document) have stabilized. This permits adjustments to such documents as necessary to maintain consistency as protocol development is done. The following issues are considered out-of-scope for the WG: - Implementation of policies regarding copyright-protected or illegal content. For example, one possibility is that that an in-network storage system may have system-wide ingress and egress filters to implement policies related to copyrighted and illegal content. This is outside the scope of this working group. - Locating the "best" in-network storage location from which to retrieve content if there are more than one location can provide the same content. - Developing a new protocol for data transport between P2P applications and in-network storage. Goals and Milestones: Aug 2010 Working Group Last Call for Problem Statement Nov 2010 Submit Problem Statement to IESG as Informational Nov 2010 Working Group Last Call for Survey document Feb 2011 Submit Survey document to IESG as Informational Feb 2011 Working Group Last Call for Requirements document Feb 2011 Working Group Last Call for Architecture document Mar 2011 Identify need for rechartering May 2011 Submit Requirements document to IESG as Informational Jul 2011 Submit Architecture document to IESG as Informational _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue Apr 13 11:00:06 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5CC33A6A98; Tue, 13 Apr 2010 11:00:06 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 008EF3A68F3; Tue, 13 Apr 2010 11:00:01 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20100413180002.008EF3A68F3@core3.amsl.com> Date: Tue, 13 Apr 2010 11:00:01 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Tue, 13 Apr 2010 12:18:04 -0700 Subject: [secdir] [New-work] WG Review: Congestion Exposure (conex) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 18:00:06 -0000 A new IETF working group has been proposed in the Transport Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, April 20, 2010. Congestion Exposure (conex) -------------------------------------------------- Current Status: Proposed Working Group Last Updated: 2010-04-08 Chair(s): TBD Transport Area Director(s): Lars Eggert David Harrington Transport Area Advisor: Lars Eggert Mailing Lists: TBD Description of Working Group: The purpose of the CONEX working group is to develop a mechanism by which senders inform the network about the congestion encountered by previous packets on the same flow. Today, the network may signal congestion by ECN markings or by dropping packets, and the receiver passes this information back to the sender in transport-layer acknowledgements, The mechanism to be developed by the CONEX WG will enable the sender to also relay the congestion information back into the IP layer, such that the total level of congestion is visible to all IP devices along the path. The primary goal of the CONEX WG is to develop experimental specifications to achieve the above in IPv6 networks. The WG will also develop an abstract, higher-level description of the congestion exposure mechanism. Primary work items are: * An Informational document containing an abstract description of the congestion exposure mechanism that is independent of specific transport protocols and congestion information encoding techniques needed for different IP protocol versions. * An Experimental specification of an IPv6 packet structure that encapsulates CONEX information, defining a packet format and an interpretation. * An Experimental specification of a modification to TCP, for the timely transport of congestion information from the destination to the sender. It is believed that the CONEX mechanism will be useful as a generative technology that can be applied as a key element of congestion management solutions in a wide variety of use cases. However, the CONEX WG will initially focus on one use case, where the end hosts and the network that contains the destination end host are CONEX-enabled but other networks need not be. CONEX information can assist the network operator's traffic management and, for example, incentivize LEDBAT-like applications. Experiments on such use cases are encouraged and the WG will solicit feedback from such deployments. The WG may decide to document the experience from such use cases in Informational documents, covering: * Assumptions made * Deployment considerations * Advice on how to use the CONEX mechanism as an element of a congestion management solution * Security threats and advice on mitigation approaches (detailed specifications of threat mitigation techniques are out of scope) * Descriptions of results from experiments with the use case The CONEX WG is only chartered to work a congestion exposure mechanism for IPv6 networks. When the output of the WG has seen adoption and has proven to be useful, the WG may propose to the IESG that it should be rechartered to extend this effort. Milestones Mar 2011 Submit abstract specification for the congestion exposure mechanism to IESG as Informational Mar 2011 Submit use case description to IESG as Informational Sep 2011 Submit specification of IPv6 packet structure to IESG as Experimental Sep 2011 Submit specification for modification to TCP to IESG as Experimental _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From weiler+secdir@watson.org Wed Apr 14 23:36:20 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C14FB3A69E8 for ; Wed, 14 Apr 2010 23:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUktUKWCI5Sh for ; Wed, 14 Apr 2010 23:36:19 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id B306D3A69E1 for ; Wed, 14 Apr 2010 23:36:19 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o3F6aCHA091393 for ; Thu, 15 Apr 2010 02:36:12 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o3F6aCc1091390 for ; Thu, 15 Apr 2010 02:36:12 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 15 Apr 2010 02:36:12 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 15 Apr 2010 02:36:12 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 06:36:20 -0000 The telechat agenda for next week may not yet be final, but with the number of never-reviewed docs scheduled for it, I decided to send this week's assignments a day or so early, just to give folks more warning. There may be another update to this list in the next couple of days. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2010-04-22 Reviewer Deadline Draft Rob Austein T 2010-04-20 draft-denenberg-mods-etc-media-types-01 Alan DeKok T 2010-04-20 draft-ietf-netmod-yang-12 Shawn Emery TR2010-04-20 draft-ietf-nsis-ext-07 Stephen Farrell T 2010-04-20 draft-ietf-sipcore-info-events-07 Tobias Gondrom TR2010-04-20 draft-mattsson-mikey-ticket-03 Phillip Hallam-Baker T 2010-04-20 draft-ietf-radext-status-server-06 Love Hornquist-Astrand T 2010-04-20 draft-ietf-opsawg-smi-datatypes-in-xsd-06 Scott Kelly T 2010-04-20 draft-turner-asymmetrickeyformat-algs-01 Stephen Kent T 2010-04-20 draft-wallace-using-ta-constraints-02 Russ Mundy T 2010-04-20 draft-ietf-pce-pcep-p2mp-extensions-09 Sandy Murphy T 2010-04-20 draft-ietf-avt-register-srtp-01 Brian Weis T 2010-04-20 draft-ietf-nsis-rmd-19 Nico Williams T 2010-04-20 draft-haberman-rpsl-reachable-test-03 For telechat 2010-05-06 Reviewer Deadline Draft Tom Yu T 2010-05-04 draft-ietf-ipsecme-ikev2bis-10 Last calls and special requests: Reviewer Deadline Draft Dave Cridland 2010-03-22 draft-ietf-isms-dtls-tm-10 Alan DeKok 2009-10-01 draft-ietf-enum-enumservices-transition-04 Steve Hanna None draft-ietf-tsvwg-ecn-tunnel-08 Love Hornquist-Astrand 2010-04-07 draft-ietf-eai-mailinglist-06 Jeffrey Hutzelman 2010-04-06 draft-lawrence-sipforum-user-agent-config-00 Charlie Kaufman 2010-04-05 draft-turner-additional-cms-ri-choices-03 Barry Leiba 2010-04-16 draft-moriarty-post-inch-rid-transport-02 David McGrew 2010-03-10 draft-ietf-ecrit-framework-10 David McGrew 2010-04-14 draft-turner-encryptedkeypackagecontenttype-algs-01 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Catherine Meadows None draft-ietf-tsvwg-dtls-for-sctp-05 Chris Newman 2010-04-19 draft-ietf-ipsecme-aes-ctr-ikev2-07 Magnus Nystrom 2010-04-21 draft-ietf-mpls-tp-framework-11 Hilarie Orman 2010-04-26 draft-hethmon-mcmurray-ftp-hosts-11 Radia Perlman 2010-04-29 draft-ietf-avt-rtp-rfc3984bis-10 Eric Rescorla 2010-04-26 draft-ietf-keyprov-dskpp-10 Vincent Roca 2010-04-26 draft-ietf-keyprov-pskc-05 Joe Salowey 2010-04-26 draft-ietf-keyprov-symmetrickeyformat-07 Stefan Santesson 2010-04-23 draft-reschke-webdav-post-06 Juergen Schoenwaelder 2010-04-26 draft-turner-application-pkcs10-media-type-02 Sam Weiler 2008-08-13 draft-chown-v6ops-rogue-ra-03 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-04 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-06 Larry Zhu 2010-03-20 draft-ietf-sip-domain-certs-06 From barryleiba.mailing.lists@gmail.com Thu Apr 15 07:09:47 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76D3C3A6A37; Thu, 15 Apr 2010 07:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wt8OrmjKXTMl; Thu, 15 Apr 2010 07:09:46 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 98E7028B797; Thu, 15 Apr 2010 07:09:43 -0700 (PDT) Received: by wyb35 with SMTP id 35so664226wyb.31 for ; Thu, 15 Apr 2010 07:09:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:date:received :message-id:subject:from:to:cc:content-type; bh=dYZcE5cf4FvqpUbge5U6zB8GFYbTwhOn3SOnJTpEo6o=; b=jurcMKxsnrZy3qiMMt0DsCvG4NBbQqQxVddElvieocJS8NqjG8U4eGS3equhlWocXi jqBDk2/X1SQ9wYZpiespDyZ94imAIo8Ct+llROYQR13od8af4kTimCpf4IZ1+5K3aKtY 91kW22vIkyRguKA2oQAge2Oqpog/XAU88BdLU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; b=bSIVE4rN2VELCA7K/jiioVSbonUNjEokPKIKZYahrP4w1irfToLNTC74+stqLxs/Uc 2aqeFrNPf3XxDKzdrsEkNACL+TrzUWvWq+p53SwUYsdc8Yu1FbS8LPi4Tzs/g0uHgMgu SoUW0cEvgjS3h+/mNJUB+jPLsGuryFmaHydC8= MIME-Version: 1.0 Received: by 10.216.87.148 with HTTP; Thu, 15 Apr 2010 07:09:33 -0700 (PDT) Date: Thu, 15 Apr 2010 10:09:33 -0400 Received: by 10.216.88.15 with SMTP id z15mr137978wee.92.1271340573938; Thu, 15 Apr 2010 07:09:33 -0700 (PDT) Message-ID: From: Barry Leiba To: draft-moriarty-post-inch-rid-transport.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: iesg@ietf.org, secdir@ietf.org Subject: [secdir] secdir review of draft-moriarty-post-inch-rid-transport-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 14:09:47 -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 is going for Informational status, not Standards Track, and yet defines a protocol layered over HTTP, using normative language. I have some concern about that -- we know how much attention is often NOT paid to the distinction between Informational and Standards Track. Further, HTTP seems particularly ill-suited to transporting this protocol... this seems another in the long line of "use HTTP for everything" cases, which BCP 56 has tried (unsuccessfully) to stave off. The "callbacks", in particular, are worrisome -- the payload has to contain all the state information, the system doing the callback has to have the correct addresses of the system that originally contacted it, and the whole thing is vulnerable to asymmetry problems (firewalls, NAT, multi-homing, and so on; see http://tools.ietf.org/id/draft-iab-ip-model-evolution-01.txt and Dave Thaler's technical plenary presentation from IETF 73, http://www.ietf.org/proceedings/73/plenaryw.html ). At least it's not doing it over port 80. :-) -- Barry Leiba From Nicolas.Williams@oracle.com Thu Apr 15 10:24:55 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03F9A3A6B2E; Thu, 15 Apr 2010 10:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.57 X-Spam-Level: X-Spam-Status: No, score=-4.57 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, FAKE_REPLY_C=2.012, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vp8KWKIZR764; Thu, 15 Apr 2010 10:24:54 -0700 (PDT) Received: from rcsinet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by core3.amsl.com (Postfix) with ESMTP id DB70228C2B5; Thu, 15 Apr 2010 10:23:22 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet12.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o3FHN9YJ029419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Apr 2010 17:23:10 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3FHN3il018759; Thu, 15 Apr 2010 17:23:03 GMT Received: from abhmt003.oracle.com by acsmt353.oracle.com with ESMTP id 178949631271352182; Thu, 15 Apr 2010 10:23:02 -0700 Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 15 Apr 2010 10:23:01 -0700 Date: Thu, 15 Apr 2010 12:22:57 -0500 From: Nicolas Williams To: iesg@ietf.org, secdir@ietf.org Message-ID: <20100415172256.GW10389@Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BC74B7D.001B:SCFMA4539814,ss=1,fgs=0 Cc: brian@innovationslab.net Subject: Re: [secdir] secdir review of draft-haberman-rpsl-reachable-test-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 17:24:55 -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 is aiming for the Standards Track. It defines a pair of RPSL attibutes for advertising IP addresses in a route's address block that can be used for diagnostics via ping, traceroute. The document lacks the normally-required security considerations section. However, I see no security considerations whatever in this document. Nico -- From Nicolas.Williams@oracle.com Thu Apr 15 11:39:24 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE4C73A69D0; Thu, 15 Apr 2010 11:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.581 X-Spam-Level: X-Spam-Status: No, score=-5.581 tagged_above=-999 required=5 tests=[AWL=1.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OEKFFgejo5m; Thu, 15 Apr 2010 11:39:24 -0700 (PDT) Received: from rcsinet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by core3.amsl.com (Postfix) with ESMTP id E94543A6BC4; Thu, 15 Apr 2010 11:39:22 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet12.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o3FIdDj9025539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Apr 2010 18:39:15 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3FGwW4A030861; Thu, 15 Apr 2010 18:39:11 GMT Received: from abhmt002.oracle.com by acsmt354.oracle.com with ESMTP id 163939461271356641; Thu, 15 Apr 2010 11:37:21 -0700 Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 15 Apr 2010 11:37:20 -0700 Date: Thu, 15 Apr 2010 13:37:15 -0500 From: Nicolas Williams To: iesg@ietf.org, secdir@ietf.org Message-ID: <20100415183715.GF11130@Sun.COM> References: <20100415172256.GW10389@Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100415172256.GW10389@Sun.COM> User-Agent: Mutt/1.5.20 (2010-03-02) X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BC75D50.0184:SCFMA4539814,ss=1,fgs=0 Cc: brian@innovationslab.net Subject: Re: [secdir] secdir review of draft-haberman-rpsl-reachable-test-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 18:39:25 -0000 On Thu, Apr 15, 2010 at 12:22:56PM -0500, Nicolas Williams 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 is aiming for the Standards Track. It defines a pair of > RPSL attibutes for advertising IP addresses in a route's address block > that can be used for diagnostics via ping, traceroute. > > The document lacks the normally-required security considerations > section. However, I see no security considerations whatever in this > document. One might also wonder why not have an IANA registry of RPSL attributes. Then there might not have been a need for an RFC to add these two attributes, nor would there have been any need for a secdir review of their registration. Nico -- From j.schoenwaelder@jacobs-university.de Fri Apr 16 01:01:01 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C24BF28C106; Fri, 16 Apr 2010 01:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_20=-0.74, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPjar8hTSMSF; Fri, 16 Apr 2010 01:01:00 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4A13328C11B; Fri, 16 Apr 2010 01:00:28 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 36B1CC0006; Fri, 16 Apr 2010 10:00:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id AglR56HGvDs1; Fri, 16 Apr 2010 10:00:20 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F1943C000C; Fri, 16 Apr 2010 10:00:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 59AE0118D700; Fri, 16 Apr 2010 10:00:12 +0200 (CEST) Date: Fri, 16 Apr 2010 10:00:11 +0200 From: Juergen Schoenwaelder To: turners@ieca.com Message-ID: <20100416080010.GB272@elstar.local> Mail-Followup-To: turners@ieca.com, iesg@ietf.org, secdir@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: iesg@ietf.org, secdir@ietf.org Subject: [secdir] secdir review of draft-turner-application-pkcs10-media-type-02.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 08:01:02 -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 document re-registers the application/pkcs10 MIME type and the security considerations seem adequate. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From turners@ieca.com Sun Apr 18 11:45:58 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A87F28C140 for ; Sun, 18 Apr 2010 11:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.915 X-Spam-Level: X-Spam-Status: No, score=-0.915 tagged_above=-999 required=5 tests=[AWL=-0.917, BAYES_50=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfZNNE2oV+5B for ; Sun, 18 Apr 2010 11:45:57 -0700 (PDT) Received: from smtp115.biz.mail.re2.yahoo.com (smtp115.biz.mail.re2.yahoo.com [66.196.116.35]) by core3.amsl.com (Postfix) with SMTP id C0B6C3A6B9F for ; Sun, 18 Apr 2010 11:45:53 -0700 (PDT) Received: (qmail 36853 invoked from network); 18 Apr 2010 18:45:40 -0000 Received: from thunderfish.local (turners@96.231.123.45 with plain) by smtp115.biz.mail.re2.yahoo.com with SMTP; 18 Apr 2010 11:45:40 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: ORw5JXIVM1mFDrcf0koraq9yuEjndpP7KoQie3YNczXoPAlXVhIXa4vlVbnamhvZ3JxyDKvJDHfHVruB2dKnUheEnghdiKbYLbu0VX4jhyj_m8pwS.IYPM6RAzLjTrX7Injrvi.au8.ToyTBk0hjSS8Ix.gQSWIsDjulYfOUntDluHaNl5.ixaBXny_1cdN.g8XYAYqK74bIsTXXX36YbIzS1r2NK5X.p7smVgRQ.Czf4pmhkHYHzAEnbqvMBShJFsJ6SCOgA3mOMaf7nbtJ0Qe9D2U.lnf4gXXeyRar1AGbMizcjPwdGEmmjqn9cV8zVpi0gzmSrOV_QYki2uusN_Aik2Kos3v5Izw3wMuvQCcHmznPC9sfU1J._K.unNspp2ygQpqPyP5Szgm42KEXShP5yYYHELbXwH42xPD4h_46NVuyzSuF36TqE2a3wEBnaMAnSlgCtd6iipfbguJw6x.dhR2Wn3xw X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BCB5353.902@ieca.com> Date: Sun, 18 Apr 2010 14:45:39 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Mark Nottingham References: <4A7161C0.4040007@ieca.com> <6E228B34-B441-404E-8DDD-8CE46CEAED5E@mnot.net> In-Reply-To: <6E228B34-B441-404E-8DDD-8CE46CEAED5E@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-nottingham-http-link-header@tools.ietf.org, "Julian F. F. Reschke" , secdir Subject: Re: [secdir] secdir review of draft-nottingham-http-link-header X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2010 18:45:58 -0000 I pretty much full on dropped the ball on this. What I was hoping to see was some text that points to a mechanism that can be used to secure the Link header-entity field. Also, (I stole these from RFC4287) I think you should point to security considerations of "stuff" used in this ID like IRIs, URIs, and HTTP headers. Something like: The Link entity-header field makes extensive use of IRIs and URIs. See [RFC3987] for security considerations relating to IRIs. See [RFC3987] for security considerations relating to URIs. See [RFC2616] for security considerations relating to HTTP headers. spt Mark Nottingham wrote: > Thanks, Sean. > > I'm not sure how to incorporate your suggestion into the document; did > you have specific mechanisms in mind, and/or specific placement in the > draft? > > Cheers, > > > On 30/07/2009, at 7:02 PM, Sean Turner 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. >> >> Document: draft-nottingham-http-link-header-06.txt >> Reviewer: Sean Turner >> Review Date: 2009-07-30 >> IETF LC End Date: 2009-08-11 >> IESG Telechat date: N/A >> >> Summary: This document specifies relation types for Web links, and >> defines a registry for them. It also defines how to send such links >> in HTTP headers with the Link header-field. >> >> Comments: The security considerations are pretty clear: the content of >> the fields aren't secured in any way. I think some text should be >> added that says something like "[Mechanism XYZ] can be combined with >> [protocol ABC] to provide the following security service: 1, 2, 3." >> >> spt > > > -- > Mark Nottingham http://www.mnot.net/ > > From mnot@mnot.net Sun Apr 18 18:17:58 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 681A93A6A5A for ; Sun, 18 Apr 2010 18:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-3.600, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJmDxxOz03IT for ; Sun, 18 Apr 2010 18:17:56 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 6ED2E3A6846 for ; Sun, 18 Apr 2010 18:17:56 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.16.193]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 81323509B4; Sun, 18 Apr 2010 21:17:40 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4BCB5353.902@ieca.com> Date: Mon, 19 Apr 2010 11:17:36 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <2BE9ECFF-8FD5-4E4B-8B42-750537F48657@mnot.net> References: <4A7161C0.4040007@ieca.com> <6E228B34-B441-404E-8DDD-8CE46CEAED5E@mnot.net> <4BCB5353.902@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1078) Cc: draft-nottingham-http-link-header@tools.ietf.org, "Julian F. F. Reschke" , secdir Subject: Re: [secdir] secdir review of draft-nottingham-http-link-header X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 01:17:58 -0000 On 19/04/2010, at 4:45 AM, Sean Turner wrote: > I pretty much full on dropped the ball on this. >=20 > What I was hoping to see was some text that points to a mechanism that = can be used to secure the Link header-entity field. TLS/SSL is the only viable option here ATM (although people are making = noises about separate integrity for HTTP, it's going to be a while). I = can add a mention of this at the end of the first paragraph in Security = Considerations. > Also, (I stole these from RFC4287) I think you should point to = security considerations of "stuff" used in this ID like IRIs, URIs, and = HTTP headers. Something like: >=20 > The Link entity-header field makes extensive use of IRIs and URIs. = See [RFC3987] for security considerations relating to IRIs. See = [RFC3987] for security considerations relating to URIs. See [RFC2616] = for security considerations relating to HTTP headers. I can add this at the end of Security Considerations. Cheers, > Mark Nottingham wrote: >> Thanks, Sean. >> I'm not sure how to incorporate your suggestion into the document; = did you have specific mechanisms in mind, and/or specific placement in = the draft? >> Cheers, >> On 30/07/2009, at 7:02 PM, Sean Turner wrote: >>> I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. >>>=20 >>> Document: draft-nottingham-http-link-header-06.txt >>> Reviewer: Sean Turner >>> Review Date: 2009-07-30 >>> IETF LC End Date: 2009-08-11 >>> IESG Telechat date: N/A >>>=20 >>> Summary: This document specifies relation types for Web links, and = defines a registry for them. It also defines how to send such links in = HTTP headers with the Link header-field. >>>=20 >>> Comments: The security considerations are pretty clear: the content = of the fields aren't secured in any way. I think some text should be = added that says something like "[Mechanism XYZ] can be combined with = [protocol ABC] to provide the following security service: 1, 2, 3." >>>=20 >>> spt >> --=20 >> Mark Nottingham http://www.mnot.net/ -- Mark Nottingham http://www.mnot.net/ From turners@ieca.com Sun Apr 18 18:21:48 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 742CD3A6358 for ; Sun, 18 Apr 2010 18:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gK4kGSQ+w-WF for ; Sun, 18 Apr 2010 18:21:44 -0700 (PDT) Received: from smtp114.biz.mail.re2.yahoo.com (smtp114.biz.mail.re2.yahoo.com [66.196.116.99]) by core3.amsl.com (Postfix) with SMTP id 103D53A6931 for ; Sun, 18 Apr 2010 18:21:38 -0700 (PDT) Received: (qmail 81350 invoked from network); 19 Apr 2010 01:21:28 -0000 Received: from thunderfish.local (turners@96.231.119.232 with plain) by smtp114.biz.mail.re2.yahoo.com with SMTP; 18 Apr 2010 18:21:27 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: PG.2QHEVM1mJHIjLtnwKgBR9xBNhtgjUvK_Kh3YE2WLvo674xBFkZYdKdPbiSsLWrJYQs3SF5bZEj7lZ1hOkSWy0W.HZh1cSUjXJVpqRimDTcWQvusTNNZqmBds8Dl1A7uvgqfFthXdR_DTKLp42b1kGRqVCtQWSyJIIQh19xzAMoCSW8oMbOsKCaHRQ9DMGFLDDzQqCDkMdT4LkyPAIfXTjjw.Ldj72Kj7fPXe0c65AUHzWkmTJ5uJSoGolz2MC6fzOQPq8qVi1E7E6Mhw5oSBoJzo.0GneYuNbK5HFhPDes.E2Jx.S1fSfxGY5V_F7HjYrwuOcgNrLRfyfCd0Qi3wYxE_zpqXIpHTHYs0Vo1AGMLXr4E0ZDsyoSL1agf0vz4J4dRQ1J8XlUL1JjucwC_hm12PfDltoDtLblgxI1_7ui3.Pp_5.e5h3cQm9TvJDRBmt42W7v4nYR6MUobVQY5s9A1Y2SIUXf00- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BCBB017.6020303@ieca.com> Date: Sun, 18 Apr 2010 21:21:27 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Mark Nottingham References: <4A7161C0.4040007@ieca.com> <6E228B34-B441-404E-8DDD-8CE46CEAED5E@mnot.net> <4BCB5353.902@ieca.com> <2BE9ECFF-8FD5-4E4B-8B42-750537F48657@mnot.net> In-Reply-To: <2BE9ECFF-8FD5-4E4B-8B42-750537F48657@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-nottingham-http-link-header@tools.ietf.org, "Julian F. F. Reschke" , secdir Subject: Re: [secdir] secdir review of draft-nottingham-http-link-header X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 01:21:48 -0000 Mark Nottingham wrote: > On 19/04/2010, at 4:45 AM, Sean Turner wrote: > >> I pretty much full on dropped the ball on this. >> >> What I was hoping to see was some text that points to a mechanism that can be used to secure the Link header-entity field. > > TLS/SSL is the only viable option here ATM (although people are making noises about separate integrity for HTTP, it's going to be a while). I can add a mention of this at the end of the first paragraph in Security Considerations. > >> Also, (I stole these from RFC4287) I think you should point to security considerations of "stuff" used in this ID like IRIs, URIs, and HTTP headers. Something like: >> >> The Link entity-header field makes extensive use of IRIs and URIs. See [RFC3987] for security considerations relating to IRIs. See [RFC3987] for security considerations relating to URIs. See [RFC2616] for security considerations relating to HTTP headers. > > I can add this at the end of Security Considerations. That would do it. Thanks and sorry again for spacing so badly on getting back to you. spt > Cheers, > > >> Mark Nottingham wrote: >>> Thanks, Sean. >>> I'm not sure how to incorporate your suggestion into the document; did you have specific mechanisms in mind, and/or specific placement in the draft? >>> Cheers, >>> On 30/07/2009, at 7:02 PM, Sean Turner 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. >>>> >>>> Document: draft-nottingham-http-link-header-06.txt >>>> Reviewer: Sean Turner >>>> Review Date: 2009-07-30 >>>> IETF LC End Date: 2009-08-11 >>>> IESG Telechat date: N/A >>>> >>>> Summary: This document specifies relation types for Web links, and defines a registry for them. It also defines how to send such links in HTTP headers with the Link header-field. >>>> >>>> Comments: The security considerations are pretty clear: the content of the fields aren't secured in any way. I think some text should be added that says something like "[Mechanism XYZ] can be combined with [protocol ABC] to provide the following security service: 1, 2, 3." >>>> >>>> spt >>> -- >>> Mark Nottingham http://www.mnot.net/ > > > -- > Mark Nottingham http://www.mnot.net/ > > From bew@cisco.com Sun Apr 18 23:15:12 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DB5C3A6AB1; Sun, 18 Apr 2010 23:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.299 X-Spam-Level: X-Spam-Status: No, score=-9.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5J0PBTG-56lm; Sun, 18 Apr 2010 23:15:11 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 59F9E3A6845; Sun, 18 Apr 2010 23:15:11 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAA6Ry0urR7Ht/2dsb2JhbACbdXGgPpkIhRAEgzI X-IronPort-AV: E=Sophos;i="4.52,234,1270425600"; d="scan'208";a="517137168" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 19 Apr 2010 06:15:03 +0000 Received: from stealth-10-32-244-210.cisco.com (stealth-10-32-244-210.cisco.com [10.32.244.210]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3J6F2Hf010436; Mon, 19 Apr 2010 06:15:03 GMT Message-Id: <4CCE7D8C-DECC-479D-89F6-FCA316050ADC@cisco.com> From: Brian Weis To: secdir@ietf.org, iesg@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 18 Apr 2010 23:15:02 -0700 X-Mailer: Apple Mail (2.936) Cc: draft-ietf-nsis-rmd@tools.ietf.org, nsis-chairs@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-nsis-rmd-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 06:15:12 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These 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 NSIS QoS Model for networks that use the Resource Management in Diffserv (RMD) concept. It describes RMD-QOSM, which are new payloads sent using the GISP signaling mechanism, where the new payloads request or reserve resources. A number of data flows are discussed, depending on whether nodes within a network boundary participate in the protocol or not. The Security Considerations section covers the following topics: - Byzantine adversaries (i.e., participants taken over by an adversary) are a general problem, but this section intends to discuss additional threats as a result of the new protocol. There is an extensive discussion of on-path and off-path adversaries, which seems to intend to be addressing Byzantine adversaries. - RMD-QOSM is claimed to be lightweight, with different routers allowed certain operations dependant on the role a router plays in the system. E.g., only Ingress/Egress nodes are allowed to initiate certain signaling messages. - RMD-QOSM "relies on the security support that is provided by the bounded end-to-end session, which is running between the boundaries of the RMD domain", but doesn't mandate that security support. The existing text is helpful, but not sufficient. The following points are suggestions to improve this section. 1. The statement at the beginning of Security Considerations discusses adversaries taking over a router, but the new threats are not very clear. Are the authors considering that security associations are revealed, that reservation data routed to a particular router can be changed or forged, or something else? 2. The trust model used by RMD-QOSM is hinted at in the discussion of on-path and off-path adversaries, but a discussion of exactly what devices are trusted and what they're trusted to do would be helpful. For example, is every interior router in the network is trusted to handle any particular RESERVE or RESERVE` message? If not, then how are the paths setup so that only authorized routers will see a particular message? On the other hand, if routing is used to route the messages then it would seem that any router must be authorized to handle messages happened to be routed to them -- but then it isn't clear that there can be a difference between an "on-path" and "off- path" adversary. 3. Another dimension of trust model is the fact that ingress/egress routers seem to trust each other more than they trust interior nodes. This seems evidenced by the fact that RESERVE messages (Figure 24) don't seem to be intended to be modified by the interior routers. In the case of probes, I would expect that this would be especially important, but probes do not seem to be specifically discussed in this section. 4. There don't seem to be any actual security requirements or recommendations made on GIST messaging. As such, it isn't clear that attackers that have not taken over a participant (i.e., a man in the middle) are in any way foiled. I would expect to see more MUSTs and SHOULDs in this section regarding message security. There are statements in the I-D such as "In the situation a security association exists" and "If we assume that the RESERVE/RESPONSE is sent with hop- by-hop channel security". There should be some description of the threats to the messaging by a non-participant, and stating what available mechanisms MUST or SHOULD be used. 5. Since roles seem to be an important part of the security considerations, it would be helpful to see discussion of the different threats & requirements on the ingress/egress routers and the internal routers in their different roles. 6. An important service of RMD-QOSM is admission control, but there doesn't seem to be any discussion of how the ingress routers determine whether or not reservation requests given to them are valid. I would have thought that is of particular importance, but if it's considered out of scope this section might mention that fact. Hope that helps, Brian From shawn.emery@oracle.com Mon Apr 19 16:18:26 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 844323A67F4; Mon, 19 Apr 2010 16:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMdqiSlTa28M; Mon, 19 Apr 2010 16:18:25 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 77B033A67E3; Mon, 19 Apr 2010 16:18:24 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3JNI7gt032730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Apr 2010 23:18:09 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3JLcuVJ021864; Mon, 19 Apr 2010 23:18:04 GMT Received: from abhmt005.oracle.com by acsmt354.oracle.com with ESMTP id 172428781271719075; Mon, 19 Apr 2010 16:17:55 -0700 Received: from [129.150.12.239] (/129.150.12.239) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 19 Apr 2010 16:17:54 -0700 Message-ID: <4BCCE4A1.1030009@oracle.com> Date: Mon, 19 Apr 2010 17:17:53 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: elwynd@folly.org.uk References: <4BA48592.8040804@sun.com> <4BA4EB7D.3080702@folly.org.uk> In-Reply-To: <4BA4EB7D.3080702@folly.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: rcsinet13.oracle.com [148.87.113.125] X-CT-RefId: str=0001.0A090204.4BCCE4B3.00CD:SCFMA4539811,ss=1,fgs=0 X-Mailman-Approved-At: Mon, 19 Apr 2010 16:57:34 -0700 Cc: draft-ietf-nsis-ext.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-ietf-nsis-ext-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 23:18:26 -0000 I have reviewed revision 07 of this draft and find that the requested updates have been sufficiently made. Thanks, Shawn. -- On 03/20/10 09:36 AM, Elwyn Davies wrote: > Thanks for the review. > > The suggestion about RFC 4081 is well taken. > > I will take the editorials under advisement! > > Regards, > Elwyn > > Shawn M Emery 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 draft describes is an informational document that provides an >> overview of the Next Steps in Signaling (NSIS) set of protocols, how >> to deploy said protocols, and how to extend the set of NSIS protocols. >> >> The security considerations section does exist and gives guidance for >> any extensions to the NSIS protocol set. It then talks about using >> authentication, integrity checks, and authorization for any NSIS >> supported routers. >> >> The section continues guidance for extensions by making sure they >> leverage NSIS' lower layer transport authentication and that any new >> transport protocols created support NSIS' low layer authentication and >> integrity check capabilities. >> >> I think this section should include a reference to RFC 4081 for the >> possible attack scenarios for NSIS when considering an extension to >> the NSIS protocol set. >> >> General comments: >> >> None. >> >> Editorial comments: >> >> 3. The General Internet Signaling Transport >> >> s/in future/in the future/ >> >> >> 8. Extending the Protocols >> >> s/identified in future/identified in the future/ >> >> > > From trammell@tik.ee.ethz.ch Mon Apr 19 05:49:29 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 769F03A68F6; Mon, 19 Apr 2010 05:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-wrvU5509FC; Mon, 19 Apr 2010 05:49:28 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id DD0D03A687E; Mon, 19 Apr 2010 05:49:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 6F877D936B; Mon, 19 Apr 2010 14:49:17 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MdO5fU3dwzHr; Mon, 19 Apr 2010 14:49:17 +0200 (MEST) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 3367BD9373; Mon, 19 Apr 2010 14:49:17 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1078) From: Brian Trammell Date: Mon, 19 Apr 2010 14:49:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: barryleiba.mailing.lists@gmail.com X-Mailer: Apple Mail (2.1078) X-Mailman-Approved-At: Mon, 19 Apr 2010 16:57:59 -0700 Cc: secdir@ietf.org, iesg@ietf.org, Kathleen Moriarty Subject: [secdir] Fwd: secdir review of draft-moriarty-post-inch-rid-transport-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 12:49:29 -0000 Hi, Barry, Many thanks for your review! My response, in brief, would be, yes, we = need to remove the 2119 language, but it is unclear what we should do = instead of using HTTP as a substrate. Detailed responses inline, below. Best regards, Brian > -----Original Message----- > From: Barry Leiba [mailto:barryleiba.mailing.lists@gmail.com]=20 > Sent: Thursday, April 15, 2010 10:10 AM > To: draft-moriarty-post-inch-rid-transport.all@tools.ietf.org > Cc: iesg@ietf.org; secdir@ietf.org > Subject: secdir review of draft-moriarty-post-inch-rid-transport-02 >=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 is going for Informational status, not Standards Track, > and yet defines a protocol layered over HTTP, using normative > language. We've had the same issue when turning standards into guidelines in IPFIX (when RFC5473 was first submitted to the IESG, it had a lot of 2119 = language in it). We presume that stripping 2119 refs and lowercasing everything would be an acceptable solution here as well, but we've not done that yet. > I have some concern about that -- we know how much > attention is often NOT paid to the distinction between Informational > and Standards Track. Further, HTTP seems particularly ill-suited to > transporting this protocol... this seems another in the long line of > "use HTTP for everything" cases, which BCP 56 has tried > (unsuccessfully) to stave off. We acknowledge as such, directly in the document. However, we cannot ignore that for the types of data we're moving around, HTTP seems to be pretty much the only base protocol we can extend that has the implementation support and community understanding to get into production quickly, in a way that's easy to integrate with the security policies surrounding public-facing information services at most organizations likely to be members of a RID consortium.=20 BEEP was supposed to do this. It didn't. Shimming something like SOAP in here is insanely complicated for what we're doing (indeed, the old version of the document was SOAP based, and nobody liked it, least of all the authors), and anyway still needs a transport binding.=20 We could define something over bare sockets would end up for the most part replicating what we've done with HTTP, but make the document much longer and obscure the fact that we've taken most of the base interaction from HTTP, thereby making it harder to implement. Given these considerations, we consider HTTP the worst base protocol for RID, except for all the others that have been implemented (more than once). > The "callbacks", in particular, are > worrisome -- the payload has to contain all the state information, the > system doing the callback has to have the correct addresses of the > system that originally contacted it, and the whole thing is vulnerable > to asymmetry problems (firewalls, NAT, multi-homing, and so on; see > http://tools.ietf.org/id/draft-iab-ip-model-evolution-01.txt and Dave > Thaler's technical plenary presentation from IETF 73, > http://www.ietf.org/proceedings/73/plenaryw.html ). Given the arbitrary amount of time that a RID interchange might take (minutes, hours, even days if there's human interaction involved and the request is considered low-priority enough at the receiving end), any transport for RID is going to have a callback mechanism anyway, unless we want to force people to hold TCP sessions open for long periods, which has its own problems. In a RID infrastructure, each consortium member is expected to have a well-known, public-facing endpoint; getting around the asymmetry problems is therefore considered a deployment-time consideration. I suppose this could be made clearer in the document. From stephen.farrell@cs.tcd.ie Tue Apr 20 02:18:58 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94E1D28C0FD for ; Tue, 20 Apr 2010 02:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RU5ZKNMjwQ+t for ; Tue, 20 Apr 2010 02:18:56 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id 3C2883A6900 for ; Tue, 20 Apr 2010 02:18:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 681773E4083; Tue, 20 Apr 2010 10:18:39 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1271755118; bh=YNow6914nNIh13NJQMkM8SWC 44WplpGbVYlr0Pk0N1M=; b=CFFqsf/rWNyI/re8Xd4sUAgHjYGX0dDd16vKThxK yqjtcbCaCTGF+2G7uvGjr7hhRs67hd3Q+XsylOmOxubHPxNvtPh0Iy/gxemykX55 +iYFPrDWqRf/QpRR75uP/b3Fi7+vMSNcmO+Op6uEit6D1ihSSfsz3d85bGPSPs38 PR/qPDlLlh1uWDuqnBO7ethcUvrUS+4KE1fDa2KzcowVI0U+eeeGQVszaByNqZc6 neVMilgRZ/NHuU6qSrzGM/wIkiRIGQXYUvFAXu5UQMXr5jOVwjnrq8xiuv/Xvfol lqNGBpnal8hX12Qvk5CrcMLe/aTO0XipygJeCFq3t+Sxbg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id aBgUrh-G7337; Tue, 20 Apr 2010 10:18:38 +0100 (IST) Received: from [134.226.36.180] (sfarrell.dsg.cs.tcd.ie [134.226.36.180]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 964143E407F; Tue, 20 Apr 2010 10:18:36 +0100 (IST) Message-ID: <4BCD7169.9020701@cs.tcd.ie> Date: Tue, 20 Apr 2010 10:18:33 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: secdir@ietf.org, draft-ietf-sipcore-info-events@tools.ietf.org, sipcore-chairs@tools.ietf.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] secdir review of draft-ietf-sipcore-info-events X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 09:18:58 -0000 Hi, (Sorry for the tardy review;-) This specification sort-of provides a SIP-based tunnel for application protocols. 1: What prevents (or allows detection of) insertion of bogus Info Package specifications? (e.g. by a proxy). If nothing, then why is this ok? 2: I don't know how prevalent implementations of this are, or will be, but since this calls for the user agents to include a MIME parser plus parsers for whatever MIME types the user agent claims to support, I'd say some guideance about defensive programming (e.g. avoiding buffer overruns etc.) should be given somewhere (maybe that's a more generic SIP thing though). 3. 4.2.2. says that a UA MUST indicate which Info packages it supports. That seems a bit open-kimono - why MUST all UAs tell everyone everything they support all the time? Won't that expose more attack surface than is wise? Wouldn't it be better to first know who the other UA is, before telling them everything every time? For example, imagine a UA supported the "US Govt SECRET foobar application Info Package," I'm guessing that it wouldn't be ok to just say that to every UA one meets on the Internet. 4. 10.10 says that if TLS is not good enough, then use S/MIME. My understanding is that no UAs implement S/MIME (or CMS really) and no networks support its use. So shouldn't that really say "if TLS is not good enough, then just don't do it or require the application to do its own security"? Same point applies to section 13. I would think that securing specific applications would be easier and more likely than getting S/MIME used in UAs, so why not recommend that? 5. 1st para of section 13 says that this will be an improvement over RFC2976. I would think a reference to the problems with that RFC or to something detailing the expected improvement is warranted. 6. How and why would one "filter for approved Info Packages" as stated in section 13? It seems like that single sentence is either too much or too little, so maybe delete it or expand upon it, so that an implementer might know what's reasonable filtering. Non security notes: s1, 2nd para: how can you prevent INFO being used to update the state of a "SIP dialog or session"? Seems like it'd be more accurate to say that that's the intent but that there really are no guarantees. The example given in the abstract of RFC2976 seems in fact to be directly related to signalling so that's confusing. Nits/Typos: 10.10: s/certain level/a certain level/ Stephen. From christer.holmberg@ericsson.com Tue Apr 20 06:19:54 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0245428C155 for ; Tue, 20 Apr 2010 06:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.226 X-Spam-Level: X-Spam-Status: No, score=-5.226 tagged_above=-999 required=5 tests=[AWL=1.373, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHIpw5+1DphF for ; Tue, 20 Apr 2010 06:19:51 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id F402C3A69E2 for ; Tue, 20 Apr 2010 06:19:24 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-d7-4bcda9d259fe Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 0C.DE.23532.2D9ADCB4; Tue, 20 Apr 2010 15:19:14 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 20 Apr 2010 15:19:14 +0200 From: Christer Holmberg To: Stephen Farrell , "secdir@ietf.org" , "draft-ietf-sipcore-info-events@tools.ietf.org" , "sipcore-chairs@tools.ietf.org" Date: Tue, 20 Apr 2010 15:19:07 +0200 Thread-Topic: secdir review of draft-ietf-sipcore-info-events Thread-Index: Acrgan2adtTaRafGR3CloxG6hYVqjgAHTm7g Message-ID: References: <4BCD7169.9020701@cs.tcd.ie> In-Reply-To: <4BCD7169.9020701@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [secdir] secdir review of draft-ietf-sipcore-info-events X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 13:19:54 -0000 Hi Stephen,=20 Thanks for your review! Comments inline. ------- >This specification sort-of provides a SIP-based tunnel for=20 >application protocols. >=20 >1: What prevents (or allows detection of) insertion of bogus=20 >Info Package specifications? (e.g. by a proxy). If nothing,=20 >then why is this ok? Unless you somehow secure your SIP signalling, evil proxies can insert/modi= fy/remove more or less whatever information elements in the messages. It's = not specific to INFO. ------- >2: I don't know how prevalent implementations of this are, or=20 >will be, but since this calls for the user agents to include=20 >a MIME parser plus parsers for whatever MIME types the user=20 >agent claims to support, I'd say some guideance about=20 >defensive programming (e.g. avoiding buffer overruns >etc.) should be given somewhere (maybe that's a more generic=20 >SIP thing though). It is not necessarily the SIP stack of the user agent itself that needs to = include the parser, but the application using the Info Package. Also, I belive you would have the same issue for event packages. Having said that, the trend today seem to be using XML, so probably there w= ill not be a need for too many parsers. ------- =20 >3. 4.2.2. says that a UA MUST indicate which Info packages it=20 >supports. That seems a bit open-kimono - why MUST all UAs=20 >tell everyone everything they support all the time? Won't=20 >that expose more attack surface than is wise? Wouldn't it be=20 >better to first know who the other UA is, before telling them=20 >everything every time? For example, imagine a UA supported=20 >the "US Govt SECRET foobar application Info Package," I'm=20 >guessing that it wouldn't be ok to just say that to every UA=20 >one meets on the Internet. The intention is to say that a UA MUST indicate which Info Packages it is w= illing to support for a specific session. So, maybe something like: "A UA which supports the Info Package mechanism MUST indicate, using the Recv-Info header field, the set of Info Packages for which it is willing to receive INFO requests for a specific session." ------- >4. 10.10 says that if TLS is not good enough, then use S/MIME. >My understanding is that no UAs implement S/MIME (or CMS=20 >really) and no networks support its use. So shouldn't that=20 >really say "if TLS is not good enough, then just don't do it=20 >or require the application to do its own security"? Same=20 >point applies to section 13. I would think that securing=20 >specific applications would be easier and more likely than=20 >getting S/MIME used in UAs, so why not recommend that? I don't think 10.10 says "then use S/MIME". It only says that one way to ac= hieve end-to-end application security is to use S/MIME. Section 13 doesn't = mention S/MIME. And, the text DOES say that the Info Package specification needs to specify= what kind of security is required. ------- >5. 1st para of section 13 says that this will be an=20 >improvement over RFC2976. I would think a reference to the=20 >problems with that RFC or to something detailing the expected=20 >improvement is warranted. I guess a reference to section 9.2 could be added: "By eliminating multiple usages of INFO messages without adequate community review and by eliminating the possibility for rogue SIP UAs from confusing another UA by purposely sending unrelated INFO requests, as described in section 9.2, we expect this document's=20 clarification of the use of INFO to improve the security of the Internet." ------- >6. How and why would one "filter for approved Info Packages"=20 >as stated in section 13? It seems like that single sentence=20 >is either too much or too little, so maybe delete it or=20 >expand upon it, so that an implementer might know what's=20 >reasonable filtering. Maybe the text could be modified to: "Whilst rogue UAs can still send unrelated INFO requests, this mechanism pr= ovides mechanisms for which the UAS and other security devices can associate INFO requests with I= nfo Packages that have been negotiated for a session." ------- >Non security notes: >=20 >s1, 2nd para: how can you prevent INFO being used to update=20 >the state of a "SIP dialog or session"? Seems like it'd be=20 >more accurate to say that that's the intent but that there=20 >really are no guarantees. The example given in the abstract=20 >of RFC2976 seems in fact to be directly related to signalling=20 >so that's confusing. The purpose of the expert review is to ensure that an Info Package does not= update the state. Of course, an application that receives an Info Package may trigger actions= that updates the session state. ------- >Nits/Typos: >=20 >10.10: s/certain level/a certain level/ Fixed it will be. Thank You! Regards, Christer From adam@nostrum.com Tue Apr 20 06:26:59 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 504173A6A9A for ; Tue, 20 Apr 2010 06:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jgAQK7JjHDw for ; Tue, 20 Apr 2010 06:26:58 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 1F85A28C15F for ; Tue, 20 Apr 2010 06:26:33 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o3KDQIwk063742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Apr 2010 08:26:18 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BCDAB7A.7080208@nostrum.com> Date: Tue, 20 Apr 2010 08:26:18 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Stephen Farrell References: <4BCD7169.9020701@cs.tcd.ie> In-Reply-To: <4BCD7169.9020701@cs.tcd.ie> Content-Type: multipart/alternative; boundary="------------090107090809010306030206" Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Tue, 20 Apr 2010 09:05:20 -0700 Cc: draft-ietf-sipcore-info-events@tools.ietf.org, sipcore-chairs@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-sipcore-info-events X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 13:26:59 -0000 This is a multi-part message in MIME format. --------------090107090809010306030206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 4/20/10 04:18, Apr 20, Stephen Farrell wrote: > Hi, > > (Sorry for the tardy review;-) > > This specification sort-of provides a SIP-based tunnel > for application protocols. > > 1: What prevents (or allows detection of) insertion of > bogus Info Package specifications? (e.g. by a proxy). If > nothing, then why is this ok? > This is the general way that SIP works, and it applies to all the SIP header fields. It's not great, but proxies are implicitly trusted to do the right thing. If it's a problem for INFO, then it's a problem for everything that has ever used or will ever use SIP. > 2: I don't know how prevalent implementations of this are, > or will be, but since this calls for the user agents to > include a MIME parser plus parsers for whatever MIME types > the user agent claims to support, I'd say some guideance > about defensive programming (e.g. avoiding buffer overruns > etc.) should be given somewhere (maybe that's a more generic > SIP thing though). > I would think that's also a general comment about the way that SIP works. Such guidance would seem out of place squirreled away in a document that is otherwise simply defining a new method. In fact, I would argue that it should be attached to a MIME-related document, not a SIP-related one. > 3. 4.2.2. says that a UA MUST indicate which Info packages it > supports. That seems a bit open-kimono - why MUST all UAs tell > everyone everything they support all the time? Won't that > expose more attack surface than is wise? Wouldn't it be better > to first know who the other UA is, before telling them everything > every time? For example, imagine a UA supported the "US Govt > SECRET foobar application Info Package," I'm guessing that it > wouldn't be ok to just say that to every UA one meets on > the Internet. > I think that's a somewhat tortured reading of that text. The actual text is: A UA which supports the Info Package mechanism MUST indicate, using the Recv-Info header field, the set of Info Packages for which it is willing to receive INFO requests. This leaves a lot of wiggle room around the difference between "supports" and "is willing to receive." > 4. 10.10 says that if TLS is not good enough, then use S/MIME. > My understanding is that no UAs implement S/MIME (or CMS really) > and no networks support its use. So shouldn't that really say > "if TLS is not good enough, then just don't do it or require > the application to do its own security"? Same point applies to > section 13. I would think that securing specific applications > would be easier and more likely than getting S/MIME used in UAs, > so why not recommend that? > The difficulties with getting S/MIME deployed in SIP, I think, stem from the lack of a viable PKI. With the publication of draft-ietf-sip-certs-12 as an RFC -- which I anticipate happening soon -- I have renewed hope that S/MIME may se some deployment yet. > 5. 1st para of section 13 says that this will be an improvement > over RFC2976. I would think a reference to the problems with > that RFC or to something detailing the expected improvement is > warranted. > So you want it to point back to section 9.2? > Non security notes: > > s1, 2nd para: how can you prevent INFO being used to update the > state of a "SIP dialog or session"? Seems like it'd be more > accurate to say that that's the intent but that there really are > no guarantees. The example given in the abstract of RFC2976 seems > in fact to be directly related to signalling so that's confusing. > SIP dialog and session state is a very specific set of information described in RFC 3261. It relates to things like the route a message takes through the SIP network, certain endpoint identifiers, and whether the dialog itself is active or terminated. It is a very specific term of art that is generally known to SIP implementors. /a --------------090107090809010306030206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 4/20/10 04:18, Apr 20, Stephen Farrell wrote: 
Hi,

(Sorry for the tardy review;-)

This specification sort-of provides a SIP-based tunnel
for application protocols.

1: What prevents (or allows detection of) insertion of
bogus Info Package specifications? (e.g. by a proxy). If
nothing, then why is this ok?

This is the general way that SIP works, and it applies to all the SIP header fields. It's not great, but proxies are implicitly trusted to do the right thing. If it's a problem for INFO, then it's a problem for everything that has ever used or will ever use SIP.

2: I don't know how prevalent implementations of this are,
or will be, but since this calls for the user agents to
include a MIME parser plus parsers for whatever MIME types
the user agent claims to support, I'd say some guideance
about defensive programming (e.g. avoiding buffer overruns
etc.) should be given somewhere (maybe that's a more generic
SIP thing though).

I would think that's also a general comment about the way that SIP works. Such guidance would seem out of place squirreled away in a document that is otherwise simply defining a new method. In fact, I would argue that it should be attached to a MIME-related document, not a SIP-related one.

3. 4.2.2. says that a UA MUST indicate which Info packages it
supports.  That seems a bit open-kimono - why MUST all UAs tell
everyone everything they support all the time? Won't that
expose more attack surface than is wise? Wouldn't it be better
to first know who the other UA is, before telling them everything
every time? For example, imagine a UA supported the "US Govt
SECRET foobar application Info Package," I'm guessing that it
wouldn't be ok to just say that to every UA one meets on
the Internet.

I think that's a somewhat tortured reading of that text. The actual text is:

   A UA which supports the Info Package mechanism MUST indicate, using
   the Recv-Info header field, the set of Info Packages for which it is
   willing to receive INFO requests.

This leaves a lot of wiggle room around the difference between "supports" and "is willing to receive."

4. 10.10 says that if TLS is not good enough, then use S/MIME.
My understanding is that no UAs implement S/MIME (or CMS really)
and no networks support its use. So shouldn't that really say
"if TLS is not good enough, then just don't do it or require
the application to do its own security"? Same point applies to
section 13. I would think that securing specific applications
would be easier and more likely than getting S/MIME used in UAs,
so why not recommend that?

The difficulties with getting S/MIME deployed in SIP, I think, stem from the lack of a viable PKI. With the publication of draft-ietf-sip-certs-12 as an RFC -- which I anticipate happening soon -- I have renewed hope that S/MIME may se some deployment yet.

5. 1st para of section 13 says that this will be an improvement
over RFC2976. I would think a reference to the problems with
that RFC or to something detailing the expected improvement is
warranted.

So you want it to point back to section 9.2?

Non security notes:

s1, 2nd para: how can you prevent INFO being used to update the
state of a "SIP dialog or session"? Seems like it'd be more
accurate to say that that's the intent but that there really are
no guarantees. The example given in the abstract of RFC2976 seems
in fact to be directly related to signalling so that's confusing.

SIP dialog and session state is a very specific set of information described in RFC 3261. It relates to things like the route a message takes through the SIP network, certain endpoint identifiers, and whether the dialog itself is active or terminated. It is a very specific term of art that is generally known to SIP implementors.

/a
--------------090107090809010306030206-- From Sandra.Murphy@cobham.com Tue Apr 20 08:44:58 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A30A3A68AE; Tue, 20 Apr 2010 08:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvsyufaYIWBo; Tue, 20 Apr 2010 08:44:57 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 99ECD3A6ADA; Tue, 20 Apr 2010 08:44:57 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o3KFillg003552; Tue, 20 Apr 2010 10:44:47 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o3KFijCG009873; Tue, 20 Apr 2010 10:44:45 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.248.12]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Apr 2010 11:44:45 -0400 Date: Tue, 20 Apr 2010 11:44:44 -0400 (Eastern Daylight Time) From: Sandra Murphy To: "secdir@ietf.org" , "iesg@ietf.org" Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 20 Apr 2010 15:44:45.0543 (UTC) FILETIME=[66AC2F70:01CAE0A0] X-Mailman-Approved-At: Tue, 20 Apr 2010 09:05:20 -0700 Cc: draft-ietf-avt-register-srtp@tools.ietf.org, avt-chairs@tools.ietf.org Subject: [secdir] secdir review of draft-ietf-avt-register-srtp-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 15:44:58 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document resolves a conflict between IETF process and SRTP registration process, wrt country specific cryptographic transforms. The IETF process requires that such transforms be published as informational rfcs, but the SRTP documentation requires a standards track RFC for extensions to SRTP. This document modifies RFC3711 and RFC4568 to allow either informational RFCs or standards RFCs as the basis of registration in IANA's SRTP Cyrpto Suite Registrations. There are no security concerns that I can see that would result from this modification. (I have one idle question. If the crypto suites are only required to be informational, does that mean that the interoperability requirement for standards progress would not apply to the crypto transforms? I do not suggest that this is a problem that needs to be addressed.) --Sandy From Sandra.Murphy@cobham.com Tue Apr 20 08:58:33 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CD423A69DF for ; Tue, 20 Apr 2010 08:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNnJeMqthgwL for ; Tue, 20 Apr 2010 08:58:32 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 27D143A6B21 for ; Tue, 20 Apr 2010 08:58:32 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o3KFwMYW003864; Tue, 20 Apr 2010 10:58:22 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o3KFwKo3010713; Tue, 20 Apr 2010 10:58:22 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.248.12]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Apr 2010 11:58:21 -0400 Date: Tue, 20 Apr 2010 11:58:18 -0400 (Eastern Daylight Time) From: Sandra Murphy To: secdir@ietf.org, iesg@iesg.orm Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 20 Apr 2010 15:58:21.0126 (UTC) FILETIME=[4CCC4660:01CAE0A2] X-Mailman-Approved-At: Tue, 20 Apr 2010 09:05:20 -0700 Subject: [secdir] brief comment on draft-ietf-pce-pcep-p2mp-extensions-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 15:58:33 -0000 This draft caught my eye and I would have loved to investigate it fully. However, this is one of those drafts that requires a whole lot of advanced knowledge, and lacking that a whole lot of background reading. I was not able to do that. This is an extension ot the PCEP to provide for point-to-multipoint LSPs. Yep, multicast. PCEP is the Path Comuptation Element Protocol (the PCE computes LSPs on behalf of routers in an AS or inter-ASs). OSPF and IS-IS have been enhanced to help in the PCE discovery process (also in carrying around info for traffic engineered LSPs.). A complicated set of background: MPLS, PCEP, P2MP, OSPF, ISIS, RSVP, yada yada. (Excuses, excuses.) But I did notice one thing I wanted to comment on. PCEP requires use of TCP-MD5 with recognition of its failings, specifically mentioning that TCP-AO was not yet complete. This document refers to the PCEP security analysis. But as TCP-AO has now passed the IESG, should there be some recognition of that change? This doc does not seem the proper place to change the PCEP recommendation, but a change in the MUST requirement in PCEP (RFC5440) seems to be something to consider somehow. I expect that's a AD level discussion between the security ADs and the routing ADs. --Sandy From scott@hyperthought.com Tue Apr 20 11:03:16 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 393843A6AE0 for ; Tue, 20 Apr 2010 11:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1YKDYyIZ3IN for ; Tue, 20 Apr 2010 11:03:16 -0700 (PDT) Received: from smtp122.iad.emailsrvr.com (smtp122.iad.emailsrvr.com [207.97.245.122]) by core3.amsl.com (Postfix) with ESMTP id 990033A6B36 for ; Tue, 20 Apr 2010 11:03:09 -0700 (PDT) Received: from relay32.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay32.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 5FFD11B4130; Tue, 20 Apr 2010 14:03:00 -0400 (EDT) Received: from dynamic12.wm-web.iad.mlsrvr.com (dynamic12.wm-web.iad.mlsrvr.com [192.168.2.219]) by relay32.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 53BC11B4119; Tue, 20 Apr 2010 14:03:00 -0400 (EDT) Received: from hyperthought.com (localhost [127.0.0.1]) by dynamic12.wm-web.iad.mlsrvr.com (Postfix) with ESMTP id 43B43216807E; Tue, 20 Apr 2010 14:03:00 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Tue, 20 Apr 2010 11:03:00 -0700 (PDT) Date: Tue, 20 Apr 2010 11:03:00 -0700 (PDT) From: scott@hyperthought.com To: secdir@ietf.org, "iesg@ietf.org" , draft-turner-asymmetrickeyformat-algs@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain Message-ID: <1271786580.275918665@192.168.2.231> X-Mailer: webmail7.0 Subject: [secdir] secdir review of draft-turner-asymmetrickeyformat-algs-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 18:03:16 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These 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.=0A=0AThis document describes conventions for cry= pto algorithms for use with a companion document (http://tools.ietf.org/htm= l/draft-turner-asymmetrickeyformat-03) which is intended to replace rfc5208= . =0A=0AI couldn't give this review the amount of time I would have liked t= o, but I hope my comments are useful nonetheless.=0A=0AIn section 2, it say= s that the de facto standard for PrivateKeyInfo encryption is Password Base= d Encryption using either PKCS5 or PKCS12, and that the major difference be= tween these is the password encoding. I was surprised that no mention was m= ade of the more robust crypto algorithms supported by PKCS12, which seems l= ike an important consideration for this application.=0A=0AAlso, I was confu= sed as to whether the draft is mixing the documentation of current practice= s with some recommendations, or whether it intends to specify a required us= age profile. If the latter, it seems reasonable to ask why deprecated algor= ithms are included. If the former, maybe the document could do a better job= of making this intention clear, and of demarcating which is which.=0A=0ATh= e only other nit I had was that no mention is made of the implications of w= rapping various asymmetric key sizes with potentially weaker symmetric keys= /algorithms, but the security considerations section references a mighty li= st of related RFCs, at least one of which discusses this (RFC5649), so mayb= e that is good enough.=0A=0A--Scott=0A From dwing@cisco.com Tue Apr 20 12:13:28 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C002F3A6BB3; Tue, 20 Apr 2010 12:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.138 X-Spam-Level: X-Spam-Status: No, score=-10.138 tagged_above=-999 required=5 tests=[AWL=0.461, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3VvKxz2pohI; Tue, 20 Apr 2010 12:13:27 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id A605F3A68F6; Tue, 20 Apr 2010 12:13:27 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsHANaZzUurR7H+/2dsb2JhbACHWoEUkxlxolGaSIUPBIM0HQ X-IronPort-AV: E=Sophos;i="4.52,244,1270425600"; d="scan'208";a="118102645" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 20 Apr 2010 19:13:18 +0000 Received: from dwingwxp01 (dhcp-128-107-109-1.cisco.com [128.107.109.1]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3KJDIfS000522; Tue, 20 Apr 2010 19:13:18 GMT From: "Dan Wing" To: "'Sandra Murphy'" , , References: Date: Tue, 20 Apr 2010 12:13:19 -0700 Message-ID: <02f801cae0bd$897075d0$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcrgoHlsVNnbn8mpQMOjMblSdXcWgQAHOLeQ X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: Cc: draft-ietf-avt-register-srtp@tools.ietf.org, avt-chairs@tools.ietf.org Subject: Re: [secdir] secdir review of draft-ietf-avt-register-srtp-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 19:13:29 -0000 > -----Original Message----- > From: Sandra Murphy [mailto:sandra.murphy@sparta.com] > Sent: Tuesday, April 20, 2010 8:45 AM > To: secdir@ietf.org; iesg@ietf.org > Cc: avt-chairs@tools.ietf.org; > draft-ietf-avt-register-srtp@tools.ietf.org > Subject: secdir review of draft-ietf-avt-register-srtp-01 > > > 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 resolves a conflict between IETF process and SRTP > registration process, wrt country specific cryptographic > transforms. The > IETF process requires that such transforms be published as > informational > rfcs, but the SRTP documentation requires a standards track RFC for > extensions to SRTP. > > This document modifies RFC3711 and RFC4568 to allow either > informational > RFCs or standards RFCs as the basis of registration in IANA's > SRTP Cyrpto > Suite Registrations. > > There are no security concerns that I can see that would > result from this modification. Thanks for your review. > (I have one idle question. If the crypto suites are only > required to be > informational, does that mean that the interoperability > requirement for > standards progress would not apply to the crypto transforms? > I do not > suggest that this is a problem that needs to be addressed.) There are mandatory-to-implement standards track SRTP crypto suites [RFC3711], which would progress through the standards process. It is true that the informational SRTP crypto suites would not be progressed. -d > --Sandy > From mundy@sparta.com Tue Apr 20 22:51:50 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AE503A6A30; Tue, 20 Apr 2010 22:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IXwkn8t5h5m; Tue, 20 Apr 2010 22:51:49 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 8248B3A6A04; Tue, 20 Apr 2010 22:51:45 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o3L5pZwV013289; Wed, 21 Apr 2010 00:51:35 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o3L5pWLk005845; Wed, 21 Apr 2010 00:51:32 -0500 Received: from calvin.home.tislabs.com ([69.250.64.147]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Apr 2010 01:51:32 -0400 Received: from calvin.home.tislabs.com (localhost [127.0.0.1]) by calvin.home.tislabs.com (Postfix) with ESMTP id 4DBE72221C43; Wed, 21 Apr 2010 01:51:11 -0400 (EDT) Message-ID: <4BCE924F.8000003@sparta.com> Date: Wed, 21 Apr 2010 01:51:11 -0400 From: Russ Mundy User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 SeaMonkey/2.0.4 MIME-Version: 1.0 To: ietf@ietf.org, secdir@ietf.org, draft-ietf-pce-pcep-p2mp-extensions.txt.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Apr 2010 05:51:32.0447 (UTC) FILETIME=[B1F27EF0:01CAE116] Cc: Russ Mundy Subject: [secdir] Review of draft-ietf-pce-pcep-p2mp-extensions-10.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 05:51: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 presented an interesting challenge for a security review in that it is building on several other referenced RFCs [1] each of which has it's own set of references and security consideration section. Also, the .10 version of the ID was posted on the 19 Apr and the security ADs recently posted some comments for discussion. I have not previously had the opportunity (or need) to examine the fairly large set of documents that this ID builds upon and could be missing (or mis-understanding) some important aspects. I tried to do the review as someone that wanted to "do the right security thing" for implementing or deploying this capability. Given these caveats, following are my comments on the document: - Resolution of Tim's 'Discuss (2010-04-19)' comment should provide additional information in this document. However, it's not clear to me that the security considerations section of this document and RFC5440 and RFC5671 (individually or jointly) provide what the PCE Architecture document [RFC4655] says will be expected for each PCE solution. -- Although the need for Applicability statements to detail security related issues and techniques is stated in 4655, the word 'Applicability' is not in 5440 and is only in the title and abstract of 5671. The 5671 applicability examination is related to "the applicability of PCE to path computation for P2MP TE LSPs in MPLS and GMPLS networks." but does not provide security related applicability specifics as expected in 4655. --- Although this may seem like "spec legalism", I think this lack of specification will likely have direct impacts on implementations and will result in the lack of interoperability between implementations (except for TCP-AO (or TCP-MD5)). --- This may be my lack of background in this area but 4655 has a number of statements that there are different security concerns when the PCE architecture is used in an intra-domain case vs an inter-domain (or multi-domain) cases. I was not able to find enough guidance in this document (or 5440 or 5671) that would identify what information elements would be more (or less?) sensitive in inter-domain or multi-domain use cases. Neither was there any useful guidance on what different security techniques should be applied in these different cases/environments. ---- This is further complicated in that RFC5440 enumerates several security vulnerabilities but only identifies TCP-MD5 as a MUST be implemented. Other security techniques are described but it's unclear when (or if) these should be used. Without any other MUST implement requirements or use case recommendations, it's unclear whether or not any of the other mechanisms will be implemented. --- RFC4875 Security Considerations requires that the ingress LSR of a P2MP TE LSP the leaves for the P2MP LSP for use in multi-vendor deployments. Although it's not clear that this document needs to provide this requirement, I wanted to flag the requirement in case that it had been overlooked. Russ [1] nice technology list by Sandy Murphy in an earlier email to the secdir & iesg lists From karagian@cs.utwente.nl Wed Apr 21 01:24:43 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DE5B3A6976; Wed, 21 Apr 2010 01:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.096 X-Spam-Level: ** X-Spam-Status: No, score=2.096 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyqVzZ8GD-Xo; Wed, 21 Apr 2010 01:24:42 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id 1A3AF3A68F5; Wed, 21 Apr 2010 01:24:41 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id o3L8NTEa012934; Wed, 21 Apr 2010 10:23:40 +0200 (MEST) From: "Georgios Karagiannis" To: "'Brian Weis'" , , References: <4CCE7D8C-DECC-479D-89F6-FCA316050ADC@cisco.com> Date: Wed, 21 Apr 2010 10:23:36 +0200 Message-ID: <000301cae12b$f796f7f0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4CCE7D8C-DECC-479D-89F6-FCA316050ADC@cisco.com> Thread-Index: Acrfi1700whOF+HqQA66edw2yq4qCQBoA7Mg X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 21 Apr 2010 10:23:48 +0200 (MEST) X-Mailman-Approved-At: Wed, 21 Apr 2010 07:09:51 -0700 Cc: draft-ietf-nsis-rmd@tools.ietf.org, nsis-chairs@tools.ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-nsis-rmd-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 08:24:43 -0000 Dear Brian Thank you very much for reviewing and sending us the very useful comments! We will work out the comments, but due to some problems that some of the co-authors have associated with the traveling situation in Europe we will need some more days to fulfill this activity. Best regards, Georgios > -----Original Message----- > From: Brian Weis [mailto:bew@cisco.com] > Sent: maandag 19 april 2010 8:15 > To: secdir@ietf.org; iesg@ietf.org > Cc: nsis-chairs@tools.ietf.org; draft-ietf-nsis-rmd@tools.ietf.org > Subject: Secdir review of draft-ietf-nsis-rmd-19 > > 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 NSIS QoS Model for networks that > use the Resource Management in Diffserv (RMD) concept. It > describes RMD-QOSM, which are new payloads sent using the > GISP signaling mechanism, where the new payloads request or > reserve resources. A number of data flows are discussed, > depending on whether nodes within a network boundary > participate in the protocol or not. > > The Security Considerations section covers the following topics: > - Byzantine adversaries (i.e., participants taken over by an > adversary) are a general problem, but this section intends to > discuss additional threats as a result of the new protocol. > There is an extensive discussion of on-path and off-path > adversaries, which seems to intend to be addressing Byzantine > adversaries. > - RMD-QOSM is claimed to be lightweight, with different > routers allowed certain operations dependant on the role a > router plays in the system. E.g., only Ingress/Egress nodes > are allowed to initiate certain signaling messages. > - RMD-QOSM "relies on the security support that is provided > by the bounded end-to-end session, which is running between > the boundaries of the RMD domain", but doesn't mandate that > security support. > > The existing text is helpful, but not sufficient. The > following points are suggestions to improve this section. > > 1. The statement at the beginning of Security Considerations > discusses adversaries taking over a router, but the new > threats are not very clear. Are the authors considering that > security associations are revealed, that reservation data > routed to a particular router can be changed or forged, or > something else? > > 2. The trust model used by RMD-QOSM is hinted at in the > discussion of on-path and off-path adversaries, but a > discussion of exactly what devices are trusted and what > they're trusted to do would be helpful. > For example, is every interior router in the network is > trusted to handle any particular RESERVE or RESERVE` message? > If not, then how are the paths setup so that only authorized > routers will see a particular message? On the other hand, if > routing is used to route the messages then it would seem that > any router must be authorized to handle messages happened to > be routed to them -- but then it isn't clear that there can > be a difference between an "on-path" and "off- path" adversary. > > 3. Another dimension of trust model is the fact that > ingress/egress routers seem to trust each other more than > they trust interior nodes. > This seems evidenced by the fact that RESERVE messages > (Figure 24) don't seem to be intended to be modified by the > interior routers. In the case of probes, I would expect that > this would be especially important, but probes do not seem to > be specifically discussed in this section. > > 4. There don't seem to be any actual security requirements or > recommendations made on GIST messaging. As such, it isn't > clear that attackers that have not taken over a participant > (i.e., a man in the > middle) are in any way foiled. I would expect to see more MUSTs and > SHOULDs in this section regarding message security. There > are statements in the I-D such as "In the situation a > security association exists" and "If we assume that the > RESERVE/RESPONSE is sent with hop- by-hop channel security". > There should be some description of the threats to the > messaging by a non-participant, and stating what available > mechanisms MUST or SHOULD be used. > > 5. Since roles seem to be an important part of the security > considerations, it would be helpful to see discussion of the > different threats & requirements on the ingress/egress > routers and the internal routers in their different roles. > > 6. An important service of RMD-QOSM is admission control, but > there doesn't seem to be any discussion of how the ingress > routers determine whether or not reservation requests given > to them are valid. I would have thought that is of particular > importance, but if it's considered out of scope this section > might mention that fact. > > Hope that helps, > Brian > From alexey.melnikov@isode.com Wed Apr 21 07:29:09 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 637FD28C142; Wed, 21 Apr 2010 07:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NILrGq+UlP1D; Wed, 21 Apr 2010 07:29:08 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 0730C28C192; Wed, 21 Apr 2010 06:59:07 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 21 Apr 2010 14:58:57 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4BCF04A0.1000905@isode.com> Date: Wed, 21 Apr 2010 14:58:56 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Tero Kivinen References: <19396.29206.787824.69029@fireball.kivinen.iki.fi> In-Reply-To: <19396.29206.787824.69029@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Cyrus Daboo , Ned Freed , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-freed-sieve-notary-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 14:29:09 -0000 Hi Tero, Thank you for the review. In this message I am responding to the second part of your comments: Tero Kivinen wrote: >Also in section 5, it should be made clear that the "bytime" can also >be negative, if the bymode is "notify" and the message is already >pasts is notification time. > > Agreed. >Section 5 also says that the "bytime" is "the initial integer part of >the delive-by extension", but then comments that deliver-by by-time is >decremented as message passes through the transport infrastructure. >This does not make it clear whether the sieve filtering system should >also decrement the number while message is waiting to be processed. >I.e. if message was received earlier, but it took some time before the >sieve email filter could be run on the message, should the "bytime" be >the original time from the smtp MAIL FROM BY= part, or whether it is >decremented. > > I don't think it makes sense to decrement the by-time once the message is in the final delivery agent. Otherwise it might be hard to debug Sieve scripts making use of this extension. >Also the example in 5.1 is wrong, as it is only true if the sieve >filter is run exactly when the deliver-by expired. > Good point. >It should compare >whether the "bytime" is <= 0, not whether it is equal to 0 (note, that >if tye bymode is "return" then the "bytime" never should reach 0, as >at that point mail is returned to the sender. > Yes. I would also note that the i;ascii-numeric comparator doesn't work with negative numbers. >In section 7 it should be made clear that ":bytime" parameter "number>" can be negative too, but it seems that RFC 5228 specifies >that numbers can only be non-negative so I am not sure whether the >usage is correct or not. > I concur, this is a bug. From kivinen@iki.fi Wed Apr 21 08:12:04 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A87328C3D7; Wed, 21 Apr 2010 08:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQEu-xrR2gPE; Wed, 21 Apr 2010 08:12:02 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id B5D1A28C43C; Wed, 21 Apr 2010 07:50:00 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o3LEnehP022198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Apr 2010 17:49:40 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o3LEneQI001446; Wed, 21 Apr 2010 17:49:40 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19407.4228.54234.610657@fireball.kivinen.iki.fi> Date: Wed, 21 Apr 2010 17:49:40 +0300 From: Tero Kivinen To: Alexey Melnikov In-Reply-To: <4BCF04A0.1000905@isode.com> References: <19396.29206.787824.69029@fireball.kivinen.iki.fi> <4BCF04A0.1000905@isode.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 5 min Cc: Cyrus Daboo , Ned Freed , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-freed-sieve-notary-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 15:12:04 -0000 Alexey Melnikov writes: > >Section 5 also says that the "bytime" is "the initial integer part of > >the delive-by extension", but then comments that deliver-by by-time is > >decremented as message passes through the transport infrastructure. > >This does not make it clear whether the sieve filtering system should > >also decrement the number while message is waiting to be processed. > >I.e. if message was received earlier, but it took some time before the > >sieve email filter could be run on the message, should the "bytime" be > >the original time from the smtp MAIL FROM BY= part, or whether it is > >decremented. > > > I don't think it makes sense to decrement the by-time once the message > is in the final delivery agent. Otherwise it might be hard to debug > Sieve scripts making use of this extension. What about if email is redirected again, then should the delay caused by the Sieve script be taken into account? I do not know whether the Sieve scripts are always run immediately when the email comes in, or whether it is possible to queue the messages during peak hours, and then run them through the Sieve scripts later when the load peak causing servers to be overloaded is over. In that case it might be useful to decrement the by-time, just in case the message was something that deliver this if it can be delivered before the 17:00, but after that return it back to the sender, so he will know that he needs to call the user, as he knows the user does not read his emails after that hour (which was one reason for by-time). > >Also the example in 5.1 is wrong, as it is only true if the sieve > >filter is run exactly when the deliver-by expired. > > > Good point. > > >It should compare > >whether the "bytime" is <= 0, not whether it is equal to 0 (note, that > >if tye bymode is "return" then the "bytime" never should reach 0, as > >at that point mail is returned to the sender. > > > Yes. > I would also note that the i;ascii-numeric comparator doesn't work with > negative numbers. Then you might want to express negative (i.e expired by-time) as setting by-time to zero, but this should be mentioned in the draft. Other option would be to use strings, I am not sure which one would better fit to Sieve architecture. > >In section 7 it should be made clear that ":bytime" parameter " >number>" can be negative too, but it seems that RFC 5228 specifies > >that numbers can only be non-negative so I am not sure whether the > >usage is correct or not. > > > I concur, this is a bug. -- kivinen@iki.fi From alexey.melnikov@isode.com Wed Apr 21 09:33:37 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41F9728C4AD; Wed, 21 Apr 2010 09:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.404 X-Spam-Level: X-Spam-Status: No, score=-2.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmMrvooW5XUi; Wed, 21 Apr 2010 09:33:36 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id C19C73A6D25; Wed, 21 Apr 2010 09:05:44 -0700 (PDT) Received: from [172.16.2.144] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 21 Apr 2010 17:05:34 +0100 Message-ID: <4BCF2247.5040107@isode.com> Date: Wed, 21 Apr 2010 17:05:27 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Tero Kivinen References: <19396.29206.787824.69029@fireball.kivinen.iki.fi> In-Reply-To: <19396.29206.787824.69029@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Cyrus Daboo , Ned Freed , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-freed-sieve-notary-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 16:33:37 -0000 Hi Tero, Tero Kivinen wrote: >I have reviewed this document as part of the security directorate's >ongoing effort to review all IETF documents being processed by the >IESG. These comments were written primarily for the benefit of the >security area directors. Document editors and WG chairs should treat >these comments just like any other last call comments. > >This draft provides two things. Firstly it will provide ability for >sieve email filtering program to see the delivery status notification >and deliver by information from the envelope. Secondly it allows >setting those same parameters when using sieve redirect action. > >The first part does not have security issues, but the second might >have, as it causes delivery notify emails to be sent which were not >originally requested by the original author. > >This can cause problems for the original sender, as he is now getting >the deliver status notifications which he has not requested. The draft >does not explictly specify, but I do assume that the sieve redirect >keeps the original sender intact, so the deliver status notification >messages are sent to the original author, not to the user doing the >redirect. > > The answer to your question is "it depends on an implementation". The redirect action is defined in section 4.2 of RFC 5228, which says: The envelope sender address on the outgoing message is chosen by the sieve implementation. It MAY be copied from the message being processed. However, if the message being processed has an empty envelope sender address the outgoing message MUST also have an empty envelope sender address. This last requirement is imposed to prevent loops in the case where a message is redirected to an invalid address when then returns a delivery status notification that also ends up being redirected to the same invalid address. >The number of delivery status notifications can be quite large, >especially if the ":bytrace" option of the redirect is used, as then >every single future step for email processing, will send "relayed" >status notification, and if there is for example mail loop or similar, >this can be several dozen of status notifications. > Can you clarify what do you mean by "every single future step for email processing"? My recollection is that for any given SMTP path from a sender to a recipient only a single "relay" DSN can be generated. >This should most likely be mentioned in the security considerations >section more clearly. The security considerations section do warn >about generating status notification, and says that > > "Sites which limit the ability to request success notifications will > also need to restrict the ability to request them using the > redirect-dsn extension." > >but that does not help at all, as if the original senders site limits >the ability to request notifications, the host running sieve email >filter of the receiver might not have such restrictions, thus receiver >can enable them even when they were forbidden from the sender. > > From alexey.melnikov@isode.com Wed Apr 21 09:42:04 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27E9C3A6C83; Wed, 21 Apr 2010 09:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8r2rrJkykVi; Wed, 21 Apr 2010 09:42:03 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 35A8D28C2DB; Wed, 21 Apr 2010 09:14:34 -0700 (PDT) Received: from [172.16.2.144] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 21 Apr 2010 17:14:24 +0100 Message-ID: <4BCF2459.9070603@isode.com> Date: Wed, 21 Apr 2010 17:14:17 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Tero Kivinen References: <19396.29206.787824.69029@fireball.kivinen.iki.fi> <4BCF04A0.1000905@isode.com> <19407.4228.54234.610657@fireball.kivinen.iki.fi> In-Reply-To: <19407.4228.54234.610657@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Cyrus Daboo , Ned Freed , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-freed-sieve-notary-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 16:42:04 -0000 Hi Tero, Tero Kivinen wrote: >Alexey Melnikov writes: > > >>>Section 5 also says that the "bytime" is "the initial integer part of >>>the delive-by extension", but then comments that deliver-by by-time is >>>decremented as message passes through the transport infrastructure. >>>This does not make it clear whether the sieve filtering system should >>>also decrement the number while message is waiting to be processed. >>>I.e. if message was received earlier, but it took some time before the >>>sieve email filter could be run on the message, should the "bytime" be >>>the original time from the smtp MAIL FROM BY= part, or whether it is >>>decremented. >>> >>> >>> >>I don't think it makes sense to decrement the by-time once the message >>is in the final delivery agent. Otherwise it might be hard to debug >>Sieve scripts making use of this extension. >> >> > >What about if email is redirected again, then should the delay caused >by the Sieve script be taken into account? > > Yes, it might make sense to do that for redirect-deliverby. (I was thinking about envelope-deliverby when I answered your question.) >I do not know whether the Sieve scripts are always run immediately >when the email comes in, or whether it is possible to queue the >messages during peak hours, and then run them through the Sieve >scripts later when the load peak causing servers to be overloaded is >over. In that case it might be useful to decrement the by-time, just >in case the message was something that deliver this if it can be >delivered before the 17:00, but after that return it back to the >sender, so he will know that he needs to call the user, as he knows >the user does not read his emails after that hour (which was one >reason for by-time). > > I don't know of implementations that do the latter (off-peak processing), but this is certainly allowed. I.e. this is an implementation detail. So yes, maybe it is worth discussing this in more details even for envelope-deliverby. >>>Also the example in 5.1 is wrong, as it is only true if the sieve >>>filter is run exactly when the deliver-by expired. >>> >>> >>Good point. >> >> >>>It should compare >>>whether the "bytime" is <= 0, not whether it is equal to 0 (note, that >>>if tye bymode is "return" then the "bytime" never should reach 0, as >>>at that point mail is returned to the sender. >>> >>> >>Yes. >>I would also note that the i;ascii-numeric comparator doesn't work with >>negative numbers. >> >> > >Then you might want to express negative (i.e expired by-time) as >setting by-time to zero, but this should be mentioned in the draft. > > I thought about that as well. I agree. I will wait for the author to suggest a fix to this. >Other option would be to use strings, I am not sure which one would >better fit to Sieve architecture. > > Co-incidently I suggested that to the author during my AD review :-). >>>In section 7 it should be made clear that ":bytime" parameter ">>number>" can be negative too, but it seems that RFC 5228 specifies >>>that numbers can only be non-negative so I am not sure whether the >>>usage is correct or not. >>> >>> >>I concur, this is a bug. >> >> From ned.freed@mrochek.com Wed Apr 21 10:27:55 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC0BF3A69E8; Wed, 21 Apr 2010 10:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.103 X-Spam-Level: X-Spam-Status: No, score=0.103 tagged_above=-999 required=5 tests=[AWL=-1.588, BAYES_50=0.001, DATE_IN_PAST_96_XX=1.69] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uLfr3dwWbfu; Wed, 21 Apr 2010 10:27:54 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 6E8DA3A6C7B; Wed, 21 Apr 2010 10:15:02 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NM7KYWFEWW00KI10@mauve.mrochek.com>; Wed, 21 Apr 2010 10:14:49 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NM0NO8AQM80000BI@mauve.mrochek.com>; Wed, 21 Apr 2010 10:14:40 -0700 (PDT) Message-id: <01NM7KYS0I420000BI@mauve.mrochek.com> Date: Fri, 16 Apr 2010 13:04:57 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 13 Apr 2010 16:31:02 +0300" <19396.29206.787824.69029@fireball.kivinen.iki.fi> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <19396.29206.787824.69029@fireball.kivinen.iki.fi> To: Tero Kivinen DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1271869716; bh=t/jFaMZ4oEgEYb8e9PWjU5WUxdJ/3COKd3SronfVGJA=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=fTZSNtK9U6GtLqYCuWG+1466Zsr8W65UAF+AwdFjQPqNOBqKFqfFpT+wPtU7rknNM CkIx/XMnlHv17ZKnORGCAmMiT//VFk5o3ngJ8jNe2dKFB5OI3iBapVO2HKD0fNwDEY XSNArsiIo0oem2sSUjbSGLSo1rpLwJe2r1lVKKhA= X-Mailman-Approved-At: Wed, 21 Apr 2010 10:30:03 -0700 Cc: draft-freed-sieve-notary.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-freed-sieve-notary-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 17:27:55 -0000 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > This draft provides two things. Firstly it will provide ability for > sieve email filtering program to see the delivery status notification > and deliver by information from the envelope. Secondly it allows > setting those same parameters when using sieve redirect action. > The first part does not have security issues, but the second might > have, as it causes delivery notify emails to be sent which were not > originally requested by the original author. THis really isn't the issue, or more precisely, if this is an issue warranting such great concern this isn't the place to address it. All this extension does is give a user access to existing site capabilities through Sieve. If those capabilities are available, a user can use or abuse them directly far more easily than they can through Sieve. The only scenario where this presents an added exposure is one where these capabilities can be accessed through Sieve but not through regular submission or SMTP. If such a setup were created, it would be a fairly wierd thing - so wierd I really cannot see much point in worrying about it. But even so, this particular case is specifically dealt with by the current security considerations. > This can cause problems for the original sender, as he is now getting > the deliver status notifications which he has not requested. The draft > does not explictly specify, but I do assume that the sieve redirect > keeps the original sender intact, Sieve redirect is defined in RFC 5228 and it doesn't specify whether the original address is used or the address of the Sieve owner. (What it does say is that if the original message had an empty envelope from, any redirected message must also have an empty envelope from. This prevents certain especially pernicious loops from forming, but I don't see it as relevant to this discussion.) Considering redirect behavior further, it does raise an issue that needs to be addressed in this document, but it's a usability issue, not a security issue. Specifically, what does it mean to add a DSN request or activate deliverby when you don't know where these notifications are going to go? This ruins the usability of both redirect-dsn and redirect-deliverby. I therefore propose adding the following text to redirect-dsn and similar text to redirect-deliverby: RFC 5228 does not require any particular envelope sender address be associated with redirected messages. However, the redirect-dsn extension isn't terribly useful if the place where the delivery status notifications are sent isn't known. Accordingly, when either :notify or :ret is specified and the envelope sender address isn't empty, implementations MUST set the envelope sender address to the address of the sieve owner. > so the deliver status notification > messages are sent to the original author, not to the user doing the > redirect. That's one possible behavior, but if someone wants to create intentional backscatter, it is far simpler to just connect to the submit port and say: MAIL FROM: RCPT TO: NOTIFY=SUCCESS,FAILURES DATA blah blah . > The number of delivery status notifications can be quite large, > especially if the ":bytrace" option of the redirect is used, as then > every single future step for email processing, will send "relayed" > status notification, and if there is for example mail loop or similar, > this can be several dozen of status notifications. The same arguments hold for DELIVERBY. If the extension is available, why not just (ab)use it directly? Why bother with a convoluted path through Sieve that will almost certainly leave a much bigger trail? > This should most likely be mentioned in the security considerations > section more clearly. The security considerations section do warn > about generating status notification, and says that > "Sites which limit the ability to request success notifications will > also need to restrict the ability to request them using the > redirect-dsn extension." > but that does not help at all, as if the original senders site limits > the ability to request notifications, the host running sieve email > filter of the receiver might not have such restrictions, thus receiver > can enable them even when they were forbidden from the sender. You're missing the point. If the site restricts notification requests in some way, e.g, you can only request a success notification if the envelope from is local, then that restriction also needs to apply to redirect-dsn and redirect-deliveryby, because if it doesn't you've left a hole someone could exploit. But if there is no such restriction, then it simply doesn't matter what we do in Sieve, because nobody is going to bother using Sieve when direct usage is simpler, easier and less likely to be detected. > Also in section 5, it should be made clear that the "bytime" can also > be negative, if the bymode is "notify" and the message is already > pasts is notification time. Unfortunately, RFC 2852 predates the current thinking in email that there's significant semantic difference between submission and relay. My understanding of the purpose of negative by-times is that they are arrived at when a message exceeds the time limit but still needs to be delivered. If there's a justification for having a negative by-time on initial submission I haven't heard it. In fact had RFC 2852 distinguished between submit and relay I suspect it would have disallowed negative by-times in the submit case. And since the use of this extension effectively means the message is being resubmitted, I don't see any reason to allow negative by-times to be specified. I do not feel strongly about this, however, so if others feel this should be allowed I'll be happy to change it. (The other argument, and in my view more reasonable, argument in favor of the change is that this would mean the parameter would have to be a string rather than an counting number, and that would allow variables to be used.) > Section 5 also says that the "bytime" is "the initial integer part of > the delive-by extension", but then comments that deliver-by by-time is > decremented as message passes through the transport infrastructure. > This does not make it clear whether the sieve filtering system should > also decrement the number while message is waiting to be processed. > I.e. if message was received earlier, but it took some time before the > sieve email filter could be run on the message, should the "bytime" be > the original time from the smtp MAIL FROM BY= part, or whether it is > decremented. I first have to say that if the timing is so critical that this sort of thing really matters, you're pretty much sunk before you start. For better or worse the DELIVERBY extension only applies while mail is in transit, and there's an increasing amount of stuff that happens outside of this context (e.g., downloads from a POP3/IMAP4 server) that cannot be traced or "timed out"). And again, if this really bothers you, this draft is not the place to address the issue. Be that as it may, I actualy the the draft is pretty clear on this point. It says: When these arguments are specified, they are used to construct the corresponding BY ESMTP MAIL FROM parameter. The :bytime value becomes the by-time, the :bymode becomes the by-mode value, and :bytrace sets the by-trace modifier. I think this makes it clear the values are simply passed unchanged to the SMTP/submit server. But if you want to suggest a specific change, that's fine. > Also the example in 5.1 is wrong, as it is only true if the sieve > filter is run exactly when the deliver-by expired. It should compare > whether the "bytime" is <= 0, not whether it is equal to 0 (note, that > if tye bymode is "return" then the "bytime" never should reach 0, as > at that point mail is returned to the sender. Yep, this is broken, and moreover the fix isn't that simple because the i;ascii-numeric comparator only handles unsigned values. I've updated the text to address this issue. > In section 7 it should be made clear that ":bytime" parameter " number>" can be negative too, but it seems that RFC 5228 specifies > that numbers can only be non-negative so I am not sure whether the > usage is correct or not. That's only true if we decide to allow specification of negative values. However, I did add a note saying that negative values cannot be specified. Thanks for the comments - very useful. I'll post a revision once there's agreement on the envelope sender text and whether or not to change :bytime. Ned From kivinen@iki.fi Thu Apr 22 02:14:15 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A4BC3A6A51; Thu, 22 Apr 2010 02:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.02 X-Spam-Level: X-Spam-Status: No, score=-1.02 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7eonpC-hu-V; Thu, 22 Apr 2010 02:14:05 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 8A05F3A6A24; Thu, 22 Apr 2010 02:14:02 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o3M9DiUF020564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Apr 2010 12:13:44 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o3M9DgIW024619; Thu, 22 Apr 2010 12:13:42 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19408.4934.51757.287355@fireball.kivinen.iki.fi> Date: Thu, 22 Apr 2010 12:13:42 +0300 From: Tero Kivinen To: Alexey Melnikov In-Reply-To: <4BCF2247.5040107@isode.com> References: <19396.29206.787824.69029@fireball.kivinen.iki.fi> <4BCF2247.5040107@isode.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 14 min X-Total-Time: 15 min Cc: Cyrus Daboo , Ned Freed , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-freed-sieve-notary-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 09:14:15 -0000 Alexey Melnikov writes: > The answer to your question is "it depends on an implementation". The > redirect action is defined in section 4.2 of RFC 5228, which says: > > The envelope sender address on the outgoing message is chosen by the > sieve implementation. It MAY be copied from the message being > processed. However, if the message being processed has an empty > envelope sender address the outgoing message MUST also have an empty > envelope sender address. This last requirement is imposed to prevent > loops in the case where a message is redirected to an invalid address > when then returns a delivery status notification that also ends up > being redirected to the same invalid address. Ok. Then it might be good idea to mention this also in this document, as it affects where the status notifications are going to, i.e. if user decides he wants to request status notifications, he does not know whether it goes to the original author or to his own address. > >The number of delivery status notifications can be quite large, > >especially if the ":bytrace" option of the redirect is used, as then > >every single future step for email processing, will send "relayed" > >status notification, and if there is for example mail loop or similar, > >this can be several dozen of status notifications. > > > Can you clarify what do you mean by "every single future step for email > processing"? > > My recollection is that for any given SMTP path from a sender to a > recipient only a single "relay" DSN can be generated. No. If I send email from my home machine to kivinen@iki.fi address, and use the trace option of DELIVERYBY feature I will get one status notification when my local machine takes email in and relays it to iki.fi mail server. Then I get another status notification when the iki.fi email-server gets message in and forwards it to iki.fi-spam filter (this setting is per user setting and the spam processing is done on the other machine). Then I get next one when the spam filter machine is done running the spamassasin and forwards that email to my real end delivery address (which in my case happens to be my home machine kivinen.iki.fi). Then when my home machine gets the email again now with envelope receiver of kivinen@kivinen.iki.fi (as rewritten by the iki.fi machines) it will send me the fourth trace message. So every single machine which relays the email sends the status notification saying the email was relayed. Now when I noticed there is such feature, I have found it quite useful when debugging email problems. I am one of the maintainers of the iki.fi, which provides permanent email forwarding services, and quite often our members complain that their emails does not get through, and now I have easy way of sending one email with trace option and I can see from DSNs that the email goes through iki.fi machines without delays and problems, and that the email was delivered to the members next step machine (which usually does not enable DELIVERYBY so I do not get any further reports). So if someone enables trace option in the middle and then redirects the email to forward then there might be several of those relayed status notifications sent to either to the original author or to the one running the sieve (depending which envelope sender the sieve implementation used). > >This should most likely be mentioned in the security considerations > >section more clearly. The security considerations section do warn > >about generating status notification, and says that > > > > "Sites which limit the ability to request success notifications will > > also need to restrict the ability to request them using the > > redirect-dsn extension." > > > >but that does not help at all, as if the original senders site limits > >the ability to request notifications, the host running sieve email > >filter of the receiver might not have such restrictions, thus receiver > >can enable them even when they were forbidden from the sender. Ok, now this also makes bit more sense, as if the sieve implmentation decides to rewrite the envelope sender then this restriction is appropriate, but if it does not rewrite the envelope sender, then it does not help, as the machine running sieve might not know the policy required by the original senders machine, i.e. whether the original sender was allowed to request those status notifications or not. -- kivinen@iki.fi From kivinen@iki.fi Thu Apr 22 03:51:24 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0036C3A6809; Thu, 22 Apr 2010 03:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.808 X-Spam-Level: X-Spam-Status: No, score=-0.808 tagged_above=-999 required=5 tests=[AWL=-0.809, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNJ5YJLD-lHk; Thu, 22 Apr 2010 03:51:22 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id E684A3A67DB; Thu, 22 Apr 2010 03:51:20 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o3MAp4xF023394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Apr 2010 13:51:04 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o3MAp4NG019881; Thu, 22 Apr 2010 13:51:04 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19408.10776.164789.537305@fireball.kivinen.iki.fi> Date: Thu, 22 Apr 2010 13:51:04 +0300 From: Tero Kivinen To: Ned Freed In-Reply-To: <01NM7KYS0I420000BI@mauve.mrochek.com> References: <19396.29206.787824.69029@fireball.kivinen.iki.fi> <01NM7KYS0I420000BI@mauve.mrochek.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 32 min X-Total-Time: 91 min Cc: draft-freed-sieve-notary.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-freed-sieve-notary-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 10:51:24 -0000 Ned Freed writes: > All this extension does is give a user access to existing site capabilities > through Sieve. If those capabilities are available, a user can use or abuse > them directly far more easily than they can through Sieve. > > The only scenario where this presents an added exposure is one where > these capabilities can be accessed through Sieve but not through > regular submission or SMTP. If such a setup were created, it would > be a fairly wierd thing - so wierd I really cannot see much point in > worrying about it. But even so, this particular case is specifically > dealt with by the current security considerations. This all depends what envelope sender is used for redirects. If original author envelope sender is used, then normally there is no way to enable sending deliver status notifications to the original sender for email in transit, usually the original sender must request it. This feature adds option to someone else to request them (but see the text later about this). > RFC 5228 does not require any particular envelope sender address > be associated with redirected messages. However, the redirect-dsn > extension isn't terribly useful if the place where the delivery > status notifications are sent isn't known. Accordingly, when > either :notify or :ret is specified and the envelope sender > address isn't empty, implementations MUST set the envelope sender > address to the address of the sieve owner. This text will address the problem as after this it is not possible for someone else to request status notification for original author, i.e with this text added the problem mentioned earlier disappears. > > so the deliver status notification > > messages are sent to the original author, not to the user doing the > > redirect. > > That's one possible behavior, but if someone wants to create intentional > backscatter, it is far simpler to just connect to the submit port and say: > > MAIL FROM: > RCPT TO: NOTIFY=SUCCESS,FAILURES > DATA > blah blah > . With trace option you get amplification factor, i.e. you only need send one message and that can generate multiple messages back. > The same arguments hold for DELIVERBY. If the extension is available, why > not just (ab)use it directly? Why bother with a convoluted path through > Sieve that will almost certainly leave a much bigger trail? If the relayed status notifications go to the original author instead of the sieve filter owner, then the attacker does not need to send any emails, the victim attacks himself by sending email to attackers address which will then add trace option to the email on the fly. This attack goes away if status notifications always go to the sieve owner. > > > This should most likely be mentioned in the security considerations > > section more clearly. The security considerations section do warn > > about generating status notification, and says that > > > "Sites which limit the ability to request success notifications will > > also need to restrict the ability to request them using the > > redirect-dsn extension." > > > but that does not help at all, as if the original senders site limits > > the ability to request notifications, the host running sieve email > > filter of the receiver might not have such restrictions, thus receiver > > can enable them even when they were forbidden from the sender. > > You're missing the point. If the site restricts notification requests in some > way, e.g, you can only request a success notification if the envelope from is > local, then that restriction also needs to apply to redirect-dsn and > redirect-deliveryby, because if it doesn't you've left a hole someone could > exploit. Yes, I understood that, but depending what envelope sender is used for those status notification there is ANOTHER problem. Say host A limits DSN notification complately, i.e does not allow them at all. Now host A user A sends email to user B on host B whose sieve filter adds status notifications (as they are not restricted on host B, only on host A) and the status notifications go to original author A. Now host A user A will get status notifications even when the host A policy forbid requesting them. Host B cannot know what policy host A has, thus it cannot restrict operations. Again this problem goes away if host B can only request status notifications so they come to the host B envelope sender. > > Also in section 5, it should be made clear that the "bytime" can also > > be negative, if the bymode is "notify" and the message is already > > pasts is notification time. > > Unfortunately, RFC 2852 predates the current thinking in email that > there's significant semantic difference between submission and > relay. My understanding of the purpose of negative by-times is that > they are arrived at when a message exceeds the time limit but still > needs to be delivered. If there's a justification for having a > negative by-time on initial submission I haven't heard it. In fact > had RFC 2852 distinguished between submit and relay I suspect it > would have disallowed negative by-times in the submit case. I do not thing this is relevant here. > And since the use of this extension effectively means the message is > being resubmitted, I don't see any reason to allow negative by-times > to be specified. It might be needed if the sieve filter wants to preserve by-time values given to it in the beginning. I do not know enough of Sieve to know if it is possible, but one use could be using sieve to for example limit the by-time to something, i.e. wants to make sure that when email is redirected to cellular phone it is delivered before certain time (for example before 22:00, because user does not want to wake up when cellular phone beeps in the middle of night), unless the email already had shorted by-time, in which case it wants to preserve it. In that case the by-time could be already negative when user redirects the email. Also I think the Sieve should be able to preserve by-time and envelope sender when it redirects email, if it does not ADD new notifications. I.e if someone sends email having by-time saying it needs to be delivered during next hour, and the Sieve forwards it to the cellular, it would be useful to keep that same time limit there, and it would also be nice if the original author still gets the status notifications he asked for. If the sieve owner asks for additional notifications they should come to sieve owner, not to the original author. > I first have to say that if the timing is so critical that this sort > of thing really matters, you're pretty much sunk before you start. > For better or worse the DELIVERBY extension only applies while mail > is in transit, and there's an increasing amount of stuff that > happens outside of this context (e.g., downloads from a POP3/IMAP4 > server) that cannot be traced or "timed out"). If the email is not yet delivered to the local mail box, but is redirected to somewhere else by the Sieve then I do consider the email to still be in transit, and the time used to run the Sieve should be taken in to account. In most cases it does not really matter as running it is very fast, but I think it still needs to be counted for. > I think this makes it clear the values are simply passed unchanged > to the SMTP/submit server. But if you want to suggest a specific > change, that's fine. I think RFC 2852 is very clear that you are supposed to convert that DELTA time to absolute time upon receipt of email, and then convert it back to delta time when you send email forward: A delta time is used so as to prevent problems associated with differences in system clocks between clients and servers. Servers in receipt of a valid by-parameter are expected to convert the by-time into a locale-specific absolute time called the deliver-by-time. This is done by adding the by-time upon receipt to the current locale-specific time and thereby arriving at a locale-specific absolute time which is by-time seconds in the future or past, depending upon the arithmetic sign of by-time. The message is then to be delivered by the deliver-by-time. Hmm.. actually it would be more accordingly to the RFC2852 to not give out the delta time to Sieve, but instead the deliver-by-time (which is locale-specific absolute time instead), and leave the processing of negative and positive delta times for the email service instead of Sieve filter. This of course depends whether Sieve has time and date data format, i.e. if those can be expressed in Sieve in a way where they can processed. This would allow it easier to for example to set delivery-by-time so that no email is delivered to your cellular phone after certain time (i.e. it is bounced back if it is tried to deliver after that). -- kivinen@iki.fi From alexey.melnikov@isode.com Thu Apr 22 04:31:44 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D7033A6801; Thu, 22 Apr 2010 04:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYPtWkTsizlF; Thu, 22 Apr 2010 04:31:43 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 152903A6840; Thu, 22 Apr 2010 04:31:42 -0700 (PDT) Received: from [172.16.2.165] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 22 Apr 2010 12:31:31 +0100 Message-ID: <4BD03382.7090705@isode.com> Date: Thu, 22 Apr 2010 12:31:14 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Ned Freed References: <19396.29206.787824.69029@fireball.kivinen.iki.fi> <01NM7KYS0I420000BI@mauve.mrochek.com> In-Reply-To: <01NM7KYS0I420000BI@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-freed-sieve-notary.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-freed-sieve-notary-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 11:31:44 -0000 Ned Freed wrote: [...] >>This can cause problems for the original sender, as he is now getting >>the deliver status notifications which he has not requested. The draft >>does not explictly specify, but I do assume that the sieve redirect >>keeps the original sender intact, >> >> >Sieve redirect is defined in RFC 5228 and it doesn't specify whether the >original address is used or the address of the Sieve owner. (What it does say >is that if the original message had an empty envelope from, any redirected >message must also have an empty envelope from. This prevents certain especially >pernicious loops from forming, but I don't see it as relevant to this >discussion.) > >Considering redirect behavior further, it does raise an issue that needs to be >addressed in this document, but it's a usability issue, not a security issue. >Specifically, what does it mean to add a DSN request or activate deliverby >when you don't know where these notifications are going to go? This ruins >the usability of both redirect-dsn and redirect-deliverby. I therefore >propose adding the following text to redirect-dsn and similar text to >redirect-deliverby: > > RFC 5228 does not require any particular envelope sender address be associated > with redirected messages. However, the redirect-dsn extension isn't terribly > useful if the place where the delivery status notifications are sent isn't > known. Accordingly, when either :notify or :ret is specified and the envelope > sender address isn't empty, implementations MUST set the envelope sender > address to the address of the sieve owner. > > This looks good to me, so I've entered 2 RFC Editor notes (one for redirect-dsn and a similar one for redirect-deliverby) From turners@ieca.com Thu Apr 22 06:57:51 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 082A628C11C for ; Thu, 22 Apr 2010 06:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[AWL=-0.873, BAYES_50=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neueAty0CI59 for ; Thu, 22 Apr 2010 06:57:50 -0700 (PDT) Received: from smtp112.biz.mail.re2.yahoo.com (smtp112.biz.mail.re2.yahoo.com [66.196.116.97]) by core3.amsl.com (Postfix) with SMTP id 3B5183A6ABF for ; Thu, 22 Apr 2010 06:56:57 -0700 (PDT) Received: (qmail 49459 invoked from network); 22 Apr 2010 13:56:47 -0000 Received: from thunderfish.local (turners@71.191.8.248 with plain) by smtp112.biz.mail.re2.yahoo.com with SMTP; 22 Apr 2010 06:56:46 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: OVFvGOEVM1lGQSZq1vVUmZCT_tFOad2FgrYx2EHDH3_750FpPjKd5oND X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BD0559D.2030609@ieca.com> Date: Thu, 22 Apr 2010 09:56:45 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: scott@hyperthought.com References: <1271786580.275918665@192.168.2.231> In-Reply-To: <1271786580.275918665@192.168.2.231> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "iesg@ietf.org" , draft-turner-asymmetrickeyformat-algs@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-turner-asymmetrickeyformat-algs-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 13:57:51 -0000 scott@hyperthought.com wrote: > I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. > > This document describes conventions for crypto algorithms for use with a companion document (http://tools.ietf.org/html/draft-turner-asymmetrickeyformat-03) which is intended to replace rfc5208. > > I couldn't give this review the amount of time I would have liked to, but I hope my comments are useful nonetheless. > > In section 2, it says that the de facto standard for PrivateKeyInfo encryption is Password Based Encryption using either PKCS5 or PKCS12, and that the major difference between these is the password encoding. I was surprised that no mention was made of the more robust crypto algorithms supported by PKCS12, which seems like an important consideration for this application. > > Also, I was confused as to whether the draft is mixing the documentation of current practices with some recommendations, or whether it intends to specify a required usage profile. If the latter, it seems reasonable to ask why deprecated algorithms are included. If the former, maybe the document could do a better job of making this intention clear, and of demarcating which is which. I revisited section 2 and agree. It's not clear what the actual must algorithms. It's waxing poetic about PBES1. I double checked RFC 2898 and it recommends PBES2 be used in new applications, which I think this is one. Further someone notes that the sip-certs ID (http://tools.ietf.org/html/draft-ietf-sip-certs-12) wants to use a PBES2 algorithm. I'll work on the wording to make it clear what the requirement is (follow what sip-certs wanted), delete the tutorial about PBES1, and follow the recommendation from RFC 2898. Tim's worked up an RFC editor's note to incorporate this change. > The only other nit I had was that no mention is made of the implications of wrapping various asymmetric key sizes with potentially weaker symmetric keys/algorithms, but the security considerations section references a mighty list of related RFCs, at least one of which discusses this (RFC5649), so maybe that is good enough. That is exactly why I included the reference to RFC 5649. > --Scott > > > From ned.freed@mrochek.com Thu Apr 22 13:17:25 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8590F3A692C; Thu, 22 Apr 2010 13:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.402 X-Spam-Level: X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[AWL=-0.447, BAYES_50=0.001, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ta14-9SSodoz; Thu, 22 Apr 2010 13:17:23 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 2DBCE3A68C3; Thu, 22 Apr 2010 13:17:07 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NM95LTB09C00JION@mauve.mrochek.com>; Thu, 22 Apr 2010 13:16:43 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NM8VKSGM8G004042@mauve.mrochek.com>; Thu, 22 Apr 2010 13:16:39 -0700 (PDT) Message-id: <01NM95LR5YZ2004042@mauve.mrochek.com> Date: Thu, 22 Apr 2010 09:26:26 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 22 Apr 2010 13:51:04 +0300" <19408.10776.164789.537305@fireball.kivinen.iki.fi> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <19396.29206.787824.69029@fireball.kivinen.iki.fi> <01NM7KYS0I420000BI@mauve.mrochek.com> <19408.10776.164789.537305@fireball.kivinen.iki.fi> To: Tero Kivinen DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1271967028; bh=U8mV+oAA+AMajrkBfqWZwpJzVvcYHVSrbz2Hi/8HHD4=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=fFzIeTRJR0chdbwkHoG1PigQOlClp+1qEraryceR/zBY67z+bItc5SizNzljqjJ7G a8saGos0ma5Q7ogNknzitzeusTgNSJSGFYN6u+WEHkVwXayLiOhnBmTJvnmsw13aEh 2CQJpGMZFkCWyl+dFRpqgFzuqbUV10tX+Gbvdg1o= X-Mailman-Approved-At: Sat, 24 Apr 2010 08:48:32 -0700 Cc: draft-freed-sieve-notary.all@tools.ietf.org, Ned Freed , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-freed-sieve-notary-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 20:17:25 -0000 > Ned Freed writes: > > All this extension does is give a user access to existing site capabilities > > through Sieve. If those capabilities are available, a user can use or abuse > > them directly far more easily than they can through Sieve. > > > > The only scenario where this presents an added exposure is one where > > these capabilities can be accessed through Sieve but not through > > regular submission or SMTP. If such a setup were created, it would > > be a fairly wierd thing - so wierd I really cannot see much point in > > worrying about it. But even so, this particular case is specifically > > dealt with by the current security considerations. > This all depends what envelope sender is used for redirects. Not really. Again, since regular submit/SMTP allows specification of *any* envelope sender, and Sieve piggybacks off that capability, the only added exposure this extension provides is if the restrictions on redirect are for some reason less than what's on submit/SMTP itself. And that case is already explicitly covered in the security considersions section. > If > original author envelope sender is used, then normally there is no way > to enable sending deliver status notifications to the original sender > for email in transit, usually the original sender must request it. Sure there is. All I have to do is resubmit the message, specifying the original sender but adding whatever NOTIFY options I choose. At most Sieve offers a different way to get at this functionality; it doesn't offer the functionality itelf. > This feature adds option to someone else to request them (but see the > text later about this). > > RFC 5228 does not require any particular envelope sender address > > be associated with redirected messages. However, the redirect-dsn > > extension isn't terribly useful if the place where the delivery > > status notifications are sent isn't known. Accordingly, when > > either :notify or :ret is specified and the envelope sender > > address isn't empty, implementations MUST set the envelope sender > > address to the address of the sieve owner. > This text will address the problem as after this it is not possible > for someone else to request status notification for original author, > i.e with this text added the problem mentioned earlier disappears. It prevents it from being done using Sieve, yes, but that's not the reason for making the change and doesn't change the fact that the security issue you've described does not exist in any meaningful sense. > > > so the deliver status notification > > > messages are sent to the original author, not to the user doing the > > > redirect. > > > > That's one possible behavior, but if someone wants to create intentional > > backscatter, it is far simpler to just connect to the submit port and say: > > > > MAIL FROM: > > RCPT TO: NOTIFY=SUCCESS,FAILURES > > DATA > > blah blah > > . > With trace option you get amplification factor, i.e. you only need > send one message and that can generate multiple messages back. And the trace option is also available via submit/SMTP, so this is a distinction without a difference. > > The same arguments hold for DELIVERBY. If the extension is available, why > > not just (ab)use it directly? Why bother with a convoluted path through > > Sieve that will almost certainly leave a much bigger trail? > If the relayed status notifications go to the original author instead > of the sieve filter owner, then the attacker does not need to send > any emails, the victim attacks himself by sending email to attackers > address which will then add trace option to the email on the fly. Now please explain the significant advantage this provides to an attacker. It's not like sending emails is hard. > This attack goes away if status notifications always go to the sieve > owner. Yes, but you have failed to make the case that this "attack" is worth worrying about. > > > This should most likely be mentioned in the security considerations > > > section more clearly. The security considerations section do warn > > > about generating status notification, and says that > > > > > "Sites which limit the ability to request success notifications will > > > also need to restrict the ability to request them using the > > > redirect-dsn extension." > > > > > but that does not help at all, as if the original senders site limits > > > the ability to request notifications, the host running sieve email > > > filter of the receiver might not have such restrictions, thus receiver > > > can enable them even when they were forbidden from the sender. > > You're missing the point. If the site restricts notification requests in some > > way, e.g, you can only request a success notification if the envelope from is > > local, then that restriction also needs to apply to redirect-dsn and > > redirect-deliveryby, because if it doesn't you've left a hole someone could > > exploit. > Yes, I understood that, but depending what envelope sender is used for > those status notification there is ANOTHER problem. A problem which the security considerations already address. > Say host A limits DSN notification complately, i.e does not allow them > at all. Now host A user A sends email to user B on host B whose sieve > filter adds status notifications (as they are not restricted on host > B, only on host A) and the status notifications go to original author > A. Now host A user A will get status notifications even when the host > A policy forbid requesting them. In other words, this is a case where the Sieve policy for requesting DSNs is more lenient that for submit/SMTP. I agree this is a security concern, which is why the security considerations section of the document addresses it. It says: Sites which limit the ability to request success notifications will also need to restrict the ability to request them using the redirect-dsn extension. > Host B cannot know what policy host A has, thus it cannot restrict > operations. Not only can it know, it has to. This is what administrators are for - to implement consistent policies across hosts. And if you don't have consistent administrative policies for email handling the set of issues we're discussing here are going to be the absolute least of your problems. > Again this problem goes away if host B can only request > status notifications so they come to the host B envelope sender. Actually, no, it doesn't. It may prevent the mechanism from being used to create backscatter, but inconsistent administrative policies open the door to all sorts of other bad behavior. > > > Also in section 5, it should be made clear that the "bytime" can also > > > be negative, if the bymode is "notify" and the message is already > > > pasts is notification time. > > > > Unfortunately, RFC 2852 predates the current thinking in email that > > there's significant semantic difference between submission and > > relay. My understanding of the purpose of negative by-times is that > > they are arrived at when a message exceeds the time limit but still > > needs to be delivered. If there's a justification for having a > > negative by-time on initial submission I haven't heard it. In fact > > had RFC 2852 distinguished between submit and relay I suspect it > > would have disallowed negative by-times in the submit case. > I do not thing this is relevant here. On the contrary, it's entirely relevant because what we have done by requiring the resetting of the envelope sender is to effectively require that these extended redirect be considered as a new submission, not a relay operation. > > And since the use of this extension effectively means the message is > > being resubmitted, I don't see any reason to allow negative by-times > > to be specified. > It might be needed if the sieve filter wants to preserve by-time > values given to it in the beginning. I do not know enough of Sieve to > know if it is possible, but one use could be using sieve to for > example limit the by-time to something, i.e. wants to make sure that > when email is redirected to cellular phone it is delivered before > certain time (for example before 22:00, because user does not want to > wake up when cellular phone beeps in the middle of night), unless the > email already had shorted by-time, in which case it wants to preserve > it. The short answer is ths use-case you describe here really isn't feasible in Sieve, for a bunch of different reasons. THe longer answer is that this ends up being infeasible because: (1) Sieve doesn't have enough numeric and time computation facilities to perform the sort of limit operation you describe. (2) Even if you could do the calculation, or if, say, there was a related use-case where limiting the relative value made sense (I confess I cannot come up with one where it does), most Sieve implementations operate after final delivery, so copying deliver-by information doesn't really make sense. (3) A script that does something like this really needs to know what sort of Sieve implementation it is dealing with before doing it. In particular, it needs to know if the Sieve is operating before or after final delivery. It turns out this can be determined, but it requires an additional extension - the environment extenion and the "phase" item, e.g., "phase" => The point relative to final delivery where the Sieve script is being evaluated. Possible values are "pre", "during", and "post", referring respectively to processing before, during, and after final delivery has taken place. (4) A script that tries to do this and doesn't check the phase could result in bad behavior. I think all of this conspires to make this particular use-case one not worth worrying about. But again, this isn't something I feel strongly about, so if the consensus is to change it I will do so. > In that case the by-time could be already negative when user redirects > the email. Actually, no. In the use-case you describe, the goal is to prevent the phone from ringing after a certain point. That implies that a by-mode of "R" has to be used, which means no negative by-times are allowed. Moreover, if the original mode was "R", you can copy over a shorter by-time. But what happens if the mode is "N"? I think in that case you'd want to ignore the original by-time in order to get sensible behavior. All that said, this use-case makes me wonder if the real error here is that we aren't providing a way to look at and set by-times as absolute, rather than relative, time values. > Also I think the Sieve should be able to preserve by-time and envelope > sender when it redirects email, if it does not ADD new notifications. > I.e if someone sends email having by-time saying it needs to be > delivered during next hour, and the Sieve forwards it to the cellular, > it would be useful to keep that same time limit there, and it would > also be nice if the original author still gets the status > notifications he asked for. That's totally outside the purview of this extension, which does not and cannot deal with the unextended redirect case. Moreover, the lack of specificity about when Sieve operates - which is both intentional and essential - makes this a very difficult question to address in ANY context. Just as one example, you most certainly do NOT want to try and preserve these things if Sieve is operating in a user agent weeks after final delivery - which is a perfectly legitimate and even common situation. If this really concerns you, the place to address it is in the Sieve base specification. Feel free to propose changes there if/when that specification is revised. > If the sieve owner asks for additional notifications they should come > to sieve owner, not to the original author. Agreed and already addressed. > > I first have to say that if the timing is so critical that this sort > > of thing really matters, you're pretty much sunk before you start. > > For better or worse the DELIVERBY extension only applies while mail > > is in transit, and there's an increasing amount of stuff that > > happens outside of this context (e.g., downloads from a POP3/IMAP4 > > server) that cannot be traced or "timed out"). > If the email is not yet delivered to the local mail box, but is > redirected to somewhere else by the Sieve then I do consider the email > to still be in transit, and the time used to run the Sieve should be > taken in to account. In most cases it does not really matter as > running it is very fast, but I think it still needs to be counted for. Sieve implementations that operate at this point are in fact the exception, not the rule. > > I think this makes it clear the values are simply passed unchanged > > to the SMTP/submit server. But if you want to suggest a specific > > change, that's fine. > I think RFC 2852 is very clear that you are supposed to convert that > DELTA time to absolute time upon receipt of email, and then convert it > back to delta time when you send email forward: Yes, I'm well aware of what it says, and why. I carpool to work every day with the guy who wrote it. The reason for this text is so that implementations won't carelessly lose track of some amount of elapsed time. But again, this only works while messages are in transit. I'm not convinced there's an issue worth addressing in the Sieve case. > Hmm.. actually it would be more accordingly to the RFC2852 to not give > out the delta time to Sieve, but instead the deliver-by-time (which is > locale-specific absolute time instead), and leave the processing of > negative and positive delta times for the email service instead of > Sieve filter. Given how Sieve is situated in regards to final delivery, I once again disagree that RFC 2852 provides justification for such a change. THat said, I think the change is worth considering for other reaons, first that Sieve is equipped to deal with with absolute time values better than it is with relative ones, and second, that there are quite a few reaonsable use-cases for setting an absolute :by-time. But this is a somwwhat complex topic, and this message is already very long, so I'm going to defer discussing this to a separate message. > This of course depends whether Sieve has time and date data format, > i.e. if those can be expressed in Sieve in a way where they can > processed. This would allow it easier to for example to set > delivery-by-time so that no email is delivered to your cellular phone > after certain time (i.e. it is bounced back if it is tried to deliver > after that). That's not going to be an easy effect to get, but more on that later. Ned From prz@mit.edu Sat Apr 24 14:23:01 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D3C33A66B4; Sat, 24 Apr 2010 14:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.597 X-Spam-Level: * X-Spam-Status: No, score=1.597 tagged_above=-999 required=5 tests=[AWL=-0.733, BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_31=0.6, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZ4xpggxwEMM; Sat, 24 Apr 2010 14:22:59 -0700 (PDT) Received: from mail.philzimmermann.com (adsl-99-107-86-52.dsl.pltn13.sbcglobal.net [99.107.86.52]) by core3.amsl.com (Postfix) with ESMTP id E666C3A691D; Sat, 24 Apr 2010 14:22:54 -0700 (PDT) Received: from [10.0.1.218] ([10.0.1.1]) (authenticated bits=0) by mail.philzimmermann.com (8.14.3/8.14.3) with ESMTP id o3OLMcGm069920 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 24 Apr 2010 14:22:41 -0700 (PDT) (envelope-from prz@mit.edu) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Philip Zimmermann X-Priority: 3 (Normal) In-Reply-To: <142c29cbb5f6f54edc203861e7c6ac7b.squirrel@www.trepanning.net> Date: Sat, 24 Apr 2010 14:22:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <69BB892A-4D41-4B39-8641-4CEEA19F9F1B@mit.edu> References: <142c29cbb5f6f54edc203861e7c6ac7b.squirrel@www.trepanning.net> To: Dan Harkins X-Mailer: Apple Mail (2.1078) X-Mailman-Approved-At: Sat, 24 Apr 2010 14:32:56 -0700 Cc: draft-zimmermann-avt-zrtp.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-zimmermann-avt-zrtp-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 21:23:01 -0000 Dan, thank you for reviewing our draft. It's great to get comments from = someone who understands hash functions so well. When we talked on the phone, I clarified the fact that we already use = hash commits to address some of the concerns you raised below. I have adjusted our computations of srtps and ZRTPSess to use KDFs more = effectively, because of our conversation. This will be reflected in = ZRTP draft 18. Your reference to Hugo's paper was most helpful. Because of this, I = read his paper, and called Lily Chen at NIST to discuss how NIST would = use Hugo's ideas in the future. She said NIST plans to update SP800-56A = to address this. As it stands, we are using the current version of = SP800-56A to achieve strict NIST compliance to facilitate FIPS-140 = validation testing. Regards, Phil On Mar 30, 2010, at 1:22 PM, Dan Harkins wrote: >=20 > Hi, >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > This draft defines a Diffie-Hellman based key exchange to generate > a session key to use with SRTP. It prevents a man-in-the-middle attack > against the Diffie-Hellman key exchange without requiring traditional > authentication. It does not require use of a PKI. >=20 > There are three things I think the ADs should take a look at: having > the protocol resist a small sub-group attack, use of the "auxsecret", = and > the hashing mishmash. All are described below. >=20 > The MitM attack is thwarted by using a short authentication string = (SAS) > that is presented to users on each side of the ZRTP exchange to be = read > and verbally compared. >=20 > An immediate concern with such an approach is that it might enable a > small sub-group attack against the Diffie-Hellman exchange that would > be undetectable by verification of the SAS. An attacker could take an > element of small order, f, and create pvi' =3D pvi^f modp and > pvr' =3D pvr^f mod p and the shared secret, DHResult', would be = confined to > the small group. The SAS would verbally verify and the two parties = would > continue unaware of the attack. But the DH shared secret is = subsequently > used (indirectly) in a hash which fixes it and exposes it to the MitM, > which can run through the values in the small sub-group to determine > DHResult' and then attack the SRTP connection. >=20 > The draft specifies support for a Diffie-Hellman domain parameter set > using a safe prime (from RFC 3526) which would prevent such an attack > but it seems that the protocol should be secure in and of itself and = not > rely on external safeguards. I recommend sections 4.4.1.2 and 4.4.1.3 > define an additional processing step to ensure pvi and pvr are not in > a small sub-group. For a safe-prime this can be viewed as a "belt and > suspenders" approach, but I don't see why ZRTP couldn't be used in the > future with other domain parameter sets which may not be based on safe > primes and therefore such a check would be vital. >=20 > The draft has a clever shared secret state matching algorithm to use > secrets from a cache of state associated with a peer. One of these is > called "auxsecret", as described in section 4.3.1: >=20 > "the auxsecret shared secret may be manually provisioned in other > application-specific ways that are out-of-band, such as computed = from > a hashed pass phrase by prior agreement between the two parties. Or > it may be a family key used by an institution that the two parties = both > belong to." >=20 > If one does not have an "auxsecret" configured a random value is used = in > its field during the ZRTP exchange. If one does have an "auxsecret" = though > it does not appear to change. >=20 > Traffic analysis, therefore, would tell an attacker whether an > "auxsecret" is being used or not. If one is, an off-line dictionary = attack > might be possible if the "auxsecret" is being used per section 4.3.1 = (if > it is a "family key used by an institution" then every member of the > institution would use the same "auxsecret" and that could also be = easily > detected). >=20 > I recommend that the "auxsecret" be updated in the cache in section > 4.6.1 so that it is different with a subsequent run of the protocol. = If > that logistically isn't possible then perhaps hash rs1 or rs2 with it > in 4.3.1 to produce "auxsecretIDi" and "auxsecretIDr". Since there is = a > matching algorithm for r1 and r2 then it might be necessary to have = two > "auxsecretIDi" and two "auxsecretIDr", one hashed with r1 and one with > r2. The cost is a little extra space but the benefit seems worth it. >=20 > There is a confusing mix of hashing, HMACing, and KDFing. In section > 4.4.1.4 a secret value s0 is derived using the KDF technique from > SP800-56A, which is not of the keyed variety, it just uses a hash = function > in counter mode. But if a preshared key is used then section 4.4.2.4 > derives s0 with an HMAC-based KDF based on SP800-108. This value, s0, > is then used to derive the SRTP session key, the SAS, and various > encryption and integrity protection keys using the HMAC-based, = SP800-108 > version of a KDF. When a session is terminated all keys are destroyed > except ZRTPSess which is replace by a hash of itself. But it was > originally derived by a keyed KDF. This seems unnecessarily complex = and > would make this protocol very difficult to analyze. >=20 > There has been much discussion on the CFRG list about how the output > of a hash function is too structured to use the key to an HMAC (see > Hugo Krawczyk's HKDF draft). Whether the SP800-56A hash-style KDF is > good or whether the SP800-108 keyed HMAC-style KDF is good is a debate > for another forum but I think this draft should choose one and stick = to > it. Keys derived from a hash function should not be used as keys to > an HMAC and keys derived from an HMAC-based KDF should not be replaced > with a simple hash of themselves. >=20 > Editorial nits: >=20 > * sections 4.4.1.1 and 4.4.1.2 mention the "width of the DH prime". > How about "bit-length of the DH prime" instead? > * section 4.4.1.1 mentions ECDH but then goes on to specify the > finite field (MODP) version of the exchange. I suggest adding an > example of ECDH in 4.4.1.1 and 4.4.1.2. >=20 > regards, >=20 > Dan. >=20 >=20 ------------------------------------------------ Philip R Zimmermann prz@mit.edu (spelled with 2 n's) http://philzimmermann.com tel +1 831 425-7524 http://zfone.com From ned.freed@mrochek.com Sat Apr 24 14:46:02 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 532973A6AA3; Sat, 24 Apr 2010 14:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.855 X-Spam-Level: X-Spam-Status: No, score=-0.855 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41EdRYVOSjb6; Sat, 24 Apr 2010 14:46:01 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 4E4A13A6A8E; Sat, 24 Apr 2010 14:46:01 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NMC1AXOBSW00KSB9@mauve.mrochek.com>; Sat, 24 Apr 2010 14:45:46 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NMAT47YVRK0000BI@mauve.mrochek.com>; Sat, 24 Apr 2010 14:45:43 -0700 (PDT) Message-id: <01NMC1AVJ6D80000BI@mauve.mrochek.com> Date: Sat, 24 Apr 2010 14:44:43 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 22 Apr 2010 12:31:14 +0100" <4BD03382.7090705@isode.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <19396.29206.787824.69029@fireball.kivinen.iki.fi> <01NM7KYS0I420000BI@mauve.mrochek.com> <4BD03382.7090705@isode.com> To: Alexey Melnikov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1272145166; bh=qXkdKU+y+Cb39xhJTPS3zZbJ+jaPC4a4cfAdnK0k6hw=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=Oa1qUeFRv26Galq19PHU5ml+9XL6uI3jDwE7np6mWoqU5cL7+3PZG/PY0ByLtLv5P dpfq7nCJvaavHfB0Jlj9l/HsDpL9mvaAHCeVtpEmGnaKWZGEsoZsbRmj8AxqSvCQFh 5HJUkYPe08cw0k+WfLzYd22uJKE5V5ZvhirtL934= X-Mailman-Approved-At: Sat, 24 Apr 2010 14:47:17 -0700 Cc: draft-freed-sieve-notary.all@tools.ietf.org, Ned Freed , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-freed-sieve-notary-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 21:46:02 -0000 > Ned Freed wrote: > [...] > >>This can cause problems for the original sender, as he is now getting > >>the deliver status notifications which he has not requested. The draft > >>does not explictly specify, but I do assume that the sieve redirect > >>keeps the original sender intact, > >> > >> > >Sieve redirect is defined in RFC 5228 and it doesn't specify whether the > >original address is used or the address of the Sieve owner. (What it does say > >is that if the original message had an empty envelope from, any redirected > >message must also have an empty envelope from. This prevents certain especially > >pernicious loops from forming, but I don't see it as relevant to this > >discussion.) > > > >Considering redirect behavior further, it does raise an issue that needs to be > >addressed in this document, but it's a usability issue, not a security issue. > >Specifically, what does it mean to add a DSN request or activate deliverby > >when you don't know where these notifications are going to go? This ruins > >the usability of both redirect-dsn and redirect-deliverby. I therefore > >propose adding the following text to redirect-dsn and similar text to > >redirect-deliverby: > > > > RFC 5228 does not require any particular envelope sender address be associated > > with redirected messages. However, the redirect-dsn extension isn't terribly > > useful if the place where the delivery status notifications are sent isn't > > known. Accordingly, when either :notify or :ret is specified and the envelope > > sender address isn't empty, implementations MUST set the envelope sender > > address to the address of the sieve owner. > > > > > This looks good to me, so I've entered 2 RFC Editor notes (one for > redirect-dsn and a similar one for redirect-deliverby) Ggood. I dp think this has reached the point where a new draft is needed, especially if we also decide to pursue the whole absolute time thing. Ned From Sandra.Murphy@cobham.com Sun Apr 25 00:48:23 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91BFC3A6850 for ; Sun, 25 Apr 2010 00:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.032 X-Spam-Level: X-Spam-Status: No, score=-1.032 tagged_above=-999 required=5 tests=[AWL=-1.033, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQqq5qywKNwE for ; Sun, 25 Apr 2010 00:48:22 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id DF0743A684C for ; Sun, 25 Apr 2010 00:48:21 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o3P7m4Cq029429; Sun, 25 Apr 2010 02:48:05 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o3P7m3cX025718; Sun, 25 Apr 2010 02:48:03 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.248.12]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Apr 2010 03:42:00 -0400 Date: Sun, 25 Apr 2010 03:41:59 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Adam Roach In-Reply-To: <4BCDAB7A.7080208@nostrum.com> Message-ID: References: <4BCD7169.9020701@cs.tcd.ie> <4BCDAB7A.7080208@nostrum.com> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 25 Apr 2010 07:42:00.0374 (UTC) FILETIME=[CA26E560:01CAE44A] Cc: secdir@ietf.org, draft-ietf-sipcore-info-events@tools.ietf.org, sipcore-chairs@tools.ietf.org Subject: Re: [secdir] secdir review of draft-ietf-sipcore-info-events X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Apr 2010 07:48:23 -0000 On Tue, 20 Apr 2010, Adam Roach wrote: > On 4/20/10 04:18, Apr 20, Stephen Farrell wrote: >> Hi, >> >> (Sorry for the tardy review;-) >> >> This specification sort-of provides a SIP-based tunnel >> for application protocols. >> >> 1: What prevents (or allows detection of) insertion of >> bogus Info Package specifications? (e.g. by a proxy). If >> nothing, then why is this ok? >> > > This is the general way that SIP works, and it applies to all the SIP header > fields. It's not great, but proxies are implicitly trusted to do the right > thing. If it's a problem for INFO, then it's a problem for everything that > has ever used or will ever use SIP. Aye, and therein lies the rub. ;-} In my usual broken-record nagging, insider failures are hard to protect against, sometimes impossible. But knowing just how bad things might get (how much damage an insider failure could potentially cause) might be a good idea. It might inspire people to put strong operational controls in place. Buy a bigger liability policy. Abandon all hope ye who enter here. etc. When I made some similar comments on a different SIP draft a while back, there was a discussion on the sip wg list of writing down somewhere what the wg chair called the "please molest me" security model. I didn't follow the discussion to the end, so I don't know if that ever got past the good intention stage and if so where the written down text ended up. --Sandy > >> 2: I don't know how prevalent implementations of this are, >> or will be, but since this calls for the user agents to >> include a MIME parser plus parsers for whatever MIME types >> the user agent claims to support, I'd say some guideance >> about defensive programming (e.g. avoiding buffer overruns >> etc.) should be given somewhere (maybe that's a more generic >> SIP thing though). >> > > I would think that's also a general comment about the way that SIP works. > Such guidance would seem out of place squirreled away in a document that is > otherwise simply defining a new method. In fact, I would argue that it should > be attached to a MIME-related document, not a SIP-related one. > >> 3. 4.2.2. says that a UA MUST indicate which Info packages it >> supports. That seems a bit open-kimono - why MUST all UAs tell >> everyone everything they support all the time? Won't that >> expose more attack surface than is wise? Wouldn't it be better >> to first know who the other UA is, before telling them everything >> every time? For example, imagine a UA supported the "US Govt >> SECRET foobar application Info Package," I'm guessing that it >> wouldn't be ok to just say that to every UA one meets on >> the Internet. >> > > I think that's a somewhat tortured reading of that text. The actual text is: > > A UA which supports the Info Package mechanism MUST indicate, using > the Recv-Info header field, the set of Info Packages for which it is > willing to receive INFO requests. > > > This leaves a lot of wiggle room around the difference between "supports" and > "is willing to receive." > >> 4. 10.10 says that if TLS is not good enough, then use S/MIME. >> My understanding is that no UAs implement S/MIME (or CMS really) >> and no networks support its use. So shouldn't that really say >> "if TLS is not good enough, then just don't do it or require >> the application to do its own security"? Same point applies to >> section 13. I would think that securing specific applications >> would be easier and more likely than getting S/MIME used in UAs, >> so why not recommend that? >> > > The difficulties with getting S/MIME deployed in SIP, I think, stem from the > lack of a viable PKI. With the publication of draft-ietf-sip-certs-12 as an > RFC -- which I anticipate happening soon -- I have renewed hope that S/MIME > may se some deployment yet. > >> 5. 1st para of section 13 says that this will be an improvement >> over RFC2976. I would think a reference to the problems with >> that RFC or to something detailing the expected improvement is >> warranted. >> > > So you want it to point back to section 9.2? > >> Non security notes: >> >> s1, 2nd para: how can you prevent INFO being used to update the >> state of a "SIP dialog or session"? Seems like it'd be more >> accurate to say that that's the intent but that there really are >> no guarantees. The example given in the abstract of RFC2976 seems >> in fact to be directly related to signalling so that's confusing. >> > > SIP dialog and session state is a very specific set of information described > in RFC 3261. It relates to things like the route a message takes through the > SIP network, certain endpoint identifiers, and whether the dialog itself is > active or terminated. It is a very specific term of art that is generally > known to SIP implementors. > > /a > From weiler+secdir@watson.org Sun Apr 25 10:42:07 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6CEA3A68DF for ; Sun, 25 Apr 2010 10:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqysFvP4s12t for ; Sun, 25 Apr 2010 10:42:06 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 06F5C3A6A06 for ; Sun, 25 Apr 2010 10:32:15 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o3PHW46J029969 for ; Sun, 25 Apr 2010 13:32:04 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o3PHW4i0029966 for ; Sun, 25 Apr 2010 13:32:04 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Sun, 25 Apr 2010 13:32:04 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Sun, 25 Apr 2010 13:32:04 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Apr 2010 17:42:07 -0000 Nico Williams is next in the rotation. Documents on the telechat agenda typically have a last call end date before the date shown below; reviews by the end of last call are typically more appreciated by the doc editors. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2010-05-06 Reviewer Deadline Draft Rob Austein T 2010-05-04 draft-denenberg-mods-etc-media-types-01 Dave Cridland T 2010-05-04 draft-ietf-isms-dtls-tm-10 Alan DeKok T 2010-05-04 draft-ietf-netmod-yang-12 Tobias Gondrom TR2010-05-04 draft-mattsson-mikey-ticket-03 David McGrew T 2010-05-04 draft-turner-encryptedkeypackagecontenttype-algs-01 Chris Newman T 2010-05-04 draft-ietf-ipsecme-aes-ctr-ikev2-07 Eric Rescorla T 2010-05-04 draft-ietf-keyprov-dskpp-10 Joe Salowey T 2010-05-04 draft-ietf-keyprov-symmetrickeyformat-07 Tina TSOU T 2010-05-04 draft-ietf-mext-flow-binding-06 Tom Yu T 2010-05-04 draft-ietf-ipsecme-ikev2bis-10 Last calls and special requests: Reviewer Deadline Draft Alan DeKok 2009-10-01 draft-ietf-enum-enumservices-transition-05 Steve Hanna None draft-ietf-tsvwg-ecn-tunnel-08 Love Hornquist-Astrand 2010-04-07 draft-ietf-eai-mailinglist-06 Jeffrey Hutzelman 2010-04-06 draft-lawrence-sipforum-user-agent-config-01 Charlie Kaufman 2010-04-05 draft-turner-additional-cms-ri-choices-03 David McGrew 2010-03-10 draft-ietf-ecrit-framework-10 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Catherine Meadows None draft-ietf-tsvwg-dtls-for-sctp-05 Magnus Nystrom 2010-04-21 draft-ietf-mpls-tp-framework-11 Hilarie Orman 2010-04-26 draft-hethmon-mcmurray-ftp-hosts-11 Radia Perlman 2010-04-29 draft-ietf-avt-rtp-rfc3984bis-10 Vincent Roca 2010-04-26 draft-ietf-keyprov-pskc-05 Stefan Santesson 2010-04-23 draft-reschke-webdav-post-06 Yaron Sheffer 2010-05-19 draft-hoffman-tls-master-secret-input-01 Carl Wallace 2010-05-06 draft-ietf-mpls-tp-survive-fwk-05 Sam Weiler 2008-08-13 draft-chown-v6ops-rogue-ra-03 Sam Weiler 2010-05-19 draft-hoffman-tls-additional-random-ext-01 Brian Weis 2010-05-19 draft-sheffer-emu-eap-eke-06 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-04 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-06 Larry Zhu 2010-03-20 draft-ietf-sip-domain-certs-06 From jsalowey@cisco.com Sun Apr 25 13:30:24 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 194F83A6894; Sun, 25 Apr 2010 13:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.493 X-Spam-Level: X-Spam-Status: No, score=-10.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sP9oFppkPnDm; Sun, 25 Apr 2010 13:30:23 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 05D4B3A68D8; Sun, 25 Apr 2010 13:30:15 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOtC1EurR7H+/2dsb2JhbACcM3GleZhthQwEgzk X-IronPort-AV: E=Sophos;i="4.52,270,1270425600"; d="scan'208";a="120322770" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 25 Apr 2010 20:30:03 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3PKU3HY023749; Sun, 25 Apr 2010 20:30:03 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Apr 2010 13:30:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 25 Apr 2010 13:30:00 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: review of draft-ietf-keyprov-symmetrickeyformat-07 Thread-Index: AcrkthOxnwbFPjkSS7OYo3hFe5GsPg== From: "Joseph Salowey (jsalowey)" To: , , X-OriginalArrivalTime: 25 Apr 2010 20:30:03.0813 (UTC) FILETIME=[1605A550:01CAE4B6] Cc: draft-ietf-keyprov-pskc@tools.ietf.org Subject: [secdir] review of draft-ietf-keyprov-symmetrickeyformat-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Apr 2010 20:30:24 -0000 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. The document defines an ASN.1 container for symmetric keys. This seems useful. For the most part the document is clear. I have the following comments (I also copied the authors of draft-ietf-keyprov-pskc-05 since some of the comments may more pertain to that document).=20 1. Is the sKey value encrypted or clear text? =20 2. Section 3.2.12 Value MAC I was not clear to me how this MAC was calculated. What exactly does it cover? I assume it is the octet string in the sKey field in the OneSymmetricKey sequence. Does it include the ASN.1 encoding or not. =20 3. Why is section 4 necessary in draft-ietf-keyprov-symmetrickeyformat-07 and not in http://tools.ietf.org/html/draft-ietf-keyprov-pskc-05? =20 Thanks, Joe From turners@ieca.com Sun Apr 25 15:55:43 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D407A3A69D4 for ; Sun, 25 Apr 2010 15:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.863 X-Spam-Level: X-Spam-Status: No, score=-0.863 tagged_above=-999 required=5 tests=[AWL=-0.865, BAYES_50=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXytN0jIUO9d for ; Sun, 25 Apr 2010 15:55:43 -0700 (PDT) Received: from smtp114.biz.mail.re2.yahoo.com (smtp114.biz.mail.re2.yahoo.com [66.196.116.99]) by core3.amsl.com (Postfix) with SMTP id 606713A689B for ; Sun, 25 Apr 2010 15:55:42 -0700 (PDT) Received: (qmail 89144 invoked from network); 25 Apr 2010 22:55:28 -0000 Received: from thunderfish.local (turners@96.231.128.135 with plain) by smtp114.biz.mail.re2.yahoo.com with SMTP; 25 Apr 2010 15:55:27 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: Bd3T1h0VM1lsCI2F_ulu2niZsnR8aT6HMvean8fUb3DOiYDowYoik7yIAmxtzlfuygENeOsckD7L097iIAzxfcbr3kTYkNCf9tg_JuIJwTBXege3Px.7y8RD1c4umv4QytinxMn1ZpGIwheuWtBTR.UJgJSuw7K1RHHDZowXVcegxP7SY_fVL2oSxzPM4q2Rlalr2uXsOXK7GpVxS5h7J.fivgPupzULmaEx6Ky0UmlBlsABPpgZ2Zp1S_y_nRecW8vg.JS3UM5nXn6uIEycS.1PIk9hOGaDXsZG5ULH7c5sbh5NP6kgZSPxF1kt9OWxW2CD0OehFsBuOICS_cRJaodQaHsjAOZUETP2zxF67UjN.ghXvWzNT8nQM.LJKN07dtd7Y7P_ddh2RxUF6Ku5Z_7VFgQG9P4Z5Ja4v8sOEAJn3uOzMQeHgYxBiv7M6S9GCzK9Mleo4HTSX1oHuHo- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BD4C85A.1060200@ieca.com> Date: Sun, 25 Apr 2010 18:55:22 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Joseph Salowey \(jsalowey\)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-keyprov-pskc@tools.ietf.org, draft-ietf-keyprov-symmetrickeyformat.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] review of draft-ietf-keyprov-symmetrickeyformat-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Apr 2010 22:55:43 -0000 Joseph Salowey (jsalowey) 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. > > The document defines an ASN.1 container for symmetric keys. This seems > useful. For the most part the document is clear. I have the following > comments (I also copied the authors of draft-ietf-keyprov-pskc-05 since > some of the comments may more pertain to that document). > > 1. Is the sKey value encrypted or clear text? It can be either. If it's in the cleartext then an encapsulation mechanism is needed to provide confidentiality (DSKPP provides one and CMS is another). But, you could also encrypt just the key and add an attribute that gives you the information needed to decrypt it. > 2. Section 3.2.12 Value MAC > > I was not clear to me how this MAC was calculated. What exactly does it > cover? I assume it is the octet string in the sKey field in the > OneSymmetricKey sequence. Does it include the ASN.1 encoding or not. This attribute is necessary because PSKC supports encryption of just the key but the required key encryption algorithms does not provide an integrity check (i.e., they're requiring AES-128-CBC and not AES Key Wrap or AES Key Wrap with Padding). If the key is encrypted with an algorithm that doesn't support an integrity check, then you do a MAC over the encrypted key (the text uses "encrypted value") and this attribute identifies the MAC algorithm and includes the MAC value. Does the following make more sense: OLD: The Value MAC attribute is a Message Authentication Code (MAC) generated from the encrypted value in case the encryption algorithm does not support integrity checks (e.g., AES-CBC does not provide integrity while AES Key Wrap with MLI does). NEW: The Value MAC attribute is a Message Authentication Code (MAC) generated over the encrypted key in case the key encryption algorithm does not support integrity checks (e.g., AES-CBC does not provide integrity while AES Key Wrap with MLI does). The MAC is over the value portion of the sKey field. > 3. Why is section 4 necessary in > draft-ietf-keyprov-symmetrickeyformat-07 and not in > http://tools.ietf.org/html/draft-ietf-keyprov-pskc-05? I don't see why it couldn't go in PSKC. I think I just forgot to suggest that they include it. > Thanks, > > Joe > From radiaperlman@gmail.com Sun Apr 25 22:30:51 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2BAE28C145; Sun, 25 Apr 2010 22:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Y-KgsHB6brH; Sun, 25 Apr 2010 22:30:51 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id F1F0D3A6B05; Sun, 25 Apr 2010 22:14:19 -0700 (PDT) Received: by qyk11 with SMTP id 11so14494368qyk.13 for ; Sun, 25 Apr 2010 22:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=v+XD2PuhkelMuaJWAnxbHdqfowRaIdIASyFzQVrH6so=; b=GnW+UK+BzZX+kuCAA5SVWSMX7y9EEyY13kS+nyOdA1s+Dbuok/A6oRyISTteO2lm8s wRMff27ttj5gCZ68Lc95FRYtahBg9Q+e0ptGd2Nz4hHUT0KMyPtqrZH/64COAjIZahoN l2MWZqVMszjeNiUlfrQVyA2faQje5+PqXibKQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=seOrGAGV/mb7wXpkzkl8gVlOM2XSDGC/q0cV+0/S2g22Nx0/2Ua/u6DkQsgZPAxPwH xoUfv6/gq36hUHNxSoNlp2gd/FVplzAJvOJZrsXc0esx0y2ZxbgNqY5Y8i4Vxg4QxzvR P1v+Y13XBpb1ZQYcJ6h4OchjgwEZOzb1BcBz0= MIME-Version: 1.0 Received: by 10.229.191.15 with SMTP id dk15mr4270456qcb.20.1272258845323; Sun, 25 Apr 2010 22:14:05 -0700 (PDT) Received: by 10.231.147.70 with HTTP; Sun, 25 Apr 2010 22:14:05 -0700 (PDT) Date: Sun, 25 Apr 2010 22:14:05 -0700 Message-ID: From: Radia Perlman To: secdir@ietf.org, iesg@ietf.org, draft-ietf-avt-rtp-rfc3984bis-10.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] secdir review of draft-ietf-avt-rtp-rfc3984bis-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 05:30:51 -0000 This document just describes how to carry video in RTP. Apparently there is a standard in ISO and a standard in ITU (ITU-T Recommendation H.264 and ISO/IEC International Standard 14496 Part 10) that both specify nearly identical compression algorithms for video encoding. Given that this document is not describing the video encoding itself, but just how to carry it in RTP, it is a little surprising that this document is 104 pages, but it describes what to do about reordering, lost packets, fragmentation across packet boundaries, and so forth. There really are not any security considerations, and certainly not anything they missed in their security considerations section. One thing that might be nice to mention is that it is dangerous to do encryption without integrity protection because a single bit error in the ciphertext can cause a lot of errors in the plaintext. Radia From radiaperlman@gmail.com Sun Apr 25 22:34:59 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E7DD28C15F; Sun, 25 Apr 2010 22:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.204 X-Spam-Level: X-Spam-Status: No, score=-1.204 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nP2PH50F6hSk; Sun, 25 Apr 2010 22:34:58 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id 2830A3A6BA5; Sun, 25 Apr 2010 22:21:37 -0700 (PDT) Received: by qyk11 with SMTP id 11so14501553qyk.13 for ; Sun, 25 Apr 2010 22:20:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=YPScOG3R6sVMpnIjOBGt1XdGkOjooOR3jBX8AfaPySk=; b=Qz23o16C5Uc00kR/apkop9dVn1z8lgNlQgd6SVLXayH+qHT3WVNdXPpbQl/HRvOCls 6uc1upH6IMo9Ug7kqkZ9gpT/UEgjX38ByuF+VRVayvSdgRPuf0oqfEBQ7Lm1daSp7e4d plmoLI3XfDxyBtK+CX+uU8X3/lSGenbc8/tMQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=RVZpXvFwYxL7r9sHdl4D4jVN+vJtLKTJFfgWqdMDH8wxwL6iCRRS4Br/auU/iSWQ0C VsB1I1CtzKsty9qQBb5yFBgjbzGgoq88FGLv9J0jG4zWxzCznNbZ0vta/1pa/iNWqpcw gx4FUqYExhY9JJhErSBLmq2RMOCnwtpnJfowo= MIME-Version: 1.0 Received: by 10.229.227.5 with SMTP id iy5mr4326278qcb.29.1272259247872; Sun, 25 Apr 2010 22:20:47 -0700 (PDT) Received: by 10.231.147.70 with HTTP; Sun, 25 Apr 2010 22:20:47 -0700 (PDT) In-Reply-To: References: Date: Sun, 25 Apr 2010 22:20:47 -0700 Message-ID: From: Radia Perlman To: secdir@ietf.org, iesg@ietf.org, yekuiwang@huawei.com, ron.even.tlv@gmail.com, tom.kristensen@tandberg.com, tomkri@ifi.uio.no, rjesup@wgate.com Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [secdir] secdir review of draft-ietf-avt-rtp-rfc3984bis-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 05:34:59 -0000 Sorry secdir and iesg for sending this twice...I've been trying to figure out how to use the tools thing to get all the authors, and apparently didn't do it right, so I'll manually put in the authors names like I have done before, on previous secdir reviews. (sending to draft-ietf-avt-rtp-rfc3984bis-10.all@tools.ietf.org bounced) On Sun, Apr 25, 2010 at 10:14 PM, Radia Perlman wrote: > This document just describes how to carry video in RTP. Apparently > there is a standard in ISO and a standard in ITU (ITU-T Recommendation > H.264 and ISO/IEC International Standard 14496 Part 10) that both > specify nearly identical compression algorithms for video encoding. > Given that this document is not describing the video encoding itself, > but just how to carry it in RTP, it is a little surprising that this > document is 104 pages, but it describes what to do about reordering, > lost packets, fragmentation across packet boundaries, and so forth. > > There really are not any security considerations, and certainly not > anything they missed in their security considerations section. One > thing that might be nice to mention is that it is dangerous to do > encryption without integrity protection because a single bit error in > the ciphertext can cause a lot of errors in the plaintext. > > Radia > From charliek@microsoft.com Sun Apr 25 22:48:47 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AFA13A69D2; Sun, 25 Apr 2010 22:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVImOMT+CGlC; Sun, 25 Apr 2010 22:48:46 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id C47243A6880; Sun, 25 Apr 2010 22:44:06 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 25 Apr 2010 22:43:55 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.187]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi; Sun, 25 Apr 2010 22:43:54 -0700 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-turner-additional-cms-ri-choices.all@tools.ietf.org" Thread-Topic: Secdir review of draft-turner-additional-cms-ri-choices-03.txt Thread-Index: AcrlA3NMIZNH4zjOTC66YANKWweFog== Date: Mon, 26 Apr 2010 05:43:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] Secdir review of draft-turner-additional-cms-ri-choices-03.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 05:48:47 -0000 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. This document proposes a syntax for including OCSP (Online Certificate Stat= us Protocol) and SCVP (Server-Based Certificate Validation Protocol) respon= se within a RevocationInfoChoices data structure defined in CMS. Previously= , while that data structure was designed to be extensible, the only defined= syntax was for the inclusion of CRLs (Certificate Revocation Lists). The document proposes the most natural way to embed the new information and= I found no problems with the spec. My only concern is with regard to the last line of Security Considerations:= "It is a matter of local policy whether these encapsulated SCVP responses = are considered valid by another entity." Even though the SCVP responses are= signed by the SCVP server, there is no way for the verifying entity to det= ermine whether the nonces inside the response are fresh, therefore it's not= obvious under what circumstances it would be safe for the verifying entity= to trust that response. If there were a timestamp inside the response, tha= t would help. I don't know whether there is or whether there is a similar i= ssue with OCSP. I am surprised that IANA is not expected to track and post the object ident= ifiers defined in this RFC below an arc that IANA delegated to the PKIX wor= king group, but the IANA considerations section seems to imply this. Some typos (both in section 4): posses -> possess "client can retain" -> "client to retain" From christer.holmberg@ericsson.com Mon Apr 26 05:43:52 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90D393A6993 for ; Mon, 26 Apr 2010 05:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.941 X-Spam-Level: X-Spam-Status: No, score=-3.941 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zMG5FpReiVN for ; Mon, 26 Apr 2010 05:43:51 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id D94E43A6B9B for ; Mon, 26 Apr 2010 05:43:46 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-33-4bd58a7531da Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 35.10.23532.57A85DB4; Mon, 26 Apr 2010 14:43:33 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.70]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Mon, 26 Apr 2010 14:43:33 +0200 From: Christer Holmberg To: Sandra Murphy , Adam Roach Date: Mon, 26 Apr 2010 14:43:31 +0200 Thread-Topic: [secdir] secdir review of draft-ietf-sipcore-info-events Thread-Index: AcrkS8PJRsNZFtp4S8KgbBF/Bk6uDQA8adKA Message-ID: References: <4BCD7169.9020701@cs.tcd.ie> <4BCDAB7A.7080208@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "secdir@ietf.org" , "draft-ietf-sipcore-info-events@tools.ietf.org" , "sipcore-chairs@tools.ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-sipcore-info-events X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 12:43:52 -0000 Hi Sandy,=20 >>>This specification sort-of provides a SIP-based tunnel for=20 >>>application protocols. >>>=20 >>>1: What prevents (or allows detection of) insertion of bogus Info=20 >>>Package specifications? (e.g. by a proxy). If nothing, then why is=20 >>>this ok? >>>=20 >> >>This is the general way that SIP works, and it applies to all the SIP=20 >>header fields. It's not great, but proxies are implicitly=20 >>trusted to do the right thing. If it's a problem for INFO, then it's a pr= oblem=20 >>for everything that has ever used or will ever use SIP. >=20 >Aye, and therein lies the rub. ;-} >=20 >In my usual broken-record nagging, insider failures are hard=20 >to protect against, sometimes impossible. But knowing just=20 >how bad things might get (how much damage an insider failure=20 >could potentially cause) might be a good idea. It might=20 >inspire people to put strong operational controls in place. =20 >Buy a bigger liability policy. Abandon all hope ye who enter=20 >here. etc. >=20 >When I made some similar comments on a different SIP draft a=20 >while back, there was a discussion on the sip wg list of=20 >writing down somewhere what the wg chair called the "please=20 >molest me" security model. I didn't follow the discussion to=20 >the end, so I don't know if that ever got past the good=20 >intention stage and if so where the written down text ended up. I guess Adam can comment on the status about that. However, I see that as a generic work, and not something that should be don= e in the Info-Events draft. Section 10.10 talks about the usage of some security mechanism in order to = protect the data, and I am not sure what more we could say in this draft. Regards, Christer From turners@ieca.com Mon Apr 26 06:41:09 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F32528C110 for ; Mon, 26 Apr 2010 06:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.817 X-Spam-Level: X-Spam-Status: No, score=-0.817 tagged_above=-999 required=5 tests=[AWL=-0.819, BAYES_50=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PejXSvLJHQUq for ; Mon, 26 Apr 2010 06:41:08 -0700 (PDT) Received: from smtp112.biz.mail.re2.yahoo.com (smtp112.biz.mail.re2.yahoo.com [66.196.116.97]) by core3.amsl.com (Postfix) with SMTP id 6D2D83A6B27 for ; Mon, 26 Apr 2010 06:41:08 -0700 (PDT) Received: (qmail 50443 invoked from network); 26 Apr 2010 13:40:56 -0000 Received: from thunderfish.local (turners@71.191.2.51 with plain) by smtp112.biz.mail.re2.yahoo.com with SMTP; 26 Apr 2010 06:40:56 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: W0o440oVM1krpBGmzR1Ch16geaibHvwQo1mMt2FHkLBGojI8Ki39e3HUFEnPMlLoLZoq0G0yMIsEb3AIJvSqG8KSaM7gmnos1oz52cGE10VDFsXzIErwENkxepiLzdTLOjz6J3DSgwxMxSRAE.XmUq7G318AMCGYbSgDv_gICJz3vilgydngc3GcJckN6aEfqScffhXD1N4gqrUCcuANUr7QhGurJ0ChyQmYBVQoEqLIGK1ZK9yvqJFthOIvmKd6S1r2c3sOxZlVyOzKiwBlBUpg8KaRw1IbGgj4FxCJj0KZpNO8GhTSs0WVZMPJwnSO_MkTJlFMp56M5HZSbUbS57v.QJlwD8tMNxI04HdVnDWbZvTg35BwSkYEjaFoYYN3QPExmQneoXtKNXgttMJ__BC45uwzzInBL6YcqT0KRbVe X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BD597DA.7000002@ieca.com> Date: Mon, 26 Apr 2010 09:40:42 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Charlie Kaufman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-turner-additional-cms-ri-choices.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-turner-additional-cms-ri-choices-03.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 13:41:09 -0000 Charlie, Thanks for your review. Responses inline. spt Charlie Kaufman 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 proposes a syntax for including OCSP (Online Certificate Status Protocol) and SCVP (Server-Based Certificate Validation Protocol) response within a RevocationInfoChoices data structure defined in CMS. Previously, while that data structure was designed to be extensible, the only defined syntax was for the inclusion of CRLs (Certificate Revocation Lists). > > The document proposes the most natural way to embed the new information and I found no problems with the spec. > > My only concern is with regard to the last line of Security Considerations: "It is a matter of local policy whether these encapsulated SCVP responses are considered valid by another entity." Even though the SCVP responses are signed by the SCVP server, there is no way for the verifying entity to determine whether the nonces inside the response are fresh, therefore it's not obvious under what circumstances it would be safe for the verifying entity to trust that response. If there were a timestamp inside the response, that would help. I don't know whether there is or whether there is a similar issue with OCSP. The "these encapsulated SCVP responses" refers to the locally stored unprotected and unauthenticated responses from the first line of that paragraph: To locally store unprotected or authenticated SCVP responses, an entity can encapsulate the unprotected or authenticated SCVP response in a SignedData. It's legal for SCVP to return unsigned and authenticated responses (the server might do this because they use TLS between the client and the server) and then for the client to apply a SignedData and store it for it's own use. So, we're just pointing out that though the client might accept these as valid chances are nobody else is going to accept them as valid. If I change the paragraph as follows is it clearer? OLD: To locally store unprotected or authenticated SCVP responses, an entity can encapsulate the unprotected or authenticated SCVP response in a SignedData. It is a matter of local policy whether these encapsulated SCVP responses are considered valid by another entity. NEW: To locally store unprotected or authenticated SCVP responses, a client can encapsulate the unprotected or authenticated SCVP response in a SignedData. It is a matter of local policy whether these SCVP responses that are encapsulated and signed by the client are considered valid by another entity. > I am surprised that IANA is not expected to track and post the object identifiers defined in this RFC below an arc that IANA delegated to the PKIX working group, but the IANA considerations section seems to imply this. I used to put "none" because the OIDs were already registered, but then somebody said that I needed to explain where I got the OIDs and what IANA had to do now and in the future. I decided to follow the lead of RFC 5280. Note that similar text was also used in RFC 5753, 5755, and drafts that have recently been put through to the IESG. > Some typos (both in section 4): > > posses -> possess > "client can retain" -> "client to retain" Both fixed. From charliek@microsoft.com Mon Apr 26 09:39:10 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A9AC3A6A2D; Mon, 26 Apr 2010 09:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wW+c2i0xVuKz; Mon, 26 Apr 2010 09:39:09 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 35E883A67D7; Mon, 26 Apr 2010 09:39:09 -0700 (PDT) Received: from TK5EX14CASC132.redmond.corp.microsoft.com (157.54.52.17) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 26 Apr 2010 09:38:57 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.187]) by TK5EX14CASC132.redmond.corp.microsoft.com ([157.54.52.17]) with mapi; Mon, 26 Apr 2010 09:38:56 -0700 From: Charlie Kaufman To: Sean Turner Thread-Topic: Secdir review of draft-turner-additional-cms-ri-choices-03.txt Thread-Index: AcrlA3NMIZNH4zjOTC66YANKWweFogAfUmEAAAjrOdA= Date: Mon, 26 Apr 2010 16:38:54 +0000 Message-ID: References: <4BD597DA.7000002@ieca.com> In-Reply-To: <4BD597DA.7000002@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-turner-additional-cms-ri-choices.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-turner-additional-cms-ri-choices-03.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 16:39:10 -0000 I guess what I was looking for was some guidance as to under what circumsta= nces it would be reasonable for a verifier to trust such an SCVP response, = since it could have been trivially forged by the sender. I guess it could b= e taken as an assertion by the sender that the sender verified the status o= f the certificates before sending on the message, and so if the sender were= judged sufficiently trustworthy the certificates might be believed on that= basis. But the intricacies of who is trusting who for what are sufficientl= y subtle that it might deserve explicit mention. I don't remember SCVP or O= CSP well enough to know whether there is an asserted timestamp associated w= ith any of these signatures; if so, that might also be relevant to a trust = decision. I don't feel strongly about this, and don't want to make trouble. When I'm = reviewing a spec that is "just fine", I try to find the most significant ar= ea for possible elaboration by way of saying I don't believe there are any = issues more significant than this "nit". --Charlie -----Original Message----- From: Sean Turner [mailto:turners@ieca.com]=20 Sent: Monday, April 26, 2010 6:41 AM To: Charlie Kaufman Cc: secdir@ietf.org; iesg@ietf.org; draft-turner-additional-cms-ri-choices.= all@tools.ietf.org Subject: Re: Secdir review of draft-turner-additional-cms-ri-choices-03.txt Charlie, Thanks for your review. Responses inline. spt Charlie Kaufman wrote: > I have reviewed this document as part of the security directorate's=20 > ongoing effort to review all IETF documents being processed by the=20 > IESG. These comments were written primarily for the benefit of the=20 > security area directors. Document editors and WG chairs should treat=20 > these comments just like any other last call comments. >=20 > This document proposes a syntax for including OCSP (Online Certificate St= atus Protocol) and SCVP (Server-Based Certificate Validation Protocol) resp= onse within a RevocationInfoChoices data structure defined in CMS. Previous= ly, while that data structure was designed to be extensible, the only defin= ed syntax was for the inclusion of CRLs (Certificate Revocation Lists). >=20 > The document proposes the most natural way to embed the new information a= nd I found no problems with the spec. >=20 > My only concern is with regard to the last line of Security Consideration= s: "It is a matter of local policy whether these encapsulated SCVP response= s are considered valid by another entity." Even though the SCVP responses a= re signed by the SCVP server, there is no way for the verifying entity to d= etermine whether the nonces inside the response are fresh, therefore it's n= ot obvious under what circumstances it would be safe for the verifying enti= ty to trust that response. If there were a timestamp inside the response, t= hat would help. I don't know whether there is or whether there is a similar= issue with OCSP. The "these encapsulated SCVP responses" refers to the locally stored unprot= ected and unauthenticated responses from the first line of that paragraph: To locally store unprotected or authenticated SCVP responses, an entity can= encapsulate the unprotected or authenticated SCVP response in a SignedData= . It's legal for SCVP to return unsigned and authenticated responses (the ser= ver might do this because they use TLS between the client and the server) and then for the client to apply a SignedData and store it for it's= own use. So, we're just pointing out that though the client might accept = these as valid chances are nobody else is going to accept them as valid. I= f I change the paragraph as follows is it clearer? OLD: To locally store unprotected or authenticated SCVP responses, an entity can encapsulate the unprotected or authenticated SCVP response in a SignedData. It is a matter of local policy whether these encapsulated SCVP responses are considered valid by another entity. NEW: To locally store unprotected or authenticated SCVP responses, a client can encapsulate the unprotected or authenticated SCVP response in a SignedData. It is a matter of local policy whether these SCVP responses that are encapsulated and signed by the client are considered valid by another entity. > I am surprised that IANA is not expected to track and post the object ide= ntifiers defined in this RFC below an arc that IANA delegated to the PKIX w= orking group, but the IANA considerations section seems to imply this. I used to put "none" because the OIDs were already registered, but then som= ebody said that I needed to explain where I got the OIDs and what IANA had = to do now and in the future. I decided to follow the lead of RFC 5280. No= te that similar text was also used in RFC 5753, 5755, and drafts that have = recently been put through to the IESG. > Some typos (both in section 4): >=20 > posses -> possess > "client can retain" -> "client to retain" Both fixed. From dharkins@lounge.org Mon Apr 26 12:51:05 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 550C43A69EE; Mon, 26 Apr 2010 12:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.596 X-Spam-Level: X-Spam-Status: No, score=-3.596 tagged_above=-999 required=5 tests=[AWL=-0.531, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8h9gYL7CL-s; Mon, 26 Apr 2010 12:51:03 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 397653A69C2; Mon, 26 Apr 2010 12:51:03 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 75E521022404C; Mon, 26 Apr 2010 12:50:51 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 26 Apr 2010 12:50:51 -0700 (PDT) Message-ID: <6a634030770e19d07b9dd79ab408bd37.squirrel@www.trepanning.net> In-Reply-To: <69BB892A-4D41-4B39-8641-4CEEA19F9F1B@mit.edu> References: <142c29cbb5f6f54edc203861e7c6ac7b.squirrel@www.trepanning.net> <69BB892A-4D41-4B39-8641-4CEEA19F9F1B@mit.edu> Date: Mon, 26 Apr 2010 12:50:51 -0700 (PDT) From: "Dan Harkins" To: "Philip Zimmermann" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: secdir@ietf.org, draft-zimmermann-avt-zrtp.all@tools.ietf.org, iesg@ietf.org Subject: Re: [secdir] secdir review of draft-zimmermann-avt-zrtp-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 19:51:05 -0000 Hi Phil, That makes sense. I guess that addresses the last of my comments then (the previous ones were resolved over the phone). Thanks! Dan. On Sat, April 24, 2010 2:22 pm, Philip Zimmermann wrote: > Dan, thank you for reviewing our draft. It's great to get comments from > someone who understands hash functions so well. > > When we talked on the phone, I clarified the fact that we already use hash > commits to address some of the concerns you raised below. > > I have adjusted our computations of srtps and ZRTPSess to use KDFs more > effectively, because of our conversation. This will be reflected in ZRTP > draft 18. > > Your reference to Hugo's paper was most helpful. Because of this, I read > his paper, and called Lily Chen at NIST to discuss how NIST would use > Hugo's ideas in the future. She said NIST plans to update SP800-56A to > address this. As it stands, we are using the current version of SP800-56A > to achieve strict NIST compliance to facilitate FIPS-140 validation > testing. > > Regards, > Phil > > > > On Mar 30, 2010, at 1:22 PM, Dan Harkins wrote: > >> >> Hi, >> >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should treat >> these comments just like any other last call comments. >> >> This draft defines a Diffie-Hellman based key exchange to generate >> a session key to use with SRTP. It prevents a man-in-the-middle attack >> against the Diffie-Hellman key exchange without requiring traditional >> authentication. It does not require use of a PKI. >> >> There are three things I think the ADs should take a look at: having >> the protocol resist a small sub-group attack, use of the "auxsecret", >> and >> the hashing mishmash. All are described below. >> >> The MitM attack is thwarted by using a short authentication string >> (SAS) >> that is presented to users on each side of the ZRTP exchange to be read >> and verbally compared. >> >> An immediate concern with such an approach is that it might enable a >> small sub-group attack against the Diffie-Hellman exchange that would >> be undetectable by verification of the SAS. An attacker could take an >> element of small order, f, and create pvi' = pvi^f modp and >> pvr' = pvr^f mod p and the shared secret, DHResult', would be confined >> to >> the small group. The SAS would verbally verify and the two parties would >> continue unaware of the attack. But the DH shared secret is subsequently >> used (indirectly) in a hash which fixes it and exposes it to the MitM, >> which can run through the values in the small sub-group to determine >> DHResult' and then attack the SRTP connection. >> >> The draft specifies support for a Diffie-Hellman domain parameter set >> using a safe prime (from RFC 3526) which would prevent such an attack >> but it seems that the protocol should be secure in and of itself and not >> rely on external safeguards. I recommend sections 4.4.1.2 and 4.4.1.3 >> define an additional processing step to ensure pvi and pvr are not in >> a small sub-group. For a safe-prime this can be viewed as a "belt and >> suspenders" approach, but I don't see why ZRTP couldn't be used in the >> future with other domain parameter sets which may not be based on safe >> primes and therefore such a check would be vital. >> >> The draft has a clever shared secret state matching algorithm to use >> secrets from a cache of state associated with a peer. One of these is >> called "auxsecret", as described in section 4.3.1: >> >> "the auxsecret shared secret may be manually provisioned in other >> application-specific ways that are out-of-band, such as computed from >> a hashed pass phrase by prior agreement between the two parties. Or >> it may be a family key used by an institution that the two parties >> both >> belong to." >> >> If one does not have an "auxsecret" configured a random value is used in >> its field during the ZRTP exchange. If one does have an "auxsecret" >> though >> it does not appear to change. >> >> Traffic analysis, therefore, would tell an attacker whether an >> "auxsecret" is being used or not. If one is, an off-line dictionary >> attack >> might be possible if the "auxsecret" is being used per section 4.3.1 (if >> it is a "family key used by an institution" then every member of the >> institution would use the same "auxsecret" and that could also be easily >> detected). >> >> I recommend that the "auxsecret" be updated in the cache in section >> 4.6.1 so that it is different with a subsequent run of the protocol. If >> that logistically isn't possible then perhaps hash rs1 or rs2 with it >> in 4.3.1 to produce "auxsecretIDi" and "auxsecretIDr". Since there is a >> matching algorithm for r1 and r2 then it might be necessary to have two >> "auxsecretIDi" and two "auxsecretIDr", one hashed with r1 and one with >> r2. The cost is a little extra space but the benefit seems worth it. >> >> There is a confusing mix of hashing, HMACing, and KDFing. In section >> 4.4.1.4 a secret value s0 is derived using the KDF technique from >> SP800-56A, which is not of the keyed variety, it just uses a hash >> function >> in counter mode. But if a preshared key is used then section 4.4.2.4 >> derives s0 with an HMAC-based KDF based on SP800-108. This value, s0, >> is then used to derive the SRTP session key, the SAS, and various >> encryption and integrity protection keys using the HMAC-based, SP800-108 >> version of a KDF. When a session is terminated all keys are destroyed >> except ZRTPSess which is replace by a hash of itself. But it was >> originally derived by a keyed KDF. This seems unnecessarily complex and >> would make this protocol very difficult to analyze. >> >> There has been much discussion on the CFRG list about how the output >> of a hash function is too structured to use the key to an HMAC (see >> Hugo Krawczyk's HKDF draft). Whether the SP800-56A hash-style KDF is >> good or whether the SP800-108 keyed HMAC-style KDF is good is a debate >> for another forum but I think this draft should choose one and stick to >> it. Keys derived from a hash function should not be used as keys to >> an HMAC and keys derived from an HMAC-based KDF should not be replaced >> with a simple hash of themselves. >> >> Editorial nits: >> >> * sections 4.4.1.1 and 4.4.1.2 mention the "width of the DH prime". >> How about "bit-length of the DH prime" instead? >> * section 4.4.1.1 mentions ECDH but then goes on to specify the >> finite field (MODP) version of the exchange. I suggest adding an >> example of ECDH in 4.4.1.1 and 4.4.1.2. >> >> regards, >> >> Dan. >> >> > > ------------------------------------------------ > Philip R Zimmermann prz@mit.edu > (spelled with 2 n's) http://philzimmermann.com > tel +1 831 425-7524 http://zfone.com > > > > > From yaronf.ietf@gmail.com Mon Apr 26 12:52:49 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BA093A69EE; Mon, 26 Apr 2010 12:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CPVYZprrhJZ; Mon, 26 Apr 2010 12:52:48 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id B08223A69C2; Mon, 26 Apr 2010 12:52:47 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so470367fgb.13 for ; Mon, 26 Apr 2010 12:52:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:content-type :date:message-id:mime-version:x-mailer:content-transfer-encoding; bh=F2QZqa0vqEzZ76HiyJCudb+M2HjCjuqdmug+v5lS0pE=; b=F23NMZIAWP8Xoe2KBe7fkmkcorjRTDiP37roCkz1b0HD8Uk/qMSC9xNq5rfsX8vtf/ jcCG+n/oqvCEjmFt2qkQX1jkwOhKl+4mnKhR6cnspxtEfpvyE0xrKGQFKB625JwEM5Yg ++JZBUsb9HUydonyApHPzN2NrzssS2YN/puVo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; b=p/fhJjw/k44ZbYwwHdN5h26rCgV3wyAteNFVKoxOBrbYWbI2tda018SaVqEc4BdtsI bS34+EoSr6rJ73wpsWFwOokKMP/OVKdXIZN9O1TmcbfNUdzoceRShvlOmq1KceKux6gE 1P+ODnn5CR06Q7YV7I0DdlsYc9Ye1rVgndtDM= Received: by 10.87.69.29 with SMTP id w29mr3015578fgk.35.1272311549014; Mon, 26 Apr 2010 12:52:29 -0700 (PDT) Received: from [10.0.0.3] (bzq-79-181-18-85.red.bezeqint.net [79.181.18.85]) by mx.google.com with ESMTPS id 31sm5101566fkt.19.2010.04.26.12.52.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 26 Apr 2010 12:52:28 -0700 (PDT) From: Yaron Sheffer To: iesg@ietf.org, secdir@ietf.org, Paul Hoffman Content-Type: text/plain; charset="UTF-8" Date: Mon, 26 Apr 2010 22:52:22 +0300 Message-ID: <1272311542.2347.64.camel@yaronf-linux> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Subject: [secdir] SecDir review of draft-hoffman-tls-master-secret-input-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 19:52:49 -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. General Having followed the discussion on the TLS and then the IETF mailing lists, I initially thought that this draft is harmless, while its companion draft draft-hoffman-tls-additional-random-ext-01 (ARE) is controversial. Having reread this draft, I now think there is no value in reviewing them separately. This draft does not mention ARE (although it should), but its sole raison d'etre is that other draft. In other words, they should be viewed as one proposal and, given that there is widespread criticism of the utility of ARE, I strongly recommend that both should be published as Experimental (rather than Proposed Standard). Although the introduction does mention crypto binding, this document is clearly NOT about channel binding. CB is not mentioned as a motivation, and I don't see where this extension would add value for channel binding, compared to the existing Finished messages. Details - Quoting from TLS 1.2: "In general, the specification of each extension type needs to describe the effect of the extension both during full handshake and session resumption." I think a similar sentence should be included here, and extensions should explicitly define their behavior with respect to MS calculation in the case of session resumption. - Sec. 1: although this may be trivial, we should still say that only extensions that are understood by both peers participate in the calculation. - I don't understand why the extensions are sorted by type number, instead of taken directly from the message, i.e. in the order they appear there. But I seem to remember this has already been hashed out on the list. - The notation in Sec. 2 is confusing: it is unclear whether the MS input can be computed, or whether it should appear explicitly in the extension fields in the messages. The notation ClientHello.additional_ms_input implies the latter, but this is not spelled out. If computed, the additional MS input should not necessarily be associated with the Client/Server Hello message. It could simply be a shared value common to both peers. - Given that this extension is intended to deal with faulty RNGs and presumably less than perfect PRFs, I think the simple concatenation of the input byte strings may be too easy to attack, if the extensions are variable length. For example, if additional MS input 1 (AMSI1) is "1234" and AMSI2="56", an attacker can play with the client-side extensions to achieve AMSI1="12" and AMSI2="3456", resulting in the same MS. One way to harden the computation is by adding a fixed delimiter between inputs, e.g. "/". - Sec. 3: "The additional master secret input may have no entropy" - this seems to negate the only justification that was given for this protocol extension. - Sec. 4: although the text is formally correct, it should still reference the ARE draft. In fact, if this section is planned to go away, the right place for this reference appears to be the Introduction. From Nicolas.Williams@oracle.com Mon Apr 26 14:03:14 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B6BF28C17C; Mon, 26 Apr 2010 14:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.062 X-Spam-Level: X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[AWL=-1.878, BAYES_40=-0.185, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMCSV2IrENxU; Mon, 26 Apr 2010 14:03:13 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 258F028C114; Mon, 26 Apr 2010 14:03:13 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3QL2u7o014736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Apr 2010 21:02:58 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3QIIpNC026056; Mon, 26 Apr 2010 21:02:54 GMT Received: from abhmt016.oracle.com by acsmt354.oracle.com with ESMTP id 210397971272315713; Mon, 26 Apr 2010 14:01:53 -0700 Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Apr 2010 14:01:52 -0700 Date: Mon, 26 Apr 2010 16:01:48 -0500 From: Nicolas Williams To: Yaron Sheffer Message-ID: <20100426210146.GC10389@Sun.COM> References: <1272311542.2347.64.camel@yaronf-linux> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1272311542.2347.64.camel@yaronf-linux> User-Agent: Mutt/1.5.20 (2010-03-02) X-Auth-Type: Internal IP X-Source-IP: rcsinet15.oracle.com [148.87.113.117] X-CT-RefId: str=0001.0A090209.4BD5FF82.011E:SCFMA4539811,ss=1,fgs=0 Cc: Paul Hoffman , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-hoffman-tls-master-secret-input-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 21:03:14 -0000 On Mon, Apr 26, 2010 at 10:52:22PM +0300, Yaron Sheffer wrote: > Having followed the discussion on the TLS and then the IETF mailing > lists, I initially thought that this draft is harmless, while its > companion draft draft-hoffman-tls-additional-random-ext-01 (ARE) is > controversial. Having reread this draft, I now think there is no value > in reviewing them separately. This draft does not mention ARE (although > it should), but its sole raison d'etre is that other draft. In other > words, they should be viewed as one proposal and, given that there is > widespread criticism of the utility of ARE, I strongly recommend that > both should be published as Experimental (rather than Proposed > Standard). IMO draft-hoffman-tls-master-secret-input-01 is useful as a tool to add channel binding [RFC5056] to TLS. I'm not sure that there ever will be any uses for channel binding in TLS (re-negotiation, now that it's fixed, does something like channel binding internally, but that's not relevant here). So I'm inclined to agree that draft-hoffman-tls-master-secret-input is useless at this time. ARE is definitely controversial, and possibly harmful. > Although the introduction does mention crypto binding, this document is > clearly NOT about channel binding. CB is not mentioned as a motivation, > and I don't see where this extension would add value for channel > binding, compared to the existing Finished messages. Indeed, Paul reject CB as a use for draft-hoffman-tls-master-secret-input early on. I don't understand why, exactly, other than the fact that there's no need in sight to bind TLS to other channels -- but Paul did not argue as much, IIRC. > - Sec. 1: although this may be trivial, we should still say that only > extensions that are understood by both peers participate in the > calculation. Good point. > - I don't understand why the extensions are sorted by type number, > instead of taken directly from the message, i.e. in the order they > appear there. But I seem to remember this has already been hashed out on > the list. As long as there's a canonical order... > - The notation in Sec. 2 is confusing: it is unclear whether the MS > input can be computed, or whether it should appear explicitly in the > extension fields in the messages. The notation > ClientHello.additional_ms_input implies the latter, but this is not > spelled out. If computed, the additional MS input should not necessarily > be associated with the Client/Server Hello message. It could simply be a > shared value common to both peers. The extra ms input need not be sent (no extensions for sending them are provided in this I-D). Either both sides agree on what the extra inputs must be, or additional extensions must be specified and used to negotiate what those inputs are. > - Given that this extension is intended to deal with faulty RNGs and > presumably less than perfect PRFs, I think the simple concatenation of > the input byte strings may be too easy to attack, if the extensions are > variable length. For example, if additional MS input 1 (AMSI1) is "1234" > and AMSI2="56", an attacker can play with the client-side extensions to > achieve AMSI1="12" and AMSI2="3456", resulting in the same MS. One way > to harden the computation is by adding a fixed delimiter between inputs, > e.g. "/". I'm very uncomfortable with ARE and the notion that larger randoms are needed here. > - Sec. 3: "The additional master secret input may have no entropy" - > this seems to negate the only justification that was given for this > protocol extension. A CB need not add entropy (think of tls-server-endpoint). > - Sec. 4: although the text is formally correct, it should still > reference the ARE draft. In fact, if this section is planned to go away, > the right place for this reference appears to be the Introduction. Perhaps. Nico -- From kivinen@iki.fi Tue Apr 27 05:13:28 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 903A23A6975; Tue, 27 Apr 2010 05:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.841, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+T0EqvORcMY; Tue, 27 Apr 2010 05:13:26 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id D8B433A6939; Tue, 27 Apr 2010 05:13:24 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o3RCD6a9018904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Apr 2010 15:13:06 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o3RCD4x2001566; Tue, 27 Apr 2010 15:13:04 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19414.54480.856525.140444@fireball.kivinen.iki.fi> Date: Tue, 27 Apr 2010 15:13:04 +0300 From: Tero Kivinen To: Ned Freed In-Reply-To: <01NM95LR5YZ2004042@mauve.mrochek.com> References: <19396.29206.787824.69029@fireball.kivinen.iki.fi> <01NM7KYS0I420000BI@mauve.mrochek.com> <19408.10776.164789.537305@fireball.kivinen.iki.fi> <01NM95LR5YZ2004042@mauve.mrochek.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 49 min X-Total-Time: 49 min Cc: draft-freed-sieve-notary.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-freed-sieve-notary-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 12:13:28 -0000 Ned Freed writes: > > > The same arguments hold for DELIVERBY. If the extension is available, why > > > not just (ab)use it directly? Why bother with a convoluted path through > > > Sieve that will almost certainly leave a much bigger trail? > > > If the relayed status notifications go to the original author instead > > of the sieve filter owner, then the attacker does not need to send > > any emails, the victim attacks himself by sending email to attackers > > address which will then add trace option to the email on the fly. > > Now please explain the significant advantage this provides to an > attacker. It's not like sending emails is hard. (This dicussion is mostly background stuff, and as the new text says that redirect-deliverby uses Sieve owners address as envelope sender address this does not really matter anymore as that alone solves the attack.] Sending emails is not hard, but I have understood that Sieve is supposed to be something that can be safely enabled for any users even when they do not have too much capabilities in the system. For example lets say someone joins some mailing list and then make Sieve filter that will redirect all mails from that mailing list forward to some system using DELIVERBY with trace option. If those status notifications (lets say there are for example 3 email hops before the email reaches its final destination) go to the original author, this one Sieve user has very easily generated (even perhaps by accident) distributed attack against all mailing list users. Everybody sending email to this list will get 3 DSN notifications back from some hosts on the network which he does not have any idea why he is getting them and unless he really knows how to read email Received headers etc he does not even know who enabled the feature, i.e. who is doing the attack. Yes, the original attacker could do the same thing with procmail or .forward and simple shell script, but I understood one of the reasons for Sieve was that it was supposed to be safer for "normal" people to use it and not cause problems, i.e. it is used in environments where shell access is not provided. Also as the distributed machines sending those DSN notifications are real legal email servers which normally do process emails (in or out) the original sender getting those DSN's does not want to filter them out (or not even all DSN from them machines, as somethings he himself might want to enable DSNs and get DSN reports back from those machines too). The problem is not very big, I agree, but if Sieve is supposed to be system which can safely be given to the "normal" people who are not allowed to get shell access to email systems, then this does offer them new way of causing trouble and harm to other users (i.e. the original sender). This is why I think it is issue which might need to be mentioned here but as I said already the new text which says redirect-deliverby uses Sieve owners address as envelope sender solves all of this already as now Sieve owner can only attack himself... > > Say host A limits DSN notification complately, i.e does not allow them > > at all. Now host A user A sends email to user B on host B whose sieve > > filter adds status notifications (as they are not restricted on host > > B, only on host A) and the status notifications go to original author > > A. Now host A user A will get status notifications even when the host > > A policy forbid requesting them. > > In other words, this is a case where the Sieve policy for requesting > DSNs is more lenient that for submit/SMTP. I agree this is a > security concern, which is why the security considerations section > of the document addresses it. It says: > > Sites which limit the ability > to request success notifications will also need to restrict the ability > to request them using the redirect-dsn extension. > > > Host B cannot know what policy host A has, thus it cannot restrict > > operations. > > Not only can it know, it has to. This is what administrators are for > - to implement consistent policies across hosts. Ok, do my home machine kivinen.iki.fi allow DSN or not? When I send this email to you, is your Sieve filter allowed to add DSNs to this email or not, i.e. do you know whether my outgoing email server allowed me to enable DSNs or not. In general case you do not. I have understood that Sieve is normally run on the receiver end of the email, but perhaps I have misunderstood that. The DSN policy is for the sender end of the email transmission. Very often there is no common adminstration between the sender and the receiver as people DO send cross-domain emails... Again this point has also gone away now when the Sieve owner's address is used as envelope sender as now the machine running Sieve can know the policy to be used. > > > > Also in section 5, it should be made clear that the "bytime" can also > > > > be negative, if the bymode is "notify" and the message is already > > > > pasts is notification time. > > > > > > Unfortunately, RFC 2852 predates the current thinking in email that > > > there's significant semantic difference between submission and > > > relay. My understanding of the purpose of negative by-times is that > > > they are arrived at when a message exceeds the time limit but still > > > needs to be delivered. If there's a justification for having a > > > negative by-time on initial submission I haven't heard it. In fact > > > had RFC 2852 distinguished between submit and relay I suspect it > > > would have disallowed negative by-times in the submit case. > > > I do not thing this is relevant here. > > On the contrary, it's entirely relevant because what we have done by > requiring the resetting of the envelope sender is to effectively > require that these extended redirect be considered as a new > submission, not a relay operation. Ok, that I can agree, but I assumed you were processing these two issues independently and without the first change (i.e. the envelope sender change) this would be different. > > It might be needed if the sieve filter wants to preserve by-time > > values given to it in the beginning. I do not know enough of Sieve to > > know if it is possible, but one use could be using sieve to for > > example limit the by-time to something, i.e. wants to make sure that > > when email is redirected to cellular phone it is delivered before > > certain time (for example before 22:00, because user does not want to > > wake up when cellular phone beeps in the middle of night), unless the > > email already had shorted by-time, in which case it wants to preserve > it. > > The short answer is ths use-case you describe here really isn't feasible > in Sieve, for a bunch of different reasons. > > THe longer answer is that this ends up being infeasible because: > > (1) Sieve doesn't have enough numeric and time computation facilities to > perform the sort of limit operation you describe. And there is not going to be extensions offering such features, like adding and substracting integers and comparing them, and getting the current time? > (2) Even if you could do the calculation, or if, say, there was a related > use-case where limiting the relative value made sense (I confess I cannot > come up with one where it does), most Sieve implementations operate > after final delivery, so copying deliver-by information doesn't really > make sense. For the user who is redirecting this to cellular phone it does make sense. Lets say the email is about meeting that starts at 18:00, and because of this the original deliver-by-time is 18:00, i.e. this email is useless after that time. This email arrives to the users Sieve filter at 14:44, and it is stored to users mail box, and the user's Sieve filter wants to send a copy of that to cellular but add additional limit that it cannot be send after 22:00 (just in case there is some delays there), so user wants to add new deliver-by-time that is going to be 22:00, but as the original had deliver-by-time of 18:00, it would be better to use shorter of those two as even when the email is already delivered to the final destination (users mail box) before the 18:00, the copy sent to be out usually has exactly same meaningful time period as the original email. It does not help the user to get that email to his cellular phone at 20:00 when the meeting is already over. Because of this it does not really matter whether this is final deliver or not as user still would have interest to use the earlier of the two deliver-by-times. (I used absolute deliver-by-time in the example above as it was easier to explain using that, but of course the Sieve filter itself could as easily use the delta time too.) > Actually, no. In the use-case you describe, the goal is to prevent the phone > from ringing after a certain point. That implies that a by-mode of "R" has to > be used, which means no negative by-times are allowed. True. > Moreover, if the original mode was "R", you can copy over a shorter by-time. > But what happens if the mode is "N"? I think in that case you'd want to > ignore the original by-time in order to get sensible behavior. Most likely. Or you just take shorter time and use R in that case too, as if this is copy the email is already delivered to Sieve users mail box, but this is for the Sieve user to decide. Of course all this is also related to where the status notifications are sent. As with the current change the status notifications are always sent to the Sieve owner, so he most likely would be using R always in this setups as this "cellular phone" is supposed to be the way to reach him more quickly than from normal mail box, and N notifications does not really offer any new information for him. > All that said, this use-case makes me wonder if the real error here > is that we aren't providing a way to look at and set by-times as > absolute, rather than relative, time values. I actually start to feel that it might be better option. > > Also I think the Sieve should be able to preserve by-time and envelope > > sender when it redirects email, if it does not ADD new notifications. > > > I.e if someone sends email having by-time saying it needs to be > > delivered during next hour, and the Sieve forwards it to the cellular, > > it would be useful to keep that same time limit there, and it would > > also be nice if the original author still gets the status > > notifications he asked for. > > That's totally outside the purview of this extension, which does not > and cannot deal with the unextended redirect case. Moreover, the > lack of specificity about when Sieve operates - which is both > intentional and essential - makes this a very difficult question to > address in ANY context. Just as one example, you most certainly do > NOT want to try and preserve these things if Sieve is operating in a > user agent weeks after final delivery - which is a perfectly > legitimate and even common situation. Ok. > > If the email is not yet delivered to the local mail box, but is > > redirected to somewhere else by the Sieve then I do consider the email > > to still be in transit, and the time used to run the Sieve should be > > taken in to account. In most cases it does not really matter as > > running it is very fast, but I think it still needs to be counted for. > > Sieve implementations that operate at this point are in fact the exception, > not the rule. So perhaps saying something that when Sieve is run as part of transit then the delta time should be decremented. Btw, this will be automatically taken account if the delta time is converted to absolute deliver-by-time when the email is received and then back to delta time when it is sent forward as part of relay. > > > I think this makes it clear the values are simply passed unchanged > > > to the SMTP/submit server. But if you want to suggest a specific > > > change, that's fine. > > > I think RFC 2852 is very clear that you are supposed to convert that > > DELTA time to absolute time upon receipt of email, and then convert it > > back to delta time when you send email forward: > > Yes, I'm well aware of what it says, and why. I carpool to work > every day with the guy who wrote it. The reason for this text is so > that implementations won't carelessly lose track of some amount of > elapsed time. But again, this only works while messages are in > transit. I'm not convinced there's an issue worth addressing in the > Sieve case. Not even those exceptional cases where Sieve is run as part of email transit, not as part of final delivery? > > Hmm.. actually it would be more accordingly to the RFC2852 to not give > > out the delta time to Sieve, but instead the deliver-by-time (which is > > locale-specific absolute time instead), and leave the processing of > > negative and positive delta times for the email service instead of > > Sieve filter. > > Given how Sieve is situated in regards to final delivery, I once > again disagree that RFC 2852 provides justification for such a > change. THat said, I think the change is worth considering for other > reaons, first that Sieve is equipped to deal with with absolute time > values better than it is with relative ones, and second, that there > are quite a few reaonsable use-cases for setting an absolute > :by-time. > > But this is a somwwhat complex topic, and this message is already > very long, so I'm going to defer discussing this to a separate > message. Ok. -- kivinen@iki.fi From weiler+secdir@watson.org Tue Apr 27 07:54:04 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C28EC3A6B8E for ; Tue, 27 Apr 2010 07:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJ36lI5Mk4p4 for ; Tue, 27 Apr 2010 07:54:03 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id B1FE93A6B5A for ; Tue, 27 Apr 2010 07:47:58 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o3REljmq068456 for ; Tue, 27 Apr 2010 10:47:45 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o3RElj6K068453 for ; Tue, 27 Apr 2010 10:47:45 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 27 Apr 2010 10:47:45 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Tue, 27 Apr 2010 10:47:46 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 14:54:04 -0000 Yes, you just saw an assignment message on Sunday. Enough has changed that it seemed best to send another already. And I'm traveling on Thursday and Friday, so you may not be getting another such message week. Glen Zorn is next in the rotation. Documents on the telechat agenda typically have a last call end date before the date shown below; reviews by the end of last call are typically more appreciated by the doc editors. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2010-05-06 Reviewer Deadline Draft Rob Austein T 2010-05-04 draft-denenberg-mods-etc-media-types-01 Dave Cridland T 2010-05-04 draft-ietf-isms-dtls-tm-10 Alan DeKok T 2010-05-04 draft-ietf-netmod-yang-12 Tobias Gondrom TR2010-05-04 draft-mattsson-mikey-ticket-03 Chris Newman T 2010-05-04 draft-ietf-ipsecme-aes-ctr-ikev2-07 Eric Rescorla T 2010-05-04 draft-ietf-keyprov-dskpp-10 Vincent Roca T 2010-05-04 draft-ietf-keyprov-pskc-05 Yaron Sheffer TR2010-05-04 draft-ietf-ipfix-mediators-problem-statement-09 Tina TSOU T 2010-05-04 draft-ietf-mext-flow-binding-06 Tom Yu T 2010-05-04 draft-ietf-ipsecme-ikev2bis-10 For telechat 2010-05-20 David McGrew T 2010-05-18 draft-turner-encryptedkeypackagecontenttype-algs-01 For telechat 2010-06-03 Tom Yu TR2010-06-01 draft-krishnan-v6ops-teredo-update-06 Last calls and special requests: Alan DeKok 2009-10-01 draft-ietf-enum-enumservices-transition-05 Steve Hanna None draft-ietf-tsvwg-ecn-tunnel-08 Love Hornquist-Astrand 2010-04-07 draft-ietf-eai-mailinglist-06 Jeffrey Hutzelman 2010-04-06 draft-lawrence-sipforum-user-agent-config-01 David McGrew 2010-03-10 draft-ietf-ecrit-framework-10 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Catherine Meadows None draft-ietf-tsvwg-dtls-for-sctp-05 Magnus Nystrom 2010-04-21 draft-ietf-mpls-tp-framework-11 Hilarie Orman 2010-04-26 draft-hethmon-mcmurray-ftp-hosts-11 Stefan Santesson 2010-04-23 draft-reschke-webdav-post-06 Carl Wallace 2010-05-06 draft-ietf-mpls-tp-survive-fwk-05 Sam Weiler 2008-08-13 draft-chown-v6ops-rogue-ra-03 Sam Weiler 2010-05-19 draft-hoffman-tls-additional-random-ext-01 Brian Weis 2010-05-19 draft-sheffer-emu-eap-eke-06 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-04 Nico Williams 2010-05-10 draft-ietf-opsec-routing-protocols-crypto-issues-04 Tom Yu 2010-05-10 draft-ietf-avt-rtcp-guidelines-03 Kurt Zeilenga 2010-05-11 draft-ietf-radext-tcp-transport-06 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-06 Larry Zhu 2010-03-20 draft-ietf-sip-domain-certs-06 Larry Zhu 2010-05-24 draft-santoni-media-type-tsd-00 From hilarie@purplestreak.com Tue Apr 27 09:18:29 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 124643A6838; Tue, 27 Apr 2010 09:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KuWDb8kpC+R; Tue, 27 Apr 2010 09:18:28 -0700 (PDT) Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) by core3.amsl.com (Postfix) with ESMTP id 6B1AE3A67EA; Tue, 27 Apr 2010 09:18:26 -0700 (PDT) Received: from mx01.mta.xmission.com ([166.70.13.211]) by out02.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1O6nUD-0006kO-BU; Tue, 27 Apr 2010 10:18:14 -0600 Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=fermat.rhmr.com) by mx01.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1O6nU7-0007DE-TT; Tue, 27 Apr 2010 10:18:13 -0600 Received: from fermat.rhmr.com (localhost [127.0.0.1]) by fermat.rhmr.com (8.14.3/8.14.3/Debian-9ubuntu1) with ESMTP id o3RGIDQe026945; Tue, 27 Apr 2010 10:18:13 -0600 Received: (from ho@localhost) by fermat.rhmr.com (8.14.3/8.14.3/Submit) id o3RGI9Fp026926; Tue, 27 Apr 2010 10:18:09 -0600 Date: Tue, 27 Apr 2010 10:18:09 -0600 Message-Id: <201004271618.o3RGI9Fp026926@fermat.rhmr.com> X-Authentication-Warning: fermat.rhmr.com: ho set sender to hilarie using -f From: "Hilarie Orman" To: secdir@ietf.org X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx01.mta.xmission.com; ; ; ip=166.70.57.249; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-DomainKey: sender_domain=alum.mit.edu; ; ; sender=ho@alum.mit.edu; ; ; status=error X-SA-Exim-Connect-IP: 166.70.57.249 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa04 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;secdir@ietf.org X-Spam-Relay-Country: X-SA-Exim-Version: 4.2.1 (built Thu, 25 Oct 2007 00:26:12 +0000) X-SA-Exim-Scanned: Yes (on mx01.mta.xmission.com) Cc: phethmon@hethmon.com, robmcm@microsoft.com, iesg@ietf.org Subject: [secdir] review of draft-hethmon-mcmurray-ftp-hosts-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hilarie Orman List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 16:18:29 -0000 Security review of File Transfer Protocol HOST Command draft-hethmon-mcmurray-ftp-hosts-11 Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This protocol modification adds a command ("HOST") by which the client designates a virtual host. The server will then use an authentication method suitable for that host, much as though a separate FTP server were running for each virtual host. There is a small area of concern surrounding the information contained in the "HOST" command. If the name of the virtual host is sensitive information, then clients should protect it by using encryption when first connecting to the server. Although the document anticipates host names as being publicly available DNS names, that is not necessary, and some organizations will probably use private names. Hilarie From yaronf.ietf@gmail.com Tue Apr 27 13:04:33 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38AD13A6774; Tue, 27 Apr 2010 13:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.273 X-Spam-Level: X-Spam-Status: No, score=-1.273 tagged_above=-999 required=5 tests=[AWL=-0.893, BAYES_00=-2.599, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZLRQlWD8ZKA; Tue, 27 Apr 2010 13:04:32 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id A80263A6988; Tue, 27 Apr 2010 13:04:24 -0700 (PDT) Received: by wyb35 with SMTP id 35so3943428wyb.31 for ; Tue, 27 Apr 2010 13:04:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:content-type :date:message-id:mime-version:x-mailer:content-transfer-encoding; bh=0NUWIFptgk95Krykx/LJJqfayQifnSOjP+xZm1Ob4qE=; b=tWq8vxCfoc4MiRdlaZ7N747vyoXaoBNwHI3T46TKxIg4KsEjKX1Qh3Aoth0bQYh8kf 6rEF4MrwRAaIw7zeYgO65RoceWb/w4aLd8xkQ1ZwGnBimDM3RNeaJqkJ+NnrQSf8KqZo mojGLNlJwvUvNrsYnMocxJmLhW4tRqLZGuXzo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; b=kB8IDa2JAvg2y5TtcocUrQyAz5zslRcYW3C/ofAiFgmRZxsLcxU5D7Q5Ifj79o+RKc NEMAv/S+tgGlextKDPYlTIgzZTdbkD4Vm2mOU6GcJi1xinbCccxN2d7beqVjNwQ3o1Mh soh2rXc2FrEkNX/xuIHvYtuxpL01t8895Gcz0= Received: by 10.216.90.133 with SMTP id e5mr2388342wef.23.1272398648492; Tue, 27 Apr 2010 13:04:08 -0700 (PDT) Received: from [10.0.0.3] (bzq-79-181-18-85.red.bezeqint.net [79.181.18.85]) by mx.google.com with ESMTPS id d75sm310126wek.20.2010.04.27.13.04.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 27 Apr 2010 13:04:07 -0700 (PDT) From: Yaron Sheffer To: iesg , secdir , draft-ietf-ipfix-mediators-problem-statement.all@tools.ietf.org Content-Type: text/plain; charset="UTF-8" Date: Tue, 27 Apr 2010 23:04:00 +0300 Message-ID: <1272398640.2557.7.camel@yaronf-linux> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Subject: [secdir] SecDir repeat review of draft-ietf-ipfix-mediators-problem-statement-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 20:04:33 -0000 . Draft -09 addresses all my earlier review comments on -08, http://www.ietf.org/mail-archive/web/secdir/current/msg01541.html. Thanks, Yaron From Sandra.Murphy@cobham.com Tue Apr 27 14:00:25 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51D2C3A6A6C for ; Tue, 27 Apr 2010 14:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.832 X-Spam-Level: X-Spam-Status: No, score=-0.832 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlxIkX5QDnjw for ; Tue, 27 Apr 2010 14:00:24 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 115E33A6A53 for ; Tue, 27 Apr 2010 14:00:23 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o3RL06K8006661; Tue, 27 Apr 2010 16:00:06 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o3RL03lp024713; Tue, 27 Apr 2010 16:00:04 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.132]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Apr 2010 16:52:36 -0400 Date: Tue, 27 Apr 2010 16:52:36 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Christer Holmberg In-Reply-To: Message-ID: References: <4BCD7169.9020701@cs.tcd.ie> <4BCDAB7A.7080208@nostrum.com> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 27 Apr 2010 20:52:36.0849 (UTC) FILETIME=[91520E10:01CAE64B] Cc: "secdir@ietf.org" , "sipcore-chairs@tools.ietf.org" , "draft-ietf-sipcore-info-events@tools.ietf.org" , Adam Roach Subject: Re: [secdir] secdir review of draft-ietf-sipcore-info-events X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 21:00:25 -0000 On Mon, 26 Apr 2010, Christer Holmberg wrote: > > Hi Sandy, > >>>> This specification sort-of provides a SIP-based tunnel for >>>> application protocols. >>>> >>>> 1: What prevents (or allows detection of) insertion of bogus Info >>>> Package specifications? (e.g. by a proxy). If nothing, then why is >>>> this ok? >>>> >>> >>> This is the general way that SIP works, and it applies to all the SIP >>> header fields. It's not great, but proxies are implicitly >>> trusted to do the right thing. If it's a problem for INFO, then it's a problem >>> for everything that has ever used or will ever use SIP. >> >> Aye, and therein lies the rub. ;-} >> >> In my usual broken-record nagging, insider failures are hard >> to protect against, sometimes impossible. But knowing just >> how bad things might get (how much damage an insider failure >> could potentially cause) might be a good idea. It might >> inspire people to put strong operational controls in place. >> Buy a bigger liability policy. Abandon all hope ye who enter >> here. etc. >> >> When I made some similar comments on a different SIP draft a >> while back, there was a discussion on the sip wg list of >> writing down somewhere what the wg chair called the "please >> molest me" security model. I didn't follow the discussion to >> the end, so I don't know if that ever got past the good >> intention stage and if so where the written down text ended up. > > I guess Adam can comment on the status about that. > > However, I see that as a generic work, and not something that should be done in the Info-Events draft. I wasn't intending to comment strictly on the info draft. I was agreeing with Adam's comment that this problem was common to all of SIP. If the sip wg did work or is doing work on cautionary tales about proxies in general, then that work could and should be noted in the info draft. That's the scope of impact on the info draft. --Sandy > > Section 10.10 talks about the usage of some security mechanism in order to protect the data, and I am not sure what more we could say in this draft. > > Regards, > > Christer > From christer.holmberg@ericsson.com Tue Apr 27 23:04:57 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D18B93A6AC5 for ; Tue, 27 Apr 2010 23:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.511 X-Spam-Level: X-Spam-Status: No, score=-4.511 tagged_above=-999 required=5 tests=[AWL=0.599, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlasRVe2qB7y for ; Tue, 27 Apr 2010 23:04:57 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 9503C3A6A26 for ; Tue, 27 Apr 2010 23:04:52 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-b5-4bd7cff65f14 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 2E.39.23532.6FFC7DB4; Wed, 28 Apr 2010 08:04:38 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 28 Apr 2010 08:04:38 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.70]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 28 Apr 2010 08:04:37 +0200 From: Christer Holmberg To: Sandra Murphy Date: Wed, 28 Apr 2010 08:04:36 +0200 Thread-Topic: [secdir] secdir review of draft-ietf-sipcore-info-events Thread-Index: AcrmTKDb4U+hsjmvQzOs2yqAtTsObwAS7naA Message-ID: References: <4BCD7169.9020701@cs.tcd.ie> <4BCDAB7A.7080208@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "secdir@ietf.org" , "sipcore-chairs@tools.ietf.org" , "draft-ietf-sipcore-info-events@tools.ietf.org" , Adam Roach Subject: Re: [secdir] secdir review of draft-ietf-sipcore-info-events X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 06:04:57 -0000 Hi Sandy,=20 >>>>>This specification sort-of provides a SIP-based tunnel for=20 >>>>>application protocols. >>>>> >>>>> 1: What prevents (or allows detection of) insertion of bogus Info=20 >>>>> Package specifications? (e.g. by a proxy). If nothing, then why is=20 >>>>> this ok? >>>>> >>>> >>>> This is the general way that SIP works, and it applies to all the=20 >>>> SIP header fields. It's not great, but proxies are implicitly=20 >>>> trusted to do the right thing. If it's a problem for INFO, then it's=20 >>>> a problem for everything that has ever used or will ever use SIP. >>> >>> Aye, and therein lies the rub. ;-} >>> >>> In my usual broken-record nagging, insider failures are hard to=20 >>> protect against, sometimes impossible. But knowing just how bad=20 >>> things might get (how much damage an insider failure could=20 >>> potentially cause) might be a good idea. It might inspire people to=20 >>> put strong operational controls in place. >>> Buy a bigger liability policy. Abandon all hope ye who enter here.=20 >>> etc. >>> >>> When I made some similar comments on a different SIP draft a while=20 >>> back, there was a discussion on the sip wg list of writing down=20 >>> somewhere what the wg chair called the "please molest me" security=20 >>> model. I didn't follow the discussion to the end, so I don't know if=20 >>> that ever got past the good intention stage and if so where the=20 >>> written down text ended up. >> >> I guess Adam can comment on the status about that. >> >> However, I see that as a generic work, and not something that should be = done in the Info-Events draft. >=20 >I wasn't intending to comment strictly on the info draft. I=20 >was agreeing with Adam's comment that this problem was common=20 >to all of SIP. If the sip wg did work or is doing work on=20 >cautionary tales about proxies in general, then that work=20 >could and should be noted in the info draft.=20 >That's the scope of impact on the info draft. AFAIK the sipcore wg is currently not doing such work. Regards, Christer From stefan@aaa-sec.com Wed Apr 28 02:16:43 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 233BA3A6821 for ; Wed, 28 Apr 2010 02:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.905 X-Spam-Level: X-Spam-Status: No, score=0.905 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_50=0.001, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQ9Bakz3CKpa for ; Wed, 28 Apr 2010 02:16:42 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.112]) by core3.amsl.com (Postfix) with ESMTP id 61A773A68C0 for ; Wed, 28 Apr 2010 02:16:31 -0700 (PDT) Received: from s42.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 19F83295265 for ; Wed, 28 Apr 2010 11:16:21 +0200 (CEST) Received: (qmail 19783 invoked from network); 28 Apr 2010 09:16:17 -0000 Received: from unknown (HELO [192.168.1.3]) (stefan@fiddler.nu@[85.235.2.114]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 28 Apr 2010 09:16:17 -0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Wed, 28 Apr 2010 11:16:16 +0200 From: Stefan Santesson To: , , Message-ID: Thread-Topic: SecDir revirw of draft-reschke-webdav-post-06 Thread-Index: Acrms3RowQqEr07Et0mx5OXmAwiH4w== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3355298177_26142149" Subject: [secdir] SecDir revirw of draft-reschke-webdav-post-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 09:16:43 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3355298177_26142149 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These 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 inherits the security considerations of WebDAV as well as XML= . RFC 4918 clearly identifies that WebDAV, through its nature of providing users with capabilities to change and collect information from web servers, introduces a number of security issues which need to be addressed through means of protected and authenticated communication. Rather than introducing completely new functions to WebDAV, the current draft specifies the meaning existing functions as well as means of discovering server support for this draft. >From this perspective I can=B9t see that this draft introduce new risks that are not already addressed in the security considerations section of this draft or inherited sections form other documents (such as RFC 4918). /Stefan Santesson --B_3355298177_26142149 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable SecDir revirw of draft-reschke-webdav-post-06
I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG.  Thes= e comments were written primarily for the benefit of the security area direc= tors.  Document editors and WG chairs should treat these comments just = like any other last call comments.

This document inherits the security considerations of WebDAV as well as XML= . RFC 4918 clearly identifies that WebDAV, through its nature of providing u= sers with capabilities to change and collect information from web servers, i= ntroduces a number of security issues which need to be addressed through mea= ns of protected and authenticated communication.

Rather than introducing completely new functions to WebDAV, the current dra= ft specifies the meaning existing functions as well as means of discovering = server support for this draft.

>From this perspective I can’t see that this draft introduce new risks= that are not already addressed in the security considerations section of th= is draft or inherited sections form other documents (such as RFC 4918).

/Stefan Santesson --B_3355298177_26142149-- From aland@deployingradius.com Wed Apr 28 06:38:27 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A913C28C14F; Wed, 28 Apr 2010 06:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[AWL=0.553, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y40PzjLv4NFT; Wed, 28 Apr 2010 06:38:26 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 6F6423A6BFF; Wed, 28 Apr 2010 06:36:53 -0700 (PDT) Message-ID: <4BD839E7.4040200@deployingradius.com> Date: Wed, 28 Apr 2010 15:36:39 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: secdir@ietf.org, IESG IESG , draft-ietf-netmod-yang@tools.ietf.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] Secdir review of draft-ietf-netmod-yang-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 13:38: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. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document defines a language used to read and write descriptions of management information. It is not intended to be used within an "on the wire" internet protocol. As such, the usual "on the wire" security issues do not apply. The "Security Considerations" looks OK. I would suggest adding a caution about reading data from untrusted sources. Document readers have a long history of being attacked by malformed documents. e.g.: YANG parsers need to be robust with respect to malformed documents. Reading malformed documents from unknown or untrusted sources could result in an attacker gaining privileges of the user running the YANG parser. In an extreme situation, the entire machine could be compromised. Alan DeKok. From sra@hactrn.net Wed Apr 28 08:01:12 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F7AA3A6B65; Wed, 28 Apr 2010 08:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sblHC+l4gsYl; Wed, 28 Apr 2010 08:01:11 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id BC9413A6B88; Wed, 28 Apr 2010 07:57:32 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 26EC128431; Wed, 28 Apr 2010 14:57:18 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id D230322831; Wed, 28 Apr 2010 10:57:17 -0400 (EDT) Date: Wed, 28 Apr 2010 10:57:17 -0400 From: Rob Austein To: iesg@ietf.org, secdir@ietf.org MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20100428145717.D230322831@thrintun.hactrn.net> Cc: draft-denenberg-mods-etc-media-types.all@tools.ietf.org Subject: [secdir] Review of draft-denenberg-mods-etc-media-types-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 15:01:12 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft is a non-WG standards track submission whose sole purpose is registration of four MIME types for use with XML schemata developed by the (US) Library of Congress. The document has a number of nit-level issues which the sponsoring AD proposes to have fixed at the RFC Editor stage, so I won't elaborate on them here, other than to note that the document includes no Security Considerations section. The MIME type registration templates that make up the body of the document all reference the Security Considerations from RFC 3023, which is a general (and, necessarily, rather vague and alarming) discussion of potential security issues that might be found in any XML document. XML schemata are encoded as XML documents, so this reference is correct, as far as it goes. Nothing about XML schemata in general or these schemata in particular. Just about everything referenced by this document is external to the IETF, it's either a W3C standard, work being done by the Library of Congress, or in the case of the SRU specification, OASIS. It's not obvious to me why this document has been proposed for the IETF standards track, given that MIME type registrations do not appear (as far as I can tell) to require an RFC at all. Informational status might be more appropriate, but I'll leave that up to the IESG. I don't see any security issues with the MIME type registrations per se. I don't know enough about the (non-IETF) protocols sitting behind the proposed MIME types to have an informed opinion on them. The one (non-security) part of this that I don't understand is why a separate MIME types is necessary for each individual schema. This seems weird to me, but perhaps it's just the way things are done over in Apps. I don't consider this a blocking issue, just odd. From new-work-bounces@ietf.org Tue Apr 27 10:30:22 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D78B28C143; Tue, 27 Apr 2010 10:30:22 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BACD43A6A2B; Tue, 27 Apr 2010 10:30:02 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20100427173002.BACD43A6A2B@core3.amsl.com> Date: Tue, 27 Apr 2010 10:30:02 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Wed, 28 Apr 2010 08:30:28 -0700 Subject: [secdir] [New-work] WG Review: SIP Overload Control (soc) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 17:30:22 -0000 A new IETF working group has been proposed in the Real-time Applications and Infrastructure Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, May 4, 2010. SIP Overload Control (soc) --------------------------- Current Status: Proposed Working Group Last Modified: 2010-04-22 Chair(s) TBD Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: General Discussion: sip-overload@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sip-overload Archive: http://www.ietf.org/mail-archive/web/sip-overload/ Description of Working Group: As with any network element, a Session Initiation Protocol (SIP) server can suffer from overload when the number of SIP messages it receives exceeds the number of messages it can process. Overload is said to occur when a SIP server does not have sufficient resources to complete the processing of all incoming SIP messages within the required time. These resources can include CPU, memory, network bandwidth, input/ output, or disk resources. Overload can pose a serious problem for a network of SIP servers. During periods of overload, the goodput (effective application throughput not counting the overhead of retransmission and redundant data) of a network of SIP servers can be significantly degraded. In fact, overload may lead to a situation in which the goodput drops down to zero or a small fraction of the original processing capacity. This is often called congestion collapse. The objective of a SIP overload control mechanism is to enable SIP servers to operate close to their capacity limit during times of overload. The SIP protocol provides a limited mechanism for overload control through its 503 (Service Unavailable) response code and the Retry-After header. However, this mechanism cannot fully prevent overload of a SIP server and it cannot prevent congestion collapse. In fact, its on/off behavior may cause traffic to oscillate and shift between SIP servers and thereby worsen an overload condition. A detailed discussion of the SIP overload problem, the problems with the 503 (Service Unavailable) response code and the Retry-After header and the requirements for a SIP overload control mechanism can be found in RFC5390. The objective of the working group is to develop mechanisms for SIP overload control. The problem domain of SIP overload control can be split into overload control between a user agent and a SIP server and overload control between SIP servers. Any specification developed by the working group needs to clearly specify its scope. A specification also needs to clearly state any limitations, in performance or otherwise, the specified overload control mechanism may have. In particular, the working group shall carefully define the deployment considerations for the effective operation of the specified mechanisms and discuss, for example, when a mechanism requires coordinated deployment and operation (if all servers need to deploy the same mechanism, certain configuration values need to be identical on all servers, etc), when a mechanism can become less effective or ineffective under some conditions, or especially if there are cases when a mechanism can reduce goodput compared to no overload protection. The intent of these considerations is to allow potential deployers to make the best use of these mechanism in their particular networks. The working group will consider two complementary approaches for handling overload situations: - The first mechanism aims at preventing overload in SIP servers by adjusting the incoming load to a level that is acceptable for this server. This mechanism uses implicit and/or explicit feedback to determine when an overload condition occurs in a SIP server and a reduction in load is required. - The second mechanism aims at preventing overload in SIP servers by distributing load control filters to SIP servers that throttle calls based on their source or destination domain, telephone number prefix or for a specific user. Such filters can be used, for example, to throttle calls to a hotline during a ticket-giveaway event. The working group will develop the following deliverables: 1. A document describing key design considerations for a SIP overload control mechanism. 2. A specification for an SIP overload control mechanism based on implicit/explicit feedback. 3. A specification for a SIP load filtering mechanism. Milestones: Sep 2010 Design Considerations to IESG for publication as Informational Dec 2010 Specification for a SIP overload control mechanism based on implicit/explicit feedback to IESG for publication as Proposed Standard May 2011 Specification for a SIP load filtering mechaism to IESG for publication as Proposed Standard _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From ned.freed@mrochek.com Tue Apr 27 16:22:08 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D8093A6A1A; Tue, 27 Apr 2010 16:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.917 X-Spam-Level: X-Spam-Status: No, score=0.917 tagged_above=-999 required=5 tests=[AWL=-1.708, BAYES_50=0.001, DATE_IN_PAST_06_12=1.069, FRT_LITTLE=1.555] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uooE76EblAvt; Tue, 27 Apr 2010 16:22:01 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 3A6803A6946; Tue, 27 Apr 2010 16:21:56 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NMGBIRKTE800IQ3X@mauve.mrochek.com>; Tue, 27 Apr 2010 16:21:36 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NMFVPGA94W008LOQ@mauve.mrochek.com>; Tue, 27 Apr 2010 16:21:30 -0700 (PDT) Message-id: <01NMGBIO7M50008LOQ@mauve.mrochek.com> Date: Tue, 27 Apr 2010 09:39:00 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 27 Apr 2010 15:13:04 +0300" <19414.54480.856525.140444@fireball.kivinen.iki.fi> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <19396.29206.787824.69029@fireball.kivinen.iki.fi> <01NM7KYS0I420000BI@mauve.mrochek.com> <19408.10776.164789.537305@fireball.kivinen.iki.fi> <01NM95LR5YZ2004042@mauve.mrochek.com> <19414.54480.856525.140444@fireball.kivinen.iki.fi> To: Tero Kivinen DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1272410105; bh=txGbebhBuxjN2MzkvFzl64RYCZZW8Mx/QjQRohfdVio=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=f5mJknb5mq4LGKTxdjO+6U8eFLscauLOxE0WAK6aYHB0Z9rCPnGScHLXYcmUZCgZf XiSHWWYd7DqmokkjIXBO4c0gqqn/FgdkPYSGOoasSNNJmVlaQMenjRLU9o1H7m7YPO gdZys71QFlHWdGnHZhQOkqrDdOs44EHG809B4a5c= X-Mailman-Approved-At: Wed, 28 Apr 2010 08:30:28 -0700 Cc: draft-freed-sieve-notary.all@tools.ietf.org, Ned Freed , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-freed-sieve-notary-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 23:22:08 -0000 > Ned Freed writes: > > > > The same arguments hold for DELIVERBY. If the extension is available, why > > > > not just (ab)use it directly? Why bother with a convoluted path through > > > > Sieve that will almost certainly leave a much bigger trail? > > > > > If the relayed status notifications go to the original author instead > > > of the sieve filter owner, then the attacker does not need to send > > > any emails, the victim attacks himself by sending email to attackers > > > address which will then add trace option to the email on the fly. > > > > Now please explain the significant advantage this provides to an > > attacker. It's not like sending emails is hard. > (This dicussion is mostly background stuff, and as the new text says > that redirect-deliverby uses Sieve owners address as envelope sender > address this does not really matter anymore as that alone solves the > attack.] > Sending emails is not hard, but I have understood that Sieve is > supposed to be something that can be safely enabled for any users even > when they do not have too much capabilities in the system. Yes and no. Sieve is specifically designed so that users can be allowed to access it directly without being able to cause adverse impact to the email infrastructure. Just as one example, the language isn't directly Turing-complete, so you cannot write infinite loops of the "10 goto 10" variety in it that will compromise your server by sending it into an infinite evaluation loop. But this doesn't mean you can just provide full and unrestricted access to every Sieve capability and not have any problems. And this is true even if you're talking about Sieve as defined in the base specification with no extensions at all. A compliant basic implementation will provide the redirect action, and nothing prevents me from writing a Sieve containing 100,000 redirects, one right after another, one to each person I want to spam. So every competent Sieve implementation limits the number of redirects a script can perform, just as an SMTP server limits the number of recipients it will accept. (The very close parallel between this case and success DSN/delivery case should be noted.) What most implementations do to address this is to limit the number of redirects allowed in a single Sieve. Typically this limit is set to 5 or so, but it really needs to be a configurable parameter because the needs of different installations in this regard are very different. Moreover, such issues aren't limited to the actions the scripts can take. Consdier the Sieve body test. I can write something like this: require ["body", "variables"]; if header :matches "from" "*a*" {if body :contains "${1}b${2}" {keep;}} if header :matches "from" "*b*" {if body :contains "${1}c${2}" {keep;}} if header :matches "from" "*c*" {if body :contains "${1}c${2}" {keep;}} ... In other words, I can write a script that does an arbitrary number of body searches where the strings being searched for are dependent on the input message in a very complex way that prevents precomputation and therefore forces the Sieve implementtion to perform an arbitrary number of searches of what might easily be a very large amount of text. (Our implementation provides body tests but without the ability to perform variable substititions in the pattern in order to prevent this sort of thing from being done.) What this all translates to is that proper implementation and configuration is still essential. You cannot operate an email system without proper and consistent configuration and the presence or absence of Sieve suppport doesn't change this fact in any way. And while it is nice to talk about a world where such careful configuration of services isn't necessary, email simply wasn't designed that way and you cannot make this happen after the fact. (Indeed, I doubt it would be possible even in a blank slate design, but email is so far away from that it's pointless to even think about.) > For example lets say someone joins some mailing list and then make > Sieve filter that will redirect all mails from that mailing list > forward to some system using DELIVERBY with trace option. If those > status notifications (lets say there are for example 3 email hops > before the email reaches its final destination) go to the original > author, this one Sieve user has very easily generated (even perhaps by > accident) distributed attack against all mailing list users. Everybody > sending email to this list will get 3 DSN notifications back from some > hosts on the network which he does not have any idea why he is getting > them and unless he really knows how to read email Received headers etc > he does not even know who enabled the feature, i.e. who is doing the > attack. And once again, contrast this with an attack where I simply do the same thing by sending a bunch of messages to the SMTP server directly using a problem on my desktop system. No need to wait for the list to cough up the messages, no audit trail showing how I edited my Sieve to make this happen - something that's going to be hard to claim a virus or bot did, no need to worry about the necessary extensions being there, etc. etc. Really, this whole line of argument of yours is at best like worrying about a pinprick when there's a deep stab wound right next to it. > Yes, the original attacker could do the same thing with procmail or > .forward and simple shell script, but I understood one of the reasons > for Sieve was that it was supposed to be safer for "normal" people to > use it and not cause problems, i.e. it is used in environments where > shell access is not provided. The difference between Sieve and procmail or .forward isn't that Sieve is incapable of being abused. It's that Sieve is designed in such a way that you can actually prevent various forms of abuse with proper implementation and configuration. Procmail in particular is impossible to secure in a similar fashion: It's regex-based and it's trivial to write regexes that will consume vast amounts of CPU, and moreover you can construct problematic patterns where their problematic nature is difficult if not imposisble to detect in advance, it allows execution of arbirary shell scripts, no consideration was given to the ecurity implications of the built in action set, etc. etc. etc. It is fair to say that Sieve probably wouldn't exist had procmail been designed with safe server-side operation in mind. But it wasn't. > Also as the distributed machines sending those DSN notifications are > real legal email servers which normally do process emails (in or out) > the original sender getting those DSN's does not want to filter them > out (or not even all DSN from them machines, as somethings he himself > might want to enable DSNs and get DSN reports back from those machines > too). In almost every real world case it is going to be same set of servers the user has direct access to. > The problem is not very big, I agree, but if Sieve is supposed to be > system which can safely be given to the "normal" people who are not > allowed to get shell access to email systems, then this does offer > them new way of causing trouble and harm to other users (i.e. the > original sender). This is why I think it is issue which might need to > be mentioned here but as I said already the new text which says > redirect-deliverby uses Sieve owners address as envelope sender solves > all of this already as now Sieve owner can only attack himself... With all due respect, I think you're operating from a seriously outdated attack tree here. The whole shell access on the server thing is only really relevant these days because of the potential for local resource consumption and privilege amplification attacks. The presence of a scriptable PC on almost everyone's desk has eliminated the need for direct server access to perform more general sorts of automated attacks. That's why the SMTP server has to be properly secured irrespective of what Sieve does or doesn't allow, and the only relevant case is where Sieve offers most access than regular SMTP does. > > > Say host A limits DSN notification complately, i.e does not allow them > > > at all. Now host A user A sends email to user B on host B whose sieve > > > filter adds status notifications (as they are not restricted on host > > > B, only on host A) and the status notifications go to original author > > > A. Now host A user A will get status notifications even when the host > > > A policy forbid requesting them. > > In other words, this is a case where the Sieve policy for requesting > > DSNs is more lenient that for submit/SMTP. I agree this is a > > security concern, which is why the security considerations section > > of the document addresses it. It says: > > Sites which limit the ability > > to request success notifications will also need to restrict the ability > > to request them using the redirect-dsn extension. > > > Host B cannot know what policy host A has, thus it cannot restrict > > > operations. > > Not only can it know, it has to. This is what administrators are for > > - to implement consistent policies across hosts. > Ok, do my home machine kivinen.iki.fi allow DSN or not? When I send > this email to you, is your Sieve filter allowed to add DSNs to this > email or not, i.e. do you know whether my outgoing email server > allowed me to enable DSNs or not. If the servers I have available to me don't allow me to make DSN requests, I would not expect to be able to do it from Sieve either. Ditto for DELIVERBY. And if this isn't true, we're back to the case explicitly covered in the security consideations. > In general case you do not. I have understood that Sieve is normally > run on the receiver end of the email, but perhaps I have misunderstood > that. The DSN policy is for the sender end of the email transmission. The DSN policy on the sender end is irrelevant, because Sieve has no access to that end of things. It has to submit the DSN request to the local submit server; Sieve provides no means for the user to select the submit server that's going to be used. Come to think of it, this is another way where any potential vulnerability in Sieve falls far short - if I want to I can usually bypass local admimistrative policy entirely by submitting my message with the forged envelope sender directly to a server in another administrative domain. There's no way to do that in Sieve. Again, Sieve acts a a proxy for the user, providing another means for the user to send mail. If this alternative means of sending mail is for whatever reason more permissive to the point of allowing abuse the regular SMTP server does not, that's a configuration problem that needs to be addressed. > Very often there is no common adminstration between the sender and the > receiver as people DO send cross-domain emails... Of course there isn't, but since the Sieve isn't operating in the sender's administrative realm, it's irrelevant. > Again this point has also gone away now when the Sieve owner's address > is used as envelope sender as now the machine running Sieve can know > the policy to be used. And again I assert that this supposed security never existed in the first place. > > > > > Also in section 5, it should be made clear that the "bytime" can also > > > > > be negative, if the bymode is "notify" and the message is already > > > > > pasts is notification time. > > > > > > > > Unfortunately, RFC 2852 predates the current thinking in email that > > > > there's significant semantic difference between submission and > > > > relay. My understanding of the purpose of negative by-times is that > > > > they are arrived at when a message exceeds the time limit but still > > > > needs to be delivered. If there's a justification for having a > > > > negative by-time on initial submission I haven't heard it. In fact > > > > had RFC 2852 distinguished between submit and relay I suspect it > > > > would have disallowed negative by-times in the submit case. > > > I do not thing this is relevant here. > > On the contrary, it's entirely relevant because what we have done by > > requiring the resetting of the envelope sender is to effectively > > require that these extended redirect be considered as a new > > submission, not a relay operation. > Ok, that I can agree, but I assumed you were processing these two > issues independently and without the first change (i.e. the envelope > sender change) this would be different. I have no idea what this is supposed to mean. > > > It might be needed if the sieve filter wants to preserve by-time > > > values given to it in the beginning. I do not know enough of Sieve to > > > know if it is possible, but one use could be using sieve to for > > > example limit the by-time to something, i.e. wants to make sure that > > > when email is redirected to cellular phone it is delivered before > > > certain time (for example before 22:00, because user does not want to > > > wake up when cellular phone beeps in the middle of night), unless the > > > email already had shorted by-time, in which case it wants to preserve > it. > > > > The short answer is ths use-case you describe here really isn't feasible > > in Sieve, for a bunch of different reasons. > > > > THe longer answer is that this ends up being infeasible because: > > > > (1) Sieve doesn't have enough numeric and time computation facilities to > > perform the sort of limit operation you describe. > And there is not going to be extensions offering such features, like > adding and substracting integers and comparing them, and getting the > current time? Well, of course that's impossible to predict, but despite there being a huge number of proposals for Sieve extensions, dozens of drafts, and many RFCs, nobody has even suggested such a thing, let alone written up a draft. And we appear to be coming to the end of Sieve extension work. So I think the odds of it happening are pretty low. That said, I think there may be a way to do this without arithmetic as long as you can get the comoonents of the by-time in absolute form. > > (2) Even if you could do the calculation, or if, say, there was a related > > use-case where limiting the relative value made sense (I confess I cannot > > come up with one where it does), most Sieve implementations operate > > after final delivery, so copying deliver-by information doesn't really > > make sense. > For the user who is redirecting this to cellular phone it does make > sense. I first note that the action of "redirect to cellular phone" is rarely if even what's actually going on. And in this case it's an important distinction. What actually occurs is that the message is sent to a submit server and back out into the transport infrastructure. Eventually the message gets delivered to a mailbox somewhere. And there it sits until the client polls and finds the message. The time spent waiting for that poll to occur is time that is not and cannot be controlled by DELIVERBY. Of course there are alternatives to polling. The standard ones are IMAP IDLE and NOTIFY. But both IDLE and NOTIFY require that the client hold open a connection to the server. That's highly problematic for cell phones so most of them don't do it. Absent IDLE or NOTIFY, you're left with nonstandard mechamisms. Unfortunately most of this stuff is highly vendor-specific and what I little I do know about it is covered by various nondisclosure agreements. But suffice it to say that the availability of such capabilities is far from universal, and the quality of the resulting services can vary considerably. And even if the client is notified immediately, it may not for various reasons be able to get at the message right away. And again, all of this is happening outside of the supervisory control DELIVERBY provides. Even if we assume none of these delays occur - and it's my current experience that these days delays post final delivery are far more prevalent than transport infrastructure delays - there's the question of intended semantics. DELIVERBY can be used to say, "Deliver this message by such and such a time, if not, give up". But why this is being done isn't part of the package. You may infer that what the sender cared about was getting the message in front of the recipient's eyes in a certain amount of time, but what if the goal was merely to get the message into the recipient's mailbox before some deadline and the sender could not care less if they have seen it or not? The protocol doesn't let you make that distinction, and that makes willy-nilly copying of DELIVERBY information acrsss resubmits problematic. There's also the issue of Sieve NOTIFY. IF notify is available, not only can you use it to send a notification about the message to the phone in a way that avoids most if not all of these issues. What you're left with is the case where (a) The sender's intentions are known in advance, (b) DELIVERBY is unformly supported across both transports, (c) Sieve and this particular extension are also supported on the initial delivery server, and (d) Post-delivery delays are negligable, and (e) No better alternative like Sieve notify are available. While I'm sure such situations could exist, this is now a pretty esoteric case. > Lets say the email is about meeting that starts at 18:00, and > because of this the original deliver-by-time is 18:00, i.e. this email > is useless after that time. This email arrives to the users Sieve > filter at 14:44, and it is stored to users mail box, and the user's > Sieve filter wants to send a copy of that to cellular but add > additional limit that it cannot be send after 22:00 (just in case > there is some delays there), so user wants to add new deliver-by-time > that is going to be 22:00, but as the original had deliver-by-time of > 18:00, it would be better to use shorter of those two as even when the > email is already delivered to the final destination (users mail box) > before the 18:00, the copy sent to be out usually has exactly same > meaningful time period as the original email. It does not help the > user to get that email to his cellular phone at 20:00 when the meeting > is already over. Because of this it does not really matter whether > this is final deliver or not as user still would have interest to use > the earlier of the two deliver-by-times. I understand the use-case. What I'm saying is that it's a lot harder to implement than you think. And while you can argue that it shouldn't be, the real difficulties here have nothing to do with this extension. > (I used absolute deliver-by-time in the example above as it was easier > to explain using that, but of course the Sieve filter itself could as > easily use the delta time too.) As a practical matter, yes, but once you capture a relative time you're no longer accounting for the time elapsed between when you captured it and when you use it. Since one of the main points of Sieve is that all scripts can be executed in negligable time, this is not a realistic concern, but there's still a gap. So really, the best way to do it is with an absolute time, which you need anyway to perform the necessary comparisons. > > Actually, no. In the use-case you describe, the goal is to prevent the phone > > from ringing after a certain point. That implies that a by-mode of "R" has to > > be used, which means no negative by-times are allowed. > True. > > Moreover, if the original mode was "R", you can copy over a shorter by-time. > > But what happens if the mode is "N"? I think in that case you'd want to > > ignore the original by-time in order to get sensible behavior. > Most likely. Or you just take shorter time and use R in that case too, > as if this is copy the email is already delivered to Sieve users mail > box, but this is for the Sieve user to decide. Of course all this is > also related to where the status notifications are sent. As with the > current change the status notifications are always sent to the Sieve > owner, so he most likely would be using R always in this setups as > this "cellular phone" is supposed to be the way to reach him more > quickly than from normal mail box, and N notifications does not really > offer any new information for him. > > All that said, this use-case makes me wonder if the real error here > > is that we aren't providing a way to look at and set by-times as > > absolute, rather than relative, time values. > I actually start to feel that it might be better option. It's a better option for several additional reasons, one being that this way yuo can do much simoler and more obvious stuff like redirect a message that has to be delivered before 10:00PM to do. That's impossible to do currently, but it can be done if you have an absolute time argument variant on redirect. > > > Also I think the Sieve should be able to preserve by-time and envelope > > > sender when it redirects email, if it does not ADD new notifications. > > > > > I.e if someone sends email having by-time saying it needs to be > > > delivered during next hour, and the Sieve forwards it to the cellular, > > > it would be useful to keep that same time limit there, and it would > > > also be nice if the original author still gets the status > > > notifications he asked for. > > > > That's totally outside the purview of this extension, which does not > > and cannot deal with the unextended redirect case. Moreover, the > > lack of specificity about when Sieve operates - which is both > > intentional and essential - makes this a very difficult question to > > address in ANY context. Just as one example, you most certainly do > > NOT want to try and preserve these things if Sieve is operating in a > > user agent weeks after final delivery - which is a perfectly > > legitimate and even common situation. > Ok. > > > If the email is not yet delivered to the local mail box, but is > > > redirected to somewhere else by the Sieve then I do consider the email > > > to still be in transit, and the time used to run the Sieve should be > > > taken in to account. In most cases it does not really matter as > > > running it is very fast, but I think it still needs to be counted for. > > > > Sieve implementations that operate at this point are in fact the exception, > > not the rule. > So perhaps saying something that when Sieve is run as part of transit > then the delta time should be decremented. Btw, this will be > automatically taken account if the delta time is converted to absolute > deliver-by-time when the email is received and then back to delta time > when it is sent forward as part of relay. It's actually better for the reasons I gave above. > > > > I think this makes it clear the values are simply passed unchanged > > > > to the SMTP/submit server. But if you want to suggest a specific > > > > change, that's fine. > > > > > I think RFC 2852 is very clear that you are supposed to convert that > > > DELTA time to absolute time upon receipt of email, and then convert it > > > back to delta time when you send email forward: > > > > Yes, I'm well aware of what it says, and why. I carpool to work > > every day with the guy who wrote it. The reason for this text is so > > that implementations won't carelessly lose track of some amount of > > elapsed time. But again, this only works while messages are in > > transit. I'm not convinced there's an issue worth addressing in the > > Sieve case. > Not even those exceptional cases where Sieve is run as part of email > transit, not as part of final delivery? Not even then. See above for why this is a lot more esoteric than it first appears. Ned From magnusn@gmail.com Wed Apr 28 20:38:44 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E2CA28C18F; Wed, 28 Apr 2010 20:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.302 X-Spam-Level: X-Spam-Status: No, score=0.302 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKke9wjpaz0k; Wed, 28 Apr 2010 20:38:42 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 969403A67B3; Wed, 28 Apr 2010 20:38:42 -0700 (PDT) Received: by gwaa12 with SMTP id a12so4294200gwa.31 for ; Wed, 28 Apr 2010 20:38:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=Ec/m4dy4HeYgydqVhNfaGnBqjx3KV5//LyK52BxU3XQ=; b=CwzZeJwJoHSSdeDFRa1mnkxRevsGsaMMzoHegBjJPBwe0ENEJh85BYv+/kINrc528O 0WNWKtLSZcJb7FNuufmmRMySjxdinyFQiCjOi9KIbtQZbJ6DeziBzLpW+tUSMHESvQIN HZ26+ZxLgdcShqfsy/A2pB/f9cG7upNYs6VdM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=CRtlxF4pvb+FbsI4pnYGn6UON8d5hj+sUDeFNqDYkX4kycD8fV5ALBIU3IeB7mjCkD BYHHONXAcSWuFYMnSKHj6Cm3Q/f1Xe4S7Kwb303sYUAV1Mz9JIIlYf7/PikORX/4w3lT Xo/P/Tdq5NLuHo/cQoMpOr4AHC9tTKvTTzBKg= MIME-Version: 1.0 Received: by 10.101.170.38 with SMTP id x38mr4076026ano.211.1272512305343; Wed, 28 Apr 2010 20:38:25 -0700 (PDT) Received: by 10.100.124.16 with HTTP; Wed, 28 Apr 2010 20:38:25 -0700 (PDT) Date: Wed, 28 Apr 2010 20:38:25 -0700 Message-ID: From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: draft-ietf-mpls-tp-framework@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Content-Type: multipart/alternative; boundary=0016368e33a6eeab93048557db46 Subject: [secdir] Secdir review of draft-ietf-mpls-tp-framework-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 03:38:44 -0000 --0016368e33a6eeab93048557db46 Content-Type: text/plain; charset=ISO-8859-1 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes the architectural framework for applying MPLS to transport networks. It is joint work with the ITU-T. The document does not contain any normative statements in the RFC 2119 sense; presumably this is because the framework nature of the document and/or the coupling to ITU-T, but it is a little concerning as there are a number of "must", "should" and "may" statements in the document that do look normative to me (e.g. "In cases where a MAC address is needed, the sending node must set the destination MAC address to an address that ensures delivery to the adjacent node."). The security considerations section is very brief and consists mainly of references to other, related documents' security considerations sections. I think it could have been beneficial if it had covered security aspects stemming from the architectural framework and not only force the reader to turn to the component documents. For example, since G-ACh traffic is indistinguishable at the server layer from data traffic, is it possible to craft data traffic messages that confuse a server to believe it is G-ACh? Or, does the bandwidth sharing between control traffic and user data traffic have any security implications? Also, the NNI traffic may involve signaling over the same channel as user data traverse which may cause similar concerns (I am not an expert on MPLS or TP so these threats may well not be realistic, however they serve only as examples). (A minor editorial suggestion: Perhaps better if the list of acronyms in Section 1.3 would be in alphabetical order?) -- Magnus --0016368e33a6eeab93048557db46 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security=20 directorate's ongoing effort to review all IETF documents being processed by the IESG. =A0These comments were written primarily for the benefit of the security area directors. =A0Document editors and WG chairs should treat these comments just like any other last call comments.

This document describes the architectural framework for applying MPLS= to transport networks. It is joint work with the ITU-T.

The documen= t does not contain any normative statements in the RFC 2119 sense; presumab= ly this is because the framework nature of the document and/or the coupling= to ITU-T, but it is a little concerning as there are a number of "mus= t", "should" and "may" statements in the document = that do look normative to me (e.g. "In cases where a MAC address is = needed, the sending node must set the destination MAC address to an addre= ss that ensures delivery to the adjacent node.").

The security considerations section is very brief and consists mainly o= f references to other, related documents' security considerations secti= ons. I think it could have been beneficial if it had covered security aspec= ts stemming from the architectural framework and not only force the reader = to turn to the component documents. For example, since G-ACh traffic is ind= istinguishable at the server layer from data traffic, is it possible to cra= ft data traffic messages that confuse a server to believe it is G-ACh? Or, = does the bandwidth sharing between control traffic and user data traffic ha= ve any security implications? Also, the NNI traffic may involve signaling o= ver the same channel as user data traverse which may cause similar concerns= (I am not an expert on MPLS or TP so these threats may well not be realist= ic,=20 however they serve only as examples).

(A minor editorial suggestion:= Perhaps better if the list of acronyms in Section 1.3 would be in alphabet= ical order?)

-- Magnus
--0016368e33a6eeab93048557db46-- From ron.even.tlv@gmail.com Fri Apr 30 02:50:25 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D8E528C1BB; Fri, 30 Apr 2010 02:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XnF3EEAVkJv; Fri, 30 Apr 2010 02:50:23 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 854F328C19E; Fri, 30 Apr 2010 02:50:21 -0700 (PDT) Received: by wyb35 with SMTP id 35so18531wyb.31 for ; Fri, 30 Apr 2010 02:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:content-language:thread-index; bh=9I7yUF+yejaAC4Df4r3I0yfESLNHssZJY8mqDiwupIU=; b=Rs3Slkv7sM/ftYX1kidV0mrfVfMGJdW0S+3Kn+kWw6A5+KwlUx4lfhhF06hug0dnE2 CxzlAaeW/N4l+KSwwzru8e+ki6PLQ4ipypkPZXnOGA9h5v/S+jmuJOsXAOpLJ9pgLOMF /xJ2iOwS00B4bwOoFTBKYyP7UUeitIm/ljUaU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:content-language :thread-index; b=dhRzP7TXeiBI76N+LU9naHMheJktdZmnA1WvNCtVUSmOu2v5y4wInVw2X7AZAwaSQL yNll06VajJFd7qDIzWssxjLa5HaoAyHGHj4Sb0CskJWnAJNmgGbnvo4+d3FVGVdb2Hna VxaAg8fiy9IH82UZTUl77yGzb0H4N4MORtYbQ= Received: by 10.216.90.9 with SMTP id d9mr3875136wef.95.1272621004396; Fri, 30 Apr 2010 02:50:04 -0700 (PDT) Received: from windows8d787f9 ([109.65.33.169]) by mx.google.com with ESMTPS id x14sm14402331wbs.12.2010.04.30.02.50.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 30 Apr 2010 02:50:02 -0700 (PDT) From: "Roni Even" To: "'Radia Perlman'" , , , , , , References: In-Reply-To: Date: Fri, 30 Apr 2010 12:49:02 +0300 Message-ID: <4bdaa7ca.8e83e30a.4af1.ffff851e@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-us Thread-index: AcrlAD0F3iYgPT83Tjyg4fLLudYHLQDSVGNg X-Mailman-Approved-At: Fri, 30 Apr 2010 10:40:39 -0700 Subject: Re: [secdir] secdir review of draft-ietf-avt-rtp-rfc3984bis-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 09:50:25 -0000 Hi Radia, This is a video payload specification and the length of the document is mostly because the big number of optional parameters that can be negotiated and the offer answer behavior for the parameters. The 3984bis draft updates RFC 3984 based on implementation on experience, explaining the issues that came to the mailing list on offer answer issues. As for the reordering of packets this are RTP issues and not the codec issues. Thanks Roni Even > -----Original Message----- > From: Radia Perlman [mailto:radiaperlman@gmail.com] > Sent: Monday, April 26, 2010 8:21 AM > To: secdir@ietf.org; iesg@ietf.org; yekuiwang@huawei.com; > ron.even.tlv@gmail.com; tom.kristensen@tandberg.com; tomkri@ifi.uio.no; > rjesup@wgate.com > Subject: Re: secdir review of draft-ietf-avt-rtp-rfc3984bis-10 > > Sorry secdir and iesg for sending this twice...I've been trying to > figure out how to use the tools thing to get all the authors, and > apparently didn't do it right, so I'll manually put in the authors > names like I have done before, on previous secdir reviews. > (sending to draft-ietf-avt-rtp-rfc3984bis-10.all@tools.ietf.org > bounced) > > > > On Sun, Apr 25, 2010 at 10:14 PM, Radia Perlman > wrote: > > This document just describes how to carry video in RTP. Apparently > > there is a standard in ISO and a standard in ITU (ITU-T > Recommendation > > H.264 and ISO/IEC International Standard 14496 Part 10) that both > > specify nearly identical compression algorithms for video encoding. > > Given that this document is not describing the video encoding itself, > > but just how to carry it in RTP, it is a little surprising that this > > document is 104 pages, but it describes what to do about reordering, > > lost packets, fragmentation across packet boundaries, and so forth. > > > > There really are not any security considerations, and certainly not > > anything they missed in their security considerations section. One > > thing that might be nice to mention is that it is dangerous to do > > encryption without integrity protection because a single bit error in > > the ciphertext can cause a lot of errors in the plaintext. > > > > Radia > > From mbj@tail-f.com Fri Apr 30 04:08:32 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A13CF3A67E3; Fri, 30 Apr 2010 04:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.108 X-Spam-Level: X-Spam-Status: No, score=0.108 tagged_above=-999 required=5 tests=[AWL=-0.446, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rY6XXJkKVB3T; Fri, 30 Apr 2010 04:08:30 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4026A3A6B9F; Fri, 30 Apr 2010 04:08:14 -0700 (PDT) Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id 51296616001; Fri, 30 Apr 2010 13:07:59 +0200 (CEST) Date: Fri, 30 Apr 2010 13:07:59 +0200 (CEST) Message-Id: <20100430.130759.243104998.mbj@tail-f.com> To: aland@deployingradius.com From: Martin Bjorklund In-Reply-To: <4BD839E7.4040200@deployingradius.com> References: <4BD839E7.4040200@deployingradius.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 30 Apr 2010 10:40:39 -0700 Cc: iesg@ietf.org, draft-ietf-netmod-yang@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-netmod-yang-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 11:08:32 -0000 Hi, Alan DeKok 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. > > The document defines a language used to read and write descriptions of > management information. It is not intended to be used within an "on the > wire" internet protocol. As such, the usual "on the wire" security > issues do not apply. > > The "Security Considerations" looks OK. I would suggest adding a > caution about reading data from untrusted sources. Document readers > have a long history of being attacked by malformed documents. > > e.g.: > > YANG parsers need to be robust with respect to malformed documents. > Reading malformed documents from unknown or untrusted sources could > result in an attacker gaining privileges of the user running the YANG > parser. In an extreme situation, the entire machine could be compromised. I agree that this makes sense. I will add your suggested text. Thank you! /martin From rden@loc.gov Fri Apr 30 09:00:16 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1420028C0E6; Fri, 30 Apr 2010 09:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vq7joM1TPtyC; Fri, 30 Apr 2010 09:00:15 -0700 (PDT) Received: from sun8.loc.gov (sun8.loc.gov [140.147.249.48]) by core3.amsl.com (Postfix) with ESMTP id 33F9728C117; Fri, 30 Apr 2010 09:00:07 -0700 (PDT) Received: from lsdds9qg1 (lsdds9qg1.lib.loc.gov [140.147.175.24]) by sun8.loc.gov with SMTP id o3UFxmDT007106; Fri, 30 Apr 2010 11:59:49 -0400 (EDT) Message-ID: <038601cae87e$2965c820$18af938c@lib.loc.gov> From: "Ray Denenberg, Library of Congress" To: "Rob Austein" , , References: <20100428145717.D230322831@thrintun.hactrn.net> Date: Fri, 30 Apr 2010 11:59:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailman-Approved-At: Fri, 30 Apr 2010 10:40:39 -0700 Cc: draft-denenberg-mods-etc-media-types.all@tools.ietf.org Subject: Re: [secdir] Review of draft-denenberg-mods-etc-media-types-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 16:00:16 -0000 From: "Rob Austein" > The one (non-security) part of this that I don't understand is why a > separate MIME types is necessary for each individual schema. I took this question up with the relevant implementers here. Each schema corresponds to a separate content type. And the fact is, this applies not just to these schemas in question but to even a larger set, the rest of which are in development now. For each of these content types there are applications already in use that employ content negotiation on the type (so some implementers have already implemented these mime types). --Ray