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 <paul@xxxxxxxxx> 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 <openssl-omc@xxxxxxxxxxx>" [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
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
