Hiya, Had a quick flick through the paper. Good work but not something that could yet be immediately used (which is entirely reasonable). Nonetheless it'd be good to see work done in this space.
I do however disagree with some of the motivations for the smarter crypto: - The authors say: "The public key is required to persist over disclosures: otherwise, the frequency of manual key updates and DNS updates would render fine-grained disclosures inviable." ESNI is an example that frequent (hourly) public key rotation is entirely doable and in any case the effort required is in publishing anything at some frequency - it makes no difference if the value is cryptographic (like an RRSIG) nor mostly how frequently one publishes - once the automation is in place then you're done. - I don't buy threat model 2 being that sensible as one against which to focus defences. AIUI, mostly the signatures that end up having undesirable properties (non-repudiation) are leaked from collections. In real-time, leaking the message content (regardless of whether that came in email, sms, signal or whatever) and not an email envelope seems much more likely. - It's not clear to me there's an hierarchical IBS scheme that could scale and that hasn't got a fatal key escrow problem. There may be - I didn't look, but I don't know there is. (And IBS always seem to smell patenty, sadly.) Even if key escrow were to somehow be considered ok, I'm not sure that the role of key generator fits into the architecture of email. - section 5.1: starting out with (paraphrasing) "replace the currently widely deployed thing" isn't realistic - TimeForge seems pretty complex to the point where I can't see it happening. In the end, I'd like to see us exploring this space and this paper is a fine input for that exploration but I don't see that it provides usable solutions so far. Still a good paper though. Cheers, S. On 02/10/2019 20:29, Jon Callas wrote: > I know that I've written about this before, so please bear with me a bit. A > continuing concern of mine is the way that DKIM contributes to overall > surveillance smog that the Internet has. > > When we designed DKIM, this was something we considered; it was a concern. It > wasn't so big a concern that we thought it should derail DKIM, and it wasn't > even a concern when it was taken over by the IETF. Nonetheless, it was an > issue, is an issue, and becomes a bigger issue nearly every day. The most > notorious failure here is the Podesta email dump, where the stolen emails > were verified against the DKIM signatures. This is precisely what we didn't > want to happen -- that DKIM was used for things beyond fighting inauthentic > emails. We ought to do something, the question is what. > > When I think about how to reduce the tracking and surveillance issues, the > solution space includes: (1) Better management of the keys (e.g. lifecycle > management of some sort); (2) Better management of the emails (e.g. strip out > surveillance-friendly headers in an MDA between the MTA and MUA -- think > procmail filter that removes information leaks); (3) Better crypto. If I wave > my magic wand and can cause software to appear and be deployed, I'd do them > all. None of them are perfect. A crawler that would collect all DKIM keys > would blunt the benefits of better key management; building and deploying > better header handling is a huge task; better crypto needs an addendum to the > DKIM standard. > > Nonetheless, I recently came across an interesting article, "KeyForge: > Mitigating Email Breaches with Forward-Forgeable Signatures". It's on the > IACR eprint archive at <https://eprint.iacr.org/2019/390.pdf>. I think that > everyone here should look at it. The TL;DR is that they have a signing > mechanism that blunts attributable signatures and introduces some interesting > new concepts. They call it, "Delayed universal forgeability." Yes, that's > vague, and it's my point; consider that an advert for the paper. It's an > interesting way to look at better crypto that allows for spam-fighting > without open-ended tracking. > > I don't know that their solution is the answer, but I do know that it's > asking the right questions. In 2005-7, we were concerned about surveillance > smog, but we didn't have a good answer (or even consensus, but this was > pre-Snowden). The stated answer of the day was proper key management of keys, > but it's not clear that anyone has ever deleted a DKIM key out of DNS. (Okay, > I'm exaggerating for effect.) They have very good comments about that; I'm > not sure I agree, but I really like what they're saying. We also briefly > considered some sort of ring or group signature to blunt attribution. That a > mediocre mitigation at best, and one of our core goals was to boil the crypto > down to essentials, using bare keys rather than certs or any other uniforms > for the keys. It's DKIM, not DCIM. > > I think their signatures take that *intent* -- a mix of math and operation -- > and creates something really worth considering. Even if it's not the answer, > the questions that we punted on in 2005 are vital for 2020 and beyond. > > Thus, any discussion of it is good. I really liked it. Please read it. > > Jon > > _______________________________________________ > Ietf-dkim mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ietf-dkim >
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ietf-dkim mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-dkim
