Subject: Re: [dmarc-ietf] Mediation and controlled forwarding

From: "Douglas E. Foster" <[email-masked]>
Date: Sat, 20 Jun 2020 07:46:58 -0400

If conditional signatures require the participatuon of the author's MTA, then the consent of the domain owner is implied.   DKIM scopes already provide a solution for delegating authority, but the MLM problem stems from not wanting to seek domain owner involvement.

Just as significantly, tbe MLM does not want to sign the same document as what was signed by the author.  If the document is unchanged, a conditional signature is not needed.  If tbe document is alrered after the first signature, the first signsture is not applicable to the second signature.

On Jun 20, 2020 7:13 AM, Alessandro Vesely <[email-masked]> wrote:On Sat 20/Jun/2020 02:52:55 +0200 John Levine wrote:
> On Fri, 19 Jun 2020, Murray S. Kucherawy wrote:
> 
>> A number of drafts were floated, as I recall.  I had a couple.
> 
> There's always my conditional signing hack, in which one puts a very
> weak signature on the message which says it only counts if it's
> resigned by X, where X is the expected mediator.

Conditional signatures should be paired with a mechanism that tells
the author's MTA when to apply them.  For example, a water tight
opt-in protocol whereby author, MLM, and author's MTA can do a
three-hand handshake.  Without that, we're back to depending on
reputation, for which simple whitelisting suffices.

Best
Ale
-- 

_______________________________________________
dmarc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dmarc

---

From: "John Levine" <[email-masked]>
Date: 20 Jun 2020 11:53:23 -0400

In article <[email-masked]> you write:
>Just as significantly, tbe MLM does not want to sign the same document as what was signed by the author.  If the document is unchanged, a conditional
>signature is not needed.  If tbe document is alrered after the first signature, the first signsture is not applicable to the second signature.

It would be nice if you'd looked at my conditional signing drafts
before guessing (wrong) about what they say.

Here's the 2014 version:

https://datatracker.ietf.org/doc/draft-levine-may-forward/

And the improved 2018 version:

https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Sat, 20 Jun 2020 20:52:27 -0400

> https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/

Does this mean, the author, nows support and is going to champion his 
proposal?

I seem to recall in 2014, the author citing a lack of interest to 
pursue this and felt it would cause problems. As stated in the 2014 
security conditions, he wrote:

6.  Security Considerations

    DKIM was designed to provide assurances that a message with a valid
    signature was received in essentially the same form that it was sent.
    The forwarding signature condition deliberately circumvents that
    design, to create a loophole for messages intended to be forwarded by
    entities that edit the message.  It opens up a variety of obvious
    replay attacks that may or may not be important depending on both the
    selection of target domains for messages to be forwarded, and the
    behavior of forwarders that receive messages with conditional
    signatures.

I felt then it was another "poison pill" to kill the 3rd party 
authorization effort. I was not impressed but this so I putted on the 
proposal.

Now I read in the improved 2018 version:

6.  Security Considerations

    DKIM was designed to provide assurances that a message with a valid
    signature was received in essentially the same form that it was sent.
    The forwarding signature condition deliberately creates a loophole
    for messages intended to be forwarded by entities that edit the
    message.  It opens up a variety of obvious replay attacks that may or
    may not be important depending on both the selection of target
    domains for messages to be forwarded, and the behavior of forwarders
    that receive messages with conditional signatures.

    A sender can limit the conceptual size of the loophole by being
    selective about what other domains it allows in its !fs tags, and by
    using the x= tag to limit the time during which forwarded signatures
    are valid.

If the author still believes this loophole exist, why are we bothering?

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos