[OPSEC] Paul Wouters' Yes on draft-ietf-opsec-indicators-of-compromise-03: (with COMMENT)

[Paul Wouters via Datatracker <[e-mail]>]

Paul Wouters has entered the following ballot position for
draft-ietf-opsec-indicators-of-compromise-03: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsec-indicators-of-compromise/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this document.

I just have a few nits/comments:

Why is figure 1 a pyramid ? I understand the "more and "less"
modifiers to "precise", "fragile" and "pain", but I don't understand
why one layer sits on top of another smaller layer. Especially seeing
domain names at 25M and SHA256 hashes at 5M, with domain names
being a smaller layer on top of SHA256 hashes ?

        This outlined recent exploitation of Fortinet [FORTINET]

I would change "Fortinet" to something not identifiable to a single
vendor. No need to shame them for a decade while this RFC is current.

        28 million of them were for domain generation algorithms (DGAs)

It wasn't for the algorithms but for the domains generated by such algorithms.
Perhaps:  28 million of these were for domains generated by known domain
generation algorithms (DGAs)

        Other IoCs, like Server Name Indicator values in TLS or the
        server certificate information, also provide IoC protections.

This sentence is in a section that talks about DNS and blocking at an
upstream DNS layer, but that does not apply to SNI/TLS. Perhaps this needs
its own section or be moved elsewhere? It now appears SNI can be blocked
by a DNS server.

        Note too that DNS goes through firewalls, proxies and possibly
        to a DNS filtering service; it doesn't have to be unencrypted,
        but these appliances must be able to decrypt it to do anything
        useful with it, like blocking queries for known bad URIs.

I find this paragraph weak and alluding to 'DoH is evil'. In an enterprise,
surely one can force DNS through their own DNS infrastructure, and HTTPS
through their own middleware proxy, and one would certainly want to block
any direct connections to the outside world that are encrypted regardless
of whether it is encrypted payload is DNS or something else.