Tony,
First of all, MANY thanks for such a quick review!
TF> The new documents are much clearer, however they are still vague on
TF> important details,
please note where i've asked for clarification about what you want to
have different. if you did not list something in your note, please
send details.
TF> they take an awfully long time to get to the point, and
TF> they contain an amazing amount of irrelevant digression.
Given the amount of effort we put into fleshing out the text and
working on clarity and completeness, it is not likely that any of its
irrelevance or digressiveness will be obvious to us. So, again, your
comments say exactly what you think needs to be changed, right?
In any event, none of us expects these drafts to be in their final
form. In fact there are aspects we have internal disagreements about,
but decided it would better to pursue public discussion rather than
wait longer to figure out a consensus among the 3 of us.
I'm in transit, and do not yet know what my connectivity will be for
the next 5 weeks. Therefore, John L. will be doing the heavy lifting of
responding to comments, so I'll just touch on any of your comments
that seem to go at core difficulties or issues.
TF> Section 3.3
TF> The CSV spec makes a nice distinction between authentication and
TF> authorization. So why is the CSV authorization step defined by a document
TF> called "Client SMTP authentication"? (Actually this appears to be a typo
TF> since the document calls itself "Client SMTP authorization".)
Indeed, a typo. We, ourselves, have had a very, very tough time
keeping the two functions clearly separate. The typo is residue.
TF> I'm very dubious of the weaker DNS checking suggested in 2.1 and 2.2. I
TF> think there should be much more discussion of the possible attacks and
TF> defences,
Perhaps. THere is a challenge to balance between specification and
pedagogy. At the least, we felt is likely to be sufficient to make
clear that we do not see it as a useful technique for any type of
really serious authentication.
TF> and why they are under consideration when full foward + reverse
TF> checking is available.
reverse is often not available, as we noted. so the question is
whether forward, by itself, is useful. Our conclusion is that for
this very constrained use, it is. It won't surprise anyone that we
won't be surprised if the community concludes otherwise
TF> 3.2 SMTP Auth
TF> As I understand it this draft is intended to be independent of SMTP.
TF> Therefore SASL should be cited instead.
Well, we do have a bit of a challenge, given that the actual use of
the document is part of an smtp-based service.
TF> In addition to this, SASL is generally used for user authentication not
TF> hostname authentication. This section needs to be more explicit about how
TF> this unusual use works in practice.
interesting point.
TF> 4 Independent Policy Services
TF> "In effect, the question about domain name use is a question about the
TF> reputation and accountability of the domain name administrator."
TF> No, it is a question about the reliability of the host. This entire
TF> section refers to a part of the CSV process covered by the DNS draft.
reliability is often part of the input to an accreditation process.
TF> draft-ietf-marid-dsvcsa-00
TF> Sections 4 & 5
TF> These sections overlap rather a lot. They also omit to specify what the
TF> server should do if the client's CSA records has invalid data.
What do you mean by "invalid" data? How is invalidity assessed?
TF> The protocol specified in this draft appears to be (I'm reading between
TF> the lines here) that the EHLO domain name stated by the SMTP client is
TF> used to look up a SRV record. This record states in the weight field if
TF> that name may be used by an SMTP client, and it also contains a target
TF> name. The DNS reply should contain additional data, being the IP address
TF> records associated with this target name. One of these must match the
TF> client IP address from the SMTP connection in order for the EHLO domain
TF> name to be considered valid. Or maybe (according to HNA) the IP addresses
TF> associated with the EHLO domain itself must match the connection IP
TF> address. Or maybe the reverse DNS must agree too. This is not clear. It's
TF> also not clear how this relates to the RFC 2821 nix on EHLO checks.
wow. what a really excellent summary! wish we had written it, and thoroughly
appreciate that you did. it will be a nice addition to the doc.
TF> draft-crocker-marid-csvdna-00
TF> There's no discussion of the obvious attack of a client recommending
TF> accreditation services that all say the client is wonderful.
that's not an attack. i would fully expect a client to cite only
those with positive assessments.
the question is what the receiving smtp server thinks of those
accreditation services.
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>