ESMTP: STARTTLS with "target domain" parameter(s)
Andrzej Adam Filip
"target domain" parameter(s)?
It would allow mail servers servicing multiple domains to
"authenticate themselves" *to sending host*" as responsible
for the domain using SSL certificate.
Later it would ease implementation of "two way authentication"
based on SSL certificates (server to client and client to server).
URL(s):
http://www.rfc-editor.org/rfc/rfc2487.txt
SMTP Service Extension for Secure SMTP over TLS
--
[pl>en Andrew] Andrzej Adam Filip : an...@onet.eu : Andrze...@gmail.com
Democracy is a form of government in which it is permitted to wonder
aloud what the country could do under first-class management.
-- Senator Soaper
ska
> Do you think it would make sense to make STARTTLS support
> "target domain" parameter(s)?
IMHO every STARTTLS regardless of SMTP, IMAP, POP3 a.s.o. should
accept a target domain optionally.
One could question how a server should react, if the domain is not
supported, e.g. use a default cert in order to avoid probing for
domains
vs. return a failure.
-ska
Henning Hucke
Hello Andrzej,
> Do you think it would make sense to make STARTTLS support
> "target domain" parameter(s)?
I think you misunderstand what certificates proof.
I understand that mail hosters might want to use different MX names in
relation to the customers they host but an MTA contacts an IP address in
the end. And relying on what a remote party is requesting usually triggers
more problems than it solves.
If a hoster wants to enable _strong_ authentication of its own server(s)
they shoud use the name(s) in the certificate for _every_ DNS MX-RR not
regarding for which domain they function as the MXer.
> It would allow mail servers servicing multiple domains to
> "authenticate themselves" *to sending host*" as responsible
> for the domain using SSL certificate.
You don't proof to be responsible for the domain! You proof to have a
specific host name. Strong authentication with SMTP-STARTTLS means that a
sending MTA retrieves the name of the MXer for a domain being
"server.domain.tld" and the server presents a certificate which contains
at least this name in its "CN" field. If a hoster uses multiple names for
the same server or load balances to a server cluster/array he should
include the alternative names in the "altSubject" attribute of the
certificate possibly with the main name or the name for the virtual IP in
the CN of the subject attribute.
> [...]
Regards
Henning
--
I don't normally kill strangers, but I seem to have run out of friends.
Andrzej Adam Filip
Your arguments do make sense in "very stable/simple" or "ordered like
atoms in crystal" email configurations. It makes less sense (IMHO) in
much more dynamic configuration adapting in very wide range to server
failures and load changes where MXes for domain example.net may be
expected to present certificates for mx[0-9]+.example.net.
BTW parametrized STARTTLS" would allow running "inbound proxies" with
"per email destination domain" rerouting of encrypted TCP connections.
P.S.
I am personally dead sure it will provide some benefits.
I would like to poll for opinions about its "cost effectiveness".
Your statements have forced me to "adapt argumentation" :-)
--
[pl>en Andrew] Andrzej Adam Filip : an...@onet.eu : Andrze...@gmail.com
Open-Sendmail: http://open-sendmail.sourceforge.net/
What we see depends on mainly what we look for.
-- John Lubbock
ska
> On Thu, 29 Oct 2009, Andrzej Adam Filip wrote:
>
> Hello Andrzej,
>
> > Do you think it would make sense to make STARTTLS support
> > "target domain" parameter(s)?
>
> I think you misunderstand what certificates proof.
>
> I understand that mail hosters might want to use different MX names in
> relation to the customers they host but an MTA contacts an IP address in
> the end. And relying on what a remote party is requesting usually triggers
> more problems than it solves.
You talk about MTA, but what about MSA ? As end-user I would wonder
why I should connect to "smtp.some.wicked.domain" instead of
"smtp.my.domain".
I would not call "STARTTLS domain-i-want-to-connect-to" as "rely on
remote info", but just hinting. e.g. passing along the symbolic name
used to connect to the server.
In http the very same feature had to be implemented later on, now it
is called virtual hosting.
-ska
Andrzej Adam Filip
Even MSA may use it to allow smtp.very-big-corporation.com redirect
incoming smtp(s) connection (after STARTTLS) to
smtp.very-secret-department.very-big-corporation.com "residing" on
private IP address (e.g. 10.20.0.1).
Do you Henning expect all departments in very-big-corporation to trust
each other *fully*? ;-)
P.S.
IMHO the idea would provide some benefits for sure.
I am much less sure if implementing it would be "cost effective".
No server can be forced in ESMTP framework to serve extension it is
unwilling to serve.
--
[pl>en Andrew] Andrzej Adam Filip : an...@onet.eu : Andrze...@gmail.com
Politicians are the same all over.
They promise to build a bridge even where there is no river.
-- Nikita Khrushchev
Andrzej Adam Filip
> On Fri, 30 Oct 2009, Andrzej Adam Filip wrote:
>
>> [...]
>> Your arguments do make sense in "very stable/simple" or "ordered like
>> atoms in crystal" email configurations. It makes less sense (IMHO) in
>> much more dynamic configuration adapting in very wide range to server
>> failures and load changes where MXes for domain example.net may be
>> expected to present certificates for mx[0-9]+.example.net.
>
>
> And even more what you suggest is like chasing the devil with the
> belzebub which means that you assult X.509 certificates to solve a
> problem which first of all can be solved with other mechanisms and
> second of all doesn't show up that often.
>
> Take into account that we will have secured DNS data in the nearer
> future and then take into account that the remote site can proofe that
> it is what it is supposed to be.
>
>> BTW parametrized STARTTLS" would allow running "inbound proxies" with
>> "per email destination domain" rerouting of encrypted TCP connections.
>
> security.
>
> All you need is secure information about who is responsible for a
> domain - MX-RRs with DNSSEC - and a proof that the specified system
> wasn't replaced - simple STARTTLS with comparision of MX-RR against
> Subject-CN and eventuall AltSubject-CNs. Simply asserting that a site
> is responsible for a specific mail domain doesn't help much as long as
> this assertion can't be verified with another source of information...
1) I do believe in multiple "cross-checks"
2) I do believe that allowing "inbound fronted proxies for may 'internal' servers"
would be "interesting++" for many netmasters.
Inbound proxy may block connections from "very bad networks", offer
(D)DoS protection, do initial checks during SSL handshake but
in the end external client would get encrypted connection to internal
mail server without easy access to unencrypted content by MTA in the
middle.
P.S.
To shorten our discussion - it is unlikely I am going to implement it.
--
[pl>en Andrew] Andrzej Adam Filip : an...@onet.eu : Andrze...@gmail.com
"Who is General Failure and why is he reading my hard disk?"
Microsoft spel chekar vor sail, worgs grate !!
-- Felix von Leitner, lei...@inf.fu-berlin.de
Henning Hucke
> Henning Hucke wrote:
> [...]
>> I understand that mail hosters might want to use different MX names in
>> relation to the customers they host but an MTA contacts an IP address in
>> the end. And relying on what a remote party is requesting usually triggers
>> more problems than it solves.
>
> You talk about MTA, but what about MSA ? As end-user I would wonder
> why I should connect to "smtp.some.wicked.domain" instead of
> "smtp.my.domain".
You would prefer to use protocols/standard off their specs just because
you don't like to see things which might make you wonder?
Strange view.
But beside of that I described the possibility to use alternative names in
altSubject attributes of a certificate. And even these you only need for
MX-RRs for which CNAMEs are discouraged.
> I would not call "STARTTLS domain-i-want-to-connect-to" as "rely on
> remote info", but just hinting. e.g. passing along the symbolic name
> used to connect to the server.
And would that help with *STARTTLS*!? What if I'm only allowed to connect
to a setup for Company A but I connect to the MSA with "STARTTLS compB".
That's what I call "relying on remote info". You might retort that one
might check this with other mechanisms but then you don't need certs
anymore - well at least you foil them to a certain degree.
> In http the very same feature had to be implemented later on, now it
> is called virtual hosting.
There are deep ranging differences between http virtual hosting and
hosting multiple domains with a given MTA/MSA setup.
All in all your "arguments" seem to be driven from what you would like to
have instead of what you know about protocols and their appropriate and
acceptable use.
Best regards
Henning
--
"My country right or wrong" is like saying, "My mother drunk or
sober."
-- G.K. Chesterton
Henning Hucke
> [...]
> incoming smtp(s) connection (after STARTTLS) to
> smtp.very-secret-department.very-big-corporation.com "residing" on
> private IP address (e.g. 10.20.0.1).
Using STARTTLS in this context is useless use of certs.
> Do you Henning expect all departments in very-big-corporation to trust
> each other *fully*? ;-)
The primary sense of Certificate Authorities (CAs) is to trust certs they
sign as long as one trusts the CA! So yes, it would be the sense of a
very-big-corporation CA cert to trust all certs (might it be a user or a
subCA cert and certs signed with the later) which are directly or
indirectly signed with it.
Andrzej, you are without question quite competent concerning sendmail and
its rule system but it strongly seems to me that you are not familiar with
certificates and their use... Trust me! I know what I'm talking about %-)
(as far as I talk about it ;).
> P.S.
> IMHO the idea would provide some benefits for sure.
That's something I don't doubt. But as stated: I see more problems
triggered by such a mechanism than triggered facilities.
> I am much less sure if implementing it would be "cost effective".
> No server can be forced in ESMTP framework to serve extension it is
> unwilling to serve.
That's one of the "problems". It doesn't help enough to be widely
implemented.
I would be _much_ more effective to redesign MTAs to seamlessly implement
real virtual hosting. Even postfix doesn't do that. And the SMTP protocol
itself is one of the reasons why this will hardly be possible; in contrast
to HTTP it intentionally implements routing.
Best regards
Henning
--
I'm receiving a coded message from EUBIE BLAKE!!
Andrzej Adam Filip
> On Mon, 2 Nov 2009, Andrzej Adam Filip wrote:
>
>> [...]
>> incoming smtp(s) connection (after STARTTLS) to
>> smtp.very-secret-department.very-big-corporation.com "residing" on
>> private IP address (e.g. 10.20.0.1).
>
> Using STARTTLS in this context is useless use of certs.
>
>> Do you Henning expect all departments in very-big-corporation to trust
>> each other *fully*? ;-)
>
> The primary sense of Certificate Authorities (CAs) is to trust certs
> they sign as long as one trusts the CA! So yes, it would be the sense
> of a very-big-corporation CA cert to trust all certs (might it be a
> user or a subCA cert and certs signed with the later) which are
> directly or indirectly signed with it.
>
> Andrzej, you are without question quite competent concerning sendmail
> and its rule system but it strongly seems to me that you are not
> familiar with certificates and their use... Trust me! I know what I'm
> talking about %-)
> (as far as I talk about it ;).
From my perspective you take "the way it is (typically) used" for
"the only way to use it". I am accustomed to drag things far above
and beyond original design goals.
Some services use "client certificates" as a substitute to authentication.
There is nothing to stop clients from using SSL certificates to
authenticate server to themselves - to use SSL for "both ways" authentication.
--
[pl>en Andrew] Andrzej Adam Filip : an...@onet.eu : Andrze...@gmail.com
Life is a grand adventure -- or it is nothing.
-- Helen Keller
Andrzej Adam Filip
> On Sat, 7 Nov 2009, Andrzej Adam Filip wrote:
>
> ((You should never ever write a mail reply without making clear that this
> reply also goes into the newsgroup! This is very bad style! :-( ))
> [...]
I can assure you I do consider it to be "a bad habit" too.
It was subtle consequence of "new&experimental configuration" fixed
after first occurrence.
[ I have replied from gnus "cache of usenet group" group I intended to
hold posts to reply later - I assumed (without checking) that the reply
would go to the newsgroup but Gnus' idea of "reasonable assumption" has
been different. I also assumed (wrongly=without checking) that I have
stopped email before it has gone out. ]
P.S. I treat my "personal host" as permanent experiment.
--
[pl>en Andrew] Andrzej Adam Filip : an...@onet.eu : Andrze...@gmail.com
Open-Sendmail: http://open-sendmail.sourceforge.net/
Small is beautiful.
-- Schumacher's Dictum
Andrzej Adam Filip
> On Sat, 7 Nov 2009, Andrzej Adam Filip wrote:
> [...]
>> "the only way to use it". I am accustomed to drag things far above
>> and beyond original design goals.
>>
>> Some services use "client certificates" as a substitute to authentication.
>> There is nothing to stop clients from using SSL certificates to
>> authenticate server to themselves - to use SSL for "both ways"
>> authentication.
>
> well as clients as well as _servers_. Thats exactly what I was talking
> about.
>
> You can "boost" usages of protocols - a certificate is also a
> protocol, a convention - beyong their initial purpose but you should
> do it in a sensible and especially consistent manner and
>
> using _multiple_ certificates for one and the same entity - the mail
> server on which you host multiple independent (read as AS / autonomious
> system) domains or the relay (of one or the other kind) to them - is
> far beyond the sense and intention of a certificate and triggers such a
> lot of inconsitencies that... I can't find words for it %-).
>
> Read: "STARTTLS <domain in my mind>" is rubbish and - even more than that
> - evil.
>
> [... Personal part removed ...]
I do not assume that one "smtp destination" (IP address) *MUST* mean
one physical/logical smtp server. For me extending STARTTLS syntax is
an elegant way to support it. I do not talk about "MUST provide/accept
destination domain as parameter", I talk about "MAY provide/accept
destination domain parameter". (In future if it is deployed) Server may
decide not to offer support for it, client may decide to ignore that
server supports it.
I may (reluctantly) agree that extending STARTTLS may be not the best
way to achieve "virtual SMTP" server and "inbound proxying" of SMTP
connections.
BTW For me "trust tree" sucks as design (trust in tree topology).
I would strongly prefer multiple independent sources confirming
"validity".
--
[pl>en Andrew] Andrzej Adam Filip : an...@onet.eu : Andrze...@gmail.com
Open-Sendmail: http://open-sendmail.sourceforge.net/
If I could drop dead right now, I'd be the happiest man alive!
-- Samuel Goldwyn
Henning Hucke
> [...]
> I do not assume that one "smtp destination" (IP address) *MUST* mean
> one physical/logical smtp server. For me extending STARTTLS syntax is
> an elegant way to support it. I do not talk about "MUST provide/accept
> destination domain as parameter", I talk about "MAY provide/accept
> destination domain parameter". (In future if it is deployed) Server may
> decide not to offer support for it, client may decide to ignore that
> server supports it.
Andrzej,
certificates authenticate a communications partner. Even / especially if
you load-balance you either need one and the same certificate on all load
balanced machines or (better) a certificate on the dispatcher with STARTTLS
against the dispatcher or a separate certificate on every destination MTA
(depending on your load balancing mechanism, might it be TCP, "application
level gateway" or DNS load balancing).
If you connect to machine "mailprocessor.mydom.ain" the clients correctly
expects to see a certificate for "mailprocessor.mydom.ain" or at least
this name in an altSubject.
There is no way for the server to figure out which name was resolved to
its IP (which points to some kind of solution which is easily
implementable with today's MTAs: bind multiple instances to different IPs
and give each instance a separate certificate in its configuration).
> I may (reluctantly) agree that extending STARTTLS may be not the best
> way to achieve "virtual SMTP" server and "inbound proxying" of SMTP
> connections.
There is actually no such thing as "virtual SMTP". You always route mails
towards their destination mail servers on which you have diverse recipient
eventually destined at different domains.
If you want to break the principals behind SMTP do it but live with the
implications. Otherwise its like the bear saying "wash me but don't make
me wet". Either wash the bear of don't make him wet!
> BTW For me "trust tree" sucks as design (trust in tree topology).
> I would strongly prefer multiple independent sources confirming
> "validity".
The "trust tree" is the implicit nature of X.509 certificates. If you
don't like it develop another cryptographic system or implement something
which uses PGP certificates. But even PGP certificates authenticate
*entities*!
> [...]
Regards
Henning
--
Conservative:
One who admires radicals centuries after they're dead.
-- Leo C. Rosten
Andrzej Adam Filip
> On Sun, 8 Nov 2009, Andrzej Adam Filip wrote:
>
>> [...]
>> I do not assume that one "smtp destination" (IP address) *MUST* mean
>> one physical/logical smtp server. For me extending STARTTLS syntax is
>> an elegant way to support it. I do not talk about "MUST provide/accept
>> destination domain as parameter", I talk about "MAY provide/accept
>> destination domain parameter". (In future if it is deployed) Server may
>> decide not to offer support for it, client may decide to ignore that
>> server supports it.
>
> if you load-balance you either need one and the same certificate on
> all load balanced machines or (better) a certificate on the dispatcher
> with STARTTLS against the dispatcher or a separate certificate on
> every destination MTA (depending on your load balancing mechanism,
> might it be TCP, "application level gateway" or DNS load balancing).
> If you connect to machine "mailprocessor.mydom.ain" the clients
> correctly expects to see a certificate for "mailprocessor.mydom.ain"
> or at least this name in an altSubject.
>
> There is no way for the server to figure out which name was resolved
> to its IP (which points to some kind of solution which is easily
> implementable with today's MTAs: bind multiple instances to different
> IPs and give each instance a separate certificate in its
> configuration).
You argue for my side, do not you? "STATTLS with domain" would give
server idea about name client wanted to talk to.
>> I may (reluctantly) agree that extending STARTTLS may be not the best
>> way to achieve "virtual SMTP" server and "inbound proxying" of SMTP
>> connections.
>
> There is actually no such thing as "virtual SMTP". You always route
> mails towards their destination mail servers on which you have diverse
> recipient eventually destined at different domains.
> If you want to break the principals behind SMTP do it but live with
> the implications. Otherwise its like the bear saying "wash me but
> don't make me wet". Either wash the bear of don't make him wet!
SMTP is nothing more than an *UGLY* but anyhow very useful tradition.
The best way would be to create new protocol but (E)SMTP is widespread
enough and somehow capable to work to make such move "wishful thinking"
in near term future.
I merely have tried to follow "one more 'small' improvement" path that
keeps ESMTP useful.
>> [...]
>> 2) I do believe that allowing "inbound fronted proxies for may 'internal' servers"
>> would be "interesting++" for many netmasters.
>> Inbound proxy may block connections from "very bad networks", offer
>> (D)DoS protection, do initial checks during SSL handshake but
>> in the end external client would get encrypted connection to internal
>> mail server without easy access to unencrypted content by MTA in the
>> middle.
>
> What you describe is actually a relay. Implement it as a relay, supply
> this relay with an apporpriate certificate and there is no need for
> "STARTTLS <what I want to present>"!
It is a matter of "personally preferred style(guide)".
>> [...]
>
> Imagine two "real" MTAs behind a "STARTTLS <selector>"-relay/balancer.
> One is for companyA and the other for companyB.
> What happens if the source says "STARTTLS companyA" but later emits a
> "RCPT TO:<user@companyB>" (or vice versa)? Or what if it emits "RCPT
> TO:<user@companyA>\nRCPT TO:<user@companyB>"?
> Do load balancing in the sense of these words but push away thoughts
> on something like "STARTTLS <selector>" and even from something like
> "CONNECT <selector>". _It_ _triggers_ _more_ _problems_ _than_ _it_
> _solves_ (_are_ there _any_ *problems* which need to be _solved!?).
By using "STARTLS domainA" client would give server "right" to reject
recipients in other domains.
--
[pl>en Andrew] Andrzej Adam Filip : an...@onet.eu : Andrze...@gmail.com
Open-Sendmail: http://open-sendmail.sourceforge.net/
Moderation is a fatal thing. Nothing succeeds like excess.
-- Oscar Wilde
Andrzej Adam Filip
> On Tue, 10 Nov 2009, Andrzej Adam Filip wrote:
>
>> [...]
>>> to its IP (which points to some kind of solution which is easily
>>> implementable with today's MTAs: bind multiple instances to different
>>> IPs and give each instance a separate certificate in its
>>> configuration).
>>
>> You argue for my side, do not you? "STATTLS with domain" would give
>> server idea about name client wanted to talk to.
>
> server a statement of the client under which name it found the
> server. This opens the client all and every door to _fake_ this
> statement. So in effect the statement of the client is untrustable and
> therefore useless.
Client would present in "STARTLS with (optional) domain" "name" it wants
to talk to. Server would check if it supports the name or not.
How client located the name is irrelevant in my opinion.
>> [...]
>>> Imagine two "real" MTAs behind a "STARTTLS <selector>"-relay/balancer.
>>> One is for companyA and the other for companyB.
>>> What happens if the source says "STARTTLS companyA" but later emits a
>>> "RCPT TO:<user@companyB>" (or vice versa)? Or what if it emits "RCPT
>>> TO:<user@companyA>\nRCPT TO:<user@companyB>"?
>>> Do load balancing in the sense of these words but push away thoughts
>>> on something like "STARTTLS <selector>" and even from something like
>>> "CONNECT <selector>". _It_ _triggers_ _more_ _problems_ _than_ _it_
>>> _solves_ (_are_ there _any_ *problems* which need to be _solved!?).
>>
>> By using "STARTLS domainA" client would give server "right" to reject
>> recipients in other domains.
>
> Aha...
>
> You suppress a common example from above:
> I want to send a mail to "user@compA" and "user@compB". My MTA queries
> DNS for the MX-RR of these two domains and gets one and the same
> destination IP. Sensefully it doesn't split the mail but wants to send
> it to the server. It realizes via ESMTP that the server speaks
> STARTTLS and ESTARTTLS ("STARTTLS with domain"). Not only that your
> mechanism forces the sending server to talk much more than before but
> you also force it to modify its routing mechanism and even more than
> that you force it to make a "_late_ routing decision" ("Destination
> server speaks ESTARTTLS so I have to split the mail _now_", which - by
> the way - is eventually not necessary for the case that at least these
> two domains are located on the same server behind the ESTARTTLS
> relay).
Client may:
a) use one smtp connection with "STARTTLS without domains" [default]
b) "split" the message and send it over two smtp connections with
"STARTTLS with domains" [for more "confidential" messages]
> You make mail routing more complex and you introduce the need for late
> routing...
> And what do you do if the sending server doesn't speak ESTARTTLS?
> Behaving like a normal mail relay so that ESTARTTLS doesn't really
> help because you still have to implement something which you tried to
> avoid by introducing ESTARTTLS? Relay the connection to a "default"
> backend which in turn rejects the mails to half of the list of
> recipients as stated above?
AFAIR most messages contains one recipient anyway [your mileage may vary].
--
[pl>en Andrew] Andrzej Adam Filip : an...@onet.eu : Andrze...@gmail.com
"He did decide, though, that with more time and a great deal of mental
effort, he could probably turn the activity into an acceptable perversion."
-- Mick Farren, "When Gravity Fails"