draft-hoffman-rfc2487bis-03.txt

[Paul Hoffman / IMC]

Greetings after a long time. I updated that rfc2487bis draft a month
ago but forgot to tell this list. Could all the folks who have
implemented STARTTLS for SMTP please review the draft and comment on
any changes needed? There is a list of the changes at the beginning
of section 1.

--Paul Hoffman, Director
--Internet Mail Consortium

[Lutz Jaenicke]

Post by Paul Hoffman / IMC
Greetings after a long time. I updated that rfc2487bis draft a month
ago but forgot to tell this list. Could all the folks who have
implemented STARTTLS for SMTP please review the draft and comment on
any changes needed? There is a list of the changes at the beginning
of section 1.

Ok :-) The new draft reflects the discussions taking place on
ietf-apps-tls with respect to STARTTLS for SMTP. I think it is a worthful
improvement of RFC2487.

I would like to discuss some points.

[Section 5]:
After receiving a 220 response to a STARTTLS command, the client
SHOULD start the TLS negotiation before giving any other SMTP
commands.

I would prefer MUST here instead of SHOULD. At the point given, the server
expects the TLS handshake to be initiated by the client by sending the TLS
ClientHello message. In order to be able to deal with the SHOULD condition,
the server software must be able to intercept the TLS handshake and "guess"
from the bytes coming in from the client, that this is another SMTP command
and not the ClientHello message. Depending on the implementation that may
be difficult to realize.
I don't think a MUST is too strict here. A client software must be able to
decide whether it is able to start a TLS handshake and only send the
STARTTLS command if all necessary conditions are fulfilled.

[Section 5.1]:
- A SMTP client would probably only want to authenticate an SMTP
server whose server certificate has a domain name that is the
domain name that the client thought it was connecting to.

This is a sufficient description for a MUA. The MUA has an entry for the
mailserver to be used and can check the server certificate against this
entry.
It is however not clear to me how a client MTA should handle this topic.
The MTA will obtain the server's name by performing a MX DNS-lookup, which
should return the canonical name. This name can however be different from
a CNAME given to customers.
Example: The mailserver "server.dom.ain" has the CNAME "mail.dom.ain" which
is given to customers as the address to submit emails with their MUAs.
Hence, the server certificate should be issued for "mail.dom.ain".
A client MTA will however try to contact "server.dom.ain" and will not be
able to authenticate the server.
This raises several points:
* The DNS lookup has to be considered insecure. Shall we think of an extension
to the STARTTLS protocal such that the server can present another certificate
based on the _recipient_ email address? HTTP is redesigned in this manner
to allow name based virtual hosting.
* Another possibility would be to use the dNSName feature in the
subjectAltName field. What names should be included?
All CNAMEs for the server and/or the names of the domains this server
receives email for?

[Section 7]:
A server announcing in an EHLO response that it uses a particular TLS
protocol should not pose any security issues, since any use of TLS
will be at least as secure as no use of TLS.

I am not sure I missed something: does this mean that a server can announce
a particular protocol in its EHLO response, such as
250 STARTTLS SSLv3 TLSv1
I have not seen this described before.

Best regards,
Lutz Jaenicke

[Bodo Moeller]

Post by Lutz Jaenicke
After receiving a 220 response to a STARTTLS command, the client
SHOULD start the TLS negotiation before giving any other SMTP
commands.
I would prefer MUST here instead of SHOULD.

So would I, and I said so one year ago when the previous revision of
the draft was being discussed on this mailing list (or possibly on
ietf-tls). Paul commented that the client should have the possibility
to send a clear "QUIT" command instead of starting a handshake.

