IETF | Reporting Protocol Vulnerabilities to the IETF

The IETF works on a broad range of networking technologies that provide the foundation for the Internet's growth and evolution.
While most IETF work takes place online, meetings and other events such as Hackathons provide in-person opportunities to advance work within the IETF.
The IETF is the premier Internet standards organization. It follows open and well-documented processes for setting these standards. Once published, those standards are made freely available.
The global IETF community works together in many different ways to produce high quality, relevant technical documents that influence the way people design, use, and manage the Internet.
By supporting the IETF today, you are ensuring a free and open Internet exists tomorrow.
The IETF recognizes that security vulnerabilities will be discovered in IETF protocols and welcomes their critical evaluation by researchers.
Such research keeps the Internet safe. If you believe you’ve discovered a protocol vulnerability, we very much welcome your contribution.
Remediation of vulnerabilities is typically started through disclosure to an open and public IETF working group or mailing list where protocol improvements can be discussed. If you do not know which IETF working group or mailing list to use, or that does not seem appropriate for your work, we invite you to contact <protocol-vulnerability@ietf.org> (link to PGP key below) for assistance.
A full explanation of the IETF processes related to disclosure and remediation of vulnerabilities is documented below.
The IETF does not pay “bug bounties” for reported vulnerabilities.
The IETF is a standards development organization that publishes RFCs that describe Internet protocols and specifications. Internet-Drafts (I-Ds) are working documents used in the creation of RFCs. RFCs and I-Ds are collectively referred to as documents. While documents include an occasional reference or example source code, the IETF does not build or maintain implementations of protocols.
Design vulnerabilities or security issues with operational practices described in IETF documents can be addressed in the IETF. Implementation or configuration vulnerabilities in products, open source projects, or services that may implement these documents need to be addressed by their corresponding vendor or maintainers. The IETF does not have a formal means to reach these parties.
Additionally, the IETF does not certify conformance of products to its published documents.
Vulnerabilities in any infrastructure and services that support the IETF, IRTF and IAB (such as those associated with the ietf.org, iab.org, irtf.org and rfc-editor.org domains) are the responsibility of the IETF Administration LLC who has their own vulnerability disclosure policy.
The IETF values your critical analysis of its work. What the IETF will do with your vulnerability report depends on the type of document where the issue is found, the severity of the issue, the complexity of the mitigation, and the maturity of the document in question.
Vulnerabilities found in working group Internet-Drafts or individual submission documents that have expired, or were fixed in subsequent versions; or published RFCs that are marked historic, are unlikely to have action taken on them. Additionally, as the RFC series predates the IETF and not all RFCs are the result of IETF standards activity — some even document proprietary protocols not developed in the IETF. These may also not have action taken in response to a vulnerability report.
Generally speaking, being available for follow-up clarifications and related discussions posed by the Area Directors, Working Group Chairs, working group participants, or document authors is extremely helpful.
The IETF does not pay “bug bounties” for reported vulnerabilities.
A vulnerability report related to IETF documents can be sent to the <protocol-vulnerability@ietf.org> (link to PGP key below) and the Security Area Directors will make a best effort to triage and action the information. This email alias does not have a public archive. If explicitly requested by the vulnerability reporter, information about the reporter can be removed when the Area Directors forward along the vulnerability information to public mailing list(s) (as noted below in the “Transparency in the IETF” and Activity #10 of Figure 1).
However, because of the distributed organization of IETF work, consulting Figure 1 can help expedite issues being reported. No vulnerability is the same and, depending on the maturity and circumstances of a given document, the reporting path will vary. Each activity in Figure 1 is documented below.
Can the specific document in which the vulnerability is present be identified? All IETF documents are published in the IETF Datatracker.
What is the name of the document in which the vulnerability is present? Published documents have the naming convention of RFCxxxx (where xxxx is a four digit number). Internet-Drafts adopted by a working group have a naming convention of draft-ietf-xxx-yyy (where xxx is the working group in which the work is being done; and yyy is the chosen filename). Individual submissions, drafts that are not adopted by a working group are named draft-ZZZ-AAA (where ZZZ is typically the document submitter's name). See Section 7 of Guidelines to Authors of Internet-Drafts for additional background on naming of IETF documents.
Consult the list of active working groups.
To determine if an document named ABC was produced by a working group and if this working group is active:
If the originating working group is found not to be active, also review the list of active working groups per Activity #3. A number of protocol maintenance work groups (e.g., LAMPS to address the maintenance of PKI specifications; TCPM to address TCP maintenance) have been established to update older, widely used protocols.
The procedure is the same as for Activity #4.
Judging “minor text edits or clarifications” is subjective. Generally speaking a “minor