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

From: "Salz, Rich" <[email-masked]>
Date: Mon, 9 Dec 2019 17:55:54 +0000

>    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]

I don't know if this is substantive or not, but OpenSSL has provided this since Feb 2018.  I strongly support this draft.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 9 Dec 2019 18:07:51 +0000

On 09/12/2019 17:55, Salz, Rich wrote:
> I strongly support this draft.

I also support publication. (Not so strongly though:-)

S.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 11 Dec 2019 11:40:23 +0100

On Mon, Dec 09, 2019 at 05:55:54PM +0000,
 Salz, Rich <[email-masked]> wrote 
 a message of 11 lines which said:

> I don't know if this is substantive or not, but OpenSSL has provided
> this since Feb 2018.  

% wget https://www.openssl.org/.well-known/security.txt

% wget https://www.openssl.org/news/openssl-security.asc

% gpg --import openssl-security.asc

% wget https://www.openssl.org/.well-known/security.txt.asc

% gpg --verify security.txt.asc  security.txt    
gpg: Signature made Thu Jan  4 04:22:26 2018 CET
gpg:                using RSA key EFC0A467D613CB83C7ED6D30D894E2CE8B3D79F5
gpg: BAD signature from "OpenSSL OMC <[email-masked]>" [unknown]

This illustrates a common problem with all similar schemes: these
files tend to rot.

Still, I support the draft (the above issue is well described in
section 6.2).

---

From: Paul Wouters <[email-masked]>
Date: Wed, 11 Dec 2019 10:26:37 -0500 (EST)

> This illustrates a common problem with all similar schemes: these

This is one of the reasons I have brought up during the discussion why
this proposal is not a good idea at all. It just provides more places
with more non-standard types of unverified, obsolete or malicious
information that are especially untrustworthy when needing to report a
compromise. The information simply can never really be trusted.

To report issues with compromised servers, don't depend on the
compromised servers. Use DNS or WHOIS/RDAP as that is more independent
of the web servers. It has the additional benefit of being rather
independant of the web farm of the entity you are looking to contact.

If the data is openpgp signed, I still need another place and entity to
verify the key is not something the attacker installed.

I'm not often against a proposal - after all it is better to try and fail
and try something new than not to try. But in this case, the result of
a failed experiment is damaging. Some will assume people look at this
new location for secure data. Some will assume it secure. Heaven forbid
browsers will make this available to endusers in an automated way. It will
be stale as can already be seen here. It just adds another questionable
source of information and we do not need more of these. That is why in
this case, I am against publication of this document.

Also, if I look at the practical way of contacting large organisations
about things, people already have a good set of patterns, and I am not
convinced this problem needs solving - and surely not in this way.

1) Using twitter. Those twitter accounts are acively monitored by people
    who can reach the right person for the right issues. I have a very
    high success rate contacting Fortune500 companies this way.

2) Using the About or Contact page on the company website.

3) Use LinkedIn. Instead of using the "Hiring" field in a security.txt file
    on a company's webserver, people will use LinkedIn, or the company's
    Jobs page or About page. Even for security issues, contacting someone
    of the company at Linked In might give a more reliable contact that
    is independent of the entity's web or mail servers that might be
    compromised.

Only a handful of geeks will ever look at this new .well-known location
with quickly diminishing returns. It's simply not a good enough idea
and it will result in more broken and obsolete data being published (and
harvested for spam). Having remnants of the failed experiment lying around
is harmful.

I recommend NOT publishing this document.

Paul

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 11 Dec 2019 10:31:49 -0500

Hi Paul,

Thank you for your detailed comments.  Your objection has been noted in the
shepherd writeup with links to prior emails sent to the list.

Best regards,
Kathleen (shepherd hat on)

-- 

Best regards,
Kathleen

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 11 Dec 2019 16:08:19 +0000

files tend to rot.
  
Already noted and there are plans to address it; https://github.com/openssl/web/issues/145

---

From: Randy Bush <[email-masked]>
Date: Wed, 11 Dec 2019 09:03:10 -0800

> compromise. The information simply can never really be trusted.

agree.  pushing back against this untrustable, though well intentioned,
hack yet again.  paul says it all.

randy

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 11 Dec 2019 14:01:24 -0500

> compromise. The information simply can never really be trusted.

