Re: STARTTLS & EHLO

Hector Santos <hsantos@santronics.com> Thu, 29 January 2009 01:14 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 n0T1EaW4079211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2009 18:14:36 -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 n0T1EaR2079210; Wed, 28 Jan 2009 18:14:36 -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 (mail.santronics.com [208.247.131.9]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0T1EPlO079192 for <ietf-smtp@imc.org>; Wed, 28 Jan 2009 18:14:35 -0700 (MST) (envelope-from hsantos@santronics.com)
Received: by winserver.com (Wildcat! SMTP Router v6.3.452.5) for ietf-smtp@imc.org; Wed, 28 Jan 2009 20:15:03 -0500
Received: from hdev1 ([65.10.45.22]) by winserver.com (Wildcat! SMTP v6.3.452.5) with ESMTP id 2677525375; Wed, 28 Jan 2009 20:15:02 -0500
Message-ID: <498102EA.7050809@santronics.com>
Date: Wed, 28 Jan 2009 20:14:18 -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
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> <4980C684.2070300@santronics.com> <4980CF1D.4000303@att.com>
In-Reply-To: <4980CF1D.4000303@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>

HI Tony,

Yes, right, I acknowledge this question. My point is that the 
simplistic statement in 4.2

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

was not "considerate" of the other key points the documents makes 
about private vs public vs authentication levels it clearly made.

IOW, programmatically, the client should of interpret these points in 
the document and see this a MUST is the only logical option simply 
because of the other key points made about how the server status can 
change, especially when accessing a private smtp host (ie. SUBMIT server),

If the private submit server presented only STARTTLS then the client 
has no choice but to start with STARTTLS and when completely, only 
then the SERVER will present the AUTH schemes, then the client has no 
choice but to reissue the EHLO to find what methods are available.

The point is that there are some states the force the issue, 
programmatically.

-- 
Sincerely

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

Tony Hansen wrote:
> Hector, what started this was a client that doesn't use any other
> extended smtp features beyond STARTTLS. So once it had started up TLS,
> it had no use for the output of EHLO, and consequently it didn't bother
> sending either HELO or EHLO after the STARTTLS. This was fine until it
> ran into a server that demanded that EHLO be sent again. Leading to the
> questions on the table: 1) which interpretation of the spec is correct,
> and 2) what should be done once this is decided?
> 
> 	Tony Hansen
> 	tony@att.com
> 
> Hector Santos wrote:
>> My take on this:
>>
>> I think the client should be aware that most, if not all, servers expect
>> a 2nd pass of EHLO, but I also believe the client should not presume
>> server features would be the same under TLS and NON-TLS sessions.
>>
>> For example, the use case where the private or even public server allows
>> a stronger AUTH for non TLS sessions and allows weaker AUTH under TLS:
>>
>>    S: 220 blah blah blah
>>    C: EHLO client-domain.com
>>    S: 250-server-domain.com
>>    S: 250 AUTH CRAM-MD5 OTHER
>>    S: 250 STARTTLS
>>    C: MAIL FROM: <xxxxxxx>
>>    S: 530 Must issue a STARTTLS or AUTH command first
>>    ...
>>
>> Note: both RFC 2487 (TLS) and RFC 2554 (AUTH) use 530 for an enforcement
>> requirement. So here, if it client support CRAM or DIGEST it can
>> continue with AUTH CRAM-MD5 or AUTH OTHER. But if it does not support
>> these stronger AUTH, and does support TLS, it can continue with a STARTLS:
>>
>>    ...
>>    C: STARTTLS
>>    S: 220 Go ahead
>>    C & S: <TLS negotiation>
>>    C: MAIL FROM: <xxxxxxx>
>>    S: 530 AUTH command first
>>    C: EHLO client-domain.com
>>    S: 250-server-domain.com
>>    S: 250 AUTH LOGIN
>>    S: 250 AUTH-LOGIN
>>    S: AUTH LOGIN
>>    S: 235 Authentication successful.
>>
>> The point is, the client MUST be aware of this possibility and should
>> always (MUST) issue an EHLO after TLS is established.
>>
>> The idea of public vs private and level of authentication is discussed
>> in 2487 and this is where the 4.2 statement:
>>
>>    The client SHOULD send an EHLO command as the
>>    first command after a successful TLS negotiation.
>>
>> is "forgetful" of its other key points.  So it should of been something
>> like:
>>
>>    For a SMTP server that is privately referenced, the client
>>    MUST issue the EHLO command after a successful TLS negotiation
>>    to determine if there are any changes in AUTH methods, such
>>    as the strength of the authentication.
>>
>>    If the server is the publicly reference, the client SHOULD
>>    send an EHLO command as the first command after a successful
>>    TLS negotiation, however, it is highly recommended it reissues
>>    the EHLO in all cases.
>>
>>    The client SHOULD not degrade from EHLO to HELO.
>>
>> My take.
>>
> 
> 
>