> If this hack essentially weakens a DKIM signed message so that it can > survive the transport, the MLM changes and the final destination. then > why not just do create this weakness with just one original v1 > signature using the i= (AUID) to pass the resigner information? > > Just as you expect the v2 signature to survive, and also not get > stripped, why can't that happen with the weak v1 author domain signature?
A weak single signature makes it more vulnerable to a replay attack. With two signatures, the MTA --> MLM is protected (which is important) and the MLM --> MTA is also protected although there is a time window of vulnerability. However, if the first leg is protected then it's smaller risk if the second leg is less protected. Thus, it's easier for the MLM (MTA --> MLM) to filter it properly the first time. -- Terry -----Original Message----- From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Hector Santos Sent: Wednesday, May 20, 2015 4:53 AM To: dmarc@ietf.org Subject: [dmarc-ietf] Weaker single author signature With two sigs, all I can see is that the first leg of the transport is stronger PATH: MTA ----> MLM strong 1st party v1 signature PATH: MLM o---> MTA weak 1st party v2 signature If this hack essentially weakens a DKIM signed message so that it can survive the transport, the MLM changes and the final destination. then why not just do create this weakness with just one original v1 signature using the i= (AUID) to pass the resigner information? From: user@author.example DKIM-Signature: v=1 d=author.example s=signer.selector i=resigner.example@author.example l= <-- weak sizing h= <-- weak header binding list Just as you expect the v2 signature to survive, and also not get stripped, why can't that happen with the weak v1 author domain signature? The resigner domain can be passed via the AUID i= tag. The final receiver will now see weak first party signature and the OPTIONAL stronger resigner signature. Since this is a DMARC extension, the trigger tag can be used such as "dualsig=y" on the DMARC record to enable the logic. But that wouldn't be needed as long as the first party sig is survivable which is all we are doing with the v2 sig. Unless I missing something, using this simpler method offer compatibility with the non-signing MLM as well. The only benefit using 2 sigs I see is the stronger first leg transport to the MLM and as long as the MLM domain is known, it doesn't matter at the point why you send this guy as long as its survivable for the distribution. The final receiver can use the i= tag of the original weak signature to get the permission to "authorize" the potential resigner. -- HLS On 5/19/2015 11:25 PM, John Levine wrote: >> The challenge here is that the second signer may not have anything to do with >> the message. Since, except for From, only invisible parts of the message are >> signed, the signature could be applied to almost any email. Using the >> reputation of the second signer's domain is not substantially different than >> using the reputation of an unauthenticated identity. I don't see how that >> helps. > > The second signer has at least enough to do with the message that it > has a real message in hand with permission to re-sign. > > Remember the problem that got us here in the first place: AOL and > Yahoo had security failures that let crooks steal zillions of address > books, who then used botnets to send spam to AOL and Yahoo users that > appeared to be from other AOL and Yahoo users that they knew. The > actual source of the mail had nothing to do with AOL or Yahoo, or any > system that had ever gotten mail from AOL or Yahoo. > > The double signing hack limits the opportunity for trouble to mail > systems that have a recent real message in hand. While I can > certainly imagine spammy scenarios, it's hard to imagine ones that > wouldn't be fairly easy to detect and shut down. If nothing else, if > the original sender gets spam reports about double signed mail (there > are FBLs that key on DKIM signature) it can tell who's screwing > around and stop putting conditional signatures on mail to them. > > R's, > John > > _______________________________________________ > 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 _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
