[secdir] Secdir review of draft-ietf-lpwan-coap-static-content-hc-13

Charlie Kaufman <charliekaufman@outlook.com> Fri, 13 March 2020 06:10 UTC

Return-Path: <charliekaufman@outlook.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349893A1171; Thu, 12 Mar 2020 23:10:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com
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 AWBDOKelQcSC; Thu, 12 Mar 2020 23:10:32 -0700 (PDT)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-oln040092004072.outbound.protection.outlook.com [40.92.4.72]) (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 448E53A116E; Thu, 12 Mar 2020 23:10:32 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RJRJDUju9Vg8k16xc3cyyXC1z2brO+zntrPD/JUyM5U3yZwalzEa2+0FrF3GVp39JOgnZy+y8vlX/MXgkR31Ljt1Q2wAI2ceGf2Kfm+G9D5f2OGu6yTzrHa/epD5r4Egz7HWHqeZgYgA7hHjGNlxq00zUrgiqsyqlURaKABCGrEGYBBv3uFAqHuY4SiZLhwI0qf1XsMKIsuu8i0jAexq+VhSEpxpnjiNcgVgp1u6zytFfs9HrlOMS9+KH5Kdsd/QFsZ++Th3oyHqJXzRvyusYquvmebW252KBYs/P9JA/dK+bGswCoa3FtO7watDnsVEHA3T4URwoB7859iPBuyCdQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;bh=v80Sb5utK6cdiDHAGrWccBu9TCZAs75L4/lm3it+mng=; b=oCzoien8qPFk42OEXLznEcaNdtQCiu7dw0cstQVVRqP3qCXNmeqxOSEmWzK+lKd3l5vjMUqonhPBUF5CoG08EFiojt93nUvyxIgwEc6Gzwuq8RKSXGSLzaIG47RcvozxNNMblMe69lDIYRHUhWCb7jf88i9HIpk+7vUuypAPhXIJdpqka58CiAWMEYhZ4DHfrTeoMi8J+Pdtn5ZvEOfCEMGWCOPhOpcc480d/G8G2hrzfy9Ieo+W9H1fR6q37jfSoGJuwPCqJJpKOvU20aBl/1h9eVuLyuDGgWZkx1B7+4NI0nQ++uDJvpAJH2J9EvvOF8stEKG6J6FXukC+hLIsAw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;bh=v80Sb5utK6cdiDHAGrWccBu9TCZAs75L4/lm3it+mng=; b=k+VmI90Xm3U6xS3g9L9Ka8DycDMu1KQfbO9cTWVj2ySDvyHvgsdMDe7uHv7orHWqpr4O9hRm6HJv0SinLhaIBnwl44D3df05a37XXfvJKbN7AWAAs59trukBjwGFy8AXjz0QnLUuqHLiN6AllxE/Fo04lGuhdSurUOExmd7B7xhMFE85ilY+8B5x3hK8r/leNWKrycOk3GIyr2F45rbOAsAXNEhHIpQ8yucN+FeJOHVOFmgB+d12jXVWNh6Kiq3P6qb196ktCCywLoM1lShdTOq+XL+NhQopizYAlnz8k8r1fQz0OFMviiC7J4zhQCyCewx5oEi05YRnKrrXZAJy2w==
Received: from BL2NAM02FT005.eop-nam02.prod.protection.outlook.com (10.152.76.51) by BL2NAM02HT020.eop-nam02.prod.protection.outlook.com (10.152.77.54) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.13; Fri, 13 Mar 2020 06:10:31 +0000
Received: from MWHPR07MB3022.namprd07.prod.outlook.com (10.152.76.56) by BL2NAM02FT005.mail.protection.outlook.com (10.152.76.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.13 via Frontend Transport; Fri, 13 Mar 2020 06:10:31 +0000
Received: from MWHPR07MB3022.namprd07.prod.outlook.com ([fe80::b8aa:d51:1c05:e5c2]) by MWHPR07MB3022.namprd07.prod.outlook.com ([fe80::b8aa:d51:1c05:e5c2%10]) with mapi id 15.20.2793.018; Fri, 13 Mar 2020 06:10:31 +0000
From: Charlie Kaufman <charliekaufman@outlook.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-lpwan-coap-static-content-hc.all@ietf.org" <draft-ietf-lpwan-coap-static-content-hc.all@ietf.org>
Thread-Topic: Secdir review of draft-ietf-lpwan-coap-static-content-hc-13
Thread-Index: AQHV+P3rKcTCZ1P5vEmbTfI320LRuA==
Date: Fri, 13 Mar 2020 06:10:31 +0000
Message-ID: <MWHPR07MB30229CA068BE628C515653DFDFFA0@MWHPR07MB3022.namprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: OriginalChecksum:88410AB0D7EF56E90FBC6BCE823130E2B5792CBEEBBE88EB8EFC4CFA35F800AF; UpperCasedChecksum:535724E2F0CED84D01F733E92319B97AFB94EE5DFAFBA708004AEFF1484C2C48; SizeAsReceived:7031; Count:42
x-tmn: [AhQQU/UO2kUbRL2qvMfqASCQodPkmfXr9psnW2JN3fqOUyot5aLvQClCYb5aWapT]
x-ms-publictraffictype: Email
x-incomingheadercount: 42
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 9ef06c18-0f0a-4ea6-eeb6-08d7c7153c17
x-ms-traffictypediagnostic: BL2NAM02HT020:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: VeUkWrnWACG2QixhADaMoegj23HneU0D8qGqvxczGsGpp6MW92Qqr5LXHJ3aMyhAXTUgyYSXGZ7pwqpgFM/WMzDhUYn/Sx+0481whp0XaQ67yLixtDtoI1IUR9Gz8ofzSmfieWk1kbkOeyryzjnoPu1DWWwMhGFES+PznPruKSW64YDfKwBU/MR+w0VeHC7l9k16tZC540FX1rU5v9lnsLV9tHYz/RtT5BTAOLHG6es=
x-ms-exchange-antispam-messagedata: +xqATIx/smoxHgbVaaO5aMWYU5ga5JNRIYo1d5df/wX1QkfIQ62YoM9pPeUnRMMlKdLWr0doaYyriifhxw+Xfi5HiwnLzJDMXfG8VH/1rAmfvBnTq9qxv2u6vWtr9SwnPTGwZyw9wovluDMxtinu5R9cI0iCPDEMi/l+suEege1MYiV9pKq4BgHrUTCvT8WwMPS5EeBeitNnqOkhtblRyw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MWHPR07MB30229CA068BE628C515653DFDFFA0MWHPR07MB3022namp_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 9ef06c18-0f0a-4ea6-eeb6-08d7c7153c17
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2020 06:10:31.2196 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2NAM02HT020
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/WTSy7ms73-W16bFJ4-aqFOrqXjE>
Subject: [secdir] Secdir review of draft-ietf-lpwan-coap-static-content-hc-13
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
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: <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: Fri, 13 Mar 2020 06:10:34 -0000

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

This draft defines how SCHC (Static Context Header Compression) should be applied to the CoAP (Constrained Application Protocol). It appears that this is designed for low end devices speaking standard protocols with a lot of static content they would like to suppress to avoid wasting processing time and communications overhead. That means that these devices are likely to be generating and parsing the compressed content directly rather than generating the full content and then compressing it. The only security considerations worth noting is that whenever compression is used with a protocol intended to be encrypted (which this one is), the question should be raised as to whether the compression can be leveraged by an attacker to make traffic analysis more effective. In this case, I don't believe it can, but there should probably be an explanation of why in the security considerations.

With a compression scheme like Lempel Ziv, the value of some field potentially supplied by an attacker can affect the compression of some other field potentially containing a secret. This allows traffic analysis looking at the lengths of messages containing content supplied by an adversary to reveal secrets. On the other hand, with a compression scheme like Huffman coding, fields are compressed independently. This scheme appears to be more like Huffman; the compression rules are not dynamically adjusted based on variable content. If anything, the compression here seems likely to make traffic analysis more difficult by making messages shorter such that the lengths are masked by padding.

Nits:

The acronym CoAP appears 181 times in this document but is never defined/expanded except in the references. It probably should be either on first use or in terminology.

The capitalization of certain keywords (e.g., Rule, Residue, Plaintext, Outer, Header) seems inconsistent. If whether the word is capitalized is intended to convey some meaning to the reader, that should probably be mentioned somewhere, and in any case the usage should be consistent.

"to performs the" -> "to perform the"
"might be use" -> "might be used"
"knwoledge" -> "knowledge"
"to appears" -> "to appear"
"length send" -> "length sent"
"bits on the SCHC packet" -> "bits in the SCHC packet"

"This document does not have any more Security consideration than the ones already raised on..."
->"This document does not have any security considerations beyond those raised in..."

...except that the security considerations goes on to raise some issues. So unless those are duplicating ones mentioned in the referenced document, the introductory phrase should probably be "These security considerations are in addition to those raised in ...".

 --Charlie



Sent from Outlook<http://aka.ms/weboutlook>