[secdir] SecDir Review of draft-weis-gdoi-iec62351-9-08

Yoav Nir <ynir.ietf@gmail.com> Tue, 04 October 2016 16:38 UTC

Return-Path: <ynir.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E1AA01295A1; Tue, 4 Oct 2016 09:38:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id v8TBgGqfewyC; Tue, 4 Oct 2016 09:38:39 -0700 (PDT)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03104120726; Tue, 4 Oct 2016 09:38:38 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id b201so155731100wmb.0; Tue, 04 Oct 2016 09:38:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=9uQFlQ9Ft7eakfMhyJfTdqghw+wFlyJXUOJr6EnGWow=; b=WoLnc1/ChJL0RQt7Eo87ytVd6sdf6yopbWymDELCsx6yCFDV1ZHCKrVLOKKHOoxlEY hHKdloX/XeUaOCkXd1fI6HAt+1hWUW0MDFCuh7itEp7nD1PbIKfUrt3Vyn8RoULMhPWy 1wdgDfr3jlRUJqpOanhx0m5p2U2PjyYE66KRjTsyO/kipjzdA/d+o8TNqCYtWs1gXwPI 6jFNkIAcyhRbTpytWyqqgmJHtca2iIMJazqEttQm4HkJqz2NReU5+Cb9rHb1s8gZdg6X lGz0QE9iLmmMGuMUN7Fn4AYxBlWWZzvQzPJlZ3l9cXlO6mgXHQmFQlpQJFrkLTuJ1HgV gunA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=9uQFlQ9Ft7eakfMhyJfTdqghw+wFlyJXUOJr6EnGWow=; b=CcuU1Y5z1bpixmRImXxtMoLRLhMdI9ulR4cVgiJEnSEjknSnQNw9I14fhFiK+J2Ppf KBNJpcj74CEj8a+xxhIjk3+91bXG4/dbNNxkFhC7/LUH/CNl9ITZMSmM8vHI6pLEYK48 1HCLTi35mSUC4uxqSmn6ZIUaff2WyAS6+HJSaBg/SMBWBi6edQMxl5youBvXu1XSJ2XA NwikeIcssAaxBh0kME3EqyEjqBsmPEOQuscPUibUbxcg9l0Get0n13I/XHH27w1X3Z+C /zmNOMnSv++dI9hRrvekhe/dxm5lK7bzCAIFMcrlNTcKYKCQXMdaUZROOdnctsdYvmY5 omAA==
X-Gm-Message-State: AA6/9RlUrP8zz6DhngomW2plMOmWmL4aJKyso6Zq3zcIJMmhbbuhxQ7KccKRYb/C1UM9/A==
X-Received: by with SMTP id f3mr3840830wjw.2.1475599117468; Tue, 04 Oct 2016 09:38:37 -0700 (PDT)
Received: from [] ([]) by smtp.gmail.com with ESMTPSA id w71sm4906718wmw.17.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Oct 2016 09:38:36 -0700 (PDT)
From: Yoav Nir <ynir.ietf@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\))
Message-Id: <834C9D97-98D2-49EB-BD34-5C28C84AB10F@gmail.com>
Date: Tue, 04 Oct 2016 19:38:33 +0300
To: draft-weis-gdoi-iec62351-9.all@tools.ietf.org, secdir <secdir@ietf.org>, The IESG <iesg@ietf.org>
X-Mailer: Apple Mail (2.3226)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/TdYtPuypiMKEVOCsWLZFThWbqGw>
Subject: [secdir] SecDir Review of draft-weis-gdoi-iec62351-9-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 04 Oct 2016 16:38:41 -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.

Summary: Ready with a question

The draft describes using GDOI with some extensions to transport keying material for the IEC 61850 power utility automation family of standards.

I have previously reviewed version -02 of the draft three years ago ([1]). Later versions addressed my issues about the document being too opaque for people not versed in IEC protocols and terminology. It is still rather hard to read without the relevant background, but that is to be expected in a document targeted at a very specific audience (which I am not part of).

The Security Considerations section points to the section in RFC 6407 (GDOI). Additional paragraphs point out that message authentication is mandatory, while confidentiality is optional.  And yet the same paragraph makes confidentiality a SHOULD if the packets are expected to traverse the public Internet. The last sentence says that 128-bit AES-CBC is good enough for the foreseeable future, "but some security policies may require the use of AES-CBC-256.” There is no mention of why such policies may require this. The usual reason is to protect against future attacks by quantum computers, but I think it’s fine to leave that out.

My question is about the IEC-61850 SA TEK Payload described in Figure 4 in section 2.2. It has separate fields for Auth Alg and Enc Alg. The Enc Alg field has 4 possible values described in section 2.2.3, including AES-GCM-128 and AES-GCM-256. AES-GCM is an AEAD algorithm. As such it should not be used in conjunction with a MAC algorithm. Other protocols either omit the MAC algorithm when an AEAD is used, or create a special ‘none’ value for such cases. Here there are no None value (though there are two Reserved values in the IANA considerations section). This makes it possible to have SA TEK payloads with AES-GCM-128 and HMAC-SHA256-128.  How do you even do that? And why?


[1] https://mailarchive.ietf.org/arch/msg/secdir/-C5_XjfTk42DO013DkbA6q0tQmA