ietf-mailsig
[Top] [All Lists]

RE: replay, revocation, repudiation, was RE: [ietf-dkim] On per-user-keying

2005-08-11 12:13:38
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
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim

<Prev in Thread] Current Thread [Next in Thread>