Re: STARTTLS & EHLO: Errata text?

Hector Santos <hsantos@santronics.com> Sun, 01 February 2009 21:52 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 n11LqLDt007555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2009 14:52:21 -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 n11LqLZK007554; Sun, 1 Feb 2009 14:52:21 -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 (secure.winserver.com [208.247.131.9]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n11LqKqp007547 for <ietf-smtp@imc.org>; Sun, 1 Feb 2009 14:52:20 -0700 (MST) (envelope-from hsantos@santronics.com)
Received: by winserver.com (Wildcat! SMTP Router v6.3.452.5) for ietf-smtp@imc.org; Sun, 01 Feb 2009 16:52:57 -0500
Received: from hdev1 ([65.10.45.22]) by winserver.com (Wildcat! SMTP v6.3.452.5) with ESMTP id 3010999406; Sun, 01 Feb 2009 16:52:56 -0500
Message-ID: <49861982.60809@santronics.com>
Date: Sun, 01 Feb 2009 16:52: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 Finch <dot@dotat.at>
CC: John C Klensin <john+smtp@jck.com>, 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> <alpine.LSU.2.00.0901301832470.4795@hermes-2.csi.cam.ac.uk> <49835DE2.3030403@santronics.com> <alpine.LSU.2.00.0901312021190.14750@hermes-2.csi.cam.ac.uk> <4984C49C.5030401@santronics.com> <alpine.LSU.2.00.0902011706190.10756@hermes-2.csi.cam.ac.uk> <AE5689449BAC89829F0DD5E7@PST.JCK.COM> <4985FCD8.8040305@santronics.com> <alpine.LSU.2.00.0902012028320.10756@hermes-2.csi.cam.ac.uk>
In-Reply-To: <alpine.LSU.2.00.0902012028320.10756@hermes-2.csi.cam.ac.uk>
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 Finch wrote:
> On Sun, 1 Feb 2009, Hector Santos wrote:
>> I was thinking of 3207 with text similar to:
>>
>>     The secured SMTP client MUST resend the EHLO command and the
>>     secured SMTP server MUST be prepared to issue an 503
>>     for any out of sequence commands by legacy 3207 clients.
> 
> What's wrong with the text I suggested?
> 
>    Upon completion of the TLS handshake, the SMTP protocol is reset to
>    the initial state (the state in SMTP after a server issues a 220
>    service ready greeting).  The requirement in [RFC5321] that "a client
>    MUST issue HELO or EHLO before starting a mail transaction" also
>    applies to this fresh state.

IMO, it is lacking insights regarding legacy servers and clients 
potential behavior.  See below.

>> On the other hand, if 3207 is altered to enforce a MUST, then we need to
>> change our server and in that vain, I reject this 3207 change to a MUST.
> 
> This isn't a change to 3207, it's a clarification. This is a requirement
> on the client so it isn't strictly necessary for servers to enforce it
> (robustness principle and all that). 

I like to see "Protocol Consistency."  What is expected of the client, 
helps define what is expected of the server, and vice versa.

> Does your server enforce the
> requirement for plaintext connections?

Not sure how that applies.  But specifically, its all local policy.

Ok, lets back track and summarize some of this.

Because of the 3207 conflictive semantics, we have come to learn there 
are three forms or potential outcomes for behavior:

1) A secured client who literally took the term 3207 SHOULD as an
    option and did not expect the secured server to barf when
    the secured client did not issue EHLO/EHLO and went straight
    to MAIL FROM.

2) A secured server who issued the wrong reply code (550), but
    did include correct human response text to an out of
    sequence command.  This is probably why the OP was able to
    find the cause, the human text, but an automated client seeing
    550 would think it was a normal server defined return path
    address rejection, e.g., maybe SPF? CBV?

3) Due to the 7 year old current wordings in the text, possible
    servers, including ours, who will not enforce EHLO/HELO
    after TLS is established.  We might be the only one, but
    who knows without testing all the servers there.

Because of these potentials, I don't think you can generally clarify 
and produce generic documents and "cross your fingers" that all 
documents will fit and work together to fix the above potentials.

You will need more clarification that will provide specifics to 
address situations where they might be compatibility issues.

You covered the general statement.  A specific statement is required 
to remind legacy servers and clients that out of sequence issues are 
possible and appropriate (code) change actions are necessary.

For example, adding to your text:

    Upon completion of the TLS handshake, the SMTP protocol is reset to
    the initial state (the state in SMTP after a server issues a 220
    service ready greeting).  The requirement in [RFC5321] that "a
    client MUST issue HELO or EHLO before starting a mail transaction"
    also applies to this fresh state.  Note: Keep in mind that legacy
    clients may exist which do not re-issue EHLO/HELO. As required by
    SMTP, the server [SHOULD|]MUST issue an out of sequence
    negative response. i.e. 503 versus 55x.

If you are not specific, then it is quite possible an "security 
argument" can be made such as:

    A secured server expects no "errors" in commands sequence and
    thus will abort (55x) all unexpected commands during a
    secured session.

If you deem this is an appropriate possibility, then that should 
probably be stated as well.  '

Simply looking for client/server protocol consistency.

-- 
Sincerely

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