IETF Logo Mail Archive

Re: STARTTLS & EHLO: Errata text?

Russ Allbery <rra@stanford.edu> Fri, 30 January 2009 02:30 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 n0U2UDHj052619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 19:30:13 -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 n0U2UDqW052618; Thu, 29 Jan 2009 19:30:13 -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 smtp1.stanford.edu (smtp1.Stanford.EDU [171.67.219.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0U2U27a052607 for <ietf-smtp@imc.org>; Thu, 29 Jan 2009 19:30:12 -0700 (MST) (envelope-from eagle@windlord.stanford.edu)
Received: from smtp1.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0D31717097D for <ietf-smtp@imc.org>; Thu, 29 Jan 2009 18:30:02 -0800 (PST)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) by smtp1.stanford.edu (Postfix) with ESMTP id 3AB1217091F for <ietf-smtp@imc.org>; Thu, 29 Jan 2009 18:30:00 -0800 (PST)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id E0ACAE813A; Thu, 29 Jan 2009 18:30:00 -0800 (PST)
To: ietf-smtp@imc.org
Subject: Re: STARTTLS & EHLO: Errata text?
In-Reply-To: <49825E78.7080303@santronics.com> (Hector Santos's message of "Thu\, 29 Jan 2009 20\:57\:12 -0500")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
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> <6.2.5.6.2.20090129094120.02f234a0@resistor.net> <01N4VB00O5UQ00007A@mauve.mrochek.com> <49823FDC.4000006@isode.com> <49825E78.7080303@santronics.com>
From: Russ Allbery <rra@stanford.edu>
Organization: The Eyrie
Date: Thu, 29 Jan 2009 18:30:00 -0800
Message-ID: <87ab99le53.fsf@windlord.stanford.edu>
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>

Hector Santos <hsantos@santronics.com> writes:
> Alexey Melnikov wrote:

>> I would like suggest an alternative: how about saying
>>
>> The server MUST NOT trust any information obtained from the client,
>> such as command verbs and their arguments, prior to the TLS
>> negotiation.  The client MUST NOT trust any information obtained from
>> the server, such as the list of SMTP service extensions, prior to the
>> TLS negotiation.
>>
>> This avoid the whole issue of what the client/server must and must not
>> remember.
>
> I don't follow the client MUST NOT trust statement.  Is it not suppose to
> believe what the server presents for extensions?
>
>    S:  We supports STARTTLS, AUTH CRAM-MD5
>    C:  Liar!! No you don't, I don't believe you.
>
> ??

It's not supposed to trust what the server said before STARTTLS, since
everything sent before STARTTLS may have been provided by a
man-in-the-middle attacker.  It's stronger than just not assuming that the
same extensions apply.  Even if extensions happen to still be available,
trusting the extension return before STARTTLS can permit an attacker to
launch a down-negotiation attack, for example.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

v2.23.0 | Report a Bug | By Email