To be clear, the scope of the draft is not about *compromised* servers
- rather it is about reporting vulnerabilities. As described in the
CERT CVD guide referenced in the draft, these are not the same thing.
This point was made earlier during the discussion on the SAAG list:
https://mailarchive.ietf.org/arch/msg/saag/zl7ZFk4esY-O-q6qHLgErVThvbE

"Incident vs. Vulnerability Response

Sometimes the term "Incident Response" is used synonymously with
Vulnerability Response. These two concepts are related, but different;
Vulnerability Response specifically indicates responding to reports of
product vulnerabilities, usually via the CVD process, whereas Incident
Response is more general and can also include other security events
such as network intrusions. We will generally stick to the
Vulnerability Response terminology since this work is specifically
about CVD."

Thanks

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 11 Dec 2019 14:13:01 -0500

Yes, the Achilles heel of security policy today is knowing if it is
accurate or not.

But consider the fact that for all existing Internet protocols, the default
is insecure. That means that we have two possible approaches to moving to a
default secure internet:

1) Replace every existing Internet protocol with one that is default secure.

2) Work out how to make security policy work.

Designing a complete replacement protocol suite is not impossible. In fact
I have done exactly that. But as we all know, deployment of such a suite is
another matter. So if we are to make the Internet default secure, we need
to focus on (2).

One possible fix for this situation is to add an attribute to security
policies that describes the preparation mechanism so that relying parties
can handle the resulting assertions appropriately and includes a time stamp.

But really, it is not a problem if people misconfigure their network and
their systems fail as a result. In fact that is the desired outcome here.

The key to making security policy accurate is to automate the process of
publishing it. So the infrastructure that is responsible for bringing up a
service host also causes the corresponding DNS records to be provisioned.

This doesn't have to be a pipe dream, this is exactly the sort of thing
that kubernetes and such are supposed to be up to. I go a stage further
with the Mesh Service management architecture because I don't want my host
images to contain the private keys used for TLS, host authentication etc.
Right now this is slideware but I think it shouldn't take too long to make
it real:

* Host image has a unique set of device base key contributions.

* Each time the host image is started, it contacts the management service
and obtains a set of activation key contributions .

* The keys used by the host for TLS, service authentication, etc. etc. are
generates as a combination of the base key contributions and  activation
key contributions

* Once the host is ready to process service requests it notifies the
management service

* The management service performs any network configuration changes that
may be required to enable service (e.g. firewall rules).

* The management service calculates all the necessary DNS entries including
security policy entries for the service and publishes them (and publishes
any other entries in other services that might be required).

* The management service monitors the status of the host continuously and
reacts appropriately in the case that it should fail.

* The management service reverses all the above in the case that the
service is shut down (with appropriate handling of planned and unplanned
termination).

Personal note:

We are 1/5th the way through the 21st century at this point. It is long
past the point where we can or should consider manual configuration of
Internet hosts and service as being normal practice. The idea that those of
us who manage our systems in a maintainable fashion should be required to
accommodate the folk trying to do things by hand is bunk.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 11 Dec 2019 21:32:56 +0100

On Wed, Dec 11, 2019 at 10:26:37AM -0500,
 Paul Wouters <[email-masked]> wrote 
 a message of 77 lines which said:

> compromised servers. Use DNS or WHOIS/RDAP as that is more
> independent of the web servers.

As Yakov Shafranovich explained, the goal is to report
vulnerabilities, not compromises.

And if you fear that the attacker is already inside, this is also true
for the DNS (remember the Middle-east hijackings at the end of 2018)
and even for Whois/RDAP. Nothing is perfectly secure.

> Some will assume people look at this new location for secure
> data. Some will assume it secure.

They are wrong, the draft is crystal-clear here, specially section
6.1. Yes, some people won't read the RFC but it is true for every RFC.

> Also, if I look at the practical way of contacting large
> organisations about things, people already have a good set of
> patterns, and I am not convinced this problem needs solving

Your experience here does not match mine, and it doesn't match the
experience of all the people who asked for such as draft, because they
were frustrated by the inability to contact a knowledgeable person. My
own experience is that there is not a perfect solution: we use whois,
DNS SOA, personal contacts, official organisations like ANSSI in
France, and sometimes rants on Twitter.

>    high success rate contacting Fortune500 companies this way.

I had some success with Twitter, too, but also many failures. Not to
mention the lack of privacy.

> 2) Using the About or Contact page on the company website.