I don't believe that there's any implementation that can handle this
(although it should be not too difficult to patch Postfix-TLS
accordingly since you're using BIO pairs :-), and I don't think that
it makes sense to require servers to be able to handle anything other
than a TLS handshake after the STARTTLS. Among other things, this
requires us to assume that the ASCII representation of "QUIT" (and of
any other SMTP command since the specification does not state that
only "QUIT" is allowed at this stage) will never coincide with the
first bytes of a valid TLS handshake message. While this may be the
case, it is just a coincidence and does not follow from the design
goals of the SMTP and TLS protocols.

If, after having issued the STARTTLS command, the client finds out
that some failure prevents it from actually starting a TLS handshake,
then it should just abort the connection.


Another issue that IMO should be discussed in the draft, but isn't,
is backwards compatibility. While specifying SSL 2.0 or SSL 3.0
connections is obviously out of the scope of the document, there
should be something on backwards compatible Client Hello messages,
i.e. Client Hellos with client_version of TLS 1.0 (or later)
but in the SSL 2.0 record format or in an SSL 3.0 record.
It's not quite clear to me if clients that use those backwards
compatible formats (and most, or even all, existing implementions do
this) violate the specification in draft-hoffman-rfc2487bis-03.txt.
If it's legal, then we have a problem because nothing in
draft-hoffman-rfc2487bis-03.txt requires servers to be able
to handle such Client Hello messages.

I think the specification should state that servers MUST be able
to understand backwards compatible Client Hello messages (provided
that client_version is TLS 1.0 or later), and that clients MAY
use backwards compatbile Client Hellos messages. Of course neither
clients or servers can be required to actually offer the full
protocols because the specification is just about TLS.

[Eric Rescorla]

Post by Bodo Moeller

Post by Lutz Jaenicke
After receiving a 220 response to a STARTTLS command, the client
SHOULD start the TLS negotiation before giving any other SMTP
commands.
I would prefer MUST here instead of SHOULD.

So would I, and I said so one year ago when the previous revision of
the draft was being discussed on this mailing list (or possibly on
ietf-tls). Paul commented that the client should have the possibility
to send a clear "QUIT" command instead of starting a handshake.

Thirded.

-Ekr

[Paul Hoffman / IMC]

Post by Bodo Moeller
If, after having issued the STARTTLS command, the client finds out
that some failure prevents it from actually starting a TLS handshake,
then it should just abort the connection.

I'm OK with this if everyone else is. It feels weird to me on a
protocol level, but I'm not an implementor. More opinions are welcome.

Post by Bodo Moeller
I think the specification should state that servers MUST be able
to understand backwards compatible Client Hello messages (provided
that client_version is TLS 1.0 or later), and that clients MAY
use backwards compatbile Client Hellos messages. Of course neither
clients or servers can be required to actually offer the full
protocols because the specification is just about TLS.

Sounds OK to me. Other voices?

--Paul Hoffman, Director
--Internet Mail Consortium

[Bodo Moeller]

Post by Paul Hoffman / IMC

Post by Bodo Moeller
If, after having issued the STARTTLS command, the client finds out
that some failure prevents it from actually starting a TLS handshake,
then it should just abort the connection.

I'm OK with this if everyone else is. It feels weird to me on a
protocol level, but I'm not an implementor. More opinions are welcome.

Maybe it *feels* weird, but requiring the server to detect whether
the bytes from the client are plain commands or a TLS/SSL record
*is* weird :-)

It just happens that none of the currently defined ContentType values
is a valid ASCII character, so it is in fact possible to tell a TLS
record from an SMTP command; but there is no systematic reason for
this. If you were to draw a state machine for SMTP with the STARTTLS
extension, then currently the most natural way to do this would be to
handle the peer's protocol data non-deterministically at this point of
the protocol, which doesn't easily translate into an implementation.

For having a well-structured implementation, you want to have a
clearly defined point during protocol execution where the TLS layer
starts to handle the network connection, with the SMTP protocol
implementation running on top of that. And I bet that even the less
well structured implementations make this assumption :-)

[John Gardiner Myers]

I suggest the following paragraph be appended to section 4:

A server which does not have a certificate installed and which does not
support any anonymous ciphers SHOULD NOT advertise the STARTTLS keyword
as it is not currently able to negotiate the use of TLS.

[Eric Rescorla]

Post by John Gardiner Myers
A server which does not have a certificate installed and which does not
support any anonymous ciphers SHOULD NOT advertise the STARTTLS keyword
as it is not currently able to negotiate the use of TLS.

Why this particular exception? Servers which have been configured not
to support any ciphers or any compression algorithms also shoulnd't
advertise. In short, servers which can't do TLS shoulnd't advertise
it.
-Ekr

[John Gardiner Myers]

Post by Eric Rescorla
Why this particular exception?

