[ietf-smtp(_at_)imc(_dot_)org copied - I suspect we need more SMTP folks on
this]
At 12:51 AM -0400 7/1/01, Keith Moore wrote:
here are some comments on this document
1. section 5 says:
A publicly-referenced SMTP server MUST NOT require use of the
STARTTLS extension in order to deliver mail locally. This rule
prevents the STARTTLS extension from damaging the interoperability of
the Internet's SMTP infrastructure. A publicly-referenced SMTP server
is an SMTP server which runs on port 25 of an Internet host listed in
the MX record (or A record if an MX record is not present) for the
domain name on the right hand side of an Internet mail address.
this might seem like a nit, but the fact that a host is listed as an MX
for a particular domain does not compel that host to run an SMTP server
that accepts mail for that domain - because nothing ensures that the party
that administers the DNS zone containing the MX record has the
authorization of the party running the SMTP server to list that server
as a mail exchanger for that domain.
(lately, several people report seeing lots of SMTP errors of the form
"we're not a mail exchanger for this domain". whether this is more
likely due to a misconfiguration of the SMTP server, or of the DNS zone,
is unclear.)
so I might suggest a slight change in wording
A publicly-referenced SMTP server
is an SMTP server which runs on port 25 of an Internet host listed in
the MX record (or A record if an MX record is not present) for the
domain name on the right hand side of an Internet mail address, and
when the SMTP server is configured to act as a mail exchanger for that
domain.
That seems fine to me.
but more generally, it seems like what needs to happen in response to
the RCPT command, when an SMTP server wishes to refuse non-TLSed mail,
is this:
server listed | SMTP server configured to act as mail exchanger
as an MX for | for recipient domain
the recipient |
domain | no | yes
--------------------------------------------------------------------------
no | 530 must use starttls | 530 must use starttls
| or |
| 5xx not configured as an MX |
| for domain x.y |
--------------------------------------------------------------------------
yes | 5xx server incorrectly listed | return 2xx, 4xx, or 5xx
| in DNS as MX for domain x.y | based on whether the
| (or similar message) | recipient address is
valid
Do others agree with this chart? I'm not that comfortable with
describing what a server that is not listed as an MX for a domain but
is configured to accept mail for that domain should do. Also, how
would a server that is not configured to accept mail for a domain
know whether or not it is listed as an MX for that domain? This is
not the document to describe those situations. I'm OK with no/no and
yes/yes parts of the table.
I think the upper right box is also correct.
The text in the lower left box was only a suggestion for providing
text for the bounced mail that actually explains what is going
on. It would be sufficient if the message were "5xx we do not
accept mail for domain x.y". (the usual message is something
like "local configuration error") Of course if the server is willing
to act as a third-party relay, it can return "2xx message not local;
will forward" and go on its merry way... and it can decide whether
to accept third-party traffic based on whether the submitter has
authenticated with TLS and also on that submitter's identity.
(The server knows whether it's listed as an MX by looking up x.y in
DNS and seeing whether any of the domain names returned resolve to
any of its IP addresses.)
The point here is that the SMTP server is under no obligation to accept
mail (TLSed or otherwise) for a domain if it's not explicitly configured
as a mail exchanger for that domain. The fact that it's listed in DNS
is irrelevant.
I agree that this the text to be returned when the DNS and SMTP
configuration are out-of-sync isn't something that should be
defined in an SMTP-over-TLS document; it's a general SMTP issue.
2. similarly, if the client does do STARTTLS, if the server is *listed* in
DNS as an MX for the recipient's domain, it should not refuse to accept the
mail because the server doesn't recognize the client's credentials, or
because the server doesn't like the ciphersuite used, etc.
the server should act like is specified in the second row in the table above.
in other words, if the client is talking to a publically-listed server,
and has a proper implementation of TLS, its use of STARTTLS shouldn't lessen
the chance that the mail will be delivered.
That sounds right, but I would like to hear specific wording on it.
How's this?
A client's attempt (successful or otherwise) to use the STARTTLS command
SHOULD NOT cause a server to refuse to accept mail from a client, if the
server would have accepted the message without authentication, even if
the STARTTLS command or the subsequent TLS negotiation resulted in an error.
3. also in section 5
I don't understand the reason for this being a MUST:
Servers MUST be able to understand backwards compatible SSL Client
Hello messages (provided that client_version is TLS 1.0 or later),
and clients MAY use backwards compatible Client Hellos messages.
Neither clients or servers are required to actually offer Client
Hello messages for anything other than TLS 1.0.
I can see it being a SHOULD, but why should we insist that a SMTP server
that supports STARTTLS, also support outdated and nonstandard versions of
SSL?
Also, why is it not a MUST that Clients send TLS 1.0 Hello messages?
This was also noted by some TLS folks. Bodo Möller suggested the
following replacement:
Clients MAY use backwards compatible SSL Client Hello message
formats. However, except for SSL session resumption, Client
Hello messages MUST be suitable for negotiating TLS 1.0 or later
(i.e. the version field of SSL 2.0 compatible Client Hello
messages or the client_version field of SSL 3.0 compatible Client
Hello messages must be at least 3.1).
Servers MUST be able to understand backwards compatible SSL
Client Hello messages, provided that the client indicates that
it supports TLS 1.0 or later.
Note that neither clients nor servers are required to actually
support protocol versions other than TLS 1.0; but the above rules
make sure that clients can operate in a backwards-compatible mode
without risking interoperability with servers following the
current specifications.
This is completely bogus. The reason we have a TLS specification
is so people can get interoperability by implementing it. If they
instead implement some earlier specification that isn't TLS, they're
not meeting the requirements of the standard. SMTP servers that claim
to support STARTTLS and don't accept TLS 1.0 Hello messages are BROKEN,
full stop. Similarly, clients that issue a STARTTLS command and don't
send TLS 1.0 Hello messages are also BROKEN, full stop.
If a server wants to accept older Hello messages, that's its own
business. And servers would do well to parse older Hello messages
and continue with the TLS dialog even if they don't accept the
resulting client authentication as valid and don't treat the
negotiated session as if it were secure - just because it makes
for better error recovery. But client implementations shouldn't
expect that sending older Hello messages are going to make them
interoperable with servers that advertise STARTTLS.
4. in section 7
An SMTP client can partially protect against these attacks by
recording the fact that a particular SMTP server offers TLS during
one session and generating an alarm if it does not appear in the
EHLO response for a later session. The lack of TLS during a session
SHOULD NOT result in the bouncing of email, although it could result
in delayed processing.
it seems quite reasonable to explicitly configure a client to insist
on the server supporting TLS, and refusing to send a message to the
server if it doesn't advertise STARTTLS. this also seems safer than
the "automatic discovery" mechanism above.
This was discussed at length during the first round on this document,
and the consensus was to use the words that are here.
This is also bogus. People need to be able to change server configurations,
or switch from one server to another, without it causing bounced mail.
Experimenting with TLS on an SMTP server (and turning it off later)
should not cause subsequent mail for that SMTP server to bounce.
What you
propose does not go against the words in section 7 *if the client is
the orignator of the message*.
or if the client and the server are in the same administrative domain
and have an a priori agreement to use TLS.
If the client is an SMTP relay, what
you are proposing would cause mail to bounce,
I don't see how. What I'm proposing is intended to do two things
(a) to refuse to send mail over an insecure path if the client knows
a prior that the path is supposed to be secure
(b) to keep mail from bouncing when a server changes configuration
in the absence of firm knowledge that the path is supposed to be
secure
To put it simply, the fact that a particular server has used TLS in the
past should not be considered any indicator of whether it will do so
in the future.
and if there is explicit configuration to require STARTTLS along a
particular path, it seems perfectly reasonable for the client to refuse to
relay the message for as long as the server fails to support STARTTLS,
which could eventually result in a bounced message if delivery times out.
Again, that was not the consensus of the group.
the proposal needs consensus of the IETF, not just "the group".
"the group" probably needs to go back and think about this again.
(what group is this anyway?)
I find it completely bizarre that "the group" thinks that it's okay to
fall back to an insecure path if the client knows that a secure path
is supposed to be available. To behave in this way makes it easy
to defeat any confidentiality service that might be gained by
using TLS with SMTP.
Keith