On Fri, Nov 10, 2017 at 11:39 AM, Nancy Cam-Winget (ncamwing) <
ncamw...@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.farr...@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.farr...@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)"
> > > <fandr...@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
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