It's not an exception, it derives directly from the existing section 4.
It's an case which implementors commonly get wrong.

[Marc Shannon]

Post by John Gardiner Myers

Post by John Gardiner Myers
A server which does not have a certificate installed and which does not
support any anonymous ciphers SHOULD NOT advertise the STARTTLS keyword
as it is not currently able to negotiate the use of TLS.

It's an case which implementors commonly get wrong.

Further, it's also an area where past SMTP proxy servers have made mistakes.
The proxy servers attempt to validate the SMTP commands as a
man-in-the-middle, passing through the STARTTLS option knowing full well
that they won't allow for TLS negotiation anyway. In one particular case,
the proxy server responded "250 OK" to the STARTTLS command (and, in fact,
it responded that way to _any_ unrecognized command) leading to a serious
communications breakdown as the client was starting to negotiate TLS while
the server was happily awaiting its next plain-text command.

--Marc

[Eric Rescorla]

Post by Marc Shannon

Post by John Gardiner Myers

Post by John Gardiner Myers
A server which does not have a certificate installed and which does not
support any anonymous ciphers SHOULD NOT advertise the STARTTLS keyword
as it is not currently able to negotiate the use of TLS.

It's an case which implementors commonly get wrong.

Further, it's also an area where past SMTP proxy servers have made mistakes.
The proxy servers attempt to validate the SMTP commands as a
man-in-the-middle, passing through the STARTTLS option knowing full well
that they won't allow for TLS negotiation anyway. In one particular case,
the proxy server responded "250 OK" to the STARTTLS command (and, in fact,
it responded that way to _any_ unrecognized command) leading to a serious
communications breakdown as the client was starting to negotiate TLS while
the server was happily awaiting its next plain-text command.

As you suggest, I'd be happy to see a blanket statement that if you're
not prepared to negotiate TLS you shouldn't advertise STARTTLS.

The point I was trying to make is that there are all sorts of ways
to not be actually ready to negotiate TLS that are no more stupid
than not having a certificate. For instance not negotiating
any cipher suites or having a certificate that doesn't match
your cipher suite or whatever. (I definitely see this one a lot)
I don't see the point of specially mentioning this one.

-Ekr

[Lutz Jaenicke]

Post by Eric Rescorla

Post by Marc Shannon

Post by John Gardiner Myers

Post by John Gardiner Myers
A server which does not have a certificate installed and which does not
support any anonymous ciphers SHOULD NOT advertise the STARTTLS keyword
as it is not currently able to negotiate the use of TLS.

It's an case which implementors commonly get wrong.

Further, it's also an area where past SMTP proxy servers have made mistakes.
The proxy servers attempt to validate the SMTP commands as a
man-in-the-middle, passing through the STARTTLS option knowing full well
that they won't allow for TLS negotiation anyway. In one particular case,
the proxy server responded "250 OK" to the STARTTLS command (and, in fact,
it responded that way to _any_ unrecognized command) leading to a serious
communications breakdown as the client was starting to negotiate TLS while
the server was happily awaiting its next plain-text command.

As you suggest, I'd be happy to see a blanket statement that if you're
not prepared to negotiate TLS you shouldn't advertise STARTTLS.
The point I was trying to make is that there are all sorts of ways
to not be actually ready to negotiate TLS that are no more stupid
than not having a certificate. For instance not negotiating
any cipher suites or having a certificate that doesn't match
your cipher suite or whatever. (I definitely see this one a lot)
I don't see the point of specially mentioning this one.

Hmm. I think I/we do need some clarification. Section 4 states:
The STARTTLS keyword is used to tell the SMTP client that the SMTP
server is currently able to negotiate the use of TLS. It takes no
parameters.
Section 5 however allows
454 TLS not available due to temporary reason

So actually, section 5 implicitly allows the server to step back from its
STARTTLS offer.
Wo what does it mean? When TLS is not available for a temporary reason, why
did the server first offer STARTTLS, as it obviously is not able to negotiate
the use of TLS. Or does it mean: sending the 454 reply already is part of
the "negotiation" and negotiation!=TLS-handshake.

