[OPSEC] Éric Vyncke's Discuss on draft-ietf-opsec-indicators-of-compromise-03: (with DISCUSS and COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-opsec-indicators-of-compromise-03: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


# Éric Vyncke, INT AD, comments for draft-ietf-opsec-indicators-of-compromise-03

CC @evyncke

Thank you for the work put into this document. It is interesting and an easy
read and so refreshing to read the British "defense" ;-) Once my DISCUSS is
cleared, I intend to ballot a YES.

Please find below one blocking DISCUSS points (easy to address), some
non-blocking COMMENT points (but replies would be appreciated even if only for
my own education), and some nits.

Special thanks to Jen Linkova for the shepherd's detailed write-up including
the WG consensus (always low response rate in OPSEC) *and* the justification of
the intended status.

Other thanks to Dave Thaler, the Internet directorate reviewer (at my request),
please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-opsec-indicators-of-compromise-03-intdir-telechat-thaler-2023-01-13/
Dave has raised interesting issues in the text, notably linked to IP addresses,
that I fully second; _I have yet to read any reply from the authors_, but the
review was posted just before the week-end and we are on the blue Monday.

I hope that this review helps to improve the document,

Regards,

-éric

## DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion on the following topics:

### Section 3.1 no IPv6 data

I am *really* surprised to only see IPv4 addresses in the numbers, even if
today AlienVault has 7k IPv6 addresses as IoC vs. 3M IPv4 addresses. Please
include some IPv6 statistics. I appreciate that this issue does not really
comply to a DISCUSS point but it is so easy to address and I would like to
start a discussion with the authors and the AD.


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


## COMMENTS

### What about DOTS WG

Should there be any text about the use of IoC by protocols specified in the
DOTS WG ?

### Section 1
`This draft provides best practice for implementers` while this if common
English, I find it a little weird to use "best practice" in an informational
document (as opposed to BCP). Could it be rephrased into 'provides suggestions"
to clarify ?

### Section 3.1

It took me to read the whole section to understand why it is a pyramid and not
a cursor. Unsure how to address the issue though.

Any chance to get more recent data than June 2021 ? Especially when reading
`This discrepancy warrants further research` about domain names as IoC.

### Section 4.2.1

It took me a while to understand the apparent oxymoron `commercial attack
framework`, suggest adding some words around 'for simulation and training' ?

### Section 5.1.1

I can only second Dave Thaler's review comment about the IPv4 address part; NAT
and CGN should also probably be mentioned.

### Section 5.1.2

`by using alternative DNS resolution services` should DoH be mentioned as well ?

### Section 6.1

Another reference dated 2018 ;-) any chance to get a fresh one ?

## NITS

### References location

The useful and relevant references are sometimes located at the end of a
sentence or a paragraph, which is unusual in IETF document. I am sure that the
RFC editor will either allow it or fix it ;-)

### Section 3.1

`blue team` is only used one, is it useful to introduce this term ?

### Section 3.2.3

As I am not a native English speaker, I am unsure whether "intel" is a usual
term in English (even if I understand it ;-) ).

### Section 5.1.3

`can lead to a compromise decision` the use of compromise is probably
ill-suited in an IoC document.

### Section 10

Suggest to prefix the "National" (as in NIST & NCSC) with the country to avoid
any ambiguity.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments