Subject: [dmarc-ietf] About "non-rewindable crypto"

From: Bron Gondwana <[email-masked]>
Date: Sat, 19 Aug 2017 10:53:48 +1000

So this is an interesting case that I'd like to spin into a
separate thread.
At the moment, ARC headers are purely additive.  You receive a message
with some ARC headers on it, you add some more on top and send it on.
AR: arc=pass, ...  // at receiver
AS: i=3; cv=pass, d=site4.com
AMS: i=3; d=site4.com
AAR: i=3; arc=pass
AS: i=2; cv=pass, d=site3.com
AMS: i=2; d=site3.com
AAR: i=2; arc=pass
AS: i=1; cv=none, d=site2.com
AMS: i=1; d=site2.com
AAR: i=1; arc=none; dkim=pass
DKIM-Signature: d=site1.com

site1 => site2 => site3 => site4 => receiver

Somebody who obtains a copy of that message could then trim the
message back:
AS: i=2; cv=pass, d=site3.com
AMS: i=2; d=site3.com
AAR: i=2; arc=pass
AS: i=1; cv=none, d=site2.com
AMS: i=1; d=site2.com
AAR: i=1; arc=none; dkim=pass
DKIM-Signature: d=site1.com

And pretend that the message was sent from site3 down a different path:
AR: arc=pass, ...  // at receiver
AS: i=3; cv=pass, d=badsite.com
AMS: i=3; d=badsite.com
AAR: i=3; arc=pass
AS: i=2; cv=pass, d=site3.com
AMS: i=2; d=site3.com
AAR: i=2; arc=pass
AS: i=1; cv=none, d=site2.com
AMS: i=1; d=site2.com
AAR: i=1; arc=none; dkim=pass
DKIM-Signature: d=site1.com

And the message still arrives at receiver with a valid ARC chain, just
via badsite.com instead of site3.com.
It is possible to do things with crypto,  mixing in hashes, such that
you not only add new headers, but you rewrite past headers such that the
original versions of them can't be reconstructed any more.  Which would
mean that if you could intercept a copy at the receiver, you couldn't
trim back to i=2 and restart the chain on that message.  It would mean
header replacement rather than just header addition though.
Is this something that would have enough interest to be worth pursuing?
It's bound to be more complex than ARC-as-defined, but it also makes
faking mail flows a lot harder, because you would have to intercept the
message between site3 and site4 if you wanted to fake the mail flow from
site3 - you couldn't just pick it up later.
Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [email-masked]

---

From: Brandon Long <[email-masked]>
Date: Sun, 20 Aug 2017 10:00:37 -0700

Can you do that and it's still possible to validate that site2 signed it?

Brandon

On Aug 18, 2017 5:53 PM, "Bron Gondwana" <[email-masked]> wrote:

> So this is an interesting case that I'd like to spin into a separate
> thread.
>
> Somebody who obtains a copy of that message could then trim the message
> back:
>
> And the message still arrives at receiver with a valid ARC chain, just via
> badsite.com instead of site3.com.
>
> It is possible to do things with crypto, mixing in hashes, such that you
> not only add new headers, but you rewrite past headers such that the
> mean that if you could intercept a copy at the receiver, you couldn't trim
> back to i=2 and restart the chain on that message.  It would mean header
> replacement rather than just header addition though.
>
> It's bound to be more complex than ARC-as-defined, but it also makes faking
> mail flows a lot harder, because you would have to intercept the message
> between site3 and site4 if you wanted to fake the mail flow from site3 -
> you couldn't just pick it up later.
>
> Bron.
>
> --
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>
>

---

From: Hector Santos <[email-masked]>
Date: Sun, 20 Aug 2017 19:34:08 -0400

On 8/18/2017 8:53 PM, Bron Gondwana wrote:

> ...

The same receiver?  If so, wouldn't this be a duplicate message when 
the same receiver can see the same 5322.Message-Id?

-- 
HLS

---

From: Bron Gondwana <[email-masked]>
Date: Mon, 21 Aug 2017 09:47:30 +1000

On Mon, 21 Aug 2017, at 09:34, Hector Santos wrote:
>> And the message still arrives at receiver with a valid ARC
>> chain, just>> via badsite.com instead of site3.com.
> 

There is nothing stopping you changing the 5322.Message-Id - it's not
encoded in the AS or AAR.
Bron.

---

From: Hector Santos <[email-masked]>
Date: Sun, 20 Aug 2017 20:04:12 -0400

On 8/20/2017 7:47 PM, Bron Gondwana wrote:
>>     chain, just

