idnits 2.17.1 draft-fenton-smtp-require-tls-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 13, 2017) is 2628 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'MailParams' -- Possible downref: Non-RFC (?) normative reference: ref. 'SMTPStatusCodes' == Outdated reference: A later version (-21) exists of draft-ietf-uta-mta-sts-02 -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Fenton 3 Internet-Draft Altmode Networks 4 Intended status: Standards Track February 13, 2017 5 Expires: August 17, 2017 7 SMTP Require TLS Option 8 draft-fenton-smtp-require-tls-03 10 Abstract 12 The SMTP STARTTLS option, used in negotiating transport-level 13 encryption of SMTP connections, is not as useful from a security 14 standpoint as it might be because of its opportunistic nature; 15 message delivery is prioritized over security. This document 16 describes a complementary SMTP service extension, REQUIRETLS. If the 17 REQUIRETLS option is used when sending a message, it asserts a 18 request on the part of the message sender to override the default 19 negotiation of TLS, either by requiring that TLS be negotiated when 20 the message is relayed, or by requesting that policy mechanisms such 21 as SMTP STS and DANE be ignored when relaying a high priority 22 message. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 17, 2017. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 2. The REQUIRETLS Service Extension . . . . . . . . . . . . . . 3 61 3. REQUIRETLS Semantics . . . . . . . . . . . . . . . . . . . . 5 62 3.1. REQUIRETLS Receipt Requirements . . . . . . . . . . . . . 5 63 3.2. REQUIRETLS Sender Requirements . . . . . . . . . . . . . 5 64 3.2.1. Sending with TLS Required . . . . . . . . . . . . . . 5 65 3.2.2. Sending with TLS Optional . . . . . . . . . . . . . . 6 66 3.3. REQUIRETLS Submission . . . . . . . . . . . . . . . . . . 7 67 3.4. Delivery of REQUIRETLS messages . . . . . . . . . . . . . 7 68 4. Non-delivery message handling . . . . . . . . . . . . . . . . 7 69 5. Mailing list considerations . . . . . . . . . . . . . . . . . 8 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 7.1. Passive attacks . . . . . . . . . . . . . . . . . . . . . 9 73 7.2. Active attacks . . . . . . . . . . . . . . . . . . . . . 9 74 7.3. Bad Actor MTAs . . . . . . . . . . . . . . . . . . . . . 9 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 76 9. Revision History . . . . . . . . . . . . . . . . . . . . . . 10 77 9.1. Changes Since -02 Draft . . . . . . . . . . . . . . . . . 10 78 9.2. Changes Since -01 Draft . . . . . . . . . . . . . . . . . 10 79 9.3. Changes Since -00 Draft . . . . . . . . . . . . . . . . . 10 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 82 10.2. Informative References . . . . . . . . . . . . . . . . . 12 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 85 1. Introduction 87 The SMTP [RFC5321] STARTTLS service extension [RFC3207] provides a 88 means by which an SMTP server and client can establish a Transport 89 Layer Security (TLS) protected session for the transmission of email 90 messages. By default, TLS is used only upon mutual agreement 91 (successful negotiation) of STARTTLS between the client and server; 92 if this is not possible, the message is sent without transport 93 encryption. Furthermore, it is common practice for the client to 94 negotiate TLS even if the SMTP server's certificate fails to 95 authenticate it. 97 Policy mechanisms such as DANE [RFC7672] and SMTP STS 98 [I-D.ietf-uta-mta-sts] may impose requirements for the use of TLS for 99 email destined for some domains. However, such policies do not allow 100 the sender to specify which messages are more sensitive and require 101 transport-level encryption, and which ones are urgent and ought to be 102 relayed even if TLS cannot be negotiated successfully. 104 The default opportunistic nature of SMTP TLS enables several "on the 105 wire" attacks on SMTP security between MTAs. These include passive 106 eavesdropping on connections for which TLS is not used, interference 107 in the SMTP protocol to prevent TLS from being negotiated (presumably 108 followed by eavesdropping), and insertion of a man-in-the-middle 109 attacker taking advantage of the lack of server authentication by the 110 client. Attacks are more described in more detail in the Security 111 Considerations section of this document. 113 The REQUIRETLS SMTP service extension allows the SMTP client to 114 specify that a given message sent during a particular session MUST be 115 sent over a TLS protected session with specified security 116 characteristics, or conversely that delivery should be prioritized 117 over ability to negotiate TLS. For messages requiring TLS 118 negotiation, it also requires that the SMTP server advertise that it 119 also supports REQUIRETLS, in effect promising that it will honor the 120 requirement to require TLS transmission and REQUIRETLS support for 121 onward transmission of messages specifying that requirement. 123 1.1. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 2. The REQUIRETLS Service Extension 131 1. The textual name of the extension is "Require TLS". 133 2. The EHLO keyword value associated with this extension is 134 "REQUIRETLS". 136 3. One MAIL FROM option is defined by this extension. 138 4. Two new SMTP status codes are defined by this extension to convey 139 error conditions resulting from failure of the client to 140 negotiate a TLS connection with the required security and as a 141 result of an attempt to send to a server not also supporting the 142 REQUIRETLS extension. 144 In order to specify REQUIRETLS treatment for a given message, the 145 REQUIRETLS option is specified on the MAIL FROM command when that 146 message is transmitted. With the exception of REQUIRETLS=NO 147 (described below), this option MUST only be specified in the context 148 of an SMTP session meeting the security requirements that have been 149 specified: 151 o The session itself MUST employ TLS transmission, unless the NO 152 parameter is specified. 154 o Any server authentication requirements specified as an option to 155 the REQUIRETLS option (see below) MUST have been satisfied in 156 establishing the current session. 158 An optional parameter to the REQUIRETLS MAIL FROM option specifies 159 the requirements for server authentication that MUST be used for any 160 onward transmission of the following message. The parameter takes 161 the form of either a single value or comma-separated list, separated 162 from the REQUIRETLS option by a single "=" (equals-sign) character. 163 If present, the parameter MUST take one or more of the following 164 values: 166 o CHAIN - The certificate presented by the SMTP server MUST verify 167 successfully in a trust chain leading to a certificate trusted by 168 the SMTP client. The choice of trusted (root) certificates by the 169 client is at their own discretion. The client MAY choose to use 170 the certificate set maintained by the CA/B forum [citation needed] 171 for this purpose. 173 o DANE - The certificate presented by the SMTP server MUST verify 174 succesfully using DANE as specified in RFC 7672 [RFC7672]. 176 o DNSSEC - The server MUST confirm that any MX record or CNAME 177 lookup used to locate the SMTP server must be DNSSEC [RFC4035] 178 signed and valid. 180 o NO - The SMTP client SHOULD attempt to send the message regardless 181 of its ability to negotiate STARTTLS with the SMTP server, 182 ignoring policy-based mechanisms, if any, asserted by the 183 recipient domain. Nevertheless, the client MAY negotiate STARTTLS 184 with the server if available. If the NO parameter is present, any 185 other REQUIRETLS parameter MUST NOT be used. 187 The CHAIN and DANE parameters are additive; if both are specified, 188 either method of certificate validation is acceptable. If neither 189 CHAIN nor DANE is specified, the certificate presented by the SMTP 190 server is not required to be verified. 192 3. REQUIRETLS Semantics 194 3.1. REQUIRETLS Receipt Requirements 196 Upon receipt of the REQUIRETLS option on a MAIL FROM command during 197 the receipt of a message, an SMTP server MUST tag that message as 198 needing REQUIRETLS handling with the specified option(s). The manner 199 in which this tagging takes place is implementation-dependent. If 200 the message is being locally aliased and redistributed to multiple 201 addresses, all instances of the message MUST be tagged in the same 202 manner. 204 3.2. REQUIRETLS Sender Requirements 206 3.2.1. Sending with TLS Required 208 When sending a message tagged with REQUIRETLS other than the 209 REQUIRETLS=NO option, the sending (client) MTA MUST: 211 1. Look up the SMTP server to which the message is to be sent. If 212 the DNSSEC option is included in the message tag, the MX record 213 lookups in this process MUST use DNSSEC verification and the 214 response(s) MUST be DNSSEC-signed in order to ensure the 215 integrity of the resource identifier [RFC6125] used to 216 authenticate the SMTP server. 218 2. Open an SMTP session with the peer SMTP server using the EHLO 219 verb. The server MUST advertise the REQUIRETLS capability. 221 3. Establish a TLS-protected SMTP session with its peer SMTP server 222 and authenticate the server's certificate with the specified 223 authentication method. 225 4. The SMTP client SHOULD also require that meaningfully secure 226 cipher algorithms and key lengths be negotiated with the server. 227 The choices of key lengths and algorithms change over time, so a 228 specific requirement is not presented here. 230 If any of the above steps fail, the client SHOULD issue a QUIT to the 231 server and repeat steps 2-4 with each host on the recipient domain's 232 list of MX hosts in an attempt to find a mail path that meets the 233 sender's requirements. If there are no more MX hosts or if the MX 234 record lookup is not DNSSEC-protected and DNSSEC verification is 235 required, the client MUST NOT transmit the message and MUST issue an 236 SMTP QUIT command to the server. The client MAY send other, 237 unprotected, messages to that server prior to issuing the QUIT if it 238 has any. 240 Following such a failure, the SMTP client MUST send a non-delivery 241 notification to the reverse-path of the failed message as described 242 in section 3.6 of [RFC5321]. The following status codes [RFC5248] 243 SHOULD be used: 245 o DNSSEC lookup failure: 5.x.x DNSSEC lookup required 247 o REQUIRETLS not supported by server: 5.7.x REQUIRETLS needed 249 o Unable to establish TLS-protected SMTP session: 5.7.10 Encryption 250 needed 252 Refer to Section 4. for further requirements regarding non-delivery 253 messages. 255 If all REQUIRETLS requirements have been met, transmit the message, 256 issuing the REQUIRETLS option on the MAIL FROM command with the 257 required option(s), if any. 259 3.2.2. Sending with TLS Optional 261 Messages tagged REQUIRETLS=NO are handled differently from other 262 REQUIRETLS messages, as follows. When sending a message tagged with 263 REQUIRETLS=NO, the sending (client) MTA MUST: 265 o Look up the SMTP server to which the message is to be sent as 266 described in [RFC5321]. 268 o Open an SMTP session with the peer SMTP server using the EHLO 269 verb. Attempt to negotiate STARTTLS if possible, and follow any 270 policy published by the recipient domain, but do not fail if this 271 is unsuccessful. 273 o If the server does not advertise the REQUIRETLS capability, send 274 the message in the usual manner (without the REQUIRETLS option, 275 because the server will not understand the option). 277 o If the server advertises the REQUIRETLS capability, send the 278 message with the REQUIRETLS=NO option. 280 Some SMTP servers that are configured to expect STARTTLS connections 281 as a matter of policy may not accept messages in the absence of 282 STARTTLS. This MUST be expected, and a non-delivery notification 283 returned to the sender. 285 Messages tagged with the REQUIRETLS=NO option will be sent without 286 the option to SMTP servers not supporting REQUIRETLS. REQUIRETLS=NO 287 MAY therefore not persist through multiple email relay hops. 289 3.3. REQUIRETLS Submission 291 An MUA or other agent making the initial introduction of a message to 292 SMTP has authority to decide whether to require TLS, and if so, using 293 what authentication method(s). It does so by issuing the REQUIRETLS 294 option in the MAIL FROM command during message submission. This MAY 295 be done based on a user interface selection, on a header field 296 included in the message, or based on policy. The manner in which the 297 decision to require TLS is made is implementation-dependent and is 298 beyond the scope of this specification. 300 3.4. Delivery of REQUIRETLS messages 302 Messages are usually retrieved by end users using protocols other 303 than SMTP such as IMAP [RFC3501], POP [RFC1939], or web mail systems. 304 Mail delivery agents supporting REQUIRETLS SHOULD require that 305 retrieval of messages requiring transport encryption take place over 306 authenticated, encrypted channels. 308 4. Non-delivery message handling 310 Non-delivery ("bounce") messages usually contain important metadata 311 about the message to which they refer, including the original message 312 header. They therefore MUST be protected in the same manner as the 313 original message. All non-delivery messages, whether resulting from 314 a REQUIRETLS error or some other, MUST employ REQUIRETLS using the 315 same authentication method(s) as the message that caused the error to 316 occur. 318 It should be noted that the path from the origination of an error 319 bounce message back to the MAIL FROM address may not share the same 320 REQUIRETLS support as the forward path. Therefore, users of 321 REQUIRETLS (other than REQUIRETLS=NO) are advised to make sure that 322 they are capable of receiving mail using REQUIRETLS at the same 323 authentication method(s) as messages they send. Otherwise, such non- 324 delivery messages will be lost. 326 If unable to send a bounce message due to a REQUIRETLS failure (the 327 return path not supporting the TLS requirements in the original 328 message), the MTA sending the bounce message MAY send a redacted non- 329 delivery message to the postmaster of the domain identified in the 330 envelope-From address identifying the message only by Message-ID and 331 indicating the type of failure. The original From, Return-path, To, 332 Sender, Cc, and related header fields MUST NOT be included in this 333 message. 335 Senders of messages specifying REQUIRETLS (other than REQUIRETLS=NO) 336 are advised to consider the increased likelihood that bounce messages 337 will be lost as a result of REQUIRETLS return path failure. 339 5. Mailing list considerations 341 Mailing lists, upon receipt of a message, originate new messages to 342 list addresses, as distinct from an aliasing operation that redirects 343 the original message, in some cases to multiple recipients. The 344 requirement to preserve the REQUIRETLS tag and options therefore does 345 not extend to mailing lists. REQUIRETLS users SHOULD use caution 346 when sending to mailing lists and MUST NOT assume that REQUIRETLS 347 applies to messages from the list operator to list members. 349 Mailing list operators MAY apply REQUIRETLS requirements in incoming 350 messages to the resulting messages they originate. If this is done, 351 they SHOULD also apply these requirements to administrative traffic, 352 such as messages to moderators requesting approval of messages. 354 6. IANA Considerations 356 If published as an RFC, this draft requests the addition of the 357 keyword REQUIRETLS to the SMTP Service Extensions Registry 358 [MailParams]. 360 If published as an RFC, this draft also requests the creation of a 361 registry, REQUIRETLS Security Requirements, to be initially populated 362 with the CHAIN, DANE, DNSSEC, and NO keywords. 364 If published as an RFC, this draft requests the addition of an entry 365 to the Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes 366 Registry [SMTPStatusCodes] in the 5.7.YYY range to indicate lack of 367 REQUIRETLS support by an SMTP server to which a message is being 368 routed. 370 This section is to be removed during conversion into an RFC by the 371 RFC Editor. 373 7. Security Considerations 375 The purpose of REQUIRETLS is to improve communications security for 376 email by giving the originator of a message an expectation that it 377 will be transmitted in an encrypted form "over the wire". When used, 378 REQUIRETLS changes the traditional behavior of email transmission, 379 which favors delivery over the ability to send email messages using 380 transport-layer security, to one in which requested security takes 381 precedence over delivery and domain-level policy. 383 The following considerations apply to STARTTLS other than the 384 STARTTLS=NO option, since messages specifying that option are 385 specifying less concern with transport security. 387 7.1. Passive attacks 389 REQUIRETLS is generally effective against passive attackers who are 390 merely trying to eavesdrop on an SMTP exchange between an SMTP client 391 and server. This assumes, of course, the cryptographic integrity of 392 the TLS connection being used. 394 7.2. Active attacks 396 Active attacks against TLS encrypted SMTP connections can take many 397 forms. One such attack is to interfere in the negotiation by 398 changing the STARTTLS command to something illegal such as XXXXXXXX. 399 This causes TLS negotiation to fail and messages to be sent in the 400 clear, where they can be intercepted. REQUIRETLS detects the failure 401 of STARTTLS and declines to send the message rather than send it 402 insecurely. 404 A second form of attack is a man-in-the-middle attack where the 405 attacker terminates the TLS connection rather than the intended SMTP 406 server. This is possible when, as is commonly the case, the SMTP 407 client either does not verify the server's certificate or establishes 408 the connection even when the verification fails. The REQUIRETLS 409 CHAIN and DANE options allow the message sender to specify that 410 successful certificate validation, using either or both of two 411 different methods, is required before sending the message. 413 Another active attack involves the spoofing of DNS MX records of the 414 recipient domain. An attacker having this capability could cause the 415 message to be redirected to a mail server under the attacker's own 416 control, which would presumably have a valid certificate. The 417 REQUIRETLS DNSSEC option allows the message sender to require that 418 valid DNSSEC [RFC4033] signatures be obtained when locating the 419 recipient's mail server, in order to address that attack. 421 In addition to support of the DNSSEC option, domains receiving email 422 SHOULD deploy DNSSEC and SMTP clients SHOULD deploy DNSSEC 423 verification. 425 7.3. Bad Actor MTAs 427 A bad-actor MTA along the message transmission path could 428 misrepresent its support of REQUIRETLS and/or actively strip 429 REQUIRETLS tags from messages it handles. However, since 430 intermediate MTAs are already trusted with the cleartext of messages 431 they handle, and are not part of the threat model for transport-layer 432 security, they are also not part of the threat model for REQUIRETLS. 434 It should be reemphasized that since SMTP TLS is a transport-layer 435 security protocol, messages sent using REQUIRETLS are not encrypted 436 end-to-end and are visible to MTAs that are part of the message 437 delivery path. Messages containing sensitive information that MTAs 438 should not have access to MUST be sent using end-to-end content 439 encryption such as OpenPGP [RFC4880] or S/MIME [RFC5751]. 441 8. Acknowledgements 443 The author would like to acknowledge many helpful suggestions on the 444 ietf-smtp and uta mailing lists, in particular those of Viktor 445 Dukhovni, Tony Finch, Jeremy Harris, Arvel Hathcock, John Klensin, 446 John Levine, Rolf Sonneveld, and Per Thorsheim. 448 9. Revision History 450 To be removed by RFC Editor upon publication as an RFC. 452 9.1. Changes Since -02 Draft 454 o Incorporation of "MAY TLS" functionality as REQUIRETLS=NO per 455 suggestion on UTA WG mailing list. 457 o Additional guidance on bounce messages 459 9.2. Changes Since -01 Draft 461 o Specified retries when multiple MX hosts exist for a given domain. 463 o Clarified generation of non-delivery messages 465 o Specified requirements for application of REQUIRETLS to mail 466 forwarders and mailing lists. 468 o Clarified DNSSEC requirements to include MX lookup only. 470 o Corrected terminology regarding message retrieval vs. delivery. 472 o Changed category to standards track. 474 9.3. Changes Since -00 Draft 476 o Conversion of REQUIRETLS from an SMTP verb to a MAIL FROM 477 parameter to better associate REQUIRETLS requirements with 478 transmission of individual messages. 480 o Addition of an option to require DNSSEC lookup of the remote mail 481 server, since this affects the common name of the certificate that 482 is presented. 484 o Clarified the wording to more clearly state that TLS sessions must 485 be established and not simply that STARTTLS is negotiated. 487 o Introduced need for minimum encryption standards (key lengths and 488 algorithms) 490 o Substantially rewritten Security Considerations section 492 10. References 494 10.1. Normative References 496 [MailParams] 497 Internet Assigned Numbers Authority (IANA), "IANA Mail 498 Parameters", 2007, 499 . 501 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 502 Requirement Levels", BCP 14, RFC 2119, 503 DOI 10.17487/RFC2119, March 1997, 504 . 506 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 507 Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, 508 February 2002, . 510 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 511 Rose, "Protocol Modifications for the DNS Security 512 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 513 . 515 [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced 516 Mail System Status Codes", BCP 138, RFC 5248, 517 DOI 10.17487/RFC5248, June 2008, 518 . 520 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 521 DOI 10.17487/RFC5321, October 2008, 522 . 524 [SMTPStatusCodes] 525 Internet Assigned Numbers Authority (IANA), "Simple Mail 526 Transfer Protocol (SMTP) Enhanced Status Codes Registry", 527 2008, . 530 10.2. Informative References 532 [I-D.ietf-uta-mta-sts] 533 Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., 534 and J. Jones, "SMTP MTA Strict Transport Security (MTA- 535 STS)", draft-ietf-uta-mta-sts-02 (work in progress), 536 December 2016. 538 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 539 STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, 540 . 542 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 543 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 544 . 546 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 547 Rose, "DNS Security Introduction and Requirements", 548 RFC 4033, DOI 10.17487/RFC4033, March 2005, 549 . 551 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 552 Thayer, "OpenPGP Message Format", RFC 4880, 553 DOI 10.17487/RFC4880, November 2007, 554 . 556 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 557 Mail Extensions (S/MIME) Version 3.2 Message 558 Specification", RFC 5751, DOI 10.17487/RFC5751, January 559 2010, . 561 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 562 Verification of Domain-Based Application Service Identity 563 within Internet Public Key Infrastructure Using X.509 564 (PKIX) Certificates in the Context of Transport Layer 565 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 566 2011, . 568 [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via 569 Opportunistic DNS-Based Authentication of Named Entities 570 (DANE) Transport Layer Security (TLS)", RFC 7672, 571 DOI 10.17487/RFC7672, October 2015, 572 . 574 Author's Address 576 Jim Fenton 577 Altmode Networks 578 704 Benvenue Avenue 579 Los Altos, California 94024 580 USA 582 Email: fenton@bluepopcorn.net