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. > > 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? 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. > 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. >> 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.) 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? 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 >> >> > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
