Bron Gondwana wrote in <[email protected]>: ... |Speaking with Barry in person at the hackathon today, I am persuaded \ |that what we actually want to have in the spec is this: | |The verifier MUST support at least one of the signature algorithms. |The verifier SHOULD check all the algorithms that is supports |The signature MUST be valid for at least one of the signature algorithms \ |which are checked. |The signature SHOULD be valid for all signatures algorithms which are \ |checked (however, the verifier MAY decide to just log signature failures \ |for new signature algorithms during a transition phase, while interopera\ |bility is not yet reliable).
In how far is this any different that DKIMv1, and/or is moving anything forward, technologically-wise? It is not only DANE, i think the OpenPGP people talked a lot on the new quantum-resistant algorithms, and especially in paired combination mode, which seems the natural thing these come with, everywhere (OpenSSH, too); mostly Ed25519. There are already standard documents / late drafts (i have forgotten; it is not relevant to me at the moment, but i saw lots of things fly by!) available. So for DKIMv1 it surely would (quite naturally me thinks) be: choose the best algorithm there is and you know about. When a IETF draft on such a quantum-resistant algorithm for DKIM will get written, the large pool of knowledge already established should then be condensed for DKIM purposes. For the interested reading over the last months of email archive of the OpenPGP IETF mailing-list can be beneficial here. |I am persuaded of this for two reasons: | |1) an attacker trying to replace/fake a message could always just create \ |a message with only the "broken" algorithm. It's always possible to \ |replace the i=MAX DKIM2 header with a new DKIM2 header. I do not understand. If a message comes from X and a man in the middle Y replaces the signature of X then this is just an attack; if Y does not have the private key of X, then this is just a man in the middle attack. |2) all the later hops can validate all previous signatures, so if they \ |aren't happy about the content of a message they can tell if it was \ |insufficiently checked by a previous hop (which they need to do anyway, \ |because any hop can lie about the validation is has done of previous hops. This is not for ACDC, except in "R"eputation mode. That is, one could do that, always, one likely would have a software config switch, too: it makes absolutely no sense to apply very expensive actions if i just *know* the domain X-1 does it right. *But*, i blindly trust RFC 5863, section 2.5, on "organizational trust", in that this knowledge can also very well be automatized. Especially so in case of succeeding verifications, the reputation checks could become more and more sparingly. Maybe, maybe different to 5863, it could be reset upon failure immediately, because something is very, very wrong. And resetting does not really hurt except by increasing verification costs a bit, more often. --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) | |During summer's humble, here's David Leonard's grumble | |The black bear, The black bear, |blithely holds his own holds himself at leisure |beating it, up and down tossing over his ups and downs with pleasure | |Farewell, dear collar bear _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
