Re: [Secdispatch] Review of draft-foudil-securitytxt

[Yakov Shafranovich <[e-mail]>]

Hi Kathleen,

Thank you for volunteering to review our document. It is very much appreciated.

On Mon, Jul 23, 2018 at 12:09 PM, Kathleen Moriarty
<[e-mail]> wrote:
...
>
> Section 3:
>
> I'd prefer to see that TLS is required in with the statement:
>    the instructions MUST be accessible via the Hypertext
>    Transfer Protocol [RFC1945] as a resource of Internet Media Type
>    "text/plain" with the default charset parameter set to "utf-8" per
>    section 4.1.3 of [RFC2046].
>
> And since that's really hard to enforce, I think using RECOMMENDED at a
> minimum here and in many of the places SHOULD appears in the document would
> be better.  I know the meaning is similar, but I think it sounds a bit
> stronger.
>

Because it is hard to enforce, we choose SHOULD in some places. I
don't see an issue with changing that language to RECOMMENDED and
opened an issue to track this and other recommendations:
https://github.com/securitytxt/security-txt/issues/118

>
> It looks like it is permissible to retrieve the file using HTTP only from
> examples.  This has probably been discussed, but I am curious as to the
> reasons.
>

I assume you are referring to section 3.1 (in the -04) draft:

   # This security.txt file applies to IPv4 address of 192.0.2.0.
   http://192.0.2.0/.well-known/security.txt

   # This security.txt file applies to IPv6 address of 2001:db8:8:4::2.
   http://[2001:db8:8:4::2]/.well-known/security.txt

It is probably an oversight due to the fact that it is not clear if
SSL certificates can be issued for IP addresses, although I see that
CloudFlare got one for "https://1.1.1.1" using a Subject Alternative
Name (SAN). LetsEncrypt however, doesn't allow them:
https://community.letsencrypt.org/t/certificate-for-public-ip-without-domain-name/6082/82

We can probably change to "https", and if someone is unable to get an
SSL cert, they will end up using "http".

> Section 3.8 seems odd as most would look to a companies job listings rather
> than use this as a source for information that should be timely.  The
> vulnerability disclosure procedures are likely to be static for long periods
> of time and hiring isn't necessarily.
>

When the initial adoption of our proposal started among larger
companies, some of them added this field as a way to attract security
researchers to work for them. This was added to the draft in order to
document that usage, even though it was somewhat unorthodox.

> 4.3.  Internal hosts READS:
>
>    A .security.txt file SHOULD be placed in the root directory of an
>    internal host to trigger incident response.
>
> The .security.txt doesn't trigger the response, but rather provides
> information on the steps for disclosure with the organization, correct?
>

We will re-word this. In the discussions around the earlier drafts
there was some mention about scope and IR may have been included, but
certainly in the current version and going forward, the scope is
disclosure only.

Thank you