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.
- [secdir] Secdir review of draft-ietf-ecrit-additi… Magnus Nyström
- [secdir] Secdir review of draft-ietf-mpls-tp-oam-… Tina TSOU
- Re: [secdir] Secdir review of draft-ietf-mpls-tp-… Venkatesan Mahalingam
- Re: [secdir] Secdir review of draft-ietf-mpls-tp-… Venkatesan Mahalingam
- Re: [secdir] Secdir review of draft-ietf-mpls-tp-… Tina TSOU
- Re: [secdir] Secdir review of draft-ietf-ecrit-ad… Randall Gellens
- Re: [secdir] Secdir review of draft-ietf-ecrit-ad… Magnus Nyström
- Re: [secdir] Secdir review of draft-ietf-ecrit-ad… Randall Gellens
- Re: [secdir] Secdir review of draft-ietf-ecrit-ad… Magnus Nyström
- Re: [secdir] Secdir review of draft-ietf-ecrit-ad… Randall Gellens
- Re: [secdir] Secdir review of draft-ietf-ecrit-ad… stephen.farrell
- Re: [secdir] Secdir review of draft-ietf-ecrit-ad… Hannes Tschofenig
- Re: [secdir] Secdir review of draft-ietf-ecrit-ad… Randall Gellens
- Re: [secdir] Secdir review of draft-ietf-ecrit-ad… Magnus Nyström
- Re: [secdir] Secdir review of draft-ietf-ecrit-ad… Randall Gellens
- Re: [secdir] Secdir review of draft-ietf-ecrit-ad… Magnus Nyström
- Re: [secdir] Secdir review of draft-ietf-ecrit-ad… Randall Gellens
- Re: [secdir] Secdir review of draft-ietf-ecrit-ad… Magnus Nyström
- Re: [secdir] Secdir review of draft-ietf-ecrit-ad… Brian Rosen
- Re: [secdir] Secdir review of draft-ietf-ecrit-ad… Randall Gellens
- Re: [secdir] Secdir review of draft-ietf-ecrit-ad… Brian Rosen