From nobody Fri Aug 1 02:39:47 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50EB1A063E for ; Fri, 1 Aug 2014 02:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.122 X-Spam-Level: X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0M-PYLZARKn for ; Fri, 1 Aug 2014 02:39:43 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 525961A04C2 for ; Fri, 1 Aug 2014 02:39:43 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s719dd7a028894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 1 Aug 2014 12:39:39 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s719ddAl011871; Fri, 1 Aug 2014 12:39:39 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21467.24667.562905.688337@fireball.kivinen.iki.fi> Date: Fri, 1 Aug 2014 12:39:39 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/1hqFSwIwhTW4tegZnoc_s6Z9wjg Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 09:39:45 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Dan Harkins is next in the rotation. For telechat 2014-08-07 Reviewer LC end Draft Sam Hartman T 2014-06-23 draft-ietf-dnsop-child-syncronization-02 Charlie Kaufman TR2014-07-02 draft-ietf-6man-multicast-addr-arch-update-07 Warren Kumari T 2014-07-02 draft-ietf-netext-pmip-cp-up-separation-05 Alexey Melnikov T 2014-07-04 draft-ietf-p2psip-service-discovery-14 Eric Osterweil T 2014-07-15 draft-ietf-l2vpn-etree-frwk-07 Joe Salowey T 2014-07-21 draft-ietf-trill-loss-delay-05 Zach Shelby T 2014-07-21 draft-ietf-trill-oam-fm-07 Melinda Shore T 2014-08-01 draft-ietf-websec-key-pinning-19 Ondrej Sury T 2014-07-15 draft-kivinen-ipsecme-signature-auth-07 Sean Turner T 2014-07-17 draft-ietf-appsawg-nullmx-06 Carl Wallace T 2014-07-25 draft-ietf-isis-tlv-codepoints-00 Paul Wouters T 2014-08-01 draft-ietf-appsawg-email-auth-codes-05 For telechat 2014-08-21 Shaun Cooley T 2014-08-08 draft-ietf-tram-auth-problems-04 Alan DeKok T 2014-08-08 draft-ietf-appsawg-json-merge-patch-06 Shawn Emery TR2014-07-16 draft-ietf-tictoc-security-requirements-11 Shawn Emery T 2014-08-14 draft-ietf-core-groupcomm-21 Dorothy Gellert T 2014-08-08 draft-ietf-core-observe-14 Last calls and special requests: Derek Atkins 2014-08-09 draft-ietf-l3vpn-pmsi-registry-03 Donald Eastlake 2014-08-08 draft-ietf-conex-abstract-mech-12 Tobias Gondrom 2014-08-13 draft-ietf-forces-protoextension-04 Phillip Hallam-Baker 2014-08-11 draft-ietf-netmod-snmp-cfg-06 Steve Hanna 2014-08-13 draft-ietf-rmcat-cc-requirements-05 Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-06 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Ondrej Sury 2014-07-30 draft-ietf-ipfix-text-adt-07 Sam Weiler 2014-08-12 draft-ietf-karp-bfd-analysis-04 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-11 Brian Weis 2014-07-29 draft-ietf-dnsop-rfc6304bis-04 Klaas Wierenga 2014-07-29 draft-ietf-dnsop-as112-dname-04 Tom Yu 2014-08-09 draft-ietf-forces-model-extension-03 Dacheng Zhang 2014-08-07 draft-ietf-l2vpn-ipls-14 -- kivinen@iki.fi From nobody Fri Aug 1 02:40:43 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB28A1A0496; Fri, 1 Aug 2014 02:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4s69yR4SSGGh; Fri, 1 Aug 2014 02:40:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63C7D1A04C2; Fri, 1 Aug 2014 02:40:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHU70955; Fri, 01 Aug 2014 09:40:36 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 1 Aug 2014 10:40:33 +0100 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.141]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Fri, 1 Aug 2014 17:40:28 +0800 From: "Zhangdacheng (Dacheng)" To: "draft-ietf-l2vpn-ipls@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-l2vpn-ipls-14 Thread-Index: Ac+tbKBmSURf/kQdQ6KYONVa4goh8A== Date: Fri, 1 Aug 2014 09:40:28 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.139] Content-Type: multipart/alternative; boundary="_000_C72CBD9FE3CA604887B1B3F1D145D05E7BCAD63Enkgeml507mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Mss_mXIc5VEx1Itx2jryIAhnSN0 Cc: IESG , "secdir@ietf.org" Subject: [secdir] Secdir review of draft-ietf-l2vpn-ipls-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 09:40:41 -0000 --_000_C72CBD9FE3CA604887B1B3F1D145D05E7BCAD63Enkgeml507mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document proposes a 'simplified' type of VPLS which only support IP. I= n addition, in this solution the maintenance of the MAC forwarding tables i= s done via a control plane protocol, rather than via the MAC address learni= ng procedures specified in [IEEE 802.1D] I think this document is almost ready for publication. Two comments are as = follows: 1) In security consideration, MD5 should not be recommended. So, "authentic= ating the LDP messages using MD5 authentication." could be changed to "auth= enticating the LDP messages by verifying keyed digests." 2) In this solution, a PE actively detects the presence of local CEs by sno= oping IP and ARP frames received over the ACs. As the PE discovers each loc= ally attached CE, a unicast multipoint- to-point pseudowire (mp2p PW) assoc= iated exclusively with that CE is created by distributing the MAC address a= nd optionally IP address of the CE along with a PW-Label to all the remote = PE peers that participate in the same IPLS instance. So, IMHO, DDoS attacks= by generating large amounts of bogus IP and ARP frames should be considere= d, and counter measures should be provided. For instance, MAC addresses of = CEs should be distributed only in a limited frequency. Cheers Dacheng --_000_C72CBD9FE3CA604887B1B3F1D145D05E7BCAD63Enkgeml507mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hello,

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

= This document proposes a &= #8216;simplified’ type of VPLS which only support IP. In addition, in this solution the m= aintenance of the MAC forwarding tables is done via a control plane protocol, rather = than via the MAC address learning procedures specified in [IEEE 802.1D]

= I think this document is almost ready for publication. Two comments are as = follows:

= 1) In security consideration, MD5 should not be recommended. So, "auth= enticating the LDP messages using MD5 authentication." could be change= d to "authenticating the LDP messages by verifying keyed digests."

= 2) In this solution, a PE actively detects the presence of local CEs by sno= oping IP and ARP frames received over the ACs. As the PE discovers each loc= ally attached CE, a unicast multipoint- to-point pseudowire (mp2p PW) associated exclusively with that CE is creat= ed by distributing the MAC address and optionally IP address of the CE alon= g with a PW-Label to all the remote PE peers that participate in the same I= PLS instance. So, IMHO, DDoS attacks by generating large amounts of bogus IP and ARP frames should be considere= d, and counter measures should be provided. For instance, MAC addresses of = CEs should be distributed only in a limited frequency.

= Cheers

= Dacheng

--_000_C72CBD9FE3CA604887B1B3F1D145D05E7BCAD63Enkgeml507mbschi_-- From nobody Fri Aug 1 08:28:25 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8E11B27E0; Fri, 1 Aug 2014 08:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BndyBWsPWB8W; Fri, 1 Aug 2014 08:28:21 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A1BC1B27C3; Fri, 1 Aug 2014 08:28:20 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6759080048; Fri, 1 Aug 2014 11:28:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1406906899; bh=Si5wuKVpAfgaG+j9z7QMexAKp0IcKThdKb4rcYIro+o=; h=Date:From:To:Subject; b=ZN1+2kk8v0FhX+6o1ZPaV/Hnp+G3BQwyiw+yekaGYNFHHCWrjcbNTKyLihFx5eGZg ZYJnZIBYnsU5mWmLdWypNO0I8MWQw7Z0NJn4Lr8qHJter9Hypssj9D4uzP2EWN8BZ9 izF3bQIuySfhBsMKRhPLeQ+7LRNR9xMgT6tNCrGo= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s71FSIkm014474; Fri, 1 Aug 2014 11:28:18 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 1 Aug 2014 11:28:18 -0400 (EDT) From: Paul Wouters To: iesg@ietf.org, secdir@ietf.org, draft-ietf-appsawg-email-auth-codes.all@tools.ietf.org Message-ID: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/nvRsndAkVI48vmIL1YSlm1WCGD4 Subject: [secdir] Secdir review of draft-ietf-appsawg-email-auth-codes X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 15:28:24 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document proposes to add additional entries to the "SMTP Enhanced Status Codes Registry", specifically related to DKIM, SPF and Reverse DNS checks, to assist operators and endusers in determining why their email message was rejected. The document looks good and has a proper security consideration section. I do have one question with respect to the temporary failure codes. For SPF Failure Codes, a distinction is made between an SPF validation failure (X.7.22) and an SPF validation error (X.7.23). A failure is the result of a successful (SPF) check method to mark the email message as failed. An error means the (SPF) method to check for failure did not run successfully and it could not determine whether the message should pass or fail. For example, an error in the (SPF) check could be due to a temporary DNS problem. For the DKIM and Reverse DNS, which like SPF depends on a working DNS resolver for the mail server, there is no such split made. These can only return failures, not errors in determining success or failure. If there is value in indicating this distinction for SPF, I would assume the same distinction would be useful for DKIM and Reverse DNS. If there are good reasons not to do this, perhaps it would be good to explain those reasons in the document along with some advise for implementors on what (existing) extended message code to return in the case of temporary DNS failures in the DKIM and Reverse DNS case. Paul From nobody Fri Aug 1 11:08:43 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2E11A02DB; Fri, 1 Aug 2014 11:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVUm4Uk4NaS7; Fri, 1 Aug 2014 11:08:32 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D8521B2796; Fri, 1 Aug 2014 11:08:31 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id x12so4665696wgg.28 for ; Fri, 01 Aug 2014 11:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3kpjEZi3cGQCvz9O00B64Vt13SS4fNgX1fHstkAB3co=; b=Vqovyw1VcNznWTnplaT4KaS4HsWKHztMIYLTab5B7PURxuXy+tHg8M05P5+K5omjzI dgQz9ThTziirKzBZAlFBv5e1EDh1sZ5+Kd9nMT0/gJ1EaSOVb6yfMgAqmDponv8kkWC8 5GqHInxhZiS71ZAhmUbrVDvp+Owlm+UvE49dzuHfxtpxkUp+RJpNexccJLdXUPfNQo4D S1I5BZrQqrvl9n6O0Jm5fVxKu5uHCh3GIuWc7qPifPU+keJg4Easu1V04QEWJUh+N9hQ hc5/RvrELUDhfQMKQmCUpc7TSrt58tLfS1NsQV0H0TenpWYu/kNIRiDrplH9+iNnbkDk G6EA== MIME-Version: 1.0 X-Received: by 10.194.7.36 with SMTP id g4mr10485263wja.37.1406916509385; Fri, 01 Aug 2014 11:08:29 -0700 (PDT) Received: by 10.180.10.99 with HTTP; Fri, 1 Aug 2014 11:08:29 -0700 (PDT) In-Reply-To: References: Date: Fri, 1 Aug 2014 11:08:29 -0700 Message-ID: From: "Murray S. Kucherawy" To: Paul Wouters Content-Type: multipart/alternative; boundary=047d7b450a7cc54d7b04ff954650 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/SLYmYp0NR5lrEB2iuwTgj1ukhY0 Cc: draft-ietf-appsawg-email-auth-codes.all@tools.ietf.org, The IESG , IETF Apps Discuss , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-appsawg-email-auth-codes X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 18:08:39 -0000 --047d7b450a7cc54d7b04ff954650 Content-Type: text/plain; charset=UTF-8 Hi Paul, thanks for the review. On Fri, Aug 1, 2014 at 8:28 AM, Paul Wouters wrote: > I do have one question with respect to the temporary failure codes. > > For SPF Failure Codes, a distinction is made between an SPF validation > failure (X.7.22) and an SPF validation error (X.7.23). > > A failure is the result of a successful (SPF) check method to mark the > email message as failed. An error means the (SPF) method to check for > failure did not run successfully and it could not determine whether the > message should pass or fail. For example, an error in the (SPF) check > could be due to a temporary DNS problem. > > For the DKIM and Reverse DNS, which like SPF depends on a working DNS > resolver for the mail server, there is no such split made. These can > only return failures, not errors in determining success or failure. > > If there is value in indicating this distinction for SPF, I would assume > the same distinction would be useful for DKIM and Reverse DNS. If there > are good reasons not to do this, perhaps it would be good to explain > those reasons in the document along with some advise for implementors > on what (existing) extended message code to return in the case of > temporary DNS failures in the DKIM and Reverse DNS case. I think the case of interest for both is what to do when something malformed is discovered. In that respect, the two communities operate a little differently. Specifically, if a malformed SPF record is found in the DNS, the intent here is to reject the message with the newly-registered error code rather than something less precise. For DKIM, however, a malformed signature or key record typically leads to the message being delivered with an annotation (RFC7001, for example) that there was no valid signature on the message, rather than rejecting it. For rDNS, I suspect most MTAs use x.4.3 to report that condition, which is already registered. I imagine there's no harm in adding an error code for DKIM and maybe for rDNS. As the document already says, there's no compulsion to use them if operators choose to continue using whatever they're using today. -MSK --047d7b450a7cc54d7b04ff954650 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Paul, thanks for the review.

On Fri, Aug 1, 2014 at 8:28 AM, Pau= l Wouters <paul@nohats.ca> wrote:
I do have one question with respect to the t= emporary failure codes.

For SPF Failure Codes, a distinction is made between an SPF validation
failure (X.7.22) and an SPF validation error (X.7.23).

A failure is the result of a successful (SPF) check method to mark the
email message as failed. An error means the (SPF) method to check for
failure did not run successfully and it could not determine whether the
message should pass or fail. For example, an error in the (SPF) check
could be due to a temporary DNS problem.

For the DKIM and Reverse DNS, which like SPF depends on a working DNS
resolver for the mail server, there is no such split made. These can
only return failures, not errors in determining success or failure.

If there is value in indicating this distinction for SPF, I would assume the same distinction would be useful for DKIM and Reverse DNS. If there
are good reasons not to do this, perhaps it would be good to explain
those reasons in the document along with some advise for implementors
on what (existing) extended message code to return in the case of
temporary DNS failures in the DKIM and Reverse DNS case.

I think the case of interest for both is what to do when something malf= ormed is discovered.=C2=A0 In that respect, the two communities operate a l= ittle differently.=C2=A0 Specifically, if a malformed SPF record is found i= n the DNS, the intent here is to reject the message with the newly-register= ed error code rather than something less precise.=C2=A0 For DKIM, however, = a malformed signature or key record typically leads to the message being de= livered with an annotation (RFC7001, for example) that there was no valid s= ignature on the message, rather than rejecting it.

For rDNS, I suspect most MTAs use x.4.= 3 to report that condition, which is already registered.

I imagine there's no harm in adding an error code= for DKIM and maybe for rDNS.=C2=A0 As the document already says, there'= ;s no compulsion to use them if operators choose to continue using whatever= they're using today.

-MSK
--047d7b450a7cc54d7b04ff954650-- From nobody Sun Aug 3 19:51:27 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF071B281E; Sun, 3 Aug 2014 19:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDhgDo5CCXUK; Sun, 3 Aug 2014 19:51:24 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FA291B281C; Sun, 3 Aug 2014 19:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=498; q=dns/txt; s=iport; t=1407120684; x=1408330284; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=4yH2we5nCDXBEVWEoWoHNl1AwrvpptYt33fqjvBj028=; b=FHiGfx3Ax+S5Y351Fcef8/PQgXh+V54sbAivJ3uYx0poP+Z/GQDDM9jg 0abAz0dp3x+YH5YihJXQV2Ua0xKQiiIEbW8qJyzPXDXL9D649YkIgLsBc qu+XiMUfW1wyT2/03gBRdDcfmj/HLPwxBzp/dJJa3dOpjz+nb90b/U2m4 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAOX03lOtJA2J/2dsb2JhbABbgw2BLdR6FneECjpRAT5CJwQBiFTFeheTAoEcBZwGlF+DTYIy X-IronPort-AV: E=Sophos;i="5.01,795,1400025600"; d="scan'208";a="344842416" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-3.cisco.com with ESMTP; 04 Aug 2014 02:51:20 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s742pKTV021681 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Aug 2014 02:51:20 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Sun, 3 Aug 2014 21:51:20 -0500 From: "Joseph Salowey (jsalowey)" To: "" , IESG , "draft-ietf-trill-loss-delay-05.all@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-trill-loss-delay-05 Thread-Index: AQHPr474bgzZWUCee0itdMp1CjayKw== Date: Mon, 4 Aug 2014 02:51:19 +0000 Message-ID: <729629AB-CA13-4B00-82AF-8392A5D6454F@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <9B2CDDB2DBAEEE49AE0A2C08240877F4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/D5VIvEjCxU-b6_125cLuK0EC1W8 Subject: [secdir] Secdir review of draft-ietf-trill-loss-delay-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 02:51:26 -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 is ready.=20 The document has a security considerations section that covers the issues t= hat I can think of. =20 Cheers, Joe= From nobody Mon Aug 4 15:18:04 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 683121A0367; Mon, 4 Aug 2014 15:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vc2yyd9m65RQ; Mon, 4 Aug 2014 15:17:44 -0700 (PDT) Received: from www.gondrom.org (www.gondrom.org [91.250.114.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3777B1A0350; Mon, 4 Aug 2014 15:17:44 -0700 (PDT) X-No-Relay: not in my network DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=L2jOhswxAW41IUamdneOZJuLe+QHXYN5Cfts1v/iUJohar6KR6+8q6zX2G6ugeNbexci2WCTNy24UgCPg4QjFl6+CC3nIzn7YxVYHHgsMDZZA1Y0/jG2cXExdfy9r+3Pnv90XhtbgsYbIhOHRXEF2Rar6Zb9ER7k+DdsPqsxaiM=; h=X-No-Relay:X-No-Relay:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Enigmail-Version:Content-Type; X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.6] (5ec20b19.skybroadband.com [94.194.11.25]) by www.gondrom.org (Postfix) with ESMTPSA id 997981539007B; Tue, 5 Aug 2014 00:17:42 +0200 (CEST) Message-ID: <53E00686.7030909@gondrom.org> Date: Mon, 04 Aug 2014 23:17:42 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: draft-ietf-forces-protoextension.all@tools.ietf.org, iesg@ietf.org X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------040302020804040505010707" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/LscY2CxPp5Ksgd-IDZxfSmeqBA0 Cc: secdir@ietf.org Subject: [secdir] secdir review of draft-ietf-forces-protoextension-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 22:17:55 -0000 This is a multi-part message in MIME format. --------------040302020804040505010707 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The draft is standards track and describes a few extensions to ease programmability and to improve wire efficiency of some transactions. It adds extensions to the ForCES Protocol RFC5810 and RFC7121. The document appears mostly ready for publication. The security considerations section (section 6) only refers to RFC 5810. 1 Nits and 3 Questions regarding the security section below: Nits: - section 3.2.3.1. last paragraph: s/writting/writing Questions: 1. section 3.2.3.1. last paragraph: "On an FE which supports both RESULT-TLVs and EXTENDEDRESULT-TLVs, a master CE can turn on support for extended results by setting the value to 2 in which case the FE MUST switch over to sending only EXTENDEDRESULT-TLVs." Not sure about the full network topology, but could that enable a master CE to effectively make the replies of a FE unreadable to other old-version CEs (which can only understand RESULT-TLVs) by switching on the "only" new EXTENDEDRESULT-TLVs? 2. with the New Codes in section 3.2.1. : do any of the new more detailed error codes (e.g. "E_EMPTY | Table is empty") pose a risk of data leakage of information detail that was not intended to be disclosed in that detail in the original RFC 5810? 3. section 3.1.: Could the new "TABLERANGE-TLV", which requires significantly more computing on the receiver per request from the sender, enable an attacker for a type of Denial of Service attack scenario? NOTE: though I reviewed the ID, I did not validate the XML structure in appendix A. Thank you and best regards. Tobias --------------040302020804040505010707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

The draft is standards track and describes a few extensions to ease programmability and to improve wire efficiency of some transactions. It adds extensions to the ForCES Protocol RFC5810 and RFC7121.

The document appears mostly ready for publication.

The security considerations section (section 6) only refers to RFC 5810.


1 Nits and 3 Questions regarding the security section below:

Nits:
- section 3.2.3.1. last paragraph:
s/writting/writing

Questions:
1. section 3.2.3.1. last paragraph: 
"On an FE which supports both RESULT-TLVs and EXTENDEDRESULT-TLVs, a
   master CE can turn on support for extended results by setting the
   value to 2 in which case the FE MUST switch over to sending only
   EXTENDEDRESULT-TLVs."

Not sure about the full network topology, but could that enable a master CE to effectively make the replies of a FE unreadable to other old-version CEs (which can only understand RESULT-TLVs) by switching on the "only" new EXTENDEDRESULT-TLVs?

2. with the New Codes in section 3.2.1. :
do any of the new more detailed error codes (e.g. "E_EMPTY |  Table is empty") pose a risk of data leakage of information detail that was not intended to be disclosed in that detail in the original RFC 5810?

3. section 3.1.:
Could the new "TABLERANGE-TLV", which requires significantly more computing on the receiver per request from the sender, enable an attacker for a type of Denial of Service attack scenario?


NOTE: though I reviewed the ID, I did not validate the XML structure in appendix A.


Thank you and best regards.

Tobias

