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

Flemming Andreasen <fandreas@cisco.com> Wed, 08 November 2017 17:06 UTC

Return-Path: <fandreas@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 00A14128D86 for <tls@ietfa.amsl.com>; Wed, 8 Nov 2017 09:06:04 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 OMidb7q-uU6H for <tls@ietfa.amsl.com>; Wed, 8 Nov 2017 09:06:01 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 954BC1288A9 for <tls@ietf.org>; Wed, 8 Nov 2017 09:06:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15963; q=dns/txt; s=iport; t=1510160761; x=1511370361; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=3aDhirL0/Cq5czGCfoS24CisBjB1GsKvGRpazdm347Q=; b=DqT5O5Xeg1cJ0O79BgULXq0gTqMEjWBwBumnBkpgtVUqsQGyL2XEtlux rkHHefEmWb82xJ7bqGOpMhs1chfsGHfsPnFX2xq55ZIA6fdCUEjzzFajo P7ulTcCPbtBB6TaYE5TIT3T8A/5RgHcr+3RgwzkO/7KVtvnPZh02TSdfn k=;
X-IronPort-AV: E=Sophos;i="5.44,365,1505779200"; d="scan'208,217";a="321701165"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Nov 2017 17:05:56 +0000
Received: from [10.118.10.19] (rtp-fandreas-2-8812.cisco.com [10.118.10.19]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vA8H5tu4018569; Wed, 8 Nov 2017 17:05:56 GMT
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Florian Weimer <fw@deneb.enyo.de>, "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>
Cc: "tls@ietf.org" <tls@ietf.org>
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> <eebb00b8-c13c-3880-72d1-333f3761956d@cs.tcd.ie>
From: Flemming Andreasen <fandreas@cisco.com>
Message-ID: <9107b2dc-1f62-8aa8-645a-98aba623ae8a@cisco.com>
Date: Wed, 8 Nov 2017 12:06:46 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <eebb00b8-c13c-3880-72d1-333f3761956d@cs.tcd.ie>
Content-Type: multipart/alternative; boundary="------------A4BD86FEFFB482C795EDA588"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/aV3fUTyLtLta8XRQeGw5B3Ok_Cw>
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: Wed, 08 Nov 2017 17:06:04 -0000


On 11/7/17 7:01 PM, Stephen Farrell wrote:
> Hiya,
>
> On 07/11/17 23:27, Flemming Andreasen 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
>>
> Thanks for that.
>
> So I didn't see any mention of TLS in that document at all.
Correct - the document is not a technical protocol specification but 
rather provides a set of requirements that have to be satisfied.
>> 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
> For inbound (on page 9) I see it mentions IDSes and application
> layer firewalls as examples yes. Given that the latter would not
> require any messing with TLS at all, this seems to be a very
> clear example of a regulation not requiring breaking TLS. That'd
> mean there is no regulatory requirement at all wouldn't it?
An application layer firewall (aka NGFW these days) does indeed require 
you to be involved with TLS. How would you perform application-level 
inspection without ? Example functions include scanning for malware 
downloads, URL/application filtering, attack signatures (getting a bit 
more into the IDS space).


> But again, if there are real regulatory requirements there that
> really do call for MitM attacks on TLS I'd be glad to look at them
> if you want to quote them.

Again, the document is not a technical protocol specification, but it 
clearly describes the notion of an electronic security perimeter with a 
need for electronic access point and provides IDS/IPS as example 
instantiations of such a function. Let me quote a bit more from said 
document:
<quote>
/The standard adds a requirement to detect malicious communications for 
Control Centers. This//
//is in response to FERC Order No. 706, Paragraphs 496-503, where ESPs 
are required to have two//
//distinct security measures such that the BES Cyber Systems do not lose 
all perimeter protection//
//if one measure fails or is misconfigured. The Order makes clear that 
this is not simply//
//redundancy of firewalls, thus the SDT has decided to add the security 
measure of malicious//
//traffic inspection as a requirement for these ESPs. Technologies 
meeting this requirement//
//include Intrusion Detection or Intrusion Prevention Systems (IDS/IPS) 
or other forms of deep//
//packet inspection. These technologies go beyond 
source/destination/port rule sets and thus//
//provide another distinct security measure at the ESP./
</quote>

I don't know how you can reasonably argue that you satisfy the 
requirement here if you don't inspect encrypted traffic.

>> and outbound communications by leveraging an "Electronic Access Point"
>> (e.g. IDS/IPS) to enforce the Electronic Security Perimeter.
> Personally, I have to say I find the outbound stuff nonsense.
> I know people make money selling product and services for that.
It's not nonsense - it's deployed for a reason and it actually blocks a 
lot of attacks, in no small part by disabling command and control 
traffic. WannaCry and HeartBleed are just two of the more prominent 
examples of this, and there are many more where they came from (some 
encrypted, some not). You may want to take a look at 
http://blog.talosintelligence.com/2017/05/wannacry.html and 
http://blog.talosintelligence.com/2014/04/heartbleed-memory-disclosure-upgrade.html 
for starters. Feel free to browse around for many more.

>>> 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.
> It's been asked for a number of times without any substantive
> response. I would assume that one of the authors of this would
> be able to point at the text that caused you to add in a mention
> of PCI-DSS. If not, that seems odd.
>
> I actually looked through the PCI spec myself and found that it
> is fairly explicitly asking for good crypto and not bad crypto.
> (E.g. as mentioned, saying to minimise the number of copies of
> keys that are anywhere.)
Let's take the PCI-DSS part on the parallel part of this thread.

>
> Maybe the ADs ought liaise to some of those organisations and
> ask them if they do or do not recognise the claims related to
> breaking TLS being attributed to them?
I think that's a really good suggestion.

Thanks

-- Flemming

> Or even better, maybe just not making those claims would be
> easier all around and more accurate.
>
> S.
>
>> Thanks
>>
>> -- Flemming
>>
>>
>>> Thanks,
>>> S.
>>>
>>>
>>> [1]
>>> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00.html#ref-NERCCIP
>>>
>>>
>>