It is protected by the original DKIM-Signature. Message-Id is pretty 
high on the recommended hashed header list.

But if the original DKIM signature was lost, all bets are off and 
nothing else matters unless ARC is attempting to replace DKIM which 
you just illustrated it is quite easy to create alternate paths, even 
when its not all to the same final destination.

-- 
HLS

---

From: Bron Gondwana <[email-masked]>
Date: Mon, 21 Aug 2017 11:25:34 +1000

On Mon, 21 Aug 2017, at 10:04, Hector Santos wrote:
>>> The same receiver?  If so, wouldn't this be a duplicate message when>>> the same receiver can see the same 5322.Message-Id?
>> 
>> There is nothing stopping you changing the 5322.Message-Id - it's not>> encoded in the AS or AAR.
> 
> you just illustrated it is quite easy to create alternate paths, even> when its not all to the same final destination.

Right - so how exactly does that help, given that you've modified the
message since then?  You could easily change the message-id at the same
time.  If the original DKIM-Signature still passes then sure, you can't
modify anything.  But then you don't need ARC anyway.
If the DKIM signature allowed you to tell that some of the protected
headers were unchanged while allowing others to change, then it would
mean something - but the whole point of ARC is for when DKIM doesn't
validate any more, and if DKIM doesn't validate any more then the message-
id can be spoofed too.
Bron.

---

From: Hector Santos <[email-masked]>
Date: Mon, 21 Aug 2017 07:46:54 -0400

On 8/20/2017 9:25 PM, Bron Gondwana wrote:
> message since then?  You could easily change the message-id at the
> same time.  If the original DKIM-Signature still passes then sure, you
> can't modify anything.  But then you don't need ARC anyway.
>
> validate any more, and if DKIM doesn't validate any more then the
> message-id can be spoofed too.

Which brings us back to square one, the lost of the 1st party 
association with the author-domain and the signer-domain whose 
signature is broken.  ARC needs to re-establish this association if 
its going to grab the "security baton" from DKIM.

I presume the first seal is the association.  Any other subsequent 
seal is beyond the author-domain understanding (unknown) other than 
its expected to be valid chain to the end which the receiver can verify.

So one way to mitigate the "Chain Trimming" problem is to a) reseal 
the message-id and b) provide insight of the expected final destination.

List servers are now resigning and not to beat on the proverbial dead 
horse, we don't have the 3rd party association to work with.  ARC is 
trying to change that, I suppose.

DKIM supports the concept of user tags. I've explore this. You will 
notice in my isdg.net DKIM-signature, it will have atps= tag;

  DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1;
  c=simple/relaxed; l=910; t=1503273855; atps=ietf.org; atpsh=sha1;

signifying the list domain, ietf.org, is the expected authorized 
resigner and can be trusted.  As long as the original signature is 
valid, that tag can be used by the receiver to confirm the resigner. 
But that signature is lost.

I guess, overall, if ARC reason to exist is because of lost of 
original signatures, and it has a trimming problem, then this should 
not to be taken lightly. It will suggest there several original DKIM 
hashed headers that need to be preserved in order to mitigate the 
potential issue.

-- 
HLS

---

From: Brandon Long <[email-masked]>
Date: Wed, 23 Aug 2017 15:49:21 -0700

On Sun, Aug 20, 2017 at 6:25 PM, Bron Gondwana <[email-masked]>
wrote:
> headers were unchanged while allowing others to change, then it would mean
> something - but the whole point of ARC is for when DKIM doesn't validate
> any more, and if DKIM doesn't validate any more then the message-id can be
> spoofed too.
>
>
Do we think there's any utility to adding more message info to the AS, such
as message-id?

We originally tried to keep them very separate, but we could combine the AS
with the concepts of the "weak DKIM" signature we talked about a while back.

It equally doesn't prevent any individual attack, but perhaps there are
other benefits in aggregate.

I could also easily imagine some utility for having AMS include the z= DKIM
tag, though this may get into the weeds of what can be used
programmatically to determine spamminess/reuse vs expert user forensics
after the fact.

Brandon

---

From: "John Levine" <[email-masked]>
Date: 25 Aug 2017 15:43:19 -0000

>Do we think there's any utility to adding more message info to the AS, such

Probably not.  Mailing lists sometimes change the message ID, so it's not
a very useful indication of evil.

Having watched this thread, I don't see what the issue is.  If a bad
guy rewinds and resends a message, it'll arrive from the bad guy, not
from wherever it was supposed to come from.  I think we agree that ARC
is only useful on messages that come from normally trustworthy
sources, which the bad guy would not be.

So what problem are we solving here?

R's,
John