Steffen Nurpmeso wrote in <20240816221411.vxiofR2g@steffen%sdaoden.eu>: |Hanno Böck wrote in | <20240816223214.495a7770@computer>: ... ||I already believe the support of Ed25519 is of limited usefulness. | |When Google, Microsoft does not support Ed25519 by fall, i will |write (and try to get through) a variant of it that does not pass |through only the hash to the algorithm, but the entire data, as |Ed25519 uses internal checksumming. (SHA-512 iirc.) | | https://mailarchive.ietf.org/arch/msg/art/vUndyjOsv72LkEfDxsoCDEuWq_0 | ||Given DKIM has no algorithm negotiation mechanism, you have no way of ||knowing what the receiving mail server supports. So you kinda cannot ||really use Ed25519 alone. You'll always have to support RSA, and can ||only support RSA+Ed25519, adding additional complexity for no real ||security advantage. | |And i will write a draft that changes that.
Of course -- it will not change *that*. So one *could* do something about that, but i have not thought about that at all. In effect i would assume your "always" represents nothing more but a finite timespan, more so if major players start supporting new algorithms. There are not that many DKIM implementations, and most have active maintainers and thus support new algorithms, some even many more than are standardized! (rspamd being especially famous in this regard.) That is: major players ship updates to billions of boxes, you cannot even help it (i think), and LTS distributions of Linux etc die out at times, too. (Etc: you know all that of course.) |In my opinion ARC and DMARC are over-complex over-engineered |dead-ends, and SPF i personally think is not right either. | |With TLS you do not even agree in a connection if the verification |fails, but for email people want thousand different data points to |build up a reputation. No. ... In private a got a very friendly and interesting email that pointed to RFC 5617: Steffen Nurpmeso wrote in <20240816233952.Tke__2e0@steffen%sdaoden.eu>: ... ||On 16 Aug 2024, at 15:14, Steffen Nurpmeso wrote: ||> Instead there should be a (yet another) DNS entry that notifies ||> whether a host DKIM-signs its emails, or not. ||> Then receivers can peek that state. ||> This idea in several forms was posted here in the past, without ||> responses. [ | https://mailarchive.ietf.org/arch/msg/ietf-dkim/DuinnZFuaFaKughaXSxkYwtR\ | jMw ] ||Have you read RFC 5617, _DomainKeys Identified Mail (DKIM) Author Domain ||Signing Practices (ADSP)_? [.] it does exactly that. | |Actually i did not know about [it] until January this year, |i downloaded it then. | ||[.]RFC 5617 has been reclassified as historic: ||https://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ | |Well i cannot help that, of course. |But i think Eric Allman, Jim Fenton and John Levine (and the |unknown to me M. Delany) are not bad company. | |The ideas i had do not involve dkim=all and =discardable. |I think the idea always was that "DNS presence means DKIM |presence" for one; i think the last idea was that the content |could already be a (the preferred) DKIM key, ready for use. | |(Though: likely DKIM signature key lookups already started when |From: is encountered, therefore this would be a redundancy; maybe |only the name of the most preferred one could thus be announce |.. i have not looked into this for months. And i am not a giant |or even larger email provider, if such a protocol change would |come voices should be heard which talk on that. DNS TTL caching |is involved here, but, for example, if i announce i want ed25519 |to be used, a possibly existing very large RSA key DNS cache entry |could be thrown away. Etc.) ... |That is. Whatever there was 2009, DMARC, ARC, SPF, it all came |thereafter, and now there is a tremendous amount etc etc etc, |i repeat that much too often (for no value). | |Ie, the situation has changed, and things should, in my opinion, |be reconsidered. ADSP is a good thing, i would only use |a different data content, plus accompany it with DKIM flag |additions, like also posted in the past. |For example the DKIM signature should definitely announce several |things, for example to-be-expected presence of "ADSP", .. and then |the sub-signatures. Creating these anywhere else but in the |context of DKIM aka domain-key specific, is just a fault. (Imho.) ... --End of <20240816233952.Tke__2e0@steffen%sdaoden.eu> --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 -- [email protected] To unsubscribe send an email to [email protected]
