On 11/7/17 7:01 PM, Stephen Farrell wrote:
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.
Correct - the document is not a technical protocol specification but
rather provides a set of requirements that have to be satisfied.
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?
An application layer firewall (aka NGFW these days) does indeed require
you to be involved with TLS. How would you perform application-level
inspection without ? Example functions include scanning for malware
downloads, URL/application filtering, attack signatures (getting a bit
more into the IDS space).
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.
Again, the document is not a technical protocol specification, but it
clearly describes the notion of an electronic security perimeter with a
need for electronic access point and provides IDS/IPS as example
instantiations of such a function. Let me quote a bit more from said
document:
<quote>
/The standard adds a requirement to detect malicious communications for
Control Centers. This//
//is in response to FERC Order No. 706, Paragraphs 496-503, where ESPs
are required to have two//
//distinct security measures such that the BES Cyber Systems do not lose
all perimeter protection//
//if one measure fails or is misconfigured. The Order makes clear that
this is not simply//
//redundancy of firewalls, thus the SDT has decided to add the security
measure of malicious//
//traffic inspection as a requirement for these ESPs. Technologies
meeting this requirement//
//include Intrusion Detection or Intrusion Prevention Systems (IDS/IPS)
or other forms of deep//
//packet inspection. These technologies go beyond
source/destination/port rule sets and thus//
//provide another distinct security measure at the ESP./
</quote>
I don't know how you can reasonably argue that you satisfy the
requirement here if you don't inspect encrypted traffic.
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.
It's not nonsense - it's deployed for a reason and it actually blocks a
lot of attacks, in no small part by disabling command and control
traffic. WannaCry and HeartBleed are just two of the more prominent
examples of this, and there are many more where they came from (some
encrypted, some not). You may want to take a look at
http://blog.talosintelligence.com/2017/05/wannacry.html and
http://blog.talosintelligence.com/2014/04/heartbleed-memory-disclosure-upgrade.html
for starters. Feel free to browse around for many more.
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.)
Let's take the PCI-DSS part on the parallel part of this thread.
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?
I think that's a really good suggestion.
Thanks
-- Flemming
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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
