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

[Benjamin Kaduk <[e-mail]>]

Hi Michael,

On Tue, Jun 30, 2020 at 11:03:44PM -0400, Michael Richardson 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 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