On Sun, May 10, 2015 at 7:05 AM, Anne Bennett <a...@encs.concordia.ca> wrote:
> But I think that some of the "re-signing" schemes being proposed at > the moment do *not* require this type of registration, so in those > cases, the registration problem wouldn't apply. If A is not "signing > B's mail", but rather, "signing its own modifications to B's message", > then the evaluation of the two signatures doesn't require a published > or pre-existing relationship between the two domains. > Yes, exactly; re-signing in some way that is entirely self-contained (i.e., does not mandate further queries to establish a relationship between A and B) appears to be far more promising than anything requiring a registration component. The theory behind some of my proposals tries to extend the basic notion of DKIM, which "allows a domain to take some responsibility for a message"; the idea in the extensions is to allow the different actors to claim responsibility for different parts of the content, and let the receiver decide what to do with that additional information. You allude to this here: Under at least one of the proposals, it can be determined that "yes, A > signed the mods, and if the mods are removed to re-generate the original > message, B signed the original message". If we have that, then I think > the question becomes: if this is to be a DMARC-like scheme, how do we tie > A's signature to some kind of relevant header field, since the "From:" > header is already "reserved" for the original signer. > In general, what you're hoping to do is confirm a relationship between A and B. A system involving a registration scheme seeks to query a registry for such relationships. The favorite way to do this is the DNS of B, where the set A would be published somehow. These other re-signing methods (and their variants) are seeking to confirm this relationship via two signatures that are somehow associated. That is, for a registration scheme, you might be testing for the existence of a DNS record called A._related._dmarc.B. For a re-signing scheme, you're looking for a signature from A that is somehow endorsed (for some definition thereof) by a signature from B. The beauty of that mechanism is that the signer gets to decide when to apply that endorsement, and with what parameters. In fact, it's possible that A doesn't even know that B is doing it. B could do it for all messages, which is simpler but increases exposure; it could decide to apply the aforementioned heuristics and only include the endorsement when it feels it's appropriate, which is safer but requires a lot more internal infrastructure to support. Both camps are enabled. > Now despite injunctions on this list against referring to the user > interface, the fact is that DMARC uses the "holy From: header" to extract > the "alignable domain". Unless I'm gravely mistaken, the reason for > that *is* indeed that this field is shown to the user (in some form) > by every user agent out there, and the user is thought to place a fair > deal of confidence in the "truth" of that header. Unless we can state > something similar with respect to another header, I suspect that > anything we propose will be considered to be watering down DMARC to an > unacceptable extent. :-( > I agree with both your context and conclusion here. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
