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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 08 November 2017 00:01 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 8DCFA129BCA for <tls@ietfa.amsl.com>; Tue, 7 Nov 2017 16:01:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 RCGWPSOFjAem for <tls@ietfa.amsl.com>; Tue, 7 Nov 2017 16:01:36 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1200129B74 for <tls@ietf.org>; Tue, 7 Nov 2017 16:01:35 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 098FFBE39; Wed, 8 Nov 2017 00:01:34 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4ashdpkmYPf; Wed, 8 Nov 2017 00:01:31 +0000 (GMT)
Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7FDC5BE38; Wed, 8 Nov 2017 00:01:31 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1510099291; bh=8fAl7R0JfVLdTPORTwlCW4qWb/tpeIhhkO/md/llAVY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=LxQ/E9Cp6+QzeO4sQI/JHdzOk4uZ7jGKlbtDnjXbby3zXmBMrk0zcGTYgQzLSxd/3 xf7Ls8z68UZMhtnCmLNyJFbH5DHcAE9HGCXpTnP41HjbJBHWRJ//QXfnhHoEiUAP6A 5httKI+PCYH+wn7nPBmYDPsCtBAo7U6VnAD3t43g=
To: Flemming Andreasen <fandreas@cisco.com>, 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>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <eebb00b8-c13c-3880-72d1-333f3761956d@cs.tcd.ie>
Date: Wed, 8 Nov 2017 00:01:30 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <b93fb058-7a61-13e0-9a39-a8f55e970d6c@cisco.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4rmcX1MfiidtAt4c8pnDc0JBECDAtMO6N"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/-1DImNyAigBDh3J2-U6YCDNV0IE>
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 00:01:38 -0000

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.

> 
> 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?

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.

> 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.

>> 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.)

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?

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
>>
>>
> 
>