Hanno Böck wrote in <20240816223214.495a7770@computer>: |On Fri, 16 Aug 2024 21:21:34 +0200 |Jan Dušátko <[email protected]> wrote: |> - uses the PKCS#1 v1.5 padding, but thanks to the architecture I do |> not know about the possibility of applying Bleichenbacher attack |> ('98). | |Bleichenbacher's 98 attack does not apply to signatures. | |There's another Bleichenbacher attack from 2004 that does apply to |signatures, but requires essentially a faulty RSA implementation. It |also only works on very small e (like e=3), and typically, RSA keys |have e=65537. That completely prevents this attack. | |> - I do not know about the possibility of using PKCS#1 v2.2 aka |> RSA-OAEP | |OAEP is for encryption, the corresponding signature standard is called |PSS. | |Given the difficulty of deploying new algorithms in DKIM, I find it |unlikely that deploying PSS - or any other new algorithm - has much |benefit as long as there's no serious breakage. | |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. 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. 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/DuinnZFuaFaKughaXSxkYwtRjMw The thing is maybe IETF-unlike, .. i do not take airplanes and fly around the world for taking part in meetings and such .., maybe .., but in my opinion it actually does not make any sense to create a draft or hm RFC if it is for the toilet. Usually i would think people need to agree that things are wrong, and should have interest in moving some technical agenda forward onto a better solution. But in the last three or so years all i have seen is a new terrifying and complicated draft for ARC. Oh, not too long ago a draft for reporting based on DKIM not DMARC and ARC, which .. maybe someone really needs, and i never understood why you need anything else than DKIM for such a thing. Maybe thus i find some time by the end of August to try to write an IETF compliant (horrifying XML that is then, i think), with (horrors) my name in it, to get forward DKIM, which really has deserved something better. |As for post-quantum: There really isn't a big risk for a signature-only |system like DKIM any time soon. For encryption systems, you have the |"store-now-encrypt-later" scenario, so you are potentially at risk |before scalable quantum computers exist. Therefore, it makes sense to |adopt post-quantum encryption early. But for signatures, this doesn't |apply. As long as scalable quantum computers don't exist, you don't |need post-quantum signatures. Given DKIM signatures are short-lived, Maybe someone with more knowledge should give hints on DKIM signature timeout lengths. It is really often that i see DKIM signatures without timeout even, and my own "ttl 666666" is just a nice number, too. |there's really no problem to be adressed unless we see massive |breakthroughs in quantum computing. | |Post-quantum signature mechanisms come with the challenge that they |have relatively large keys and signatures. This is challenging with |DKIM's principle of storing keys in DNS. | |But given there's no immediate risk, I believe the DKIM community has |plenty of time to wait and see how post quantum signatures develop. |Maybe there will be better / more compact signature systems in the |future, maybe we'll learn things from early-adopters that will figure |out how to work with post-quantum signatures. --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]
