Re: STARTTLS & EHLO: Errata text?

Tony Hansen <tony@att.com> Thu, 29 January 2009 17:04 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 n0TH4qIW029306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 10:04:52 -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 n0TH4q99029305; Thu, 29 Jan 2009 10:04:52 -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 mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TH4pnI029297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-smtp@imc.org>; Thu, 29 Jan 2009 10:04:52 -0700 (MST) (envelope-from tony@att.com)
X-VirusChecked: Checked
X-Env-Sender: tony@att.com
X-Msg-Ref: server-12.tower-167.messagelabs.com!1233248690!20014637!1
X-StarScan-Version: 6.0.0; banners=-,-,-
X-Originating-IP: [144.160.128.141]
Received: (qmail 5687 invoked from network); 29 Jan 2009 17:04:51 -0000
Received: from sbcsmtp9.sbc.com (HELO flph161.enaf.ffdc.sbc.com) (144.160.128.141) by server-12.tower-167.messagelabs.com with AES256-SHA encrypted SMTP; 29 Jan 2009 17:04:51 -0000
Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph161.enaf.ffdc.sbc.com (8.14.3/8.14.3) with ESMTP id n0TH4oZC020621 for <ietf-smtp@imc.org>; Thu, 29 Jan 2009 09:04:50 -0800
Received: from klph001.kcdc.att.com (klph001.kcdc.att.com [135.188.3.11]) by flph161.enaf.ffdc.sbc.com (8.14.3/8.14.3) with ESMTP id n0TH4k4u020540 for <ietf-smtp@imc.org>; Thu, 29 Jan 2009 09:04:46 -0800
Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id n0TH4jgY028135 for <ietf-smtp@imc.org>; Thu, 29 Jan 2009 11:04:45 -0600
Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id n0TH4hP1028118 for <ietf-smtp@imc.org>; Thu, 29 Jan 2009 11:04:43 -0600
Received: from [135.91.110.250] (ds135-91-110-250.dhcps.ugn.att.com[135.91.110.250](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20090129170443gw1000u61ve> (Authid: tony); Thu, 29 Jan 2009 17:04:43 +0000
Message-ID: <4981E1AB.9000002@att.com>
Date: Thu, 29 Jan 2009 12:04:43 -0500
From: Tony Hansen <tony@att.com>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: 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>
In-Reply-To: <37F39FF37390694B69567838@PST.JCK.COM>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
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>

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.

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

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.

Reason:
   Since the state is reset to that of a connection having just been
   opened, the requirement from RFC 5321 applies:

	In any event, a client MUST issue HELO or EHLO before starting a
	mail transaction.

   The previous text implied that a client can get by without sending
   one or the either.

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.


Now for the $64k questions:

1) Is there consensus behind this viewpoint?

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

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

	Tony Hansen
	tony@att.com

John C Klensin wrote:
> 
> 
> --On Thursday, January 29, 2009 10:09 -0500 Tony Hansen
> <tony@att.com> wrote:
> 
>> If this is the interpretation that we gain consensus on, that
>> it means "start over from scratch", it might as well also say
>> that it
>>
>> 	SHOULD only be executed immediately after the initial EHLO.
>>
>> The only possible exceptions to this rule would be for verbs
>> that don't affect the state machine, such as VRFY, EXPN, HELP,
>> NOOP.
> 
> RSET is also harmless immediately after EHLO.  Changing the
> state from "session open (EHLO issued), no mail transaction
> state" to "session open (EHLO issued), no mail transaction
> state" is a no-op.  And the first paragraph of 4.1.1.5 of 5321
> says that.
> 
> Out of context, I'm not sure exactly what you are suggesting
> above, but I believe that it would mean:
> 
>     S: 220 ...
>     C: EHLO ...
>     S: 250-...
>     S: 250-STARTTLS
>     S: 250-...
>     S: 250 OK
>     C: STARTTLS  ...
>     (TLS session starts)
>     and the next command must be either EHLO
>     or as many instances of any of VRFY, 
>       EXPN, HELP, NOOP, RSET as desired, followed by EHLO
> 
> Also, the "what the server MUST (or SHOULD) discard and the
> client MUST (or SHOULD) not depend on" sentences and example
> might reasonably be modified to explicitly include any
> information gained from VRFY or EXPN issued between the 220
> greeting and the initial EHLO.  While one might not trust VRFY
> or EXPN queries or results issued under TLS either, it would be
> pointless and silly to send them before the initial EHLO if one
> knew that one was going to issue STARTTLS if the server
> permitted it.   Indeed the only reason for doing so would be if
> one intended to make a decision about whether to continue with a
> mail transaction at all based on the results of VRFY or EXPN...
> and that would be very rare today except in special
> circumstances.
> 
>       john
>