[secdir] Secdir review of draft-ietf-core-observe-14

Dorothy Gellert <dgellert@silverspringnet.com> Thu, 21 August 2014 21:15 UTC

Return-Path: <dgellert@silverspringnet.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id CC4171A8A0C for <secdir@ietfa.amsl.com>; 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-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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id lKziYK5hkUIA for <secdir@ietfa.amsl.com>; Thu, 21 Aug 2014 14:15:00 -0700 (PDT)
Received: from it-ipcorp-02.silverspringnet.com (it-ipcorp-02.silverspringnet.com []) by ietfa.amsl.com (Postfix) with ESMTP id 0108F1A8A08 for <secdir@ietf.org>; Thu, 21 Aug 2014 14:14:59 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
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) ([]) 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 <dgellert@silverspringnet.com>
To: "secdir@ietf.org" <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: <D01BA4C5.15153%dgellert@silverspringnet.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
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" <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 <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Aug 2014 21:15:02 -0000

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

This Standards Track draft is a best effort protocol extension to CoAP to enable clients to retrieve a representation of a resource and keep this representation 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 notifications 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 state. This issue could be considered a security threat depending on the sensitivity 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<mailto:dgellert@silverspringnet.com>
O +1 650 839 4378
C +1 650 556-5994
[Description: Description: Description: Description: cid:image001.jpg@01CD8D1D.E8F2D9D0]