RE: Man In The Middle Attacks and STARTTLS

Bodo, your points are good. I would think that it is better to state that a
reasonable amount of time SHOULD pass before the message is returned to the
sender rather than stating a default time because of issues that might arise
in the future. 

We could add to section 5 stating:
	A client that receives a 454 reply code from a server that has
advertised the STARTTLS verb SHOULD attempt to retry the mail in a
reasonable amount of time or reroute it before returning it to the sender.
The amount of time before retrying the message and/or NDRing the message
should be left up to the implementation and is outside the scope of this
document. 



> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]
> Sent: Thursday, April 15, 1999 3:05 PM
> To: Paul Hoffman / IMC
> Cc: [email protected]
> Subject: Re: Man In The Middle Attacks and STARTTLS
> 
> 
> On Thu, Apr 15, 1999 at 12:02:19PM -0700, Paul Hoffman / IMC wrote:
> 
> > Greetings again. I thinking about the recent messages, I 
> realized that we 
> > have missed a major problem here, one that might not be 
> fixable at all.
> > [...]    we missed an attack that uses (b) and/or (c).
> > 1) The server says "250 STARTTLS". The attacker lets this go by.
> > 2) The client says "STARTTLS". The attacker changes the 
> command to "NOOP" 
> > or some other harmless command before the server sees it.
> > 3) The server replies to the NOOP. The attacker changes the 
> status reply to 
> > "454 TLS not available due to temporary reason" before the 
> client sees it.
> 
> > No one suspects anything.
> 
> Well, I certainly do :-), was my message of March 26 too vague?  See
> the first sentence of my reply:
> 
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> Date: Fri, 26 Mar 1999 19:43:07 +0100
> From: Bodo Moeller <[email protected]>
> To: Scott Roberts <[email protected]>
> Cc: [email protected], [email protected]
> Subject: Re: Interop problem with SMTP STARTTLS and Cisco PIX firewall
> Message-ID: <[email protected]>
> References: <002f01be77b0$28e49110$01731fac@scotthome>
> 
> On Fri, Mar 26, 1999 at 09:43:26AM -0800, Scott Roberts wrote:
> 
> > The RFC for STARTTLS has a section for dealing with the 
> middleman attack
> > where the client should keep track of each server's TLS and 
> remember the
> > last time it was advertised. If a server stops advertising 
> STARTTLS due to
> > an invalid certificate or invalid configuration it could 
> lead to false
> > security issues and alerts when the problem was just a bad 
> certificate that
> > caused it to stop advertising the STARTTLS during the EHLO.
> 
> The "454 TLS not available due to temporary reason" answer to STARTTLS
> could just as well indicate an MITM attack.  If the server is
> misconfigured, it is very unlikely that waiting after the 454 response
> will fix the problem (how often do people change their mail server's
> configuration?) -- similarly, an incorrect "RCPT TO:" typically will
> not generate "451 User does not yet exist" :-)
> 
> >     [...] The server will return a '454 TLS not available 
> due to temporary
> > reason' to any client that issues the STARTTLS command and 
> fails.  If we do
> > not advertise STARTTLS when there is ANY problem with the 
> certificate or
> > configuration than why have this error code?
> 
> "Temporary reasons" for unavailability of TLS could have several
> reasons: E.g., after a reboot the server needs a password to decrypt
> its key; or a decrypting smart card was just removed from the
> interface because a new one with a new key is to be inserted.
> A configuration mistake _might_ be a good reason, but only for limited
> time (namely, while someone is working on the configuration: E.g., an
> old certificate and key have just been deleted, but the new one is not
> yet installed), not for more than, say, one day at most.
> I think this proposal makes sense:
> 
> >> As I see it the real question is whether the mail can be 
> sent within a
> >> reasonable amount of time. If a server has had a working TLS
> >> configuration that doesn't work just now then it should advertise
> >> STARTTLS but if it has never been configured then it 
> shouldn't. Five
> >> days seems to be a common queue return time and so I 
> suggest that if a
> >> valid configuration has not existed in the last five days 
> then it can be
> >> deemed to have never existed.
> 
> This time-out should be configurable, but three days (one weekend) or
> five days are probably a reasonable default.
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> <<<<<<<<<<<<<<<
> 
> > I do not see a way around this problem. If no one comes up 
> with a solution, 
> > I'll change the security considerations of RFC 2487 to 
> discuss this. And, 
> > then, we can move forwards with the correct wording for 
> what to do when a 
> > server is not ready to do TLS.
>