A server not having a certificate suitable for its cipher suite or not having
a certificate at all (leaving out the anonymous case here) will not be able to
complete the TLS handshake.
Hence it has the choice to either
a) not advertise STARTTLS in the first place
b) advertise STARTTLS but then send the 454 response when actually trying to
start the TLS handshake.
Alternative b) makes sense to me, if the administrator actually wants to
use STARTTLS but has made some configuration error and the server software
notices this error.
I think this is more consistant than alternative a) which would ignore the
intention of the administrator by simply not advertising STARTTLS.

Of course, when the admin never checks his setup, the 454 response will stay
for an unlimited amount of time.

The server in any case should not send the 220 Ready to start TLS response
if it cannot fulfill the requirements for a successfull TLS handshake.

Best regards,
Lutz

[Claus Assmann]

Post by Lutz Jaenicke
The STARTTLS keyword is used to tell the SMTP client that the SMTP
server is currently able to negotiate the use of TLS. It takes no
parameters.
Section 5 however allows
454 TLS not available due to temporary reason
So actually, section 5 implicitly allows the server to step back from its
STARTTLS offer.
Wo what does it mean? When TLS is not available for a temporary reason, why
did the server first offer STARTTLS, as it obviously is not able to negotiate
the use of TLS. Or does it mean: sending the 454 reply already is part of
the "negotiation" and negotiation!=TLS-handshake.

This may happen because some part of the setup is done after the
initial greeting, esp. if it is expensive to do so. This will happen
in the current sendmail implementation if generating a temporary
RSA key will fail (yes, I know we could generate one beforehand
and reuse it a few times...).

Post by Lutz Jaenicke
A server not having a certificate suitable for its cipher suite or not having
a certificate at all (leaving out the anonymous case here) will not be able to
complete the TLS handshake.
Hence it has the choice to either
a) not advertise STARTTLS in the first place
b) advertise STARTTLS but then send the 454 response when actually trying to
start the TLS handshake.
Alternative b) makes sense to me, if the administrator actually wants to
use STARTTLS but has made some configuration error and the server software
notices this error.

The server should only offer STARTTLS if it "normally" can perform
the TLS handshake, i.e., all checks up to this point have been successful.
If later on something fails (e.g., actually creating the session context),
then the server should say so before starting the TLS handshake
and failing at that level.

Post by Lutz Jaenicke
I think this is more consistant than alternative a) which would ignore the
intention of the administrator by simply not advertising STARTTLS.

If there is a configuration error, then IMHO either
- the server shouldn't start at all
- log an error and continue but not offer STARTTLS
The main point here is to let the admin know that something is wrong.

Post by Lutz Jaenicke
Of course, when the admin never checks his setup, the 454 response will stay
for an unlimited amount of time.

And then it is up to the sender what to do...

Post by Lutz Jaenicke
The server in any case should not send the 220 Ready to start TLS response
if it cannot fulfill the requirements for a successfull TLS handshake.

Which brings me to the point of "broken" (non-interoperable)
implementations. Unless I missed it, I can't see a recommendation
in the draft what to do in that case, i.e., drop the connection.
Something to this extend should be added.

[Bodo Moeller]

Post by Lutz Jaenicke
The STARTTLS keyword is used to tell the SMTP client that the SMTP
server is currently able to negotiate the use of TLS. It takes no
parameters.
Section 5 however allows
454 TLS not available due to temporary reason
So actually, section 5 implicitly allows the server to step back from its
STARTTLS offer.

No. This 454 is a reply that clients may see in response to STARTTLS
when STARTTLS was not offered in the EHLO reply.

[Lutz Jaenicke]

Post by Bodo Moeller

Post by Lutz Jaenicke
The STARTTLS keyword is used to tell the SMTP client that the SMTP
server is currently able to negotiate the use of TLS. It takes no
parameters.
Section 5 however allows
454 TLS not available due to temporary reason
So actually, section 5 implicitly allows the server to step back from its
STARTTLS offer.

No. This 454 is a reply that clients may see in response to STARTTLS
when STARTTLS was not offered in the EHLO reply.

My understanding is that a client should not use the STARTTLS command if
it was not offered. It may see a 5xx reply in that case.

Best regards,
Lutz

[RL 'Bob' Morgan]

Post by Lutz Jaenicke
My understanding is that a client should not use the STARTTLS command if
it was not offered. It may see a 5xx reply in that case.

