On Saturday, December 3, 2022 2:35:55 PM EST Jon Callas wrote: > > On Dec 3, 2022, at 11:01, Stephen Farrell <stephen.farr...@cs.tcd.ie> > > wrote: > > > > One nit though, that you should feel free to ignore if it > > was discussed already - the phrase "in a secure way" doesn't > > quite capture what the DKIM WG was trying to produce, e.g. > > we consider unsigned DNS fine for DKIM public keys, even > > though that'd not be described as "secure." > > > > Maybe s/in a secure way/using a lightweight cryptographic > > mechanism/ would be better? But again, it's a nit. > > Agreed, and we need some other weasel word than "lightweight" because there > are lots of people working on "lightweight" symmetric ciphers. Something > like "appropriate"? > > Y'all know this is one of the many bees in my bonnet -- DKIM doesn't need a > signature that is secure for a year (or more), it needs one that is secure > for somewhere between a minute and a week. > > Moreover, one of the ways that we could deal with some of the knock-on > issues of not wanting DKIM to be a non-repudiation system (the Podesta > Problem) is to use signatures that could be forged by someone who put a > CPU(s)-week's effort into it after the fact. > > Even if we never get around to the actual issues, we don't want to cut off > someone in the future at the knees.
If you want to avoid such problems, you can do so already. Script your mail server/DNS to publish a new key at a new selector weekly and then at the end of the second week, replace the public key with the private key. That will guarantee that any signatures more than two weeks old can be repudiated, but still work for normal email transit times. IETF doesn't need to do anything for domains which which to create DKIM signatures with a very limited temporal validity. Scott K _______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
