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

Eric Rescorla <ekr@rtfm.com> Sat, 11 November 2017 01:12 UTC

Return-Path: <ekr@rtfm.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 BFC98127F0E for <tls@ietfa.amsl.com>; Fri, 10 Nov 2017 17:12:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 IE-YGsQVQhUl for <tls@ietfa.amsl.com>; Fri, 10 Nov 2017 17:12:07 -0800 (PST)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9A9A126D46 for <tls@ietf.org>; Fri, 10 Nov 2017 17:12:07 -0800 (PST)
Received: by mail-yw0-x235.google.com with SMTP id y75so9554124ywg.0 for <tls@ietf.org>; Fri, 10 Nov 2017 17:12:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G8LvO/iFnac7MP6nn9Tk+4M2M5wWj0UauOCPsokj4sM=; b=EnUDoK03tgaAY/TZyaedLlP9LxaHKidBvfHVG81KPCVfK7NlUjp9AhaREaJM6Qtyd9 gRiS3BFBSH9rLwelXepIqTwvNJ/7Tx3j7hAaOHeJVmmcftyCyRFqB0vaGZ7st42IIPL+ gEj6ZvS6R9YaQpS5nUXwparOq3H+IEiCQ6txRocCQ0Xc8T+dQuxDOF0aJw4120ue3XNP af6AFPdCK3LpRhxFt365p48IxpSCi1W0LK7Wft090fiRYSA9qNXM0Jj6Ze47yXLU7Vd7 I4QSI7pRxToXA5R3bP1j/0Gj/P26aUbXAUWrd9v/cOZfKbSh1+U4NoJM5r3oVwAFCc+l 64FA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G8LvO/iFnac7MP6nn9Tk+4M2M5wWj0UauOCPsokj4sM=; b=B22VSO7ID1gCA/nymkwYZchnJ/lvvIiaj3GjfSFSW1R4AANoTUnNINSn1ke4B3mLmK 3lby+DcNe5iS2y2iRoW+ZRS9mm1u2G4rctrmZnYdMAbjj1eIDuYt6Kk2UgYqlR0aFD+s XIxBbv3gZQZn7orYPDAwaXi/SIeheu9tJYtfLiYjnEKr7Ge5Kzn+nPhfQLGUeHp6Nwdt c9mt2mg/Ep853aMqT7loA9T5kKQuQM4JaK1FyubrICtv0BET/YvfFmIxbukLQq+MCVyx ijqlBugLw8aR7vDQ0dpLmdZ5aZfp5Aarr9irEDK9y20N21WLfCCM6BiwyDrBH6UDVswX IZRw==
X-Gm-Message-State: AJaThX7FcuEz7SKBDJoToDngNwXQzCMWyfPSofDFB3O7DjyHEcI76nzF 5XcY8Xf1AnBTyVYqhXPbIJTFFUvXnikCvUibZ47S2A==
X-Google-Smtp-Source: AGs4zManW5sus3davhm4KfMbyRfKlIS00mkq0vBQbzr2pp/4sCP49iHDM6MpaVivPq/Fv9eNOuJCIDl0qzpIJdeZsVE=
X-Received: by 10.37.20.193 with SMTP id 184mr1460384ybu.400.1510362726855; Fri, 10 Nov 2017 17:12:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.61.12 with HTTP; Fri, 10 Nov 2017 17:11:26 -0800 (PST)
In-Reply-To: <B6932E78-6856-4D4B-8540-ED0696FC7915@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> <8448A3AF-CEAF-41F4-A43F-9ED7B209C7B9@cisco.com> <84562f24-7a4f-4a9f-264c-1edf1e41bebe@cs.tcd.ie> <C40B7001-346A-4F42-9E8F-A80332CAE0A3@cisco.com> <3db42c7c-2904-f11f-ab8e-116835669816@cs.tcd.ie> <B6932E78-6856-4D4B-8540-ED0696FC7915@cisco.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 10 Nov 2017 17:11:26 -0800
Message-ID: <CABcZeBOaq6sLQ23BGtU9=4S6yxkc=SiubXunZx7MPKtHyfOwkg@mail.gmail.com>
To: "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "Flemming Andreasen (fandreas)" <fandreas@cisco.com>, Florian Weimer <fw@deneb.enyo.de>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a113e72b6d10d78055daab95e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/BMnffRZBZolhIqulg7YY5OYKE7Q>
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: Sat, 11 Nov 2017 01:12:12 -0000

On Fri, Nov 10, 2017 at 11:39 AM, Nancy Cam-Winget (ncamwing) <
ncamwing@cisco.com>; wrote:

>
> Hi all,
>
> I think Flemming has expressed our points well.  But I think we are losing
> sight of the purpose of the draft: this is what industry is doing today in
> response to requirements; whether imposed by customers or regulations.  I
> would not expect these to explicitly state how a solution, architecture and
> protocol is to be implemented, they do impose requirements to an expected
> outcome.  As such, solutions have embraced the use of TLS pervasively and
> balanced the requirements of customers/regulations to provide firewall,
> inspection for monitoring and troubleshooting by the use cases as
> documented in the draft.
>
> We are NOT against the use of PFS and improved security; we continue to
> look forward to evolving solutions that use TLS (1.3)…but in some cases
> there are implications that we thought merited awareness and further
> discussion.
>

Nancy,

I don't dispute that some organizations ("industry" seems like a pretty
overbroad term as many organizations do not do these things) engage in some
of the practices that you list. However, as I noted in my review, I think
there are real concerns about whether these practices in fact securely
achieve their stated goals (even ignoring the impact that accommodating
them would have on TLS 1.3).

-Ekr





> Warm regards, Nancy
>
>
> On 11/7/17, 4:40 PM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie>; wrote:
>
>
>     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
>     >     >
>     >     >>
>     >     >
>     >     >
>     >     >
>     >     >
>     >
>     >
>     >
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>