--------------040302020804040505010707-- From nobody Mon Aug 4 19:44:52 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2F81ABC10 for ; Mon, 4 Aug 2014 19:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_Yw05fHX2zt for ; Mon, 4 Aug 2014 19:44:49 -0700 (PDT) Received: from mail-yk0-f170.google.com (mail-yk0-f170.google.com [209.85.160.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D77FD1ABB32 for ; Mon, 4 Aug 2014 19:44:48 -0700 (PDT) Received: by mail-yk0-f170.google.com with SMTP id 9so224691ykp.29 for ; Mon, 04 Aug 2014 19:44:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version:content-type:content-transfer-encoding; bh=d9gwtdzyLOkO3w5ryYHa9eG1ztdmMUgsn0Sf5+PO0OQ=; b=kJXDP9icxWL02x8kb4JjJhemAPlT23jHbub5cRj1Ubrr6dDIdH/NflpyXKeVN1jYcq 1+9/LX+Q6CZSyZWw168Y1jzoy9q0Kh00Gocx4KQFj8iHp2S9vEpn1efz/Wh64n5P5cqX kblGOBmkv0APvI2ro6YHdjBgC0wegqTT4vFpyENFvRQHltXTquUSMb1XqwVbeqmqy9M1 USf//5UiTKSecEtztZN1GAvYIJv9NGId1l5qqjkdQ5QlebdqojRiM0jXKcPkhJq+SEhK 11iFL0d2M8hdzEZ22CEQ+vR6M/MkYAiW/wiFLZ9WO/kDwl1La4wEQfvMqQHKWr5xtQq0 /F9w== X-Gm-Message-State: ALoCoQnitIUxIO/ptC9I6lIfnpu4/gRKUzYvUpkjTt8gkSQhJA0umYJlqHg2PE/HO/hMTQ52HMr+ X-Received: by 10.236.106.10 with SMTP id l10mr1074463yhg.101.1407206688140; Mon, 04 Aug 2014 19:44:48 -0700 (PDT) Received: from [10.100.10.149] (69.216-16-171-net.sccoast.net. [216.16.171.69]) by mx.google.com with ESMTPSA id j21sm688170yhj.29.2014.08.04.19.44.45 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 04 Aug 2014 19:44:47 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.4.3.140616 Date: Mon, 04 Aug 2014 22:44:40 -0400 From: Carl Wallace To: "secdir@ietf.org" , Message-ID: Thread-Topic: secdir review of draft-ietf-isis-tlv-codepoints-00 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/P-yr-Qb9Dc_zZrbQEbT12gG_LMI Subject: [secdir] secdir review of draft-ietf-isis-tlv-codepoints-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 02:44: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 recommends some editorial changes to the IANA IS-IS TLV Codepoints registry to more accurately document the state of the protocol. It claims to introduce no new security issues, which seems fine. From nobody Tue Aug 5 04:14:05 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201A11B29A3; Tue, 5 Aug 2014 04:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMu5C24Zl7T7; Tue, 5 Aug 2014 04:14:00 -0700 (PDT) Received: from www.gondrom.org (www.gondrom.org [91.250.114.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A76E91B29A5; Tue, 5 Aug 2014 04:13:59 -0700 (PDT) X-No-Relay: not in my network DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=zcJiBzWNhxumPAllR6X7uP0Rjt2+IYTJHdT2RbTrlaCjhAUt/JGnQB3lV8euOy/FOeMyuqaQ86nFO2jFWiOxwqxkxhNZW18tF+X5jFdt0NjOqp1ExsABBltBwuaSNNW/kwhAjbPvX44MjT5A0OB+hfDHreTvAnqb9ON79Altmj8=; h=X-No-Relay:X-No-Relay:X-No-Relay:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.6] (5ec20b19.skybroadband.com [94.194.11.25]) by www.gondrom.org (Postfix) with ESMTPSA id 4F03A1539000F; Tue, 5 Aug 2014 13:13:57 +0200 (CEST) Message-ID: <53E0BC74.8090804@gondrom.org> Date: Tue, 05 Aug 2014 12:13:56 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: hadi@mojatatu.com References: <53E00686.7030909@gondrom.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/XsMbqtUXkmEZGY7JdXJCIXDDI1o Cc: draft-ietf-forces-protoextension.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-forces-protoextension-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 11:14:03 -0000 Hi Jamal, thanks for the fast reply. And thank you for taking the time to answer my questions. Please see my answers only as my personal comments and I am no expert in the forces spec. So I might very well be wrong. Answers inline. On 05/08/14 11:49, Jamal Hadi Salim wrote: > Hi Tobias, > > Thank you for the review. Comments in line. > > On Mon, Aug 4, 2014 at 6:17 PM, Tobias Gondrom > 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 draft is standards track and describes a few extensions to ease >> programmability and to improve wire efficiency of some transactions. It adds >> extensions to the ForCES Protocol RFC5810 and RFC7121. >> >> The document appears mostly ready for publication. >> >> The security considerations section (section 6) only refers to RFC 5810. >> >> >> 1 Nits and 3 Questions regarding the security section below: >> >> Nits: >> - section 3.2.3.1. last paragraph: >> s/writting/writing >> > Fixed. > >> Questions: >> 1. section 3.2.3.1. last paragraph: >> "On an FE which supports both RESULT-TLVs and EXTENDEDRESULT-TLVs, a >> master CE can turn on support for extended results by setting the >> value to 2 in which case the FE MUST switch over to sending only >> EXTENDEDRESULT-TLVs." >> >> Not sure about the full network topology, but could that enable a master CE >> to effectively make the replies of a FE unreadable to other old-version CEs >> (which can only understand RESULT-TLVs) by switching on the "only" new >> EXTENDEDRESULT-TLVs? >> > Hrm. In a cluster of CEs where you have new + older CEs, yes - that is possible. > Caveat: The CEs are spec-ed to talk to each other on CE-CE plane. I would expect > what you described to be a "buggy" decision by the master CE. > Would text that describes this as a faulty setup be reasonable to add > to cover this? Yes. That might be a useful point. But please see my review questions only as personal comment. I would not want to make suggestions that go against the WG views. Small add-on question: Not sure whether there are potentially two scenarios here: 1. the first as you described might be a "buggy" decision by a master CE to switching on the "only" new EXTENDEDRESULT-TLVs and by that switching off the old codes for the other old CEs. 2. wondering whether there might be a second scenario where a malicious person would intentionally try to insert one new CE and switch the FEs to EXTENDEDRESULT-TLVs to "blind" an existing "old" CE network to some of the error codes? > >> 2. with the New Codes in section 3.2.1. : >> do any of the new more detailed error codes (e.g. "E_EMPTY | Table is >> empty") pose a risk of data leakage of information detail that was not >> intended to be disclosed in that detail in the original RFC 5810? >> > There is no new information per-se being sent. Implementations sent back > different things like E_NOT_FOUND or E_INVALID_PATH etc before this > and it was left up to the controller to interpret i.e no explicit coherency > for what ended up being a common use case. Therefore E_EMPTY is > providing a little more clarity. Ok. > >> 3. section 3.1.: >> Could the new "TABLERANGE-TLV", which requires significantly more computing >> on the receiver per request from the sender, enable an attacker for a type >> of Denial of Service attack scenario? >> > Note: it is the controller that would be doing this. If your brain wants > to attack your legs by punching them endlessly, not sure what those > legs could do;-> > (cant run unless brain tells you to). i.e there is explicit, unquestionable > trust of the controller. If the controller is compromised, then we are > talking about > a different ballgame altogether (and nothing we can do here resolves that). > > I am not sure i agree on the "significant compute" statement[1]. > You are right however that a not so good implementation doing the filtering > at the source would suffer because it has to check for index validity. > An implementation can reject table range requests by issuing a > response of E_INVALID_TFLAGS (section 3.1) > Probably we need to add a small discussion to describe this scenario as another > one that would neccessitate the issuing of E_INVALID_TFLAGS? Yes. I understand. My concern is the following: AFAIK (and I might very well be wrong) so far the protocol mostly required many requests to receive the data from the FEs. Which is inefficient, but equally put symmetric compute resource requirements on both points (CE and FE). Aka, you would see a many requests to put a FE to work. With the new "TABLERANGE-TLV", it seems I can send one request which will trigger more computing activity on the FE. So yes, you are right with your analogy between brain and legs and the trust relationship to the controller. However, before, your "brain" could send one command at a time to the legs, now it could send a whole marching program to the legs with one single request. And send multiple such requests in succession. Could that pose risks for denial of service (accidental or malicious) that might not have been anticipated in RFC5810? > >> NOTE: though I reviewed the ID, I did not validate the XML structure in >> appendix A. >> > At least one other person (the shepherd) has taken of this, so no worries. Thanks. Cheers, Tobias > > Thanks again for taking the time to review. > > cheers, > jamal > > [1] The filter essentially does a table dump, > checks what the index is and adds it to the response if it matches. > > >> Thank you and best regards. >> >> Tobias >> From nobody Tue Aug 5 06:11:43 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6047E1B278B; Tue, 5 Aug 2014 06:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYVv5VuXbaRH; Tue, 5 Aug 2014 06:11:30 -0700 (PDT) Received: from www.gondrom.org (www.gondrom.org [91.250.114.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4DC61B278E; Tue, 5 Aug 2014 06:11:26 -0700 (PDT) X-No-Relay: not in my network DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=2rf3/v/gKsrHpchGItCvSVEle3lkNV4+dz8yAHdayQcnRJhj8gaImqfGBThjP3oDAapgCNtt8kqNtORg2/wCWaHF3fRkV5A+y3zEp4nDJjx8+nOQEf4tCh8qfOBu8kyDijaAlKhookL5oc0uUG53jhK7OQmcVHC2ZIKGuGUZ3nc=; h=X-No-Relay:X-No-Relay:X-No-Relay:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.6] (5ec20b19.skybroadband.com [94.194.11.25]) by www.gondrom.org (Postfix) with ESMTPSA id 4E5941539000F; Tue, 5 Aug 2014 15:11:24 +0200 (CEST) Message-ID: <53E0D7FB.7050603@gondrom.org> Date: Tue, 05 Aug 2014 14:11:23 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: hadi@mojatatu.com References: <53E00686.7030909@gondrom.org> <53E0BC74.8090804@gondrom.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/KTGpWeqCvU8jx0Y6QuGLpdw_SHE Cc: draft-ietf-forces-protoextension.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-forces-protoextension-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 13:11:38 -0000 Thanks for your response. Thank you. I think my concerns have been heard and leave it to you whether you want to amend text in some places or not. Best wishes, Tobias On 05/08/14 13:55, Jamal Hadi Salim wrote: > Hi Tobias, > > On Tue, Aug 5, 2014 at 7:13 AM, Tobias Gondrom > wrote: >> Hi Jamal, >> >> thanks for the fast reply. >> And thank you for taking the time to answer my questions. >> >> Please see my answers only as my personal comments and I am no expert in >> the forces spec. So I might very well be wrong. >> > No worries, an extra pair of eyes with a different view always provides a > perspective we may have overlooked. > >>> Hrm. In a cluster of CEs where you have new + older CEs, yes - that is possible. >>> Caveat: The CEs are spec-ed to talk to each other on CE-CE plane. I would expect >>> what you described to be a "buggy" decision by the master CE. >>> Would text that describes this as a faulty setup be reasonable to add >>> to cover this? >> Yes. That might be a useful point. >> But please see my review questions only as personal comment. I would not >> want to make suggestions that go against the WG views. >> > Ok, will find a spot to discuss this. > >> Small add-on question: >> Not sure whether there are potentially two scenarios here: >> 1. the first as you described might be a "buggy" decision by a master CE >> to switching on the "only" new >> EXTENDEDRESULT-TLVs and by that switching off the old codes for the >> other old CEs. >> 2. wondering whether there might be a second scenario where a malicious >> person would intentionally try to insert one new CE and switch the FEs >> to EXTENDEDRESULT-TLVs to "blind" an existing "old" CE network to some >> of the error codes? >> > An arbitrary CE should not be able to join a cluster or win an election for > mastership without authentication and authorization. > i.e this is all covered by the trust issue i described earlier. > The FE has explicit trust with the CE. If that trust is compromised, security > breach is not limited to just this one issue. > The reason i described the other scenario as buggy is the CEs should be > able to coordinate amongst themselves if they have discrepancies > (although it is outside scope of ForCES to describe how that is achieved) > >> Yes. I understand. >> My concern is the following: AFAIK (and I might very well be wrong) so >> far the protocol mostly required many requests to receive the data from >> the FEs. Which is inefficient, but equally put symmetric compute >> resource requirements on both points (CE and FE). Aka, you would see a >> many requests to put a FE to work. With the new "TABLERANGE-TLV", it >> seems I can send one request which will trigger more computing activity >> on the FE. > Note that a single request to get many (possible) responses back already > exists *today*. Example, I can send one message to dump 10M table rows. > Nothing new there. ForCES says to restrict the transaction pipeline window size > (default of 1) so you cant send 10000 of those - and if you could, > then such requests > which will cause problems of starving other possible transactions because you > are hogging both bandwidth and cpu at the FE . It is likely a buggy > control application to do this. But these are *trusted* apps - they are just > bad code as opposed to malice and the transaction windowing should minimize > damage. > In our implementation (and specified in RFC 5811) we would lower the priority > of these dump responses in a work conserving way > if there are other high prio requests (like a SET for example). > > A simplistic approach to retrieve a table range would be to get all the 10M > table rows and then do the filtering to select 2000 rows in the controller. > This uses more bandwidth and possibly more CPU on the FE (slave) since it > has to dump *all* rows. > What you describe as "more computing activity" boils down to running the filter > i described above at the FE device instead of the controller. > In my experience this hasnt been an issue - but i am willing to be cautious. > >> So yes, you are right with your analogy between brain and >> legs and the trust relationship to the controller. However, before, your >> "brain" could send one command at a time to the legs, now it could send >> a whole marching program to the legs with one single request. And send >> multiple such requests in succession. Could that pose risks for denial >> of service (accidental or malicious) that might not have been >> anticipated in RFC5810? >> > Not any more than they do today. i.e Malice is solved by the general security > infrastructure; if a CE can get into the cluster, be authenticated and vetted as > legit, wins an election and starts telling the FE what to do, then we have > a bigger problem. > OTOH, bugs may exist and we gotta protect against those. > > Thanks again for taking the time. > > cheers, > jamal From nobody Tue Aug 5 19:31:15 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1001B2A68 for ; Tue, 5 Aug 2014 19:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOVz1oAdf0dO for ; Tue, 5 Aug 2014 19:31:12 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 908761B28B3 for ; Tue, 5 Aug 2014 19:31:12 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s762VAuL019825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Aug 2014 02:31:11 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s762VAfR000596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Aug 2014 02:31:10 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s762V7hq000461; Wed, 6 Aug 2014 02:31:08 GMT Received: from [10.154.121.87] (/10.154.121.87) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 05 Aug 2014 19:31:06 -0700 Message-ID: <53E1937A.9000502@oracle.com> Date: Tue, 05 Aug 2014 20:31:22 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20140508 Thunderbird/17.0.11 MIME-Version: 1.0 To: secdir@ietf.org References: <53E16AFC.4080108@oracle.com> In-Reply-To: <53E16AFC.4080108@oracle.com> X-Forwarded-Message-Id: <53E16AFC.4080108@oracle.com> Content-Type: multipart/alternative; boundary="------------080501050908040304060300" X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/hDn7h1-QMKHNzs_br4yJ_YTCLio Cc: draft-ietf-tictoc-security-requirements.all@tools.ietf.org Subject: [secdir] Review of draft-ietf-tictoc-security-requirements-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 02:31:14 -0000 This is a multi-part message in MIME format. --------------080501050908040304060300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Adding secdir, sorry for the duplicate post to this draft's list. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This informational draft describes the various security issues with time distribution protocols, specifically the Network Time Protocol (NTP) and the Precision Time Protocol (PTP). This is my second review of this draft and I believe that all of my comments/concerns have been addressed in this version of the draft. Thank you. General comments: None. Editorial comments: None. Shawn. -- --------------080501050908040304060300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
Adding secdir, sorry for the duplicate post to this draft's list.

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

This informational draft describes the various security issues with time
distribution protocols, specifically the Network Time Protocol (NTP) and
the Precision Time Protocol (PTP).  This is my second review of this draft
and I believe that all of my comments/concerns have been addressed in this
version of the draft.  Thank you.

General comments:

None.

Editorial comments:

None.

Shawn.
--
--------------080501050908040304060300-- From nobody Wed Aug 6 08:39:30 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC28F1B298C for ; Tue, 5 Aug 2014 03:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjzPuyjf6Stb for ; Tue, 5 Aug 2014 03:49:45 -0700 (PDT) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 133D51B2988 for ; Tue, 5 Aug 2014 03:49:40 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id hq11so1114549vcb.2 for ; Tue, 05 Aug 2014 03:49:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Avlqf72FhNja0q+E/FpM33R0U9nGLFDSm7sbRWk4awc=; b=OSeBQQriojIkuJ/zV4kdUZY1FjqQW74ddr+51F2dscFHyXUXW46PC94Tq4OxBG3xIa gZ9aGTh08TxlXXSgj69xtiDIJfAr/+lDK4tapWz4LroUYEakIptOlK+/ijUGssaVWbT7 onB0tYQnPJfQfdxZAztsd5hVXbI2e1B+nFRXoqe3va+N1gOepWoBBBQyYihG4TR6l0uM kpyK7KGhgVeVTE7eZwXUga0EbMhQhx8SiMU6ZeFqYfyGmQicmXJOoQ4B6TtK4vBs3o/l CmNt0qqoIWXadMIzsHwOUUo4oUPaeItr0QKbaazFzFYjWmiDA02SY7FstTPOFEtx/u68 5dLQ== X-Gm-Message-State: ALoCoQmT6rfGAg8YHCIMgVAbYAWzsQlRQQa944PmoMhetVTtyZPIixC2SI79m624YxJr4eJmSJF2 X-Received: by 10.52.248.232 with SMTP id yp8mr310450vdc.83.1407235780128; Tue, 05 Aug 2014 03:49:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.208.107 with HTTP; Tue, 5 Aug 2014 03:49:20 -0700 (PDT) In-Reply-To: <53E00686.7030909@gondrom.org> References: <53E00686.7030909@gondrom.org> From: Jamal Hadi Salim Date: Tue, 5 Aug 2014 06:49:20 -0400 Message-ID: To: Tobias Gondrom Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/GTufGQM8ybHRgSZPq2eohd1M_PE X-Mailman-Approved-At: Wed, 06 Aug 2014 08:39:26 -0700 Cc: draft-ietf-forces-protoextension.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-forces-protoextension-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 10:49:50 -0000 Hi Tobias, Thank you for the review. Comments in line. On Mon, Aug 4, 2014 at 6:17 PM, Tobias Gondrom 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 draft is standards track and describes a few extensions to ease > programmability and to improve wire efficiency of some transactions. It adds > extensions to the ForCES Protocol RFC5810 and RFC7121. > > The document appears mostly ready for publication. > > The security considerations section (section 6) only refers to RFC 5810. > > > 1 Nits and 3 Questions regarding the security section below: > > Nits: > - section 3.2.3.1. last paragraph: > s/writting/writing > Fixed. > Questions: > 1. section 3.2.3.1. last paragraph: > "On an FE which supports both RESULT-TLVs and EXTENDEDRESULT-TLVs, a > master CE can turn on support for extended results by setting the > value to 2 in which case the FE MUST switch over to sending only > EXTENDEDRESULT-TLVs." > > Not sure about the full network topology, but could that enable a master CE > to effectively make the replies of a FE unreadable to other old-version CEs > (which can only understand RESULT-TLVs) by switching on the "only" new > EXTENDEDRESULT-TLVs? > Hrm. In a cluster of CEs where you have new + older CEs, yes - that is possible. Caveat: The CEs are spec-ed to talk to each other on CE-CE plane. I would expect what you described to be a "buggy" decision by the master CE. Would text that describes this as a faulty setup be reasonable to add to cover this? > 2. with the New Codes in section 3.2.1. : > do any of the new more detailed error codes (e.g. "E_EMPTY | Table is > empty") pose a risk of data leakage of information detail that was not > intended to be disclosed in that detail in the original RFC 5810? > There is no new information per-se being sent. Implementations sent back different things like E_NOT_FOUND or E_INVALID_PATH etc before this and it was left up to the controller to interpret i.e no explicit coherency for what ended up being a common use case. Therefore E_EMPTY is providing a little more clarity. > 3. section 3.1.: > Could the new "TABLERANGE-TLV", which requires significantly more computing > on the receiver per request from the sender, enable an attacker for a type > of Denial of Service attack scenario? > Note: it is the controller that would be doing this. If your brain wants to attack your legs by punching them endlessly, not sure what those legs could do;-> (cant run unless brain tells you to). i.e there is explicit, unquestionable trust of the controller. If the controller is compromised, then we are talking about a different ballgame altogether (and nothing we can do here resolves that). I am not sure i agree on the "significant compute" statement[1]. You are right however that a not so good implementation doing the filtering at the source would suffer because it has to check for index validity. An implementation can reject table range requests by issuing a response of E_INVALID_TFLAGS (section 3.1) Probably we need to add a small discussion to describe this scenario as another one that would neccessitate the issuing of E_INVALID_TFLAGS? > > NOTE: though I reviewed the ID, I did not validate the XML structure in > appendix A. > At least one other person (the shepherd) has taken of this, so no worries. Thanks again for taking the time to review. cheers, jamal [1] The filter essentially does a table dump, checks what the index is and adds it to the response if it matches. > Thank you and best regards. > > Tobias > From nobody Wed Aug 6 08:39:32 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA0A1A8BAF for ; Tue, 5 Aug 2014 05:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5O2GrPG1la7 for ; Tue, 5 Aug 2014 05:56:07 -0700 (PDT) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 042FF1A0AFF for ; Tue, 5 Aug 2014 05:56:06 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id la4so1367238vcb.19 for ; Tue, 05 Aug 2014 05:56:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=qWVa2x7ecU004xoiTlIdv4IdbO4d9hZLjGXKFJaisXc=; b=OIp8sRJPfq1qCM8vK1la30hDy4TQzJHGEkfHPCPaskdci9lePu6cH2dkGBhT/Ve+Lh AqdcH1DjTXH4F3HLQ3aHeJsMrsuGxq24NQ10hos/vemFqVZEN15XV7s/laeILq1+6U5Y 14voadTuBpkzDVeAKtda/c5fc+Qzp5dPbe3v99Lw7TOx+m6wtvhpsV3xXYBrCjuMc9Ia N4mk2sdQu1EagKzuEsIm14dKDobOu4di/CHBFL2+deaDStZ27DSYHOA05Xr0gGgLur0q BA1lBR7JjGBwQgmR9XDWMlmso8H1/8PT3uzZ8XuUnXyEBvBqbmKv/v9Shm0m4EKAk7hf pz9A== X-Gm-Message-State: ALoCoQlM5LO6qV3PRCGAS8KdvNNOt7DiMjDDW2HsXv84qJ8sXQMzpqhcw/moyqKpujTs3xMIHxKB X-Received: by 10.220.122.132 with SMTP id l4mr3063128vcr.41.1407243365974; Tue, 05 Aug 2014 05:56:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.208.107 with HTTP; Tue, 5 Aug 2014 05:55:44 -0700 (PDT) In-Reply-To: <53E0BC74.8090804@gondrom.org> References: <53E00686.7030909@gondrom.org> <53E0BC74.8090804@gondrom.org> From: Jamal Hadi Salim Date: Tue, 5 Aug 2014 08:55:44 -0400 Message-ID: To: Tobias Gondrom Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/ZGlU5-SAAopuwdH3t3G1Pq1pLwI X-Mailman-Approved-At: Wed, 06 Aug 2014 08:39:26 -0700 Cc: draft-ietf-forces-protoextension.all@tools.ietf.org, The IESG , secdir Subject: Re: [secdir] secdir review of draft-ietf-forces-protoextension-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 12:56:08 -0000 Hi Tobias, On Tue, Aug 5, 2014 at 7:13 AM, Tobias Gondrom wrote: > Hi Jamal, > > thanks for the fast reply. > And thank you for taking the time to answer my questions. > > Please see my answers only as my personal comments and I am no expert in > the forces spec. So I might very well be wrong. > No worries, an extra pair of eyes with a different view always provides a perspective we may have overlooked. >> Hrm. In a cluster of CEs where you have new + older CEs, yes - that is possible. >> Caveat: The CEs are spec-ed to talk to each other on CE-CE plane. I would expect >> what you described to be a "buggy" decision by the master CE. >> Would text that describes this as a faulty setup be reasonable to add >> to cover this? > > Yes. That might be a useful point. > But please see my review questions only as personal comment. I would not > want to make suggestions that go against the WG views. > Ok, will find a spot to discuss this. > Small add-on question: > Not sure whether there are potentially two scenarios here: > 1. the first as you described might be a "buggy" decision by a master CE > to switching on the "only" new > EXTENDEDRESULT-TLVs and by that switching off the old codes for the > other old CEs. > 2. wondering whether there might be a second scenario where a malicious > person would intentionally try to insert one new CE and switch the FEs > to EXTENDEDRESULT-TLVs to "blind" an existing "old" CE network to some > of the error codes? > An arbitrary CE should not be able to join a cluster or win an election for mastership without authentication and authorization. i.e this is all covered by the trust issue i described earlier. The FE has explicit trust with the CE. If that trust is compromised, security breach is not limited to just this one issue. The reason i described the other scenario as buggy is the CEs should be able to coordinate amongst themselves if they have discrepancies (although it is outside scope of ForCES to describe how that is achieved) > Yes. I understand. > My concern is the following: AFAIK (and I might very well be wrong) so > far the protocol mostly required many requests to receive the data from > the FEs. Which is inefficient, but equally put symmetric compute > resource requirements on both points (CE and FE). Aka, you would see a > many requests to put a FE to work. With the new "TABLERANGE-TLV", it > seems I can send one request which will trigger more computing activity > on the FE. Note that a single request to get many (possible) responses back already exists *today*. Example, I can send one message to dump 10M table rows. Nothing new there. ForCES says to restrict the transaction pipeline window size (default of 1) so you cant send 10000 of those - and if you could, then such requests which will cause problems of starving other possible transactions because you are hogging both bandwidth and cpu at the FE . It is likely a buggy control application to do this. But these are *trusted* apps - they are just bad code as opposed to malice and the transaction windowing should minimize damage. In our implementation (and specified in RFC 5811) we would lower the priority of these dump responses in a work conserving way if there are other high prio requests (like a SET for example). A simplistic approach to retrieve a table range would be to get all the 10M table rows and then do the filtering to select 2000 rows in the controller. This uses more bandwidth and possibly more CPU on the FE (slave) since it has to dump *all* rows. What you describe as "more computing activity" boils down to running the filter i described above at the FE device instead of the controller. In my experience this hasnt been an issue - but i am willing to be cautious. >So yes, you are right with your analogy between brain and > legs and the trust relationship to the controller. However, before, your > "brain" could send one command at a time to the legs, now it could send > a whole marching program to the legs with one single request. And send > multiple such requests in succession. Could that pose risks for denial > of service (accidental or malicious) that might not have been > anticipated in RFC5810? > Not any more than they do today. i.e Malice is solved by the general security infrastructure; if a CE can get into the cluster, be authenticated and vetted as legit, wins an election and starts telling the FE what to do, then we have a bigger problem. OTOH, bugs may exist and we gotta protect against those. Thanks again for taking the time. cheers, jamal From nobody Wed Aug 6 08:39:35 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D223D1B2790 for ; Tue, 5 Aug 2014 06:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g09fqEMwvydR for ; Tue, 5 Aug 2014 06:22:08 -0700 (PDT) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 604D21B27A2 for ; Tue, 5 Aug 2014 06:22:08 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id hy4so1438184vcb.13 for ; Tue, 05 Aug 2014 06:22:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=IIWNOM3VQYHMqShO60/LwLppTE0Q9y744k4n8CWJzfA=; b=N/Aw5feStcuUlhf/eUG9UpDPppuGi2Rioe+CJqASM0t0CtNM4mEqeTfaLkOrHU53b5 r7YAntISEd0XEtVCCLtuFyC2kYcbDeMNszRpYappDO6HCXbMkMcGhXxlgVCRz57hCtY7 E08fKe0AdTh3DjvE2UJ5wfTOL0M6XQDzeR3VqRyMqXN1zxlDmf159wk5wgU7pULzKbKD Mywv/ZGFBqoLY0KDzhp8QMbY1Sq+ZqxakV8oSXu56EyxZh58+F+ihQO5b9Z0XjtxhnS7 YZz2P4UlM66XsAvXRhcZU1upIodQ6yUsLTx76sWncnSlcr1dwIzTnLPJDANphMsRA730 f0Yg== X-Gm-Message-State: ALoCoQnns3dyUvh2jZ/L8E73s6nAf7++vrfByZPVzb+vB+jbnSJkM7yuVcvplomyZll012vUVXvz X-Received: by 10.220.122.132 with SMTP id l4mr3289928vcr.41.1407244927396; Tue, 05 Aug 2014 06:22:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.208.107 with HTTP; Tue, 5 Aug 2014 06:21:47 -0700 (PDT) In-Reply-To: <53E0D7FB.7050603@gondrom.org> References: <53E00686.7030909@gondrom.org> <53E0BC74.8090804@gondrom.org> <53E0D7FB.7050603@gondrom.org> From: Jamal Hadi Salim Date: Tue, 5 Aug 2014 09:21:47 -0400 Message-ID: To: Tobias Gondrom Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/8W-MCKKluyETHeR88qts3FIAbEg X-Mailman-Approved-At: Wed, 06 Aug 2014 08:39:27 -0700 Cc: draft-ietf-forces-protoextension.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-forces-protoextension-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 13:22:14 -0000 Thanks Tobias. I will make the changes we discussed - wait for other reviews and amalgamate. The AD should be able to decide if we need a revised publication. cheers, jamal On Tue, Aug 5, 2014 at 9:11 AM, Tobias Gondrom wrote: > Thanks for your response. > Thank you. I think my concerns have been heard and leave it to you > whether you want to amend text in some places or not. > Best wishes, Tobias > > > On 05/08/14 13:55, Jamal Hadi Salim wrote: >> Hi Tobias, >> >> On Tue, Aug 5, 2014 at 7:13 AM, Tobias Gondrom >> wrote: >>> Hi Jamal, >>> >>> thanks for the fast reply. >>> And thank you for taking the time to answer my questions. >>> >>> Please see my answers only as my personal comments and I am no expert in >>> the forces spec. So I might very well be wrong. >>> >> No worries, an extra pair of eyes with a different view always provides a >> perspective we may have overlooked. >> >>>> Hrm. In a cluster of CEs where you have new + older CEs, yes - that is possible. >>>> Caveat: The CEs are spec-ed to talk to each other on CE-CE plane. I would expect >>>> what you described to be a "buggy" decision by the master CE. >>>> Would text that describes this as a faulty setup be reasonable to add >>>> to cover this? >>> Yes. That might be a useful point. >>> But please see my review questions only as personal comment. I would not >>> want to make suggestions that go against the WG views. >>> >> Ok, will find a spot to discuss this. >> >>> Small add-on question: >>> Not sure whether there are potentially two scenarios here: >>> 1. the first as you described might be a "buggy" decision by a master CE >>> to switching on the "only" new >>> EXTENDEDRESULT-TLVs and by that switching off the old codes for the >>> other old CEs. >>> 2. wondering whether there might be a second scenario where a malicious >>> person would intentionally try to insert one new CE and switch the FEs >>> to EXTENDEDRESULT-TLVs to "blind" an existing "old" CE network to some >>> of the error codes? >>> >> An arbitrary CE should not be able to join a cluster or win an election for >> mastership without authentication and authorization. >> i.e this is all covered by the trust issue i described earlier. >> The FE has explicit trust with the CE. If that trust is compromised, security >> breach is not limited to just this one issue. >> The reason i described the other scenario as buggy is the CEs should be >> able to coordinate amongst themselves if they have discrepancies >> (although it is outside scope of ForCES to describe how that is achieved) >> >>> Yes. I understand. >>> My concern is the following: AFAIK (and I might very well be wrong) so >>> far the protocol mostly required many requests to receive the data from >>> the FEs. Which is inefficient, but equally put symmetric compute >>> resource requirements on both points (CE and FE). Aka, you would see a >>> many requests to put a FE to work. With the new "TABLERANGE-TLV", it >>> seems I can send one request which will trigger more computing activity >>> on the FE. >> Note that a single request to get many (possible) responses back already >> exists *today*. Example, I can send one message to dump 10M table rows. >> Nothing new there. ForCES says to restrict the transaction pipeline window size >> (default of 1) so you cant send 10000 of those - and if you could, >> then such requests >> which will cause problems of starving other possible transactions because you >> are hogging both bandwidth and cpu at the FE . It is likely a buggy >> control application to do this. But these are *trusted* apps - they are just >> bad code as opposed to malice and the transaction windowing should minimize >> damage. >> In our implementation (and specified in RFC 5811) we would lower the priority >> of these dump responses in a work conserving way >> if there are other high prio requests (like a SET for example). >> >> A simplistic approach to retrieve a table range would be to get all the 10M >> table rows and then do the filtering to select 2000 rows in the controller. >> This uses more bandwidth and possibly more CPU on the FE (slave) since it >> has to dump *all* rows. >> What you describe as "more computing activity" boils down to running the filter >> i described above at the FE device instead of the controller. >> In my experience this hasnt been an issue - but i am willing to be cautious. >> >>> So yes, you are right with your analogy between brain and >>> legs and the trust relationship to the controller. However, before, your >>> "brain" could send one command at a time to the legs, now it could send >>> a whole marching program to the legs with one single request. And send >>> multiple such requests in succession. Could that pose risks for denial >>> of service (accidental or malicious) that might not have been >>> anticipated in RFC5810? >>> >> Not any more than they do today. i.e Malice is solved by the general security >> infrastructure; if a CE can get into the cluster, be authenticated and vetted as >> legit, wins an election and starts telling the FE what to do, then we have >> a bigger problem. >> OTOH, bugs may exist and we gotta protect against those. >> >> Thanks again for taking the time. >> >> cheers, >> jamal > From nobody Thu Aug 7 00:51:23 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 789C41B2974 for ; Thu, 7 Aug 2014 00:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.578 X-Spam-Level: * X-Spam-Status: No, score=1.578 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTXqD8SFqccl for ; Thu, 7 Aug 2014 00:51:20 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E6531B2900 for ; Thu, 7 Aug 2014 00:51:19 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s777pGER001702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 7 Aug 2014 10:51:16 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s777pGfk023737; Thu, 7 Aug 2014 10:51:16 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21475.12276.264388.338814@fireball.kivinen.iki.fi> Date: Thu, 7 Aug 2014 10:51:16 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/or6fjUoSmTZPYS-KmPso3zWdYcs Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 07:51:22 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Dan Harkins is next in the rotation. For telechat 2014-08-07 Reviewer LC end Draft Charlie Kaufman TR2014-07-02 draft-ietf-6man-multicast-addr-arch-update-07 Warren Kumari T 2014-07-02 draft-ietf-netext-pmip-cp-up-separation-05 Alexey Melnikov T 2014-07-04 draft-ietf-p2psip-service-discovery-14 Eric Osterweil T 2014-07-15 draft-ietf-l2vpn-etree-frwk-07 Zach Shelby T 2014-07-21 draft-ietf-trill-oam-fm-07 Melinda Shore T 2014-08-01 draft-ietf-websec-key-pinning-19 Ondrej Sury T 2014-07-15 draft-kivinen-ipsecme-signature-auth-07 Sean Turner T 2014-07-17 draft-ietf-appsawg-nullmx-07 For telechat 2014-08-21 Shaun Cooley T 2014-08-08 draft-ietf-tram-auth-problems-04 Alan DeKok T 2014-08-08 draft-ietf-appsawg-json-merge-patch-06 Shawn Emery T 2014-08-14 draft-ietf-core-groupcomm-21 Dorothy Gellert T 2014-08-08 draft-ietf-core-observe-14 Catherine Meadows TR2014-08-20 draft-ietf-paws-protocol-14 Brian Weis T 2014-07-29 draft-ietf-dnsop-rfc6304bis-04 Klaas Wierenga T 2014-07-29 draft-ietf-dnsop-as112-dname-04 For telechat 2014-09-18 Sam Hartman T 2014-06-23 draft-ietf-dnsop-child-syncronization-02 Last calls and special requests: Derek Atkins 2014-08-09 draft-ietf-l3vpn-pmsi-registry-03 Donald Eastlake 2014-08-08 draft-ietf-conex-abstract-mech-12 Phillip Hallam-Baker 2014-08-11 draft-ietf-netmod-snmp-cfg-06 Steve Hanna 2014-08-13 draft-ietf-rmcat-cc-requirements-05 Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-06 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Ondrej Sury 2014-07-30 draft-ietf-ipfix-text-adt-09 Sam Weiler 2014-08-12 draft-ietf-karp-bfd-analysis-05 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-11 Tom Yu 2014-08-09 draft-ietf-forces-model-extension-03 -- kivinen@iki.fi From nobody Thu Aug 7 02:44:54 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F4D1B2A20; Thu, 7 Aug 2014 02:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CszkVgugyV03; Thu, 7 Aug 2014 02:44:51 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D3451B28C6; Thu, 7 Aug 2014 02:44:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1669; q=dns/txt; s=iport; t=1407404691; x=1408614291; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=+kAIljJgQ30+HHp564jvu+1EbS19vzHoQlvVQpAVbQE=; b=ZB5larAejicEg02x4pfEfoJMN9eYySm8A3FXyk6vifoZ6IIPe9IQT3Sd 36Kny0OU9ISGqmY6NvcNDH7ySOH15/jy2ncRuD0/5LEgOu/BcouGynO0/ jO769EWW7GyJevw9eAMFneoaD5ityDQY0sTzd8+vg12xTC7C/M33lcQxN o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFADBK41OtJV2c/2dsb2JhbABagw2BLdUsFneECoELAYEAJwQBiFTDdReOdIQOgRwFnBiUbYNXgXBC X-IronPort-AV: E=Sophos;i="5.01,816,1400025600"; d="scan'208";a="345528567" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 07 Aug 2014 09:44:50 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s779iovi007391 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Aug 2014 09:44:50 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.214]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Thu, 7 Aug 2014 04:44:50 -0500 From: "Klaas Wierenga (kwiereng)" To: "draft-ietf-dnsop-as112-dnam.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Thread-Topic: secdir review of draft-ietf-dnsop-as112-dname-04 Thread-Index: AQHPsiQ7P55iCfHuK0WU2psSv6HHWw== Date: Thu, 7 Aug 2014 09:44:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.110.132] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/rLKZAHPCHLfszyKAesFperbdYHI Subject: [secdir] secdir review of draft-ietf-dnsop-as112-dname-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 09:44:53 -0000 Hi, I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. I believe this document is "ready with issues." The document describes adding and dropping of zones for AS112, the zone tha= t is meant rot act as a sinkhole for reverse lookups for addresses that are= for private-use only. I think the document is clearly written and with my limited understanding o= f DNS it all seems to make sense from a technical point of view.=20 What I am not so sure of however is the statement in the security considera= tions:=20 "This document presents no known additional security concerns to the Intern= et. For security considerations relating to AS112 service in general, see RFC63= 04bis]." And in the introduction "The AS112 project does not accommodate the addition and removal of DNS zones elegantly. Since additional zones of definitively local significance are known to exist=94 It appears to me that moving from a static list of well known ranges as def= ined in 6304bis to a dynamic adding and dropping of IP-address ranges that = are "of definitively local significance=94 is prone to error, potentially leading to blackholing val= id address space, either on purpose or by accident. I may show my ignorance= here, but I feel that a discussions as to why that risk doesn=92t exist is= warranted.=20 Hope this helps, Klaas From nobody Thu Aug 7 02:45:17 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6231B28C6; Thu, 7 Aug 2014 02:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7-JQhVDHLs3; Thu, 7 Aug 2014 02:45:06 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B5911B2A3E; Thu, 7 Aug 2014 02:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1672; q=dns/txt; s=iport; t=1407404703; x=1408614303; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=fczTejjFbCATVq7sdkYX9aaNzb5cW/usZi+feUa36K0=; b=EDyuragKEyk9XhneMVUmw6ijE8253uW151C+l+i6X72LSUZFvnoldbYz EKDp9LQQRj8k+QwUkPzNmPf/GOmKjDiZ1Yc6DDacAKo3jEp4fC4syYCri jxPLqy9G7Ek+0MSBy+ovpAavhkDjnNr079X4vcXj/BO13YTQl4YnIPcmp M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAGxK41OtJA2I/2dsb2JhbABagw2BLdUsFneECoELAYEAJwQBiFTDdheOdIQOgRwFnBiUbYNXgXBC X-IronPort-AV: E=Sophos;i="5.01,816,1400025600"; d="scan'208";a="345695938" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-7.cisco.com with ESMTP; 07 Aug 2014 09:44:45 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s779ijBq002234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Aug 2014 09:44:45 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.214]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Thu, 7 Aug 2014 04:44:45 -0500 From: "Klaas Wierenga (kwiereng)" To: "draft-ietf-dnsop-as112-dnam.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Thread-Topic: secdir review of draft-ietf-dnsop-as112-dname-04 Thread-Index: AQHPsiQ3f8OY5L4Ee0OTmhRUsiOAuQ== Date: Thu, 7 Aug 2014 09:44:44 +0000 Message-ID: <04F423A7-DEEC-47B0-8FB7-61D14F2D89EB@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.110.132] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/TPcfmjEyE9edvGVDGqsRX3xefjE Subject: [secdir] secdir review of draft-ietf-dnsop-as112-dname-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 09:45:10 -0000 Hi, I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. I believe this document is "ready with issues." The document describes adding and dropping of zones for AS112, the zone tha= t is meant rot act as a sinkhole for reverse lookups for addresses that are= for private-use only. I think the document is clearly written and with my limited understanding o= f DNS it all seems to make sense from a technical point of view.=20 What I am not so sure of however is the statement in the security considera= tions:=20 "This document presents no known additional security concerns to the Intern= et. For security considerations relating to AS112 service in general, see RFC63= 04bis]." And in the introduction "The AS112 project does not accommodate the addition and removal of DNS zones elegantly. Since additional zones of definitively local significance are known to exist=94 It appears to me that moving from a static list of well known ranges as def= ined in 6304bis to a dynamic adding and dropping of IP-address ranges that = are "of definitively local significance=94 is prone to error, potentially leading to blackholing va= lid address space, either on purpose or by accident. I may show my ignoranc= e here, but I feel that a discussions as to why that risk doesn=92t exist i= s warranted.=20 Hope this helps, Klaas From nobody Thu Aug 7 03:31:05 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB88B1B27E5; Thu, 7 Aug 2014 03:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.502 X-Spam-Level: X-Spam-Status: No, score=-16.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foQHiKCiDKqs; Thu, 7 Aug 2014 03:30:57 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBFD21A00EA; Thu, 7 Aug 2014 03:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2136; q=dns/txt; s=iport; t=1407407457; x=1408617057; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=y6mHSe/A5Lqofg+nQsc17aVTk/6IEjBRvK6VKBW/gpo=; b=ETitYio9YMjAiDK70myHFEqwV8oa30GKgt6pMQmuziH6DdXJlJNdantx JwSAXIC13vyv4w04AdU+dRNDxn7OS/XrW5ykXQSx/DSr+8Np2cSW2Rmfj RZoQlA2gwHF8GYxNVXOZ9qCTTQahGnhnXucABh7b03I8RCmAup17XO6qR E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAPVU41OtJV2d/2dsb2JhbABagw1SV68LnT8KhnVTAYEWFneEAwEBAQMBAQEBaxALAgEIGC4nCyUCBAESiDoIDcN6F450JTqDL4EcBZUwhmiBVJMZg1dsgQQ X-IronPort-AV: E=Sophos;i="5.01,817,1400025600"; d="scan'208";a="67259686" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP; 07 Aug 2014 10:30:35 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s77AUYpg001436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Aug 2014 10:30:34 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.214]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Thu, 7 Aug 2014 05:30:34 -0500 From: "Klaas Wierenga (kwiereng)" To: "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-dnsop-as112-dname.all@tools.ietf.org" Thread-Topic: [secdir] secdir review of draft-ietf-dnsop-as112-dname-04 Thread-Index: AQHPsiqeTZ2SSkFU00uUSw5pbueKeQ== Date: Thu, 7 Aug 2014 10:30:33 +0000 Message-ID: <196F3D56-E65E-4870-A3BA-07666488B6CA@cisco.com> References: <04F423A7-DEEC-47B0-8FB7-61D14F2D89EB@cisco.com> In-Reply-To: <04F423A7-DEEC-47B0-8FB7-61D14F2D89EB@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/xWB0pQH-dUnFNfxDgXl92OdkD8k Subject: Re: [secdir] secdir review of draft-ietf-dnsop-as112-dname-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 10:30:59 -0000 Sorry, dropped a letter in copy/paste of draft name=20 Sent from my iPad > On 07 Aug 2014, at 11:45, "Klaas Wierenga (kwiereng)" wrote: >=20 > Hi, >=20 > 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 > I believe this document is "ready with issues." >=20 > The document describes adding and dropping of zones for AS112, the zone t= hat is meant rot act as a sinkhole for reverse lookups for addresses that a= re for private-use only. >=20 > I think the document is clearly written and with my limited understanding= of DNS it all seems to make sense from a technical point of view.=20 >=20 > What I am not so sure of however is the statement in the security conside= rations:=20 >=20 > "This document presents no known additional security concerns to the Inte= rnet. > For security considerations relating to AS112 service in general, see RFC= 6304bis]." >=20 > And in the introduction >=20 > "The AS112 project does not accommodate the addition and removal of > DNS zones elegantly. Since additional zones of definitively local > significance are known to exist=94 >=20 > It appears to me that moving from a static list of well known ranges as d= efined in 6304bis to a dynamic adding and dropping of IP-address ranges tha= t are "of definitively local > significance=94 is prone to error, potentially leading to blackholing v= alid address space, either on purpose or by accident. I may show my ignoran= ce here, but I feel that a discussions as to why that risk doesn=92t exist = is warranted.=20 >=20 > Hope this helps, >=20 > Klaas >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Thu Aug 7 03:33:29 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5731B27E5; Thu, 7 Aug 2014 03:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KeS49imd5Tzj; Thu, 7 Aug 2014 03:33:26 -0700 (PDT) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id D56BC1A00EA; Thu, 7 Aug 2014 03:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1407407604; d=isode.com; s=selector; i=@isode.com; bh=lsQabdr7+Ydvx5jXUplLXCKvb0G7AXHJJ1bzLqC6sQI=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=rHRSDC2s3G3yyCQ7/V8FvHotWwwkKcIJdVxmZCADbeSn+FVPqmd5ArSyeIKa+VXh/bhKig hfSBBUOpGkSS5/WdZ2Eq4VC5tIQDCQOMpp3U3YdZyrpuySidWxPW35UtqJZTpsnWQf3PSt hW+uoQ4pWKfWcJ0btY+rPbo8/vaECqY=; Received: from [192.168.0.4] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 7 Aug 2014 11:33:24 +0100 Message-ID: <53E355FB.5000101@isode.com> Date: Thu, 07 Aug 2014 11:33:31 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 To: draft-ietf-p2psip-service-discovery.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/SAixIKwWdv-4LVYBuFYZ1d49fSA Subject: [secdir] SecDir review of draft-ietf-p2psip-service-discovery-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 10:33:27 -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. I believe this document is "ready with issues." REsource LOcation and Discovery (RELOAD) does not define a generic service discovery mechanism as a part of the base protocol. This document defines how the Recursive Distributed Rendezvous (ReDiR) service discovery mechanism used in OpenDHT can be applied to RELOAD overlays to provide a generic service discovery mechanism. The Security Considerations section points to the Security Considerations section of RFC 6940, which is quite extensive and relevant. The document also defines a new access control policy called NODE-ID-MATCH. As only nodes that own service discovery information can update it, it looks like there are no additional security issue raised beyond what is already covered in RFC 6940. As the information is public, I can't think of any privacy concerns. While I was able to follow the document, I think it lacks attention to details which are not obvious for somebody not following the technology. Minor issues that should be easy to fix: On page 4: H(x) - missing reference to SHA-1. Any specific properties required from H(x)? Namespace - missing reference to UTF-8. On page 6: H() with multiple arguments is not defined, especially if they can be both strings and integers (what byte order)? b' is not defined. Typo in the description? In 4.2 I read "the mode of those depths". Can you explain what this means? Or is this a typo? From nobody Thu Aug 7 05:34:01 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A2D1B278D; Thu, 7 Aug 2014 05:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_19=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6xKZLw8Sduf; Thu, 7 Aug 2014 05:33:44 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C066E1B278A; Thu, 7 Aug 2014 05:33:43 -0700 (PDT) X-AuditID: c1b4fb3a-f79da6d0000008c7-db-53e372252e8e Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 84.AB.02247.52273E35; Thu, 7 Aug 2014 14:33:41 +0200 (CEST) Received: from ESESSMB305.ericsson.se ([169.254.5.45]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0174.001; Thu, 7 Aug 2014 14:33:41 +0200 From: =?iso-8859-1?Q?Jouni_M=E4enp=E4=E4?= To: Alexey Melnikov , "draft-ietf-p2psip-service-discovery.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Thread-Topic: SecDir review of draft-ietf-p2psip-service-discovery-14 Thread-Index: AQHPsiuMYv+juuCA2UmiRnXpK3H7mZvFEa+A Date: Thu, 7 Aug 2014 12:33:40 +0000 Message-ID: <27112A697EB8204D9943EAB8A0E16B7110865DB6@ESESSMB305.ericsson.se> References: <53E355FB.5000101@isode.com> In-Reply-To: <53E355FB.5000101@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM+Jvja5q0eNgg+Xz1CxmrC6yuHZvNaPF jD8TmS0+LHzI4sDisWTJTyaPU82GHl8uf2YLYI7isklJzcksSy3St0vgyniz/RljwRaJimnH +lkbGHcLdzFyckgImEhcWbKHDcIWk7hwbz2QzcUhJHCUUeLU5gcsEM4iRom9a3YxglSxCbhL HL75kxUkISLwjlHi6eUeJpCEsICLxLt/01hBbBEBV4n/fZ3MXYwcQLaRxKNtnCBhFgEViZ5r G9lBbF4BX4lVkzpYQGwhAQ2JvpWLGUHKOQU0JbomaIGEGYEO+n5qDdh0ZgFxiVtP5jNBHCog sWTPeWYIW1Ti5eN/rBC2osTHV/sYIer1JG5MncIGYWtLLFv4mhliraDEyZlPWCYwis5CMnYW kpZZSFpmIWlZwMiyilG0OLW4ODfdyEgvtSgzubg4P08vL7VkEyMwgg5u+W21g/Hgc8dDjAIc jEo8vAlLHwULsSaWFVfmHmKU5mBREuddeG5esJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZG tYWzJbeHLiifWeraY/TwtMzuV3fmhpgGTivf6C6YsDLp/426nObtf648mXLgCPO2uomMbz58 eSB736Cv6JsFy+K95zia24463J9woUQgpHTH6qMex9b5q2peObHi42OhWxvWXzm84iDjkhKF qc/+XDuuqdWaut5sVX1Q1Bklloecl7Ssrl+qMFFiKc5INNRiLipOBADt8nFogQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/ObLwSDar_U9u_2-YRKTRMabR9vw Subject: Re: [secdir] SecDir review of draft-ietf-p2psip-service-discovery-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 12:33:46 -0000 Hi, Thanks for the comments! Please find my answers inline below. Regards, Jouni > -----Original Message----- > From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] > Sent: 7. elokuuta 2014 13:34 > To: draft-ietf-p2psip-service-discovery.all@tools.ietf.org; iesg@ietf.org= ; > secdir@ietf.org > Subject: SecDir review of draft-ietf-p2psip-service-discovery-14 >=20 > Hi, >=20 > I have reviewed this document as part of the security directorate's ongoi= ng > effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security a= rea > directors. Document editors and WG chairs should treat these comments ju= st > like any other last call comments. >=20 > I believe this document is "ready with issues." >=20 > REsource LOcation and Discovery (RELOAD) does not define a generic servic= e > discovery mechanism as a part of the base protocol. This document define= s > how the Recursive Distributed Rendezvous (ReDiR) service discovery > mechanism used in OpenDHT can be applied to RELOAD overlays to provide a > generic service discovery mechanism. >=20 > The Security Considerations section points to the Security Considerations > section of RFC 6940, which is quite extensive and relevant. >=20 > The document also defines a new access control policy called NODE-ID-MATC= H. > As only nodes that own service discovery information can update it, it lo= oks like > there are no additional security issue raised beyond what is already cove= red in > RFC 6940. As the information is public, I can't think of any privacy conc= erns. >=20 > While I was able to follow the document, I think it lacks attention to de= tails > which are not obvious for somebody not following the technology. > Minor issues that should be easy to fix: >=20 > On page 4: H(x) - missing reference to SHA-1. Any specific properties r= equired > from H(x)? I will add a reference to SHA-1. The requirements are the same as in the RE= LOAD base specification (RFC 6940). > Namespace - missing reference to UTF-8. Ok, I'll add that reference as well. > On page 6: H() with multiple arguments is not defined, especially if th= ey can > be both strings and integers (what byte order)? b' is not defined. Typo i= n the > description? I will clarify this in the next revision of the draft. H(namespace,level,j)= refers to taking a hash over a concatenated string consisting of the names= pace (string), level in the ReDiR tree (integer), and the node location j (= integer).=20 Related to byte order, would it be sufficient/correct to say that it is big= -endian?=20 And you are right, b' was not defined in the draft. It refers to the numbe= r of the interval within a given tree node at a given level in the ReDiR tr= ee. > In 4.2 I read "the mode of those depths". Can you explain what this means= ? Or > is this a typo? Mode (statistics) refers to the value that appears most often in a set of d= ata. I will add also this definition to the next revision of the draft. From nobody Thu Aug 7 06:04:17 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C26CC1B29B1; Thu, 7 Aug 2014 06:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_19=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQws4JPpAlXX; Thu, 7 Aug 2014 06:04:13 -0700 (PDT) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id C3C011B29CB; Thu, 7 Aug 2014 06:04:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1407416652; d=isode.com; s=selector; i=@isode.com; bh=O1D2YQK5YUH/UbobUZSJF1AgoxDhGt/yfy52H6QkH5A=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=lztFywP5/lwOEI5OGmRDFRmr/VOacBmB4y1Pw2/4HmlhwZJBLxkiH0VX7rTvI9jJSMA8jB HKojCgo6lK4JrFAUWlqy8g/Jrz0OVWMXf22+Jd6shjhcKontiKTQ5qERv8pAelnLuXW3vl rvdRYYa3IiuzNtrkFj7bfFQCmFccckU=; Received: from [172.20.1.47] ((unknown) [217.34.220.158]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 7 Aug 2014 14:04:11 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <53E37953.8030502@isode.com> Date: Thu, 07 Aug 2014 14:04:19 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 To: =?ISO-8859-1?Q?Jouni_M=E4enp=E4=E4?= , "draft-ietf-p2psip-service-discovery.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" References: <53E355FB.5000101@isode.com> <27112A697EB8204D9943EAB8A0E16B7110865DB6@ESESSMB305.ericsson.se> In-Reply-To: <27112A697EB8204D9943EAB8A0E16B7110865DB6@ESESSMB305.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/wjlYjW0eKceVE4-iQW4GYKc18-Q Subject: Re: [secdir] SecDir review of draft-ietf-p2psip-service-discovery-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 13:04:14 -0000 On 07/08/2014 13:33, Jouni M=E4enp=E4=E4 wrote: > Hi, Hi, > Thanks for the comments! Please find my answers inline below. > > Regards, > Jouni > >> -----Original Message----- >> From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] >> Sent: 7. elokuuta 2014 13:34 >> To: draft-ietf-p2psip-service-discovery.all@tools.ietf.org; iesg@ietf.org= ; >> secdir@ietf.org >> Subject: SecDir review of draft-ietf-p2psip-service-discovery-14 [snip] >> While I was able to follow the document, I think it lacks attention to de= tails >> which are not obvious for somebody not following the technology. >> Minor issues that should be easy to fix: >> >> On page 4: H(x) - missing reference to SHA-1. Any specific properties = required >> from H(x)? > I will add a reference to SHA-1. The requirements are the same as in the R= ELOAD base specification (RFC 6940). >> Namespace - missing reference to UTF-8. > Ok, I'll add that reference as well. > >> On page 6: H() with multiple arguments is not defined, especially if t= hey can >> be both strings and integers (what byte order)? b' is not defined. Typo i= n the >> description? > I will clarify this in the next revision of the draft. H(namespace,level,j= ) refers to taking a hash over a concatenated string consisting of the names= pace (string), level in the ReDiR tree (integer), and the node location j (i= nteger). > > Related to byte order, would it be sufficient/correct to say that it is bi= g-endian? Yes, although I prefer "network byte order" :-). > And you are right, b' was not defined in the draft. It refers to the numb= er of the interval within a given tree node at a given level in the ReDiR tr= ee. Ok. Please add the definition. >> In 4.2 I read "the mode of those depths". Can you explain what this means= ? Or >> is this a typo? > Mode (statistics) refers to the value that appears most often in a set of = data. I will add also this definition to the next revision of the draft. Right. Yes, that would help. From nobody Thu Aug 7 07:32:34 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A1B1B2B7E; Thu, 7 Aug 2014 07:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lHaOXR4Itwq; Thu, 7 Aug 2014 07:32:26 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0879B1B2B87; Thu, 7 Aug 2014 07:32:15 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A639B80048; Thu, 7 Aug 2014 10:32:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1407421933; bh=epX8Helxj1QJrhTmIusStRD7bVWG7RvOItS+AJJjcLs=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=CT6pipVkrkvo6BTyDRQTajYPp5CiO9ti2EzVFTkCLZcAL/k5s1loMTXXRMEm6qUhy SkrBQqgTvrd2kHkEIDQc65mCL4AnTwVMh884Efg1+kQRvUOExMQjVIQ4FBPbNMOBwT JhZ7H7EMJA2aFms6w9HYe1T0/XUbTENyJ1Db51SE= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s77EWBel029444; Thu, 7 Aug 2014 10:32:12 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 7 Aug 2014 10:32:11 -0400 (EDT) From: Paul Wouters To: "Klaas Wierenga (kwiereng)" In-Reply-To: <04F423A7-DEEC-47B0-8FB7-61D14F2D89EB@cisco.com> Message-ID: References: <04F423A7-DEEC-47B0-8FB7-61D14F2D89EB@cisco.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/vVl8bgT6dMUCXux-Bv1MnKOiXcQ Cc: "draft-ietf-dnsop-as112-dnam.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-dnsop-as112-dname-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 14:32:30 -0000 On Thu, 7 Aug 2014, Klaas Wierenga (kwiereng) wrote: > For security considerations relating to AS112 service in general, see RFC6304bis]." > > And in the introduction > > "The AS112 project does not accommodate the addition and removal of > DNS zones elegantly. Since additional zones of definitively local > significance are known to exist” > > It appears to me that moving from a static list of well known ranges as defined in 6304bis to a dynamic adding and dropping of IP-address ranges that are "of definitively local > significance” is prone to error, potentially leading to blackholing valid address space, either on purpose or by accident. I may show my ignorance here, but I feel that a discussions as to why that risk doesn’t exist is warranted. Actually, the static list is much more problematic. Mostly because some AS112 instances would not yet have the new addition, while other AS112 instances would, and the replies would be inconsistent. By using the DNAME protocol, it makes anything thrown at an AS112 work. Anyone else throwing something in would still cause less packets on the internet than those DNS packets leaking out the regular DNS infrastructure. For instance, ISPs could run an AS112 instance to take all RFC1918 queries. When new ranges are added (like 100.64.0.0/16) the ISP does not even need to update their AS112 instance (they have to do so now). The document's main purpose is to get rid of that bad static list. Because it is static, an ISP cannot even really add anything to it, without causing inconsistency. The only people that can make a mistake to "null route" their domain into AS112 are the owners of the domain. Don't configure NS records that point to AS112 and you are fine. Paul From nobody Thu Aug 7 19:04:51 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2CBC1A03F7; Thu, 7 Aug 2014 19:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Es6iUs-UOKkO; Thu, 7 Aug 2014 19:04:46 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 708FF1A03FF; Thu, 7 Aug 2014 19:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1759; q=dns/txt; s=iport; t=1407463486; x=1408673086; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=duDq+YENeWZXZ/GAIF4++mCH4INg265ZRdDHIoIS2s8=; b=KWBP3QguFUreP+dUbCBjPjhrlMPVnu4DGfB/zB83qZ8eG78+rgi2Q1Nn /GeIY7oZo2O+8M/9YIWJh4P+6K6CnBezefWkWVbd+BEQFkgVJ9dg9GU8W sfWoJJkorMq7zilYJGB1mVYlHiJKXO6jYf7FU4R7KQ51PsCGclV+YKrT7 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMFACgv5FOtJV2b/2dsb2JhbABagw2vIAEBAQIBBQFuAaUugRcWd4REP4E+AYhUxBcXhXyIeFiDNoEcBYsWkQWHJI1Mg3cdgTM X-IronPort-AV: E=Sophos;i="5.01,821,1400025600"; d="scan'208";a="345752328" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 08 Aug 2014 02:04:46 +0000 Received: from [10.154.161.115] ([10.154.161.115]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s7824icn004489 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Aug 2014 02:04:45 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Aug 2014 19:04:44 -0700 Message-Id: To: "secdir@ietf.org" , The IESG Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/w9Qb-H7Xah1iD9t7W4lhgMiE5J0 Cc: draft-ietf-dnsop-rfc6304bis.all@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-dnsop-rfc6304bis-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 02:04:48 -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 replaces RFC 6304, which describes AS112 Nameserver = operations. AS112 nameservers are responsible for answering DNS reverse = lookup to private-use queries that somehow leaked out of private network = into the Internet. RFC 6304 described the operations for these DNS name = servers handling these queries. The main contribution of the present = document is support for a new DNAME redirection zone defined in = draft-ietf-dnsop-as112-dname-03, including adding it to the sample BIND9 = configurations. It also updates the BIND9 configurations to support = IPv6, and includes a number of new IANA actions. Although I have a limited DNS background, the advice in this document = appears to be conservative such that attacks on or using AS112 name = servers are mitigated as much as possible in the absence of DNSSEC.=20 The security considerations section ends with a statement that DNSSEC is = unlikely to be effective for AS112 name servers and I believe the = rationale is accurate. Any entity wishing to provide an AS112 name = server to provide a service of replying to private-use queries is = encouraged to do so. Because AS112 name servers are announced via = anycast, all AS112 name servers would be required to use a single public = key. This indicates that the corresponding private key would need to be = widely available, which rather defeats its purpose. Brian= From nobody Fri Aug 8 19:24:27 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE841A0A9D for ; Fri, 8 Aug 2014 19:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mrzguq3ZcTGe for ; Fri, 8 Aug 2014 19:24:23 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 301671A0A9C for ; Fri, 8 Aug 2014 19:24:23 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s792OLZL013423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 9 Aug 2014 02:24:22 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s792OKke014726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Aug 2014 02:24:21 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s792OJZa000996; Sat, 9 Aug 2014 02:24:19 GMT Received: from shawn-emerys-computer.local (/75.166.175.246) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 08 Aug 2014 19:24:18 -0700 Message-ID: <53E5864D.7040809@oracle.com> Date: Fri, 08 Aug 2014 20:24:13 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: secdir@ietf.org References: <53E1937A.9000502@oracle.com> In-Reply-To: <53E1937A.9000502@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/jtvAS-y4SoIBB0dhTqeRfQMl9aE Cc: draft-ietf-core-groupcomm.all@tools.ietf.org Subject: [secdir] Review of draft-ietf-core-groupcomm-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 02:24:24 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This informational draft provides guidance on CoAP (Constrained Application Protocol) communication when using multiple recipients (i.e. multicast). The security considerations section does exist and does disclose that CoAP group communication (i.e. multicast transmissions) does lack a security mode and references RFC 7252 for the various attacks. CoAP relies upon DTLS, which does not currently have a standardized solution for multicast communication. The draft goes on to state the various threats and how to mitigate against said attacks. It discusses possible future methods to protect multicast transmissions, such as draft-keoh-dice-multicast-security. The security considerations does also have a separate section on pervasive monitoring, which I thought was a good idea, but not just for this draft... General comments: None. Editorial comments: Please expand the first occurrence of CoAP, unless it's in the common abbreviations list. Shawn. -- From nobody Sat Aug 9 08:02:47 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3031A061D for ; Fri, 8 Aug 2014 20:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1vSwgvI2I2B for ; Fri, 8 Aug 2014 20:33:48 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7738E1A0538 for ; Fri, 8 Aug 2014 20:33:48 -0700 (PDT) X-ASG-Debug-ID: 1407555227-06daaa1c7d52010001-mFDwdl Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id AXRQ4NWMYlg6CHnR for ; Fri, 08 Aug 2014 23:33:47 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Aug 2014 23:33:41 -0400 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: Fri, 8 Aug 2014 23:33:33 -0400 X-ASG-Orig-Subj: RE: Review of draft-ietf-core-groupcomm-21 Message-ID: In-Reply-To: <53E5864D.7040809@oracle.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-core-groupcomm-21 Thread-Index: Ac+zeR85SqR9VTewTD2fa6Sj6lGAtAACPS+Q References: <53E1937A.9000502@oracle.com> <53E5864D.7040809@oracle.com> From: "Rahman, Akbar" To: "Shawn M Emery" , X-OriginalArrivalTime: 09 Aug 2014 03:33:41.0006 (UTC) FILETIME=[B6BE02E0:01CFB382] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1407555227 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.8259 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/FhOUoC06SuR55qlBhqHel8djQY8 X-Mailman-Approved-At: Sat, 09 Aug 2014 08:02:46 -0700 Cc: draft-ietf-core-groupcomm.all@tools.ietf.org Subject: Re: [secdir] Review of draft-ietf-core-groupcomm-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 03:33:50 -0000 Thank you for the prompt review, Shawn. >Editorial comments: >Please expand the first occurrence of CoAP, unless it's in the common abbreviations list. Good catch. We expand (define) CoAP in the first sentence of the main body (i.e., section 1.1). However, we did not expand CoAP in the Abstract. We will correct that in our next update. Best Regards, Akbar -----Original Message----- From: Shawn M Emery [mailto:shawn.emery@oracle.com]=20 Sent: Friday, August 08, 2014 10:24 PM To: secdir@ietf.org Cc: draft-ietf-core-groupcomm.all@tools.ietf.org Subject: Review of draft-ietf-core-groupcomm-21 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This informational draft provides guidance on CoAP (Constrained Application Protocol) communication when using multiple recipients (i.e. multicast). The security considerations section does exist and does disclose that CoAP group communication (i.e. multicast transmissions) does lack a security mode and references RFC 7252 for the various attacks. CoAP relies upon DTLS, which does not currently have a standardized solution for multicast communication. The draft goes on to state the various threats and how to mitigate against said attacks. It discusses possible future methods to protect multicast transmissions, such as draft-keoh-dice-multicast-security. The security considerations does also have a separate section on pervasive monitoring, which I thought was a good idea, but not just for this draft... General comments: None. Editorial comments: Please expand the first occurrence of CoAP, unless it's in the common abbreviations list. Shawn. -- From nobody Sun Aug 10 23:52:58 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A1E1A0337; Sun, 10 Aug 2014 23:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIPhhr7m7Jr9; Sun, 10 Aug 2014 23:52:49 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D8F51A0334; Sun, 10 Aug 2014 23:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2193; q=dns/txt; s=iport; t=1407739969; x=1408949569; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HfJio8GQb21LBxo/A975T88G4OCWcS3AlsYRBpZ5Mk8=; b=mGs7KSlC03S4qDeOBONxq7SU13vwV1MN0Yv96UDbipIaRJAKmBpvVoDl LGLdFh/eqbiVS+8ma7qli+OMQJe6v74Veuwk4AODDJgzjmJQn2TrfiuBo /JBWWJemTZ4PFfiwKA3wsTG5yYJwSX5GQwA7F2GSw07dULsj4qPJ76OuR U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkFAPRm6FOtJV2a/2dsb2JhbABagw2BKQTUOgGBExZ3hAMBAQEDAXkFCwIBCBguMiUCBA4FiDoIwGIXjxkzB4MvgR0BBJEZixaUe4NcbIFH X-IronPort-AV: E=Sophos;i="5.01,839,1400025600"; d="scan'208";a="346544747" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 11 Aug 2014 06:52:46 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s7B6qk5p015332 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Aug 2014 06:52:46 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.120]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Mon, 11 Aug 2014 01:52:46 -0500 From: "Klaas Wierenga (kwiereng)" To: Paul Wouters Thread-Topic: [secdir] secdir review of draft-ietf-dnsop-as112-dname-04 Thread-Index: AQHPsiQ3f8OY5L4Ee0OTmhRUsiOAuZvFiEiAgAXJFYA= Date: Mon, 11 Aug 2014 06:52:45 +0000 Message-ID: References: <04F423A7-DEEC-47B0-8FB7-61D14F2D89EB@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.96.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Kd9jh1E_RsL6xWThuFj4TcuTzGY Cc: "draft-ietf-dnsop-as112-dnam.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-dnsop-as112-dname-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 06:52:50 -0000 On 07 Aug 2014, at 16:32, Paul Wouters wrote: Hi Paul, > On Thu, 7 Aug 2014, Klaas Wierenga (kwiereng) wrote: >=20 >> For security considerations relating to AS112 service in general, see RF= C6304bis]." >>=20 >> And in the introduction >>=20 >> "The AS112 project does not accommodate the addition and removal of >> DNS zones elegantly. Since additional zones of definitively local >> significance are known to exist=94 >>=20 >> It appears to me that moving from a static list of well known ranges as = defined in 6304bis to a dynamic adding and dropping of IP-address ranges th= at are "of definitively local >> significance=94 is prone to error, potentially leading to blackholing v= alid address space, either on purpose or by accident. I may show my ignoran= ce here, but I feel that a discussions as to why that risk doesn=92t exist = is warranted. >=20 > Actually, the static list is much more problematic. Mostly because some > AS112 instances would not yet have the new addition, while other AS112 > instances would, and the replies would be inconsistent. By using the > DNAME protocol, it makes anything thrown at an AS112 work. Anyone else > throwing something in would still cause less packets on the internet > than those DNS packets leaking out the regular DNS infrastructure. For > instance, ISPs could run an AS112 instance to take all RFC1918 queries. > When new ranges are added (like 100.64.0.0/16) the ISP does not even > need to update their AS112 instance (they have to do so now). The > document's main purpose is to get rid of that bad static list. Because > it is static, an ISP cannot even really add anything to it, without > causing inconsistency. OK, that sounds reasonable. So I gather that this list of =93definitive loc= al significance=94 ranges is relatively dynamic? I.e. there is a need for u= pdating this list often?=20 >=20 > The only people that can make a mistake to "null route" their domain into > AS112 are the owners of the domain. Don't configure NS records that > point to AS112 and you are fine. OK, makes sense (as I pointed out, blame my ignorance ;-) Klaas = From nobody Mon Aug 11 07:08:58 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00441A03CF; Mon, 11 Aug 2014 07:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.668 X-Spam-Level: X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-P3pE8-jwgF; Mon, 11 Aug 2014 07:08:53 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C31221A01A5; Mon, 11 Aug 2014 07:08:53 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7AD0E80048; Mon, 11 Aug 2014 10:08:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1407766132; bh=OzfmrAUzWqK9sj/oYh1nItStKusorHsRxe7vcyTZJAM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=n7aRJZs5NlY3ztPvhUoOKWRSoo/kditKVZz8gUQE8ueK5deztvIEhBhnQAO6gJU0n CCTz3fwVz13fGGw7IgL243PD7YsNvheI0rudF80QVXfYiR3gngQ8ABG+RSxl/E5rck Hguinyh3CHKcxXFLTz333AuYphQ5hH46kUVflmyo= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s7BE8pEf025060; Mon, 11 Aug 2014 10:08:51 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 11 Aug 2014 10:08:51 -0400 (EDT) From: Paul Wouters To: "Klaas Wierenga (kwiereng)" In-Reply-To: Message-ID: References: <04F423A7-DEEC-47B0-8FB7-61D14F2D89EB@cisco.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=Windows-1252; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/lGvqsxn2mdzhbytD6DUMr3PBRd0 Cc: "draft-ietf-dnsop-as112-dnam.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-dnsop-as112-dname-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 14:08:55 -0000 On Mon, 11 Aug 2014, Klaas Wierenga (kwiereng) wrote: >> instance, ISPs could run an AS112 instance to take all RFC1918 queries. >> When new ranges are added (like 100.64.0.0/16) the ISP does not even >> need to update their AS112 instance (they have to do so now). The >> document's main purpose is to get rid of that bad static list. Because >> it is static, an ISP cannot even really add anything to it, without >> causing inconsistency. > > OK, that sounds reasonable. So I gather that this list of “definitive local significance” ranges is relatively dynamic? I.e. there is a need for updating this list often? It requires no reconfiguration of an AS112 node. That is the goal of the draft. AS112 becomes "zero maintanance". Of course, there will still be discussion about what the IETF as a community should point to the AS112 blackhole. Paul From nobody Mon Aug 11 09:06:18 2014 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD8B1A064E; Mon, 11 Aug 2014 08:33:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1407771225; bh=9G+yKf9zHO5fGdHLCV1RSgqBFFLuiAxYg094wl+hnn8=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=LZEO9IzQdWsNuVUb/Wxuu5LY9hh+jy9aMjKgsY75OzHNvkw0jZiLqR0FMkxhjiP0X K1+NYvCK3ubMsxtG/XfD6G0h3Ih7iSbttTOLTxXpsFJGH4jAf+utgxl6+lPvnNih+1 6ro1xchskOWI8GlM/PlT2W6OIBs11qZx3OfmynlU= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89CAE1B2C54; Fri, 8 Aug 2014 09:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GT48OndCsbFX; Fri, 8 Aug 2014 09:12:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF9E1B2C50; Fri, 8 Aug 2014 09:12:48 -0700 (PDT) MIME-Version: 1.0 From: IETF Secretariat To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140808161248.11324.98279.idtracker@ietfa.amsl.com> Date: Fri, 08 Aug 2014 09:12:48 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/new-work/uzyMBx9eYQIBwMev-rawBdaRfX4 X-Mailman-Approved-At: Mon, 11 Aug 2014 08:33:44 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/hJP2BY3rJN0ZKIoYLW72KM2oRqY X-Mailman-Approved-At: Mon, 11 Aug 2014 09:06:14 -0700 Subject: [secdir] [new-work] WG Review: Calendaring Extensions (calext) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 15:33:45 -0000 A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2014-08-18. Calendaring Extensions (calext) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Barry Leiba Mailing list Address: calsify@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/calsify Archive: http://www.ietf.org/mail-archive/web/calsify/ Charter: Calendaring Extensions (calext) ----------------------------------------------------------- The Calendaring Extensions working group is chartered to develop extensions to the iCalendar (RFC 5545), iTIP (RFC 5546), and CalDAV (RFC 4791) standards. This working group will do the following: - Develop an extension to iCalendar to support non-Gregorian recurrence rules, without the need to support new calendar scale values in iCalendar as a whole. This will allow for easy implementation of the primary use case for non-Gregorian support in calendar systems, without the need for significant changes to the iCalendar format. The non-Gregorian calendar system should be based on the International Components for Unicode work by the Unicode Consortium (http://site.icu-project.org). - Develop an extension to iCalendar to support a new component type that allows users to express arbitrary, possibly repeating, periods of "available" time. The primary use case for this is for users to express their "office hours" (e.g., Monday-Friday, 9am-5pm) in a standard way to ensure free busy lookups show the correct periods of availability. - Define a set of new iCalendar properties and parameters to standardise some existing experimental X- properties. This will include a new set of "top-level" properties for the "CALENDAR" component, as well as an new "IMAGE" property to allow users more control of the visual appearance of events and tasks within their calendars. The working group will work under the following parameters: - The extensions developed are expected to be backwards-compatible with the existing calendar standards. Incompatibilities must be identified, minimized, and justified. - For each set of extensions, examine their impact on the iTIP protocol (RFC 5546), and define any necessary extensions to iTIP to accommodate such impact. - For each set of extensions, examine their impact on the CalDAV protocol (RFC 4791), and define any necessary extensions to CalDAV to accommodate such impact. The working group will use the following drafts as initial input for its work: draft-daboo-icalendar-rscale-03 draft-daboo-calendar-availability-05 draft-daboo-icalendar-extensions-08 The following are out of scope for the working group: - Any change that significantly impacts backwards compatibility with existing deployed iCalendar/iTIP/CalDAV clients and servers. - Any attempt to develop non-Gregorian calendar systems/calculations. Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Tue Aug 12 05:24:44 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0571A0880; Tue, 12 Aug 2014 05:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0LwNd8o6Ahp; Tue, 12 Aug 2014 05:24:42 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F0031A0329; Tue, 12 Aug 2014 05:24:41 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id ty20so7885371lab.32 for ; Tue, 12 Aug 2014 05:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=6iODtDnCqQKrJLOoK6oAOI0PSaEpGtiqLv0W+8pNaLc=; b=lcVYdzwe0IKZXwKZz/81jSPLCB41HJQ1sQOW5+pRDHJ7EL9dtzUeRyDaALgtKqdttQ dqK853CLQTJYS6OSjrwF2f7X4K+SvJ06WPX3wRJArzn6xXE+0ksWLDgSp5QDjdz7eYHl u8kZaS5llY3D/Cll0nXmhuHp5PXeHwu3VYpv1raQpJQsNShdFBAdmjRknmPbRuENIpPE bfCOKsC+aXTg6MH7t+IAtHFFGvnDvqzDrWCRSr5+Bttd+w1d+YfJPjZxX7Crz7Vx64is +Xtj9tGjGDcTsEotpbqvnA8LB0jteUSz5SxglhH9gx8JCArBGXcxz9AuFagsfl+GTv4K E/hQ== MIME-Version: 1.0 X-Received: by 10.112.235.199 with SMTP id uo7mr3691532lbc.50.1407846278897; Tue, 12 Aug 2014 05:24:38 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.50 with HTTP; Tue, 12 Aug 2014 05:24:38 -0700 (PDT) Date: Tue, 12 Aug 2014 08:24:38 -0400 X-Google-Sender-Auth: tyDILeEisYTnjyDJHW5FoZ7ZCQI Message-ID: From: Phillip Hallam-Baker To: draft-ietf-netmod-snmp-cfg.all@tools.ietf.org, "secdir@ietf.org" , "iesg@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/qSM8Aiairj9LlCYwDUNSt62-8OY Subject: [secdir] Secdir review of draft-ietf-netmod-snmp-cfg-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 12:24:42 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes the use of an alternate schema format, YANG for describing SNMP configuration. As such the schema presented defines modules that are equivalent to traditionally described ASN.1 MIBs but without the insertion of sharp sticks in the eyes or underneath the fingernails. Since SNMP (wisely) forked ASN.1 some time ago and is not tracking developments in that spec, this is arguably a more principled approach. This does not in itself raise security concerns but the new model takes advantage of the modularity and block structure of YANG to separate areas of the configuration with similar concerns, for example similar access control requirements. It might be worth having a look at the specific access control requirements specified in the security considerations section. From nobody Wed Aug 13 17:20:33 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6261A04B4; Wed, 13 Aug 2014 17:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6_vEEOa4KAM; Wed, 13 Aug 2014 17:20:26 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F08301A04E9; Wed, 13 Aug 2014 17:20:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 8B8A7E2033; Wed, 13 Aug 2014 20:20:24 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 08489-10; Wed, 13 Aug 2014 20:20:20 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 1B72DE2031; Wed, 13 Aug 2014 20:20:20 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id s7E0KIc8027622; Wed, 13 Aug 2014 20:20:18 -0400 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Date: Wed, 13 Aug 2014 20:20:18 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/fBHF5vumBeQ7GpSfJCudwMHMHuI Cc: swallow@cisco.com, l3vpn-chairs@tools.ietf.org, loa@mail01.huawei.com Subject: [secdir] sec-dir review of draft-ietf-l3vpn-pmsi-registry-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 00:20:32 -0000 Hi, (Sorry for the late review) I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I see no issues with this document. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Aug 15 03:28:59 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 048901A8A33 for ; Fri, 15 Aug 2014 03:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.11 X-Spam-Level: X-Spam-Status: No, score=0.11 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.668, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gV5oZtoODFKJ for ; Fri, 15 Aug 2014 03:28:55 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76C141A09CA for ; Fri, 15 Aug 2014 03:28:55 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s7FASppX021064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 15 Aug 2014 13:28:51 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s7FASp5t024865; Fri, 15 Aug 2014 13:28:51 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21485.57570.703920.767569@fireball.kivinen.iki.fi> Date: Fri, 15 Aug 2014 13:28:50 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 1 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/y2VbjjyaiN1TdK7ZqTs5JWOdg0w Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 10:28:58 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Leif Johansson is next in the rotation. For telechat 2014-08-21 Reviewer LC end Draft Shaun Cooley T 2014-08-08 draft-ietf-tram-auth-problems-04 Alan DeKok T 2014-08-08 draft-ietf-appsawg-json-merge-patch-06 Dorothy Gellert T 2014-08-08 draft-ietf-core-observe-14 Catherine Meadows TR2014-08-20 draft-ietf-paws-protocol-14 Sam Weiler T 2014-08-12 draft-ietf-karp-bfd-analysis-06 For telechat 2014-09-04 David Harrington T 2014-08-22 draft-ietf-ippm-lmap-path-05 For telechat 2014-09-18 Sam Hartman T 2014-08-22 draft-ietf-dnsop-child-syncronization-02 For telechat 2014-10-02 Chris Inacio T 2014-08-26 draft-ietf-tsvwg-rsvp-pcn-09 Last calls and special requests: Donald Eastlake 2014-08-08 draft-ietf-conex-abstract-mech-12 Steve Hanna 2014-08-13 draft-ietf-rmcat-cc-requirements-05 Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14 Dan Harkins 2014-08-22 draft-ietf-6lo-lowpan-mib-03 Paul Hoffman 2014-08-22 draft-ietf-pwe3-mspw-er-05 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-06 Jeffrey Hutzelman 2014-08-22 draft-ietf-soc-overload-rate-control-09 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Ondrej Sury 2014-07-30 draft-ietf-ipfix-text-adt-10 Sean Turner 2014-08-25 draft-ietf-appsawg-nullmx-08 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-11 Tom Yu 2014-08-09 draft-ietf-forces-model-extension-03 -- kivinen@iki.fi From nobody Fri Aug 15 03:37:08 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C9B1A09DB; Fri, 15 Aug 2014 03:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.168 X-Spam-Level: X-Spam-Status: No, score=-6.168 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syCwDk63hHjn; Fri, 15 Aug 2014 03:37:00 -0700 (PDT) Received: from smtp2.infineon.com (smtp2.infineon.com [217.10.52.18]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 451841A09CA; Fri, 15 Aug 2014 03:36:58 -0700 (PDT) X-SBRS: None Received: from unknown (HELO mucxv001.muc.infineon.com) ([172.23.11.16]) by smtp2.infineon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Aug 2014 12:36:57 +0200 Received: from MUCSE603.infineon.com (mucltm02.eu.infineon.com [172.23.8.249]) by mucxv001.muc.infineon.com (Postfix) with ESMTPS; Fri, 15 Aug 2014 12:36:56 +0200 (CEST) Received: from MUCSE603.infineon.com (172.23.7.104) by MUCSE603.infineon.com (172.23.7.104) with Microsoft SMTP Server (TLS) id 15.0.847.32; Fri, 15 Aug 2014 12:36:55 +0200 Received: from MUCSE593.eu.infineon.com (172.23.7.82) by MUCSE603.infineon.com (172.23.7.104) with Microsoft SMTP Server (TLS) id 15.0.847.32 via Frontend Transport; Fri, 15 Aug 2014 12:36:55 +0200 Received: from MUCSE503.eu.infineon.com ([169.254.4.21]) by MUCSE593.eu.infineon.com ([172.23.7.82]) with mapi id 14.03.0174.001; Fri, 15 Aug 2014 12:36:55 +0200 From: To: , , Thread-Topic: secdir review of draft-ietf-rmcat-cc-requirements-05 Thread-Index: Ac+4bxM+fJONFVq7SleKDBCPx2Xp/A== Date: Fri, 15 Aug 2014 10:36:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.23.7.102] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0683_01CFB853.4C2E1AC0" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/1bOXLmP0jjibubnPOpWNavCr428 Subject: [secdir] secdir review of draft-ietf-rmcat-cc-requirements-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 10:37:03 -0000 ------=_NextPart_000_0683_01CFB853.4C2E1AC0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0684_01CFB853.4C2E1AC0" ------=_NextPart_001_0684_01CFB853.4C2E1AC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes a set of requirements for congestion control for interactive, point-to-point real time multimedia. I believe this document is "Ready with issues". The security considerations section of this document is brief, which is OK for a requirements document. However, I think that one sentence should probably be added. The section says "Attacks that increase the percieved available bandwidth are concievable, and need to be evaluated." While this is true (and disregarding the spelling errors for the moment), I believe it is the most concerning part of the security considerations section and therefore deserves more attention. I suggest adding a sentence reflecting on the possible impact of such attacks. For example, this sentence could be added after the one that I just quoted: "Such attacks could result in starvation of competing flows and permit amplification attacks." Adding such a sentence may provide guidance to readers who are congestion control experts not familiar with security and therefore not likely to understand the implications of the existing, brief text. I also noticed some nits and typos in the document. . The document should expand the acronym RMCAT. I realize that RMCAT expanded in the WG name but the WG will close at some point and the document should stand on its own. . "an use" => "a use" Why? See explanation at https://owl.english.purdue.edu/owl/resource/540/01 . "in order allow" => "in order to allow" . "flows competing against at" => "flows competing against it at" . "heirarchy" => "hierarchy" . "a single queue" => "a single queue." (missing period at end of section 2) . "percieved" => "perceived" . "concievable" => "conceivable" Overall, I would say that the quality and readability of the document is quite high. I am only slightly familiar with congestion control but I felt that I completely or almost completely understood the document, including the rationale for each requirement. I cannot speak to the appropriateness of these requirements with any authority since I lack deep understanding of RTCWeb or congestion control but the document seems to be a high-quality, constructive addition to the RFC series. From a security perspective, the only need is to add the clarifying sentence suggested above. And I apologize for sending this review two days after the IETF LC deadline. Still, I expect that it is not too late to include this input. The security area directors and the authors should find it useful. Thanks, Steve Hanna ------=_NextPart_001_0684_01CFB853.4C2E1AC0 Content-Type: text/html; charset="us-ascii" 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 describes a set of requirements for congestion control for = interactive, point-to-point real time multimedia.

 

