Re: [dispatch] Proposal for scantxt; scanning opt-in/out, identification, verification, notification, and reporting

[Ollie IETF <[e-mail]>]

> Most scanning is in practice malicious, even if the
> people doing the probing make excuses that it isn't.

Perhaps generic probing is mostly malicious but if you include services that people and businesses often use or sign up for, it likely isn't all that malicious. Consider the following as scanners (not recommendations, just examples): MXToolBox, Detectify, Hardenize, Snyk

> I can see why the people doing the scanning would
> want all this stuff, but I can't see why the victims of
> the probes would have any reason to go to any effort
> to make their lives easier.

I do agree with Stephen that I've perhaps overcomplicated this and the level of choice suggested is bloated/unnecessary.
The original intention for scantxt wasn't actually for allowing or disallowing different types but for the other features which I'll break down a little here from the 'victims' point of view:

Opt-out: many legitimate scanners (also consider synchronous scanning where you enter your domain/IP into a service to check configuration etc.) allow opting out but that often requires an account and verifying you own the asset in some way. Scantxt is a proposal to standardise that opt-out so that users can do so in an asynchronous, consistent way without requiring an account or direct communication with each scanner.

Identification: users may wish to look up activity against their assets to understand the intention, if they agree the scanning is useful, they could view guidance published by the scanner on how to configure reporting and notifications to receive findings.

Verification: simply adding a header saying "im-this-scanner.com" and could be easily spoofed. Users may want a way to verify a legitimate scan, perhaps they have signed up for or even purchased a service.
Scanners would include a "Scanner-Token" which would ideally be a signed JWT of {"iss": "SCANNER", "iat": epoch, "aud": "VICTIM"}
This token could then be retrieved and the signature verified with the public key from the actually scanner, this step could even happen at the edge of infrastructure including firewalls/WAFs so that the activity is allowed through and not blocked automatically.

Notifications/reporting: this allows the user to asynchronously configure endpoints directly against infrastructure in their control without having to create an account with each scanner.
As a user who sees scanning, even from services I've signed up for, I want a way to receive issues found by that scanner without having to create an account and verify my asset with every scanner.
The rua/ruf suggestion allows sending reports (either email attachments or HTTP POST) in a consistent way that can be retrieved and analysed easily.

Where they types came in was if for example I ran a site where I cared about uptime and user data but I also wanted to advocate for more scanning and reports, I could direct scanners to replica infrastructure for the purpose to reduce the risk of impact to my actual site.
Let's say I'm "example.com", I could say on "_scan.example.com" - "hey, don't do active stuff here, but check out free-all-all.example.com instead" where "_scan.free-for-all.example.com" says "sure, send me any exploits/load testing etc. and notify me of findings here..."

Thanks,
Ollie