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)

2

Agenda

� Protocol and Cipher Suite Support � Background on changes to increase deployment of

encryption

� Opportunistic Security

� The Effects of Ubiquitous Encryption

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: https://

–  To see how browsers react try: https://badssl.com/

�  IETF published a deprecation draft: –  https://datatracker.ietf.org/doc/draft-ietf-tls-sslv3-diediedie/ –  Attacks against SSLv3 included

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 –  https://datatracker.ietf.org/doc/rfc7525/ –  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 –  https://datatracker.ietf.org/doc/rfc7457/

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 trusthttp://csrc.nist.gov/publications/drafts/nistir-7977/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 —  http://www.ietf.org/mail-archive/web/cfrg/current/msg06792.html

▪  Prior polls on signatures and curves —  http://www.ietf.org/mail-archive/web/cfrg/current/msg06619.html —  http://www.ietf.org/mail-archive/web/cfrg/current/msg06521.html

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,

https://tools.ietf.org/html/draft-irtf-cfrg-curves-02 �  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

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: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305 –  TLS: Not sure if this is going forward:

https://datatracker.ietf.org/doc/draft-agl-tls-chacha20poly1305/

�  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

8

Security, Privacy, and the Effects of Ubiquitous Encryption

9

Motivation for Increased Privacy Protections

BULLRUN/EDGEHILL FOXACID PRISM

RADON TRAILBLAZER TREASUREMAP

10

Privacy & Confidentiality on the Internet Current IETF and IAB Guidance

�  IETF Privacy Considerations for Internet protocols –  https://datatracker.ietf.org/doc/rfc6973/ –  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 –  https://www.iab.org/2014/11/14/iab-statement-on-

internet-confidentiality/

11

Pervasive Monitoring Changed the Game

• 

• 

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 –  https://www.rfc-editor.org/rfc/rfc7258.txt –  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 –  https://datatracker.ietf.org/doc/rfc7435/

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 –  https://datatracker.ietf.org/doc/draft-bortzmeyer-dnsop-dns-privacy/

•  IPsec –  NULL authentication support for Opportunistic Security approach

14

How are Operators and Security Professionals Impacted?

The Effects of Ubiquitous Encryption https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/

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

16

What’s the Problem? Encryption blocked to prevent impact on current operations

�  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

010100101010001001111001010101001

Ad Injection

More recently, the Great Cannon

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

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 host-related causes of unavailability

�  Inaccuracy will increase and efficiency of repair activities will decrease

� Use of websockets will make application differentiation more difficult

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.

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

21

Incident Monitoring

Information

Denial of

Service

© Copyright 2015 EMC Corporation. All rights reserved.

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”

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.

RFC3935

24

25

Ethos of the IETF

• Open standards process –  Everyone is invited to participate at all levels –  Our primary venue is email –  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, RFC7282