[Top] [All Lists]

Re: Last Call: SMTP Service Extension for Secure SMTP over TLS to Proposed Standard

2001-07-08 19:35:48

[ietf-smtp(_at_)imc(_dot_)org copied - I suspect we need more SMTP folks on 

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

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 

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 

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

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.