Skip to content

Last changes before publishing new version #186

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
nightwatchcyber merged 3 commits into from
Feb 25, 2020
Merged

Last changes before publishing new version #186

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
d94f00f
last changes before publishing new version
nightwatchcyber Feb 25, 2020
23095c5
adding commas
nightwatchcyber Feb 25, 2020
3a30d93
fixing nits
nightwatchcyber Feb 25, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 18 additions & 16 deletions draft-foudil-securitytxt.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@
<head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />

<title>A Method for Web Security Policies</title>
<title>A File Format to Aid in Security Vulnerability Disclosure</title>


<style type="text/css">/*<![CDATA[*/
Expand Down Expand Up @@ -341,9 +341,9 @@

<meta name="dct.creator" content="Foudil, E. and Y. Shafranovich" />
<meta name="dct.identifier" content="urn:ietf:id:draft-foudil-securitytxt-09" />
<meta name="dct.issued" scheme="ISO8601" content="2020-01-20" />
<meta name="dct.abstract" content="When security vulnerabilities are discovered by independent security researchers, they often lack the channels to report them properly. As a result, security vulnerabilities may be left unreported. This document defines a format (&#8220;security.txt&#8221;) to help organizations describe their vulnerability disclosure practices to make it easier for researchers to report security vulnerabilities." />
<meta name="description" content="When security vulnerabilities are discovered by independent security researchers, they often lack the channels to report them properly. As a result, security vulnerabilities may be left unreported. This document defines a format (&#8220;security.txt&#8221;) to help organizations describe their vulnerability disclosure practices to make it easier for researchers to report security vulnerabilities." />
<meta name="dct.issued" scheme="ISO8601" content="2020-02-24" />
<meta name="dct.abstract" content="When security vulnerabilities are discovered by researchers, proper reporting channels are often lacking. As a result, vulnerabilities may be left unreported. This document defines a format (&#8220;security.txt&#8221;) to help organizations describe their vulnerability disclosure practices to make it easier for researchers to report vulnerabilities." />
<meta name="description" content="When security vulnerabilities are discovered by researchers, proper reporting channels are often lacking. As a result, vulnerabilities may be left unreported. This document defines a format (&#8220;security.txt&#8221;) to help organizations describe their vulnerability disclosure practices to make it easier for researchers to report vulnerabilities." />

</head>

Expand All @@ -365,28 +365,28 @@
<td class="right">Y. Shafranovich</td>
</tr>
<tr>
<td class="left">Expires: July 23, 2020</td>
<td class="left">Expires: August 27, 2020</td>
<td class="right">Nightwatch Cybersecurity</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">January 20, 2020</td>
<td class="right">February 24, 2020</td>
</tr>


</tbody>
</table>

<p class="title">A Method for Web Security Policies<br />
<p class="title">A File Format to Aid in Security Vulnerability Disclosure<br />
<span class="filename">draft-foudil-securitytxt-09</span></p>

