Re: [saag] Protocol Design Pattern (was Re: Last Call: <draft-dukhovni-opportunistic-security-01.txt>)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

On 8/19/2014 8:39 AM, Stephen Farrell wrote:
> also do a diff of this vs. -03, 

attached


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
Title: Diff: draft-dukhovni-opportunistic-security-03.txt - draft-dukhovni-opportunistic-security-03-kent.txt
< draft-dukhovni-opportunistic-security-03.txt   draft-dukhovni-opportunistic-security-03-kent.txt >
Network Working Group V. Dukhovni Network Working Group V. Dukhovni
Internet-Draft Two Sigma Internet-Draft Two Sigma
Intended status: Informational August 15, 2014 Intended status: Informational August 15, 2014
Expires: February 16, 2015 Expires: February 16, 2015
Opportunistic Security: Some Protection Most of the Time Opportunistic Security: Some Protection Most of the Time
draft-dukhovni-opportunistic-security-03 draft-dukhovni-opportunistic-security-03
Abstract Abstract
This memo introduces the "Opportunistic Security" (OS) protocol This memo introduces the concept "Opportunistic Crypto-Security"
design pattern. Protocol designs based on OS depart from the (OCS). OCS is a set of protocol design principles that attempt to
established practice of employing cryptographic protection against remove barriers to the widespread use of encryption on the Internet.
both passive and active attacks, or no protection at all. As a OCS is not a protocol. Protocols that adhere to OCS guidelines may
result, with OS at least some cryptographic protection should be offer additional crypto-security services, e.g., integrity and
provided most of the time. For example, the majority of Internet authentication, if these services are supported by all parties
SMTP traffic is now opportunistically encrypted. OS designs remove to a communication. The OCS design philosophy departs from the
barriers to the widespread use of encryption on the Internet. The common practice of other Internet security protocols; they commonly
actual protection provided by opportunistic security depends on the require cryptographic protection against both passive and active
advertised security capabilities of the communicating peers. attacks, or offer no protection at all. OCS protocols strive to
offer encryption even if authentication is not available. This
This document promotes designs in which cryptographic protection document encourages designs in which cryptographic protection
against both passive and active attacks can be rolled out against both passive and active attacks can be deployed
incrementally as new systems are deployed, without creating barriers incrementally, without creating barriers to communication.
to communication.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
skipping to change at page 2, line 28 skipping to change at page 3, line ?
5. Example: Opportunistic TLS in SMTP . . . . . . . . . . . . . 8 5. Example: Opportunistic TLS in SMTP . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
Historically, Internet security protocols have emphasized The development of Opportunistic Crypto-Security (OCS) is motivated
comprehensive "all or nothing" cryptographic protection against both by the concerns raised in [RFC7258]. Pervasive monitoring (as defined
passive and active attacks. With each peer, such a protocol achieves in that RFC) is feasible because of the lack of widespread use of
either full protection or else total failure to communicate (hard encryption for confidentiality. Although the IETF has developed many
fail). As a result, operators often disable these security protocols security protocols (e.g., TLS, IPsec, SSH, ?) that employ encryption
at the first sign of trouble, degrading all communications to for confidentiality, most of them also require one-way or two-way
cleartext transmission. Protection against active attacks requires authentication. Authentication is mandated by the protocols to protect
authentication. The ability to authenticate any potential peer on against active attacks. If communicating peers are unable to meet the
the Internet requires a key management approach that works for all. authentication requirements imposed by these protocols, the result may
be no communication, or plaintext communication.
Designing and deploying a key management for the whole Internet is
for now an unsolved problem. For example, the Public Key
Infrastructure (PKI) used by the web (often called the "Web PKI") is
based on broadly trusted public certification authorities (CAs). The
Web PKI has too many trusted authorities and imposes burdens that not
all peers are willing to bear. Web PKI authentication is vulnerable
to MiTM attacks when the peer reference identifier ([RFC6125]) is
obtained indirectly over an insecure channel, perhaps via an MX or
SRV lookup. With so many certification authorities, which not
everyone is willing to trust, the communicating parties don't always
agree on a mutually trusted CA. Without a mutually trusted CA,
authentication fails, leading to communications failure. The above
issues are compounded by operational difficulties. For example, a
common problem is for site operators to forget to perform timely
renewal of expiring certificates. In interactive applications,
security warnings are all too frequent, and end-users learn to
actively ignore security problems.
DNS Security (DNSSEC [RFC4033]) can be used to leverage the global
DNS infrastructure as a distributed authentication system. DNS-Based
Authentication of Named Entities (DANE [RFC6698]) provides the
guidelines and DNS records to use the DNS as an alternative to the
Web PKI. However, at this time, DNSSEC is not sufficiently widely
adopted to allow DANE to play the role of an Internet-wide any-to-any
authentication system. Therefore, protocols that mandate
authentication for all peers cannot generally do so via DANE.
Opportunistic security protocols on the other hand, can begin to use
DANE immediately, without waiting for universal adoption.
Other authentication mechanisms have been designed that do not rely
on trusted third parties. The trust-on-first-use (TOFU)
authentication approach makes a leap of faith (LoF, [RFC4949]) by
assuming that unauthenticated public keys obtained on first contact
will likely be good enough to secure future communication. TOFU is
employed in SSH and in various certificate pinning designs. TOFU
does not protect against an attacker who can hijack the first contact
communication and requires more care from the end-user when systems
update their cryptographic keys. TOFU can make it difficult to
distinguish routine system administration from a malicious attack.
The lack of a global key management system means that for many
protocols only a minority of communications sessions can be
authenticated. When protocols only offer the choice between an
authenticated encrypted channel or no protection, the result is that
most traffic is sent in cleartext. The fact that most traffic is not
encrypted makes pervasive monitoring easier by making it cost-
effective, or at least not cost-prohibitive; see [RFC7258] for more
detail.
To reach broad adoption, it must be possible to roll out support for The ability to authenticate any potential peer on the Internet requires
unauthenticated encryption or authentication incrementally. an authentication mechanism that encompasses all such peers. No IETF
Incremental rollout on the scale of the Internet means that for some standards for authentication meet this criteria. The Public Key
considerable time security capabilities vary from peer to peer, and Infrastructure (PKI) model employed by browsers to authenticate web
therefore protection against passive and active attacks needs to be servers (often called the "Web PKI" [cite]) imposes cost and management
applied selectively peer by peer. burdens that have limited its use. The trust-on-first-use (TOFU)
authentication approach assumes that an unauthenticated public key
obtained on first contact (and retained for future use) will be good
enough to secure future communication. TOFU-based protocols, e.g., SSH
[cite] work well in enterprise environments, but were not designed to
scale for Internet-wide use.
We will use the phrase "opportunistically employed" to mean that the DNS-Based Authentication of Named Entities (DANE [RFC6698]) defines a
use of a type of protection or a security mechanism was tailored to way to distribute public keys bound to DNS names. It can provide an
the advertised capabilities of the peer. Both opportunistically alterative to the Web PKI (for other than EV certificates [cite]).
employed encryption and opportunistically employed authentication DANE should be used in conjunction with DNSSEC [RFC4033]. At time,
need to avoid deployment roadblocks and need to be designed with care DNSSEC is not sufficiently widely deployed to allow DANE to satisfy the
to "just work". Internet-wide, any-to-any authentication criteria noted above. Thus
protocols that mandate authenticated communication cannot generally
do so via DANE (at time).
To enable broader use of encryption, it must be possible to OCS provides a near-term approach to removing barriers to widespread
opportunistically employ encryption with peers that support it use of encryption, while offering a path to authenticated, encrypted
without always demanding authentication. This defends against communication in the future. The primary goal of OCS is to counter
pervasive monitoring and other passive attacks, as even attacks, consistent with the goals established in [RFC7258]. However,
unauthenticated encryption (see definition in Section 2) is OCS does not preclude offering protection against active attacks, if
preferable to cleartext. suitable authentication capabilities are available. OCS is not intended
as a substitute for authenticated, encrypted communication when such
communication is already available to peers, e.g., based on TLS, IPsec,
SSH, etc.
The opportunistic security design pattern involves stepping up from a To achieve widespread adoption, OCS must support incremental deployment.
baseline security policy compatible with all relevant peers to the Incremental deployment implies that security capabilities will vary
most secure policy compatible with the capabilities of a given peer. from peer to peer, perhaps for a very long time. Thus use of an OCS
Note, this is rather different from setting a high standard and protocol by one peer may yield communication that is unauthenticated
attempting to determine (perhaps by asking the user) whether an but encrypted, authenticated and encrypted, or plaintext. This last
exception can be made. outcome will occur if not all parties to a communication support OCS
(or if an active attack makes it appear that this is the case). OCS
protocols will attempt to establish authenticated, encrypted
communication whenever both parties are capable of such, but will
fallback to unauthenticated encrypted communication if authentication
is not possible. Fallback to plaintext communication will occur as
noted above.
The risk of active attacks should not be ignored. The opportunistic OCS protocols do not prohibit the use of local security policies. A
security design pattern recommends that protocols employ multiple security administrator may specify security policies that override
cryptographic protection levels, with encrypted transmission opportunistic security. For example, a policy might require authenticated,
accessible to most if not all peers. Protocol designers are encrypted communication, in contrast to the default OCS security policy.
encouraged to produce protocols that can securely determine which
peers support authentication, and can then establish authenticated
communication channels resistant to active attacks with those peers.
Operators must be able specify explicit security policies that The remainder of this document provides definitions of critical terms,
override opportunistic security where appropriate. enumerates the OCS design principles/guidelines, and provides an example
of an OSC design, in the context of communication between mail relays.
2. Terminology 2. Terminology
Perfect Forward Secrecy (PFS): As defined in [RFC4949]. Perfect Forward Secrecy (PFS): As defined in [RFC4949].
Man-in-the-Middle (MiTM) attack: As defined in [RFC4949]. Man-in-the-Middle (MiTM) attack: As defined in [RFC4949].
Trust on First Use (TOFU): In a protocol, TOFU typically consists of Trust on First Use (TOFU): In a protocol, TOFU calls for accepting
accepting and storing an asserted identity, without authenticating and storing a public key/credential associated with an asserted
that assertion. Subsequent communication using the cached key/ identity, without authenticating that assertion. Subsequent
credential is secure against an MiTM attack, if such an attack did communication that is authenticated using the cached key/credential
not succeed during the (vulnerable) initial communication. The is secure against an MiTM attack, if such an attack did not
succeed during the (vulnerable) initial communication. The
SSH protocol makes use of TOFU. The phrase "leap of faith" (LoF, SSH protocol makes use of TOFU. The phrase "leap of faith" (LoF,
[RFC4949]) is sometimes used as a synonym. [RFC4949]) is sometimes used as a synonym.
[note that this is still not quite correct. In an enterprise environment it
is common for the enterprise to provide an out-of-band means of verifying the
asserted identity, e.g., based on the hash of the public key.]
Authenticated encryption: Encryption using a session establishment One-way and Two-way Authentication <fill in>
method in which at least the initiator (client) authenticates the
identity of the acceptor (server). This is required to protect
against both passive and active attacks. Authenticated encryption
can be one-sided, where only the client authenticates the server.
One-sided authentication of the server by the client is the most
common deployment used with Transport Layer Security (TLS,
[RFC5246]) for "secure browsing" in which client authentication is
typically performed at another layer in the protocol.
Authenticated encryption can also be two-sided or "mutual".
Mutual authentication plays a role in mitigating active attacks
when the client and server roles change in the course of a single
session. Authenticated encryption is not synonymous with use of
AEAD [RFC5116]. AEAD algorithms can be used with either
authenticated or unauthenticated peers.
Unauthenticated Encryption: Encryption using a session establishment
method that does not authenticate the identities of the peers. In
typical usage, this means that the initiator (client) has not
verified the identity of the target (server), making MiTM attacks
possible. Unauthenticated encryption is not synonymous with non-
use of AEAD [RFC5116].
3. The Opportunistic Security Design Pattern
Opportunistic Security is a protocol design pattern that aims to
remove barriers to the widespread use of encryption on the Internet.
A related goal is broader adoption of protection against active
attacks, by enabling incremental deployment of authenticated
encryption.
The opportunistic security design pattern supports multiple
protection levels, while seeking the best protection possible.
The determination of which security mechanisms to use can vary from
case to case and depends on the properties of the protocol in which
OS is applied. In many cases, OS will result in negotiating channels
with one of the following security properties:
o No encryption (cleartext), which provides no protection against
passive or active attacks.
o Unauthenticated encryption (definition in Section 2), which
protects only against passive attacks.
o Authenticated encryption, (definition in Section 2) which protects
against both passive and active attacks.
An opportunistic security protocol first determines the capabilities
of a peer. This might include whether that peer supports
authenticated encryption, unauthenticated encryption or perhaps only
cleartext. After each peer has determined the capabilities of the
other, the most preferred common security capabilities are activated.
Peer capabilities can be advertised out-of-band or (negotiated) in-
band.
An OS protocol may elect to apply more stringent security settings
for authenticated encryption than for unauthenticated encryption.
For example, the set of enabled TLS cipher-suites might be more
restrictive when authentication is required.
Security services that "just work" are more likely to be deployed and
enabled by default. It is vital that the capabilities advertised for
an OS-compatible peer match the deployed reality. Otherwise, OS
systems will detect such a broken deployment as an active attack and
communication may fail.
This might mean that peer capabilities are further filtered to
consider only those capabilities that are sufficiently operationally
reliable, and any that work only "some of the time" are treated by an
opportunistic security protocol as "not present" or "undefined".
Opportunistic security does not start with an over-estimate of peer
capabilities only to settle for lesser protection when a peer fails
to deliver. Rather, opportunistic security sets a minimum protection
level expected of all peers, which is raised for peers that are
capable of more.
Opportunistic security protocols should provide a means to enforce
authentication for those peers for which authentication can be
expected to succeed based on information advertised by the peer via
DANE, TOFU or other means. With DANE, the advertisement that a peer
supports authentication is downgrade-resistant. What is
"opportunistic" here is the selective use of authentication for
certain peers; much in the same way as unauthenticated encryption may
be used "opportunistically" with peers capable of more than
cleartext.
Enforcement of authentication is not incompatible with opportunistic
security. If an OS-enabled peer (A) makes available authenticated
key material, e.g., via DANE, to peer (B), then B should make use of
this material to authenticate A, if B is OS-enabled and supports
DANE.
With a peer that does not advertise authentication support, to which
transmission even in cleartext is permissible, authentication (or the
lack thereof) must never downgrade encrypted communication to
cleartext. When employing opportunistic unauthenticated encryption,
any enabled by default authentication checks need to be disabled or
configured to soft-fail, allowing the unauthenticated encrypted
session to proceed.
Cleartext support is for backwards compatibility with already
deployed systems. Even when cleartext needs to be supported,
protocol designs based on opportunistic security prefer to encrypt,
employing cleartext only with peers that do not appear to be
encryption capable.
4. Opportunistic Security Design Principles 3. Opportunistic Crypto-Security Design Principles
Coexist with explicit policy: Explicit security policy preempts As noted in Section 1, OCS aims to remove barriers to the
opportunistic security. Administrators or users can elect to widespread use of encryption on the Internet. A secondary goal is
disable opportunistic security for some or all peers and set a protection against active attacks, by enabling incremental
fixed security policy not based on capabilities advertised or deployment of authenticated, encrypted communication. OCS seeks
published by the peer. Alternatively, opportunistic security to achieve the best protection possible, based on the capabilities
might be enabled only for specified peers, rather than by default. of communicating peers.
Opportunistic security never displaces or preempts explicit
policy. Some applications or data may be too sensitive to employ
opportunistic security, and more traditional security designs can
be more appropriate in such cases.
Emphasize enabling communication: The primary goal of opportunistic 1. Determine Peer Security Capabilities: An OCS protocol first
security is to enable secure communication and maximize determines the capabilities of the peer with which it is attempting
deployment. If potential peers are only capable of cleartext, to communicate. Peer capabilities may be discovered by out-of-band
then it may be acceptable to employ cleartext when encryption is or in-band means. (Inband determination implies negotiation between
not possible. If authentication is only possible for some peers, peers. Out-of-band mechanism include the use of DANE records or
then it is likely best to require authentication for only those cached keys/credentials acquired via TOFU.) The capability phase
peers and not the rest. Opportunistic security needs to be determination may indicate that the peer supports authenticated,
deployable incrementally, with each peer configured independently encrypted communication, unauthenticated encrypted communication,
by its administrator or user. Opportunistic security must not get or only plaintext communication. (Note that use of out-of-band
in the way of two peers communicating when neither advertises or capability determine, e.g., DANE or TOFU, is downgrade resistant,
negotiates security services that are not in fact available or and thus preferred over in-band negotiation techniques. The goal
that don't function correctly. of this design principle is to maximize the offered security
services on a pairwise, peer basis.
Maximize security peer by peer: Opportunistic security strives to 2. Apply Security Policy: Having determined peer security
maximize security based on the capabilities of the peers. capabilities, an OCS protocol next applies any local security polices
Communications traffic should generally be at least encrypted. in addition to the default OCS policy (see below). Local policies may
Opportunistic security protocols may refuse to communicate with require security services in addition to encryption, e.g., authentication.
peers for which higher security is expected, but for some reason A policy might restrict the set of algorithms that are employed (for encryption,
is not achieved. Advertised capabilities must match reality to authentication, integrity, etc.) The OCS default policy is simple: establish
ensure that the only condition under which there is a failure of encrypted communication if possible; authenticate the peer if the capability
communication is when one or both peers are under an active exists; revert to plaintext if encrypted communication is not possible.
attack. Reverting to plaintext merely because authentication was not possible is
inconsistent with the default policy! However, explicit, local policy
overrides the default OCS policy.
Employ PFS: Opportunistic Security should employ Perfect Forward 3. Employ Perfect Forward Secrecy: OCS protocols SHOULD employ PFS
Secrecy (PFS) to protect previously recorded encrypted to protect previously recorded encrypted communication from
communication from decryption even after a compromise of long-term decryption even after a compromise of long-term keys.
keys.
No misrepresentation of security: Unauthenticated encrypted 4. No misrepresentation of security: Unauthenticated encrypted
communication must not be misrepresented to users or in communication must not be misrepresented to users (or in
application logs of non-interactive applications as equivalent to logs) of non-interactive applications as equivalent to
communication over an authenticated encrypted channel. communication over an authenticated encrypted channel. This principle
is consistent with the goal of not encouraging use of OCS in lieu of
protocols that offer additional security services, when such protocols
can be employed successfully.
5. Example: Opportunistic TLS in SMTP 4. Example: Opportunistic TLS in SMTP
Many Message Transfer Agents (MTAs, [RFC5598]) support the STARTTLS Many Message Transfer Agents (MTAs, [RFC5598]) support the STARTTLS
([RFC3207]) ESMTP extension. MTAs acting as SMTP clients are ([RFC3207]) ESMTP extension. MTAs acting as SMTP clients are
generally willing to send email without TLS (and therefore without generally willing to send email without TLS (and therefore without
encryption), but will employ TLS (and therefore encryption) when the encryption), but will employ TLS (and therefore encryption) when the
SMTP server announces STARTTLS support. Since the initial ESMTP SMTP server announces STARTTLS support. Since the initial ESMTP
negotiation is not cryptographically protected, the STARTTLS negotiation is not cryptographically protected, the STARTTLS
advertisement is vulnerable to MiTM downgrade attacks. Further, MTAs advertisement is vulnerable to MiTM downgrade attacks. Further, MTAs
do not generally require peer authentication. Thus opportunistic TLS do not generally require peer authentication. Thus the use of STARTTLS
for SMTP only protects against passive attacks. for SMTP protects only against passive attacks.
Therefore, MTAs that implement opportunistic TLS either employ MTAs that implement STARTTLS establish either an authenticated,
unauthenticated encryption or deliver over a cleartext channel. encrypted session or deliver messages over a plaintext channel.
Recent reports from a number of large providers suggest that the Recent reports [cite?] from a number of large providers suggest
majority of SMTP email transmission on the Internet is now encrypted, that the majority of SMTP email transmission on the Internet is now
and the trend is toward increasing adoption. encrypted, and the trend is toward increasing adoption.
Not only is the STARTTLS advertisement vulnerable to active attacks, The STARTTLS advertisement is vulnerable to active attacks and
but also at present some MTAs that advertise STARTTLS exhibit various some MTAs that advertise STARTTLS exhibit various interoperability
interoperability problems in their implementations. As a result, it problems in their implementations. As a result, it is common for a
is common practice to fall back to cleartext transmission not only pair of STARTTLS-enabled MTAs to fall back to plaintext
when STARTTLS is not offered, but also when the TLS handshake fails, communication when the TLS handshake fails, or when TLS fails during
or even when TLS fails during message transmission. This is a message transmission. This is a reasonable trade-off, consistent with
reasonable trade-off, since STARTTLS protects only against passive OCS principles, since STARTTLS protects against only passive
attacks, and absent an active attack TLS failures are simply attacks; absent an active attack TLS failures are simply
interoperability problems. interoperability problems.
Some MTAs employing STARTTLS ([RFC3207]) abandon the TLS handshake Some MTAs employing STARTTLS abandon the TLS handshake when the
when the server MTA fails authentication, only to immediately deliver peer MTA fails authentication, only to immediately deliver
the same message over a cleartext connection. Other MTAs have been the same message over a plaintext connection. Other MTAs have been
observed to tolerate unverified self-signed certificates, but not observed to tolerate unverified self-signed certificates, but not
expired certificates, again falling back to cleartext. These and expired certificates, again falling back to plaintext. These and
similar implementation errors must be avoided. In either case, had similar behaviors are NOT consistent with OCS principles, since
these MTAs instead used the OS design pattern, the communication they revert to plaintext communication when authentication fails,
would still have been encrypted and therefore protected against instead of employing unauthenticated, encryption, communication.
passive attacks.
Protection against active attacks for SMTP is proposed in Protection against active attacks for SMTP is described in
[I-D.ietf-dane-smtp-with-dane]. That draft introduces the terms [I-D.ietf-dane-smtp-with-dane]. That draft introduces the terms
"Opportunistic TLS" and "Opportunistic DANE TLS", which are for now "Opportunistic TLS" and "Opportunistic DANE TLS"; this draft is
informal. consistent with the OCS design principles defined in this document.
6. Security Considerations 6. Security Considerations
Though opportunistic security potentially supports transmission in OCS supports communication that is authenticated and encrypted,
cleartext, unauthenticated encryption, or other cryptographic unauthenticated and encrypted, or plaintext. The security services
protection levels short of the strongest potentially applicable, the offered to communicating peers is not reduced by the use of OCS.
effective security for peers is not reduced. If a cryptographic This is because the default OCS policy employs the best security
capability is neither required by policy nor supported by the peer, services available based on the capabilities of the peers, and
nothing is lost by going without. Opportunistic security is strictly because local security policies take precedence over the default
stronger than the alternative of providing no security services when OCS policy. OCS is an improvement over the status quo; it provides
maximal security is not applicable. better security than the alternative of providing no security services
when authentication is not possible (and not strictly required)
Opportunistic security coexists with and is preempted by any OCS coexists with and is preempted by local, non-OCS security polices.
applicable non-opportunistic security policy. However, such non- Non-OCS policies may inhibit use of encryption when many peers cannot
opportunistic policy can be counter-productive when it demands more offer authenticated, encrypted communication. Unless authenticated,
than many peers can in fact deliver. Non-opportunistic policy should encrypted communication is necessary, non-OCS local policies of this
be used with care, lest users find it too restrictive and act to sort run counter to the goals established in [RFC7258].
disable security entirely.
7. Acknowledgements 7. Acknowledgements
I would like to thank Steve Kent. Some of the text in this document I would like to thank Steve Kent. Some of the text in this document
is based on his earlier draft. I would like to thank Dave Crocker, is based on his earlier draft. I would like to thank Dave Crocker,
Peter Duchovni, Paul Hoffman, Steve Kent, Scott Kitterman, Martin Peter Duchovni, Paul Hoffman, Scott Kitterman, Martin
Thomson, Nico Williams, Paul Wouters and Stephen Farrell for their Thomson, Nico Williams, Paul Wouters and Stephen Farrell for their
helpful suggestions and support. helpful suggestions and support.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, February 2002. Transport Layer Security", RFC 3207, February 2002.
 End of changes. 30 change blocks. 
302 lines changed or deleted 164 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35
[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]