It appears that Wei Chuang <[email protected]> said: >I'm very much in agreement with the need to attribute who contributed which >content to the message. I think this is the key difference from the >RFC6376 DKIM l= body length tag (section 3.5) that tried to tolerate >mailing footer modification also, but left unknown who added a potentially >malicious footer, which can be exploited today. Agreed there is DKIM RFC >security section 8.2 that warns about using DKIM body length but >unfortunately a very small but important part of the sending population >uses it today despite those warnings and risk. My guess is that they have >use cases that compel them to use DKIM body length despite its >unsoundness.
When this came up a few months ago, I think we found that the people we found using l= didn't understand it. There was an ESP (bulk mailer) that was doing l=0 who promptly stopped when someone told them why it was a bad idea, and I think there was some list software that was putting l= with the actual length as a poorly chosen default. This is quite different from the algebra, since l= gave you no reliable way to tell who might have added what. >+1. My belief is that security gateways are a particularly complex case >that needs this trust me bit. For example they may redact or >encrypt content where it doesn't make sense to provide the original content >for. When security gateways rewrite many URLs, it may become burdensome to >encode and reverse, and downstream receivers are going to have to trust >the gateway to make benign transformations. This can work because they >already have a relationship with their security vendor. However a trust me >bit in general introduces a security loophole hence receivers should use >only in those limited well understood scenarios. Right. We need to make it clear that the "trust me" bit is only intended for mail from gateways with whom you already have a relationship. R's, John _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