<h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
<p>When security vulnerabilities are discovered by independent security researchers, they often lack the channels to report them properly. As a result, security vulnerabilities may be left unreported. This document defines a format (&#8220;security.txt&#8221;) to help organizations describe their vulnerability disclosure practices to make it easier for researchers to report security vulnerabilities.</p>
<p>When security vulnerabilities are discovered by researchers, proper reporting channels are often lacking. As a result, vulnerabilities may be left unreported. This document defines a format (&#8220;security.txt&#8221;) to help organizations describe their vulnerability disclosure practices to make it easier for researchers to report vulnerabilities.</p>
<h1 id="rfc.status"><a href="#rfc.status">Status of This Memo</a></h1>
<p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
<p>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/.</p>
<p>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."</p>
<p>This Internet-Draft will expire on July 23, 2020.</p>
<p>This Internet-Draft will expire on August 27, 2020.</p>
<h1 id="rfc.copyrightnotice"><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
<p>Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
<p>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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p>
Expand Down Expand Up @@ -510,9 +510,9 @@ <h1 id="rfc.section.1">
<h1 id="rfc.section.1.1">
<a href="#rfc.section.1.1">1.1.</a> <a href="#motivation-prior-work-and-scope" id="motivation-prior-work-and-scope">Motivation, Prior Work and Scope</a>
</h1>
<p id="rfc.section.1.1.p.1">Many security researchers encounter situations where they are unable to report security vulnerabilities to organizations because there is no way indicated to contact the owner of a particular resource and no information available about the vulnerability disclosure practices of such owner.</p>
<p id="rfc.section.1.1.p.1">Many security researchers encounter situations where they are unable to report security vulnerabilities to organizations because there are no reporting channels to contact the owner of a particular resource and no information available about the vulnerability disclosure practices of such owner.</p>
<p id="rfc.section.1.1.p.2">As per section 4 of <a href="#RFC2142" class="xref">[RFC2142]</a>, there is an existing convention of using the &lt;SECURITY@domain&gt; email address for communications regarding security vulnerabilities. That convention provides only a single, email-based channel of communication for security vulnerabilities per domain, and does not provide a way for domain owners to publish information about their security disclosure practices.</p>
<p id="rfc.section.1.1.p.3">There are also contact conventions prescribed for Internet Service Providers (ISPs) in section 2 of <a href="#RFC3013" class="xref">[RFC3013]</a>, for Computer Security Incident Response Teams (CSIRTs) in section 3.2 of <a href="#RFC2350" class="xref">[RFC2350]</a> and for site operators in section 5.2 of <a href="#RFC2196" class="xref">[RFC2196]</a>. As per <a href="#RFC7485" class="xref">[RFC7485]</a>, there is also contact information provided by Regional Internet Registries (RIRs) and domain registries for owners of IP addresses, autonomous system numbers (ASNs) and domain names. However, none of these address the issue of how security researchers can locate vulnerability disclosure practices and contact information for organizations in order to report security vulnerabilities.</p>
<p id="rfc.section.1.1.p.3">There are also contact conventions prescribed for Internet Service Providers (ISPs) in section 2 of <a href="#RFC3013" class="xref">[RFC3013]</a>, for Computer Security Incident Response Teams (CSIRTs) in section 3.2 of <a href="#RFC2350" class="xref">[RFC2350]</a> and for site operators in section 5.2 of <a href="#RFC2196" class="xref">[RFC2196]</a>. As per <a href="#RFC7485" class="xref">[RFC7485]</a>, there is also contact information provided by Regional Internet Registries (RIRs) and domain registries for owners of IP addresses, autonomous system numbers (ASNs) and domain names. However, none of these address the issue of how security researchers can locate contact information and vulnerability disclosure practices for organizations in order to report vulnerabilities.</p>
<p id="rfc.section.1.1.p.4">In this document, we define a richer and more extensible way for organizations to communicate information about their security disclosure practices and ways to contact them. Other details of vulnerability disclosure are outside the scope of this document. Readers are encouraged to consult other documents such as <a href="#ISO.29147.2018" class="xref">[ISO.29147.2018]</a> or <a href="#CERT.CVD" class="xref">[CERT.CVD]</a>.</p>
<h1 id="rfc.section.1.2">
<a href="#rfc.section.1.2">1.2.</a> <a href="#terminology" id="terminology">Terminology</a>
Expand Down Expand Up @@ -636,7 +636,7 @@ <h1 id="rfc.section.3.5.4">
<h1 id="rfc.section.3.5.5">
<a href="#rfc.section.3.5.5">3.5.5.</a> <a href="#expires" id="expires">Expires</a>
</h1>
<p id="rfc.section.3.5.5.p.1">This field indicates the date/time after which the data contained in the &#8220;security.txt&#8221; file is considered stale and should not be used (as per <a href="#stale" class="xref">Section 6.2</a>). The value of this field follows the format defined in section 3.3 of <a href="#RFC5322" class="xref">[RFC5322]</a>.</p>
<p id="rfc.section.3.5.5.p.1">This field indicates the date and time after which the data contained in the &#8220;security.txt&#8221; file is considered stale and should not be used (as per <a href="#stale" class="xref">Section 6.2</a>). The value of this field follows the format defined in section 3.3 of <a href="#RFC5322" class="xref">[RFC5322]</a>.</p>
<p id="rfc.section.3.5.5.p.2">This field MUST NOT appear more than once.</p>
<pre>
Expires: Thu, 31 Dec 2020 18:37:07 -0800
Expand Down Expand Up @@ -808,9 +808,9 @@ <h1 id="rfc.section.6.1">
<a href="#rfc.section.6.1">6.1.</a> <a href="#redirects" id="redirects">Compromised Files and Redirects</a>
</h1>
<p id="rfc.section.6.1.p.1">An attacker that has compromised a website is able to compromise the &#8220;security.txt&#8221; file as well or setup a redirect to their own site. This can result in security reports not being received by the organization or sent to the attacker.</p>
<p id="rfc.section.6.1.p.2">To protect against this, organizations should digitally sign their &#8220;security.txt&#8221; files (as per <a href="#signature" class="xref">Section 3.4</a>), use the &#8220;Canonical&#8221; field to sign the locations of the file (as per <a href="#canonical" class="xref">Section 3.5.2</a>), and regularly monitor the file and the referenced resources to detect tampering.</p>
<p id="rfc.section.6.1.p.2">To protect against this, organizations should use the &#8220;Canonical&#8221; field to indicate the locations of the file (as per <a href="#canonical" class="xref">Section 3.5.2</a>), digitally sign their &#8220;security.txt&#8221; files (as per <a href="#signature" class="xref">Section 3.4</a>), and regularly monitor the file and the referenced resources to detect tampering.</p>
<p id="rfc.section.6.1.p.3">Security researchers should triage the &#8220;security.txt&#8221; file including verifying the digital signature and checking any available historical records before using the information contained in the file. If the &#8220;security.txt&#8221; file looks suspicious or compromised, it should not be used.</p>
<p id="rfc.section.6.1.p.4">When retrieving the file and any resources referenced in the file, researchers should record any redirects since they can lead to a different domain or IP address controlled by an attacker. Further inspections of such redirects is recommended before using the information.</p>
<p id="rfc.section.6.1.p.4">When retrieving the file and any resources referenced in the file, researchers should record any redirects since they can lead to a different domain or IP address controlled by an attacker. Further inspections of such redirects is recommended before using the information contained within the file.</p>
<h1 id="rfc.section.6.2">
<a href="#rfc.section.6.2">6.2.</a> <a href="#stale" id="stale">Incorrect or Stale Information</a>
</h1>
Expand Down Expand Up @@ -948,7 +948,8 @@ <h1 id="rfc.section.8">
<a href="#rfc.section.8">8.</a> <a href="#contributors" id="contributors">Contributors</a>
</h1>
<p id="rfc.section.8.p.1">The authors would like to acknowledge the help provided during the development of this document by Tom Hudson, Jobert Abma, Gerben Janssen van Doorn, Austin Heap, Stephane Bortzmeyer, Max Smith, Eduardo Vela and Krzysztof Kotowicz.</p>
<p id="rfc.section.8.p.2">The authors would also like to acknowledge the feedback provided by multiple members of IETF&#8217;s SAAG and SECDISPATCH lists.</p>
<p id="rfc.section.8.p.2">The authors would also like to acknowledge the feedback provided by multiple members of IETF&#8217;s LAST CALL, SAAG, SECDISPATCH lists.</p>
<p id="rfc.section.8.p.3">Yakov would like to also thank LTS (for everything).</p>
<h1 id="rfc.references">
<a href="#rfc.references">9.</a> References</h1>
<h1 id="rfc.references.1">
Expand Down Expand Up @@ -1249,8 +1250,9 @@ <h1 id="rfc.appendix.B.9">
<li>Added language and example regarding URI encoding (#176)</li>
<li>Add &#8220;Expires&#8221; field (#181)</li>
<li>Changed language from &#8220;directive&#8221; to &#8220;field&#8221; (#182)</li>
<li>Addressing last call feedback (#179 and #180)</li>
<li>Addressing last call feedback (#179, #180 and #183)</li>
<li>Clarifying order of fields (#174)</li>
<li>Revert comment/field association (#158)</li>
</ul>
<p id="rfc.section.B.9.p.2">Full list of changes can be viewed via the IETF document tracker: https://tools.ietf.org/html/draft-foudil-securitytxt</p>
<h1 id="rfc.authors"><a href="#rfc.authors">Authors' Addresses</a></h1>
Expand Down
38 changes: 20 additions & 18 deletions draft-foudil-securitytxt.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
---
title: A Method for Web Security Policies
title: A File Format to Aid in Security Vulnerability Disclosure
docname: draft-foudil-securitytxt-09
ipr: trust200902
cat: info
Expand Down Expand Up @@ -31,12 +31,11 @@ informative:


--- abstract
When security vulnerabilities are discovered by independent
security researchers, they
often lack the channels to report them properly. As a result,
security vulnerabilities may be left unreported. This document defines a format
When security vulnerabilities are discovered by
researchers, proper reporting channels are often lacking. As a result,
vulnerabilities may be left unreported. This document defines a format
("security.txt") to help organizations describe their vulnerability disclosure practices
to make it easier for researchers to report security vulnerabilities.
to make it easier for researchers to report vulnerabilities.

--- middle

Expand All @@ -45,8 +44,8 @@ to make it easier for researchers to report security vulnerabilities.
## Motivation, Prior Work and Scope

Many security researchers encounter situations where they are unable
to report security vulnerabilities to organizations because there is
no way indicated to contact the owner of a particular
to report security vulnerabilities to organizations because there are
no reporting channels to contact the owner of a particular
resource and no information available about the vulnerability disclosure practices
of such owner.

Expand All @@ -63,9 +62,9 @@ in section 3.2 of {{?RFC2350}} and for site operators in section 5.2 of
{{?RFC2196}}. As per {{?RFC7485}}, there is also contact information provided by
Regional Internet Registries (RIRs) and domain registries for owners of IP
addresses, autonomous system numbers (ASNs) and domain names. However, none of
these address the issue of how security researchers can locate vulnerability disclosure
practices and contact information for organizations in order to report
security vulnerabilities.
these address the issue of how security researchers can locate contact information
and vulnerability disclosure practices for organizations in order to report
vulnerabilities.

In this document, we define a richer and more extensible way
for organizations to communicate information about their security disclosure
Expand Down Expand Up @@ -285,7 +284,7 @@ Encryption: openpgp4fpr:5f2de5521c63a801ab59ccb603d49de44b29100f

### Expires {#expires}

This field indicates the date/time after which the data contained in the "security.txt"
This field indicates the date and time after which the data contained in the "security.txt"
file is considered stale and should not be used (as per {{stale}}). The value of this field follows
the format defined in section 3.3 of {{!RFC5322}}.

Expand Down Expand Up @@ -505,9 +504,9 @@ the "security.txt" file as well or setup a redirect to their own site.
This can result in security reports not being received by the organization
or sent to the attacker.

To protect against this, organizations should digitally sign their "security.txt"
files (as per {{signature}}), use the "Canonical" field to sign the locations
of the file (as per {{canonical}}), and regularly monitor the file and
To protect against this, organizations should use the "Canonical" field to indicate the locations
of the file (as per {{canonical}}), digitally sign their "security.txt"
files (as per {{signature}}), and regularly monitor the file and
the referenced resources to detect tampering.

Security researchers should triage the "security.txt" file including verifying
Expand All @@ -517,7 +516,7 @@ it should not be used.

When retrieving the file and any resources referenced in the file, researchers should record
any redirects since they can lead to a different domain or IP address controlled by an attacker. Further
inspections of such redirects is recommended before using the information.
inspections of such redirects is recommended before using the information contained within the file.

## Incorrect or Stale Information {#stale}

Expand Down Expand Up @@ -732,8 +731,10 @@ The authors would like to acknowledge the help provided during the
development of this document by Tom Hudson, Jobert Abma,
Gerben Janssen van Doorn, Austin Heap, Stephane Bortzmeyer, Max Smith, Eduardo Vela and Krzysztof Kotowicz.

The authors would also like to acknowledge the feedback provided by multiple members of IETF's
LAST CALL, SAAG, SECDISPATCH lists.

@EdOverflow EdOverflow Feb 25, 2020

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
LAST CALL, SAAG, SECDISPATCH lists.
LAST CALL, SAAG, and SECDISPATCH lists.

@joker314 joker314 Feb 25, 2020

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should decide whether we use or don't use the Oxford comma and then be consistent (if we are for it, then the list of Contributors will need to have it -- or if we aren't, there should not be a comma here)


The authors would also like to acknowledge the feedback provided by multiple members of IETF's SAAG and SECDISPATCH lists.
Yakov would like to also thank LTS (for everything).

--- back
# Note to Readers
Expand Down Expand Up @@ -828,8 +829,9 @@ of DNS-stored encryption keys (#28 and #94)
- Added language and example regarding URI encoding (#176)
- Add "Expires" field (#181)
- Changed language from "directive" to "field" (#182)
- Addressing last call feedback (#179 and #180)
- Addressing last call feedback (#179, #180 and #183)
- Clarifying order of fields (#174)
- Revert comment/field association (#158)

Full list of changes can be viewed via the IETF document tracker:
https://tools.ietf.org/html/draft-foudil-securitytxt
Loading