I believe = this document is “Ready with issues”.

 

The security = considerations section of this document is brief, which is OK for a = requirements document. However, I think that one sentence should = probably be added. The section says “Attacks that increase the = percieved available bandwidth are concievable, and need to be = evaluated.”  While this is true (and disregarding the = spelling errors for the moment), I believe it is the most concerning = part of the security considerations section and therefore deserves more = attention. I suggest adding a sentence reflecting on the possible impact = of such attacks. For example, this sentence could be added after the one = that I just quoted: “Such attacks could result in starvation of = competing flows and permit amplification attacks.” Adding such a = sentence may provide guidance to readers who are congestion control = experts not familiar with security and therefore not likely to = understand the implications of the existing, brief = text.

 

I also noticed some nits and typos in the = document.

 

·         = The document should expand the acronym = RMCAT. I realize that RMCAT expanded in the WG name but the WG will = close at some point and the document should stand on its = own.

·         = “an use” =3D> “a = use” Why? See explanation at = https://owl.english.purdue.edu/owl/resource/540/01

·         = “in order allow” =3D> = “in order to allow”

·         = “flows competing against at” = =3D> “flows competing against it at”

·         = “heirarchy” =3D> = “hierarchy”

·         = “a single queue” =3D> = “a single queue.” (missing period at end of section = 2)

