I would point out that finterprints do not have the issues to the same
extent as public keys. In particular they take 1/10th the memory in
dns cache and the query answers itself is 1/3rd smaller.
If group wants to look at using dns for authorization and at threats
to existing dns infrastructure, then I think you need to compare the
threats posed by using public key for authorization and by fingerprints
and decide based on the results of analysis of the impact using one or
the other would have.
On Tue, 2 Aug 2005, Douglas Otis wrote:
On Aug 1, 2005, at 6:23 PM, Hallam-Baker, Phillip wrote:
I think that it is entirely reasonable to expect competent network
admins to monitor resource requirements for infrastructures such as DNS
and plan to add more capacity if required. It is utterly unreasonable to
require new infrastructure to require no additional resources.
The issue here is the impact of DKIM verification on the DNS cache. I
would expect network administration to consider this issue and if
necessary put the DKIM verifier on a separate DNS resolver.
It could be true DKIM will not see deployments with millions of user-keys per
server, as DKIM makes possible. As this is for email, email itself can
distribute private user-keys to permit rapid scaling for high levels of
deployment with just simple tools given end-users. However, the two hundred
or so bytes consumed for each user-key may rapidly fill DNS cache. Other
applications may also use these now distributed DNS user-keys, where a
multitude of applications will make it impossible to isolate resolvers which
confront the loads generated by these user-keys. It is also possible these
other applications will establish separate user-keys as well, which will
further increase the impact user-keys will have.
DKIM is creating the possibility that DNS will be expected to resolve rather
large resource records for an unlimited and highly unstable number of virtual
entities (users), rather than what is normally limited and stable physical
entities (servers). Should it be later determined that DNS is not well
suited to handle user-keys, in addition to its normal and vital function, how
can this be established after DKIM user-keys are being widely used? Should
other protocols also decide that DNS should become a key server for their
user-keys, how can there be a line drawn to separate what should and should
not be placed into DNS?
The role of DKIM establishes who is the accountable domain, not who sent the
message. This domain should police the users provided keys within their
domain. I feel there should be a policy provision to further sub-divide
third-party signatures to optionally permit sub-domain signers and exclude
other third-party signers. The use of the sub-domain would clearly indicate
a different entity is accountable for the message, while also demonstrating
some type of administrative relationship. The level of trust must be placed
upon the signer, where this is normally done at the server, rather by the end
user. DKIM permits holding those domains accountable to ensure they enforce
proper behavior.
This user-key mechanism is attempting to prevent one type of abuse but then
overlaps the function provided by S/MIME or OpenPGP. There are many other
types of abuse that still must be managed. The higher level of control
desired is better provided by forcing users to utilize a centralized server.
The choice of not using this approach is they must be enforce behavior of the
users issued private keys. Perhaps the application that signs messages by
the end-user must signal and receive acknowledgment prior to the message
being signed with an encrypted key. There are possible solutions that do not
require user-keys.
-Doug
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net