Last Call Review of draft-ietf-lamps-header-protection-20
review-ietf-lamps-header-protection-20-artart-lc-gondwana-2024-03-17-00

I'm the ARTART reviewer for this document.

Ouch, 200 pages!  I admit I didn't read all the examples, just grepped them for
keywords.  I do appreciate giving many examples to help implementations check
their behaviour against those examples; and wish there was a way to do so by
reference without including them inline in a document which is rendered as
paginated text.

Generally I'm very impressed with the clarity of writing; as with
draft-ietf-lamps-e2e-mail-guidance which I also reviewed, it's a pleasure to
read this document.

I have no editorial comments.

My one concern with HP-Removed and HP-Obscured is that some or any of these
could be multi-valued headers; and it would be possible to remove or obscure a
header (with the more complex hcp algorithms; hcp_minimal only affects a header
which SHOULD be single-valued) and have legimitate intermediates add another
header with the same name.

This is somewhat handled by the language in this draft around things like
"List-Unsubscribe", but if the sender happened to have one of these and protect
it, then an intermediate adding it might be unintentionally making the message
appear to be tampered with.  And the intermediate can't know that this header
is being tamper protected; because the HP-Obscured and HP-Removed headers are
NOT visible to the intermediate.

My initial proposal around this was to have some kind of count in HP-Obscured
(or multiple of them with the same name), and any multi-valued header, include
one per removal in HP-Removed - but I'm unsure whether this is overthinking
things.

Bron.