This iteration - documents the BSDiff adoption
- documents the BSDiff (-adoption) patch content - introduces the requirement to keep a cache of message identifiers in order to address man-in-the-middle replay attacks; this includes a(n) (default) upper limit on per- domain recipients in sync with RFC 5321 limits. (The _dkimacdc DNS record *could* be used to also notify higher limits in general: ie, several thousand are common in open source MTAs, for example Exim: 50000) - adds more flags to persistently transport message state through the chain of signatures: like this the highest numbered signature always tells whether along the chain just any modification to RFC 5322 IMF and RFC 5321 SMTP envelope have been encountered - is still "not polished", and surely needs more implementation advice to avoid misunderstandings. (Maybe. Likely. Yes. Hm.) Because of other messages seen, i want to say again that the BSDiff algorithm that is used is very good (mostly better). Its control data *could* (of course) be turned into textual data, which is then very small for just a single data addition, as now could be seen multiple times for the other algorithm. I personally continue to claim three things though, the first being that the DKIM2 approach is not user graspable as claimed, especially with more data to come (it is a furious mixture of numbers of some sort, and partially encoded data, really, is it). The second being that using the binary approach including the info header (16 bytes alone, uncompressed) turns it into a blob that can be worked with directly very easily, no need to en/decode from/to text etc. Patch integrity validation is easy. Required memory can be allocated perfectly sized ahead of processing any data except for the header. The third is that with the binary approach and, yes, the available self-contained 50 Kilobyte open source plug-and-play implementation it is a complete no-brainer. You feed in DKIM relaxed (verified) pre- and post-data, you get out a compressed patch. You feed in (verified) post-data and the (verified) patch, you get back (verifieable) pre-data. No more processing than that whatsoever (only base64 de-/encode). Version 0.7.0 of the plug-and-play implementation has a Coverity defect density of 0.0 in its 13.542 lines of analyzed code. Wild 13, 542, that is! (imho.) Ciao from Germany already here, after the very first real day of spring time (first sights of bees and butterflies, and not few of the former, very surprisingly), --- Forwarded from internet-dra...@ietf.org --- A new version of Internet-Draft draft-nurpmeso-dkim-access-control-diff-changes-03.txt has been successfully submitted by Steffen Nurpmeso and posted to the IETF repository. Name: draft-nurpmeso-dkim-access-control-diff-changes Revision: 03 Title: DKIM Access Control and Differential Changes Date: 2025-03-19 Group: Individual Submission Pages: 19 URL: https://www.ietf.org/archive/id/draft-nurpmeso-dkim-access-control-diff-changes-03.txt Status: https://datatracker.ietf.org/doc/draft-nurpmeso-dkim-access-control-diff-changes/ HTML: https://www.ietf.org/archive/id/draft-nurpmeso-dkim-access-control-diff-changes-03.html HTMLized: https://datatracker.ietf.org/doc/html/draft-nurpmeso-dkim-access-control-diff-changes Diff: https://author-tools.ietf.org/iddiff?url2=draft-nurpmeso-dkim-access-control-diff-changes-03 Abstract: This document specifies a bundle of DKIM (RFC 6376) extensions and adjustments. They do not hinder the currently distributed processing environment that includes DKIM, ARC, DMARC and SPF, and are as such backward compatible. Their aim is however to ultimately slim down the email environment that needs to be administrated and maintained, by establishing mutual agreements in between sender and receiver(s), verifiable through public-key cryptography, and let the SMTP protocol handle decisions solely based upon that. The IETF Secretariat -- End forward <174242477723.789285.16192509271570828395@dt-datatracker-\ 5b9b68c5b6-zxk6z> --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
