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

["Nancy Cam-Winget (ncamwing)" <[e-mail]>]

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.

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
    >     >
    >     >> 
    >     > 
    >     > 
    >     > 
    >     > 
    >     
    >     
    >