Internet DRAFT - draft-mattsson-opportunistic-encryption
draft-mattsson-opportunistic-encryption
Network Working Group J. Mattsson
Internet-Draft Ericsson
Intended status: Informational February 14, 2014
Expires: August 18, 2014
Opportunistic Encryption
draft-mattsson-opportunistic-encryption-00
Abstract
Following the recent pervasive monitoring revelations, one of the
discussed remedies has been opportunistic encryption. In this paper,
we give an overview of various opportunistic and unauthenticated
encryption techniques, discuss their benefits, limits, and
disadvantages, and try to conclude how effective they are as a mean
to thwart pervasive monitoring.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 18, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Mattsson Expires August 18, 2014 [Page 1]
Internet-Draft Opportunistic Encryption February 2014
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Deployments of Opportunistic Encryption . . . . . . . . . . . 3
3. Methods for Unauthenticated Encryption . . . . . . . . . . . 3
4. Weak Authentication Methods . . . . . . . . . . . . . . . . . 4
5. Benefits against Pervasive Monitoring . . . . . . . . . . . . 5
6. Disadvantages . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Following the recent pervasive monitoring revelations, one of the
discussed remedies has been opportunistic encryption. The term
opportunistic encryption is, however not very well defined and has
been used for very different systems, only having in common that
something in the setup is opportunistic. The term opportunistic
encryption is sometimes used as a synonym to unauthenticated
encryption, meaning that the endpoint is opportunistic about the
other endpoint being the desired endpoint and not an adversary. But
opportunistic encryption can also mean that the endpoint is
opportunistic about the other endpoint's support of encryption
(falling back to unencrypted otherwise). In most cases, it refers to
a system where encryption is added (sometimes or always) without any
pre-deployment of credentials between the two endpoints (at least not
for the protocol in question), and where the endpoints do not
authenticate each other. The end result is that the endpoints can be
unauthenticated, weakly authenticated, or strongly authenticated, in
some cases without the endpoints even knowing which.
Whereas encryption traditionally has only been used where necessary
and when the end user specifically asks for it (secure email, TLS,
crypto phones) or when set up by a network administrator (IPsec
between sites), one could say that the aim of opportunistic
encryption is to encrypt whenever possible. Similar to [OPPENC], we
define opportunistic encryption to mean systems where encryption
(authenticated or unauthenticated) is automatically set up (if
supported) without user requests or administrator involvement. We
define unauthenticated encryption to mean systems where the endpoints
are not strongly authenticated and where man-in-the-middle attacks
may be possible.
Mattsson Expires August 18, 2014 [Page 2]
Internet-Draft Opportunistic Encryption February 2014
2. Deployments of Opportunistic Encryption
The most common and successful usage of opportunistic encryption has
been for server-to-server encryption, and the most widely deployed
and used system is probably STARTTLS for SMTP [RFC3207], which
opportunistically tries to upgrade a plaintext SMTP connection to an
encrypted connection over TLS. Another example is the swan projects
(FreeS/WAN, Openswan, and Libreswan [SWAN]) that rely on DNS for
dynamic discovery and negotiation of IPsec tunnels between gateways.
If DNSSEC is used, the encryption is authenticated and secure also
against active attacks. In these use cases, the end user is totally
unaware of the encryption.
Opportunistic encryption for client-server or client-to-client
communication is not widely deployed. One client-to-server system is
HTTPS Everywhere [EFF] which enables HTTPS where supported.
3. Methods for Unauthenticated Encryption
o Unprotected key transport. The simplest way to achieve
unauthenticated encryption is to just transfer the session key or
password in the hope that the communication channel was either
confidential or that no adversary happened to eavesdrop. Examples
are SDP security descriptions [RFC4568] and the extremely common
use of unprotected emails for sending out new or forgotten
passwords. In these cases, the hope is that the key transport is
at least protected hop-by-hop and in the email case that the
legitimate user changes the temporary password before any
eavesdropper do.
Compared to unprotected communication, this approach forces an
eavesdropper to decrypt the communication and to intercept
different message types potentially taking different routes.
Except for the case with temporary passwords, an adversary can be
completely passive and cannot be easily detected. The
eavesdropper may store the encrypted communication for later
decryption. In the case of temporary passwords, an adversary
needs to act quickly before the legitimate user changes the
password.
o Self-signed certificates. A more sophisticated type of
unauthenticated encryption uses self-signed certificates (or raw
public keys) in a key agreement protocol. One example is DTLS-
SRTP [RFC5764] with a non-Diffie-Hellman ciphersuite.
Compared to key transport, an eavesdropper is forced to be active,
but as the eavesdropper can typically negotiate the same session
key with both endpoints the eavesdropper can be passive after the
Mattsson Expires August 18, 2014 [Page 3]
Internet-Draft Opportunistic Encryption February 2014
initial key management phase. The eavesdropper cannot easily be
detected except by using some out-of-band channel (see Section 4)
to compare the exchanged certificates.
o Diffie-Hellman key exchange. The most secure type of
unauthenticated encryption uses a Diffie-Hellman key exchange
(with or without exchange of self-signed certificates). Examples
are SSH, the Tor project [TOR] (that provides anonymity but not
end-to-end confidentiality), and DTLS-SRTP [RFC5764] with a
Diffie-Hellman ciphersuite.
Compared to non-Diffie-Hellman key agreement, the adversary cannot
negotiate the same session key with both endpoints forcing the
adversary to decrypt and re-encrypt all messages in real-time. It
also provides perfect forward secrecy.
4. Weak Authentication Methods
Unauthenticated encryption is often strengthened by some form of weak
authentication [WEAK] that gives imperfect, but -in some cases- good
enough, security. By weak authentication, we mean authentication
without relying on trusted third parties and without physically
meeting and exchanging credentials.
o Out of band. Ensures that the same endpoint is reachable via more
than one communication path. Examples are SDP security
descriptions, DTLS-SRTP, the common use of email for sending out
new or forgotten passwords, and the use of SMS text messages to
deliver one-time passwords. An attacker needs to intercept both
paths, and potentially also do active attacks.
o Locality check. Ensures that the other endpoint is relatively
close, e.g. by measuring round-trip latency. One example is HDCP
v2.x. Limited round-trip latency also limits the amount of
processing an adversary can do, which may increase security.
o Key continuity. Ensures that the other endpoint is the same
endpoint as in the initial connection, by checking that is has
access to the same credential as before. Examples are SSH, DTLS-
SRTP, and CDMA over-the-air provisioning. An attacker needs to be
present during the first key management session.
o Human interactive proof. Test used to determine whether the other
endpoint is human or not. One example is short authentication
strings used in crypto phones and ZRTP [ZRTP]. Short
authentication strings may also provide authentication by voice
recognition.
Mattsson Expires August 18, 2014 [Page 4]
Internet-Draft Opportunistic Encryption February 2014
All these methods have weaknesses but e.g. key continuity may be
excellent when the first communication is on a trusted local network.
Short authentication strings between people knowing each other have
traditionally been used in crypto phones, but agencies are now
believed to have developed experimental voice analysis and synthesis
systems [ZRTP].
As described, the so-called "weak" authentication may give high
assurance and similarly the so-called "strong" authentication methods
may give low assurance when used incorrectly. The classification
into strong and weak authentication methods is therefore far from
optimal and it may be better to talk about the level of assurance in
the authentication.
5. Benefits against Pervasive Monitoring
While the use of unauthenticated encryption increases the cost of
pervasive monitoring, we estimate that the cost increase is quite
low. Just as adding encryption and authentication to a protocol
usually only increases the CPU usage by a small percentage, the cost
increases for an eavesdropper forced to decrypt, or decrypt and re-
encrypt is low. An eavesdropper doing pervasive monitoring is
already saving the information or at least scanning the messages for
relevant information, adding some cryptographic processing which
could be done in hardware is not going to be a major obstruction. An
evaluation in [IMPACT] shows that the throughput of an SIP proxy with
TLS is slightly below half that of a SIP proxy with unprotected TCP.
We estimate that an agency doing pervasive monitoring would face a
similar performance penalty, and that the use of dedicated hardware
can shrink this difference even further.
On the other hand, it is likely that an agency doing pervasive
monitoring, and especially active attacks, places a high value on not
being detected. Unauthenticated encryption with Diffie-Hellman key
exchange would enable detection of man-in-the-middle attacks. To
reveal pervasive monitoring on a massive scale it would only be
necessary to manually compare session keys out-of-band on a regular
basis.
6. Disadvantages
Introducing opportunistic or unauthenticated encryption in protocols
is likely to introduce yet another option, therefore increasing
complexity. It's a fact that the secure modes of many protocols are
often not implemented, implemented later, or not well tested.
Assuming that developers will suddenly begin implementing two
different secure modes is not realistic.
Mattsson Expires August 18, 2014 [Page 5]
Internet-Draft Opportunistic Encryption February 2014
There is also a risk that developers, people deploying systems, and
end-users (wrongfully) think that unauthenticated encryption is good
enough, therefore reducing the implementation and use of strong
authentication. In fact, very few people deploying or using the
systems are likely to understand what kind of security is really
offered, and under which circumstances they are protected against
various attacks. One example of an extremely complicated trust model
is DTLS-SRTP [RFC5764], which on top of all ciphersuites and key
management options in DTLS and SRTP adds two forms of weak
authentication in the form of certificate fingerprints and key
continuity. Average end users can in most cases not be expected to
do much more than to distinguish between secure or not secure (e.g.
by looking for a padlock icon), and nor should they.
7. Conclusions
Opportunistic and unauthenticated encryption certainly has its uses
and may with the right choices provide good enough security for a low
cost. The use of opportunistic encryption in STARTTLS for SMTP and
the use of key continuity as a weak authentication method in SSH are
excellent examples of that.
However, we do not think that massive deployment of opportunistic and
unauthenticated encryption is a general solution to the pervasive
monitoring problem, and may even cause as much harm as good. The
additional cost for processing and memory is likely quite low, or at
least not high enough to substantially reduce the amount of pervasive
monitoring. However a high risk of being detected might refrain
agencies from pervasive monitoring. But even if it's possible to
identify that there is an active man-in-the-middle, it might still be
difficult to identify where it's located and who it is.
Our opinion is that any recommendation should not be stressed and
that the Internet community should take its time to think and discuss
before agreeing on any general BCP for opportunistic and
unauthenticated encryption.
Our recommendation is that unauthenticated encryption is only used
when some form of weak authentication is likely to be available. For
opportunistic encryption we think that the impacts such as
operational and network management aspects needs to be analyzed and
understood for each protocol and that general recommendations are
therefore hard to make.
We recommend the Internet community to clearly define the term
"opportunistic encryption" or to use other terms. If encryption
without authentication is meant, we suggest that "unauthenticated
encryption" is a better expression. If used, the number of options
Mattsson Expires August 18, 2014 [Page 6]
Internet-Draft Opportunistic Encryption February 2014
should be reduced and that the implementation and naming should not
lead the end user to believe that the security is better than it
really is.
8. Acknowledgements
The authors would like to thank Mats Naeslund, Ben Smeets, and Andras
Mehes for their support and valuable comments.
9. References
[EFF] EFF, "HTTPS Everywhere", <https://www.eff.org/https-
everywhere>.
[IMPACT] Shen et al., "The Impact of TLS on SIP Server
Performance", <http://academiccommons.columbia.edu/
download/fedora_content/download/ac:127663/CONTENT/
cucs-022-09.pdf>.
[OPPENC] Citizendium, "Opportunistic Encryption",
<http://en.citizendium.org/wiki/Opportunistic_encryption>.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, February 2002.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[SWAN] "The Libreswan Project", <https://www.libreswan.org/>.
[TOR] "Tor Project", <https://www.torproject.org/>.
[WEAK] Arkko, Nikander, "How to Authenticate Unknown Principals
without Trusted Parties", <www.ietf.org/proceedings/57/
slides/enroll-4/enroll-4.ppt>.
[ZRTP] Wikipedia, "ZRTP", <http://en.wikipedia.org/wiki/ZRTP>.
Author's Address
Mattsson Expires August 18, 2014 [Page 7]
Internet-Draft Opportunistic Encryption February 2014
John Mattsson
Ericsson AB
SE-164 80 Stockholm
Sweden
Phone: +46 10 71 43 501
Email: john.mattsson@ericsson.com
Mattsson Expires August 18, 2014 [Page 8]
