Subject: [saag] Fwd: Last Call: <draft-foudil-securitytxt-08.txt> (A Method for Web Security Policies) to Informational RFC

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 9 Dec 2019 16:53:09 -0500

---------- Forwarded message ---------
From: The IESG <[email-masked]>
Date: Mon, Dec 9, 2019 at 12:39 PM
Subject: Last Call: <draft-foudil-securitytxt-08.txt> (A Method for
Web Security Policies) to Informational RFC
To: IETF-Announce <[email-masked]>
Cc: <[email-masked]>,
<[email-masked]>, <[email-masked]>

The IESG has received a request from an individual submitter to consider the
following document: - 'A Method for Web Security Policies'
  <draft-foudil-securitytxt-08.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2020-01-06. Exceptionally, comments may
be sent to [email-masked] instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

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 ("security.txt") to help organizations
   describe the process for security researchers to follow in order to
   report security vulnerabilities.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-foudil-securitytxt/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-foudil-securitytxt/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: S Moonesamy <[email-masked]>
Date: Sat, 28 Dec 2019 09:58:46 -0800

>[email-masked] mailing lists by 2020-01-06. Exceptionally, comments may

Section 1.1 of the draft states that it is about helping 
organizations to communicate information about their security 
disclosure policies.  Is the field defined in Section 3.5.6 optional?

Section 3 sets a requirement for the file (security.txt) to be 
accessible via HTTP and references RFC 1945.  Does it mean that the 
file must be accessible using HTTP/1/0?

Section 3.1 specifies that the file would only apply to the domain in 
the URI.  The examples given in that section states that the file 
also applies to to IPv4 and IPv6 addresses.

There is a requirement in Section 3.3 for the line separator to be 
either CRLF or LF.  Have the authors considered using only one 
convention for specifying the end of line?

Have the authors considered line limits given that the specification 
defines a machine-parsable format?

Why does the robustness principle require capital letters? (Section 4)?

How will the designated expert determine whether a proposed 
registration (Section 7.2) provides value?  What is the "wider 
Internet community"?

How should "MAY assume that English is the default language to be 
used" be interpreted (Section 3.5.7)?  RFC 2777 states that 
"i-default" is not a specific language.

As an overall comment, there are a lot of requirements and 
recommendations (please see RFC 2119) in the draft.  There is, for 
example, a restatement of a requirement: "The value MUST follow the 
URI syntax described in [RFC3986].  This means that "mailto" and 
"tel" URI schemes MUST be used when specifying email addresses and 
telephone numbers, as defined in [RFC6068] and [RFC3966]".  Does that 
comply with the ABNF defined in Section 5?

Regards,
S. Moonesamy

---

From: Yakov Shafranovich <[email-masked]>
Date: Sat, 28 Dec 2019 22:58:33 -0500

> disclosure policies.  Is the field defined in Section 3.5.6 optional?

All fields are optional except for the "Contact" directive so at a
minimum, there is a way to contact the organization even without a
published policy.

> file must be accessible using HTTP/1/0?

Are you saying we should only allow HTTP 1.1 or 2.0? If so, I would
argue that HTTP 1.0 must be allowed.

> also applies to to IPv4 and IPv6 addresses.

Being that it is referencing the URI format, the intent is the host as
per section 3.2.2 of RFC 3986. That would include both domain names
and IP addresses. We would need to clarify the language to match.

> defines a machine-parsable format?

There is an ongoing issue with some systems supporting CRLF and some
only LF, which is why we defined in a more fluid way. This is somewhat
similar to section 3.5 in RFC 7230 (HTTP 1.1):

   Although the line terminator for the start-line and header fields is
   the sequence CRLF, a recipient MAY recognize a single LF as a line
   terminator and ignore any preceding CR.

> Why does the robustness principle require capital letters? (Section 4)?

I am not sure about this question - can you clarify?

> registration (Section 7.2) provides value?  What is the "wider

Well, from the various feedback received so far, there are certainly
strong opinions expressed whether the proposal itself and many of its
parts provide value at all :)

