ietf-smtp
[Top] [All Lists]

Re: STARTTLS & EHLO: Errata text?

2009-01-29 15:21:50

Tony Hansen wrote:
If we were to write an Errata against RFC 3207, I'd suggest text such as
the following (in Errata format):

Section:
   4.2 Result of the STARTTLS Command

Old text:
   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.

New text:
   The server MUST discard any knowledge obtained from the client that
   was not obtained from the TLS negotiation itself. The server state
   is otherwise as if the connection had just been opened.

But it isn't because its in an higher secured state. I took a look at our server and we have this:

BOOL TSMTPServer::STARTTLS(char *args)
{
   // possible replies from RFC 3207
   //   220 Ready to start TLS
   //   501 Syntax error (no parameters allowed)
   //   454 TLS not available due to temporary reason

    if (TLSStarted) {
        Send("501 TLS already negotiated!\r\n");
        return TRUE;
    }
    ...
    ...
}

I can only suggest that our engineers added it for a reason. Not having an explicit "already in TLS state" reply code, 501 was used.

My suggestion is to add a new reply code tells the client if its already in a secured state or not.

Reason:
   The example is misleading and has lead some people to think that
   knowledge of an EHLO having been sent previously should be
   remembered.


I always thought the key reason is that server features may change depending on the secured or non-secured SMTP state.

Our own server does not enforce the EHLO/HELO reissuing. If you think about it, it doesn't make sense to resend it given the fact that the CLIENT DOMAIN information can not change. It might want to use a different client domain but it MUST still be reflected of the sender machine regardless.

Our client does send it thought, mainly because that is what most servers expect.

Section:
   4.2 Result of the STARTTLS Command

Old text:
   The client SHOULD send an EHLO command as the
   first command after a successful TLS negotiation.

New text:
   The client MUST send either an EHLO command or a HELO command as the
   first command after a successful TLS negotiation.

I would not encourage a downgrade from EHLO to HELO potential. The client started in EHLO, it should probably remain in an extended state.

 > Section:
   4. The STARTTLS Command

Old text:
   The format for the STARTTLS command is:

   STARTTLS

   with no parameters.

New text:
   The format for the STARTTLS command is:

   STARTTLS

   with no parameters.

   Because the server state machine is reset to an initial connection
   state after negotiating TLS, and any modifications to the server
   state will be lost, the client SHOULD NOT issue any MAIL
   FROM or RCPT TO commands prior to using the STARTTLS command.


This text is confusing (to me). I think the common usage of "server state will be lost" is not quite right simply because the secured state of the SMTP session is not lost.

Now for the $64k questions:

1) Is there consensus behind this viewpoint?

I don't agree with the proposes errata text as is.

2) If so, does the text above cover the ground?

I don't think so.

3) If so, who wants to file the Errata?

Paul should <g> He's the one using a client that doesn't send the EHLO. :-)

--
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

<Prev in Thread] Current Thread [Next in Thread>