A client that wants to protect itself against an active attacker deleting
the STARTTLS in the EHLO from the server should go ahead and do STARTTLS
anyway.

- RL "Bob"

[Marc Shannon]

Post by RL 'Bob' Morgan
A client that wants to protect itself against an active attacker deleting
the STARTTLS in the EHLO from the server should go ahead and do STARTTLS
anyway.

I'm sorry, but perhaps I'm missing something here.

If an active attacker (I presume you mean as a man-in-the-middle attack)
deletes the STARTTLS extension offering, then what's to stop it from
responding 4xx (or 5xx, although it probably wouldn't as it wants to receive
the message) to the STARTTLS command and hoping that the client would
proceed with plain-text anyway.

--Marc

[Lutz Jaenicke]

Post by RL 'Bob' Morgan

Post by Lutz Jaenicke
My understanding is that a client should not use the STARTTLS command if
it was not offered. It may see a 5xx reply in that case.

A client that wants to protect itself against an active attacker deleting
the STARTTLS in the EHLO from the server should go ahead and do STARTTLS
anyway.

Agreed.

Ok, I will discuss an implementation to make clear how I understand the
STARTTLS negotiation. Actually, I will be discussing Postfix/TLS (in a
future version :-)
For those not familiar with Postfix (www.postfix.org, probably the readers of
this list are somewhat aware of the postfix MTA): Postfix consists of
several daemon processes, that are started on demand and that are initialized
when started. It is part of the security policy that the interdependency
between daemons is as small as possible. There is no "master" process that
is forked and so automatically distributes information to its children.

Whenever an incoming SMTP connection is accepted a new "smtpd" process is
started (or an idle one is reused). As of now, this means that all information
necessary to run the smtpd process has to be acquired at this time, and
this also includes the TLS data like keys, random seed etc. So at EHLO
time the server knows whether it can start TLS and hence can offer STARTTLS
(or may decide to not offer it).
In a future version, the TLS-layer/processing will be performed in a seperate
process, offering the advantage that the information is better encapsulated
for security reasons. It could also have performance advantages. Only a
small number of clients actually uses STARTTLS, so the TLS initialization
is often done in vein and should be delayed until really necessary.
* SMTP connection is opened
- Client sends EHLO
- Server is configured to use TLS, so STARTTLS is offered.
- Client sends STARTTLS
- Server now starts TLSserver process and notes, that for some reason
whatsoever (certificate expired, no random number seeding) the configuration
does not allow to successfully perform a TLS handshake [even though the
administrator actually wanted TLS to be enabled].
-> Server answers 454 TLS not available due to temporary reason
- Client decides whether to continue or not...

Post by RL 'Bob' Morgan
From my understanding of RFC 2487 (and the latest draft) this behaviour

is conform with respect to the standard.
For the client side it is easier, as the client can wait with its decision
whether it wants to issue a STARTTLS command.

Best regards,
Lutz

[John Gardiner Myers]

Post by RL 'Bob' Morgan
From my understanding of RFC 2487 (and the latest draft) this behaviour
is conform with respect to the standard.

You are violating at least the intent of section 4. You are doing the
clients a grave disservice by advertising a capability when the obvious
necessary preconfiguration for that capability (such as installing a
cert) has not been done.

Since TLS certs are not common, such an implementation strategy is most
likely to lead to a server population advertising STARTTLS but unable to
negotiate TLS far outnumbering the server population capable of
negotiating TLS. In such a situation, the STARTTLS keyword would have
negligible informational value; it would be worthless.

[Bodo Moeller]

Post by Lutz Jaenicke

Post by Bodo Moeller

Post by Lutz Jaenicke
The STARTTLS keyword is used to tell the SMTP client that the SMTP
server is currently able to negotiate the use of TLS. It takes no
parameters.
Section 5 however allows
454 TLS not available due to temporary reason
So actually, section 5 implicitly allows the server to step back from its
STARTTLS offer.

No. This 454 is a reply that clients may see in response to STARTTLS
when STARTTLS was not offered in the EHLO reply.

My understanding is that a client should not use the STARTTLS command if
it was not offered. It may see a 5xx reply in that case.

