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

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 1 Jul 2020 20:48:28 -0700

Hi Michael,

On Tue, Jun 30, 2020 at 11:03:44PM -0400, Michael Richardson wrote:
> 
> Benjamin Kaduk <[email-masked]> wrote:
>     > 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,
> 
> 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?

My understanding is that that's what was so controversial, yes.  (Note that
the draft is quite clear that https://example.com/.well-known/security.txt
does not apply to *.example.com, and one of the points I'd like further
clarifying text on is whether the file on the web is useful for non-web
stuff.)

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

Indeed, and well said.

> 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

I agree.  Note that I myself was not fully clear on these cases in my
writeup -- I mentioned compromise in the context of "systems involved in
retrieving security.txt" in one place but just the (presumed broader scope)
"compromise" in the high-level summary.

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

I think a lot of what we're hoping for relies on human judgment and not
blindly trusting something without cause.  Call me an optimist, but I think
there's at least some of that going around, and possibly even more than
average if you limit to the "security researcher" community.

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

That seems pretty aligned with my best guess, involving cases where https
was not possible (whether because it's going via filesystem access and not
web, or the device only has an IP address and not a name, or whatever).

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

Indeed.  (That's not the sense I'm getting, though, luckily.)

Thanks,

Ben

---

From: Michael Richardson <[email-masked]>
Date: Thu, 02 Jul 2020 12:12:27 -0400

> clarifying text on is whether the file on the web is useful for non-web

I believe that it is useful as a point of contact for all things related example.com.
I don't understand limiting it the way that 3.1 says.
It feels like this limitation is the result of some comment.
I guess I would like to have a statement that either restricts the scope
to where it is found, or not.  It might also be worth indicating if it is
worth looking for subdomain.example.com/.well-known/security.txt or not.

    > average if you limit to the "security researcher" community.

I agree with your optimism.

    > web, or the device only has an IP address and not a name, or whatever).

Okay, but if the teddycam at 192.168.1.104, has a security.txt, then it can
only apply for reporting vulnerabilities in *that* TeddyCam, since other
Teddy Cams would be at different addresses, according to section 3.1.

    > Indeed.  (That's not the sense I'm getting, though, luckily.)

Please clarify... too many negatives to parse.

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 2 Jul 2020 15:20:32 -0700

> worth looking for subdomain.example.com/.well-known/security.txt or not.

The authors may remember better than I do, but I think this came up due to
corporate scenarios where division A and division B don't talk to each
other much, so a single corporate contact point/plan wouldn't work.

I also think it would be useful to have the web's /.well-known/security.txt
provide a contact point for non-web resources (such as physical devices),
but don't want to force my opinion on people if it's not the consensus.

> Teddy Cams would be at different addresses, according to section 3.1.

Yes ... but any vulnerabilities in that one would also be expected to be
present in other instances of the same model, and if the contact point is
at the manufacturer, the manufacturer can do the right thing?
I feel like you have a downside in mind that I'm failing to spot...

> Please clarify... too many negatives to parse.

Sorry to be confusing.

I am seeing general support (in the rough consensus sense) in the IETF for
using securitytxt to report vulnerabilities, controversy about
reporting compromise or what precise scope it should have notwithstanding.

-Ben

---

From: Michael Richardson <[email-masked]>
Date: Fri, 03 Jul 2020 02:32:58 -0400

> I feel like you have a downside in mind that I'm failing to spot...

If a security.txt applies *only* to the web resource where you found it,
then that means it doesn't generalize to the other instances of that device.
That sounds dumb, and it is, but that's what I'm reading in section 3.1

    > reporting compromise or what precise scope it should have notwithstanding.

Good! We agree then.

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

---

From: Yakov Shafranovich <[email-masked]>
Date: Sun, 12 Jul 2020 20:14:33 -0400

On Tue, Jun 30, 2020 at 6:25 PM Benjamin Kaduk <[email-masked]> wrote:
>
> 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.
>

Before commenting on specific issues, I would like to thank Ben and
all of the IETF members who contributed to the discussion of our
draft. It is much appreciated. Specific comments appear in line below.

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

I think that makes sense, I am adjusting the language in the -10 draft
to match. I assume the one year recommendation is in line with what is
being currently done for TLS certificates?

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

I am adding this to sections 1.1. and 6.1, HOWEVER, my sense of the LC
comments is that using this file for incident response is ill advised
and should not be done. Perhaps, we should add a disclaimer that it
should not be used that way and leave it at that?

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

This was in response to Taro Kivinen's comment regarding reporting an
expired certificate:
https://mailarchive.ietf.org/arch/msg/last-call/C3MHndMJDDVNVdLQm6y57iPr79g/

