replay, revocation, repudiation,
was RE: [ietf-dkim] On per-user-keying
pbaker at verisign.com
Thu Aug 11 12:09:39 PDT 2005
> 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
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
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
> 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.
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.
More information about the ietf-dkim