Encryption Everywhere

Transcription

1 Encryption Everywhere Adapting to a New Reality that favors Security and Privacy Kathleen Moriarty EMC Office of CTO IETF Security Area Director (Speaking for myself, not the IETF) 1

2 Agenda Protocol and Cipher Suite Support Background on changes to increase deployment of encryption Opportunistic Security The Effects of Ubiquitous Encryption 2

3 SSLv3 has been deprecated Remove it from products SSLv3 has been deprecated, TLS 1.2 is the current recommendation Use of OpenSSL doesn t mean you are using SSL TLS 1.0 should be removed as well TLS 1.2 has improved cipher suites over TLS 1.1 Browsers now show when conditions don t meet recommendations, example: To see how browsers react try: IETF published a deprecation draft: Attacks against SSLv3 included 3

4 TLS Attacks and Recommendations TLS 1.2 with recommended cipher suites and configuration TLS 1.2 is the current recommended version, with TLS 1.3 nearing publication TLS and DTLS Best Practices Cipher suite recommendations Guidance provided is specific to needs of implementations Perfect Forward Secrecy (PFS) is now pretty much expected Development and implementation guidance provided to avoid known attacks, including use of tools like wireshark This means many tools that intercept sessions will break Summary of attacks against TLS 4

5 Crypto Forum Research Group (CFRG) TLS Cipher suites Selecting new cipher suites for TLS Motivation for CFRG starting this work: Reduced trust in NIST Note that NIST has taken some steps to improve trust nistir_7977_draft.pdf NIST Curves still required, selection of curves depends on customer base. CFRG selection did not include NIST curves, but that doesn t change product implementation requirements necessarily. CFRG process includes a series of consensus polls Improving side channel resistance and performance by selecting new curves from academia Working on consensus around requirements: Just wrapping up poll on signatures and properties Prior polls on signatures and curves 5

6 CFRG Crypto Decisions Starts with Requirements Decisions? Not sure when they will be done CFRG is iterating through consensus process on requirements 2 curves have been selected, Curve25519 approx 128 bits of security; already deployed in several places Goldilocks offers good performance-security trade-off at higher security level (approx 224 bits of security) Diffie Hellman Key exchange defined for both curves In principle, these curves can be deployed as is in TLS in combination with existing signature schemes Signature schemes to replace RSA and ECDSA in TLS Many drafts have been published with Ed25519, nothing has been selected hold on! Content from CFRG chair, Kenny Paterson 6

7 Salsa, ChaCha, Anyone? ChaCha20 and Poly1305 Support being added to Protocols RC4 replacement when no AES hardware in use ChaCha20 is a stream cipher, variant of Salsa20 Consistently faster than AES and more conservative design Inputs include: 256-bit key 96-bit nonce (initialization vector) 32-bit initial counter Of course, plaintext 20 rounds (column & diagonal) performed Poly1305 algorithm is a one-time authenticator Input 256-bit one-time key, 96-bit Designed to ensure forged messages are rejected with high probability Protocol integration: IPsec: TLS: Not sure if this is going forward: Background & Implementation Advice: See RFC7539 for guidance on libraries for Poly1305 to avoid side-channel attacks and performance issues. Be sure to read security considerations for additional advice! Both algorithms by: D. J. Bernstein 7

8 Security, Privacy, and the Effects of Ubiquitous Encryption 8

9 Motivation for Increased Privacy Protections BULLRUN/EDGEHILL RADON FOXACID TRAILBLAZER PRISM TREASUREMAP 9

10 Privacy & Confidentiality on the Internet Current IETF and IAB Guidance IETF Privacy Considerations for Internet protocols Data protection Object level encryption Determining when data is not necessary Obscuring data or generalizing when possible Protections on sensitive data and indexes to that data Push for encrypted traffic IAB Statement on Internet Confidentiality 10

11 Pervasive Monitoring Changed the Game 11

12 New IETF Work Related to Pervasive Monitoring (PM) Pervasive Monitoring Is an Attack RFC7258/BCP188 published after major IETF LC debate sets the basis for further actions BCP says to consider PM in IETF work Existing-RFC privacy/pm review team formed Opportunistic security (OS) Provides a way to get much easier deployment for some intermediate level of security Fallback to unauthenticated encrypted sessions instead of plaintext Updates to supported algorithms Lower the barriers for key and certificate management 12

