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

Randall Gellens <randy@qti.qualcomm.com> Wed, 16 September 2015 04:21 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 18C001B33AD for <secdir@ietfa.amsl.com>; Tue, 15 Sep 2015 21:21:20 -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 eYC3aFgShDGB for <secdir@ietfa.amsl.com>; Tue, 15 Sep 2015 21:21:18 -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 380761B33AA for <secdir@ietf.org>; Tue, 15 Sep 2015 21:21:18 -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=1442377278; x=1473913278; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version:content-transfer-encoding; bh=vtbIpv0pP5RbIABRpiXY5HEGJtjnz0/jx6MHDaYbPPE=; b=uxh57WN7t6J5my0Qgxl/Gmi7zjlxZZz1dv5vUhzia2+w4cCfkkBbwpAm owoUtA6h7H78gwg28wr7l+nMBPJWauqPty9lLqUlTzAIBmJZPUr9fsyxw aFkKsnI7uIKICA5FKZeYB7VeehFhjttBN/69TyEn/mHNDa4x8FbHHpTFD Y=;
X-IronPort-AV: E=McAfee;i="5700,7163,7925"; a="97936575"
Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Sep 2015 21:21:17 -0700
X-IronPort-AV: E=Sophos;i="5.17,537,1437462000"; d="scan'208";a="1002528923"
Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 15 Sep 2015 21:21:17 -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 21:21:16 -0700
Message-ID: <p06240613d21e9ea0057c@[99.111.97.136]>
In-Reply-To: <CADajj4ZGx-8vFrZXd_CQcuG3GJWYDJoFTBQ+do-duicgadkEYw@mail.gmail.com>
References: <CADajj4bzDNqCzaJSjviVZm1nk8CrbUopzj0PrNNOUcK9SNG1ZA@mail.gmail.com> <p06240610d21e68de6c17@99.111.97.136> <CADajj4a+uJi3h1qjQ9xgGup_2teQc9hgfRyWDwwKvQS5aUJDOg@mail.gmail.com> <p06240612d21e7dc050f6@99.111.97.136> <CADajj4ZGx-8vFrZXd_CQcuG3GJWYDJoFTBQ+do-duicgadkEYw@mail.gmail.com>
X-Mailer: Eudora for Mac OS X
Date: Tue, 15 Sep 2015 21:21:14 -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: NASANEXM01C.na.qualcomm.com (10.85.0.83) To nasanexm02f.na.qualcomm.com (10.85.0.87)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/dL3-Lhgry-VK-ctU0VYtfDGWqUA>
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 04:21:20 -0000

I've made these changes and included the two references.  Thanks very much.

At 8:09 PM -0700 9/15/15, Magnus Nyström wrote:

>  Yes, at least mandating TLS 1.2 or higher and recommending as per above
>  seems reasonable.
>  The references for the GCM suites would be RFC 5288 and RFC 5289.
>
>  Thanks!
>
>  On Tue, Sep 15, 2015 at 7:06 PM, Randall Gellens <randy@qti.qualcomm.com>
>  wrote:
>
>>  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



-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
This fortune intentionally not included.