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

Magnus Nyström <magnusn@gmail.com> Wed, 16 September 2015 01:39 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 C69501B2FC1 for <secdir@ietfa.amsl.com>; Tue, 15 Sep 2015 18:39:56 -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 XqXyaQkyvLfM for <secdir@ietfa.amsl.com>; Tue, 15 Sep 2015 18:39:55 -0700 (PDT)
Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (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 73B0C1B2F08 for <secdir@ietf.org>; Tue, 15 Sep 2015 18:39:54 -0700 (PDT)
Received: by wicfx3 with SMTP id fx3so51949556wic.1 for <secdir@ietf.org>; Tue, 15 Sep 2015 18:39:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GJHVE5cVBOTcBIIQLxmXjZ3myzItkUuMsozvQgV8/xM=; b=KuQLnkoMR+1yFqJ3HJAGnOJwqsPJBIAW5EXLw1ulATzfvbIc1xqsBgfq48ycjVX2dY yAwzZhV1UGpenCaMZT9QWZJccOQUEDHbu4fazTEbAWWEUWptW0G/LiAS21UZaZtHZqmU kC6S7vvY4KU2dov1NRxSHRIgumxalWqF/ZniL1s6/iDy/RtM33RqhKea+EPCeU+AcUUT syWn89o1waf4yqAMN1LWfp0Q6neYBYLMU0ta6QYB5SVqLXq0pG6ZcfDuKlhv7Ar8XVp8 ZKwLBFHdwPLrN3p+syscs2BMvo8Ju1dT5UcNyxs/Idmey4MculUNZpSCPBaHWtzFO7l8 82SQ==
MIME-Version: 1.0
X-Received: by 10.180.23.162 with SMTP id n2mr13031210wif.8.1442367593071; Tue, 15 Sep 2015 18:39:53 -0700 (PDT)
Received: by 10.27.130.200 with HTTP; Tue, 15 Sep 2015 18:39:53 -0700 (PDT)
In-Reply-To: <p06240610d21e68de6c17@99.111.97.136>
References: <CADajj4bzDNqCzaJSjviVZm1nk8CrbUopzj0PrNNOUcK9SNG1ZA@mail.gmail.com> <p06240610d21e68de6c17@99.111.97.136>
Date: Tue, 15 Sep 2015 18:39:53 -0700
Message-ID: <CADajj4a+uJi3h1qjQ9xgGup_2teQc9hgfRyWDwwKvQS5aUJDOg@mail.gmail.com>
From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= <magnusn@gmail.com>
To: Randall Gellens <randy@qti.qualcomm.com>
Content-Type: multipart/alternative; boundary=e89a8f838a9705485f051fd36086
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/CjvCTlpRJcc11N63M_k6fB2o76g>
Cc: draft-ietf-ecrit-additional-data@tools.ietf.org, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [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: Wed, 16 Sep 2015 01:39:56 -0000

Hi Randall,
Yes, I guess it may be surprising ... but I was thinking more about getting
this effort implemented in an expedited fashion rather than potentially
delaying due to the potential issues (also pointed out in the draft) around
getting the necessary trust anchors in place between PSAPs and service
providers enabling the mutual authentication.

It may be good to say something about MTI suites - I would suggest
mandating support for a set of suites that offers PFS and avoids CBC, e.g.,
something like:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

I would also suggest mandating TLS 1.2 (or later) for a new application
like this.
On the last point, yes, if the service provider is in a possession to vouch
for or sanity-check then that could help introduce reliability.

Best,


On Tue, Sep 15, 2015 at 5:58 PM, Randall Gellens <randy@qti.qualcomm.com>
wrote:

> Hi Magnus,
>
> Thank you for your review and comments.  Please see in-line.
>
> At 9:26 PM -0700 8/31/15, Magnus Nyström 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 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.)?
>>
>
> I'm very surprised that a security area person is asking why we don't make
> TLS optional!  It's a valid question, of course, just surprising in this
> context.  Because of the limited scope of the document, specifically
> emergency services, and given that the dereferencing entities will be PSAPs
> and other responders that have upgraded to support next-generation, we felt
> that it was reasonable to require the use of TLS and client-side
> certificates for dereferencing.
>
>  - 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?
>>
>
> Yes, good point.  I added clarifying text in response to Ben's comments.
>
>  - Was there any discussion around any MTI TLS cipher suites?
>>
>
> No, this was never discussed as far as I can recall.
>
>  - 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?
>>
>
> You're absolutely correct that PSAPs are concerned about spoofed (and
> other false) calls but will generally err by taking a call and asking the
> caller for information.  In general, PSAPs prefer information that comes
> from known and trusted providers (the major carriers).  Are you suggesting
> a mechanism by which providers verify the information provided by the
> device? For location information, there are discussions in other SDOs about
> sanity-checking device-provided information (location or Wi-Fi APs) against
> network-known information (macro cell to which the device is associated).
>
> --
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself only
> -------------- Randomly selected tag: ---------------
> In a sense, when we started Virgin Atlantic, I was trying to create
> an airline for myself. If you try to build the perfect airline for
> yourself, it will be appreciated by others. --Richard Branson, 1996.
>



-- 
-- Magnus