·         = “percieved” =3D> = “perceived”

·         = “concievable” =3D> = “conceivable”

 

Overall, I = would say that the quality and readability of the document is quite = high. I am only slightly familiar with congestion control but I felt = that I completely or almost completely understood the document, = including the rationale for each requirement. I cannot speak to the = appropriateness of these requirements with any authority since I lack = deep understanding of RTCWeb or congestion control but the document = seems to be a high-quality, constructive addition to the RFC series. = >From a security perspective, the only need is to add the clarifying = sentence suggested above.

 

And I = apologize for sending this review two days after the IETF LC deadline. = Still, I expect that it is not too late to include this input. The = security area directors and the authors should find it = useful.

 

Thanks,

 

Steve = Hanna

 

------=_NextPart_001_0684_01CFB853.4C2E1AC0-- ------=_NextPart_000_0683_01CFB853.4C2E1AC0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM7jCCA+4w ggLWoAMCAQICEGsk517Bqmu0TbjoYC/BbAIwDQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCZGUx ITAfBgNVBAoTGEluZmluZW9uIFRlY2hub2xvZ2llcyBBRzErMCkGA1UEAxMiSW5maW5lb24gVGVj aG5vbG9naWVzIEFHIFJvb3QgQ0EgMjAeFw0xMTA3MjYxMzEyMjBaFw0zNjA3MjYxMzIyMjBaMF0x CzAJBgNVBAYTAmRlMSEwHwYDVQQKExhJbmZpbmVvbiBUZWNobm9sb2dpZXMgQUcxKzApBgNVBAMT IkluZmluZW9uIFRlY2hub2xvZ2llcyBBRyBSb290IENBIDIwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDMQpw2+wMM1Zu9gvlmBJSMi0GGkpvNL+RUfdNatlMGrliwyaCEB+HZzZP9CLys cLIglTKWeANzKozlAjE4ubdO/Y1IBmnuJMDW2lI73bZOwR2Y0shwmO1esRd2EyGCtVa9RgKa7HD3 pEHJAXlu9+IejoYv94lF80E/5jsNMeczlwUV7cF3NwXQKMoRd1BHGtFnwwOqIVELmDC/coQM6UXe MlUzYpfVJyqdCiNHU0wPzFNyeDObgDOLNIH222OuRR5wsDvmDiP/6j8QPTBJ71uGWlFE6B7cVvAO QXVDCZYLpfQLkNFnG8BElOH7gSzuAiBvQtoERRC1QyZZC2MEValdAgMBAAGjgakwgaYwDgYDVR0P AQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQEwHQYDVR0OBBYEFDhv1fR35slaIStRFWrWIKsC DacVMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaW5maW5lb24uY29tL3Jvb3RjYTIvcm9v dGNhMi5jcmwwEAYJKwYBBAGCNxUBBAMCAQAwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEB BQUAA4IBAQCsiCetpToA0t9yFxPkiw1pekvEPPEeOqsMEGa/Xf6JyqZCC0lSAyu9Uo6l6YSCAb73 f0TjNH0JDNApW2q6556qloVM0almOTirDaM+R8bJzeRg7xHeZriif9QWfA9czBfK6MSDTDULatcH mJwNznVQWuRBefTg/txo0OuPvvmbuGVT8hhdEf1fu0rcX7fE1X7zP27opZ3DjMk+ocu9MRk3L+Cw ISxiCfo2af0hWLZBTuQPqODjx73waxOAK317QwRC4m84BwUEZ3IR3CfvK3ukk6UQ8Pgl6SmDdzNw KGVNo+tNELKtgW125xQ5znatvPJQjYJjhB0XikvWjdKJL48PMIIEIzCCAwugAwIBAgIKYR4k+gAA AAAAAjANBgkqhkiG9w0BAQUFADBdMQswCQYDVQQGEwJkZTEhMB8GA1UEChMYSW5maW5lb24gVGVj aG5vbG9naWVzIEFHMSswKQYDVQQDEyJJbmZpbmVvbiBUZWNobm9sb2dpZXMgQUcgUm9vdCBDQSAy MB4XDTExMDcyNzEyMzIwNVoXDTI2MDcyNzEyNDIwNVowXTELMAkGA1UEBhMCZGUxITAfBgNVBAoT GEluZmluZW9uIFRlY2hub2xvZ2llcyBBRzErMCkGA1UEAxMiSW5maW5lb24gVGVjaG5vbG9naWVz IEFHIFVzZXIgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKBHZyb03ScBt//g 4A4cOg5bRHXlpCBOyzJo/X4sMpuxu+47KFkVAIWhUlyhVk4f22+EDos6Ley7/10Pl7VNBuTj0i07 P5vjTbT/CgshA3mcRb4xqyXZx4Eh/rnMicAlXQ8OUhbg+uBMjBOuvQrhXg2epP6+etKdg6LlXDrD edZflpmIGvn8sgGyfbAiH0Wy/HGJngg6dncHacL6hPzGTrhR4bJwTnogxhN7NaDmuU1OxzKjsPc7 cidAmTtIlGpEfXj162C8GZ6vQjmBjH+ZqEdnz86IPGnUHb4Ifoa/GVzSlH0hPtMmybczi/BAcAQO obiKhfCbpNU8/nXhuiQ3kbcCAwEAAaOB5DCB4TALBgNVHQ8EBAMCAYYwHQYDVR0OBBYEFBoYmNi4 E/3bHsoMirMTA3B3wxeWMB8GA1UdIwQYMBaAFDhv1fR35slaIStRFWrWIKsCDacVMDwGA1UdHwQ1 MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaW5maW5lb24uY29tL3Jvb3RjYTIvcm9vdGNhMi5jcmwwEgYD VR0TAQH/BAgwBgEB/wIBADBABgNVHSAEOTA3MDUGCyqCFABEChQBAQEBMCYwJAYIKwYBBQUHAgEW GGh0dHBzOi8vY3BzLmluZmluZW9uLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAbOjg2haQMCPP0ZcS 1+hd0teYaBpi2LpwADGVyFAUO2UuPKGxAfYxWf3/v0FNW2IOhNKj8w3f076sKkeSlb6WiZZIe+ao kG2H6AimMIlhvv4GGAFHzQLVclXIz9jM7H4fH/wA/gHE4wDE1dvsGVjeM2fEjwTOtNrPzGF9SF1s NyJy8a2AZ83b6J6WIN72Jg2KXXQuVsa61/q2C5AAMfXLL4shuWN1JnYO03PBUjYWxqNdcETppKhc swaIZJ0MjKDttzuT9IntFeoOYMJx27KGowOqMDbmRoXRGWZahO4m4UkjIo9uzMX7U5EQymoMiVJc Ndp3qT5b48QXhmDe7Cmd4DCCBNEwggO5oAMCAQICAn7aMA0GCSqGSIb3DQEBBQUAMF0xCzAJBgNV BAYTAmRlMSEwHwYDVQQKExhJbmZpbmVvbiBUZWNobm9sb2dpZXMgQUcxKzApBgNVBAMTIkluZmlu ZW9uIFRlY2hub2xvZ2llcyBBRyBVc2VyIENBIDIwHhcNMTQwNTA4MDYzMDI0WhcNMTkwNTA4MDYz MDI0WjCBgjELMAkGA1UEBhMCVVMxMjAwBgNVBAoTKUluZmluZW9uIFRlY2hub2xvZ2llcyBOb3J0 aCBBbWVyaWNhIENvcnAuMRYwFAYDVQQDEw1TdGVwaGVuIEhhbm5hMScwJQYJKoZIhvcNAQkBFhhT dGV2ZS5IYW5uYUBpbmZpbmVvbi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCA FtObO7F+pUxS4qh2dVM0xI9zDZquunmkxtfb7TG3IXsd7NaqDYBXI67jA3WfxI/DHp3ub0ZuQ3qv JLzsdCr5FQgDDh7MBvesFRoYa6RHT/dUWE9SGjexFquQRHP75ZYxNBw3zOYpr87XFE1rsjXIQp7s 2ehfZLiIEr3NkyzjeAqBw6EfT65Dy598EWFon2Ky/QfJsDmBAfTc4+Ews2suhvS8x2pqSwHtOLNF PK2zD+zFsBdZJyv+ZawWaLO/B8aAwavVBDYBd3S5/4FJKEG8ednZpetkNQ2aMMg3Lnay8/t9UvcY jS810qTNVOEfiyZBzlJi53I4Nhw35UC6o1P5AgMBAAGjggFzMIIBbzA/BgNVHREEODA2gRhTdGV2 ZS5IYW5uYUBpbmZpbmVvbi5jb22BGlN0ZXBoZW4uSGFubmFAaW5maW5lb24uY29tMEAGA1UdIAQ5 MDcwNQYLKoIUAEQKFAEBAQEwJjAkBggrBgEFBQcCARYYaHR0cHM6Ly9jcHMuaW5maW5lb24uY29t MDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaW5maW5lb24uY29tL3VzZXJjYTIvdXNlcmNh Mi5jcmwwDgYDVR0PAQH/BAQDAgTwMBMGA1UdJQQMMAoGCCsGAQUFBwMEMEcGCCsGAQUFBwEBBDsw OTA3BggrBgEFBQcwAoYraHR0cDovL2NybC5pbmZpbmVvbi5jb20vdXNlcmNhMi91c2VyY2EyLmNy dDAfBgNVHSMEGDAWgBQaGJjYuBP92x7KDIqzEwNwd8MXljAdBgNVHQ4EFgQUhs576DHwRkp1mWLi fTZ7b4yVe+UwDQYJKoZIhvcNAQEFBQADggEBADKEDQXoKMcxN3zhhg3gfoVJII4Y8BWdjTzs5q2D bivs+8Ic8v/7KT3a61Gmz+BJx/8kWTe8LbJtk3GM0ui1MLUo8110r7qnvNtTtM8hYAuQGXYDGhkh H2PmZG7VSgB6G6DFNLA/017Uqvz6UiRLTUJcge7VJvk40cxJ1Mzs240+JVW9nLb/Fn+zI5KJj573 tXv7LTNVK2whVD7fJ3s07JGh75QYw5NusaHT9/4Zh/7idDdE/ailMY9pPvEtbVWcBnQxcXSoFEiM LKZFJ3o8nN7XFscSUqGRNNVYrAxpcktrnbz+assus7SbIYDpkOAOToBIWkdcxTXOWkv0Me9tVGcx ggODMIIDfwIBATBjMF0xCzAJBgNVBAYTAmRlMSEwHwYDVQQKExhJbmZpbmVvbiBUZWNobm9sb2dp ZXMgQUcxKzApBgNVBAMTIkluZmluZW9uIFRlY2hub2xvZ2llcyBBRyBVc2VyIENBIDICAn7aMAkG BSsOAwIaBQCgggH1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0 MDgxNTEwMzY1MVowIwYJKoZIhvcNAQkEMRYEFLa3YGdCbI0DL5YlwrU7B8APWOuaMHIGCSsGAQQB gjcQBDFlMGMwXTELMAkGA1UEBhMCZGUxITAfBgNVBAoTGEluZmluZW9uIFRlY2hub2xvZ2llcyBB RzErMCkGA1UEAxMiSW5maW5lb24gVGVjaG5vbG9naWVzIEFHIFVzZXIgQ0EgMgICftowdAYLKoZI hvcNAQkQAgsxZaBjMF0xCzAJBgNVBAYTAmRlMSEwHwYDVQQKExhJbmZpbmVvbiBUZWNobm9sb2dp ZXMgQUcxKzApBgNVBAMTIkluZmluZW9uIFRlY2hub2xvZ2llcyBBRyBVc2VyIENBIDICAn7aMIGr BgkqhkiG9w0BCQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzAL BglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBACRGx/Rjgi0RA+lFnNYp3NUhB1J0w26M+lMsf9IYeZtm3JTaw4U3 oQkBC0DOpU63ECHOm8uKqnN1wSrRrE1B7FII8Cp48KGaqbwJ+Q3wA76VwfvtaF5A2zkgQa5VlLtS UC3/DbcE1eAMRfuoHwgQimDrEiQk+n6N71XUm/exPuCzgJoILW+6nCtodUl2cXXFmGPZ8MS4NCU/ HSdxgV+7OWAd0SZoEIiVUk08Q8pf2wn9r/hZUt3L+pIxHIpkQld9bS+KCX+Y/EBwB//srC4HAuiT xe5OpRJKBXVYQnaU1ojLhdyB0PiP9cgFDHCbLqzZQEEqFFI6ld+vUkqxq8eXOfAAAAAAAAA= ------=_NextPart_000_0683_01CFB853.4C2E1AC0-- From nobody Fri Aug 15 04:24:06 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3F51A8A4C; Fri, 15 Aug 2014 04:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.568 X-Spam-Level: X-Spam-Status: No, score=-7.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEpSX0qQVf72; Fri, 15 Aug 2014 04:24:03 -0700 (PDT) Received: from smtp2.infineon.com (smtp2.infineon.com [217.10.52.18]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 614BD1A8A4B; Fri, 15 Aug 2014 04:24:02 -0700 (PDT) X-SBRS: None Received: from unknown (HELO mucxv001.muc.infineon.com) ([172.23.11.16]) by smtp2.infineon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Aug 2014 13:24:01 +0200 Received: from MUCSE604.infineon.com (mucltm02.eu.infineon.com [172.23.8.249]) by mucxv001.muc.infineon.com (Postfix) with ESMTPS; Fri, 15 Aug 2014 13:23:59 +0200 (CEST) Received: from MUCSE604.infineon.com (172.23.7.105) by MUCSE604.infineon.com (172.23.7.105) with Microsoft SMTP Server (TLS) id 15.0.847.32; Fri, 15 Aug 2014 13:23:58 +0200 Received: from MUCSE592.eu.infineon.com (172.23.7.81) by MUCSE604.infineon.com (172.23.7.105) with Microsoft SMTP Server (TLS) id 15.0.847.32 via Frontend Transport; Fri, 15 Aug 2014 13:23:58 +0200 Received: from MUCSE503.eu.infineon.com ([169.254.4.21]) by MUCSE592.eu.infineon.com ([172.23.7.81]) with mapi id 14.03.0174.001; Fri, 15 Aug 2014 13:23:58 +0200 From: To: , , Thread-Topic: secdir review of draft-ietf-rmcat-cc-requirements-05 Thread-Index: Ac+4bxM+fJONFVq7SleKDBCPx2Xp/AAC/ctw Date: Fri, 15 Aug 2014 11:23:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.23.7.102] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_06A1_01CFB859.DECAB360" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/YZP9ncng3JhPI63iS89hmmyjIjE Subject: [secdir] secdir review of draft-ietf-rmcat-cc-requirements-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 11:24:06 -0000 ------=_NextPart_000_06A1_01CFB859.DECAB360 Content-Type: multipart/alternative; boundary="----=_NextPart_001_06A2_01CFB859.DECAB360" ------=_NextPart_001_06A2_01CFB859.DECAB360 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resending this email because I used the wrong email address for the .all address. That's @tools.ietf.org not @ietf.org. Thanks, Steve I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes a set of requirements for congestion control for interactive, point-to-point real time multimedia. I believe this document is "Ready with issues". The security considerations section of this document is brief, which is OK for a requirements document. However, I think that one sentence should probably be added. The section says "Attacks that increase the percieved available bandwidth are concievable, and need to be evaluated." While this is true (and disregarding the spelling errors for the moment), I believe it is the most concerning part of the security considerations section and therefore deserves more attention. I suggest adding a sentence reflecting on the possible impact of such attacks. For example, this sentence could be added after the one that I just quoted: "Such attacks could result in starvation of competing flows and permit amplification attacks." Adding such a sentence may provide guidance to readers who are congestion control experts not familiar with security and therefore not likely to understand the implications of the existing, brief text. I also noticed some nits and typos in the document. . The document should expand the acronym RMCAT. I realize that RMCAT expanded in the WG name but the WG will close at some point and the document should stand on its own. . "an use" => "a use" Why? See explanation at https://owl.english.purdue.edu/owl/resource/540/01 . "in order allow" => "in order to allow" . "flows competing against at" => "flows competing against it at" . "heirarchy" => "hierarchy" . "a single queue" => "a single queue." (missing period at end of section 2) . "percieved" => "perceived" . "concievable" => "conceivable" Overall, I would say that the quality and readability of the document is quite high. I am only slightly familiar with congestion control but I felt that I completely or almost completely understood the document, including the rationale for each requirement. I cannot speak to the appropriateness of these requirements with any authority since I lack deep understanding of RTCWeb or congestion control but the document seems to be a high-quality, constructive addition to the RFC series. From a security perspective, the only need is to add the clarifying sentence suggested above. And I apologize for sending this review two days after the IETF LC deadline. Still, I expect that it is not too late to include this input. The security area directors and the authors should find it useful. Thanks, Steve Hanna ------=_NextPart_001_06A2_01CFB859.DECAB360 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Resending = this email because I used the wrong email address for the = <draft-name>.all address. That’s @tools.ietf.org not = @ietf.org.

 

Thanks,

 

Steve

 

 

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

 

This = document describes a set of requirements for congestion control for = interactive, point-to-point real time multimedia.

 

I believe = this document is “Ready with issues”.

 

The security = considerations section of this document is brief, which is OK for a = requirements document. However, I think that one sentence should = probably be added. The section says “Attacks that increase the = percieved available bandwidth are concievable, and need to be = evaluated.”  While this is true (and disregarding the = spelling errors for the moment), I believe it is the most concerning = part of the security considerations section and therefore deserves more = attention. I suggest adding a sentence reflecting on the possible impact = of such attacks. For example, this sentence could be added after the one = that I just quoted: “Such attacks could result in starvation of = competing flows and permit amplification attacks.” Adding such a = sentence may provide guidance to readers who are congestion control = experts not familiar with security and therefore not likely to = understand the implications of the existing, brief = text.

 

I also noticed some nits and typos in the = document.

 

·         = The document should expand the acronym = RMCAT. I realize that RMCAT expanded in the WG name but the WG will = close at some point and the document should stand on its = own.

·         = “an use” =3D> “a = use” Why? See explanation at https://owl.english.purdue.edu/owl/resource/54= 0/01

·         = “in order allow” =3D> = “in order to allow”

·         = “flows competing against at” = =3D> “flows competing against it at”

·         = “heirarchy” =3D> = “hierarchy”

·         = “a single queue” =3D> = “a single queue.” (missing period at end of section = 2)

·         = “percieved” =3D> = “perceived”

·         = “concievable” =3D> = “conceivable”

 

