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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 08 November 2017 00:40 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 7F56B129C67 for <tls@ietfa.amsl.com>; Tue, 7 Nov 2017 16:40:49 -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 2aVI72pUktxe for <tls@ietfa.amsl.com>; Tue, 7 Nov 2017 16:40:46 -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 16451129C5F for <tls@ietf.org>; Tue, 7 Nov 2017 16:40:45 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B3D69BE39; Wed, 8 Nov 2017 00:40:43 +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 dBGPxHfVm_dF; Wed, 8 Nov 2017 00:40:38 +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 16205BE38; Wed, 8 Nov 2017 00:40:38 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1510101638; bh=zmalz7i0KTSnHoDDc7z737/weIed7kpVfF1zVkAl+mU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=aCGyI5PLOhAqXiJJWZPN/vSbfQcPVjyPiJ3OO2AepxxFOMTngS8NmvJ17O+fslmIq qHcsKmb2FrlTQFKhkjrDicQi/DHZj5INhfL/zojZTEJJXIUSyl7Lq5uWMAkNA2pvxh DavRTgbrTjFd5o3Pu2qjhWt0B9UqftzYUU9paiwQ=
To: "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>, "Flemming Andreasen (fandreas)" <fandreas@cisco.com>, Florian Weimer <fw@deneb.enyo.de>
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> <8448A3AF-CEAF-41F4-A43F-9ED7B209C7B9@cisco.com> <84562f24-7a4f-4a9f-264c-1edf1e41bebe@cs.tcd.ie> <C40B7001-346A-4F42-9E8F-A80332CAE0A3@cisco.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <3db42c7c-2904-f11f-ab8e-116835669816@cs.tcd.ie>
Date: Wed, 8 Nov 2017 00:40:37 +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: <C40B7001-346A-4F42-9E8F-A80332CAE0A3@cisco.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="P9SdcQD2PJLJjNANDuLhEGRTLvCTcTDO2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Rup9xjq4C7oQzFi51qKcLujhjRo>
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:40:50 -0000

Hiya,

On 08/11/17 00:23, Nancy Cam-Winget (ncamwing) wrote:
> Hi Stephen,
> Please see below:
> 
> On 11/7/17, 4:08 PM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie>; wrote:
> 
>     
>     Hiya,
>     
>     On 07/11/17 23:53, Nancy Cam-Winget (ncamwing) wrote:
>     > Hi Stephen, Adding to Flemming’s comment,  finding “exact quotes”
>     > will be difficult 
>     
>     I'm sorry but when making a claim that such and such a regulation
>     *requires* breaking TLS then you really do need to be that precise.
> [NCW] In TLS 1.2, not sure why you state *requires* as there is the visibility afforded to 
> at least allow for the identity disclosure to enable white or blacklist for example.  

Quoting from your draft wrt PCI-DSS:

" Requirement #2 (and Appendix A2 as it concerns TLS)
   describes the need to be able to detect protocol and protocol usage
   correctness."

That one is nice - you seem to be arguing for protocol non-conformance
(or for weakening conformant implementations) in order to help ensure
"protocol usage correctness." That kind of makes my head spin.

Another quote wrt NERC:

" In fact, regulatory standards such as NERC CIP
   [NERCCIP] place strong requirements about network perimeter security
   and its ability to have visibility to provide security information to
   the security management and control systems. "

Where exactly did you see those "strong requirements" that presumably
*require* breaking TLS?

I don't see them.

When I or others ask to be shown them we don't get shown them.

To me that means those are not *required*.

> 
>     > 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
>     
>     The first mention of TLS there talks about protecting administrator
>     passwords via TLS. That totally argues against deployment of any kind
>     of MitM infrastructure.
> [NCW] Agreed, they also state in ensuring that the newest TLS version where 
> possible is used.  BUT, they also expect monitoring and troubleshooting.

Sure. Not all monitoring *requires* breaking TLS. Same for
troubleshooting.

Of course people who sell kit for that or have been doing
that for a while might want to see what they do as being
mandatory/required/regulated-for but I'm not seeing it.

>     
>     > 
>     > 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.
>     
>     Please point me at the specific text. Given you added PCI-DSS to
>     your document I would assume you did the work already. If not,
>     that's a bit odd.
> [NCW] From the link above, you can look at requirements in 1.3,
> also Requirement 10 details the need to monitor and provide audit trails
> for network resources and cardholder data

You mean 1.3 on page 6 I guess. I see nothing on pages 6 or 7
that call for MitMing TLS. That seems to be about addressing
and DMZs and firewall and router configs.

Requirement 10 seems to be dealing with audit of accesses to
cardholder data, not with TLS at all. I read pages 50-55 for
that.

Honestly, what you're saying is there does not seem to be
there.

S.


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