I am changing the text below that to read:
"In cases where the "security.txt" file cannot be served via HTTPS
(such as being located in a filesystem or served from localhost) or is
being served with an invalid certificate, additional human triage is
recommended since
the contents may have been modified while in transit."

>
> 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 robust information or are
> accessible to a wider audience.  A disclaimer that there is not intent to
> discourage such publicly navigatable pages could be useful.
>

Adding a note around this

> result in some text in Section 3.1.)

I am adding a note to that effect addressing issue #185

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

Will do

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

Can you clarify this? The way I am reading RFC5234, it sounds like any
ABNF terminal characters are case-insensitive:

"NOTE:
      ABNF strings are case insensitive and the character set for these
      strings is US-ASCII."
"

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

As per a different comment, I am adding this text:
"A "security.txt" file MAY also apply to products and services
provided by the organization
publishing the file. Implementors SHOULD use the policy directive (as
per {{policy}})
to provide additional details regarding scope and details of their
vulnerability disclosure
process."

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

Will fix

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

Will fix

All of the changes I am making are going into this pull request:
https://github.com/securitytxt/security-txt/pull/192

---

From: Yakov Shafranovich <[email-masked]>
Date: Sun, 12 Jul 2020 20:55:36 -0400

> That sounds dumb, and it is, but that's what I'm reading in section 3.1

The concern was that in a case where different parts of a website may
be owned by different customers, we didn't want customer A claiming
authority over customer B. This is well illustrated by Amazon's setup
for S3 where "domain.s3.amazonaws.com" is the same thing as
"s3.amazonaws.com/domain/".

With that being said, the intent is that the "Policy" directive can
point to an expanded policy document that would add more information
about scope. So in the case of the Teddy Cam, the "security.txt" file
would provide the absolute minimum but the policy directive can add
additional information.

Thanks

---

From: Yakov Shafranovich <[email-masked]>
Date: Sun, 12 Jul 2020 20:59:45 -0400

> "compromise" in the high-level summary.

This is why CERT's CVD makes the distinction between "vulnerability
response" and "incident response":
https://vuls.cert.org/confluence/display/CVD/1.2.+CVD+Context+and+Terminology+Notes

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

In our case, #1 and #2 and possibly #3 are "vulnerability response",
while #4-5 are "incident response". Our proposal is geared towards
"vulnerability response", although it can be used for both. I tried to
add additional verbiage to the next draft to make that more clear.

Thanks

---

From: Michael Richardson <[email-masked]>
Date: Sun, 12 Jul 2020 21:04:59 -0400

> "s3.amazonaws.com/domain/".

I understand.
also cf: "geocities" :-)

    > would provide the absolute minimum but the policy directive can add

okay, thank you, I'm happy with this.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 20 Jul 2020 22:41:21 -0700

Hi Yakov,

Thanks for the extra comments; some notes inline.

> being currently done for TLS certificates?

It was chosen pretty arbitrarily when I wrote it, actually :)
But the underlying reasons for needing to refresh things periodically are
similar between the two cases, so in some sense you found the right reason.

> should not be used that way and leave it at that?

In some abstract sense I agree that it is ill advised, but I do not think
that any words we write will stop everyone from trying to use it for
incident response.  So I think that even if we have such a disclaimer, in
order to be doing the responsible thing we'd still need to say something
about the risks of using it for incident response and our current best
thoughts about mitigating those risks.

> https://mailarchive.ietf.org/arch/msg/last-call/C3MHndMJDDVNVdLQm6y57iPr79g/

Ah, thank you for jogging my memory.

> the contents may have been modified while in transit."

Thanks, that looks to give a good picture of the relevant considerations.

>       ABNF strings are case insensitive and the character set for these

That's true for ABNF that we write ourselves, but it doesn't seem to be
true for all of the fields that we're defining.  Specifically, we use the
'uri' construction from RFC 3986 in several places, and as
https://tools.ietf.org/html/rfc3986#section-6.2.2.1 points out, in the
general case, many of the URI components are assumed to be case-sensitive.
While we could try to say something about the bits of field contents that
we do specify, it's probably easier to just talk about the Field names and
not make things too complicated.

> to provide additional details regarding scope and details of their

Sounds good, thanks.

> https://github.com/securitytxt/security-txt/pull/192

Thanks for the pointer; I've left that tab open and will try to take a look
tomorrow/in the morning.

Thanks again for all the updates,

Ben

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 29 Jul 2020 17:29:02 -0400

Apologizes for the delayed reply

> thoughts about mitigating those risks.

This is going to need some thinking - will take a look and get back to you

> not make things too complicated.

I will take a look again

> > > resources at those domains.]

Will watch this