Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list

From: "Douglas E. Foster" <[email-masked]>
Date: Sun, 30 Aug 2020 08:07:33 -0400

Since we are designing a system that allows a mediator to alter Subject and Body, it should be no surprise that the conditional signature has the potential for re-use.   A well behaved mediator must be assumed before any such trust delegation is granted.I see no way to ensure that the conditional signature is single-use. As long as all of the signature's hashed cntent can be replicated onto another message, the signature can be reused.The more important question is whether conditional signature could be subject to third-party attacks.  Does the limited and predictable content of a conditional signature intcrease the risk that a bad guy could use guess-and-test to construct a valid  signature block for someone else?  DKIM uses the body content in two different hash calculations.  This severely limits the ability of an attacker to find and exploit a hash collision.   The conditional  signatures seem unlikely to have that strength.Sent from my Verizon, Samsung Galaxy smartphone<div>
</div><div>
</div><!-- originalMessage --><div>-------- Original message --------</div><div>From: Jim Fenton <[email-masked]> </div><div>Date: 8/29/20  7:11 PM  (GMT-05:00) </div><div>To: [email-masked], [email-masked] </div><div>Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list </div><div>
</div>On 8/29/20 12:42 PM, Douglas E. Foster wrote:
> To elaborate on my question and Michael Hammer's answer:
>
> To be unique, a signature needs a unique dataset from which the hash
> is computed.   The weak signature will not be unique because it will
> be computed on non-random content such as From, To, and Date.

Unique != random. A time stamp (with enough precision) might be unique,
even though it is not random. For that matter, DKIM signatures don't
include any random values either.

But what I was getting at is that the "weak" signature might not have to
be any different from any other DKIM signature (except possibly to
specify the authorized mediator). It's just that a verifier might fully
verify the mediator's signature, and verify the original signature but
not check to see if the body hash matches.

The one problem is that some mediators add things like [dmarc-ietf] to
the subject line, and that's usually signed.

-Jim

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 30 Aug 2020 18:11:00 +0200

On Sun 30/Aug/2020 14:07:33 +0200 Douglas E. Foster wrote:
> Since we are designing a system that allows a mediator to alter Subject and 
> Body, it should be no surprise that the conditional signature has the potential 
> for re-use.   A well behaved mediator must be assumed before any such trust 
> delegation is granted.
> 
> I see no way to ensure that the conditional signature is single-use. As long as 
> all of the signature's hashed content can be replicated onto another message, 
> the signature can be reused.

Yes.  That's true for any DKIM signature, in particular if using l=, which 
allows to append varying content.

> The more important question is whether conditional signature could be subject 
> to third-party attacks.  Does the limited and predictable content of a 
> conditional signature intcrease the risk that a bad guy could use 
> guess-and-test to construct a valid  signature block for someone else?

If you have the signature, you presumably have the whole message.  So there's 
no need to guess.  It is enough to keep signed header fields, presumably From:, 
Message-Id: (which is random, btw), and Date:.  All the rest can be changed at 
will.

> DKIM uses the body content in two different hash calculations.  This severely 
> limits the ability of an attacker to find and exploit a hash collision.   The 
> conditional  signatures seem unlikely to have that strength.

Even if the hash covers few data, finding a collision is not any easier.

According to dkim-conditional, an attacker would need a private key of the 
domain pointed by !fs=.  That limits exploits substantially.  Using vanilla 
weak signatures (e.g. to be compatible with v=1 verifiers) allows replaying at 
recipient's discretion, a state of affairs loosely comparable to p=none.

Best
Ale
--

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 30 Aug 2020 22:54:02 -0700

> allows to append varying content.

Indeed, RFC 6376 discusses replay attacks in a number of places.  It would
be nice if we could reduce that, but I suggest that's not a roadblock to
this working group's progress since it's an acknowledged property of DKIM
already.

> recipient's discretion, a state of affairs loosely comparable to p=none.

The draft suggests use of "x=" as a way to limit exposure.  If you do that,
then an attacker would need to be able to generate mail through your signer
with an "!fs=" tag identifying a domain they control, and exploit the
replay before the time in the "x=" tag arrives.  Sure, it's time-limited,
but it only takes seconds for such an attack to succeed, and automation of
such an attack is easy.

If you attach a "!fs=" for any old domain, then the exposure is wide; if
you can somehow constrain the domains, the attack surface is considerably
smaller.  In either case, reputation of the target domain might help,
assuming that's a service to which the author domain's signer has access.

For the cases of employers that want their staff to participate in, say,
IETF lists, they might be willing to institute a program of registering
domains where lists exist, thus limiting the attack surface.  So you
register "ietf.org" with your IT department, and they start issuing weak
signatures on mail going to that domain for six months.  As the deadline
approaches, people are warned to re-register, else the registration expires
and the conditional signatures stop; destructive results resume.
Fraudulent registrations can be traced back to who made them.

But we still have the Yahoo/GMail sized use cases to consider.  I still
don't think any kind of registration system could be reasonably expected to
scale.  Auto-detection, maybe, but that's got to be prone to false
negatives (and destructive results) while the data warm up about a new
destination.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 31 Aug 2020 12:15:40 -0400

>but it only takes seconds for such an attack to succeed, and automation of

The threats I had in mind were more like attacker finds an old message
in an archive with a fs domain that's been abandoned and the attacker
can reregister.  An x= of a few days should prevent that while still
letting normal list traffic work.

As always, as I hope we all remember DMARC alignment doesn't mean not spam,
and you still do all of the stuff you do to sort your mail.  This scheme
depends on the forwarders you authorize being well-behaved.  That's why I
am concerned that senders need to be selective about who they allow to
forward.

R's,
John

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Mon, 31 Aug 2020 23:49:02 +0200

> am concerned that senders need to be selective about who they allow to

Yep. I like the proposal, but for me the only question left is: (how) 
will this scale? I'm not (yet) convinced it will.

/rolf