All jokes aside, we didn't want the registry to be a free for all via
"First Come First Served" on the one extreme, and be completely
restricted ("IESG Approval") on the other extreme. We felt an expert
review would provide the right amount of oversight so something crazy
doesn't get shoved into the registry. A good example of this would be
a proposal of a directive indicating that the researcher doesn't have
permission to test any of the assets - something we couldn't reach
consensus on earlier. This would be something that would benefit from
a review by someone versed in security and standards.

The wider community would be the researchers and organizations using
this format.

> "i-default" is not a specific language.

The reference is to the following language in RFC 2277:

   When human-readable text must be presented in a context where the
   sender has no knowledge of the recipient's language preferences (such
   as login failures or E-mailed warnings, or prior to language
   negotiation), text SHOULD be presented in Default Language.

And:

   Messages in Default Language MUST be understandable by an English-
   speaking person, since English is the language which, worldwide, the
   greatest number of people will be able to get adequate help in
   interpreting when working with computers.

   Note that negotiating English is NOT the same as Default Language;
   Default Language is an emergency measure in otherwise unmanageable
   situations.

Basically, we wanted to come up with a safe default and that was the
best reference that seemed to indicate that English may be used in
this case.

> comply with the ABNF defined in Section 5?

The earlier versions of the draft allowed contact information without
the full URI which is why the current draft calls this out. In the
ABNF grammar (section 5), URI references RFC 3986. The assumption is
that this reference also includes the IANA and all relevant RFCs that
define URIs, since it would be impractical to list all of them out in
our draft. Perhaps, the use of RFC 2119 keywords in this specific
section may not be needed, since the MUST for URI syntax would be
sufficient.

Thanks

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 29 Dec 2019 09:07:13 +0100

On Dec 28, 2019, at 18:58, S Moonesamy <[email-masked]> wrote:
> 
> Have the authors considered line limits given that the specification defines a machine-parsable format?

Don’t do that (putting in artificial limitations into a new spec can sometimes be faintly legitimized by legacy considerations, such as in MIME 8bit, but usually only has negative consequences).

> Why does the robustness principle require capital letters? (Section 4)?

I don’t see a reference to RFC 1123 there.  I think the BCP14 language in that section is justified, with the possible exception of

   Any directives registered
   via that process MUST be considered optional.

(What?  Considered by whom?  What does “considered optional” actually mean?  Does “that process” include the directives registered by the proposed document?)

.oOo.

Obviously, I’m not a fan of standardizing yet another ad-hoc parser, but this may be legitimized here by legacy considerations.  (I believe the CRLF handling is appropriate.) I also see the problems with staleness and verification.
I think requiring a mandatory expiration date in every security.txt could help a bit with the staleness issue.

I also believe this text need some good reread.  E.g., the following two sentences lead to obvious nonsense: »   This text file contains multiple directives with different values.
   The "directive" is the first part of a field all the way up to the
   colon ("Contact:") and follows the syntax defined for "field-name" in
   section 3.6.8 of [RFC5322].  «
Do the values really need to be different?  Isn’t the file containing fields, not just the directives (which demonstrates that “directive” is a bad name for a directive name)?

Grüße, Carsten

---

From: S Moonesamy <[email-masked]>
Date: Sun, 29 Dec 2019 01:38:42 -0800

Hi Yakov,

Thank you for the quick feedback.

>minimum, there is a way to contact the organization even without a

The issue identified in the draft is the lack of mechanisms (or 
methods) for "security researchers" to "locate disclosure policies 
and contact information for organizations in order to report security 
vulnerabilities.  It doesn't make sense to make the publication of 
disclosure policies optional as it creates uncertainty.  Furthermore, 
the "SHOULD consult the organization's policy" recommendation in 
Section 6.7 does not carry much weight when such information is, by 
default, inaccessible.

>argue that HTTP 1.0 must be allowed.

I was actually asking about the meaning of the requirement as the 
ambiguity leaves the door open to questions such as the above-mentioned one.

>and IP addresses. We would need to clarify the language to match.

Ok.

>similar to section 3.5 in RFC 7230 (HTTP 1.1):

Ok.

>I am not sure about this question - can you clarify?

There is a reference to RFC 793.  Section 2.10 of that document 
contains a statement about the robustness principle.

>parts provide value at all :)

It can happen. :)

>The wider community would be the researchers and organizations using