I wonder if we live in the same world. This is probably the worst
solution. (My favorite: I reported a security issue, with copy/paste
of the HTTP exchange, and I was asked to provide a screenshot...)

>    is independent of the entity's web or mail servers that might be

Using Microsoft does not seem much better than using Twitter,
privacy-wise.

> with quickly diminishing returns.

A few paragraphs before, you said that too many people will use
security.txt...

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 11 Dec 2019 16:17:36 -0500

I support publication of the document provided that it is renamed.

The current title is confusing as what is described is not a security
policy according to the accepted term of art. It may contain a link to a
policy but that is not the primary subject matter. The term 'security
description' is a possible alternative.

I would also suggest that in addition to publication via the .well-known
scheme, there is a means of publication through an appropriately prefixed
TXT record specifying an alternative URI. While HTTP service is ubiquitous,
it is not universal. More to the point, it is highly likely that the target
Web site is unavailable if there is an attack in progress.

On Mon, Dec 9, 2019 at 12:39 PM The IESG <[email-masked]> wrote:

>
> 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
>
> [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.
>
>
>
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 11 Dec 2019 17:16:18 -0500

On Wed, Dec 11, 2019 at 4:17 PM Phillip Hallam-Baker
<[email-masked]> wrote:
<snip>
> I would also suggest that in addition to publication via the .well-known scheme, there is a means of publication through an appropriately prefixed TXT record specifying an alternative URI. While HTTP service is ubiquitous, it is not universal. More to the point, it is highly likely that the target Web site is unavailable if there is an attack in progress.
>

Publishing via DNS has been considered and discussed several times
during the development of this draft. Because consensus couldn't be
reached, we made a decision to exclude DNS from this draft and plan to
address this via a separate draft in the future.

Thank you!

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 12 Dec 2019 16:26:42 +0100

On Wed, Dec 11, 2019 at 09:32:56PM +0100,
 Stephane Bortzmeyer <[email-masked]> wrote 
 a message of 67 lines which said:

> My own experience is that there is not a perfect solution: we use
> whois, DNS SOA, personal contacts, official organisations like ANSSI
> in France, and sometimes rants on Twitter.

For the record, security.txt is mentioned in some national
regulations. The US one was already referenced here, but this is also
used in France :

https://www.legifrance.gouv.fr/eli/arrete/2018/9/18/ECOP1825228A/jo/texte

Requirments for public procurement on cybersecurity
...
For the notifications to be real and efficient, standard agreements on
cybersecurity must be used (security.txt, ABUSE@).

---

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

On Sat, Dec 28, 2019 at 1:02 PM S Moonesamy <[email-masked]> wrote:
>
> 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?
>

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.

> 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?
>

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.

> 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.
>

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.

> 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?
>

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?

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

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.

> 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.
>

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.

> 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?
>

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: Yakov Shafranovich <[email-masked]>
Date: Mon, 30 Dec 2019 20:44:46 -0500

On Wed, Dec 11, 2019 at 4:17 PM Phillip Hallam-Baker
<[email-masked]> wrote:
> The current title is confusing as what is described is not a security policy according to the accepted term of art. It may contain a link to a policy but that is not the primary subject matter. The term 'security description' is a possible alternative.
>

This is a valid point - I am currently considering the title: "A
Format for Describing Vulnerability Disclosure Practices" as a better
alternative.

---

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

On Sun, Dec 29, 2019 at 4:39 AM S Moonesamy <[email-masked]> wrote:
>
> Hi Yakov,
>
> 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.

> At 07:58 PM 28-12-2019, Yakov Shafranovich wrote:
> 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.
>

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.

> 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.
>

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,"

> Ok.

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

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

Fixed to use lower case

> 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.
>

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."

> I am not sure whether the assumption in the last two paragraphs is
> 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

On Sun, Dec 29, 2019 at 3:07 AM Carsten Bormann <[email-masked]> wrote:
> On Dec 28, 2019, at 18:58, S Moonesamy <[email-masked]> wrote:
>
>    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?)
>

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.
>
> 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.
>

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.

> 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)?
>

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:
> > On Dec 28, 2019, at 18:58, S Moonesamy <[email-masked]> wrote:
> >
> >    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?)
> >
>
> 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.
> >
> > 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.
> >
>
> 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.
>
> > 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)?
> >
>
> Will address this by calling them fields, names and values instead of directives