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

[Michael Richardson <[e-mail]>]

Benjamin Kaduk <[e-mail]> wrote:
    >> >> 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...

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

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

Good! We agree then.

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


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-