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

[Eric Rescorla <[e-mail]>]

On Fri, Nov 10, 2017 at 11:39 AM, Nancy Cam-Winget (ncamwing) <
[e-mail]> 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" <[e-mail]> 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" <[e-mail]>
> 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)"
>     >     > <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>