Re: [ietf-dkim] DKIM Key Sizes
On Sunday, October 30, 2016 05:50:33 PM John R. Levine wrote: > > It's also probably worth ensuring that the major open source DKIM > > implementations support both signing and verifying with 4096-bit keys. > > Aside from OpenDKIM and dkimpy, are there any others that should be > > checked? > Perl Mail::DKIM is still widely used. It calls Crypt::OpenSSL::RSA which > is a wrapper around openssl so I'd be surprised if it had trouble with > large keys. There's also https://sourceforge.net/projects/libdkim/ by ALT-N. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Key Sizes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 > On Oct 28, 2016, at 5:02 AM, Eliot Lear wrote: > > * PGP Signed by an unknown key > > Hi Jon, > > I really don't get your point. Either the thing is worth signing or it > isn’t. See below. No problem. That you say, "either the thing is worth signing or it isn't" shows that you don't get it. I'll try to explain more. >> >> That assurance comes at a cost of whatever integrity that assigns to a >> message that might have been unintended. That message integrity is a >> privacy loss by the users. >> >> The real-world case in point is the leaked Podesta emails, where some >> people have asserted that authenticity can be checked via the DKIM >> signatures. I've raised an eyebrow on that, and the bottom line is >> that you're presuming that attackers were sophisticated enough to >> steal the email, yet unsophisticated enough that stealing the DKIM key >> from an MTA is out of the question. > > If it’s the same conversation I was engaged in, I think the person was > just confused. A simpler approach to plausible deniability is simply > not to sign. And further, just because a person can hack someone’s > personal message store, as seems to have happened to Podesta, doesn’t > mean that they can hack the private key out of Google. Furthermore, > using the example above, the key would actually have to be around for a > while (e.g., not rotate out of DNS). In fact, if the key really is > intended to verify the source over a longer period of time than, say, > delivery, certainly 512 is not enough. Yup! I agree completely. If the key is intended to verify the source longer than delivery, then 512 is not enough. And -- the key is *PRECISELY* intended to verify the source *NO* *LONGER* than delivery. 512 probably still isn't quite enough, since you can break a 512-bit key too easily. If I lick my finger and stick it into the wind, 600-700 bits is about where they should be. 512 is slight exaggeration for effect. You can make it work, but you really need to put some infrastructure in place to make it work well. But I belive that 512 is a better choice than 8K. Or even 4K. But not for the same reasons. > >> >> The full discussion is pretty nuanced, and I think the relevant part >> here is that if an administrative domain wants to protect the privacy >> of its users, it should be using *smaller* DKIM keys, not larger ones. >> I think I could convincingly argue that a privacy-friendly email >> provider is better off using 512 bit keys (where there's a chance of >> spam forgery) than 4K keys (where there's a chance of ruining the >> privacy of the customers). Now actually, I think the sweet spot for >> key size is above 512, but it's lower than 768. For maximum balance, >> you want the key to take longer than a week to crack, but less than a >> year, and change it every month. Or something like that. You get the idea. > > Color me obtuse, but are you worried about the incentives to break into > the user's account or are you worried about the provider wanting to peer > into users' email in order to assure itself that it’s not spam? Ah, I see I'm going to have to at least snuggle, if not embrace the fuller discussion. My issue -- not a worry -- is the *semantic* value of the signature. Many, if not most protocols we deal with in the IETF are strictly syntactic. We don't look at the meaning, we don't look at the internals of them. Often this is both good and intended. Look at IPsec, TLS, SSH, OpenPGP, S/MIME, and on and on, these are syntactic standards. In some of them, the unspoken semantic issues are a wart. In S/MIME and OpenPGP, there's a huge semantic issue as to what a signed message *means*. I had a co-worker (at both Pretty Good Privacy, Inc. and PGP Corporation) who would not sign his emails. The reason he wouldn't is that he said that we didn't know what signed email meant and that he didn't want to end up finding out twenty years later that his signing a message was suddenly a legal commitment that he didn't intend. This is also an interesting long discussion. Is a signature on an email nothing more than an source-directed integrity check? Does it mean a little more, such as the digital equivalent of letterhead? Does it mean even more than that, that it's 'official'? Or more than that, that it's certified true and accurate? I know where I stand on it, which is far more towards the integrity check or at most letterhead. I might even roll my eyes, but it's a not unreasonable concern that I simply happen to disagree with. My last bit if setup and groundwork is to gesture towards Phil Rogaway's essay of last year on crypto and its social aspects, which is such a big thing that I'm just going to say, "Thanks, Phil," and move on. All of this setup is relevant here because the mission of DKIM is to stop a certain class of message forgeries. These message forgeries are / were a danger to the public health of the Internet
Re: [ietf-dkim] DKIM Key Sizes
It's also probably worth ensuring that the major open source DKIM implementations support both signing and verifying with 4096-bit keys. Aside from OpenDKIM and dkimpy, are there any others that should be checked? Perl Mail::DKIM is still widely used. It calls Crypt::OpenSSL::RSA which is a wrapper around openssl so I'd be surprised if it had trouble with large keys. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Key Sizes
> > As for the original question, I agree that longer keys should be > supported as a matter of principle. But before we end up with an RFC > that makes implicit promises about what receivers can handle that don't > match reality, does anyone have an idea whether receivers can handle > key sizes larger than 2048 bits in practice? (I know the maths is the > same, but it'd make sense to set some kind of upper limit to avoid > getting DoS'ed and for all I know, people may have set that limit to be > 2048 bits.) This is certainly a fair point. I raised the issue with representatives of one of the big U.S.-based receivers, and they indicated that they can accept keys at least up to 4096 bits. But it's probably worth setting up a test mail server and validating the behavior with assorted receivers. I can look into doing that. It's also probably worth ensuring that the major open source DKIM implementations support both signing and verifying with 4096-bit keys. Aside from OpenDKIM and dkimpy, are there any others that should be checked? Best, Peter On Sat, Oct 29, 2016 at 9:26 PM, Martijn Grooten wrote: > On Fri, Oct 28, 2016 at 11:06:34AM +0100, Stephen Farrell wrote: > > Instead, I'd point out that this can be handled, even now, > > by simply rolling to a new key and then shortly publishing > > the private key used to sign the messages. That way Podesta > > could deny the content once more, at least at the crypto > > level. > > (...) > > > I could imagine us writing an RFC about why and how to do > > DKIM signature key rollover and private key publication and > > would be happy to help if there were a chance it'd get some > > traction. > > I think this is a really neat solution and I'd love to see an RFC like > this. In theory, that is. > > In practice, I think that plausible deniability is something that > concerns very few people outside the crypto community. Maybe there is a > need for such an RFC among the modern day Lavabits, and if that is the > case it would be great if we could contribute, but I would expect people > running such services to understand their complex threat models quite > well already. > > As for the original question, I agree that longer keys should be > supported as a matter of principle. But before we end up with an RFC > that makes implicit promises about what receivers can handle that don't > match reality, does anyone have an idea whether receivers can handle > key sizes larger than 2048 bits in practice? (I know the maths is the > same, but it'd make sense to set some kind of upper limit to avoid > getting DoS'ed and for all I know, people may have set that limit to be > 2048 bits.) > > Martijn. > > > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJYFPfJAAoJEI5dMs9dIv8Z/SUH/jAe2uvRQ26D+/rEAMLRbsKP > Bc8/SPsYH2lEKEf9w2xljTbRyP6M6puUFZsciPTq7v44L7Giov0gvdcDzDVVfL/A > 71yZD7abViSqIbIvcAvh0yWtWF8oRv8oOfivcGdoOaDec+zTgS0FnEyBhyA70lJC > W0pbIm8RvFCwKPjVMuFQ1mElFnSPoi0PPwP6HEpFXdtnqwfVOPWfcMfnBns6HlnR > ymwCkiYL1z/i/A5P8Gj3VknwtwJxvuOQUYjB+iZVaHDiANlSAnU0MdTSkVenKeBH > FYe8l3sEYk8NTxoJK+Z1iJ+LwasOg8qztZOimP4MMrED+5RnLfdwMQk5bDzClJw= > =3yQ1 > -END PGP SIGNATURE- > > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > > -- [image: logo for sig file.png] Bringing Trust to Email Peter Goldstein | CTO & Co-Founder pe...@valimail.com +1.415.793.5783 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Key Sizes
On 10/30/2016 01:04 AM, John R. Levine wrote: To get back to the previous argument, if you don't want people using DKIM to validate old messages, rotate the keys more often. I'd suggest that as security services and political operatives have now been alerted to the potential value of DKIM in validating leaks[1], any realistic threat model now has to assume that the adversary/ies have access to a complete DKIM public key history - at least for any sizeable sender. Indeed: * this may already have been happening for some time; and, depending upon their means of information gathering[2] * passive DNS operators may already have this capability as a side-effect of what they've always done. Those who are serious about plausible deniability can always use a separate keypair per message and retire the public key after a long enough interval for any likely delivery to take (60s? 2 minutes?), thereby defeating all subsequent analysis, at least until/unless ARC-signing by receivers becomes widespread. Whether this is a workable approach, or whether the objective is even a good idea, appears to be a long way out of scope for the DKIM specification. Deliberately weak signatures strike me as a poor alternative. Agreed. Worse still, trying to simultaneously pursue the "long enough to support abuse prevention" and "short enough to support non-repudiation" creates either of two unworkable situations: * If we're "lucky", the former is shorter than the latter and we can tweak the recommended key length to stay within the gap on a regular basis until the end of time. * If we're unlucky, the former is longer than the latter and we've taken on an impossible objective. In practice, neither length is likely to be able to be determined with sufficient precision to support realistic decision-making. - Roland 1: not to a forensic standard perhaps, but certainly to make real-world determinations about whether a leaked document has been tampered with 2: collecting cached DNS data vs. crawling the DNS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
