Re: [secdir] Secdir review of draft-ietf-ecrit-data-only-ea-18

Brian Rosen <br@brianrosen.net> Mon, 26 August 2019 20:34 UTC

Return-Path: <br@brianrosen.net>
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 48757120CF0 for <secdir@ietfa.amsl.com>; Mon, 26 Aug 2019 13:34:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.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 sUlob0Bwy6bu for <secdir@ietfa.amsl.com>; Mon, 26 Aug 2019 13:34:52 -0700 (PDT)
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 BE9C012004D for <secdir@ietf.org>; Mon, 26 Aug 2019 13:34:51 -0700 (PDT)
Received: by mail-qk1-x734.google.com with SMTP id f10so683539qkg.7 for <secdir@ietf.org>; Mon, 26 Aug 2019 13:34:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=G9QH4iFldqe77/C4KQH64rjdHhzNbEj0ujVfUaz9gzw=; b=17hBjENo7PYczx13zt0V5ulCr+xGZUsAGG8bg7+IjMR8rJllKIi5R7fZsObmIRxYc3 v0z5GoKVjt4LcBzCm+6zAjyWG/4/Yi9LO36CAH86W6B/mk1EpMIIiNMCfik9UgPgP1AU EFPfjeWrWkhET4cZ0r+FMzyb8IxUdn3fcWBwFu1I9jID7oHOXA2fQLyipGZ45bNmdQdq 6xbJaKjsTyIkNuTna97SmuzHsTzvptVpCjTO4aU5wsm20V21g57iVX6wX8/tGpDAGaIZ nYMMkXDCDFQm7FyMN+bfddEa9c9qH094221I8K9scEpHoyD9JPbzW3GVQl0vU4j7T3Yc htfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=G9QH4iFldqe77/C4KQH64rjdHhzNbEj0ujVfUaz9gzw=; b=TrpC790x5mRSgzcjEFgInCtpkNf9Qp7U15LXell/BtI7tA6JnAAnfkfuH7WHMxCpsW 9nOszcnFPP+3fdlCqpLOen7qVT0fOkZMv3fttC2dTETSgFOsL7Ve8v6x55q3P5007c92 mCWGoZ5LCsfo7RKjvbingJKL0HJlPJcwkNdoBnD2wScdkzP1Dv7WeEOCpuRkifxeedkm ekKwQXAmxVbFmY0jFlfoKv9easg+Vk7t0ISDFXPqtUMOzowsuFDsPwryPa2GHeDofW1X JUtMk37r6D9XHQian9cidJrFwfamY6gH0clKcKVkurgPOFnVqnDNedGTQcj3RiENpPYi 0Jxg==
X-Gm-Message-State: APjAAAVCHgdzI7jNvDzAPp3Iab1jB+wag3Xubem3WNqo0ylDLsi446Je S2RbfTqulpAYnc6BDDvs1lG8DA==
X-Google-Smtp-Source: APXvYqzTM0YWioaYz2Mywh/36dhPpaCCb+B38WXTTm0CkXJ/NgcVK2G+FXRvpG3sNnKBWwMzlIPyiQ==
X-Received: by 2002:a37:9b48:: with SMTP id d69mr18733327qke.449.1566851690724; Mon, 26 Aug 2019 13:34:50 -0700 (PDT)
Received: from brians-mbp-2369.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id 145sm7134511qkm.1.2019.08.26.13.34.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Aug 2019 13:34:50 -0700 (PDT)
From: Brian Rosen <br@brianrosen.net>
Message-Id: <DAD38B77-66B6-40CD-9200-DDA7632EED94@brianrosen.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_26D64576-1C1A-4C42-AB7C-6D56AFA05284"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 26 Aug 2019 16:34:49 -0400
In-Reply-To: <MWHPR04MB0367DA96CF172D996CDDA622DFA70@MWHPR04MB0367.namprd04.prod.outlook.com>
Cc: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-ecrit-data-only-ea.all@ietf.org" <draft-ietf-ecrit-data-only-ea.all@ietf.org>
To: Charlie Kaufman <charliekaufman@outlook.com>
References: <MWHPR04MB0367DA96CF172D996CDDA622DFA70@MWHPR04MB0367.namprd04.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/iJ8tWR8-Gad5_gbleN_zxbrVdEo>
Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-data-only-ea-18
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: Mon, 26 Aug 2019 20:34:54 -0000

Hi Charlie

Thanks for the review, I appreciate it.

The introduction section has this text
   Data-only emergency calls are similar to regular emergency calls in
   the sense that they require the emergency indications, emergency call
   routing functionality and may even have the same location
   requirements.  However, the communication interaction will not lead
   to the exchange of interactive media, that is, Real-Time Protocol
   packets, such as voice, video data or real-time text.

   ...

   This document describes a method of including a CAP message in a SIP
   transaction by defining it as a block of "additional data" as defined
   in [RFC7852 <https://tools.ietf.org/html/rfc7852>].  The CAP message is included either by value (the CAP
   message is in the body of the message, using a CID) or by reference
   (a URI is included in the message, which when dereferenced returns
   the CAP message).  The additional data mechanism is also used to send
   alert specific data beyond that available in the CAP message.  This
   document also describes how a SIP MESSAGE [RFC3428 <https://tools.ietf.org/html/rfc3428>] transaction can
   be used to send a data-only call.


This says that this document describes how to send an emergency call when there is not two way interactive media (voice, video and/or text), and it says that the way you do that is to send a SIP MESSAGE, with a CAP message pointed to by a Call-Info header.

That text seems very clear to me, and yet you didn’t read what we hoped into what we wrote.  I would really like to fix this, but I’m at a loss to understand what I need to do.

I’ll improve the acronym stuff.


> On Aug 24, 2019, at 3:53 PM, Charlie Kaufman <charliekaufman@outlook.com>; wrote:
> 
> 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 document defines a new MIME type: 'application/EmergencyCallData.cap+xml' for use primarily by sensors to send alert messages to emergency services providers. It also defines a new Emergency Call Data Type: 'cap' in order to embed this data efficiently in a SIP transaction. I saw no new security issues beyond those already noted for the protocols carrying these messages.
> 
> I do have some editorial suggestions:
> 
> There is a lot of context that the authors assumed any reader would have that could have been stated in the introduction. I believe from context that the purpose of this new MIME type is to support simple (IoT) sensors that don't want to implement a more heavyweight protocol, but I don't believe that was stated anywhere.
> 
> I got the impression that the functionality provided could have been done with existing protocols by sending the CAP message over a SIP session, but that doing so would place an unnecessary burden on simple (IoT) sensors, and that this protocol would be easier for such sensors to implement for the limited cases such sensors need to deal with. If that's true, it should be stated. If not, the purpose of this protocol should be more clearly stated.
> 
> These acronyms were used but never defined:
> 
> SIP
> CID
> LoST
> 
> These acronyms were expanded, but not in an easy to find place:
> 
> Common Alerting Protocol (CAP)
> Public Safety Answering Points (PSAPs)
> Emergency Services Routing Proxy (ESRP)
> 
> It would be nice to include them in the terminology section, ideally with a reference to the RFC where more information is available.
> 
> Typo:
> 
> p17 "security mechanism" -> "security mechanisms"
> 
>  --Charlie