Overall, I = would say that the quality and readability of the document is quite = high. I am only slightly familiar with congestion control but I felt = that I completely or almost completely understood the document, = including the rationale for each requirement. I cannot speak to the = appropriateness of these requirements with any authority since I lack = deep understanding of RTCWeb or congestion control but the document = seems to be a high-quality, constructive addition to the RFC series. = >From a security perspective, the only need is to add the clarifying = sentence suggested above.

 

And I = apologize for sending this review two days after the IETF LC deadline. = Still, I expect that it is not too late to include this input. The = security area directors and the authors should find it = useful.

 

Thanks,

 

Steve = Hanna

 

------=_NextPart_001_06A2_01CFB859.DECAB360-- ------=_NextPart_000_06A1_01CFB859.DECAB360 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM7jCCA+4w ggLWoAMCAQICEGsk517Bqmu0TbjoYC/BbAIwDQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCZGUx ITAfBgNVBAoTGEluZmluZW9uIFRlY2hub2xvZ2llcyBBRzErMCkGA1UEAxMiSW5maW5lb24gVGVj aG5vbG9naWVzIEFHIFJvb3QgQ0EgMjAeFw0xMTA3MjYxMzEyMjBaFw0zNjA3MjYxMzIyMjBaMF0x CzAJBgNVBAYTAmRlMSEwHwYDVQQKExhJbmZpbmVvbiBUZWNobm9sb2dpZXMgQUcxKzApBgNVBAMT IkluZmluZW9uIFRlY2hub2xvZ2llcyBBRyBSb290IENBIDIwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDMQpw2+wMM1Zu9gvlmBJSMi0GGkpvNL+RUfdNatlMGrliwyaCEB+HZzZP9CLys cLIglTKWeANzKozlAjE4ubdO/Y1IBmnuJMDW2lI73bZOwR2Y0shwmO1esRd2EyGCtVa9RgKa7HD3 pEHJAXlu9+IejoYv94lF80E/5jsNMeczlwUV7cF3NwXQKMoRd1BHGtFnwwOqIVELmDC/coQM6UXe MlUzYpfVJyqdCiNHU0wPzFNyeDObgDOLNIH222OuRR5wsDvmDiP/6j8QPTBJ71uGWlFE6B7cVvAO QXVDCZYLpfQLkNFnG8BElOH7gSzuAiBvQtoERRC1QyZZC2MEValdAgMBAAGjgakwgaYwDgYDVR0P AQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQEwHQYDVR0OBBYEFDhv1fR35slaIStRFWrWIKsC DacVMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaW5maW5lb24uY29tL3Jvb3RjYTIvcm9v dGNhMi5jcmwwEAYJKwYBBAGCNxUBBAMCAQAwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEB BQUAA4IBAQCsiCetpToA0t9yFxPkiw1pekvEPPEeOqsMEGa/Xf6JyqZCC0lSAyu9Uo6l6YSCAb73 f0TjNH0JDNApW2q6556qloVM0almOTirDaM+R8bJzeRg7xHeZriif9QWfA9czBfK6MSDTDULatcH mJwNznVQWuRBefTg/txo0OuPvvmbuGVT8hhdEf1fu0rcX7fE1X7zP27opZ3DjMk+ocu9MRk3L+Cw ISxiCfo2af0hWLZBTuQPqODjx73waxOAK317QwRC4m84BwUEZ3IR3CfvK3ukk6UQ8Pgl6SmDdzNw KGVNo+tNELKtgW125xQ5znatvPJQjYJjhB0XikvWjdKJL48PMIIEIzCCAwugAwIBAgIKYR4k+gAA AAAAAjANBgkqhkiG9w0BAQUFADBdMQswCQYDVQQGEwJkZTEhMB8GA1UEChMYSW5maW5lb24gVGVj aG5vbG9naWVzIEFHMSswKQYDVQQDEyJJbmZpbmVvbiBUZWNobm9sb2dpZXMgQUcgUm9vdCBDQSAy MB4XDTExMDcyNzEyMzIwNVoXDTI2MDcyNzEyNDIwNVowXTELMAkGA1UEBhMCZGUxITAfBgNVBAoT GEluZmluZW9uIFRlY2hub2xvZ2llcyBBRzErMCkGA1UEAxMiSW5maW5lb24gVGVjaG5vbG9naWVz IEFHIFVzZXIgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKBHZyb03ScBt//g 4A4cOg5bRHXlpCBOyzJo/X4sMpuxu+47KFkVAIWhUlyhVk4f22+EDos6Ley7/10Pl7VNBuTj0i07 P5vjTbT/CgshA3mcRb4xqyXZx4Eh/rnMicAlXQ8OUhbg+uBMjBOuvQrhXg2epP6+etKdg6LlXDrD edZflpmIGvn8sgGyfbAiH0Wy/HGJngg6dncHacL6hPzGTrhR4bJwTnogxhN7NaDmuU1OxzKjsPc7 cidAmTtIlGpEfXj162C8GZ6vQjmBjH+ZqEdnz86IPGnUHb4Ifoa/GVzSlH0hPtMmybczi/BAcAQO obiKhfCbpNU8/nXhuiQ3kbcCAwEAAaOB5DCB4TALBgNVHQ8EBAMCAYYwHQYDVR0OBBYEFBoYmNi4 E/3bHsoMirMTA3B3wxeWMB8GA1UdIwQYMBaAFDhv1fR35slaIStRFWrWIKsCDacVMDwGA1UdHwQ1 MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaW5maW5lb24uY29tL3Jvb3RjYTIvcm9vdGNhMi5jcmwwEgYD VR0TAQH/BAgwBgEB/wIBADBABgNVHSAEOTA3MDUGCyqCFABEChQBAQEBMCYwJAYIKwYBBQUHAgEW GGh0dHBzOi8vY3BzLmluZmluZW9uLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAbOjg2haQMCPP0ZcS 1+hd0teYaBpi2LpwADGVyFAUO2UuPKGxAfYxWf3/v0FNW2IOhNKj8w3f076sKkeSlb6WiZZIe+ao kG2H6AimMIlhvv4GGAFHzQLVclXIz9jM7H4fH/wA/gHE4wDE1dvsGVjeM2fEjwTOtNrPzGF9SF1s NyJy8a2AZ83b6J6WIN72Jg2KXXQuVsa61/q2C5AAMfXLL4shuWN1JnYO03PBUjYWxqNdcETppKhc swaIZJ0MjKDttzuT9IntFeoOYMJx27KGowOqMDbmRoXRGWZahO4m4UkjIo9uzMX7U5EQymoMiVJc Ndp3qT5b48QXhmDe7Cmd4DCCBNEwggO5oAMCAQICAn7aMA0GCSqGSIb3DQEBBQUAMF0xCzAJBgNV BAYTAmRlMSEwHwYDVQQKExhJbmZpbmVvbiBUZWNobm9sb2dpZXMgQUcxKzApBgNVBAMTIkluZmlu ZW9uIFRlY2hub2xvZ2llcyBBRyBVc2VyIENBIDIwHhcNMTQwNTA4MDYzMDI0WhcNMTkwNTA4MDYz MDI0WjCBgjELMAkGA1UEBhMCVVMxMjAwBgNVBAoTKUluZmluZW9uIFRlY2hub2xvZ2llcyBOb3J0 aCBBbWVyaWNhIENvcnAuMRYwFAYDVQQDEw1TdGVwaGVuIEhhbm5hMScwJQYJKoZIhvcNAQkBFhhT dGV2ZS5IYW5uYUBpbmZpbmVvbi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCA FtObO7F+pUxS4qh2dVM0xI9zDZquunmkxtfb7TG3IXsd7NaqDYBXI67jA3WfxI/DHp3ub0ZuQ3qv JLzsdCr5FQgDDh7MBvesFRoYa6RHT/dUWE9SGjexFquQRHP75ZYxNBw3zOYpr87XFE1rsjXIQp7s 2ehfZLiIEr3NkyzjeAqBw6EfT65Dy598EWFon2Ky/QfJsDmBAfTc4+Ews2suhvS8x2pqSwHtOLNF PK2zD+zFsBdZJyv+ZawWaLO/B8aAwavVBDYBd3S5/4FJKEG8ednZpetkNQ2aMMg3Lnay8/t9UvcY jS810qTNVOEfiyZBzlJi53I4Nhw35UC6o1P5AgMBAAGjggFzMIIBbzA/BgNVHREEODA2gRhTdGV2 ZS5IYW5uYUBpbmZpbmVvbi5jb22BGlN0ZXBoZW4uSGFubmFAaW5maW5lb24uY29tMEAGA1UdIAQ5 MDcwNQYLKoIUAEQKFAEBAQEwJjAkBggrBgEFBQcCARYYaHR0cHM6Ly9jcHMuaW5maW5lb24uY29t MDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaW5maW5lb24uY29tL3VzZXJjYTIvdXNlcmNh Mi5jcmwwDgYDVR0PAQH/BAQDAgTwMBMGA1UdJQQMMAoGCCsGAQUFBwMEMEcGCCsGAQUFBwEBBDsw OTA3BggrBgEFBQcwAoYraHR0cDovL2NybC5pbmZpbmVvbi5jb20vdXNlcmNhMi91c2VyY2EyLmNy dDAfBgNVHSMEGDAWgBQaGJjYuBP92x7KDIqzEwNwd8MXljAdBgNVHQ4EFgQUhs576DHwRkp1mWLi fTZ7b4yVe+UwDQYJKoZIhvcNAQEFBQADggEBADKEDQXoKMcxN3zhhg3gfoVJII4Y8BWdjTzs5q2D bivs+8Ic8v/7KT3a61Gmz+BJx/8kWTe8LbJtk3GM0ui1MLUo8110r7qnvNtTtM8hYAuQGXYDGhkh H2PmZG7VSgB6G6DFNLA/017Uqvz6UiRLTUJcge7VJvk40cxJ1Mzs240+JVW9nLb/Fn+zI5KJj573 tXv7LTNVK2whVD7fJ3s07JGh75QYw5NusaHT9/4Zh/7idDdE/ailMY9pPvEtbVWcBnQxcXSoFEiM LKZFJ3o8nN7XFscSUqGRNNVYrAxpcktrnbz+assus7SbIYDpkOAOToBIWkdcxTXOWkv0Me9tVGcx ggODMIIDfwIBATBjMF0xCzAJBgNVBAYTAmRlMSEwHwYDVQQKExhJbmZpbmVvbiBUZWNobm9sb2dp ZXMgQUcxKzApBgNVBAMTIkluZmluZW9uIFRlY2hub2xvZ2llcyBBRyBVc2VyIENBIDICAn7aMAkG BSsOAwIaBQCgggH1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0 MDgxNTExMjM1NFowIwYJKoZIhvcNAQkEMRYEFMfexpIiKKX7qMd2Kzy0nqpyP65tMHIGCSsGAQQB gjcQBDFlMGMwXTELMAkGA1UEBhMCZGUxITAfBgNVBAoTGEluZmluZW9uIFRlY2hub2xvZ2llcyBB RzErMCkGA1UEAxMiSW5maW5lb24gVGVjaG5vbG9naWVzIEFHIFVzZXIgQ0EgMgICftowdAYLKoZI hvcNAQkQAgsxZaBjMF0xCzAJBgNVBAYTAmRlMSEwHwYDVQQKExhJbmZpbmVvbiBUZWNobm9sb2dp ZXMgQUcxKzApBgNVBAMTIkluZmluZW9uIFRlY2hub2xvZ2llcyBBRyBVc2VyIENBIDICAn7aMIGr BgkqhkiG9w0BCQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzAL BglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAGcF8mk0Kb4XLrDfubhbDg6bUg7horSAqepvz3ao8GU/4TDzxM7z VIjDO+fHzsaM2b9JtynoaZABjiU3Debzu/OJfyczQwWynKm0/Y2+VIVoivYhzLMUxuuc9hiWy9rf 6tM9vqsVhAR4Gna8LC7+CbjXlL2LGKNZdvlk08uN5E1XcggNUi1HoqdX1htywYPD64uQMlSEpXmJ foRFewO9SRtxg4dIAjl0PzohK1iBXcwzPQB5f2Mc9QKrMut/ILf/8CcDMsaJES+gJGgKD15t8wRP 7BwDYyh6PN1R7kV9S7JaIsjHW1C548QYn5XD+y+kde7s7xPAwwpK5ZBl/605uZAAAAAAAAA= ------=_NextPart_000_06A1_01CFB859.DECAB360-- From nobody Fri Aug 15 07:54:11 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136B01A02F8; Fri, 15 Aug 2014 07:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyw_vhKJIWYI; Fri, 15 Aug 2014 07:54:07 -0700 (PDT) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 754521A0AAF; Fri, 15 Aug 2014 07:54:07 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id g18so2098262oah.37 for ; Fri, 15 Aug 2014 07:54:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=lpoOh4z/jzqlm/Dvw5pe61LdBJ8DWK9TsrSB6E5CqZ4=; b=uqDTDowOWSDWwULj/7RFtQn9HgOLwTX/hJwW9uiGC0AzBKa3jBI4nbjLA437GBVCPq 13G4YTcnX4dNbtzvecKhIAyQG2K+8N4YgPCr3kT8knh4nszAI3Df/n8YFq+a+QuQhYKw waEl9M1tAuniGaRmE1EJO8/vRLbTnkYgAOv/3Qf43NcWzBPqpqrCFqX1O8VDCU58Fb00 MgQGhLWXhBuLIUdcdcmqUmqegq4Ob7blAy1cua7Gbwlgr1khBylxgGNd9Tawku6N28VT Oue+yAX5gfGne8iW18UKqOgabfZKdchmVdELokf4bRSm6dv/gSbYgWpAz7fkkzhp1JD+ fyBA== X-Received: by 10.182.107.234 with SMTP id hf10mr12525449obb.22.1408114445847; Fri, 15 Aug 2014 07:54:05 -0700 (PDT) Received: from ?IPv6:2605:6000:9005:3f00:1f8:eddc:ffb2:c798? ([2605:6000:9005:3f00:1f8:eddc:ffb2:c798]) by mx.google.com with ESMTPSA id v5sm11949737oek.15.2014.08.15.07.54.03 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Aug 2014 07:54:04 -0700 (PDT) Message-ID: <53EE1F09.6070608@gmail.com> Date: Fri, 15 Aug 2014 09:54:01 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Steve.Hanna@infineon.com, iesg@ietf.org, secdir@ietf.org, draft-ietf-rmcat-cc-requirements.all@tools.ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030205090304040505040709" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/M50GKepAMiSPZ-vi5Y3JllIrxL8 Subject: Re: [secdir] secdir review of draft-ietf-rmcat-cc-requirements-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 14:54:09 -0000 This is a multi-part message in MIME format. --------------030205090304040505040709 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 08/15/2014 06:23 AM, Steve.Hanna@infineon.com wrote: > And I apologize for sending this review two days after the IETF LC > deadline. Still, I expect that it is not too late to include this > input. The security area directors and the authors should find it useful. And perhaps even a TSV AD or two ;-) Thanks, and yes, it's not too late to include this input. Spencer --------------030205090304040505040709 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
On 08/15/2014 06:23 AM, Steve.Hanna@infineon.com wrote:
And I apologize for sending this review two days after the IETF LC deadline. Still, I expect that it is not too late to include this input. The security area directors and the authors should find it useful.

And perhaps even a TSV AD or two ;-)

Thanks, and yes, it's not too late to include this input.

Spencer
--------------030205090304040505040709-- From nobody Fri Aug 15 13:51:38 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759721A06C7; Fri, 15 Aug 2014 13:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.267 X-Spam-Level: X-Spam-Status: No, score=-3.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6YSF3YAHzDm; Fri, 15 Aug 2014 13:51:34 -0700 (PDT) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [132.250.118.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25BB11A06C6; Fri, 15 Aug 2014 13:51:33 -0700 (PDT) Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id s7FKpVYW011389 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 15 Aug 2014 16:51:31 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_6BB4887E-10C4-482A-B607-92DB2E46D30A" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Catherine Meadows In-Reply-To: Date: Fri, 15 Aug 2014 16:51:31 -0400 Message-Id: <4C83FE05-DABB-40F1-A544-7E8FE54B2605@nrl.navy.mil> References: To: iesg@ietf.org, secdir@ietf.org, draft-ietf-paws-protocol.all@tools.ietf.org X-Mailer: Apple Mail (2.1878.6) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/7xT94Wly8xqKxfnATOVr5gcZbxw Subject: [secdir] Secdir Review of draft-ietf-paws-protocol-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 20:51:37 -0000 --Apple-Mail=_6BB4887E-10C4-482A-B607-92DB2E46D30A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. This ID describes a protocol, PAWS, that allows wireless devices to = access currently unused portions of the radio spectrum. The protocol works between a geospatial database and a device with = geolocation capabilities. The device reports its location and other relevant information to the database, which in turns gives it = information about which portions of the spectrum is available to it. This removes the responsibility for managing the complex information = about spectrum available from the device and to the database, which is better equipped to handle it. I previously reviewed version 12 = of this ID, and although some changes and additions have been made to = the Security Considerations section, they are minor and do not change my previous review, which ran = as follows: The ID has a very thorough and well-written Security Considerations = section, which covers the security threats against such a protocol. = They identify two main threats By using the PAWSl, the Master Device and the Database expose themselves to the following risks: o Accuracy: The Master Device receives incorrect spectrum availability information. o Privacy: An unauthorized entity intercepts identifying data for the Master Device or its Slave Devices, such as serial number and location. Note that core PAWS does not address client authentication, on the = grounds that unauthorized clients could find out the existence of white space on their own without the help of PAWS, and in that case there = would be nothing preventing them from using it. The ID does point out = though that client authentication may be required by specific regulatory = domains, and so it is possible for the Database to require client authentication, = e.g. by TLS. The authors appropriately point out the limitations of = using TLS for authentication, particularly when the keys are trusted to small ubiquitous devices. =20 I believe this draft is ready. Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil On Jul 8, 2014, at 12:17 PM, Catherine Meadows = wrote: > I am resending this, because I got one of the email addresses wrong. >=20 > Cathy >=20 >=20 > Catherine Meadows > Naval Research Laboratory > Code 5543 > 4555 Overlook Ave., S.W. > Washington DC, 20375 > phone: 202-767-3490 > fax: 202-404-7942 > email: catherine.meadows@nrl.navy.mil >=20 > On Jul 8, 2014, at 12:10 PM, Catherine Meadows = wrote: >=20 >>=20 >>=20 >>=20 >> Catherine Meadows >> Naval Research Laboratory >> Code 5543 >> 4555 Overlook Ave., S.W. >> Washington DC, 20375 >> phone: 202-767-3490 >> fax: 202-404-7942 >> email: catherine.meadows@nrl.navy.mil >>=20 >=20 --Apple-Mail=_6BB4887E-10C4-482A-B607-92DB2E46D30A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I have = reviewed this document as part of the security = directorate's 
ongoing effort to review all IETF documents being = processed by the 
IESG.  These comments were written = primarily for the benefit of the 
security area directors. =  Document editors and WG chairs should treat 
these = comments just like any other last call comments.


This ID = describes a protocol, PAWS,  that allows wireless devices to access = currently unused portions of the radio spectrum.
The protocol works = between a geospatial database and a device with geolocation = capabilities.  The device reports its location
and other = relevant information to the database, which in turns gives it = information about which portions of the spectrum is available to = it.
This removes the responsibility for managing the complex = information about spectrum available from the device and to the = database,
which is better equipped to handle it.  I previously = reviewed version 12 of this ID, and although some changes and additions = have been made to the Security Considerations
section, they are = minor and do not change my previous review, which ran as = follows:

The ID has a very thorough and well-written Security = Considerations section, which  covers the security threats against = such a protocol.  They identify two
main threats

 By = using the PAWSl, the Master Device and the Database expose
themselves = to the following risks:

o Accuracy: The Master Device = receives incorrect spectrum availability
information.
o Privacy: = An unauthorized entity intercepts identifying data for
the Master = Device or its Slave Devices, such as serial number = and
location.

Note that core PAWS does not address client = authentication, on the grounds that unauthorized clients could find out = the existence of white
space on their own without the help of PAWS, = and in that case there would be nothing preventing them from using it. = The ID does point out though that client authentication may be required = by specific regulatory domains,
and so it is possible for the = Database to require client authentication, e.g. by TLS.  The = authors appropriately point out the limitations of using TLS for = authentication, particularly
when the keys are trusted to small = ubiquitous devices.   

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

On Jul 8, 2014, at 12:17 PM, Catherine Meadows <catherine.meadows@nrl.navy.= mil> wrote:

I am resending this, because I = got one of the email addresses = wrong.

Cathy


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

On Jul 8, 2014, at 12:10 PM, Catherine Meadows <catherine.meadows@nrl.navy.= mil> wrote:




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


= = --Apple-Mail=_6BB4887E-10C4-482A-B607-92DB2E46D30A-- From nobody Fri Aug 15 19:23:45 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5FCF1A09EF for ; Fri, 15 Aug 2014 19:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCiJdBDiZ7WM for ; Fri, 15 Aug 2014 19:23:42 -0700 (PDT) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88E761A0944 for ; Fri, 15 Aug 2014 19:23:42 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s7G2Ne5M016011 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 15 Aug 2014 19:23:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3B103049-F560-43AC-8019-874BA4004CD7@vpnc.org> Date: Fri, 15 Aug 2014 19:23:39 -0700 To: secdir Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Ke4BDLzhyhs4WiyWCdIyypl_SqM Subject: [secdir] Secdir review of draft-ietf-pwe3-mspw-er X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 02:23:43 -0000 This document is about L2 pseudowire path setup. There are no real = security implications (beyond the normal "we pretend to do routing on = layer 2 but not really" things that give me the willies), and the = Security Considerations section here points to the appropriate security = considerations sections in earlier RFCs. --Paul Hoffman= From nobody Mon Aug 18 13:38:53 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1271A014C; Mon, 18 Aug 2014 13:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.659 X-Spam-Level: X-Spam-Status: No, score=-0.659 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.668, T_HDRS_LCASE=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DrzYkwKE3Dn; Mon, 18 Aug 2014 13:38:51 -0700 (PDT) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE8E1A0010; Mon, 18 Aug 2014 13:38:50 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [198.74.231.63]) by cyrus.watson.org (Postfix) with ESMTPS id EFFF046B0D; Mon, 18 Aug 2014 16:38:49 -0400 (EDT) Received: from fledge.watson.org (weiler@localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.8/8.14.8) with ESMTP id s7IKcnjQ008698; Mon, 18 Aug 2014 16:38:49 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.8/8.14.8/Submit) with ESMTP id s7IKcmfM008692; Mon, 18 Aug 2014 16:38:49 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 18 Aug 2014 16:38:48 -0400 (EDT) From: Samuel Weiler To: iesg@ietf.org, draft-ietf-karp-bfd-analysis.all@tools.ietf.org Message-ID: User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (fledge.watson.org [127.0.0.1]); Mon, 18 Aug 2014 16:38:49 -0400 (EDT) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/yCUmAz686Mi1S-VUy3TsLMvK4xY Cc: secdir@ietf.org Subject: [secdir] secdir review of draft-ietf-karp-bfd-analysis-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 20:38:52 -0000 (Doc scheduled for telechat this week.) I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: I'm not seeing anything that's grossly incorrect, but I wonder if this doc is taking the right approach. The security consideration section acknowledges that increasing the length of the sequence number or connecting the sequence numbers to clock time could reduce the risk of replay attacks as, presumably, could moving to the "meticulous" approaches that require an increasing sequence number (and recomputation) at every packet, at the possible cost of needing special hardware or having to increase the time between BFD packets. These seem like simpler fixes that adding a new hash algorithm, which is what the doc ultimately suggests, and I wonder if adding GMAC is really needed. One thing that's not explicitly discussed, and which I would like to see, is a general analysis of algorithm agility - how hard is it to add a new algorithm? The doc says that BFD has no key rollover mechanism - I suspect that adding that and algorithm agility are more important, in the long run, than just adding a stronger hash algorithm. (Which isn't to say that we even need to improve those, just that they may be more important.) I'm also somewhat skeptical of the premise that BFD needs to use algorithms that match the routing algorithm strength: Moving the routing protocols to a stronger algorithm while using weaker algorithm for BFD would allow the attacker to bring down BFD in order to bring down the routing protocol. BFD therefore needs to match the routing protocols in its strength of algorithm. Are the attack models of the two really aligned? Do the keying models for both suggest that one or the other could cope with weaker algorithms? Can one be more easily rekeyed, thus making it easier to cope with weaker algorithms? Lastly, RFC5880 (the BFD spec) says: An attacker who is in complete control of the link between the systems can easily drop all BFD packets but forward everything else (causing the link to be falsely declared down), or forward only the BFD packets but nothing else (causing the link to be falsely declared up). This attack cannot be prevented by BFD. Given that, does it make sense to go to this pain to replace MD5 and SHA1? -- Sam From nobody Tue Aug 19 08:05:44 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0AC61A8958; Tue, 19 Aug 2014 08:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQZ4ZLIPn4g4; Tue, 19 Aug 2014 08:05:06 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60AA81A8943; Tue, 19 Aug 2014 08:04:54 -0700 (PDT) Received: from mb-aye.local (c-67-171-230-191.hsd1.wa.comcast.net [67.171.230.191]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s7JF4rh9071249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 Aug 2014 15:04:53 GMT (envelope-from joelja@bogus.com) Message-ID: <53F36790.6020206@bogus.com> Date: Tue, 19 Aug 2014 08:04:48 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Waltermire, David A." , "iesg@ietf.org" , "secdir@ietf.org" , "draft-masotta-tftpexts-windowsize-opt.all@tools.ietf.org" References: <53C478E7.2030902@bogus.com> <25df6a98f9de45a1bfbc54153db42584@DM2PR09MB0224.namprd09.prod.outlook.com> In-Reply-To: <25df6a98f9de45a1bfbc54153db42584@DM2PR09MB0224.namprd09.prod.outlook.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bbXN3V9Uq1Q2XTqKgHuOddMOltg82riAk" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Tue, 19 Aug 2014 15:04:53 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/LUQZL8pJrhohk1tzefpsnfD-2Xs Subject: Re: [secdir] secdir review of draft-masotta-tftpexts-windowsize-opt-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 15:05:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bbXN3V9Uq1Q2XTqKgHuOddMOltg82riAk Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Greetings, An update that attements to address issues surfaced in last call has been uploaded. http://tools.ietf.org/html/draft-masotta-tftpexts-windowsize-opt-11 Diff is here. http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-masotta-tf= tpexts-windowsize-opt-11.txt Some explanatory text has been added to the security considerations secti= on. On the question of creating and maintaining an IANA registry for option strings, rfc 2348 elected not to manage "string space" having existed at a time after tftpext had concluded I think we are better served by continuing that precedent. I don't see a likelihood that dedicated resources would be put behind the maintenance and extension of TFTP notwithstanding RFC 1350s underspecification of some implementation details which have since become implementation folklore. I think the nits have been cleared, a language edit performed. Thanks joel On 7/14/14 5:53 PM, Waltermire, David A. wrote: > Joel, >=20 > Thanks. I was just looking at the email threads pertaining to this draf= t and there was a concern about registering the "windowsize" option strin= g with IANA. >=20 > http://www.ietf.org/mail-archive/web/tsv-area/current/msg01102.html >=20 > This seems like a reasonable request, but there doesn't seem to be an a= ssociated IANA registry defined in RFC2347. I'm not sure if this should b= e a going forward concern or not, but it is worth highlighting. >=20 > Thanks, > Dave >=20 > -----Original Message----- > From: joel jaeggli [mailto:joelja@bogus.com]=20 > Sent: Monday, July 14, 2014 8:42 PM > To: Waltermire, David A.; iesg@ietf.org; secdir@ietf.org; draft-masotta= -tftpexts-windowsize-opt.all@tools.ietf.org > Subject: Re: secdir review of draft-masotta-tftpexts-windowsize-opt-10 >=20 > Thanks! I think these are reasonable suggestions and will confer with = the author. >=20 > joel >=20 > On 7/14/14 5:32 PM, Waltermire, David A. wrote: >> I have reviewed this document as part of the security directorate's on= going effort to review all IETF documents being processed by the IESG. T= hese comments were written primarily for the benefit of the security area= directors. Document editors and WG chairs should treat these comments j= ust like any other last call comments. >> >> Status: Almost ready - There are a few security and other related conc= erns with this draft summarized below. >> >> The draft defines a method for overriding the default step-wise acknow= ledgement (ACK) behavior of TFTP. This extension suppresses the standard = step-wise ACK response until a negotiated window size of blocks have been= sent. A single ACK is then sent indicating that all blocks in the window= were transmitted. This results in a general reduction in the number of A= CKs over the exchange, allowing for higher transfer rates than using bloc= k size negotiation alone (RFC2348). >> >> Security Concerns: >> >> The specific security considerations statement appears to be copied fr= om RFC2347. It acknowledges that TFTP does not have any explicit security= mechanism and that the extension does not add any additional security ri= sk beyond the base specification. Instead of copying the text from the ot= her RFCs, this text should be replaced with text that references the secu= rity considerations from RFC1350, RFC2347, and probably RFC5405. >> >> Additionally, it seems like this option requires a state machine, invo= lving both the client and server, to track the exchange of blocks within = a window to support retransmission of failed blocks. If I am understandin= g this correctly, it looks like a potential attack vector exists where a = malicious client (or server) could cause abnormal consumption of system a= nd network resources through the use of large window sizes across a numbe= r of sessions. This malicious actor would need to selectively cause retra= nsmission of blocks that still conform with max retry, timeout, and delay= constraints. In part, the second paragraph (and the following example) i= n the "Congestion and Error Control" section provide some error handling = guidance that also addresses this security consideration. At minimum a di= scussion of this attack vector and a reference back to this explanation s= hould be included in the security considerations section. It would also b= e valuable to include some discussion on reasonabl e limits for window sizes, retry, timeout, and delay parameters, or at le= ast some guidelines around determining them based on the characteristics = of the data link layer protocol used. >> >> Other concerns: >> >> In the abstract: >> >> - The abstract should mention that this memo extends RFC1350 by adding= a new option extension for ... based on RFC2347. >> >> In section "Windowsize Option Specification": >> >> - The text in this section should be updated to make use of RFC2119 ca= pitalized keywords. >> - A specification for the Read and Write requests is provided along wi= th an example. The specification of the corresponding OACK should be prov= ided with the same degree of rigor. >> - The draft describes the ACK behavior for data exchange in the defini= tion of the windowsize "#blocks" field. The actual requirements should be= defined using RFC2119 language in a new paragraph after the discussion o= f option negotiation. This new text should express the actual windowing b= ehavior requirements for implementations of the protocol extension. It sh= ould also make explicit which block number to send in the ACK, which I in= fer to be the last block sent in the window. >> >> General nits: >> >> There are a number of grammatical and punctuation issues throughout th= e document. Some of these make it more difficult to understand the docume= nt. A quick editorial pass through the document should address this conce= rn. I am happy to provide a few specifics/suggestions in this regard if t= he author would like. >> >> Also, the nits tool reported: >> - An issue with 3 pages being longer than the required 58 lines per pa= ge. >> - The abstract contains bracketed references. See previous comment. >> - Whitespace warnings >> >> Regards, >> Dave Waltermire >> >> >=20 >=20 >=20 --bbXN3V9Uq1Q2XTqKgHuOddMOltg82riAk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlPzZ5EACgkQ8AA1q7Z/VrLA+QCfSkFsxH/j0BvT5laymI+EisyJ 7u8An2iquTJroDFs5I82DxV9Oq0qZD6f =7QA5 -----END PGP SIGNATURE----- --bbXN3V9Uq1Q2XTqKgHuOddMOltg82riAk-- From nobody Tue Aug 19 08:16:01 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C963A1A87E5 for ; Mon, 18 Aug 2014 22:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtqbbXsWBgWc for ; Mon, 18 Aug 2014 22:16:25 -0700 (PDT) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 751D61A87E3 for ; Mon, 18 Aug 2014 22:16:24 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id hz20so5381608lab.22 for ; Mon, 18 Aug 2014 22:16:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HIYpeigDo/OQrnfOhTO6AnOwqQOnr1DtRqMjBttavMw=; b=TqdWkUKVjvEt43UTDiLAsYvC99feK/Rku8TYeL7IQ+R50/cHNQkgNpxqGnixU3Pvi4 uWV4JcZQlqqPlhpufe2dZgMxFi86+j37DnQa/Kn1AbVeTSBYbwttjE92dIBg9gHMoPsB 2X02ylIk6OrtXi5BHTsMejxILzNnc1GGW4s5ebmAQtSHD7S+txQ4giRDpTL1rUWGmHiF mC4HLTnwWa5IOytcQjl8zeYJF81Ic/AC4cCwt7kKUErRaKL4MCzKtEwxxY3hrx7EV5WH Soorx4pE1t3Nrfg3UXox4oHcVERq+i1raQTseAMUJUX/Hh28CXaqRAgAFxhzvQxQlpzu K5Yg== X-Gm-Message-State: ALoCoQlk3kPwXAmNbSG9VIAnA/CSVnYLC2teZopG8Ju+qS/Zt6yYLr6t33stGq9tzHbYvchjqLIU MIME-Version: 1.0 X-Received: by 10.152.87.164 with SMTP id az4mr34131111lab.25.1408425382648; Mon, 18 Aug 2014 22:16:22 -0700 (PDT) Received: by 10.112.8.4 with HTTP; Mon, 18 Aug 2014 22:16:22 -0700 (PDT) In-Reply-To: References: Date: Tue, 19 Aug 2014 10:46:22 +0530 Message-ID: From: manav bhatia To: Samuel Weiler Content-Type: multipart/alternative; boundary=001a11c354c2a032810500f4961b Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/TwVZJ0L2J1wxcrHy3Py6P6t9oGI X-Mailman-Approved-At: Tue, 19 Aug 2014 08:15:58 -0700 Cc: draft-ietf-karp-bfd-analysis.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-karp-bfd-analysis-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 05:16:27 -0000 --001a11c354c2a032810500f4961b Content-Type: text/plain; charset=UTF-8 Hi Samuel, Thanks for the review. Please look at my comments inline. > The security consideration section acknowledges that increasing the length > of the sequence number or connecting the sequence numbers to clock time > could reduce the risk of replay attacks as, presumably, could moving to the > "meticulous" approaches that require an increasing sequence number (and > recomputation) at every packet, at the possible cost of needing special > hardware or having to increase the time between BFD packets. These seem > like simpler fixes that adding a new hash algorithm, which is what the doc > ultimately suggests, and I wonder if adding GMAC is really needed. > We need to remove all references that suggest tying the sequence number to the clock. I had removed that in the -05 version and i forgot to remove a remnant from the Security Considerations section. Will remove this in -07 BFD is a unique control protocol that sends packets every few milli seconds and is hence almost always implemented in the hardware. It is virtually impossible for HW to authenticate each packet that comes at this rate especially when you have scaled up your sessions. Enforcing "meticulous" mode is only going to make matters worse. In fact, we've often discussed about deprecating the "meticulous" mode since that doesnt make any sense in the context of BFD. > One thing that's not explicitly discussed, and which I would like to see, > is a general analysis of algorithm agility - how hard is it to add a new > algorithm? The doc says that BFD has no key rollover mechanism - I suspect > that adding that and algorithm agility are more important, in the long run, > than just adding a stronger hash algorithm. (Which isn't to say that we > even need to improve those, just that they may be more important.) > I agree. This should be mentioned. > > I'm also somewhat skeptical of the premise that BFD needs to use > algorithms that match the routing algorithm strength: > > Moving the routing protocols to a stronger algorithm while using > weaker algorithm for BFD would allow the attacker to bring down BFD > in order to bring down the routing protocol. BFD therefore needs > to match the routing protocols in its strength of algorithm. > > Are the attack models of the two really aligned? Do the keying models for > both suggest that one or the other could cope with weaker algorithms? Can > one be more easily rekeyed, thus making it easier to cope with weaker > algorithms? > Theoretically the two should use algorithms of similar strength. In fact one could argue that BFD needs stronger algorithm since an attack on BFD can bring down all your control protocols. > > Lastly, RFC5880 (the BFD spec) says: > An attacker who is in complete control of the link between the > systems can easily drop all BFD packets but forward everything else > (causing the link to be falsely declared down), or forward only the > BFD packets but nothing else (causing the link to be falsely > declared up). This attack cannot be prevented by BFD. > > Given that, does it make sense to go to this pain to replace MD5 and SHA1? > Sure, but such attacks are outside the scope of routing protocol security. Cheers, Manav > > -- Sam > --001a11c354c2a032810500f4961b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Samuel,

