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

[Brandon Long]

On Sun, Aug 20, 2017 at 6:25 PM, Bron Gondwana 
wrote:
>
> 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.
>
>
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
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Hector Santos]

On 8/20/2017 9:25 PM, Bron Gondwana wrote:


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.


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.



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


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Bron Gondwana]

On Mon, 21 Aug 2017, at 10:04, Hector Santos wrote:
> On 8/20/2017 7:47 PM, Bron Gondwana wrote:
>> On Mon, 21 Aug 2017, at 09:34, Hector Santos wrote:
>>> On 8/18/2017 8:53 PM, Bron Gondwana wrote:
>>> 
>>>   ...
>>> 
>>>   And the message still arrives at receiver with a valid ARC
>>>   chain, just
>>>   via badsite.com instead of site3.com.
>>> 
>>> 
>>> 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.
> 
> 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.

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.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  br...@fastmailteam.com


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Hector Santos]

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

On Mon, 21 Aug 2017, at 09:34, Hector Santos wrote:

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

...

And the message still arrives at receiver with a valid ARC
chain, just
via badsite.com instead of site3.com.


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.


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


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Bron Gondwana]

On Mon, 21 Aug 2017, at 09:34, Hector Santos wrote:
> On 8/18/2017 8:53 PM, Bron Gondwana wrote:
> 
>> ...
>> 
>> And the message still arrives at receiver with a valid ARC
>> chain, just>> via badsite.com instead of site3.com.
> 
> 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.
Bron.


--
  Bron Gondwana, CEO, FastMail Pty Ltd
  br...@fastmailteam.com


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Hector Santos]

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


...

And the message still arrives at receiver with a valid ARC chain, just
via badsite.com instead of site3.com.


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



--
HLS


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Brandon Long]

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"  wrote:

> 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
>   br...@fastmailteam.com
>
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc