On Mon, 14 Jun 2004, Dave Crocker wrote:
We finally have a new version of the Client SMTP Validation
specification. The changes are massive.
The new documents are much clearer, however they are still vague on
important details, they take an awfully long time to get to the point, and
they contain an amazing amount of irrelevant digression. This is a shame
because I greatly prefer this approach to SPF and its ilk, since it does
not confuse email addresses and IP addresses.
I have a few comments:
draft-crocker-marid-smtp-validate-01
Section 1, Address-based Authentication:
It's probably worth explaining why this doesn't work so well in the
current Internet, particularly the use of NATs and dynamically-allocated
addresses. An IP address may be used by more than one host at a time or
over a period of time. E.g. if I blacklist a virus-infected zombie, have I
just blacklisted a NATted network? Will the zombie get through again after
it has obtained another DHCP lease? (in which case I'll blacklist the
whole DHCP range eventually)
Section 3.3
The CSV spec makes a nice distinction between authentication and
authorization. So why is the CSV authorization step defined by a document
called "Client SMTP authentication"? (Actually this appears to be a typo
since the document calls itself "Client SMTP authorization".)
draft-crocker-marid-csvhna-00
Section 2 DNS-based Mapping
"Often when contacted by a remote host, a host uses a reverse-DNS query to
get the name of the remote host." This should be changed to "names" plural
-- there can be multiple PTR records for a given IP address.
"Although [forward + reverse DNS consistency checking] has known
limitations, it is considered sufficient for many basic uses." This
comment needs a citation to a document contining a proper explanation of
the limitations.
I'm very dubious of the weaker DNS checking suggested in 2.1 and 2.2. I
think there should be much more discussion of the possible attacks and
defences, and why they are under consideration when full foward + reverse
checking is available.
The whole section needs to be more explicit about how the process works
and what the actions of the checker should be in reaction to various kinds
of failure.
3.1 StartTLS
Again this needs to be more explicit about the authentication process.
3.2 SMTP Auth
As I understand it this draft is intended to be independent of SMTP.
Therefore SASL should be cited instead.
In addition to this, SASL is generally used for user authentication not
hostname authentication. This section needs to be more explicit about how
this unusual use works in practice.
There also needs to be some comment on the limits to scalability of this
option, since it requires pre-existing bilateral agreements between all
senders and all recipients.
4 Independent Policy Services
"In effect, the question about domain name use is a question about the
reputation and accountability of the domain name administrator."
No, it is a question about the reliability of the host. This entire
section refers to a part of the CSV process covered by the DNS draft.
draft-ietf-marid-dsvcsa-00
Sections 4 & 5
These sections overlap rather a lot. They also omit to specify what the
server should do if the client's CSA records has invalid data. What should
go in the (reserved) port field? What does the SRV target mean for a
client? i.e. what should go in that field? Does it have to be the same as
the EHLO domain name if the client is authorized? If the client is not
authorized, this draft specifies that the EHLO name should go in the
target. Does it still have to have address records in accordance with RFC
2782?
6 Domain administrator advice
Paragraph three appears to be a discussion of SMTP server policy, not DNS.
It probably belongs in the DNA draft.
The protocol specified in this draft appears to be (I'm reading between
the lines here) that the EHLO domain name stated by the SMTP client is
used to look up a SRV record. This record states in the weight field if
that name may be used by an SMTP client, and it also contains a target
name. The DNS reply should contain additional data, being the IP address
records associated with this target name. One of these must match the
client IP address from the SMTP connection in order for the EHLO domain
name to be considered valid. Or maybe (according to HNA) the IP addresses
associated with the EHLO domain itself must match the connection IP
address. Or maybe the reverse DNS must agree too. This is not clear. It's
also not clear how this relates to the RFC 2821 nix on EHLO checks.
draft-crocker-marid-csvdna-00
There's no discussion of the obvious attack of a client recommending
accreditation services that all say the client is wonderful.
--
Tony Finch <dot(_at_)dotat(_dot_)at> http://dotat.at/