[secdir] Secdir review of draft-ietf-ecrit-additional-data

Magnus Nyström <magnusn@gmail.com> Tue, 01 September 2015 04:27 UTC

Return-Path: <magnusn@gmail.com>
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 49C4C1B7D71 for <secdir@ietfa.amsl.com>; Mon, 31 Aug 2015 21:27:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 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, MIME_8BIT_HEADER=0.3, 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 HmPlKzL6slAe for <secdir@ietfa.amsl.com>; Mon, 31 Aug 2015 21:27:00 -0700 (PDT)
Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (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 855091B7D6D for <secdir@ietf.org>; Mon, 31 Aug 2015 21:26:59 -0700 (PDT)
Received: by wicjd9 with SMTP id jd9so18992190wic.1 for <secdir@ietf.org>; Mon, 31 Aug 2015 21:26:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=6B4V3vm6aU67QIAWWBsiT9cmknypZCn00n3caGtCWfw=; b=O9C/2UzYcs1oXFnMIIhy88DyoMvf1lJCtbBX0nQubU+lIztCwDp9uBshxb7ZaQbGr4 Kez093XZtFrkKy+RXhHx2oP9RaVRbA2Wxwkz9+Djd2/VdedSbE+8tVphei6raGeXxu4x 4QFKmsCMiJX+8tszKXGUva4kOxiV9adUSCGcZ4G8lrTOkg0Vme/FAxBjxs2eChiE1mD2 AnJvuIBaqB+Ca8y1naW3qGnb4ey/0ftQaNzqu0y7GiPc5nGSFFtSmmjfWk+4AA1Hk/yT QBqrs8WMxgeHKt95yg1dVftiWIdCwXyAiQiaikUC1hIZ6RbTeSTtLuwzRxQNHIBtWEys C32w==
MIME-Version: 1.0
X-Received: by 10.180.23.162 with SMTP id n2mr830402wif.8.1441081618052; Mon, 31 Aug 2015 21:26:58 -0700 (PDT)
Received: by 10.27.130.200 with HTTP; Mon, 31 Aug 2015 21:26:58 -0700 (PDT)
Date: Mon, 31 Aug 2015 21:26:58 -0700
Message-ID: <CADajj4bzDNqCzaJSjviVZm1nk8CrbUopzj0PrNNOUcK9SNG1ZA@mail.gmail.com>
From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= <magnusn@gmail.com>
To: "secdir@ietf.org" <secdir@ietf.org>, draft-ietf-ecrit-additional-data@tools.ietf.org
Content-Type: multipart/alternative; boundary=e89a8f838a97efbcb9051ea7f56f
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/v4YMFZzo8NovJG3jqj-telumYRY>
Subject: [secdir] Secdir review of draft-ietf-ecrit-additional-data
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: <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, 01 Sep 2015 04:27:01 -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 memo provides fundamental data structure definitions and procedural
rules for providing auxiliary information to public service answering
points (PSAPs) when emergency calls are being made.

This reads as an important memo and has been at least five years in the
making. I don't find the Security (and Privacy) Considerations section
lacking per se, but do have these questions:

- Why require HTTPS for the reference case but not the value case (I can
understand why you don't require it for the value case, but couldn't it be
a choice for the PSAP also in the reference case? This would also seem to
simplify during an introductory phase when a wide-spread PKI solution is
not yet in place.)?
- When HTTPS is required, I assume the PSAP needs a client certificate -
i.e., that the mutual auth option of TLS is being used, perhaps this needs
to be clarified?
- Was there any discussion around any MTI TLS cipher suites?
- I assume there's not only a privacy issue but also a potential spoofing
issue - the PSAPs don't want to be overly susceptible to spoofed calls
(although they rather err on the side of safety, of course. Thus, should
integrity of infomation in the direct case be considered? I.e., by n/w or
service providers in the path to the PSAP vouching for the information?

Thanks,
-- Magnus