[secdir] Secdir last call review of draft-ietf-lpwan-ipv6-static-context-hc-21

Joseph Salowey via Datatracker <noreply@ietf.org> Thu, 01 August 2019 04:26 UTC

Return-Path: <noreply@ietf.org>
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 192BD12013E; Wed, 31 Jul 2019 21:26:53 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Joseph Salowey via Datatracker <noreply@ietf.org>
To: <secdir@ietf.org>
Cc: lp-wan@ietf.org, draft-ietf-lpwan-ipv6-static-context-hc.all@ietf.org, iesg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.99.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Joseph Salowey <joe@salowey.net>
Message-ID: <156463361304.5240.7205361618665662244@ietfa.amsl.com>
Date: Wed, 31 Jul 2019 21:26:53 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/p-D9T5Z2nOJ9DHox1nqLCkd2z0A>
Subject: [secdir] Secdir last call review of draft-ietf-lpwan-ipv6-static-context-hc-21
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 01 Aug 2019 04:26:53 -0000

Reviewer: Joseph Salowey
Review result: Ready

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 summary of the review is Ready.  The document has a good discussion of
problems that an attacker can cause with compression and fragmentation.   My
knowledge of LPWAN is limited, so I included two possible additions to the
security considerations if they are relevant to the LPWAN environment.

One area that is not covered in the security considerations but has been a
problem with fragmentation in practice is the use of fragmentation to try to
bypass network packet inspection devices such as firewalls.   I don't know
enough about the deployment environments to know if the fragmented packets
would traverse such a device.

It is not clear to me if the header to be compressed can contain secret
information such as a cookie or authentication token.  If these packets are
going to be encrypted then compression can provide an attacker with a means to
break the confidentiality on certain data in special circumstances.  Examples
of these are BREACH[1] and CRIME attacks.  These require some specific
conditions that may not exist in the use cases for this protocol. In general
some secret information must be present in a packet,  an attacker must be able
to inject arbitrary data into the packet and the attacker must be able to
observe the effect on the encrypted compressed packet-size.  I don't know if
this is a likely scenario in the protocols use cases.  These attacks can be
mitigated by not compressing values that may be secret in the header.

[1] https://en.wikipedia.org/wiki/BREACH
[2] https://en.wikipedia.org/wiki/CRIME