Thanks for the review.
=

Please look at my comments inline.

=

The security consideration section acknowledges that increasing the length = of the sequence number or connecting the sequence numbers to clock time cou= ld reduce the risk of replay attacks as, presumably, could moving to the &q= uot;meticulous" approaches that require an increasing sequence number = (and recomputation) at every packet, at the possible cost of needing specia= l hardware or having to increase the time between BFD packets.=C2=A0 These = seem like simpler fixes that adding a new hash algorithm, which is what the= doc ultimately suggests, and I wonder if adding GMAC is really needed.

We need to remove all references that sugg= est tying the sequence number to the clock. I had removed that in the -05 v= ersion and i forgot to remove a remnant from the Security Considerations se= ction. Will remove this in -07

BFD is a unique control protocol that sends packets eve= ry few milli seconds and is hence almost always implemented in the hardware= . It is virtually impossible for HW to authenticate each packet that comes = at this rate especially when you have scaled up your sessions. Enforcing &q= uot;meticulous" mode is only going to make matters worse. In fact, we&= #39;ve often discussed about deprecating the "meticulous" mode si= nce that doesnt make any sense in the context of BFD.


One thing that's not explicitly discussed, and which I would like to se= e, is a general analysis of algorithm agility - how hard is it to add a new= algorithm?=C2=A0 The doc says that BFD has no key rollover mechanism - I s= uspect that adding that and algorithm agility are more important, in the lo= ng run, than just adding a stronger hash algorithm.=C2=A0 (Which isn't = to say that we even need to improve those, just that they may be more impor= tant.)

I agree. This should be mentioned.
=C2=A0

I'm also somewhat skeptical of the premise that BFD needs to use algori= thms that match the routing algorithm strength:

=C2=A0 =C2=A0Moving the routing protocols to a stronger algorithm while usi= ng
=C2=A0 =C2=A0weaker algorithm for BFD would allow the attacker to bring dow= n BFD
=C2=A0 =C2=A0in order to bring down the routing protocol.=C2=A0 BFD therefo= re needs
=C2=A0 =C2=A0to match the routing protocols in its strength of algorithm.
Are the attack models of the two really aligned?=C2=A0 Do the keying models= for both suggest that one or the other could cope with weaker algorithms?= =C2=A0 Can one be more easily rekeyed, thus making it easier to cope with w= eaker algorithms?

Theoretically the two should use algorithm= s of similar strength. In fact one could argue that BFD needs stronger algo= rithm since an attack on BFD can bring down all your control protocols.
=C2=A0

Lastly, RFC5880 (the BFD spec) says:
=C2=A0 =C2=A0An attacker who is in complete control of the link between the=
=C2=A0 =C2=A0systems can easily drop all BFD packets but forward everything= else
=C2=A0 =C2=A0(causing the link to be falsely declared down), or forward onl= y the
=C2=A0 =C2=A0BFD packets but nothing else (causing the link to be falsely =C2=A0 =C2=A0declared up).=C2=A0 This attack cannot be prevented by BFD.
Given that, does it make sense to go to this pain to replace MD5 and SHA1?<= br>

Sure, but such attacks are outside the = scope of routing protocol security.

Cheers, Manav<= /div>
=C2=A0

-- Sam

--001a11c354c2a032810500f4961b-- From nobody Tue Aug 19 16:20:25 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04F01A6FDE for ; Tue, 19 Aug 2014 16:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.807 X-Spam-Level: ** X-Spam-Status: No, score=2.807 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FSL_HELO_BARE_IP_2=1.674, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmfQHl5oJ9LZ for ; Tue, 19 Aug 2014 16:20:21 -0700 (PDT) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [69.56.212.20]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05F791A6FC1 for ; Tue, 19 Aug 2014 16:20:21 -0700 (PDT) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id 4B9E7781D514B; Tue, 19 Aug 2014 18:20:20 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway02.websitewelcome.com (Postfix) with ESMTP id 368E0781D512A for ; Tue, 19 Aug 2014 18:20:20 -0500 (CDT) Received: from [96.231.227.95] (port=64315 helo=192.168.1.6) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XJshP-0006fU-A7; Tue, 19 Aug 2014 18:20:19 -0500 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Aug 2014 19:20:15 -0400 Message-Id: <5CEB01E3-9793-4FE1-81CB-1C294980ECB2@ieca.com> To: draft-ietf-appsawg-nullmx.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.227.95 X-Exim-ID: 1XJshP-0006fU-A7 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.6) [96.231.227.95]:64315 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/-KyP0TQUdDvbExy80Crk-GEI2Rc Cc: The IESG , secdir@ietf.org Subject: [secdir] secdir review of draft-ietf-appsawg-nullmx X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 23:20:21 -0000 This is way late =85 I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. Summary: well written - no issues - ready to go - enjoy. spt= From nobody Thu Aug 21 05:20:28 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F32DD1A6FBF for ; Thu, 21 Aug 2014 05:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-LhahWDO_-P for ; Thu, 21 Aug 2014 05:20:21 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5697D1A6F9E for ; Thu, 21 Aug 2014 05:20:20 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s7LCKGZ5016992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 21 Aug 2014 15:20:16 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s7LCKGNq015300; Thu, 21 Aug 2014 15:20:16 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21493.58368.796962.771551@fireball.kivinen.iki.fi> Date: Thu, 21 Aug 2014 15:20:16 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 3 min X-Total-Time: 3 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/bNeKUJ-bddQEHv8Q8y7MFlVuN8M Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 12:20:24 -0000 [Note that those draft-ietf-jose-json-* documents are quite long (32-75 pages), so better reserve some time to review them, so Kaufman, Kelly, Kent, Kumari and me are going to have some fun... If you cannot make it, inform me as soon as possible, so I can assign another reviewer]. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Ben Laurie is next in the rotation. For telechat 2014-08-21 Reviewer LC end Draft Shaun Cooley T 2014-08-08 draft-ietf-tram-auth-problems-05 Alan DeKok T 2014-08-08 draft-ietf-appsawg-json-merge-patch-06 Dorothy Gellert T 2014-08-08 draft-ietf-core-observe-14 For telechat 2014-09-04 David Harrington T 2014-08-22 draft-ietf-ippm-lmap-path-05 For telechat 2014-09-18 Sam Hartman T 2014-08-22 draft-ietf-dnsop-child-syncronization-02 For telechat 2014-10-02 Chris Inacio T 2014-08-26 draft-ietf-tsvwg-rsvp-pcn-09 Last calls and special requests: Donald Eastlake 2014-08-08 draft-ietf-conex-abstract-mech-12 Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14 Dan Harkins 2014-08-22 draft-ietf-6lo-lowpan-mib-03 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-06 Jeffrey Hutzelman 2014-08-22 draft-ietf-soc-overload-rate-control-09 Leif Johansson 2014-08-29 draft-ietf-6lo-ghc-03 Simon Josefsson 2014-09-01 draft-ietf-bfd-intervals-03 Charlie Kaufman 2014-09-03 draft-ietf-jose-json-web-algorithms-31 Scott Kelly 2014-09-03 draft-ietf-jose-json-web-encryption-31 Stephen Kent 2014-09-03 draft-ietf-jose-json-web-key-31 Tero Kivinen 2014-09-03 draft-ietf-jose-json-web-signature-31 Warren Kumari 2014-09-03 draft-ietf-oauth-json-web-token-25 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Ondrej Sury 2014-07-30 draft-ietf-ipfix-text-adt-10 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-11 Tom Yu 2014-08-09 draft-ietf-forces-model-extension-03 -- kivinen@iki.fi From nobody Thu Aug 21 12:56:16 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 074B41A06D4; Thu, 21 Aug 2014 12:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D44VexPmps4P; Thu, 21 Aug 2014 12:56:13 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 144061A0698; Thu, 21 Aug 2014 12:56:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=603; q=dns/txt; s=iport; t=1408650973; x=1409860573; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=crgDaQaRMoKc5m7JggI0/OnMV8GvWwHXEl84qGiFV/g=; b=Z7rihJgWY1BtI8WAUo6qM9+hHa96SOEZ+y1mJ9R1iQ7UfyC5GJofVYnA dzndMPGy7hlrd7iEhDiL/L3K6V3VUOxRZw2aLruTjb5B+0JIGpfAEDTZD DybR8G4krFbE4YhMwmI0rLYjBM5U1S7b2iY2sMevHFkyKnU21fZpMv392 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAIFN9lOtJV2b/2dsb2JhbABZgw2BLtQfAYEPFneEBQEEeRIBKlYmAQQBDQ2IOsNdF48bMYM2gR0BBJEloCyDXoI0gQcBAQE X-IronPort-AV: E=Sophos;i="5.04,374,1406592000"; d="scan'208";a="349298970" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 21 Aug 2014 19:56:12 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s7LJuCKa021933 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Aug 2014 19:56:12 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.49]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Thu, 21 Aug 2014 14:56:12 -0500 From: "Shaun Cooley (shcooley)" To: "secdir@ietf.org" , "iesg@ietf.org" Thread-Topic: secdir review of draft-ietf-tram-auth-problems Thread-Index: Ac+9ea1oQaVlv8JyRUCafArZzl2a8A== Date: Thu, 21 Aug 2014 19:56:12 +0000 Message-ID: <187A7B1DA239514F9146FC78B19AADE323581B6C@xmb-aln-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.187.21] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/SZpn_Cz2u4J7BUXGhZW-uhL18I8 Cc: "draft-ietf-tram-auth-problems.all@tools.ietf.org" Subject: [secdir] secdir review of draft-ietf-tram-auth-problems X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 19:56:14 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document describes security and practical problems with the current Se= ssion Traversal Utilities for NAT (STUN) authentication for Traversal Using= Relays around NAT (TURN) messages. I consider this document to be READY for publication. -Shaun From nobody Thu Aug 21 14:15:05 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4171A8A0C for ; Thu, 21 Aug 2014 14:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKziYK5hkUIA for ; Thu, 21 Aug 2014 14:15:00 -0700 (PDT) Received: from it-ipcorp-02.silverspringnet.com (it-ipcorp-02.silverspringnet.com [74.121.22.26]) by ietfa.amsl.com (Postfix) with ESMTP id 0108F1A8A08 for ; Thu, 21 Aug 2014 14:14:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwEAOhg9lMKOQx0/2dsb2JhbABWA4JHgXAE1B8BgSd3hAoFdBIBJQEBAR8JBRABDgwUEwQOBAEGCMwoF451PAsQBhKEOwWUc4Z3mUVsgQdBgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,375,1406617200"; d="png'150?scan'150,208,217,150";a="1534370" Received: from sfo-barrlb-02.silverspringnet.com (HELO mail.silverspringnet.com) ([10.57.12.116]) by it-ipcorp-02.silverspringnet.com with ESMTP/TLS/AES128-SHA; 21 Aug 2014 14:14:57 -0700 Received: from SFO-EXMB-03.silverspringnet.com ([fe80::e877:a0b0:2e8d:1b57]) by SFO-EXCA-03.silverspringnet.com ([::1]) with mapi id 14.03.0181.006; Thu, 21 Aug 2014 14:14:57 -0700 From: Dorothy Gellert To: "secdir@ietf.org" Thread-Topic: Secdir review of draft-ietf-core-observe-14 Thread-Index: AQHPvYT0N/LFM96RqkeqGk5xiJ2XGA== Date: Thu, 21 Aug 2014 21:14:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.57.115.59] Content-Type: multipart/related; boundary="_004_D01BA4C515153dgellertsilverspringnetcom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/EMEq2_gq1_eaVx7BI1OiQQ5GHj8 Cc: "draft-ietf-core-observe.all@tools.ietf.org" Subject: [secdir] Secdir review of draft-ietf-core-observe-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 21:15:02 -0000 --_004_D01BA4C515153dgellertsilverspringnetcom_ Content-Type: multipart/alternative; boundary="_000_D01BA4C515153dgellertsilverspringnetcom_" --_000_D01BA4C515153dgellertsilverspringnetcom_ Content-Type: text/plain; charset="us-ascii" 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 Standards Track draft is a best effort protocol extension to CoAP to e= nable clients to retrieve a representation of a resource and keep this repr= esentation updated by its server for a period of time. The security considerations section does exist and discloses the following = threats and suggests ways to mitigate these attacks. - an increase in amplification attacks, and requires the server to limit no= tifications without client authentication. - acknowledgements may be spoofed if confirmable messages are predictable. - server may want access control to prevent resource exhaustion attacks, - intermediaries may create loops.. Section 1.3, describes 2 issues where a client might be assuming an old sta= te. This issue could be considered a security threat depending on the sensi= tivity of that resource. You might want to flag this also in the security = considerations section. This protocol is intended to be best effort only, as noted in the abstract = section. This should be also emphasized in the security section. In general, very nice thorough analysis of all the race conditions inherent= in a best effort only protocol syncing state between client and server. As an editorial comment, please expand the first occurrence of CoAP Best Regards, Dorothy Gellert Silver Spring Networks Director, Standards and Technology E dgellert@silverspringnet.com O +1 650 839 4378 C +1 650 556-5994 [Description: Description: Description: Description: cid:image001.jpg@01CD8= D1D.E8F2D9D0] --_000_D01BA4C515153dgellertsilverspringnetcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable 

I have revi=
ewed this document as part of the security directorate's
ongoing ef=
fort to review all IETF documents being processed by the IESG.
Thes=
e comments were written primarily for the benefit of the security
a=
rea directors. Document editors and WG chairs should treat these
co= mments just like any other last call comments.

= This Standards Track draft is a best effort protocol extension to CoAP to e= nable clients to retrieve a representation of a resource and keep this repr= esentation updated by its server for a period of time.
The security considerations sec=
tion does exist and discloses the following threats and suggests ways to mi=
tigate these attacks. 
- an increase in amplifi= cation attacks, and requires the server to limit notifications without clie= nt authentication.  

- a= cknowledgements may be spoofed if confirmable messages are predictable.&nbs= p;

- server= may want access control to prevent resource exhaustion attacks,

- interm= ediaries may create loops.. 

Section 1.3, describes 2 issues where a client might be assuming an old = state. This issue could be considered a security threat depending on the se= nsitivity of that resource.  You might want to flag this also in the security considerations section.
This protocol is intended to be best effort onl=
y, as noted in the abstract section.    This should be also emphasized in t=
he security section.
In general, very nice thorough analysis of all the race conditions inher= ent in a best effort only protocol syncing state between client and server.=  

As an editorial comment, please expand the first occurrence of CoAP = ;

Best Regards,

Dorothy Gell= ert

Silver Sprin= g Networks 

Director, St= andards and Technology

E=  dgellert@silverspringnet.com

O=  +1 650 839 4378

C +1 650 556-5994

=


 


