Re: STARTTLS & EHLO: Errata text?

Hector Santos <hsantos@santronics.com> Thu, 29 January 2009 20:03 UTC

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TK3Ebi038169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 13:03:14 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0TK3E9X038168; Thu, 29 Jan 2009 13:03:14 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f
Received: from winserver.com (ntbbs.santronics.com [208.247.131.9]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TK3DIV038162 for <ietf-smtp@imc.org>; Thu, 29 Jan 2009 13:03:13 -0700 (MST) (envelope-from hsantos@santronics.com)
Received: by winserver.com (Wildcat! SMTP Router v6.3.452.5) for ietf-smtp@imc.org; Thu, 29 Jan 2009 15:03:49 -0500
Received: from hdev1 ([65.10.45.22]) by winserver.com (Wildcat! SMTP v6.3.452.5) with ESMTP id 2745251406; Thu, 29 Jan 2009 15:03:48 -0500
Message-ID: <49820B76.2000302@santronics.com>
Date: Thu, 29 Jan 2009 15:03:02 -0500
From: Hector Santos <hsantos@santronics.com>
Organization: Santronics Software, Inc.
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Tony Hansen <tony@att.com>
CC: ietf-smtp@imc.org
Subject: Re: STARTTLS & EHLO: Errata text?
References: <497DE492.4080506@pscs.co.uk> <497DED29.70402@att.com> <497ED420.30708@pscs.co.uk> <alpine.LSU.2.00.0901271403220.4546@hermes-2.csi.cam.ac.uk> <497F86CB.60904@att.com> <alpine.LSU.2.00.0901281434440.4546@hermes-2.csi.cam.ac.uk> <498088B8.9040404@pscs.co.uk> <alpine.LSU.2.00.0901291310080.4546@hermes-2.csi.cam.ac.uk> <4981C0D5.1010401@pscs.co.uk> <4981C6BD.2040900@att.com> <37F39FF37390694B69567838@PST.JCK.COM> <4981E1AB.9000002@att.com>
In-Reply-To: <4981E1AB.9000002@att.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-smtp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=unsubscribe>

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