Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

["Murray S. Kucherawy" <[e-mail]>]

On Wed, Jun 28, 2023 at 5:50 PM Douglas Foster <
[e-mail]> wrote:

> We are talking about SPF AND DKIM because of the problems with DKIM
> replay.   Can someone summarize the state of the DKIM update options that
> have been ruled in or ruled out?
>

There's a document over in that working group that takes a run at doing so.

I'm worried about the complexity and assumptions in the proposal that
follows:

Given a received sequence of
>
>    - Msg Date
>    - Rcv Date 1
>    - Rcv Date 2
>    - ....
>    - Rcv Date N
>
> A signature should have a start time between one of these date boundaries.
>

There's no reason to trust the dates, IP addresses, or any other detail in
these header fields beyond infrequent manual diagnostic efforts.  They are
trivially forged and rarely signed.   You definitely should not attempt to
couple anything you infer from them with the semantics of a passing
cryptographic signature.

The first global IP after the signature server becomes the perimeter server
> which must demonstrate that it's domain has the right to act on behalf of
> the signing domain.
>

That sounds like the very definition of SPF.

By "global" I presume you mean "publicly routed".  Do we really want to
start teaching mail software how to determine which IP addresses are
publicly routed?  It's not as simple as the RFC 1918 question.

Improvements within control of the signing server:
>
> If the message is not created by the originating server, the message
> should contain one or more Received headers.   The header list on the
> signature should contain "Received" entries to match the number of Received
> headers at the time of signing.   This further identifies the signature's
> position in the Received chain.
>

The original DKIM RFC (RFC 4871) specified a list of header fields that
SHOULD and SHOULD NOT be signed, and Received was in the latter group.
It's common for Received fields to be stripped when they depart a domain in
order to conceal the topology within that domain.  Less commonly, they can
get reordered, edited, or re-wrapped.  Any of those would break the
signature if it covered them.

RFC 6376, the standard, dropped the SHOULD and SHOULD NOT, but still
discourages paying any attention to Received when signing.


> Improvements requiring changes to the DKIM specification
>
> They could identify a way to document the signing server's domain in the
> signature.
>

Isn't that the "d=" tag?

-MSK, participating