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

[Benjamin Kaduk <[e-mail]>]

On Thu, Jul 02, 2020 at 12:12:27PM -0400, Michael Richardson wrote:
> 
> Benjamin Kaduk <[e-mail]> wrote:
>     >> Benjamin Kaduk <[e-mail]> 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 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.

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.

>     > 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.
> 
> I agree with your optimism.
> 
>     >> 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).
> 
> 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.

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

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