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

[Kathleen Moriarty <[e-mail]>]

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)

On Wed, Dec 11, 2019 at 10:26 AM Paul Wouters <[e-mail]> wrote:

> On Wed, 11 Dec 2019, Stephane Bortzmeyer wrote:
>
> >> 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 <[e-mail]>"
> [unknown]
> >
> > This illustrates a common problem with all similar schemes: these
> > files tend to rot.
>
> 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
>


-- 

Best regards,
Kathleen