> On Behalf Of Tony Finch > The attack that we are worrying about is bulk-resending of an > undesirable signed message. What we want to be able to do is > (1) detect when this is happening and (2) stop it before it > goes on too long. Step (2) is effectively repudiation of the > signature. This implies that non-repudiation is not a > desirable feature of DKIM!
>From a legal point of view there non-repudiation is frequently undesirable (think large gas pipeline company once operating down in Texas). However from a practical point of view it is actually impossible to achieve deniability and very hard to meet the legal standard for non-repudiation which creates a very strong and irrebuttable proof of origin, In practice ANY system we build is going to fall between absolute deniability and absolute non-repudiation. And any system we build on top of DNS is going to be pretty much in the center ground. DO NOT state that avoiding non-repudiation is a goal, this leads to more convoluted schemes than you can imagine. Besides which RFC 822 origin is sufficient proof to create a deniable assumption the message is genuine in most legal systems. Take a look at the Adelyn Lee case for example. I think that it is clear that non-repudiation is a non-goal for the DNS key retrieval mechanism. The message signature is actually neutral on the question. What the DNS scheme is good for however is taking a first pass at signature verification within the transport loop. I would strongly suggest that anyone looking to deploy DKIM in conjunction with a comprehensive PKI such as PKIX look to support both DNS and XKMS as key retrieval mechanisms. > I'm not sure why Phillip thinks DKIM requires a full-on PKI. > Isn't publishing and removing short-lived keys in the DNS > sufficient? Key removal provides a simple repudiation > mechanism, if the TTLs are suitably short. > > Tony. There are two separate use cases: 1) Where there is a domain certificate (ie SSL class 3) that asserts that the subject can be held accountable and MAY make stronger assertions in addition. 2) Where the subject already has an extensive PKI deployed and wants to make use of it in conjunction with DKIM. For example using DKIM as the message signature format and using SMIME or PGP for message encryption. The first use case is likely to be seen very shortly, possibly before the charter is agreed. The second is slightly longer term but there is a good argument to be made that DKIM is the key to making the Federal bridge CA really deliver value without having to do extensive client software updates. _______________________________________________ ietf-dkim mailing list [email protected] http://mipassoc.org/mailman/listinfo/ietf-dkim
