On 5/28/15 7:08 PM, Brandon Long wrote: > We've been looking at weak dkim from the angle of reducing what's covered > by the signature... but unfortunately, that takes out the major parts of > the message that we care about. > > I'm wondering if there is a different alternative. > > This starts from the concept of the clean subject, similar to the > reply_regexp setting in mutt ( > http://www.mutt.org/doc/devel/manual.html#reply-regexp). In Gmail, this > same cleaning involves more, where we also strip Fwd type prefixes, as well > as list-prefixes [] and whitespace changes. > > One could imagine a canonicalization of the subject which did something > similar, allowing for most list subject mangling to not affect the > signature for that header. We'd probably also need to de-2047 the header > as well, so the processing was done on the user visible header, not the raw > header. > > Maybe there's some phishing or weirdness in allowing [whatever I want in > brackets] as a prefix, and there is the argument that given a large enough > user population, someone will fall for it... but its certainly better than > ignoring the subject completely. > > Moving on to the body is more complicated. I know the proposal for using > the l= to limit the size of the body that is signed, which could allow for > a footer to be added without breaking the signature. With HTML, it's been > argued that the later part of the message could modify the viewability of > the signed part and do all sorts of nasty things, and that may be true. We > might be able to specify a very specific format for footers, requiring both > an l= and that the rest matched that format, and maybe we could encode that > formating requirement as a canonicalization play, ie that a footer matching > the format would be removed during canonicalization, and one that doesn't, > isn't. Obviously, this may require a lot of work on list admins to move > their footers to a matching format, though if its pure text, that may be > simple enough for the list software to handle. One could also imagine that > an MUA could choose to only display the l= part by default, eliding the > rest the same way Gmail hides signatures and the like (ignore that I > mentioned that we should talk with the MUA folks, of course). > > One could also sign the body as an independent mime part and force footers > into multipart/mixed addendums. > > I realize both of these body changes require modifications to various > intermediate software, where the semi-point of the weak signatures was to > hope that it would pass unharmed and limit the scope of changes that would > be required. > > The final hare brained idea I had was more in the scope of "is this > possible" without actually knowing that myself. > > There are various fingerprinting type algorithms, is it possible to > construct a fingerprint algorithm which one could then sign, and require > the modified body to still match the fingerprint. This may not be possible > in cases where the footer is significantly larger than the original message > text, and I'm pretty ignorant of the actual algorithms to know if any would > work in this case, but it seems to me that this is something we could pose > to people knowledgeable about work in that area to see if there is a > solution. > > Now, the fingerprinting solution may end up being just a more generic > version of l=, ie it may allow for prefix and footers or rewriting links or > something. And it probably wouldn't catch the HTML writing tricks, so > maybe all of that is less useful than one would hope. > > Dear Brandon,
See: https://tools.ietf.org/html/draft-otis-dmarc-escape-03 Whether a recipient is able to see a Sender header is less of a concern but its inclusion allows accurate determination of the message source and author. Allowing Group syntax must also consider the effect of its friendly display. Large providers concerned about possible abuse can easily mitigate these issues by establishing a _tpa zone referenced by their DMARC policy assertions to establish a dead simple delegation method. I like the idea of a template able to impose header constraints in a manner similar to that used by John Levine. At the end of the day, S/MINE is likely the lowest hanging fruit with respect to mobile devices. It seems somewhat unlikely third-party services will make use of restrictive DMARC policy. Allowing use of Sender header fields can quickly overcome DMARC’s associated hindered use with third-party services. However a third-party domain is authorized, embedding authorization within stacked DKIM signatures represents higher overhead with impaired ability to effectively respond to abuse. Regards, Douglas Otis _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
