Yeah, sorry, I confused the t= with x= in the DKIM signature.

-- Terry

From: Murray S. Kucherawy [mailto:superu...@gmail.com]
Sent: Tuesday, May 19, 2015 1:02 PM
To: Terry Zink
Cc: Scott Kitterman; dmarc@ietf.org
Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - 
Effort and Policy

On Tue, May 19, 2015 at 12:00 PM, Terry Zink 
<tz...@exchange.microsoft.com<mailto:tz...@exchange.microsoft.com>> wrote:
I think we’re making progress here. So, a message would look like this:

From: joe@authordomain.example<mailto:joe@authordomain.example>
Authentication-Results: spf=pass (sender IP is xx.xx.xx.xx) 
smtp.mailfrom=mlm.example;
    dkim=fail (invalid body hash) header.d=authordomain.example
    dkim=pass (signature was verified) header.d=authordomain.example;
    dkim=pass (signature was verified) header.d=mlm.example;
    dmarc=pass header.from=authordomain.example (action=none cd=mlm.example)
DKIM-Signature: v=1; d=authordomain.example; s=selector; ...
DKIM-Signature: v=2; d=authordomain.example; s=selector; !cd=mlm.example; l=0; 
t=<now+30 seconds>
DKIM-Signature: v=1; d=mlm.example; s=foobar; ...
Some questions:


1.       This should be resistant to a replay attack 12 hours in the future 
because the “t=<now+30 seconds>” is part of the DKIM signature for v=2, and if 
a phisher copy/pastes it and changes “v=2” to “v=1”, the “t= “ part will be 
long past. Right?

"t=" is the timestamp at which the signature is generated, while "x=" is the 
expiration timestamp. So, you'd do "x=<t+lifetime>" where "lifetime" is the 
number of seconds you want the signature to be valid.
If a phisher changes the "v=2" to "v=1", the signature is rendered invalid 
because that changes the part that's hashed. That attack won't work.

2.       This will be susceptible to a replay attack for 30 seconds after 
initially sending it out, but only to the mailing list. Right?

It will be replayable for whatever the difference is between "t=" and "x=", by 
anyone that can generate a valid signature for the "!cd" domain.


3.       Verifiers need to know (enforce?) that a DKIM signature of “v=2 
!cd=<blah>” is not enough to verify a real signature without the corresponding 
“v=1 d=<blah>” additional DKIM signature. In other words “v=2 !cd=<blah>” is 
useless unless paired with something else. Right?

The idea behind changing "v=" is to cause verifiers that know about "v=2" to be 
the only ones that understand what "!cd" means, namely that the signature is 
not valid unless accompanied by a valid signature from the "!cd" domain.  A 
verifier that doesn't know about "v=2" will simply ignore that signature 
entirely, so the condition cannot possibly be satisfied.

4.       How should reputation engines accrue this message? To 
authordomain.example (the one in the header.from)? Or to mlm.example, the one 
in the smtp.mailfrom and DKIM d= domain that contained the strong signature?

That's a good question, but one outside of John's proposal.  I suppose you 
could accrue reputation on them severally, or jointly, or perhaps in some 
combinations.  I don't know off the top of my head which would be best.


5.       Verifiers will need to check at least 3 DKIM signatures. Is there a 
limit on the amount of signatures they should check? Presumably we wouldn’t 
want a verifier to check 30 signatures.

It would be unusual to check more than three or perhaps five, I would think.  
It might be useful to collect information on how many we're seeing in the wild. 
 Certainly a message bearing 20 or 30 might reasonably be regarded as a 
possible attack because a lot of DNS and crypto has to be done.

6.       What is the proposed t= time limit? Is 30 seconds enough? Too long? 
Too little?
I would guess too little, but at this point that's strictly a guess.  You need 
to leave enough time for possible network or other transmission problems 
between the signer and the intermediary you're trying to accommodate.
-MSK
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to