Jim Fenton wrote in <c44bcc95-8dcd-45ab-97d4-ad70563f3...@bluepopcorn.net>: |I suspect that my review of motivation-02 was missed because I sent \ |it in the middle if IETF week, so I’m resending it below. I see that \ |a couple of the comments (intended status, |use of “header field”) have been addressed elsewhere. | |-Jim | |Forwarded message: ... ||General comment: The draft uses the term “header” extensively, while \ ||the correct term (in every place I have noticed) is “header field”.
Also in hindsight to what Dave Crocker explained on this, i wanted to note (and did, but this did not pass moderation), that SysV mail (Seventh Edition, January 1979), but especially BSD Mail (2BSD, April 1979) and (thus) POSIX mailx had a "header" command, and talked about headers, and that before SMTP (5321) and IMF (5322) came along. (POSIX also says header field, since at least 2013, however.) ... ||Paragraph 3: Singleton flag: interesting idea, I think I like this. ... That interested me and i looked. To get there i stumbled over 3.2 backscatter, and wanted to note that this list misses sender address verification[1]. Since so many people seem to listen here, it is likely the audience includes some who do not deal nicely with it (i can give at least one larger name), and you possibly want to have a look. Regardless John Levine's post from 2008 noted in [1]. (It needs to be done somehow in the end.) (It is, actually, worse, because there exist quite expensive mail environment providers which create pseudo/false VERP addresses like bounce.mM0295fcc211a103059818efab.\ rf5167a6a-eb83-11e9-92f5-7ab8f5b1d025@EXPENSIVE-STUFF, which looks random enough for the universe for one, but is not really VERP, and therefore each such address is both, greylisted as well as sender-address-verified[1], by itself. (When anyone now feels addressed. It is even worse, since the above EXPENSIVE-STUFF returns A addresses which return NXDOMAIN when you do reverse-lookup the address .. by an even larger provider, used by some more of you listening (and writing) here, unless i am mistaken, and the latter is what is returned when you ask for the MX of EXPENSIVE-STUFF anyway. It is weird.) It is only a suggestion. I discovered it in January, and it is still true now. It is off-topic, except for context.) [1] https://en.wikipedia.org/wiki/Callback_verification Other than that i personally am in a completely opposite camp of what is described (mostly: all over) there, and am of the opinion that no other "perfect island" should be created. Also just any positive reference or talk about ARC makes me erratic, and i do not understand how anyone can come to such a conclusion. There are some goals of what an iterated DKIM should achieve. . Replay in general, mentioned in 6376, Laura Atkins said in the past that she sees it occasionally, or anyway has seen it, etc. So SMTP envelope RCPT TO must (somehow) be included. (Without revealing it in the 5322 IMF message after the message has reached its destination.) . Backscatter bounces. So SMTP envelope MAIL FROM must (somehow) be included. (Without revealing it in the 5322 IMF message after the message has reached its destination.) . It really goes for differential changes so that each modification, in an unbroken signature chain, can be undone, and the result be cryptographically verified. . Certain header fields should not only always be included in the differential changes, but should always be covered by the signature as such. (This should is a MUST, for example MIME fields to address security breaches.) . Certain constructs of 6376 DKIM should (MUST that is) no(t) (longer) be used. . ? That is the motivation. And *i* think the most minimal variant to achieve most, or all, of the goals of an iterated DKIM, should be chosen. Here, it should be taken into account that DKIM is widely deployed, not only by major players, but by a lot, if not most, domains which send emails. I think especially Google's GMail decision to require DKIM for at least multi-recipient emails coming in, i think by March 1st 2024, plays a role. I know people which never used DKIM, but use it ever since. That includes me. (GMail rejected emails from my ML for some occasions in i think November 2023, with notes in the rejection, later tries of postfix then got through. I could look if it is important, i sent mails to ask around for more info.) That also means that a high load of people has established configurations. Maybe for a decade and more. And here, please have a look at the configurability of the OpenDKIM library/tool alone. This is a complex beast, and it is not because of nothing, but because of necessities. Far beyond the question on "which headers ought to be signed"! Multiple DKIM implementations even mirror that configurability, for example the Python dkimpy of Scott Kitterman. (If i recall correctly it documents all of OpenDKIM's options, but does not implement one or two of the most "exotic" ones.) There exist a variety of implementations, which have been iterated beyond teething problems (likely), are stable and tested. (It really is so, in fact, and only to provide more context on the actual situation, which the moderator hopefully takes into account -- i really think that is important!! --, that especially those which focus on something new, contributed code to long existing software in the script language area, really only focused on this new code, and missed -- while iterating that widely used software! --, that for example it did not honour RFC 8301. It does not to the very day. (I had a communication with the main maintainer in November last year, he is also listening here.) It supports Ed, like practically all Free and Open Source Software that i know.) Developers need work time allocation for iterating their software, and fight bit (and RFC) rot. If you will, call it DKIM-10 for that., to get that going. DKIM RFC 6376 is itself an iteration of something which existed beforehand. Except for not covering the SMTP envelope at all, even though it would be a natural thing for it, here a quote of Dave Crocker from August 2023, which i quoted in communication with Murray Kucherawy: DKIM was designed to survive from posting to delivery (for an address in a SMTP RCPT-TO command). That is, it was designed to survive classic MTA relaying. What breaks a DKIM signature -- ignoring MTAs that go beyond their remit -- is activities that take delivery and then repost. Mailing lists are the classic example, but only an example. (SPF, on the other, only survives one hop, except in very special cases.) > Signature survival across intermediaries was only achievable by > encouraging intermediaries to not make any changes to the message > "inside the envelope" such as standards-allowed MIME re-encoding > (which, notably, prevents intermediaries from improving MIME > interoperability). MTAs that are doing MTA functions are not supposed to make changes to the content and typically they don't. So, in my opinion, DKIM as of RFC 6376 as such is enough to deal with the problems, if only it is extended by a few additions, which can stored in additional headers. (The other proposal does it like that, too.) Due to all the mitigations all over the place, an iterated DKIM does have no other option but to place its signature under a name other than DKIM-Signature, because that is removed or renamed, more often than not. Its content can be a duplicate. Or a superset of the normal DKIM-Signature. It is ugly. But, from the programmer side, you only add some things to an already existing normalized buffer, and sign that an additional time. What i do not understand is why there is no discussion on all that. There was a lot of talk on certain tag=s and their meaning during the charter phase, and such. Why is everybody so eager to create and deploy something completely new? To note that actual *implementors* of software do not seem to take part with the discussion that much, except for Alessandro Vesely, maybe Richard Clayton (whose area of responsibility i do not know). It must be understood, it must be implemented, the users must adapt. I mean, label it DKIM2, it *is* complicated enough. Call it a reimplementation, continue your reservation of the "months of development time" as was heard on this list. I bet there is plenty of room for coding around, if only one looks thorough enough. I personally have the best ideas when i come back to a code base after having left it for some time, for example. In the best of possible worlds, a simple software upgrade distributes the iterated DKIM, and users only have to deal with a single additional configuration switch (create_dkim2_signature, or something). And *if* the time has come, and *if* experience has grown, and *if* the non-iterated DKIM has died out, and who knows when that is, or what email circumstances exist, ie, DMARC, ARC, SPF, etc, then a future iteration could do more. No one asked for more than the above motivation as of today. And please do not strangle SMTP for no real reason except absolute control for no real reason. I do not understand how this can even be taken into account. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) _______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
