ietf-mxcomp
[Top] [All Lists]

Re: CSV specification revision available

2004-06-15 08:39:51

   Thanks, Tony, for your extensive comments.

Tony Finch <dot(_at_)dotat(_dot_)at> wrote:

The new documents are much clearer,

   Thank you. (There's been a lot of discussion leading to them.)

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.

   We mostly adopted the attitude that if any of us were confused, more
explanation was needed.

I have a few comments:

   Some of these I need to defer to Dave Crocker. Alas, it will be
several days before we know _whether_ he'll have useful Internet access
at his vacation spot.

   Please note, when I "defer to Dave" it doesn't mean I'm unwilling to
discuss the issue -- merely that I want Dave to be responsible for
changes to the document in question.

draft-crocker-marid-smtp-validate-01

   (This is the one document we tried to keep short.)

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)

   We discussed most of this, and Dave chose the terse wording:
} 
} Increased topological, transfer and access complexities...

   I'm going to defer to Dave whether to expand that.

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".)

   This is a typo. It will be fixed.

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.

   I agree with you, but I'm going to defer to Dave on changes.

"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.

   There wasn't time to chase references. I'm confident we'll add some.

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.

   I agree with you, but I'd much prefer to defer to Dave on actual wording.

3.1  StartTLS

Again this needs to be more explicit about the authentication process.

   I'm not sure I agree. RFC3207 is cited. But I'll defer to Dave.

3.2 SMTP Auth

As I understand it this draft is intended to be independent of SMTP.
Therefore SASL should be cited instead.

   Defer to Dave.

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.

   Defer to Dave.

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.

   I agree, but I'll defer to Dave.

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.

   I'm afraid we'll have to agree to disagree here. We intend for the
domain-name to be closely bound to those who administer the host --
not the machine itself. And we're more concerned about quick response
to problems than we are about the actual configuration of the host.

draft-ietf-marid-dsvcsa-00

Sections 4 & 5

These sections overlap rather a lot.i

   Indeed they do. We wanted to introduce the concept before the details.

They also omit to specify what the server should do if the client's
CSA records has invalid data.

   True. We're going to have to confer on what to say about these cases.

What should go in the (reserved) port field?

   Zero. (I'm sure this was in a previous draft!)

What does the SRV target mean for a client? i.e. what should go in
that field?

   It should ordinarily be a domain-name (typically the same as the
EHLO string) that resolves to the correct list of IP addresses.

Does it have to be the same as the EHLO domain name if the client is
authorized?

   No, but it ordinarily will be.

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?

   We really don't care: the list of IP Addresses (if any) will be
ignored.

   I agree some more words are needed. We'll confer on that.

6  Domain administrator advice

Paragraph three appears to be a discussion of SMTP server policy, not DNS.
It probably belongs in the DNA draft.

   It got written here: we'll confer on whether there's a better place
for it.

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.i

   Correct.

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.i

   For various reasons, we agreed not to talk about "authentication"
here. We consider it to be an "optimization" that the match of an IP
address here might satisfy the "authentication" need.

   Thus, there is no need for any IP checking in order for the _name_
to be authorized. I agree the wording could be clearer. We'll confer
on this.

It's also not clear how this relates to the RFC 2821 nix on EHLO checks.

   I do believe we've been over this before...

   RFC2821 specifically allows error responses to EHLO, but forbids one
very particular case:
] 
] An SMTP server MAY verify that the domain name parameter in the EHLO
] command actually corresponds to the IP address of the client.
] However, the server MUST NOT refuse to accept a message for this
] reason if the verification fails

   We are not refusing "for that reason" (though, of course, it's
already quite common to refuse for that reason).

   I quite agree that a clarification of this issue probably belongs
in the published MARID RFC.

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.

   I must disagree. See section 3, specifically the discussion of
"negative weighting", for example.

--
John Leslie <john(_at_)jlc(_dot_)net>