13 IETF Work related to PM and Opportunistic Security Using TLS in Applications (UTA WG) Update existing RFCs on how to use TLS in applications and mandate implementation of non-pfs ciphersuites BCPs for TLS and DTLS attacks and configurations TLS 1.3 (TLS WG) TLS 1.3 being developed aiming for better handshake performance and encryption properties (use of DANE for end-to-end encryption) And learning from our history of previous TLS problems HTTP/2.0 (HTTPBIS WG) Major deployment model: HTTP over TLS, but not required yet TCP Increased Security (TCPInc) Provide TLS functionality within TCP Support Opportunistic security with a way to hook in authentication DNS Privacy (DPRIVE) Reducing exposure of sensitive names found in DNS IPsec NULL authentication support for Opportunistic Security approach 13

14 How are Operators and Security Professionals Impacted? The Effects of Ubiquitous Encryption 14

15 Effects of Ubiquitous Encryption Editors: Kathleen Moriarty & Al Morton Increased encryption impacts security & network operations Shift how these functions are performed New methods to monitor and protect data will evolve In more drastic circumstances, ability to monitor may be eliminated Collection of current security and network management functions impacted by encryption Draft does not attempt to solve these problems It merely documents the current state to assist in the development of alternate options to achieve the intended purpose of the documented practices 15

16 What s the Problem? Encryption blocked to prevent impact on current operations Ad Injection Clear text has been used to inject ads, as well as monitor traffic for network and security purposes Operational capabilities are diminishing, some operators responded by stopping encryption negotiation Typically required exposure (media & regulators) to correct More recently, the Great Cannon 16

17 Middlebox Monitoring Traffic Interception and Pattern Matching Traffic Analysis Fingerprinting Encrypted and clear text pattern matching Attack detection and monitoring Invade Privacy, web traffic Traffic Surveys Observations over time Inferences about observed traffic using maximal information available Accuracy of patterns decline with encryption Deep Packet Inspection Analysis of user flows and apps (for resource optimization) Used with content distribution networks to improve efficiency Note: CDNs moving to end-to-end control of data now Data Compression Gateway Minimize traffic required using resource-constrained services, e.g., Data Caps 17

18 Performance Management and Troubleshooting Current methods for existing functions impacted by encryption Availability and Performance monitoring impacted by move to encryption Inability to discern difference between network and hostrelated causes of unavailability Inaccuracy will increase and efficiency of repair activities will decrease Use of websockets will make application differentiation more difficult 18

19 Encryption in Hosted SP Environments Drivers different for Increased Security Protections Management Access SP access to manage infrastructure: encrypted or isolated Customer management access encrypted Hosted Applications Increasingly sensitive applications Data leakage protection (DLP) now limited Access Control Management and monitoring shifting Logs may be used as an alternative monitoring data source Monitoring and filtering may be restricted to: 2-tuple IP-level with source and destination IP addresses alone, or 5-tuple IP and protocol-level with source IP address, destination IP address, protocol number, source port number, and destination port number. 19

20 Data Storage Capabilities changed, but solution providers have adapted Host-level encryption End-to-end, encrypted at application or prior to transition to hosted environment Backup, external storage Disk encryption, Data at Rest Requires transport encryption to protect data on the wire May only be used to protect from physical theft of disk Controller based encryption or Self Encrypting Drives Data replication between data centers IPsec may limit ability to monitor MACsec IEEE 802.1AE Layer 2 encryption between data centers 20

21 Incident Monitoring Denial of Service Information Copyright 2015 EMC Corporation. All rights reserved. 21

22 Summary Use of Encryption Encouraged to Protect Users Privacy Follow TLS best practices recommendations! Support TLS 1.2, Remove support for SSLv3 and TLS 1.0 Encryption increasing in response to known threats and move of sensitive application & data to hosted environments Protecting Users privacy at protocol level necessary Current techniques used by operators may no longer be possible in an encrypted Internet Devise new methods to accomplish goals First document those goals and understanding objectives Contribute to draft: Effects of Ubiquitous Encryption 22

23 Thank you!

24 Mission of the IETF Make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet. RFC

25 Ethos of the IETF Open standards process Everyone is invited to participate at all levels Our primary venue is All working and published documents are freely available online One Internet Open standards for a global Internet Maximum interoperability and scalability Avoid specialized protocols in different places Contributions are judged on technical merits: rough consensus and running code, RFC