Skip to main content

Opportunistic Security: Some Protection Most of the Time
RFC 7435

Document Type RFC - Informational (December 2014)
Was draft-dukhovni-opportunistic-security (individual in sec area)
Author Viktor Dukhovni
Last updated 2015-10-14
RFC stream Internet Engineering Task Force (IETF)
Formats
IESG Responsible AD Stephen Farrell
Send notices to (None)
RFC 7435
Network File System Version 4                                  T. Haynes
Internet-Draft                                               Hammerspace
Intended status: Standards Track                           19 March 2024
Expires: 20 September 2024

                  Add CB_LAYOUTRECLL_DEVICE to NFSv4.2
                   draft-haynes-nfsv4-recalldevice-00

Abstract

   The Parallel Network File System (pNFS) allows for the metadata
   server to use CB_LAYOUTRECALL to recall a layout from a client by
   file id or file system id or all.  It also allows the server to use
   CB_NOTIFY_DEVICEID to delete a devicid.  It does not provide a
   mechanism for the metadata server to recall all layouts that have a
   data file on a specific deviceid.  This document presents an
   extension to RFC8881 to allow the server recall layouts from clients
   based on deviceid.

Note

   This note is to be removed before publishing as an RFC.

   Discussion of this draft takes place on the NFSv4 working group
   mailing list (nfsv4@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/nfsv4/.  Working Group
   information can be found at https://datatracker.ietf.org/wg/nfsv4/
   about/.

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 https://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 20 September 2024.

Haynes                  Expires 20 September 2024               [Page 1]
Internet-Draft                RECALL_DEVICE                   March 2024

Copyright Notice

   Copyright (c) 2024 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 (https://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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Do we need RFC8435? . . . . . . . . . . . . . . . . . . .   3
     1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Extension to Operation 5: CB_LAYOUTRECALL - Recall Layout from
           Client  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Extraction of XDR . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Code Components Licensing Notice  . . . . . . . . . . . .   6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   In the Network File System version4 (NFSv4) with a Parallel NFS
   (pNFS) metadata server ([RFC8881]), there is no mechanism for the
   metadata server to recall layouts from the client for when a
   particular deviceid (see Section 3.3.14 of [RFC8881]) either
   temporarily or permanently is no longer available.

   One use case is when the deviceids in a layout are separated by power
   fault domains.  Each layout might describe 3 different devices, each
   contained in a different power fault domain.  In such a scenario, a
   single fault domain can have the power removed and not cause the loss
   of access to the data.  However, client I/O will be impacted as the
   client still has to perform WRITEs (see Section 18.32 of [RFC8881])
   to the unavailable device, send LAYOUTERRORs (see Section 15.6 of
   [RFC7862]) to inform the metadata server of NFS4ERR_NXIO (see
   Section 15.1.16.3 of [RFC8881]).

Haynes                  Expires 20 September 2024               [Page 2]
Internet-Draft                RECALL_DEVICE                   March 2024

   If the metadata sever had the means to recall layouts by deviceid, a
   lot of this unnecessary traffic could be eliminated.  Finally, while
   the metadata server could recall layouts one by one, this is again
   unnecessary traffic and can be offloaded to the client.

   Besides the use case above, consider if the metadata server wants to
   set the NOTIFY4_DEVICEID_DELETE in the CB_NOTIFY_DEVICEID callback
   (see Section 20.12 of [RFC8881]).  This flag cannot be set if a
   layout is outstanding for a deviceid.  While the metadata server can
   revoke all such layouts, there is no way to know that the client has
   acknowledged that revocation and hence is still not doing I/O to
   other data files in the layout.  The metadata server could fence
   those layouts as well (see Section 12.5.5 of [RFC8881]), but that can
   be an expensive operation.

   Using the process detailed in [RFC8178], the revisions in this
   document become an extension of NFSv4.2 [RFC7862].  They are built on
   top of the external data representation (XDR) [RFC4506] generated
   from [RFC7863].

1.1.  Do we need [RFC8435]?

   This section is to be removed before publishing as an RFC.

   The authors have tried to introduce this new functionality outside of
   a particular pNFS Layout Type.  Does that work?

1.2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Extension to Operation 5: CB_LAYOUTRECALL - Recall Layout from
    Client

   The original union layoutrecall4 (see Section 20.3.1 of [RFC8881])
   is:

Haynes                  Expires 20 September 2024               [Page 3]
quot;Block unintelligible".  The Bundle
            Deletion procedure defined in Section 5.10 MUST be followed,
            and all remaining steps of the Bundle Reception procedure
            MUST be skipped.

   Step 4:  For each block in the bundle that is an extension block that
            the BPA cannot process:

            *  If the block processing control flags in that block
               indicate that a status report is requested in this event
               and if status reporting is enabled, then a bundle
               reception status report with reason code "Block
               unsupported" SHOULD be generated, destined for the
               bundle's report-to endpoint ID.

            *  If the block processing control flags in that block
               indicate that the bundle must be deleted in this event,
               then the BPA MUST delete the bundle for the reason "Block
               unsupported"; the Bundle Deletion procedure defined in
               Section 5.10 MUST be followed, and all remaining steps of
               the Bundle Reception procedure MUST be skipped.

            *  If the block processing control flags in that block do
               *NOT* indicate that the bundle must be deleted in this
               event but do indicate that the block must be discarded,
               then the BPA MUST remove this block from the bundle.

            *  If the block processing control flags in that block
               neither indicate that the bundle must be deleted nor
               indicate that the block must be discarded, then
               processing continues with the next extension block that
               the BPA cannot process, if any; otherwise, processing
               proceeds from Step 5.

   Step 5:  Processing proceeds from Step 1 of Section 5.3.

5.7.  Local Bundle Delivery

   The steps in processing a bundle that is destined for an endpoint of
   which this node is a member are as follows:

   Step 1:  If the received bundle is a fragment, the ADU Reassembly
            procedure described in Section 5.9 MUST be followed.  If
            this procedure results in reassembly of the entire original
            ADU, processing of the fragmentary bundle whose payload has
            been replaced by the reassembled ADU (whether this bundle or
            a previously received fragment) proceeds from Step 2;
            otherwise, the retention constraint "Reassembly pending"
            MUST be added to the bundle, and all remaining steps of this
            procedure MUST be skipped.

   Step 2:  Delivery depends on the state of the registration whose
            endpoint ID matches that of the destination of the bundle:

            *  An additional implementation-specific delivery deferral
               procedure MAY optionally be associated with the
               registration.

            *  If the registration is in the Active state, then the
               bundle MUST be delivered automatically as soon as it is
               the next bundle that is due for delivery according to the
               BPA's bundle delivery scheduling policy (an
               implementation matter).

            *  If the registration is in the Passive state, or if
               delivery of the bundle fails for some implementation-
               specific reason, then the registration's delivery failure
               action MUST be taken.  The delivery failure action MUST
               be one of the following:

               -  Defer delivery of the bundle subject to this
                  registration until (a) this bundle is the least
                  recently received of all bundles currently deliverable
                  subject to this registration and (b) either the
                  registration is polled or the registration is in the
                  Active state, and also perform any additional delivery
                  deferral procedure associated with the registration,
                  or

               -  Abandon delivery of the bundle subject to this
                  registration (as defined in Section 3.1).

   Step 3:  As soon as the bundle has been delivered, if the "request
            reporting of bundle delivery" flag in the bundle's status
            report request field is set to 1 and bundle status reporting
            is enabled, then a bundle delivery status report SHOULD be
            generated, destined for the bundle's report-to endpoint ID.
            Note that this status report only states that the payload
            has been delivered to the application agent, not that the
            application agent has processed that payload.

5.8.  Bundle Fragmentation

   It may at times be advantageous for BPAs to reduce the sizes of
   bundles in order to forward them.  This might be the case, for
   example, if a node to which a bundle is to be forwarded is accessible
   only via intermittent contacts and no upcoming contact is long enough
   to enable the forwarding of the entire bundle.

   The size of a bundle can be reduced by "fragmenting" the bundle.  To
   fragment a bundle whose payload is of size M is to replace it with
   two "fragments" -- new bundles with the same source node ID and
   creation timestamp as the original bundle -- whose payloads MUST be
   the first N and the last (M - N) bytes of the original bundle's
   payload, where 0 < N < M.

   Note that fragments are bundles and therefore may themselves be
   fragmented, so multiple episodes of fragmentation may in effect
   replace the original bundle with more than two fragments.  (However,
   there is only one "level" of fragmentation, as in IP fragmentation.)

   Any bundle whose primary block's bundle processing control flags do
   *NOT* indicate that it must not be fragmented MAY be fragmented at
   any time, for any purpose, at the discretion of the BPA.  *NOTE*,
   however, that some combinations of bundle fragmentation, replication,
   and routing might result in unexpected traffic patterns.

   Fragmentation SHALL be constrained as follows:

   *  The concatenation of the payloads of all fragments produced by
      fragmentation MUST always be identical to the payload of the
      fragmented bundle (that is, the bundle that is being fragmented).
      Note that the payloads of fragments resulting from different
      fragmentation episodes, in different parts of the network, may be
      overlapping subsets of the fragmented bundle's payload.

   *  The primary block of each fragment MUST differ from that of the
      fragmented bundle, in that the bundle processing control flags of
      the fragment MUST indicate that the bundle is a fragment and both
      fragment offset and total application data unit length must be
      provided.  Additionally, the CRC of the primary block of the
      fragmented bundle, if any, MUST be replaced in each fragment by a
      new CRC computed for the primary block of that fragment.

   *  The payload blocks of fragments will differ from that of the
      fragmented bundle as noted above.

   *  If the fragmented bundle is not a fragment or is the fragment with
      offset zero, then all extension blocks of the fragmented bundle
      MUST be replicated in the fragment whose offset is zero.

   *  Each of the fragmented bundle's extension blocks whose "Block must
      be replicated in every fragment" flag is set to 1 MUST be
      replicated in every fragment.

   *  Beyond these rules, rules for the replication of extension blocks
      in the fragments must be defined in the specifications for those
      extension block types.

5.9.  Application Data Unit Reassembly

   Note that the Bundle Fragmentation procedure described in Section 5.8
   may result in the replacement of a single original bundle with an
   arbitrarily large number of fragmentary bundles.  In order to be
   delivered at a destination node, the original bundle's payload must
   be reassembled from the payloads of those fragments.

   The "material extents" of a received fragment's payload are all
   continuous sequences of bytes in that payload that do not overlap
   with the material extents of the payloads of any previously received
   fragments with the same source node ID and creation timestamp.  If
   the concatenation -- as informed by fragment offsets and payload
   lengths -- of the material extents of the payloads of this fragment
   and all previously received fragments with the same source node ID
   and creation timestamp as this fragment forms a continuous byte array
   whose length is equal to the total application data unit length noted
   in the fragment's primary block, then:

   *  This byte array -- the reassembled ADU -- MUST replace the payload
      of that fragment whose material extents include the extent at
      offset zero.  Note that this will enable delivery of the
      reconstituted original bundle as described in Step 1 of
      Section 5.7.

   *  The "Reassembly pending" retention constraint MUST be removed from
      every other fragment with the same source node ID and creation
      timestamp as this fragment.

   Note: Reassembly of ADUs from fragments occurs at the nodes that are
   members of destination endpoints as necessary; an ADU MAY also be
   reassembled at some other node on the path to the destination.

5.10.  Bundle Deletion

   The steps in deleting a bundle are as follows:

   Step 1:  If the "request reporting of bundle deletion" flag in the
            bundle's status report request field is set to 1 and if
            status reporting is enabled, then a bundle deletion status
            report citing the reason for deletion SHOULD be generated,
            destined for the bundle's report-to endpoint ID.

   Step 2:  All of the bundle's retention constraints MUST be removed.

5.11.  Discarding a Bundle

   As soon as a bundle has no remaining retention constraints, it MAY be
   discarded, thereby releasing any persistent storage that may have
   been allocated to it.

5.12.  Canceling a Transmission

   When requested to cancel a specified transmission, where the bundle
   created upon initiation of the indicated transmission has not yet
   been discarded, the BPA MUST delete that bundle for the reason
   "Transmission canceled".  For this purpose, the procedure defined in
   Section 5.10 MUST be followed.

6.  Administrative Record Processing

6.1.  Administrative Records

   Administrative records are standard ADUs that are used in providing
   some of the features of the Bundle Protocol.  Bundle Protocol
   administrative record types are registered in the IANA "Bundle
   Administrative Record Types" registry [RFC5050]; of these, only
   administrative record type 1, "Bundle status report", is defined for
   BPv7 at this time.  Note that additional types of administrative
   records may be defined by supplementary DTN protocol specification
   documents.

   Every administrative record consists of:

   *  A record type code (an unsigned integer for which valid values are
      as defined below).

   *  Record content in type-specific format.

   Each BP administrative record SHALL be represented as a CBOR array
   comprising two items.

   The first item of the array SHALL be a record type code, which SHALL
   be represented as a CBOR unsigned integer.

   The second element of this array SHALL be the applicable CBOR
   encoding of the content of the record.  Details of the CBOR encoding
   of administrative record type 1 are provided below.  Details of the
   CBOR encoding of other types of administrative records are included
   in the specifications defining those records.

6.1.1.  Bundle Status Reports

   The transmission of "bundle status reports" under specified
   conditions is an option that can be invoked when transmission of a
   bundle is requested.  These reports are intended to provide
   information about how bundles are progressing through the system,
   including notices of receipt, forwarding, final delivery, and
   deletion.  They are transmitted to the report-to endpoints of
   bundles.

   Each bundle status report SHALL be represented as a CBOR array.  The
   number of elements in the array SHALL be either 6 (if the subject
   bundle is a fragment) or 4 (otherwise).

   The first element of the bundle status report SHALL be bundle status
   information represented as a CBOR array of at least four elements.
   The first four elements of the bundle status information shall
   provide information on the following four status assertions, in this
   order:

   *  Reporting node received bundle.

   *  Reporting node forwarded the bundle.

   *  Reporting node delivered the bundle.

   *  Reporting node deleted the bundle.

   Each element of the bundle status information SHALL be a bundle
   status item encoded as a CBOR array.

   The number of elements in each bundle status item SHALL be either 2
   (if the value of the first element of the bundle status item is 1 AND
   the "Report status time"undefined".

   With unauthenticated, encrypted communication, OS protocols may
   employ more liberal settings than would be best practice when
   security is mandated by policy.  Some legacy systems support
   encryption, but implement only outdated algorithms or protocol
   versions.  Compatibility with these systems avoids the need to resort
   to cleartext fallback.

   For greater assurance of channel security, an OS protocol may enforce
   more stringent cryptographic parameters when the session is
   authenticated.  For example, the set of enabled Transport Layer
   Security (TLS) [RFC5246] cipher suites might exclude deprecated
   algorithms that would be tolerated with unauthenticated, encrypted
   communication.

   OS protocols should produce authenticated, encrypted communication
   when authentication of the peer is "expected".  Here, "expected"
   means a determination via a downgrade-resistant method that
   authentication of that peer is expected to work.  Downgrade-resistant
   methods include: validated DANE DNS records, existing TOFU identity
   information, and manual configuration.  Such use of authentication is
   "opportunistic", in that it is performed when possible, on a per-
   session basis.

   When communicating with a peer that supports encryption but not
   authentication, any authentication checks enabled by default must be
   disabled or configured to soft-fail in order to avoid unnecessary
   communications failure or needless downgrade to cleartext.

   The support of cleartext and the use of outdated algorithms, and
   especially broken algorithms, is for backwards compatibility with
   systems already deployed.  Protocol designs based on Opportunistic
   Security prefer to encrypt and prefer to use the best available
   encryption algorithms available.  OS protocols employ cleartext or
   broken encryption algorithms only with peers that do not appear to be
   capable of doing otherwise.  The eventual desire is to transition
   away from cleartext and broken algorithms, and particularly for
   broken algorithms, it is highly desirable to remove such
   functionality from implementations.

Dukhovni                      Informational                     [Page 7]
RFC 7435                 Opportunistic Security            December 2014

4.  Example: Opportunistic TLS in SMTP

   Most Message Transfer Agents (MTAs) [RFC5598] support the STARTTLS
   [RFC3207] ESMTP extension.  MTAs acting as SMTP [RFC5321] clients
   generally support cleartext transmission of email.  They negotiate
   TLS encryption when the SMTP server announces STARTTLS support.
   Since the initial ESMTP negotiation is not cryptographically
   protected, the STARTTLS advertisement is vulnerable to MiTM downgrade
   attacks.

   Recent reports from a number of large providers (e.g., [fb-starttls]
   and [goog-starttls]) suggest that the majority of SMTP email
   transmission on the Internet is now encrypted, and the trend is
   toward increasing adoption.

   Various MTAs that advertise STARTTLS exhibit interoperability
   problems in their implementations.  As a work-around, it is common
   for a client MTA to fall back to cleartext when the TLS handshake
   fails, or when TLS fails during message transmission.  This is a
   reasonable trade-off, since STARTTLS only protects against passive
   attacks.  In the absence of an active attack, TLS failures are
   generally one of the known interoperability problems.

   Some client MTAs employing STARTTLS abandon the TLS handshake when
   the server MTA fails authentication and immediately start a cleartext
   connection.  Other MTAs have been observed to accept unverified self-
   signed certificates, but not expired certificates; again falling back
   to cleartext.  These and similar behaviors are NOT consistent with OS
   principles, since they needlessly fall back to cleartext when
   encryption is clearly possible.

   Protection against active attacks for SMTP is described in
   [SMTP-DANE].  That document introduces the terms "Opportunistic TLS"
   and "Opportunistic DANE TLS", and is consistent with the OS design
   principles defined in this document.  With "Opportunistic DANE TLS",
   authenticated, encrypted communication is enforced with peers for
   which appropriate DANE records are present.  For the remaining peers,
   "Opportunistic TLS" is employed as before.

5.  Operational Considerations

   OS protocol designs should minimize the possibility of failure of
   negotiated security mechanisms.  OS protocols may need to employ
   "fallback", to work-around a failure of a security mechanisms that is
   found in practice to encounter interoperability problems.  The choice
   to implement or enable fallback should only be made in response to
   significant operational obstacles.

Dukhovni                      Informational                     [Page 8]
RFC 7435                 Opportunistic Security            December 2014

   When protection only against passive attacks is negotiated over a
   channel vulnerable to active downgrade attacks and the use of
   encryption fails, a protocol might elect non-intrusive fallback to
   cleartext.  Failure to encrypt may be more often a symptom of an
   interoperability problem than an active attack.  In such a situation,
   occasional fallback to cleartext may serve the greater good.  Even
   though some traffic is sent in the clear, the alternative is to ask
   the administrator or user to manually work-around such
   interoperability problems.  If the incidence of such problems is non-
   negligible, the user or administrator might find it more expedient to
   just disable Opportunistic Security.

6.  Security Considerations

   OS supports communication that is authenticated and encrypted,
   unauthenticated and encrypted, or cleartext.  And yet the security
   provided to communicating peers is not reduced by the use of OS
   because the default OS policy employs the best security services
   available based on the capabilities of the peers, and because
   explicit security policies take precedence over the default OS
   policy.  OS is an improvement over the status quo; it provides better
   security than the alternative of providing no security services when
   authentication is not possible (and not strictly required).

   While the use of OS is preempted by a non-OS explicit policy, such a
   non-OS policy can be counter-productive when it demands more than
   many peers can in fact deliver.  A non-OS policy should be used with
   care, lest users find it too restrictive and act to disable security
   entirely.

   When protocols follow the OS approach, attackers engaged in large-
   scale passive monitoring can no longer just collect everything, and
   have to be more selective and/or mount more active attacks.  In
   addition, OS means active attacks on everyone all the time are much
   more likely to be noticed.

   Specific techniques for detection and mitigation of active attacks in
   the absence of authentication are out of scope for this document.
   Some existing protocols that could support OS may be vulnerable to
   relatively low-cost downgrade attacks for attackers on the path.
   However, when such attacks are employed pervasively in order to
   facilitate, for example, surveillance, this is often detectable;
   hence, even in such scenarios, OS protocols provide a positive
   benefit.

   Protocols following the OS approach may need to define additional
   measures to make systematic downgrades less likely to succeed or more
   likely to be detected.  When we have more experience in this space,

Dukhovni                      Informational                     [Page 9]
RFC 7435                 Opportunistic Security            December 2014

   future revisions of this or related documents may be able to make
   more generally applicable recommendations.

7.  References

7.1.  Normative References

   [RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
              Transport Layer Security", RFC 3207, February 2002,
              <http://www.rfc-editor.org/info/rfc3207>.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements", RFC
              4033, March 2005,
              <http://www.rfc-editor.org/info/rfc4033>.

   [RFC4251]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
              Protocol Architecture", RFC 4251, January 2006,
              <http://www.rfc-editor.org/info/rfc4251>.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2", RFC
              4949, August 2007,
              <http://www.rfc-editor.org/info/rfc4949>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008,
              <http://www.rfc-editor.org/info/rfc5246>.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              October 2008, <http://www.rfc-editor.org/info/rfc5321>.

   [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
              of Named Entities (DANE) Transport Layer Security (TLS)
              Protocol: TLSA", RFC 6698, August 2012,
              <http://www.rfc-editor.org/info/rfc6698>.

7.2.  Informative References

   [RFC5598]  Crocker, D., "Internet Mail Architecture", RFC 5598, July
              2009, <http://www.rfc-editor.org/info/rfc5598>.

   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
              Attack", BCP 188, RFC 7258, May 2014,
              <http://www.rfc-editor.org/info/rfc7258>.

Dukhovni                      Informational                    [Page 10]
RFC 7435                 Opportunistic Security            December 2014

   [SMTP-DANE]
              Dukhovni, V. and W. Hardaker, "SMTP security via
              opportunistic DANE TLS", Work in Progress, draft-ietf-
              dane-smtp-with-dane-13, October 2014.

   [fb-starttls]
              Facebook, "The Current State of SMTP STARTTLS Deployment",
              May 2014, <https://www.facebook.com/notes/protect-the-
              graph/the-current-state-of-smtp-starttls-deployment/
              1453015901605223>.

   [goog-starttls]
              Google, "Safer email - Transparency Report - Google", June
              2014, <https://www.google.com/transparencyreport/
              saferemail/>.

Acknowledgements

   I would like to thank Dave Crocker, Peter Duchovni, Paul Hoffman,
   Benjamin Kaduk, Steve Kent, Scott Kitterman, Pete Resnick, Martin
   Thomson, Nico Williams, Paul Wouters, and Stephen Farrell for their
   many helpful suggestions and support.

Author's Address

   Viktor Dukhovni
   Two Sigma

   EMail: ietf-dane@dukhovni.org

Dukhovni                      Informational                    [Page 11]
Internet-Draft                RECALL_DEVICE                   March 2024