Re: Servers that just want to have TLS

I think we're looking at this question from different points of view.

As far as I'm concerned, if you say "apps", I mean any application.

HTML viewers (a/k/a browsers) are a subset of that.

SMTP servers are a subset of that.

If I build my own custom application I don't think I have to do negotiation.

If I build an application which claims to be what is generally referred to
as a standard SMTP server, then I should act like "an SMTP server" and I
agree with what you're saying.


At 08:42 AM 5/8/97 -0700, Paul E. Hoffman wrote:
>At 6:48 AM -0700 5/8/97, Rodney Thayer wrote:
>>What to do if a server JUST wants to talk TLS....
>>
>>I was thinking that one valid implementation path would be to simply always
>>use the TLS code.  So, if someone tried to talk to you in the clear, you'd
>>fail negotiation.  End of story.  Just like if you telnet to
>>www.openmarket.com port 443 (a/k/a <https://www.openmarket.com>) with a
>>generic Telnet client.
>
>So in the SMTP case, you are saying:
>
>S: <waits for connection on TCP port 25>
>C: <opens connection>
>C & S: <start TLS session>
>C & S: <check result of negotiation>
>S: 220 mail.imc.org SMTP service ready
>
>I tend think this is a bad idea on any well-known port for which a client
>might expect a non-TLS session. In the case of a non-TLS client, it would
>start getting a stream of gibberish that it could not deal with at all. A
>well-crafted SMTP client should do something like "The first thing it said
>to me wasn't 220, so I'll just leave", but I'm not sure that many will do
>this if handed a binary stream from the server.
>
>In this case, maybe the first thing out of the server's mouth should be
>something like "287 Give a STARTTLS command before I talk to you at all".
>
>And, I still want a general model for application protocols where the
>client talks first.
>
>--Paul E. Hoffman, Director
>--Internet Mail Consortium
>
>
>
>