Re: [TLS] network-based security solution use cases

"Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com> Tue, 07 November 2017 23:54 UTC

Return-Path: <ncamwing@cisco.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74DE3127AD4 for <tls@ietfa.amsl.com>; Tue, 7 Nov 2017 15:54:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level:
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 Tzpei2McGK2V for <tls@ietfa.amsl.com>; Tue, 7 Nov 2017 15:53:58 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46BF912944C for <tls@ietf.org>; Tue, 7 Nov 2017 15:53:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4452; q=dns/txt; s=iport; t=1510098838; x=1511308438; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=bNqwKpiI93sVPfDne/+OfO5FpPt2RbBZSgT/icwGpKc=; b=ZOGGab8fykLFH4WNsAEmcbV93khRv0BmLBN8eC0GKwsbN70NR2YVhmrb a8Iyd46YUO1HCzB8cz+2brmn/172FewuOi8WaCtOUoCNCs26e349vvR39 gMV+XotDQBM6rE4Ea+qB+Fb1/DU92WEajGB6FdRNOIOGlM2+SmAOJzpLj c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CRAQDvRgJa/4cNJK1dGQEBAQEBAQEBAQEBAQcBAQEBAYM0ZG4nB4N2m0GWSYIRCh6FHQIahF1AFwEBAQEBAQEBAWsohR4BAQEBAQEBIxFFEAIBCBgCAiYCAgIwFRACBAENBRuKAAgQqSqCJ4sZAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYEPgiGCB4M9KYMBg0KBHzQXgn4xgjIFohYCh2SNF4IVhgSEBIcbjGeJDAIRGQGBOAEhAzOBcXoVH1cBgjYJglMcgWd3AYsngREBAQE
X-IronPort-AV: E=Sophos;i="5.44,361,1505779200"; d="scan'208";a="28197515"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Nov 2017 23:53:57 +0000
Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vA7NrvhI026048 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 Nov 2017 23:53:57 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 7 Nov 2017 18:53:56 -0500
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Tue, 7 Nov 2017 18:53:56 -0500
From: "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>
To: "Flemming Andreasen (fandreas)" <fandreas@cisco.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, Florian Weimer <fw@deneb.enyo.de>
CC: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] network-based security solution use cases
Thread-Index: AQHTVQ82KKjKBkAk5kyjDwLCBqb5H6MF7FPMgAKjMwCAAGt7gIAA7sYA//+BIwA=
Date: Tue, 07 Nov 2017 23:53:56 +0000
Message-ID: <8448A3AF-CEAF-41F4-A43F-9ED7B209C7B9@cisco.com>
References: <895D1206-28D1-43AB-8A45-11DEEC86A71D@cisco.com> <874lq868t3.fsf@mid.deneb.enyo.de> <a7a78674-d80d-dbd3-3c65-2d4000922423@cisco.com> <6966da46-0f07-b518-4b6e-f2b5f599b050@cs.tcd.ie> <b93fb058-7a61-13e0-9a39-a8f55e970d6c@cisco.com>
In-Reply-To: <b93fb058-7a61-13e0-9a39-a8f55e970d6c@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1a.0.160910
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.155.71.77]
Content-Type: text/plain; charset="utf-8"
Content-ID: <6328D5F5EE573D40955C977B4A5DC14C@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Av0KcUI2ZN9tJWGkFdqSeQg_-gM>
Subject: Re: [TLS] network-based security solution use cases
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Nov 2017 23:54:01 -0000

Hi Stephen,
Adding to Flemming’s comment,  finding “exact quotes” will be difficult as their intent is really not to break things but rather want to ensure that inspection and oversight is available to affect guards/protections within an (enterprise/data center) infrastructure.   That said, PCI and other regulations will have a lot of documents that one has to go through….one that kind-of calls explicitly to the use of packet inspection, firewalling and such is in:

https://www.pcisecuritystandards.org/documents/SAQ_D_v3_Merchant.pdf

It is an assessment questionnaire for vendors to evaluate their compliance, the requirements speak to securing the network and systems including firewalls, DMZs and the ability to do packet inspection.

Thanks, Nancy 

On 11/7/17, 3:27 PM, "Flemming Andreasen (fandreas)" <fandreas@cisco.com> wrote:

    Thanks for taking an initial look at the document Stephen - please see 
    below for responses so far
    
    On 11/7/17 4:13 AM, Stephen Farrell wrote:
    > Hiya,
    >
    > On 07/11/17 02:48, Flemming Andreasen wrote:
    >> We didn't draw any particular line, but the use case scenarios that we
    >> tried to highlight are those related to overall security and regulatory
    >> requirements (including public sector)
    > I had a quick look at the draft (will try read properly en-route to
    > ietf-100) and I followed the reference to [1] but that only lead to a
    > forest of documents in which I didn't find any reference to breaking
    > TLS so far at least. Can you provide an explicit pointer to the
    > exact document on which that claim is based?
    For NERC, you can look under  "(CIP) Critital Infrastructure 
    Protection". CIP-005-5 for example covers the electronic security 
    perimeter, which has a couple of relevant requirements and associated text:
    
    http://www.nerc.com/_layouts/PrintStandard.aspx?standardnumber=CIP-005-5&title=Cyber%20Security%20-%20Electronic%20Security%20Perimeter(s)&jurisdiction=United%20States 
    
    
    To be clear though, the document does not specifically call out breaking 
    TLS, but it does clearly call out the need to detect malicious inbound 
    and outbound communications by leveraging an "Electronic Access Point" 
    (e.g. IDS/IPS) to enforce the Electronic Security Perimeter.
    > I'd also claim that your reference to PCI-DSS is misleading, as that
    > same spec also explicitly calls for there to be good key management
    > specifically including minimising the number of copies of keys, so
    > at most, one might be able to claim that PCI-DSS is ok with people
    > who break TLS in a nod-and-a-wink manner. But if you do have a real
    > quote from PCI-DSS that calls for breaking TLS then please do also
    > send that (it's been asked for a bunch of times without any answer
    > being provided so far).
    
    I will need to look more closely for such a quote - if anybody else 
    knows of one, please chime in as well.
    
    Thanks
    
    -- Flemming
    
    
    > Thanks,
    > S.
    >
    >
    > [1]
    > https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00.html#ref-NERCCIP
    >