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

Hannes Tschofenig <Hannes.Tschofenig@arm.com> Wed, 16 September 2015 10:55 UTC

Return-Path: <hannes.tschofenig@arm.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 8ABB31A6F9F for <secdir@ietfa.amsl.com>; Wed, 16 Sep 2015 03:55:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 wj3olpQA28-z for <secdir@ietfa.amsl.com>; Wed, 16 Sep 2015 03:55:54 -0700 (PDT)
Received: from eu-smtp-delivery-143.mimecast.com (eu-smtp-delivery-143.mimecast.com [207.82.80.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3B771A6F84 for <secdir@ietf.org>; Wed, 16 Sep 2015 03:55:48 -0700 (PDT)
Received: from emea-cam-gw2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-10-3MAizUhoQ02o6SqVZiDbSA-2; Wed, 16 Sep 2015 11:55:46 +0100
Received: from EMEA-CAM-GW3.Emea.Arm.com (10.1.106.86) by emea-cam-gw2.Emea.Arm.com (10.1.105.150) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 16 Sep 2015 11:55:40 +0100
Received: from george.Emea.Arm.com ([fe80::6ccb:73b1:f5c3:796]) by EMEA-CAM-GW3.Emea.Arm.com ([::1]) with mapi; Wed, 16 Sep 2015 11:55:40 +0100
From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
To: "stephen.farrell@cs.tcd.ie" <stephen.farrell@cs.tcd.ie>, "magnusn@gmail.com" <magnusn@gmail.com>
Date: Wed, 16 Sep 2015 11:55:41 +0100
Thread-Topic: [secdir] Secdir review of draft-ietf-ecrit-additional-data
Thread-Index: AdDwUqnlHP38AwnPTnKalfOVbYlGWAAG4svA
Message-ID: <F01D8B85CFF58440B2A13965FBA90CA401546255F7D5@GEORGE.Emea.Arm.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> <2do7j0.nurejh.2vaeqo-qmf@mercury.scss.tcd.ie>
In-Reply-To: <2do7j0.nurejh.2vaeqo-qmf@mercury.scss.tcd.ie>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-GB
MIME-Version: 1.0
X-MC-Unique: 3MAizUhoQ02o6SqVZiDbSA-2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/8IDhaHquljC8XFUO4mZniWvkNYw>
Cc: "randy@qti.qualcomm.com" <randy@qti.qualcomm.com>, "draft-ietf-ecrit-additional-data@tools.ietf.org" <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 10:55:57 -0000

I think BCP195 does the job for us.

-----Original Message-----
From: secdir [mailto:secdir-bounces@ietf.org] On Behalf Of stephen.farrell@cs.tcd.ie
Sent: 16 September 2015 09:38
To: magnusn@gmail.com
Cc: randy@qti.qualcomm.com; draft-ietf-ecrit-additional-data@tools.ietf.org; secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data



On Wed Sep 16 04:09:03 2015 GMT+0100, 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.

BCP195 has recent recommendations for most TLS options. I'd say it'd be best to use those or if not figure out why they're not correct for this context.

S.


>
> 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.
> >>
> >>   - 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
> >
>
>
>
> --
> -- Magnus
>
_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782