--_000_D01BA4C515153dgellertsilverspringnetcom_-- --_004_D01BA4C515153dgellertsilverspringnetcom_ Content-Type: image/png; name="6FB6AF3B-86F9-4E67-ABF0-08E361B809CE[4].png" Content-Description: 6FB6AF3B-86F9-4E67-ABF0-08E361B809CE[4].png Content-Disposition: inline; filename="6FB6AF3B-86F9-4E67-ABF0-08E361B809CE[4].png"; size=14034; creation-date="Thu, 21 Aug 2014 21:14:55 GMT"; modification-date="Thu, 21 Aug 2014 21:14:55 GMT" Content-ID: <14209B76-9968-4F5C-9DBD-3DDDC4D316C7> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAfQAAAAyCAIAAAAlcr7AAAAgAElEQVR4nO29eXxc1ZUtvPa5tzSU hlJpli2pSrINtiRbHjCzJzAzCZDOQCYgnU53J5CxX3deks5ASHenIXnpdPf3+nUGApkTIAFCmAJ4 YjB4km0NBmypSvKgeS5Nde/Z749zzq0r2cnve8E2YNf6JVhSVd26wzn77LP22nsTSwYzBDMEADAT EQAwGOZngAFAEgQzgwgAAQxIwGIXZLH+LIMF9IfAkOaAEhDMZD4rmZnIgu/o3qfSSOMMgtT/MjNZ ataoSaF+gJlj+leAiJhTUw/+V4nUEcg7LISaXOqvgGQI9SozEZEEEwjMBGK4RJaES7D0eyDIO0kW IDMXGWBmQSdrUnpX5L80NmaE1CV4f+Q/Zg3021xAMEOZGyYmZYjUqYP12yRBQKaMm3dY/+HNz1Ld rpN0uW8JEDMby8tEpK7V3F8pwQSLUndNPwZveDFALFyCBbUeAGQelXeoP3UCkgGkRpgE7FN7xWmk cRrB+v+g4+eCz7al/mbsvnKizCvaWjEEGEQSDJAwBzFTMmW8HPLPI2PgUsb/uJOkWb+olUOc8M1/ Nnz2HXqNgu/k/W8DqXNQBte3mHmXDEBCEguatc6xeZEkWKjjq2uQcAWsOQuJ79xcIjrD7LtIAuop ErGUDpOEGnIECSJY2ks3S7r2FNiFFGABJpAUACDV2yTgKp+dAEgCmFn5AdD/VW6CerqCZj25tGVP 40wD6f2qhH/wm92wsWpqCkhlz0mZHzVxAGOMBIOJwBAgwcoxIuNjqY9JBoPYNseUYLAghiAXgIQg 9Tlp5jNDEqTrmUgyX3dKLLtkSJBkSIYLAlj4bDcAh0HKIgOCiPUKyMLcBAmSyphAG2KR8vopCQKT BNQuxNWOI4NgMTOx/kbvrPRFEwHiTLLsAIjNQ2ZzXbOWUCL1jP1+vfYg9OfNZzw3RI9XAclmXdV3 k8ECrMet/7tSv5xgUU0jjbc39NRwQZbezhrXlUlZLsW3GGuqTD8Byu80DryefAwmQLu3PhOc4hf0 J6QmUPUkdQmW2W0zC2Gc39THATV5vdNQNM5Juwlm8zCHdPKZgpStIJ79ce/tyhylrtVYfPVXfUSG MCSEurdziBikSIUTbZ/OENC77v7JkmhNABLskhAumCQRkQu2CQ5LkGWzs6xmfiio3WqWdmFeRmN1 GSCJLJ9Fli6EBXgkoOdQSLBgAvRohrf5Uq96A/iMvMdpnOVQHDBJCRJgCRIgj2k5zpuRPmMn5r4i KBXc0oy5dCEsBkgOjU83dR4RbDMzE8X7hmK9I0Q24DJcF4Hm+LGRxIxktgSkpnbc4cR0U3s3CWYw YEESMZQ/JwSklDgpIGGxW1VaWF1aaEGSZFhCMhFQEAw0RMsECwgL0rXBDbUV4cyAFBaAwpxAQ7TC YjBMfOJ4vtfYcR3J8HMvs5YoyYALYauHAAkWIOWEypNOQ73pILz3Tii+yezFhBBSSkEs2YIl4DoA QDYBBBeKapFCCJI8A7Zh8YbFC0AugHX1VWA7FAwsry0D2+vrKhi2XpO1164WWzl77GqHAmfSrU0j DQDGMZ8VO/XYZxX0Mz8YCkIJE8AQQ1NO88E4iYwkO9vaOpnJRrJ/ytnXcQwQkkRnd3+sf5RJQBln IciVbDEpB18ySHvBLEjZMTCBpSAGhASBiFgyE2CMJ0njBYtUQPgN3gQhNX1rbKi2xdr4qHgvgZgg iQGyJEtAkKZ1dZx53dKFBJeZoyV5tSUhlzJI8ob6Sglhg9csqXEEbEgAas1jaJWH3iYxJJkNjfZB XSbLbJvOKOaANnz1pwwpWLJQgXWLpRQCTFJIdiiwP3Z0ODFDcCCZRYBJWmxLOJZ0HWETCORAMhFJ skhKYsFCPTML7DLJ9fWLwO6l9TULS/OjRUXr6quY9JhWOF4bkEYaZwwUp+xCWD4pizI9u2NHE4mp aRF4vuV128XgTHJ3x1FCxkBiuiXWKclWM0tZ2xTd4gK2gHSVmEWyADtCCCbJkgSxhCWYJLmCZ9Y2 1AnpuBYxk8WCMHNpw0Ihp13KEAxBnGQphE2cbKipKsm2CFIKS7pCCDBcIU9OGOzZtnYAyoNWq5eA ZOYtLV0sLJJJCIshBhMTze3HWFiQEOQwgdkikGDJJCXIYsuFK4gkEwQLhmSGsAQ7km0IkHSJeM2S KCy7MNteWlMm2VpQHIqUF5Ar19fXgBw2NL1Hhel/zizmgJhZGWL/dSn5lI93I1/YGrG+oY7eEeXn u2xvOXCIpEVEu+PdicRYEoFtLR1MgmSSRYBcZiISM2CbSYAcyxV1NZWro0WX1kUva6iJFOf7iMMz auVMI41Y71i8b2AkMbEn3idJNMW6xxKTg4mpfbFuZiLhsrSMA+tRB0a8aEgGFfgTRMtqKgqybaJA fjCwrGaexVKSCGfbK2vmJVWYFc6aulplt/RH9W7AVTFD9oW+DIkvtfDGj1Nj5tgQSv5pnvoqo/zx aPF471Csb0RCCMjBiel9sW5mZsHx3rGOvpEAXIfsbc0HJdnE6oNJFgFIhgVytAYQ5AgOSAGQIySY 0FgVKcwRebnB5ZGy3NzgedVFRO7a+oVnmufuxYvfMDySywWRZBEfGO3s6W/vS3T1De6NHemdohf2 tbLIBHMqjEsiUhK6afXiW9YvWxEtVWJcvVE1w53ncjhppHGCaBhrRwwwouYUS2tGkcq0IN8RfD9o yZYD2N7RjDbOhYpGGhqXZgu0GU2xo4MT7taWQyxoW0sXk9zbfmR4QjI7BLAgHbqULhExuYAlZFJS FsFluADW1i+0QPnBwIpoOZhDuTmNkRKLZV5u7opo6cm9b/onACrQepwp13yRuYfqj/63aLra8wJ9 91/rKoxIXt8lJfNPiTXVrVMRVBNGJm8Tr44j5nydJ/ecJZY3P29tjkmwFPR8S9wlMT4xtjvWD1fE BwY6+gfANiRZJFzpwhJAkthiEsRgJCECxA6ztbY+asG9tK42g/mS+ojFYk1DNc0KYutxkrpeRfQY PYgXHgeER7vNurc+Uk4dSo8lX7DlpJAZJ9G4g1PTRbsJALyItnol3ju0p7Nnd0f3trbOzfs7AGHB ZRKSRU1J/qeuv+jWtQ3hnGy9gONM2yil8f8Kk5AyaxT4BoUEkJJ8zA7Um9hjSsY7y3yoNDqWTF6k x8utc0ysSB1T6wLU925qiY1OTDXF+uK9Q7H+0T2dR4bHppT9FmAXQkU6BbF0hWKKYXFhVtayyDzY 0+vPXQJyK0vzF5QUkjuzsqYyNzcTAMEBbH3OUPywJzA5aR6lJ4FngCS7gi1JIGIvPQUOIJQAYq4n qxWcnt2RqXuuhEDqsJ4Qhf3vVIkvDrOlOYDj4qIsHSJb6y8wNx3SH5xInZJUqUxKieSCLE4p+eZe +dYDrzluoKt/rL1/YCzh7In1MMktzXEBF1DRXclKKmoizoJYgkM5ecujJdGSvJqSksZIcTiYs66h 2kRSGCoADSlBxBJkke+2Mbsgy3cnpbehMKopfbbGi4VvtXtDz/0ke+76gmcJV42NxtxFiYHfvdz2 TFvnYztbO/rHiCVLK5yb/aPbr3vnqiVm2Zekx1kaZyVcQBw3ctglWH6B4OytvXK0tSWzzBTSaUEs mZSZYOElZ6s9vLeKMACMTEztjvV29Q509I929I7F+geaY72DiWmCI7VwWBCxCQySIFdKsW5ZtDA7 szFSJgWvq48QY3l1ZUGuTSyZbDNp1fZglt8z24JLMMMQNeq7TtINVU6w8YW9fCLSskjjaAsGQJ7y OXWvfXIdAYbSNkujgzMHhnkakiRBkE6L1QZLgm2dZ0SzpZ/mJDUHrhNrZ+8OMNse+CzkHCjLS74Q qvcR42ib4Ee8f3wisavj2NjE9L5YT9/41N7O3tHEBAGSSRATC0lgdr1EgXBeRmOkakVNSSiYsXbJ gmhJfrS0QN2d1F7H6F/NGafkOD5/Y9aqaU7Nr/j8M3HSjHvKoPuTmOGZdV8SrHk/jEMEyE2tsa8/ 8OLm5kNKLXbrhhU/+sQ1hAADQJJgpWmZsxSpAe5jY81MSBkSP8mi9B76jUaSa3wOBrS74I1RxsjE xO5Yb6xvLN470BTvG52Y3NwSA7skbCk9va9iKVSqi4yWhiPFBcujZeGczKXR0qLs7DX1UfgVvdKs SQRGykPRC4+x5HJ28odHEKnJ7WeWTipSrrRkW4vC2acENBmekvQd9nxt6ZvhrG+gYdKZVSUS8j81 Fi6ZBTrlrZuFzZyIhLQkgywmv93Q3AWxUKlJxnzouwgyKe6eAgdkFDIMsiCZtcoTZs3RHrQECY9f U76/sane6vFcc4dN9nOtr48mnD2xI7H+RLxngCEEMcNsGckRUrhgCKyvW1hblFddmrumPrKgtCxS kqvSg/2BhFmmXEdWpF6BWMmZvNXhLeK5z5mESC3IBG//kUopNpsOj3STDLGtpevTP36yqb1bEH94 /fIfffwdhuRKW/azFH/UaUi9qiBZu0xkLDiYhM/8S0W4D49P7Y/3tfcOd/b374r3jk5Mb27pNGF/ ByyYBDgJtvWotFBTGIqU56+MzM8PZq2vq8rPyVwRLXMV9WKIAgdsK6M0S4Tu+Yhq0jKItBny0U3m bE/kwqd8zJM4BbRoZ1btGLXL0beamZQp9KszfRyKL+rAJoXFt8jqfYnZGrlgW89080aPHNNlFVSw TTvyLjSp67iwlYRfL47Sl500aySk1C6z2Bzv4piJyNvPzeH4UhEUdTqpn/QqC/1dkllIwr5Y98jE 9ObmjvjAWKx3ZFfn4fHRaYYAOSDLo+aZLQHeUF9dXzu/pjC3saZsfV0UEP40Bcxd87xvByRJSjGG fwZOnnFXfsof2T7r5Ve/NeXC+7Zw+j6OTUx/9r4n792yG7C2fOUja+oqT43nksbbBZoimEP3MTNM HS4yrAILInZhkjaGx6f2dh2L9Y7Fegab4n2jkzOb9x8EWYykgCW9UUoucQDksKQVNfMKcjLX1EcE Y01dbTjHXhGp8PbUqbQjPdpn5ZSmnBspNBOggk/qxLwaJynz4nlzMkVbG7PlN1InM/DEkMSJycnP /ei5e7fsKc3LHpicWlJe/IPb37E/3nP3b7b/58eu+u7ju3Kz7B/d8Y4sO3DCI2jr4xFHPjdOz2lg aGrys/c/87Mt+0J5mYnxZLSs4N9vu+qKxmrA1nGOlFWVpHToRGDXJeuLP3nmd01tj3z+Q4tKcl0K KItsMmxNCutcT9GERjyGxzsrzzTNWhWkdppVYDil6DeLqFr7jALf87gNCQGpzocFCCMTM00dh3fH ew73je+K9zbFusbGHMXZQzActR0QTIgW5y+rrVxRVbyhvrqxpjyUk4U5w+fkPe6TVsuFRcoTSVlj T2Hp8xGk3mg6gK0qugEgIzvNDwa+fevVz7XEY/2j9/z++bX17wNLVU4vjbMSQhrL7vPpvJ27JAKT 6OgfifeMxXuH4v2je2NHhhK0pa2NJZkEGYvgSBJEFmOa2JaWWB4pCwUzNtTVhrIzV9SUVpWGa4tD ekefSoKX0ASOq7fKKqdRABAEQTzjUoaACyKp07MFCwidnm0pxoXgMQqKi2AWhNSKpfIkVeRNV2Qk k6nv6cdOCiS5gq0fb2n5wZYdH1i77NqlC9r7Et99/KVfPd+8cVnN2oZoYTBrMDHBdlaGFZgTKpNE Qp+zIGU32QWsFOtidhiS+Gebm3/87O4PrFt2VUNNfGj4nkdf/sVLzVc01gJgEoSUfVeLgdZ9ElmM BfOKL0ksDNo2ELAkWDhEtmWYFX8RMVIUvFpCCamxYXgP71a7gM3sqktQKcMEHQzVGxRTfA0ASZBQ ZXqITbkULx0MIFUqEXqBDwUz1tXXrqur9Va44URyT+zY/lj3rlhPZ//YlpZ2JiZwrG+go3/okR10 50MQjKqScGNNaWNN6cYl0fpoZThok9nBzGa3/hycTLXMn8ScfaV2Y1yWFs1dMxn4+gNbvvbrzStq ynd/869NKD+NsxMnltjuifUMTDgvtR7qm+DmQzEmwSQ0W0tSsASEFBZcKSi5NBIN59lrlkQLgxkr IvNqSoNVpcW+0J/0ZTMSUs5aKuDp0cSzXDl/2SX4tvPG6fPttXXBJb/XCUOsp6IFvsKrs+7BSXTd GSBsuPOn3cOJHf/yl7lZAUBuaenMsANLa0rYBYOu+Np9kfLwN26+PDszUBXO9WZfz8jYzOTU/LKS obGJne3dWQHZGK0qCGaOJ2cGh8eKCsKDYyOvHxttrC7JCNg33vOrWN/Inn/9WF4wkxibWjszLdFQ XTQ0kSwPZe3vHOgZStRVF0ZLC8Ho6B3Kz8nMFIHdnUcq8/PKi0LTrpOfmdneO1gVLhiZmWyO9YRy s1ZE5lsWCHJkIrk31u267tLayuRkwiVrXjh3JDEVsDNysk1KvGHGwFBymuNtJXuR4VQQIsUBqsOw MEId9g0PFTvh1OA4EXwxDMb++NGDfSP7Yv1bWjt2xY6NTiSJpYriCGLJLIirSopW1FSsXVK9qrro kqULLE1w/Zk4bVUYxfG/MpRjozWtrGqZQhC7LkhNG1eQOHkDO425MKOTDddJmjTzea8+nm1ORRTP EnllWtlswsy4lqlkGfONenYQUnIRb/qlTkoCaO8b6+oZ2d15ZHR8elNr1/DE5L5YN4MtabvkpOJR JNTmnFk21pQV5mRdWL+oLEssr6mIloSqS8N04kni0R7CAmDOCV5hRl8xDMWi0KxXzR98ajY9zgV5 79GvmSwhj5lM/Tr7O8j3agonewJUF+ft6Yg/+HLbbWuXMYm19VGS/L1nd/z8hVfvet+6YDA7Jyvz kVfaHt352rdvu3z1giowxiaTH/7/fnvRgqp3rF7yye8/1tY9bINXLSj/wSduGhhLfPx7j5XkB7sH J5qP9n/31o0f2bByfnHuKwePPvjyq3+5oY7JXl9fSSx+vb3tXx/eNi+cf7C3b3g0GcrNuvP96997 ft0XfvZsz8g42NoZ6/qLC5ctjxa9/PqRz1x9wZce2FKQlREfHNkf6yvLC37sylVfuOGirsHx23/4 +I6DXdMOnVdbPj6dXBEp+cq71z6+qz0UtK5YtTicHQDAEFPJmd0Hjw1PT4Wzcs5bUJFh67wZQ3yr UUOpB+Q9Qe+GC3jbJiLf8FD0Pf3pp+MjzAlLo/OWRufduBqESxiis3dob0f3zq7+ra3xfR2HR8cd l5Lx/qHOvtGHX26DxZDJDXV1y6PhdfW1jdGiSEkRAIYrQL4SXuaEvWXJJ7h800rsEhywzT5NKJGS f8Ela1tLB9gN5+ZaKaYyHVM9BfBGJxsOQdUaYUn+goWGHzUhOJ/dh9lTqyRKbbClSG3IdDxdHYrJ JaXAg1Ke6OqsTbG+0fGZzQcOjSSc3bGj8d6RWP+ocFnaBJbkEgSzlCCbhOOSI4guaVhk8/S6JdHc 3NzV1cWVZUW1xXkn3OT5RetnOZR052+vXP3U3oN3/PCxZ/Z13LZu2cZlEQhxZGRy+6GuxFQy05au 655/TuU//PTZp3bHz19QxSQ3tR164cDRKxsW3XHvU6MTM7/41A3dQ4n/8dOnvvHrrR+/csW+eO/E zMxfblj2Vxsbl0VLLYv+duN5T+3u+My9jz67v/229XVXLDsHwPjkxO5YX//Y5D99YH1xTu4Xf/mH f3pgc115cV9icmtb59r6qm9/8OqasoIHX25tinVPTDmtXT3dg+MfWt/46Wsv/NYjL9796NYbzl/8 3ce3P727/QvvumTNkupvPfHKrpZYQU52YsZNTE8JznKmXc7KeO3Y8LNN7a1HunfFetoO92YH7Hdd tPibH7wqLzNAJPyUh78l0WmA5yVUlxRESsPvvADAGgDt/UN74z1NB49tOxDf3Bpj1yZhbWp5bXOr 9Z0ndloSVWWhFZHS9XW1a+qrVlSXQdAshZWS6PuCQ/xm1k9nm5WUQUXIGSA11eW+WM/mti6C9c5V 52hq8mRGlNKYC3/KHIMEiMjilGsDQEhiAnuuTWrny0JojRpBla4iB+yNq1QTGPUQia3NLYeGJ5ym +JGRhLMn1tPVN9jeO2zKT7BirCVIwGULlitcgfVLIwXZOctriqtLw5GS3JXV80O5mVBMqF+pnRoq XrlyFXQ7SXVrzwAwC6KLFlT89u/f95Wfb3ro5baHXmp+1/l13/nLKwuzMsOZGZmW5Uh7KjlzXqT0 8uXRh3Y0f+KqlUX5wR8+t+f82ooZ19ndfuTOm9esWlAx4ziX7qx5Zv+hWzY0ZNjYuHTpv//V9UE7 oNRKFy+sfPTvb/7yb7b8ZnvLQy+3vOfCuu/edlUwmAWW//PGNR+8tJEA2xI3ffMXj+89GLTtiqL8 //7YjefOC0kWv9/9WpadZWVYWXZgY2Pt//7IO/KCFru4494nnj/QuWV/x3svbbjr5rUMzC/Ov7az R0qnqjjvfZcss4iGJqd/u7t1aHymbn7xuoaqgrzMrfs7P/GDJ/7rqaZ3rlx81YqF7GPnYfwSH7F2 iu9/ispjPfNAAGqLwzVFBTetWqzG7b72Y5tau5rivbs7D+/vOCIpEO8divcOPfzKAZBVkJOxPDpv XV1kXV3ZuvqFKmIvdDhTu8P0Zhp3tcXxgtda7SSI8dn7nySW4WDWLRsbtRE5vvZFGm8QZhyziWUR QD7th/KvdSSJmCCItSLB5+wIxW47xLYWGROkrbJkBieSzbHu9p7heN9AvG+0YzCx9+DhoamkYMfT uhBLlyyVKQpJoVB2Y6Sstig/WhqqLi6sLguvqq7IzwnoAlmQYJt80lhDa3hZphKklpNUCoz/YtMg YgaTEBctrHzqKx9+vu3Qfz3T9NBLLTlBa3F5qZVhOywtMLPIzMy85dLlH/uvx3a2d9dVFr1y8NgX b1zXPzoK1/mPx3f8++932IKnHaqvKh6fSgYC2edWhXLsAHS4VUKIC84tf+IL73/5wOH/fGrnL19s CWYE1tRHCnMCdfOKFZtXUx4OZmW0942MTEw3VpZUF+YAILAULsERcIQQyyNluUFidvOyswqysrr6 R5KSV9aUMVsknLrKknBe0HFkhpWBDOyI9x4+0nPhwvmN0XKvDv771y799ebXHn7lVYeGJM8Isg29 jpQHo+/OqX8AKSpPR9RhhieZCCiBGmsrltVWqLDQSGL6ubZDezt6t7V0PfdaO9gZmpCbW9o3tcaI iaSzZlnNurrIusXVl9XXmGIGkvjNo2Vg0ohJq/wFEYjx5Qe3bm2NEwe+/J614SyVEHG8bjWNNwwT jlc924h8Sfw+uZjZ+mnnGKb7CjQhIyEEgCP9I+09w3vjfSOJic2tXZKdra1HAHVkTdYbF54kLCIK Ba3G2qpocW5NaagxWhHOzlhbX+vVrDM8kBYOsl549PemXmXhs+wC7BpaafakTcNA3b0D3YNlecFw TmBN3YK1dQtuFg8/9vJrfCFl2RaRkMKBDFigDUsjlSXZP39hf2koz2a6/vwF//7Y9vyczO/eelVp Xn5SzuQHs3NyAkNDk44zk2GxN0+nHO7qGSzOyw7nBy5eXHnx4kpm+Yf9h0I5Qdu2Z1xXC+0dnpRO FpEdEBAshW1CoBYzuWRLZghBUkCA5UxSzIQyM8E8MjUFAUCMT87MTCWRk9k+NH1o3CnKybpm4ypV /5hITjuT03JwdKp/1O0XmbJl4LfBzq2FWYsXF1+cIQqISdvT0zhQfBXi9POAcm0BsCBBzC6T5aVP ExDKzbxp1ZIbV9epKbq1uXNTW8fuePe2lvjQ+AyEtbU5tm1/510kCVhbF9lQH11TF9lQH30TjXuq 8oypviTv27z/Gw9uBcS6pVWfum61lhulZ+gpgV5cJUgrO0Qq+VAHNnWXTi/rj8DyuZYuYcktzZ0j icndsb6RifG9sT5A9XoRDIcBWDbIVeVqCVxVEq4tDS2NlhfmBNYvqQnlZi2vKlfPP1WQS+Wf+Csw qXMA4NOrgIT3X4ZQYQChtfDsZ5NMVYBUP/c0YO7Ddf/805tWL77nliv1Ajkzkx3Myg5kSAkmBgvX Ei47VYX5N19Sf/ej2zOtwPsvXVIVzquvnjcwtqNvdPLdF9UT5MM7Dx5o679kYaVLsGTAK/DQN5q4 8u5f3LRqwbdvuVJ946QrMzPs4mDGYCLx+O7XNi6rZrIe2fW64/J5i8pf7+mXDoEdQgYYQkVnHAiW 5DKEBAvYYnJCLqjILy/Ifejllr/asDpSkvu9p3fFensLy4rIkpfOD+aKIATA7pQrDwz2j07Hy/KG D3SMtBwcWr0ob2P9gn19D+w68shA4n1rav/KhiBYZAJIUA7vKY/tzT6+dqSEBAS5DCFMB3M94ZQT IwTDVSe6pqF6TUO12mHviXdvbY1vaunc1HpwLAFJ2NzWtbmlEwARv3nG3ZMeaeshm+L9n/nxH4hl KMf+zefeI9hKZY6lt9UnH0LJVlSqAWnFEjEpNTOGE8l9HV3tA6Ox/vHO7v5D/WP7Y8eGEtMQJJyk JFMSi2wwEwvYLFleXh9x2FpfV1WUnbV0wfzaotzqsvBsVkRKHchKEgcEaV9Spbm7gA0pdV8JNvoZ 3eDF5FUSCMQ+7Yr+gZkV75By29PO+1wwAFSW5P2v3700NjlTXZLfFOt5aPuBf3zP2nB2Rt/oxMy0 O510sqYdl6UNXNNYf88jL85Mzrz/kmW2sN59wcIHX1h0x72PvXLoaHbA/v5zO288b8n6c6omJqZG klNSuWMkwsHsRUWhf3t0x2hipqasYF+s99Ht+++8+cpzKgttO+P/PLujeyQRtO0fv7j3XavPvWbF ud99dFcwJ0CSGBLECccZSTqSncSMnHaTalsvHXdscoos8Z1br3znPb++9hv3LaoqPNgzI+3sPIja giyVEsZMk9MTR6dGJ51kRXb1/OCqpzv39Y4f/Mqai5aXrw7nVPxm/53j1s7E9K2hzOBx2aynnP49 Pt6vtPMWK9GWBHhO7UzJQhAEWzB1dbQ3TCsQAJ8AABaNSURBVFgRLV8RLf/0tasBsSfWvbW5c0tb x+bW+ND4NN5Ezl3RsqQ7lLtNsb7L77x/ZHy6MCf7D1+7JZybaS5Qks56SONkwm9vm+JHhsbc59te dzjjhZZY/9RMc0dckgVYQoJJMoFcguWCCVKAAuFce1m0oqa0MFKcEy0trinOXR4tz88JeqLDlEoS qcoTgPClswVApnIJ6YXe0oqcOeIoQVonbpTLiluHkm+aBDfvyGmD/sfBJMH0i0++5+5Htj3e1O7u 5ayg9aV3r/n8dZfsOHT0E1etWlRa8J4L6gMB2xIZgNNYW/SN921MTM+ct2A+gFAweN8d1/7Hk2VP 7H4tYInPv3PtZ64/f3LK+fi1qy9fXGOZ5IDczMAP77j+2w+/+OS+2DPN8fxM+6vv3/iZa1Y/vPNA KJDxN9ec39bVszN++G8vW/WFd19anJN9w0UL87OyAjaIBcO9oqG2tjA0v7jww2vrLz6nUj3OhRVl n7zmgnmhwtL8jP/+22t3Hux2kfmp62vv+MGjlqM8FGLmpJygAObbRQtCWUTyaN/Y9/6wo25x4boV 5wwMT/YPZOYVTPb1Z3fTcF51ruJHDL93OgbOCdRcZDKkJEMIXfoBKWmjLrhAAKTWafJsvSYEgOXK 0F9/PiCb4n2bmztORxITQ0oItfs29X6kBAtpuQIW0NR+7LK7fjIyNi1td9M/fnBNwyKL9ez11zh+ a0J7C+S5mFp2YihgL3VCpj6j6+R5PRnYb8u8Vc2TmnAqCJ4qGA3f27xPSj3GoSoQeWwGA2CK9w/H eobj/WOH+vr3xfqGEzP74seGJqZAQkiHmYyuUVU6tJhAMllfO78kmNUYLQllZ6+rrxVw1tXVOgR7 VrHcNN4e8Bb1pCPHJqdc1w3Ydn5OtiBIKaWUlmVJKZnZsiw1qh3HISLLSjHFzDySmBICOVnZltAf JEsIEhLSMqn8jktDiWnJToZlhYKZJPC9p3d9+v6nn/nyLSsXVkxPOblZGQFbSLBMEizXVr1gIR2X JEkb5EqAZEDYIClBSZfGp6Yu/uKPFpTn/fMHry4KZt63ae+//Gbzt2+94uNXr3bAltqMwlIEi2Tc +eutdz20+dM3X31pden4+Gg88cC86mdf2nH1yzvnNy4u+sINFzdESo+vF3Zm4NR77uyl6gqo3QfA JAQcCFiQuzt6Nt51/9D4NCz60d/ctKZhkeVP7fM226f8RP+fwV4rB1PBWG0ffY27LChfCZiV0SDA rNY1qDi5hCtg+ART7IIhiQRrL1VoXlwzzg7rmrEeHw2QQ7CJMZxI7OvsH0pM7op1j0+4eztig5Ny b+wIS0tnJ2lOWoLZYpZkSbbCuZlLoxXhnMCyaGVtcU5NSShSGo6UhHXlFpPMKVmA1ATmt+BDSeNP w3tkAVsU5AYVI6fj0UIoOsuyLH8BV8/Kpw5CFMrNZt8HhdAehpVyU4QluCQvy+tPzQzbyswR2ZJk UFjBXMEAJAtBwoYqxU4AE2xBgMXkWIIFAhJMEALItGRmTsbdH1j7+ftfuO6uX+dlBgZHE5+7dv1H Np4PkA2lONHcB7P79IHBbzzw7M2Xn3fH+mUlQTk2kXw8trsgUP+N997+w+wDX3n4D7G+4W1fv80r 8HaG0b+n3nP30rWN3scFLFNivynee9nXfz6amJAO3/vJGz6yrhGQ0G0KhCkJirdsBpO/2j5DMlhR Y8pnn1UYzZdONqvZGBvn2njBbPaJnMri1BnSnCIw1CF5S1tcQmxr7XBhbW2NMdwtzZ2w1LlYBJcJ qlSTCtcwiHhmZU1lXjC4sqY0PxhcWz+fYV9WN8+BbZvvVdfm78nA0BKE45rpvEUfTRonhOm3B3/9 vjeSJHiCnkEq4dkfnGSo4jxd/WOx7sSF5xYF7ExT1B6qKqQktrycOP1XpAg6tRcm6UIIxujEVHNH x9DUZLS8tKFyHqTQ4gApIOAAFtA/lrjh27/t7T322D/+9eJ5IXbx/NGvNB3becOSv6/O3fBa19AV 3/xJ79jk5E8+728PcCbhNHHuqi4eTOjAFWQB+zr61t/1k7HxGYbzg0+++7b1S73cKjYVPI3w8y24 oqbKg6rfTacDZR+NACXlV3vqIICENMnvqn2XFoGkMvtTOcRSgICtLe0S9tbWDhf8YmvMYWtLW4eJ LgqAiKXlMls2CMIVTJIpWV1SHC3Pqy0siJQWRYoLakpzGqJlRTnZzILIAWzTq8EFLBvwEpQkUs9L JRno3jlMqRJ6Ki/h9N70NN4oUi2qfdHmN6A2Pt6yjyaOHezbXT9//Wiih+xAcV7FkaG2Y0Pt4ezS mnkXhvOo9egfEhNDleElZaUNx/rbinLm9461F4dqRsZ6wnmlednlPcPtbV3PZmcWrai5OiOQNZ4Y er1nu032vJL6wmDlwMShDGSfW02upLKCyonpwbYjz2fbwXPmrbdtwexaZHESn/rvR7fvb//VZ95/ 7rwQgP1DP9ke33bxwr+ozt0AkgeO9A2Nja9bXA1V3vGPVfV5O+PUG3dS/jo7YNvUOLU4OZRwLrvr Z2NjCVDgvttvunXtUmbWPDu0nIKha4rKNzL6TiEkEVxm4UuZ8baq0Alj8IIoKlRiYn5mSVBbU1gq tLi1OeaSvbXtEFhsao0JWJtb4mCHCYItSWpDwEIlE7ElwAw3lJ3ZWFMVyslaGSkvCAYbIwX5uaGV kdI590z3QdQ6JZvBQtH9uhmFKe/DQhffMykGLmARTGFrteym+l6m8XaCridhgtAA3gDpebzbLom7 hg48/OJd3XWvZohgWX6kKK9q16HH27t3rohcGalYASDW29TR3VJxfr1gHDz28oFk4rXu7XVVlw8m Dl+z/LPDE92bmr9fmDN/aGzfyMThKxpvPzL66ra27+UGiuePnndV48cPHH7x1a6txfnnLI+sBWNf /OlN+753zXmf1xtPIgb+9dGtv9z56lffedl7Lq1l4ODIk0+/ev/SeRdeUPJREMYm+D+f2zk2437u +kskVHsMmFSMP/vOvuVwutQyij3WUmYeSeDyr/94cGwcwvrRx6+7Zd1yHQCBq2mNWUo4vCVNiCZY hCHcNf0OCYIu4gohIFnXsjBFTYGRxHRLe1fvNPa1H3YJL7TFHcbWlk4il5lAFqQLQDVyJBBbFkmp ArBrl0QIzoaGRczuhvrqvJz85dWFpJuJwdvDsiF0yLSJUGFWgmW2DKk0ObVVZ23aiUwrHEGsynxZ IBU50IVlTCXstNDwbYe57PlJPRpUuoqUkdL6/uFDA4nempWfU/WJinPnlxcvFZKCmXmLKi61YEVL G4msisLFT+76VnXpqo7epsLckrzsovbuV8ZnBv/i4q909e55qum/NzSSZVkTMwFXTl9cdK6K9A4N vxTOra4sX+0C55ZfMD453NW/75yy5dnZJWBx7wv7v/yrbbdvuPgfPngxyOocevr3B/6jpnjhuqrP Wlb2TJLv/M2zf9j76j/csGbj0hphWrsAzGdWmYrTEVBVfQotLXxjsPi7Hz/SFOsjons/ceOt6xoo Vb0ktWdM4S0pyjAuD2kS09taqOrPBEC0xroHE1N7OruHEtOHe0fbewfbB0YP9w1KVSScWcWipJsk YQudjwOGk5+bu6KmFMDauhpmvqIuIsHr6qMeca9rqsBHf/v6zRkxrc4CV+epGRXd9CAlDGDorbpp 8mX0NUReHUSkRKupHjqUrgnxtsTc4tsnmYhg4bJTlrMoWrH61y9/yZEugQK23Z84fKD7+Xnhmrzs Mtd1JeA4TiBARXkVwazwBee8+6VXf1aWvxCEkvDikuzIr7Z8KekkVix4p02wXc4v2GDJmUk5QMQB 5qrqfxieth/a8eR7zrs24Uz2jsQmJzqm3A8HIR4/OPi5B168tqH27o9uCNr268MvPP7av80Pz78s 8tUsu8R1+ZsPb/2332+/8fylX7zxUtWsQzs5bJ1hO9HTE1A1+3sGSG5p6dxw508Z7q3rG+/7+I2z uot5VerhE/Ydn7P7loAD2C7Q1n6sbzIZ6xvq7BsemZza097tCntbcyuxzZQh4EomQEJ1dVHBSsFg JkZ+bt6KSElBbubSSGk4mLUyWhrKzVseKfEq62oXGZg1A30tjlP3NnVWIlUuTotpJEj4mjEfV7pa PSXzRSreq4O3BgwwXE9kNkulk8bbCccVYT4RThAm/f8HhpyYGpp0JwuyintG4uHs8mB2aHi8q3/s sBXIqSxYaNvByenhRHKsJKccZDmOMzLZV5BdMj7ZF8gKBQNBhpiaGj7Y+3JeVqiq5HyLqW9qmjCR LawJt68guHB0fMShbEEz01Pt84qWTE0Nd/btKgrVleRXP9Mx+sGfv7h4qv/Bv7uxsCB375Htz8T+ pb68eE3FP+Vll88k5dcefPaeR7Zf2bjo+5+4dn4o38jS9KmfIMXo7YxTbtwlGJBa9scAcOO3Hnh0 x6vVJflN3/zrUF4WFAcjXFLaPj2qVPD7eKpdN1YxnbSkJN3ldlbWjEmmIEClRBKI4KRq55vQpXFT xexWDElQQHf/IknAc62HbXB7z3C8d2R4cmpvvFuCt7TEBFvSkkKqrMsM4ikALCxIIUipBllIZ2lN VXGQliyMhrOsmpJQbUnY1BlPI400tGGdleFhXklMu1m2JXlSCNsie3zaCWYELFKtMlwiYghiySQe ax+87YHXF7vHHrz98lBO4OHXt+7ruvfauqLzy7+WZZcc7kv8z1889YsX99+6ftU9N28oKsh58672 NOGU0zKCiUlJH1UNSLmlpZ3ZvWX98oK8DCUEBBHpMxF+d8GTfgMAJCQxkVENSiW10i0WjCRRJ/jo IrRqJTASXNgmmqioCU90JQhyb6xnYCI5khjfE+sPQOw5dHR0aqo/4eyPH5YqDupI3TCShIqCgiyG FBKSbGIZLc2NllSEcvIbqwvDwazlNeUSYkN9ZWrlMNflK7F7RnkKaaTxZ2KWdFJ4auDBCXea3Ql3 UvJMwMoYmUA4m12CUH2oyVIhLZB46LXxT/2ufVUo8ctbrnE5+Z3tTwyMPfSu+vMuqLjDtrJ+v/vw l375u47u4X/54NWfu26lJU7UG/aMw+lQy8AXdQRzbXHRnomjj7/y+kfXLY2U5hFsUxMkCQS8MJ0W QaaMvc5TBxOxq4J8iuAgsJLrecWRDQMhVBNbCWqOHxscTbLl7usYGEokiOj5tlhSWp39Qx29YwIz ki1BrhQgKQAL7OhAgAwQuWALtmTmxkhVQV5GOCtjWe18ieTGxQtBzvJIVSjXUg3Wvb4Q7DX8ZDZZ FewVPHlLEk1ppPHmwGNiYfS3YDHmuK+OTlblTvUlpsnNGpoJLCwU4SxrFtMoCIx7W/r/x1OHrq6g +9+//tWhgX/d/kQ5PfeRlR9qKLt6ZkZ+8eHmux98LFoc/OVn333NigWzcsXPaJyWHqqmMIhiWb7z ++2fu/8pMADrhvMXra+Prqwsr64oiBTnz0nExyzuz88VOswWgfbEj40mppksKZ2ugZFY7xg4KYW1 pSWmXPx98WND49MkbMlsEbtSkrKtEGCXBZFLbAOuuhk2IZmfm7U8UkZEjdGKgqxApDQcLc0DsL4u qj0LdnXjb0VbS8ECYJd0N3BpElclJHlVDqUWvf/5bGYaaZx5mDUdPOPOLhHtaB/KCyXDWT2d3bmj ydyGSLgs2/a4VgAMOeXSPa/0fWtb50cWB752Vf2T8dd/su+Ri8J971r2+fqS8mc7E1/5/Y4XX9n3 0dVVf3/junMqComkK4V1dkgBTrlxZ0ACBC/bHgx8/YFt33385eHEBCkxuJCqMRO5tKqmJCcnRwjh yqRFAoKkVFkGkiVtaz1kFgpBqhMxuYAQlpRSAjZBgB1Asgho8kQTKRLMLCwA6+qjxAgHA8siFVJQ bVFBTWkOoLv9mhujev6pc1YVZb1spVmVKPyFstR7IaQDYeu2yy7rLeTcXA8gTcqkkUYKmlNlJnBs cLK9+2h03vjgEA8N519wbnV+TgbDAWxTIRzto1Off7bz6eZjX11fevWSsvtbNh3s3f4X56y6Zsm7 Rqbon18ceXDProqpgX+6ftV1y88JZLisW6daZ8m++fR47oCnvZMM4QL28MTEfZv2Pbzz1f3x3sHx CbBFwgELpSfxSnKnjkFJizNcSBBDkiCW0oFlE2s7C8hIaWGktICky8LeUDdPlTFcHiktygkyu42R ilButgm6Suhi454o0GTes47SqDMnSsVdfdFaaCsupRBKeeJIWCpHy8RvdfTX2Hw2+nLAWPU0557G WY9U7W8zyyBZPNccz8vrZHc61l2xsbGmODeYqoxB0pH85Gt9X3jsNWd6/BvX1lqZI0/FnlgQomsX fTg3OO/+/RM/fOV1a3LgloaKv7nknPJwDpuca5MCclbMu9NUFdILgoOFq+uIGd0L3NGEszt+zGJs autSghnMzo9gZoIEBZjdcDDYWFvBSFogR2JBaWGkNORpB/3RGK8cPDwKBZj1d10aPBXt9LdlSeXb 67NIiWrg5dCqxcBrKsKpM/ancJ55mc1ppHGSIE1RPFNkiSneN/7C63sLizqaWsreu+b82tICknCF tFgwoWd47J9/t+enzx+87Bzr5g0lI9Q0nuyqKVhXmnfxM532vTu73dH+DzSEP3ZRXW1RjnbcWKuD jYd1VnTuPB20DBm3VdX7VRJDVQbIKLIlSVOa5Y8bQZUiTDr3XUJVXfFMs9d51rPXunoX5mp7vSs2 AhtNkfu/16tnazq66UQh8wevwQX73HAwg9hX28t4JTjOV2d/QlAaaZy98Bx2z3l6vqXr+WMPDPXz yopr37duiVf3O+k6T++J3fmLF9uOtH/oyuAVF40kRevAeCRkX7vnaNn3XxkKYvz6RYWf3bBkSUWI WIAcpBQ4DrGtdHSm8PgZjlOullFaQ/WPKXErTHqM1+ZYQPje/KcP5f2g32gkhqnOs94v3hNMlZrD rJ/g/8jsv5rDprI99QfJywydvb9TXz/7r3Nq6s95d7pPUBpnO0xnO1WKTrXlkbvaj8bGd+1/veJD F4QBMCEx7ex4LfbzZ9t//tKecxcd/ruPHq6pmNrRETjYvmRkfEnL0d6CnKHbz4vcfGH90vklpHPu mHz2jWCDoAuPv1lXe3pxWjj3NNJII40TQ5qGNMLbl3/p55uebP1NdnCmoei6D1yyvP1o36OvdG5/ PV5cduiSVZ21lYmjfTkvNFUeai2fXzK/vrr46gurL19SW1marxqBacb1rPec0sY9jTTSeDPhyxLX 5Orjuw59+H89zJnDo+NZITvHyh5YUD68oHYwVDDV3R88GqvMEosbovMvPLd85cKK6qK8nIwMfxUO XQFPqxjOEjf9BEgb9zTSSOPNg7LqXksfAiAdRz7d3PVM0+t2Zm9J4eDENCanM2zk5QZKqosqFpeX zy/KLAjlZqrq17rTkwSrenpC050SoLkc7FmFtHFPI4003jQwu4BFs3tlmBq88JeV9kkzvDzB1Avs q7E36zin/5LeMjjz9UBppJHGWxZElpKfk64aIgG4AJMEOcYFd8HK3AtWvQl0/XV1CAlIXz1Haf53 tiPtuaeRRhpvAUjolgHsApam4SF1U3jTTgDsgiiVHKgLCJoKg8qYKZLnbHbaAaSNexpppPEmwhTW hmkITJpUMRFWnpNpODvFVBcs8GUQzsonObt5mbRxTyONNNI4A5Hm3NNII400zkD8XxCXrM/6ZP69 AAAAAElFTkSuQmCC --_004_D01BA4C515153dgellertsilverspringnetcom_-- From nobody Fri Aug 22 06:37:33 2014 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E9B1A03D3; Fri, 22 Aug 2014 06:36:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1408714591; bh=ao6FGptfqBkgmyxrTtlYMwwHrZ4lwSRHGtk5++GTC18=; h=To:Date:MIME-Version:From:Message-ID:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=uHbgQqh6VdBf/ehhWb9MSpemkVsRJ7Ux07ug8NYaYgEevnJzx+rw+fD0EP1H21X32 PX9w8gVP+1fZ9QIQmnol9cI+646xrXMBuJauwiRT7kYW3yKJy3MGaK+HKijnWoLL9S b2YRuoo7Xqkw+QNvjqnbczNj5MgcKux9EoFJFnWs= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16CF31A03D3 for ; Fri, 22 Aug 2014 06:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.97 X-Spam-Level: X-Spam-Status: No, score=-6.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaOwncxxi29u for ; Fri, 22 Aug 2014 06:36:27 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F163B1A03D0 for ; Fri, 22 Aug 2014 06:36:26 -0700 (PDT) Received: from eb.bleuazur.com ([88.173.33.195] helo=sith.local) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1XKp0y-0000yq-Lz; Fri, 22 Aug 2014 09:36:24 -0400 To: new-work@ietf.org Date: Fri, 22 Aug 2014 15:36:23 +0200 MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/1.0 (MacIntel) Archived-At: http://mailarchive.ietf.org/arch/msg/new-work/VVTB9sz-NDqBVuBNmewpiaS_9C8 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/d1la9UIB_svB4dGJrTJItGwAX0E X-Mailman-Approved-At: Fri, 22 Aug 2014 06:37:22 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: RDF Data Shapes Working Group (until 2014-09-22) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 13:36:31 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Data on the Web Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the RDF Data Shapes Working Group: http://www.w3.org/2014/data-shapes/charter As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2014-09-22 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Eric Prud'hommeaux, Proposed Staff Contact . Thank you, Coralie Mercier, W3C Communications [0] http://www.w3.org/2013/data/ [1] http://www.w3.org/2014/Process-20140801/#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Communications Team - http://www.w3.org mailto:coralie@w3.org +336 4322 0001 http://www.w3.org/People/CMercier/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Mon Aug 25 10:49:35 2014 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C581A001A; Mon, 25 Aug 2014 08:32:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1408980726; bh=Msu7k2kVWyLJBi2V4M0qqVPddQaGrdrCNl4P+KVsAJs=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=gBHJsJeblGw+AGsG4P+KdZ04W2oyu+ilfInKfqL8zkqKHPZDotJmo4WHnzzv//S3D X75bik5v2gzAPtvTDDs0Rg7xaAe97UHmFLTOAaB6lubBKJpq3j+Mu65Jg0uK5uqiUr VAXRltMsFzh2exvcBYGli3V4DCW7WXKw7eGneb+Q= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056DF1A0028; Mon, 25 Aug 2014 08:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viNID03DN7pq; Mon, 25 Aug 2014 08:32:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA311A000F; Mon, 25 Aug 2014 08:31:59 -0700 (PDT) MIME-Version: 1.0 From: IESG Secretary To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140825153159.4308.76559.idtracker@ietfa.amsl.com> Date: Mon, 25 Aug 2014 08:31:59 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/new-work/ghjIBK0bzpWpc65sLQKDkIB3lLY X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/7bb8ejBlaWjn9j3Z6q5KYuhopRs X-Mailman-Approved-At: Mon, 25 Aug 2014 10:49:33 -0700 Subject: [secdir] [new-work] WG Review: Planning for the IANA/NTIA Transition (ianaplan) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 15:32:06 -0000 A new IETF working group has been proposed in the General Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2014-09-04. Planning for the IANA/NTIA Transition (ianaplan) ------------------------------------------------ Current Status: Proposed WG Chairs: TBD Assigned Area Director: Jari Arkko Mailing list Address: ianaplan@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ianaplan Archive: http://www.ietf.org/mail-archive/web/ianaplan/ Charter: Background ========== Registries of parameter values for use in IETF protocols are stored and maintainted for the IETF by the Internet Assigned Numbers Authority (IANA), and are the subject of the "IANA Considerations" section in many RFCs. For a number of years, maintenance of the IETF protocol parameters registries has been provided by the Internet Corporation for Assigned Names and Numbers (ICANN). The IETF's relationship with IANA was formalized through a Memorandum of Understanding between the IETF and ICANN codified in 2000 with the publication of RFC 2860. Over time, processes and role definitions have evolved, and have been documented in supplemental agreements. ICANN has had a contract with the US Department of Commerce (DoC) to provide the IANA function, undertaken through the National Telecommunications and Information Administration (NTIA). In March of 2014, NTIA announced its intention to transition out of its current role, meaning that NTIA would not need to renew its contract with ICANN when that contract expires 30 September 2015. NTIA requested a transition proposal be prepared to outline the necessary arrangements. In the case of the elements of the IANA function concerning the IETF protocol registries, it is likely that the existing well-documented practices will continue and no or little new activity will be required. Tasks ===== The IANAPLAN working group is chartered to produce an IETF consensus document that describes the expected interaction between the IETF and the operator of IETF protocol parameters registries. The system in place today for oversight of the IETF protocol registries component of the IANA function works well. As a result, minimal change in the oversight of the IETF protocol parameters registries is preferred in all cases and no change is preferred when possible. The working group will address the implications of moving the NTIA out of its current role with respect to IANA on the IETF protocol parameters registry function in a way that focuses on continuation of the current arrangements. The working group will assume the following documents continue to be in effect: - RFC 2850 - RFC 3777 and its updates - RFC 2860 - RFC 6220 - IETF-ICANN-MOU_2000 (http://iaoc.ietf.org/documents/IETF-ICANN-MOU_2000.pdf) - ICANN-IETF Supplemental Agreements (updated yearly since 2007, the 2014 version is available at http://iaoc.ietf.org/documents/ 2014-ICANN-IETF-MoU-Supplemental-Agreement-Executed.pdf) This working group is chartered solely with respect to the planning needed for the transition, and is not meant to cover other topics related to IANA. Possible improvements outside that scope will be set aside for future consideration. However, the mechanisms required to address the removal of the overarching NTIA contract may require additional documentation or agreements. Should proposals made by other communities regarding the transition of other IANA functions affect the IETF protocol parameter registries or the IETF, the WG may also review and comment on them. Some parts of the transition proposal may need to document detailed terms of agreements or other details of procedures that are normally delegated to and handled by the IAB or IAOC. The working group will not attempt to produce or discuss documentation for these details, but will request the IAB or IAOC to provide them ready for submission as part of the final proposal. The WG shall seek the expertise of the IAB IANA Strategy Program to formulate its output. It is expected that members of the IAB IANA Strategy Program will actively participate in the WG. Milestones: Jan 2015 - complete protocol parameters registries proposal May 2015 - review of other transition proposals, if needed Sep 2015 - close _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Thu Aug 28 02:02:53 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1731A0435 for ; Thu, 28 Aug 2014 02:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.911 X-Spam-Level: X-Spam-Status: No, score=0.911 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.668, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TebHvgBQDBIN for ; Thu, 28 Aug 2014 02:02:44 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41D721A04E7 for ; Thu, 28 Aug 2014 02:02:35 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s7S92Ue6023083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 28 Aug 2014 12:02:30 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s7S92U6Y007595; Thu, 28 Aug 2014 12:02:30 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21502.61478.182400.762269@fireball.kivinen.iki.fi> Date: Thu, 28 Aug 2014 12:02:30 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/X2YQiljfISPAgolKlcAT3iaSMek Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 09:02:50 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Ben Laurie is next in the rotation. For telechat 2014-09-04 Reviewer LC end Draft Dan Harkins T 2014-08-22 draft-ietf-6lo-lowpan-mib-03 David Harrington T 2014-08-22 draft-ietf-ippm-lmap-path-05 Takeshi Takahashi TR2014-08-05 draft-dukhovni-opportunistic-security-04 Tom Yu T 2014-08-09 draft-ietf-forces-model-extension-04 For telechat 2014-09-18 Sam Hartman T 2014-08-22 draft-ietf-dnsop-child-syncronization-02 Charlie Kaufman T 2014-09-03 draft-ietf-jose-json-web-algorithms-31 Scott Kelly T 2014-09-03 draft-ietf-jose-json-web-encryption-31 Stephen Kent T 2014-09-03 draft-ietf-jose-json-web-key-31 Tero Kivinen T 2014-09-03 draft-ietf-jose-json-web-signature-31 Warren Kumari T 2014-09-03 draft-ietf-oauth-json-web-token-25 For telechat 2014-10-02 Chris Inacio T 2014-08-26 draft-ietf-tsvwg-rsvp-pcn-09 Last calls and special requests: Donald Eastlake 2014-08-08 draft-ietf-conex-abstract-mech-12 Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-06 Jeffrey Hutzelman 2014-08-22 draft-ietf-soc-overload-rate-control-09 Leif Johansson 2014-08-29 draft-ietf-6lo-ghc-03 Simon Josefsson 2014-09-01 draft-ietf-bfd-intervals-03 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Ondrej Sury 2014-07-30 draft-ietf-ipfix-text-adt-10 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-11 -- kivinen@iki.fi From nobody Sat Aug 30 00:12:33 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1BE1A8830; Sat, 30 Aug 2014 00:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, GB_SUMOF=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5yJ_eKV4bZs; Sat, 30 Aug 2014 00:12:27 -0700 (PDT) Received: from COL004-OMC3S12.hotmail.com (col004-omc3s12.hotmail.com [65.55.34.150]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D39E1A8846; Sat, 30 Aug 2014 00:12:27 -0700 (PDT) Received: from COL401-EAS183 ([65.55.34.137]) by COL004-OMC3S12.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22701); Sat, 30 Aug 2014 00:12:27 -0700 X-TMN: [4kdEvMFsMb+N4Nz6icRmaM0m4+rVph0t] X-Originating-Email: [charliekaufman@outlook.com] Message-ID: From: Charlie Kaufman To: Date: Sat, 30 Aug 2014 00:12:25 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0042_01CFC3E7.13FAA9D0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac/EILVlvaO6koWmSBq1KV+ptV1KBQ== Content-Language: en-us X-OriginalArrivalTime: 30 Aug 2014 07:12:27.0291 (UTC) FILETIME=[C14AE6B0:01CFC421] Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Z6SxK5P2zR1JfEcjQlhgMONCJn0 Cc: draft-ietf-jose-json-web-algorithms.all@tools.ietf.org, iesg@ietf.org Subject: [secdir] Secdir review of draft-ietf-jose-json-web-algorithms-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2014 07:12:30 -0000 ------=_NextPart_000_0042_01CFC3E7.13FAA9D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document sets the initial IANA registry values for the labels to be used to specify choices of cryptographic algorithms in the context of the JSON Web Encryption, JSON Web Signature, and JSON Web Key documents (parallel I-Ds). Some aspects of how the algorithms are used are specified here; others aspects reference other documents. The issues I found with this document (all of which are minor): Section 3.4 line 4 says Elliptic Curves are generally faster to execute (for equivalent security) than RSA. While that is true for private key operations (and even more dramatically so for key generation), it is generally not true for public key operations. This is a nit in the text since these trade-offs are well understood. Section 4.5 Direct Encryption: It might be too late to change existing implementations, but it generally a good idea when using pre-negotiated keys to include some key identifier in the header to remove ambiguity in the case where there are multiple pre-negotiated keys (perhaps because they are in the process of being updated and they are not atomically updated on both ends of the connection). Section 5.1: I don't believe the pairings of AES128/HMAC-SHA256, AES192/HMAC-SHA384, and AES256/HMAC-SHA512 are "natural" in the sense of providing equivalent cryptographic strength. Without the HMAC, they would, but I believe HMAC-SHA256 is generally believed to have 256 bits of cryptographic strength, making it suitable for pairing with any of the three AES key sizes. The choices of the longer SHA2 variants are conservative, however, and so do no harm if these pairings are already in widespread use. Section 5.2: Similarly, it is not appropriate to have the length of the Message Authentication Code (MAC) reflect the key length, since it does not affect cryptographic strength but rather the strength against on-line MAC guessing attacks. For this purpose, 128 bits is generally considered adequate for all key sizes and many implementations truncate this to 96 bits or even 64. Again, the current specification is conservative (if slightly wasteful of bandwidth), and so does not harm if this is already in widespread use. Section 5.2.2.1 says "The number of octets in the input key K is the sum of MAC_KEY_LEN and ENC_KEY_LEN." I believe it would be better to say something like "MUST BE the sum". The text goes on to say that the two keys must not overlap, but it is also important that an implementation not tolerate a gap between the two keys is a too large key is provided. Section 5.2.2.2 says the authenticated decryption operation has four inputs... . I believe it has a fifth: the IV. Alternately, the IV is pre-pended to the ciphertext (and hence implicitly included in 'E'). Section 5.3 specifies AES/GCM in much less detail than the description of AES/HMAC in Section 5.2. Is this because the referenced document [NIST.800-38D] includes all the needed details (like use of PKCS7 padding)? Section 6.2.1.1: Because of the controversy over NSA allegedly planting backdoors in the "NIST curves" listed, there is a growing demand that additional curves be supported. You might want to specify how additional curves can be specified in-line and/or how to get additional curves added to the IANA registry. Section 8.7: I believe the advice in this section is too strong. It is generally considered secure to encrypt multiple data sets with the same key so long as the IV is correctly chosen and it is also generally considered secure to encrypt the same data set with multiple different keys. There are many scenarios in which this is nearly impossible to avoid. It is important that when encryption multiple data sets with the same key that the IV be chosen appropriately - which is very challenging when using GCM as noted in section 8.4. Section 8.8: I believe the advice in this section is too weak. It is generally bad practice to derive cryptographic keys from passwords as passwords almost never have adequate entropy. Where possible, it would be better to have a strong (i.e. randomly chosen) cryptographic key associated with an entity and then use the password to acquire that cryptographic key. There are a number of means for doing that, including having the strong key encrypted with the password (or XORed with it) stored someplace the entity can access it, by having a server that will return the key based on a provided password, or with a strong password authentication protocol. Deriving the key from a password using PBES should be a last resort and demanding a longer password to derive a 256 bit key is only fooling yourself... you are never likely to get more than 64 bits of entropy. --Charlie ------=_NextPart_000_0042_01CFC3E7.13FAA9D0 Content-Type: text/html; charset="us-ascii" 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 sets the initial IANA registry values = for the labels to be used to specify choices of cryptographic algorithms = in the context of the JSON Web Encryption, JSON Web Signature, and JSON = Web Key documents (parallel I-Ds). Some aspects of how the algorithms = are used are specified here; others aspects reference other = documents.

 

