RFC 2595

Using TLS with IMAP, POP3 and ACAP

📅 published June 1999, from ietf

Okay bestie, let's glow up RFC 2595! 🎀

Using TLS with IMAP, POP3 and ACAP 💖

Okay so the title block first 📋 This one's RFC 2595, called Using TLS with IMAP, POP3 and ACAP. It came out of the Network Working Group and was written by C. Newman from Innosoft. It's on the Standards Track (so it's an actual Internet standard, not a suggestion 💅), and it's dated June 1999. The header doesn't list anything it obsoletes or updates.

Status of This Memo ✨

This document specifies an Internet standards track protocol for the Internet community, and it's literally asking everyone to discuss it and send suggestions for improvements 🦋. For the standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited.

Copyright (C) The Internet Society (1999). All Rights Reserved.

1. Motivation 🌸

TLS (formerly known as SSL) is how you keep an application protocol from getting tampered with or eavesdropped on 🔒. Using it is desirable for IMAP, POP and ACAP because of common connection eavesdropping and hijacking attacks [AUTH]. Ngl, advanced SASL authentication mechanisms can give you a lightweight version of this too, but TLS is complementary to simple authentication-only SASL mechanisms or to the clear-text password login commands that are already deployed 💀.

Many sites have a huge investment in authentication infrastructure, like a big database of a one-way function applied to user passwords. So a privacy layer that isn't tightly bound to user authentication can protect against network eavesdropping without needing new authentication infrastructure, or forcing everyone to change their password 🙈. Sites like that will want simple password authentication combined with TLS encryption, so this spec defines the PLAIN SASL mechanism for protocols that lack a simple password authentication command, like ACAP and SMTP. (Heads up, there's a separate RFC for the STARTTLS command in SMTP [SMTPTLS].)

There is a strong desire in the IETF to get rid of clear-text passwords over unencrypted channels 🔥. SASL can be used for this, but TLS is an extra tool with different deployability characteristics. A server supporting both TLS with simple passwords and a challenge/response SASL mechanism is likely to work with a wide variety of clients without falling back to unencrypted clear-text passwords ✨.

The STARTTLS command fixes a bunch of problems with using a separate port for a "secure" protocol variant. We'll get to some of these in section 7 🧚.

1.1. Conventions Used in this Document 📖

The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].

Terms related to authentication are defined in "On Internet Authentication" [AUTH].

Formal syntax is defined using ABNF [ABNF].

In examples, C: and S: indicate lines sent by the client and server respectively.

2. Basic Interoperability and Security Requirements 🔐

The following requirements apply to all implementations of the STARTTLS extension for IMAP, POP3 and ACAP.

2.1. Cipher Suite Requirements 🍓

Implementation of the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher suite is REQUIRED. This is important because it makes sure any two compliant implementations can be configured to interoperate.

All other cipher suites are OPTIONAL.

2.2. Privacy Operational Mode Security Requirements 🛡️

Both clients and servers SHOULD have a privacy operational mode that refuses authentication unless an encryption layer (like the one TLS provides) gets activated before or at the time of authentication, and that terminates the connection if that encryption layer gets deactivated. Implementations are encouraged to have flexibility about the minimum encryption strength or cipher suites they permit. The minimalist approach to this recommendation would be an operational mode where the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite is mandatory before authentication is permitted.

Clients MAY have an operational mode that uses encryption only when it's advertised by the server, but authentication continues regardless. For backwards compatibility, servers SHOULD have an operational mode where only the authentication mechanisms required by the relevant base protocol specification are needed to successfully authenticate.

2.3. Clear-Text Password Requirements 🙅

Clients and servers that implement STARTTLS MUST be configurable to refuse all clear-text login commands or mechanisms (including both standards-track and nonstandard mechanisms) unless an encryption layer of adequate strength is active. Servers that allow unencrypted clear-text logins SHOULD be configurable to refuse clear-text logins both for the entire server, and on a per-user basis.

2.4. Server Identity Check 🕵️

During the TLS negotiation, the client MUST check its understanding of the server hostname against the server's identity as presented in the server Certificate message, in order to prevent man-in-the-middle attacks. Matching is performed according to these rules:

  • The client MUST use the server hostname it used to open the connection as the value to compare against the server name as expressed in the server certificate. The client MUST NOT use any form of the server hostname derived from an insecure remote source (e.g., insecure DNS lookup). CNAME canonicalization is not done.
  • If a subjectAltName extension of type dNSName is present in the certificate, it SHOULD be used as the source of the server's identity.
  • Matching is case-insensitive.
  • A * wildcard character MAY be used as the left-most name component in the certificate. For example, *.example.com would match a.example.com, foo.example.com, etc. but would not match example.com.
  • If the certificate contains multiple names (e.g. more than one dNSName field), then a match with any one of the fields is considered acceptable.

