Re: Revising RFC 2487

["Scott Roberts (Platinum)" <scotro@xxxxxxxxxxxxx>]

-----Original Message-----
From: Paul Hoffman / IMC <phoffman@xxxxxxx>
To: Chris Newman <Chris.Newman@xxxxxxxxxxxx>

>At 12:56 PM 4/14/99 -0700, Chris Newman wrote:
>>On Sun, 11 Apr 1999, Paul Hoffman / IMC wrote:
>>> (1) Advertise only if ready
>>>
>>> Change the text in section 4 to read:
>>>
>>>    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.
>>
>>I'd also add something along the lines of:
>>
>>    The SMTP server SHOULD NOT advertise the STARTTLS keyword unless at
>>    least one TLS cipher suite is enabled and any additional
>>    configuration necessary to successfully negotiate that cipher suite
>>    (such as a certificate) is present.
>
>This sounds better to me than option (2). Do other folks have opinions? I'd
>like to turn in the first draft this week to get the ball rolling.
>
>--Paul Hoffman, Director
>--Internet Mail Consortium

>
My opinions that need to be ironed out:

1. An implementation should not, by default, be configured for STARTTLS
unless it is 100% ready to perform a successful TLS negotiations.
            This should be left up to the implementation of the server and
not outlined in an RFC.

2. The server MUST always advertise STARTTLS if the server is configured for
STARTTLS regardless if the encryption is currently working.

3. If the server FAILS a TLS negotiation it should continue to advertise
STARTTLS because, to not advertise it, will allow bogus
man-in-the-middle-attacks (Section 7). This could alarm clients that are
tracking which servers are advertising the STARTTLS keyword and which
servers are not for such security attacks . Continuous TLS negotiation
failures at the server should alarm the SERVER but this would be handled by
the implementation of the server and not in the RFC.

4. If a TLS negotiation fails the server MUST return a 454 error code to the
client which will allow it to understand that:
    a. The server was capable of attempting TLS Negotiations
    b. That the TLS negotiation failed and a reply code was returned to the
client stating a temp or fatal error.
    c. a + b will allow the client to know whether or not  it should attempt
to re-send the email or reroute/NDR the message


I support #1,#2,#3,#4 but I feel that the 455 reply code could be overdoing
it because I can get enough information from just failing in #4 but this is
left up to the client implementation. But if support for a 455 error code is
big I would easily go for it to make the client's life easier.

Scott