Re: STARTTLS & EHLO: Errata text?

Tony Finch <dot@dotat.at> Fri, 30 January 2009 19:05 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 n0UJ5KWp000159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 12:05:20 -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 n0UJ5Kkh000158; Fri, 30 Jan 2009 12:05:20 -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 ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UJ58j9000135 for <ietf-smtp@imc.org>; Fri, 30 Jan 2009 12:05:19 -0700 (MST) (envelope-from fanf2@hermes.cam.ac.uk)
X-Cam-AntiVirus: no malware found
X-Cam-SpamDetails: not scanned
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:52111) by ppsw-6.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1LSyfr-0001O3-Lf (Exim 4.70) (return-path <fanf2@hermes.cam.ac.uk>); Fri, 30 Jan 2009 19:05:07 +0000
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1LSyfr-0004Zf-Ma (Exim 4.67) (return-path <fanf2@hermes.cam.ac.uk>); Fri, 30 Jan 2009 19:05:07 +0000
Date: Fri, 30 Jan 2009 19:05:07 +0000
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: Tony Hansen <tony@att.com>
cc: ietf-smtp@imc.org
Subject: Re: STARTTLS & EHLO: Errata text?
In-Reply-To: <4981E1AB.9000002@att.com>
Message-ID: <alpine.LSU.2.00.0901301832470.4795@hermes-2.csi.cam.ac.uk>
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>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
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>

On Thu, 29 Jan 2009, Tony Hansen wrote:
>
> 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.

I prefer Alexey's suggested "MUST NOT trust" text.

Note that my comment about AUTH information applies to the client as well
as the server.

Also note that AUTH means this trust issue applies to more than just SMTP
commands, arguments, and replies - it applies to SASL exchanges as well.

> 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.

That's incorrect. It's OK to QUIT at this point, for example. Rather than
paraphrasing 2821/5321, perhaps it would be better to quote verbatim.

I suggest that this paragraph should read:

   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.

   The server MUST NOT trust any knowledge obtained from the client before
   the TLS negotiation itself.  The client MUST NOT trust any knowledge
   obtained from the server before the TLS negotiation itself.  This
   includes all commands, arguments, replies, and extended exchanges
   (though in typical use there is little more than the client's EHLO
   command and the server's reply).

>    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.

I think this is unnecessary. I doubt anyone has been confused enough to
implement software that would violate this requirement. I only mentioned
it for sake of argument.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.