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

Randall Gellens <randy@qti.qualcomm.com> Wed, 16 September 2015 02:07 UTC

Return-Path: <randy@qti.qualcomm.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 5E1A71ACD03 for <secdir@ietfa.amsl.com>; Tue, 15 Sep 2015 19:07:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.711
X-Spam-Level:
X-Spam-Status: No, score=-6.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 7R5ml097IdtZ for <secdir@ietfa.amsl.com>; Tue, 15 Sep 2015 19:07:00 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 904FB1AC3D9 for <secdir@ietf.org>; Tue, 15 Sep 2015 19:07:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1442369220; x=1473905220; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version:content-transfer-encoding; bh=5nhDzqSWZrYVklLOGhRonodsDhIe08XMLJolefz7zZc=; b=A4ujBRHaOuhrt9FzyqyHO39meanMl4UyM92QUHum+CVxAF74M+h/9Ox6 QkC1l8hX+CHymZ7oQYIYexWXWSZaC8h+Bhhh5tj5Nu4Nv4vvCAl8tx7vR JmeHeIipfzAoZYMBvhlm5mhqxoLZM+xTb2WPOyNDFLwyHr2oaUWbh5MoS o=;
X-IronPort-AV: E=McAfee;i="5700,7163,7925"; a="97928829"
Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 15 Sep 2015 19:07:00 -0700
X-IronPort-AV: E=Sophos;i="5.17,537,1437462000"; d="scan'208";a="33674514"
Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 15 Sep 2015 19:06:59 -0700
Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 15 Sep 2015 19:06:58 -0700
Message-ID: <p06240612d21e7dc050f6@[99.111.97.136]>
In-Reply-To: <CADajj4a+uJi3h1qjQ9xgGup_2teQc9hgfRyWDwwKvQS5aUJDOg@mail.gmail.com>
References: <CADajj4bzDNqCzaJSjviVZm1nk8CrbUopzj0PrNNOUcK9SNG1ZA@mail.gmail.com> <p06240610d21e68de6c17@99.111.97.136> <CADajj4a+uJi3h1qjQ9xgGup_2teQc9hgfRyWDwwKvQS5aUJDOg@mail.gmail.com>
X-Mailer: Eudora for Mac OS X
Date: Tue, 15 Sep 2015 19:06:49 -0700
To: Magnus Nyström <magnusn@gmail.com>
From: Randall Gellens <randy@qti.qualcomm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (10.85.0.82) To nasanexm02f.na.qualcomm.com (10.85.0.87)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/oyLb1EGsSXcpvSl1FX0BBfGgUCA>
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 02:07:02 -0000

Hi Magnus,

I think we can mandate TLS 1.2 or later without 
any problem, and I can add that to the text that 
mandates HTTPS.  I don't think I can add MTI 
cypher suites at this stage, but I think it would 
be OK to add text such as "it is RECOMMENDED to 
use only suites that offer Perfect Forward 
Secrecy (PFS) and avoid Cipher Block Chaining 
(CBC)", with your list of suites as an example. 
What do you think?  If we go this way, I'd 
probably need to also add an informational 
reference or two; what do you suggest?

At 6:39 PM -0700 9/15/15, Magnus Nyström wrote:

>  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 
> <<mailto:randy@qti.qualcomm.com>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



-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
All we're seeing is the negative side of nuclear war.
    --Barry Goldwater