----- Original Message -----
From: "John Levine" <johnl(_at_)iecc(_dot_)com>
To: <ietf-mxcomp(_at_)imc(_dot_)org>
Cc: <andy(_at_)hxr(_dot_)us>
Sent: Wednesday, June 30, 2004 6:26 PM
Subject: Re: CSV and STARTTLS
B.4.1 StartTLS ...
Does this imply that the strong authentication provided by certificate
validation of TLS is to be subjugated by CSV, which is most likely to
be weaker authentication?
I think you're misreading it. They're saying that in practice people
don't use signed SSL certs to validate the other end of an SMTP
connection. Looking at the logs of my mail servers, I see plenty of
TLS connections, but more often than not the certs are self-signed,
and in a lot of cases they just use a default cert shipped with the
MTA. If people were going to use TLS certs to authenticate their
mail channels, they'd be doing so already, but they're not.
Good point. We implemented outbound SSL/TLS but it is rare for us to hear or
know if anyone is really using it. I would be interested to know your
thoughts as to why "they are not."
The only possible reason I can think of is because it usually means
exclusive arrangements which is already done with IP Relays tables or SMTP
AUTH accounts. Any TLS security advantage is not guarantee between
multi-hop routes.
Opportunistic encryption is fine, but I don't see that as relating
to CSV one way or the other. If you want to do CSV checks and then
STARTTLS, you can easily do so.
hmmm, the way I see it is probably makes sense after TLS (and possible SMTP
AUTH) is established. Here is me reasoning:
From RFC 2847:
5.2 Result of the STARTTLS Command
Upon completion of the TLS handshake, the SMTP protocol is reset to
the initial state (the state in SMTP after a server issues a 220
service ready greeting). The server MUST discard any knowledge
obtained from the client, such as the argument to the EHLO command,
which was not obtained from the TLS negotiation itself. The client
MUST discard any knowledge obtained from the server, such as the list
of SMTP service extensions, which was not obtained from the TLS
negotiation itself. The client SHOULD send an EHLO command as the
first command after a successful TLS negotiation.
This could suggest TLS trumps CVS or CVS trump/alter the SASL/TLS standard
behavior.
A server can offers SASL/TLS which the client may use if offered. When the
client issues its EHLO domain, could the server CVS logic be activated in
such a way to turn off SASL or TLS EHLO response extensions display?
For example:
Client - SASL, TLS compliant, may or may not be CVS compliant
Server - SASL, TLS, CVS compliant
Client connects to server::
S: 220 mail.example.org SMTP service ready
C: EHLO mail.john.org
CVS activated. You have two scenarios.
#1 Client is non CVS compliant and the normal SMTP extension exposes TLS
and possible AUTH and other MARID features.
S: 250-mail.example.org welcomes you
S: 250-SIZE
S: 250-SUBMITTER
S: 250-AUTH LOGIN [plus other SASL methods. using LOGIN for simplicity]
S: 250 STARTTLS
#2 Client is CVS compliant. What will be the response?
S: 250-mail.example.org welcomes you
S: 250 SIZE
What you are saying that CVS should not change the response? Right?
Ok, I can see that and it makes sense for scenario #2 we have:
#2 Client is CVS compliant. Normal SMTP extension response.
S: 250-mail.example.org welcomes you
S: 250-SIZE
S: 250-SUBMITTER
S: 250-AUTH LOGIN
S: 250 STARTTLS
However, the problem (design conflicts) I see is more overhead and whether
there is a need for any more validation. If the client CVS is compliant and
is accepted, do we need anything else?
My plan for implementation, as it has been for all the LMAP (now MARID) is
to delay all validation overhead until it is 100% absolutely necessary.
Lets go thru this and lets assume that we continue displaying the SMTP
extensions after a successful CVS validation has taken place.
Scenario 2.1: Client continues with a TLS and fails.
Seems easy enough, the transaction doesn't continue.
Scenario 2.2: Client continues with a TLS and succeeds
In this case, the client per RFC 2847 reissues the EHLO
C: STARTTLS
S: 220 Go ahead
C & S: <negotiate a successful TLS session>
C: EHLO mail.john.org
So what I see here for a CVS server, it needs to turn off CVS validation at
this point and offer a new set SMTP extension responses:
S: 250-mail.example.org welcomes you again!
S: 250-SIZE
S: 250-SUBMITTER
S: 250 AUTH LOGIN
The new implementation question here is whether SUBMITTER and/or AUTH LOGIN
are still required.
I have no trouble removing SUBMITTER (Badly quoting Dorothy Parker: "Don't
throw it away. Throw it away with full force!").
But with SMTP AUTH we now begin to get new design issues and conflicts of
whether AUTH is required.
This will change quite a few things because the traditional SMTP mode of
operation is that trusted transaction using SMTP AUTH or IP relay tables
allows for routing, and to allow routing, well, that means "trust!"
So to keep with tradition, compatibility, reduce overhead and most
importantly sysop expectations for operations intact with all their roaming
users, we have no choice but to implement a delayed CVS processing after TLS
is applied and the establishment of any SASL negotiation as well.
In short:
I don't think CVS will directly change TLS but it will change how the SMTP
extensions are altered. Will CVS trump SMTP AUTH? It may if its applied
before the TLS process.
Make sense?
Thanks
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com