Subject: [saag] results of IETF LC for draft-foudil-securitytxt-08 and next steps

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 30 Jun 2020 15:24:55 -0700

I'm happy to see the updates in the -09 that addressed most of the
discussion and feedback that came out of the IETF LC.  What follows are my
takeaways from the last call and discussion of what seems left to do before
the document can progress to IESG Evaluation.

One recurring concern during the IETF LC was that deployments of this
mechanism would fail to get updated, eventually becoming so stale so as to
be harmful.  I'm happy to see the addition of the "Expires" directive that
mitigates this risk, but I think we should make its presence required, and
additionally give some guidance that the expiration date should not be "too
far" into the future, perhaps capping it (at a "RECOMMENDED" level) to at
most a year in the future.  (Note that Section 6.2 has a bit of text that
assumes Expires is not mandatory, in addition to the field definition in
Section 3.5.5.)

Similarly, the refocusing on having the file be targeted at humans allows
for us to reiterate that human judgment is key in deciding when to use the
contents of a security.txt file vs. seeking other reporting mechanisms.
This applies for old/expired files, of course, but also to the recurring
topic of reporting compromise vs. reporting vulnerability.  When reporting
compromise, extra caution is needed, and there is probably some more that
can be said in Section 6.1 (see next paragraph).

The topic of use for reporting compromise vs. vulnerability was raised by
many reviewers, to the extent that it seems like it would be very
challenging to craft text that would definitively convince the reader to not
use the contents of the files for reporting cases of active compromise, or
even cases of vulnerability that would easily lead to active compromise.
Given that Section 1.1 is entitled "Motivation, Prior Work and Scope", it
seems like a very good place to put a notice that "reporting compromised
resources (e.g., web sites) is related to, but distinct from, reporting
security vulnerabilities; the mechanism defined in this document is intended
for reporting vulnerabilities.  If it is used to report cases of active
compromise, or vulnerabilities that would lead to compromise of the
system(s) involved in this mechanism, additional considerations apply, as
discussed in Section 6.1".  To expound on the nature of these considerations
a bit more, when there is (the possibility of) active compromise, the
"ambient authority" granted by finding the contents of the file at the given
domain or other location is no longer trustworthy.  In such cases, we should
expect there to be an "additional source of authority" (or "trust chain")
that can give a sense of confidence in the reliability of the contents
therein.  A PGP cleartext signature is already recommended and can be one
such additional source of authority (provided that there is a trust path to
the key that made the signature); other routes to such additional sources of
authority were posited in the review comments, such as putting a
cryptographic hash of the security.txt contents in the DNS under a DNSSEC
signature.  I think that requiring such an additional source of authority
(though not a specific mechanism thereof) would go a long way to alleviating
concerns of misuse of security.txt from compromised systems.  However, I'm
not entirely sure how practical it would be to impose such a requirement
given the current state of defined mechanisms.  I'm hoping to get some more
feedback from the community on this topic, having framed it in this way --
the previous discussion seemed focused on other aspects of the problem and
did not get very far towards a concrete resolution.  At the very least, we
will need more discussion that specifically in case of compromise, the
"additional source of authority" is the only source of authority.  I would
expect this text to go in Section 6.1.

Finally, I see that (while Section 3 is clear about "MUST be accessed with
the 'https' scheme"), in Section 6.6 we went from "MUST use HTTPS" to
"should use HTTPS", and since my review of the LC discussion was
(unfortunately) spread out in time I have forgotten what comment prompted
that change.  It would probably be worth some mention of the expected
case(s) where HTTPS would not be used (e.g., when it's local file or other
non-HTTP access), to strengthen the argument for using HTTPS the rest of the
time.  (Possibly related to
https://github.com/securitytxt/security-txt/issues/177 )

Some other minor comments from the IETF LC that may be worth addressing:

David Rogers pointed out that by creating a semi-automatable
.well-known/security.txt mechanism, we may be implicitly disincentivizing
public-facing pages like /security that give more robus information or are
accessible to a wider audience.  A disclaimer that there is not intent to
discourage such publicly navigatable pages could be useful.

Michael Richardson noted that the scope of contact information is/can be
broader than just the website hosting the file -- e.g., it would be very
useful to have a discoverable way to report vulnerabilities in the products
produced by a company, not just the company's website.  It is probably worth
a mention that (or disclaimer against) the scope of use is potentially
broader than just the immediate website hosting the file.  (This seems
related to https://github.com/securitytxt/security-txt/issues/185 and might
result in some text in Section 3.1.)

Mark Nottingham also had a late-breaking comment about the .well-known
namespace being "registration required" (and security.txt.sig not being
proposed for registration), suggesting that we add a note to remind people
about this (https://github.com/securitytxt/security-txt/issues/188).

And finally, a few additional comments from reading the -09:

Section 3

   "field-name" in section 3.6.8 of [RFC5322].  Fields are case-
   insensitive (as per section 2.3 of [RFC5234]).  The "value" comes

nit: I think it's just the "Field names" that are case-insensitive.

Section 3.1

   For HTTP servers, a "security.txt" file MUST only apply to the domain
   or IP address in the URI used to retrieve it, not to any of its
   subdomains or parent domains.

[Depending on how the discussion about "product vs. website vulnerabilities"
resolves, this might need to grow a disclaimer that it's about the HTTP
resources at those domains.]

Section 4.1

   Researchers should perform additional triage (as per Section 6.1) to
   make sure these redirects are not malicious or point to resources
   controlled by an attacker.

nit: s/point/pointing/

Section 6.6

   (as per Section 3.4).  Also, to protect security reports from being
   tampered with or observed while in transit, organizations should
   specify encryption keys (as per Section 3.5.4) unless HTTPS is being
   used.

I think we should clarify that this is "HTTPS is being used for report
submission".

Thanks,

Ben

---

From: Michael Richardson <[email-masked]>
Date: Tue, 30 Jun 2020 23:03:44 -0400

Benjamin Kaduk <[email-masked]> wrote:
    > use the contents of the files for reporting cases of active compromise,

When you say, "reporting compromise" do you think that reviewers/commenters
were limiting this to talking about reporting that example.com (where you
found security.txt) is compromised, or is it about any part of example.com?

I ask because there is a continuity of things between for instance,
  1) reporting that Example.COM "Smart" refriderators are vulnerable (and
     maybe have been compromised already),
  2) to reporting that gitlab.example.com (where the fridge source code is
     kept) is running a potentially vulnerable version of gitoris,
  3) to reporting that update.example.com (where the signed images are kept)
     is full of trojaned code
  4) to reporting that smtp.example.com seems to forward malware through
     the mailing lists maintained there
  5) to reporting that www.example.com has been p0wned.

My observation is that most of the discussion ratholed around (5),
completely ignoring other benefits.  I don't think that any amount of text we
put in will help, because it won't really get read by the *reporter*
I don't think that reporters really will understand any line we might think
we can draw.

    > https://github.com/securitytxt/security-txt/issues/177 )

My take:
  We can't get publically anchored certificates for devices without DNS names,
  such as those that might be found in your home on RFC1918 addresses.  The
  teddy cam can still have a securitytxt on it to report issues.

    > result in some text in Section 3.1.)

If the IETF *does not* want securitytxt used for reporting vulnerablities,
then the IETF had better say so loudly VERY SOON, and probably communicate through
liason to ETSI, IoTSF and UK NCSC about that... although EN 303 645 does not
mention securitytxt by name, the (not-quite-finished, not released)
educational material around it *does* mention it.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-