Document: draft-malamud-keyword-discovery-03
Review: Spencer Dawkins
Date: 27 mars 2005 


I reviewed this document for suitability as a Proposed Standard.

Summary: This document is on the right track, but still has a couple
of opportunities for improvement.

The reader has to work to dig out the goal here - I THINK the goal is
"given an RFC 3865 solicitation class keyword,discover a URI that
points to a resource that tells you what the RFC 3865 keyword actually
means", but I'm still not sure about this. The document is correctly
pointing to RFC 3865 for its context, but it doesn't stand on its
own. Given this, the non-normative example is going to have a lot of
influence on the reader's understanding.

The Security Considerationsconcern raised is really broad. Is it
saying more than "DNSSEC would help a lot of things, including this
mechanism", or is this mechanism simplysubject toa broad class
ofinsecure-DNS-based vulnerabilities? What is really at risk here?
Even saying "in the absence of DNSSEC, this mechanism can be exploited
to give mail users incorrect guidance on keyword interpretation", or
something. Mumble.

 Use of a URI with the "https:" scheme without the use of DNSSEC makes
 an unwarranted illusion of authenticity and the possibility of active
 attacks a serious concern.