[lamps] Re: Orie Steele's Discuss on draft-ietf-lamps-header-protection-21: (with DISCUSS and COMMENT)

[Daniel Kahn Gillmor <[e-mail]>]

On Mon 2024-07-01 15:38:00 -0500, Orie Steele wrote:
> I've changed my position to no objection.

Thanks for the discussion, Orie, and for clarifying the remaining pieces
too.  A few more responses below.

> OLD:
>
> ```
> A receiving implementation MUST NOT mistake the presence of an hp="cipher"
> parameter in the Cryptographic Payload for the actual presence of a
> Cryptographic Layer that provides encryption.
> ```
>
> NEW?:
>
> ```
> A receiving implementation which observes an hp="cipher" parameter in the
> Cryptographic Payload MUST NOT process the message as if it had a
> Cryptographic Layer that provides encryption.
> ```
>
> I think I understand the intention, my comment is that readers may
> interpret "MUST NOT mistake..." differently.

I think your version is actually stricter than what the original
sentence is trying to say.  There are two distinct signals that the
recipient of a message can look at:

 a) they can look at whether there is actually a Cryptographic Layer
    that provides encryption, and

 b) they can look at the hp="cipher" parameter in the Cryptographic
    Payload, which indicates whether the sender *intended* to encrypt.

These are distinct signals, unfortunately, because of how
signed+encrypted messages have traditionally been constructed in e-mail.
The cleartext message is typically signed, and then the signed message
is wrapped in a layer of encryption.

The reason we need both signals is because the sender might have sent a
message that was signed-only, but then someone in the middle could
simply wrap it in a layer of encryption.  Without a cryptographically
strong indication in the payload that the sender intended to encrypt,
the recipient can't tell whether the encryption was added by some
interfereing MTA while the message is in transit.

Without getting into why an MTA might choose to do this (for malice or
other reasons), the point is that if you want to have strong reasoning
about the e2e cryptographic properties of a message, the recipient of
the message needs to confirm both the state of the message as they
received it *and* the sender's intent of how they meant to send it.

So i wouldn't want to say that the presence of `hp="cipher"` means you
*can't* treat the message as encrypted; because an actually encrypted
message with `hp="cipher"` is the normal use case.  What you don't want
to do is to see a message that is clearly *not* encrypted, and treat it
as encrypted just because you found an `hp="cipher"` parameter on the
Cryptographic Payload.

> I suppose the expected ABNF for the header field possibly addresses this
> already.
>
> You might consider adding a section reference to
> https://www.rfc-editor.org/rfc/rfc5322#section-4

this is the "obsolete" ABNF formats.  i'd be inclined to recommend that
MUAs generating modern signed mail should *not* use any of the obsolete
ABNF forms.

> And https://www.rfc-editor.org/rfc/rfc5322#section-3.6 for the ABNF
> mentioned.

this is a reasonable reference for some Header Fields, but there are
almost certainly other Header Fields that aren't in RFC 5322.  I think
the right IANA registry to point to is:

   https://www.iana.org/assignments/message-headers/message-headers.xhtml#perm-headers

Though that registry doesn't seem to have gotten much in the way of
regular attention (e.g. the Content-Disposition entry doesn't include
RFC 9078 in its Reference column, though it seems like it probably
should).  I don't know the right way to reference a modern f