The client *should* not use the STARTTLS command, but if it does
anyway (e.g. because it is configured to always use STARTTLS when
connecting to that host and thus the reply to the initial EHLO is not
even parsed), why not use a reply that tells the client that the
server does understand the STARTTLS command in principle, but cannot
handle it at the moment? As this reply is not cryptographically
authenticated, it does not provide any security advantages whatsoever
(assuming that plain TCP over plain IP is used), but it may be helpful
for tracking down configuration problems.

(Also, if the server initially thinks that it can handle TLS, but
initialization fails for some reason, this 454 response may make sense;
or maybe just abort the connection. There can always be unpredicted
problems, such as someone removing the smart card that is responsible
for private key operations, or the process running out of memory,
or a power failure, or whatever.)

[Lutz Jaenicke]

Post by Bodo Moeller

Post by Lutz Jaenicke

Post by Bodo Moeller
No. This 454 is a reply that clients may see in response to STARTTLS
when STARTTLS was not offered in the EHLO reply.

My understanding is that a client should not use the STARTTLS command if
it was not offered. It may see a 5xx reply in that case.

The client *should* not use the STARTTLS command, but if it does
anyway (e.g. because it is configured to always use STARTTLS when
connecting to that host and thus the reply to the initial EHLO is not
even parsed), why not use a reply that tells the client that the
server does understand the STARTTLS command in principle, but cannot
handle it at the moment? As this reply is not cryptographically
authenticated, it does not provide any security advantages whatsoever
(assuming that plain TCP over plain IP is used), but it may be helpful
for tracking down configuration problems.

It seems we are thinking the same thing, just expressing it in a different
way :-)

The client can send a STARTTLS whether it was announced or not. The client
then must be able to handle the answer of the server, which can be
2xx The server can initiate the TLS handshake (STARTTLS announced or not)
4xx The server can not initiate the TLS handshake as of now, maybe later.
5xx The server cannot initiate the TLS handshake, because it is not able to
do it or does not want to do it.

Now it is up to the client to decide. For a 4/5xx answer, the client can
decide to continue without encryption. If encryption is obligatory, the
client will probably bounce the message for the 5xx answer, as it cannot
expect TLS to become available, or retry later for a 4xx answer when the
problem with the server has been solved. (That's what I might do, but this
decision is left to the client.)
This should hold whether STARTTLS was offered (or filtered out by an attacker)
or not, as the 2/4/5xx answer may have been altered on the way, too.

It should just be clear that the client MUST not send a STARTTLS if it
cannot initiate the TLS handshake itself at this time.

Post by Bodo Moeller
(Also, if the server initially thinks that it can handle TLS, but
initialization fails for some reason, this 454 response may make sense;
or maybe just abort the connection. There can always be unpredicted
problems, such as someone removing the smart card that is responsible
for private key operations, or the process running out of memory,
or a power failure, or whatever.)

Yes.

I a certain sense I discussed the use of MUST, SHOULD etc with respect to
the implementation. Of course the operator must be taken into account, too.
Any MTA server implementation will fullfill the "STARTTLS MUST only be offered
when the server is actually ready to initiate the TLS handshake" when I
additionally take into account, that the operator of the server must take
care of the correct installation and setup (otherwise it will not comply
to the standard). The implementation cannot take into account all possible
causes of failure (even though it probably SHOULD try its best to do so).

Best regards,
Lutz

[John Gardiner Myers]

Post by Lutz Jaenicke
A server not having a certificate suitable for its cipher suite or not having
a certificate at all (leaving out the anonymous case here) will not be able to
complete the TLS handshake.
Hence it has the choice to either
a) not advertise STARTTLS in the first place
b) advertise STARTTLS but then send the 454 response when actually trying to
start the TLS handshake.
Alternative b) makes sense to me, if the administrator actually wants to
use STARTTLS but has made some configuration error and the server software
notices this error.
I think this is more consistant than alternative a) which would ignore the
intention of the administrator by simply not advertising STARTTLS.

Who said the administrator stated an intention?

The situation I've seen is where the server software implements
STARTTLS, advertising it out of the box with the administrator's having
taken no action other than to install the software. In such a case
there is no cert and STARTTLS cannot possibly complete a handshake, yet
clients which implement STARTTLS are penalized with an extra round trip
when talking to such servers.