Hi Eric, I would generally agree with you about the enthusiasm of the document. This is probably a good place for it, so long as it's accurate. I would quibble with you on one point: > > o there is no dependency on the deployment of any new Internet > protocols or services for public key distribution or revocation, > > I think this is a bit misleading. DKIM depends partly on DNSSEC > for security, and that is not yet widely deployed. >
I believe the point Dave is trying to make is that you don't need to deploy a huge infrastructure to deploy DKIM. DKIM does NOT require DNSSEC. Deploying DNSSEC improves the security of DKIM in the face of DNS attacks. > > S 1.2.2 > the basis for evaluating whether to trust the message for delivery. > > I'm not sure "trust" is a useful word here. > The intent is to state that if you know who you're dealing with you can decide how best to dispose of the message. > > The owner of the domain name being used for a DKIM signature is > declaring that they are accountable for the message. This means that > their reputation is at stake. > > I'm not sure I understand what reputation means in this context. > I believe it would be pedantic to define a commonly used English word. > > o does not require the use of trusted third parties (e.g., > certificate authorities) which might impose significant costs or > introduce delays to deployment > > See discussion on the mailing list about DNS servers being TTPs. > > > S 3.3.2, 3.3.3. > > Note: these are unfinished.. > > > > S 5.2: > While modern messaging infrastructure is considerably friendlier to > the use of digital signatures than in the past even a residual > failure rate of 1% results in unacceptably high support costs when > signatures are used ubiquitously. > > While this may well be true, it's asserted without evidence. > I agree. If you're going to cite statistics provide the cite. > > S 5.4: > The Kohnfelder architecture was originally designed to allow use of > public key cryptography before the ubiquitous availability of > networking. A particular benefit of the Kohnfelder architecture is > that Alice can send an encrypted message to Bob when the only > transport available is sending floppy disks through the postal > system. Another benefit of the Kohnfelder architecture is that a > signed message supported by a digital certificate is self supporting > and may be verified years after the fact provided only that the CA > signing key does not become compromised. > > The principle weakness in PKIs based on the Kohnfelder architecture > is the difficulty of locating the correct digital key in the absence > of a directory infrastructure. This led Brian LaMacchia, then at MIT > to develop the MIT PGP key server, in effect returning to the > original public key directory model proposed by Whitt Diffe and Marty > ^^^^^^^^^^^ > Whit Diffie > > Hellman. > > This claim strikes me as rather strange.... Remember that X.509 *was* > intended to work with a directory, indeed The Directory (X.500). So, > while it's certainly true that it's hard to get keys, it's not that > the guys who designed it were somehow too stupid to know about > directory systems. > I read Dave's claim is to the contrary. They presumed a directory infrastructure that in fact has proven difficult to widely deploy to the level of the individual. > > S 5.5 > > As previously mentioned PGP and S/MIME were designed in the heyday of > the security end-to-end principle. It has since been realized that > the end points with respect to trust are not the same as the end > points with respect to the communication protocol. > > When Alice sends a personal message to Bob it is Alice the person, > not the machine Alice happens to be using that is the true trust end > point. When Alice sends a piece of business correspondence to Bob it > is her employer. > > I don't think this is necessarily true. Rather, the issue is that the > application here (e-mail responsibility attestation) is different > from the ordinary e-mail signature issue. > I agree that this assertion is poorly worded, to say the least. For one, I believe it has always been the case the the binding between protocol end points and "trust end points" has been a matter of debate. I would suggest sticking with the idea that we are attempting to make a weaker assertion - that the message originated from a particular domain and that its contents have not been tampered with since departing that domain, and nothing more at this point. Eliot _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