If the match fails, the client SHOULD either ask for explicit user confirmation, or terminate the connection and indicate the server's identity is suspect.

2.5. TLS Security Policy Check 🧐

Both the client and server MUST check the result of the STARTTLS command and the subsequent TLS negotiation to see whether acceptable authentication or privacy was achieved. Ignoring this step completely invalidates using TLS for security. The decision about whether acceptable authentication or privacy was achieved is made locally, is implementation-dependent, and is beyond the scope of this document.

3. IMAP STARTTLS extension 🧚

When the TLS extension is present in IMAP, STARTTLS is listed as a capability in response to the CAPABILITY command. This extension adds a single command, STARTTLS, to the IMAP protocol, which is used to begin a TLS negotiation.

3.1. STARTTLS Command 🦋

Arguments:  none

Responses:  no specific responses for this command

Result:     OK - begin TLS negotiation
            BAD - command unknown or arguments invalid

A TLS negotiation begins immediately after the CRLF at the end of the tagged OK response from the server. Once a client issues a STARTTLS command, it MUST NOT issue further commands until a server response is seen and the TLS negotiation is complete.

The STARTTLS command is only valid in non-authenticated state. The server remains in non-authenticated state, even if client credentials are supplied during the TLS negotiation. The SASL [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS client credentials are successfully exchanged, but servers supporting the STARTTLS command are not required to support the EXTERNAL mechanism.

Once TLS has been started, the client MUST discard cached information about server capabilities and SHOULD re-issue the CAPABILITY command. This is necessary to protect against man-in-the-middle attacks which alter the capabilities list prior to STARTTLS. The server MAY advertise different capabilities after STARTTLS.

The formal syntax for IMAP is amended as follows:

        command_any   =/  "STARTTLS"

Example:

C: a001 CAPABILITY
S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED
S: a001 OK CAPABILITY completed
C: a002 STARTTLS
S: a002 OK Begin TLS negotiation now
<TLS negotiation, further commands are under TLS layer>
C: a003 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=EXTERNAL
S: a003 OK CAPABILITY completed
C: a004 LOGIN joe password
S: a004 OK LOGIN completed

3.2. IMAP LOGINDISABLED capability 🚫

The current IMAP protocol specification (RFC 2060) requires implementation of the LOGIN command, which uses clear-text passwords. Lots of sites may choose to disable this command unless encryption is active, for security reasons. An IMAP server MAY advertise that the LOGIN command is disabled by including the LOGINDISABLED capability in the capability response. Such a server will respond with a tagged NO response to any attempt to use the LOGIN command.

An IMAP server which implements STARTTLS MUST implement support for the LOGINDISABLED capability on unencrypted connections.

An IMAP client which complies with this specification MUST NOT issue the LOGIN command if this capability is present.

This capability is useful for stopping clients that follow this spec from sending an unencrypted password in an environment subject to passive attacks. It has no impact on an environment subject to active attacks, since a man-in-the-middle attacker can remove this capability. So this does not let clients off the hook for following the privacy mode recommendation in section 2.2.

Servers advertising this capability will fail to interoperate with many existing compliant IMAP clients, and they'll be unable to stop those clients from disclosing the user's password 😭.

4. POP3 STARTTLS extension ✨

okay so the POP3 STARTTLS extension adds the STLS command to POP3 servers 💌. If a server does this, it MUST also implement the POP3 extension mechanism [POP3EXT], so clients don't have to go probing a bunch of commands just to see what's there 🧚. The capability name "STLS" tells you the command is present and allowed in the current state 💅.

STLS 🎀

Arguments: none

Restrictions: only permitted in AUTHORIZATION state 🔒

Discussion: a TLS negotiation starts right after the CRLF that ends the +OK response from the server 🌊. A -ERR response MAY come back if a security layer is already active 🙈. Once a client sends STLS, it MUST NOT send any more commands until it has seen a server response and the TLS negotiation is done 🫶.

STLS only works in AUTHORIZATION state, and the server stays in AUTHORIZATION state even if client credentials get handed over during the TLS negotiation 🧸. The AUTH command [POP-AUTH] with the EXTERNAL mechanism [SASL] MAY be used to authenticate once TLS client credentials are exchanged successfully. Servers that support STLS are not required to support the EXTERNAL mechanism, though 🤷‍♀️.

Once TLS has started, the client MUST discard its cached info about server capabilities and SHOULD re-issue the CAPA command. This protects against man-in-the-middle attacks that might change the capabilities list before STLS 👀🚨. The server MAY advertise different capabilities after STLS 🦋.

Possible Responses: +OK and -ERR 💖

Examples:

C: STLS
S: +OK Begin TLS negotiation
<TLS negotiation, further commands are under TLS layer>
  ...
C: STLS
S: -ERR Command not permitted when TLS active

5. ACAP STARTTLS extension 🌸

when the TLS extension is there in ACAP, "STARTTLS" shows up as a capability in the ACAP greeting 👋. No arguments are defined for this capability yet. The extension adds one command, "STARTTLS", which is what kicks off a TLS negotiation 🚀.

5.1. STARTTLS Command 💜

Arguments: none

Responses: no specific responses for this command

Result:

OK - begin TLS negotiation
BAD - command unknown or arguments invalid

A TLS negotiation starts right after the CRLF at the end of the tagged OK response from the server 🌊. Once a client sends a STARTTLS command, it MUST NOT send any more commands until it has seen a server response and the TLS negotiation is done 🫶.

STARTTLS is only valid in non-authenticated state. The server stays in non-authenticated state even if client credentials are supplied during the TLS negotiation 🧸. The SASL [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS client credentials are exchanged successfully. Servers that support the STARTTLS command are not required to support the EXTERNAL mechanism 🤷‍♀️.

After the TLS layer is set up, the server MUST re-issue an untagged ACAP greeting. This protects against man-in-the-middle attacks that might change the capabilities list before STARTTLS 👀🚨. The client MUST discard its cached capability info and replace it with whatever is in the new ACAP greeting. The server MAY advertise different capabilities after STARTTLS 🦋.

The formal syntax for ACAP gets amended like this 📝:

command_any   =/  "STARTTLS"

Example:

S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
C: a002 STARTTLS
S: a002 OK "Begin TLS negotiation now"
<TLS negotiation, further commands are under TLS layer>
S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL")

6. PLAIN SASL mechanism 🔑

okay, clear-text passwords are simple, they work with almost every existing operating system authentication database, and they're super useful for a smooth move to a more secure password-based mechanism ✨. The catch is that they're unacceptable over an unencrypted network connection 💀.

This section defines the "PLAIN" SASL mechanism for ACAP and other protocols that don't have a clear-text login command 🎀. The PLAIN SASL mechanism MUST NOT be advertised or used unless a strong encryption layer (such as the one TLS provides) is active, or backwards compatibility means it has to be otherwise 🔒.

The mechanism is one single message from the client to the server 📩. The client sends the authorization identity (the identity to log in as), then a US-ASCII NUL character, then the authentication identity (the identity whose password gets used), then another US-ASCII NUL character, and then the clear-text password. The client may leave the authorization identity empty to say it's the same as the authentication identity 💖.

The server checks the authentication identity and password against the system authentication database, and it checks that those credentials let the client log in as the authorization identity. If both checks pass, the user is logged in 🥳.

The server MAY also use the password to set up any new authentication database, like one for CRAM-MD5 [CRAM-MD5] 🧁.

Non-US-ASCII characters are allowed as long as they're represented in UTF-8 [UTF-8] 🌈. Non-visible characters, or characters a user might not be able to type on some keyboards, are discouraged 🙈.

Here's the formal grammar for the client message, written in Augmented BNF [ABNF] 📐:

message         = [authorize-id] NUL authenticate-id NUL password
authenticate-id = 1*UTF8-SAFE      ; MUST accept up to 255 octets
authorize-id    = 1*UTF8-SAFE      ; MUST accept up to 255 octets
password        = 1*UTF8-SAFE      ; MUST accept up to 255 octets
NUL             = %x00
UTF8-SAFE       = %x01-09 / %x0B-0C / %x0E-7F / UTF8-2 /
                  UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6
UTF8-1          = %x80-BF
UTF8-2          = %xC0-DF UTF8-1
UTF8-3          = %xE0-EF 2UTF8-1
UTF8-4          = %xF0-F7 3UTF8-1
UTF8-5          = %xF8-FB 4UTF8-1
UTF8-6          = %xFC-FD 5UTF8-1

Here's an example of how this could be used to set up a CRAM-MD5 authentication database for ACAP 🧚:

S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
C: a001 AUTHENTICATE "CRAM-MD5"
S: + "<1896.697170952@postoffice.reston.mci.net>"
C: "tim b913a602c7eda7a495b4e6e7334d3890"
S: a001 NO (TRANSITION-NEEDED)
   "Please change your password, or use TLS to login"
C: a002 STARTTLS
S: a002 OK "Begin TLS negotiation now"
<TLS negotiation, further commands are under TLS layer>
S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL")
C: a003 AUTHENTICATE "PLAIN" {21+}
C: <NUL>tim<NUL>tanstaaftanstaaf
S: a003 OK CRAM-MD5 password initialized

Note: in this example, <NUL> stands for a single ASCII NUL octet 🤓.

7. imaps and pop3s ports 🚫

Separate "imaps" and "pop3s" ports were registered for use with SSL. Using these ports is discouraged in favor of the STARTTLS or STLS commands 💅.

Separate ports have caused a bunch of problems, and this list is an attempt to name some of them 📋.

  • Separate ports lead to a separate URL scheme that messes with the user interface in weird ways 🙃. For example, lots of web pages say something like "click here if your browser supports SSL." That's a decision the browser is usually better at making than the user 🖥️.
  • Separate ports imply a model of either "secure" or "not secure," and that can be misleading in a few ways 😬. First, the "secure" port may not actually be acceptably secure, since an export-crippled cipher suite might be in use, which can give users a false sense of security 🥲. Second, the normal port might be secured by a SASL mechanism that includes a security layer. So the separate port distinction makes the already complicated topic of security policy even more confusing 🌀. One common result is that firewall admins get misled into allowing the "secure" port and blocking the standard port. That could be a poor choice, because SSL with a 40-bit key encryption layer plus plain-text password authentication is less secure than strong SASL mechanisms like GSSAPI with Kerberos 5 ⚠️.
  • Using separate ports for SSL has pushed clients into only two security policies: use SSL, or don't use SSL 😤. The much nicer policy "use TLS when available" would be clunky with the separate port model, but it's simple with STARTTLS 💖.
  • Port numbers are a limited resource 🔢. They aren't in short supply yet, but it's unwise to set a precedent that could double (or worse) how fast they get used up 🏃‍♀️💨.

8. IANA Considerations 📚

This registers the "STARTTLS" and "LOGINDISABLED" IMAP capabilities, as required by section 7.2.1 of RFC 2060 [IMAP] 🫡.

Here's the registration for the POP3 "STLS" capability 🎀:

CAPA tag:                   STLS
Arguments:                  none
Added commands:             STLS
Standard commands affected: May enable USER/PASS as a side-effect.
  CAPA command SHOULD be re-issued after successful completion.
Announced states/Valid states: AUTHORIZATION state only.
Specification reference:    this memo

Here's the registration for the ACAP "STARTTLS" capability 🧁:

Capability name:            STARTTLS
Capability keyword:         STARTTLS
Capability arguments:       none
Published Specification(s): this memo
Person and email address for further information:
    see author's address section below

And here's the registration for the PLAIN SASL mechanism 🔐:

SASL mechanism name:        PLAIN
Security Considerations:    See section 9 of this memo
Published specification:    this memo
Person & email address to contact for further information:
    see author's address section below
Intended usage:             COMMON
Author/Change controller:   see author's address section below

9. Security Considerations 🔐

okay bestie, this is the serious part, so listen up 💅 TLS only protects data while it's crossing the network connection. Messages moving over IMAP or POP3 are still visible to server admins, and they're usually open to eavesdropping, tampering, and forgery once they get passed along through SMTP or NNTP 😭. TLS is not a stand-in for an end-to-end message security mechanism, so for that you'd want MIME security multiparts [MIME-SEC] 🎀.

A man-in-the-middle attacker can sneak STARTTLS out of the capability list, or make the STARTTLS command fail on purpose 👀. To catch that, clients SHOULD warn the user when session privacy isn't active, and/or be configurable so they refuse to continue without an acceptable level of security 🚨.

A man-in-the-middle can always push a down-negotiation to the weakest authentication mechanism or cipher suite on offer 💀. That's why implementations SHOULD be configurable to refuse weak mechanisms or cipher suites 🛡️.

Anything said before the TLS handshake happens in the clear, so a man-in-the-middle can change it 🙈. For that reason, clients MUST discard cached information about server capabilities that was advertised before the TLS handshake started 🧹.

Clients are encouraged to clearly show when the encryption in use is known to be vulnerable to attack with modern hardware, such as encryption keys with 56 bits of entropy or less ⚠️.

The LOGINDISABLED IMAP capability (discussed in section 3.2) only cuts down the risk from passive attacks. It does nothing against active attacks 🙅‍♀️. The client is still responsible for not sending a password over a vulnerable channel 🔑.

The PLAIN mechanism depends on the TLS encryption layer for its security. Without TLS, it's open to a very common eavesdropping attack 🎣. So PLAIN MUST NOT be advertised or used unless a suitable TLS encryption layer is active, or backwards compatibility means otherwise 🫶.

When PLAIN is used, the server can impersonate the user to every service that uses the same password, no matter what encryption TLS or other network privacy mechanisms are providing 🎭. Lots of other authentication mechanisms have similar weaknesses, but stronger SASL mechanisms such as Kerberos deal with this problem ✨. Clients are encouraged to have an operational mode where every mechanism likely to reveal the user's password to the server is disabled 👑.

The security considerations for TLS apply to STARTTLS, and the security considerations for SASL apply to the PLAIN mechanism 🧚. More security requirements are covered in section 2 🌸.

10. References 📚

  • [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
  • [ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
  • [AUTH] Haller, N. and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.
  • [CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, September 1997.
  • [IMAP] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996.
  • [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [MIME-SEC] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
  • [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
  • [POP3EXT] Gellens, R., Newman, C. and L. Lundblade, "POP3 Extension Mechanism", RFC 2449, November 1998.
  • [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734, December 1994.
  • [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
  • [SMTPTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over TLS", RFC 2487, January 1999.
  • [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
  • [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.

11. Author's Address 💌

Chris Newman
Innosoft International, Inc.
1050 Lakes Drive
West Covina, CA 91790 USA

EMail: chris.newman@innosoft.com

A. Appendix -- Compliance Checklist ✅

this is the cheat sheet bestie, screenshot it 📸 An implementation is not compliant if it fails to satisfy one or more of the MUST requirements for the protocols it implements 🚫. If it satisfies all the MUST and all the SHOULD requirements for its protocols, it's called "unconditionally compliant" 👑. If it satisfies all the MUST requirements but not all the SHOULD requirements, it's called "conditionally compliant" 🩷.

Rules                                                 Section
-----                                                 -------
Mandatory-to-implement Cipher Suite                      2.1
SHOULD have mode where encryption required               2.2
server SHOULD have mode where TLS not required           2.2
MUST be configurable to refuse all clear-text login
  commands or mechanisms                                 2.3
server SHOULD be configurable to refuse clear-text
  login commands on entire server and on per-user basis  2.3
client MUST check server identity                        2.4
client MUST use hostname used to open connection         2.4
client MUST NOT use hostname from insecure remote lookup 2.4
client SHOULD support subjectAltName of dNSName type     2.4
client SHOULD ask for confirmation or terminate on fail  2.4
MUST check result of STARTTLS for acceptable privacy     2.5
client MUST NOT issue commands after STARTTLS
   until server response and negotiation done        3.1,4,5.1
client MUST discard cached information             3.1,4,5.1,9
client SHOULD re-issue CAPABILITY/CAPA command       3.1,4
IMAP server with STARTTLS MUST implement LOGINDISABLED   3.2
IMAP client MUST NOT issue LOGIN if LOGINDISABLED        3.2
POP server MUST implement POP3 extensions                4
ACAP server MUST re-issue ACAP greeting                  5.1
client SHOULD warn when session privacy not active and/or
  refuse to proceed without acceptable security level    9
SHOULD be configurable to refuse weak mechanisms or
  cipher suites                                          9

The PLAIN mechanism is an optional part of this specification 🧩. But if you do implement it, these rules apply 💖:

Rules                                                 Section
-----                                                 -------
MUST NOT use PLAIN unless strong encryption active
  or backwards compatibility dictates otherwise         6,9
MUST use UTF-8 encoding for characters in PLAIN          6

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🌈

Funding for the RFC Editor function is currently provided by the Internet Society 💜.

📦 where this page comes from