The issues I found with this document (all of which = are minor):

 

Section 3.4 line 4 says Elliptic Curves are generally = faster to execute (for equivalent security) than RSA. While that is true = for private key operations (and even more dramatically so for key = generation), it is generally not true for public key operations. This is = a nit in the text since these trade-offs are well = understood.

 

Section 4.5 Direct Encryption: It might be too late to = change existing implementations, but it generally a good idea when using = pre-negotiated keys to include some key identifier in the header to = remove ambiguity in the case where there are multiple pre-negotiated = keys (perhaps because they are in the process of being updated and they = are not atomically updated on both ends of the = connection).

 

Section 5.1: I don't believe the pairings of = AES128/HMAC-SHA256, AES192/HMAC-SHA384, and AES256/HMAC-SHA512 are = "natural" in the sense of providing equivalent cryptographic = strength. Without the HMAC, they would, but I believe HMAC-SHA256 is = generally believed to have 256 bits of cryptographic strength, making it = suitable for pairing with any of the three AES key sizes. The choices of = the longer SHA2 variants are conservative, however, and so do no harm if = these pairings are already in widespread use.

 

Section 5.2: = Similarly, it is not appropriate to have the length of the Message = Authentication Code (MAC) reflect the key length, since it does not = affect cryptographic strength but rather the strength against on-line = MAC guessing attacks. For this purpose, 128 bits is generally considered = adequate for all key sizes and many implementations truncate this to 96 = bits or even 64. Again, the current specification is conservative (if = slightly wasteful of bandwidth), and so does not harm if this is already = in widespread use.

 

Section = 5.2.2.1 says "The number of octets in the input key K is the sum of = MAC_KEY_LEN and ENC_KEY_LEN." I believe it would be better to say = something like "MUST BE the sum". The text goes on to say that = the two keys must not overlap, but it is also important that an = implementation not tolerate a gap between the two keys is a too large = key is provided.

 

Section = 5.2.2.2 says the authenticated decryption operation has four inputs... . = I believe it has a fifth: the IV. Alternately, the IV is pre-pended to = the ciphertext (and hence implicitly included in 'E').

 

Section 5.3 = specifies AES/GCM in much less detail than the description of AES/HMAC = in Section 5.2. Is this because the referenced document [NIST.800-38D] = includes all the needed details (like use of PKCS7 = padding)?

 

Section 6.2.1.1: Because of the controversy over NSA = allegedly planting backdoors in the "NIST curves" listed, = there is a growing demand that additional curves be supported. You might = want to specify how additional curves can be specified in-line and/or = how to get additional curves added to the IANA = registry.

 

Section 8.7: I believe the advice in this section is = too strong. It is generally considered secure to encrypt multiple data = sets with the same key so long as the IV is correctly chosen and it is = also generally considered secure to encrypt the same data set with = multiple different keys. There are many scenarios in which this is = nearly impossible to avoid. It is important that when encryption = multiple data sets with the same key that the IV be chosen appropriately = – which is very challenging when using GCM as noted in section = 8.4.

 

Section 8.8: I believe the advice in this section is = too weak. It is generally bad practice to derive cryptographic keys from = passwords as passwords almost never have adequate entropy. Where = possible, it would be better to have a strong (i.e. randomly chosen) = cryptographic key associated with an entity and then use the password to = acquire that cryptographic key. There are a number of means for doing = that, including having the strong key encrypted with the password (or = XORed with it) stored someplace the entity can access it, by having a = server that will return the key based on a provided password, or with a = strong password authentication protocol. Deriving the key from a = password using PBES should be a last resort and demanding a longer = password to derive a 256 bit key is only fooling yourself... you are = never likely to get more than 64 bits of entropy.

 

         &= nbsp;      = --Charlie

------=_NextPart_000_0042_01CFC3E7.13FAA9D0-- From nobody Sat Aug 30 01:58:06 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1041A88E6; Sat, 30 Aug 2014 01:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.439 X-Spam-Level: X-Spam-Status: No, score=-1.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.668, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZTr9Tir626y; Sat, 30 Aug 2014 01:58:02 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41C551A88DF; Sat, 30 Aug 2014 01:58:02 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s7U8vxaG026239 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 30 Aug 2014 10:57:59 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.7/8.14.7) with ESMTP id s7U8vu1Z029545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Aug 2014 10:57:59 +0200 (CEST) X-Footer: c3VuZXQuc2U= Received: from [172.20.10.3] ([2.65.35.220]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.2.4) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128 bits)); Sat, 30 Aug 2014 10:57:56 +0200 Message-ID: <54019213.9000800@sunet.se> Date: Sat, 30 Aug 2014 10:57:55 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: draft-ietf-6lo-ghc.all@tools.ietf.org, "secdir@ietf.org" , IESG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09MIUVXqX - de98ed774959 - 20140830 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/HEBG58u3Ky2idU7v9JT3TBlHmCY Subject: [secdir] Secdir review of draft-ietf-6lo-ghc-03 [no problem] X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2014 08:58:04 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I'm not a subject-matter expert of compression or ipv6 but I can't find any issues with this draft. It seems ready for publication. From nobody Sat Aug 30 06:13:22 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9421A0262 for ; Sat, 30 Aug 2014 06:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODk5VGpgOT7e for ; Sat, 30 Aug 2014 06:13:13 -0700 (PDT) Received: from smtp66.ord1c.emailsrvr.com (smtp66.ord1c.emailsrvr.com [108.166.43.66]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 375931A8A13 for ; Sat, 30 Aug 2014 06:13:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp17.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 9AD3E18032D; Sat, 30 Aug 2014 09:13:10 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp17.relay.ord1c.emailsrvr.com (Authenticated sender: scott-AT-hyperthought.com) with ESMTPSA id E85A918027D; Sat, 30 Aug 2014 09:13:09 -0400 (EDT) X-Sender-Id: scott@hyperthought.com Received: from [192.168.128.24] (c-76-21-94-29.hsd1.ca.comcast.net [76.21.94.29]) (using TLSv1 with cipher AES128-SHA) by 0.0.0.0:587 (trex/5.2.10); Sat, 30 Aug 2014 13:13:10 GMT From: Scott Kelly Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3266E6F3-AB87-4B45-9C6F-A3B6976DBCEC@hyperthought.com> Date: Sat, 30 Aug 2014 06:13:08 -0700 To: secdir@ietf.org, draft-ietf-jose-json-web-encryption.all@tools.ietf.org, iesg@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/gSgizmypUAC1DmlqcAZqnofHKjQ Subject: [secdir] secdir review of draft-ietf-jose-json-web-encryption-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2014 13:13:14 -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. =46rom the abstract, JSON Web Encryption (JWE) represents encrypted = content using JavaScript Object Notation (JSON) based data structures. A = little like CMS for web transactions. The security considerations section begins=20 "All of the security issues that are pertinent to any cryptographic application must be addressed by JWS/JWE/JWK agents. Among these issues are protecting the user's asymmetric private and symmetric secret keys, preventing various attacks, and helping avoid mistakes such as inadvertently encrypting a message to the wrong recipient. The entire list of security considerations is beyond the scope of this document, but some significant considerations are listed here." "All the security considerations in the JWS specification also apply to this specification. Likewise, all the security considerations in XML Encryption 1.1 [W3C.REC-xmlenc-core1-20130411] also apply, other than those that are XML specific." If you are going to point to the JWS specification, you should use a = normative reference. It's fine to point at other references to avoid = re-stating the obvious, but all security considerations *are* within = scope, and require coverage, either directly or by reference. I haven't = reviewed the referenced W3C spec, so I'm not sure that everything has = been covered. The JWS security considerations section only talks about = crypto algs and server identity verification. So, the ADs will want to = pay attention here. In section 5.1 (Message Encryption), step 16 says "Encrypt M..." without = ever defining M. One might guess it stands for Message, but this should = be stated.=20 Section 8 (TLS Requirements) points at JWS, but neither document = references the channel binding problem. If you are depending on TLS to = provide essential and necessary security features (which, presumably, = you are since TLS is a MUST), then you should give clear guidance as to = how to effectively use it. JWS requires combined confidentiality and = integrity protection, and also requires server identity verification per = RFC6125, but does not mention channel binding. Section 11.1 (Using Matching Algorithm Strengths) says "Algorithms of matching strengths should be used together whenever possible. For instance, when AES Key Wrap is used with a given key size, using the same key size is recommended when AES GCM is also used." This doesn't quite scan for me, but editorial nits aside, it might be = good to say greater or equal key sizes should be used for wrapping. And = you might want to point to RFC3766 for BCPs when using public keys. Section 11.2 introduces the term "key tainting". "Strict key = management/usage policy" might be better understood. Also, it might be = valuable to use SHOULD here. I was surprised not to see any mention of the lack of replay protection. = TLS channel binding could presumably be leveraged for this purpose, but = in any event, the fact that JWEs can be replayed should be mentioned. I would suggest that the authors read the security considerations in = rfc5652; most of the same concerns apply here, and you could almost = cut/paste from there to here. For the ADs: I'm not sure if one of the companion documents provides a = comprehensive threat model, but you will want to pay attention here. = This doc does not. From nobody Sat Aug 30 13:56:35 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4181A0AF0; Sat, 30 Aug 2014 13:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sx0kWDvfB7XW; Sat, 30 Aug 2014 13:56:29 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47B091A0AED; Sat, 30 Aug 2014 13:56:28 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id s7UKuH46007724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 30 Aug 2014 22:56:19 +0200 Date: Sat, 30 Aug 2014 22:56:15 +0200 From: Simon Josefsson To: secdir@ietf.org, draft-ietf-bfd-intervals.all@tools.ietf.org, iesg@ietf.org Message-ID: <20140830225615.786868b0@latte.josefsson.org> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) OpenPGP: id=54265e8c; url=http://josefsson.org/54265e8c.txt Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA256; boundary="Sig_/Nw8OQi74uXYENv=dxpFCqUF"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.4 at duva.sjd.se X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/2kz_1WLPEHpBZK14x8mYb4jomd8 Subject: [secdir] Secdir review of draft-ietf-bfd-intervals-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2014 20:56:31 -0000 --Sig_/Nw8OQi74uXYENv=dxpFCqUF Content-Type: text/plain; charset=US-ASCII 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 describe how a flaw in BFD negotiation that can lead to peers failing to agree on a transmission interval can be mitigated by having nodes follow certain conventions. I see no security considerations at all related to this document, and the Security Considerations section adequately reference RFC 5880. Other comments: 1) Why is this document Informational? Not being involved in this area at all, it seems to me that the negotiation flaw is serious enough to warrant 'Updates: 5880' to make sure implementers/deployers read this document. 2) The document refers to RFC 2119 keywords (which are meaningless for non-standards track documents) but the only use of that (that I could find) is in the second paragraph of section 3 which says SHOULD about something that I interpret as being required elsewhere and merely repeated for illustration and background. Section 1 reads 'This document proposes a set of interval values that should be supported by all implementations.' -- I suspect this ought to be SHOULD (or even MUST) instead of 'should'? 3) Pretty please expand the acronym BFD the first time it is is used. Section 1 "Introduction" starts with 'The standard [RFC5880] describes...' and I suggest 'The Bidirectional Forwarding Detection (BFD) standard [RFC5880] describes...' instead. The abstract starts with 'BFD' and I suggest 'Bidirectional Forwarding Detection (BFD)'. Maybe the document title should be changed too, it is now 'Common Interval Support in BFD'. 'Common Interval Support in Bidirectional Forwarding Detection (BFD)' or maybe 'Common Interval Support for the Bidirectional Forwarding Detection (BFD) Protocol'? /Simon --Sig_/Nw8OQi74uXYENv=dxpFCqUF Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJUAjpwAAoJEIYLf7sy+BGd1I4IAIP8e1nGNiGRmf6tdhNLEaex /wbWLZr8SwPCxHmQmy5bg2nOBxT5ZgkRQkYzddri6SzfVy7sJfrAXGijUUqq1MbI m7XRkLarjk3i+wNahR+pyd44wS1EoWlfEGI9MnczF3sOawGip3lGjReCMmjh9qs2 jLRbS1YN6bv8EtlK7YLcd1k0b8Iga9w7uLXbGwUkdIN0FUZyNHlrK0eQYKcpi3c1 4LrN0eJxlkBaSETB7XJ6PPJKaj8wTMH62oY6ZmK6Zi/JH+7NR9vJySAQLkcjvLwh PbMZqdHobVmbFgQ/ssifjuVKePOE4IGOFiUVMAr4a6GEAu2zj3z+7kg+cV1xbRs= =HrKK -----END PGP SIGNATURE----- --Sig_/Nw8OQi74uXYENv=dxpFCqUF-- From nobody Sun Aug 31 12:38:00 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8591A8BB1; Sun, 31 Aug 2014 12:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QK2VAoWQrYIo; Sun, 31 Aug 2014 12:37:57 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32D201A8AFE; Sun, 31 Aug 2014 12:37:56 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id s7VJbkBq015489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 31 Aug 2014 21:37:47 +0200 Date: Sun, 31 Aug 2014 21:37:44 +0200 From: Simon Josefsson To: Marc Binderberger Message-ID: <20140831213744.3dc0fcff@latte.josefsson.org> In-Reply-To: <20140831114409097014.277d3630@sniff.de> References: <20140830170942319588.ce02d0f5@cisco.com> <20140831114409097014.277d3630@sniff.de> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) OpenPGP: id=54265e8c; url=http://josefsson.org/54265e8c.txt Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA256; boundary="Sig_//xecfQgaLUvA68XLklujD7P"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.4 at duva.sjd.se X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/n7wE5NR28-9zUPSY9Dk9smzMAOY Cc: Gregory Mirsky , "Nobo Akiya \(nobo\)" , draft-ietf-bfd-intervals.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-bfd-intervals-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2014 19:37:59 -0000 --Sig_//xecfQgaLUvA68XLklujD7P Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Thanks for response. If the standards track issue has already been discussed by authors and WG, then I'm happy -- I just wanted to bring it up in case it hadn't already been discussed. /Simon You wrote: > Hello Simon, >=20 > thanks for the review! >=20 > Let me start with the simple part: >=20 > > 3) Pretty please expand the acronym BFD the first time it is is > > used. Section 1 "Introduction" starts with 'The standard [RFC5880] > > describes...' and I suggest 'The Bidirectional Forwarding Detection > > (BFD) standard [RFC5880] describes...' instead. > > [...] >=20 > Good point. In fact a not-yet-published updated draft contains your > first example already; I will add your other suggestions as well. >=20 >=20 > > 1) Why is this document Informational? Not being involved in this > > area at all, it seems to me that the negotiation flaw is serious > > enough to warrant 'Updates: 5880' to make sure > > implementers/deployers read this document. >=20 > This was discussed in the BFD workgroup and the consensus was the set > of "Common Intervals" should be more a guideline for developers and > not a strict requirement. I personally think the availability of the > document to the public, including customers, will create enough > momentum for implementers to read this. >=20 > Appendix B is on the border, IMHO. The underlying mechanism is still > the same Poll sequence as defined in RFC5880, we just clarify how to > apply it in a multi-step convergence. And yes, RFC5880 has a "gap" in > assuming the convergence takes only one poll sequence. Again the > workgroup seems to be fine to have this additional information > informal. >=20 >=20 > > 2) The document refers to RFC 2119 keywords (which are meaningless > > for non-standards track documents) >=20 > you have a point but as we use this one SHOULD I thought it's good to > have this reference. >=20 >=20 > > but the only use of that (that I > > could find) is in the second paragraph of section 3 which says > > SHOULD about something that I interpret as being required elsewhere > > and merely repeated for illustration and background. Section 1 > > reads 'This document proposes a set of interval values that should > > be supported by all implementations.' -- I suspect this ought to be > > SHOULD (or even MUST) instead of 'should'? >=20 > We moved away from MUST to SHOULD when we decided the draft should > have an informal status. I reduced it to the one SHOULD in section 3 > as this is the only section that spells out a technical requirement; > the other sections explain the problem and the solution idea, which > is why I used normal English "should", "may", "recommend" for these > sections. >=20 > Kind of: getting the readers attention in section 3 as these > paragraphs need to be read more carefully.=20 >=20 >=20 > Let me incorporate your proposed changes and I send you a diff to > check I do address your comments properly. >=20 >=20 > Again thanks for the review! >=20 > Best regards, > Nobo, Greg & Marc >=20 >=20 >=20 > > I have reviewed this document as part of the security directorate's > > ongoing effort to review all IETF documents being processed by the > > IESG. These comments were written primarily for the benefit of the > > security area directors. Document editors and WG chairs should > > treat these comments just like any other last call comments. > >=20 > > This document describe how a flaw in BFD negotiation that can lead > > to peers failing to agree on a transmission interval can be > > mitigated by having nodes follow certain conventions. > >=20 > > I see no security considerations at all related to this document, > > and the Security Considerations section adequately reference RFC > > 5880. > >=20 > > Other comments: > >=20 > > 1) Why is this document Informational? Not being involved in this > > area at all, it seems to me that the negotiation flaw is serious > > enough to warrant 'Updates: 5880' to make sure > > implementers/deployers read this document. > >=20 > > 2) The document refers to RFC 2119 keywords (which are meaningless > > for non-standards track documents) but the only use of that (that I > > could find) is in the second paragraph of section 3 which says > > SHOULD about something that I interpret as being required elsewhere > > and merely repeated for illustration and background. Section 1 > > reads 'This document proposes a set of interval values that should > > be supported by all implementations.' -- I suspect this ought to be > > SHOULD (or even MUST) instead of 'should'? > >=20 > > 3) Pretty please expand the acronym BFD the first time it is is > > used. Section 1 "Introduction" starts with 'The standard [RFC5880] > > describes...' and I suggest 'The Bidirectional Forwarding Detection > > (BFD) standard [RFC5880] describes...' instead. The abstract > > starts with 'BFD' and I suggest 'Bidirectional Forwarding Detection > > (BFD)'. Maybe the document title should be changed too, it is now > > 'Common Interval Support in BFD'. 'Common Interval Support in > > Bidirectional Forwarding Detection (BFD)' or maybe 'Common Interval > > Support for the Bidirectional Forwarding Detection (BFD) Protocol'? > >=20 > > /Simon --Sig_//xecfQgaLUvA68XLklujD7P Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJUA3mIAAoJEIYLf7sy+BGdMzYIALE1XEdCaX+kAqX1QaEeUxEQ /r5EunPUwnPx5ZyRCKPru1p9drgzX4WBGfHE8ha6PRvEIBHwYL7HudTM231KYeky jxqHRYrdCYmmBSQo5Xk907In1oo6jkt4eDT5b9tmLv+V+x8ggIkAgcGjyBiDHelN aCLiPuI803c7aCGnxjO/bCdvF9xiWQNXxChKbf2wAcLHegu32mxQTlxdO+InT28M F1L+ewAVtIzDHxe9KEXQh8lGoKbV0JbtBpSt19rSpqQ/nPXC8X7vfSAsn3D359LN 78UmdCAAH95Bb6YmDR8kbF53GrFTbc/1iSnPGnaQK4oFmKA+K1wApaVQNngsU6s= =vCE8 -----END PGP SIGNATURE----- --Sig_//xecfQgaLUvA68XLklujD7P--