The above explanation is different from the guidance provided in the 
draft for the review of a new field.  You have an idea of what you do 
not wish to see.  I suggest finding the appropriate wording for the criteria.

>best reference that seemed to indicate that English may be used in

I am not sure whether the assumption in the last two paragraphs is 
still valid.  Sometimes, there are strong views about that topic.

>section may not be needed, since the MUST for URI syntax would be

Ok.

Regards,
S. Moonesamy

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 30 Dec 2019 21:04:47 -0500

> Thank you for the quick feedback.

Thank you! I am making changes in Github for now with an expectation
of a new draft being published once all feedback has been
incorporated.

> Section 6.7 does not carry much weight when such information is, by

Phillip Hallam-Baker pointed a similar issue out related to the title
of the draft and the use of the term "policy":
https://mailarchive.ietf.org/arch/msg/last-call/DOH5NHcDKeQEVGpWox43w1BHOrE

Currently I am thinking of changing the title to: "A Format for
Describing Vulnerability Disclosure Practices". With this, contact
information would be the bare minimum with an organization's policy a
highly recommended thing to include (SHOULD). Because some
organizations do not want to disclose their policy publicly, the
contact information would be the starting point for a researcher.

> ambiguity leaves the door open to questions such as the above-mentioned one.

I would change it to read: "for web-based services, the file MUST be
accessible via the Hypertext Transfer Protocol (HTTP) 1.0 [RFC1945] or
higher version,"

> >and IP addresses. We would need to clarify the language to match.

I would change it to read: ""MUST only apply to the domain or IP
address in the URI used to retrieve it"

> contains a statement about the robustness principle.

Fixed to use lower case

> not wish to see.  I suggest finding the appropriate wording for the criteria.

I am rewording this as:
"Designated Experts are expected to check whether a proposed
registration or update
makes sense in the context of industry accepted vulnerability
disclosure processes
such as {{ISO.29147.2018}} and {{CERT.CVD}}, and provides value to organizations
and researchers using this format."

> still valid.  Sometimes, there are strong views about that topic.

Some sort of a sane default would be needed here even if it's not
perfect. The interpretation described above seems to be similar to
what other drafts are doing. For example, see section 2.7 here:
https://tools.ietf.org/html/draft-ietf-secevent-http-push-07

   If the SET Transmitter did not send an
   "Accept-Language" header, or if the SET Recipient does not support
   any of the languages included in the header, the SET Recipient MUST
   respond with messages that are understandable by an English-speaking
   person, as described in Section 4.5 of [RFC2277].

Thanks!

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 30 Dec 2019 22:12:41 -0500

> (What?  Considered by whom?  What does “considered optional” actually mean?  Does “that process” include the directives registered by the proposed document?)

The concern was that once the draft is published, defining additional
required fields via the registry may lead to compatibility issues
between the people doing the publishing and the researchers parsing
the files. However, since the next sentence says that people
reading/parsing the file should ignore anything not supported, perhaps
this is not needed?

"To encourage extensibility and interoperability, implementers MUST
ignore any fields they do not explicitly support."

> I think requiring a mandatory expiration date in every security.txt could help a bit with the staleness issue.

That is a great idea, I am going to add an "Expires" field to the
draft and some language in the security section around that as well.

> Do the values really need to be different?  Isn’t the file containing fields, not just the directives (which demonstrates that “directive” is a bad name for a directive name)?

Will address this by calling them fields, names and values instead of directives

On Mon, Dec 30, 2019 at 10:10 PM Nightwatch Cybersecurity Research
<[email-masked]> wrote:
>
> On Sun, Dec 29, 2019 at 3:07 AM Carsten Bormann <[email-masked]> wrote:
> The concern was that once the draft is published, defining additional
> required fields via the registry may lead to compatibility issues
> between the people doing the publishing and the researchers parsing
> the files. However, since the next sentence says that people
> reading/parsing the file should ignore anything not supported, perhaps
> this is not needed?
>
> "To encourage extensibility and interoperability, implementers MUST
> ignore any fields they do not explicitly support."
>
> > .oOo.
> >
> That is a great idea, I am going to add an "Expires" field to the
> draft and some language in the security section around that as well.
>
> Will address this by calling them fields, names and values instead of directives