IETF Logo Mail Archive

Re: STARTTLS & EHLO: Errata text?

Russ Allbery <rra@stanford.edu> Fri, 30 January 2009 16:49 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 n0UGn2Ni092760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 09:49:02 -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 n0UGn2PF092759; Fri, 30 Jan 2009 09:49:02 -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 n0UGmpTq092751 for <ietf-smtp@imc.org>; Fri, 30 Jan 2009 09:49:02 -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 7BA1C1709AD for <ietf-smtp@imc.org>; Fri, 30 Jan 2009 08:48:51 -0800 (PST)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) by smtp1.stanford.edu (Postfix) with ESMTP id 23A98170772 for <ietf-smtp@imc.org>; Fri, 30 Jan 2009 08:48:50 -0800 (PST)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 641BDE84C8; Fri, 30 Jan 2009 08:48:50 -0800 (PST)
To: ietf-smtp@imc.org
Subject: Re: STARTTLS & EHLO: Errata text?
In-Reply-To: <498277A6.2070007@santronics.com> (Hector Santos's message of "Thu\, 29 Jan 2009 22\:44\:38 -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> <87ab99le53.fsf@windlord.stanford.edu> <498277A6.2070007@santronics.com>
From: Russ Allbery <rra@stanford.edu>
Organization: The Eyrie
Date: Fri, 30 Jan 2009 08:48:50 -0800
Message-ID: <87bptokadp.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:
> Russ Allbery wrote:

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

> Maybe I don't see it.  If the client is being fooled, one would think
> that it would be to relax the client, not push it into a more secured
> mode.

Right, that's what a down-negotiation attack is.  The attacker would, for
instance, advertise that the server supported authentication but only list
weak authentication protocols.  If the client then proceeded on the basis
of the extension list from the attacker, it would use a weaker (and
possibly vulnerable) authentication protocol instead of a stronger one
that the server actually supports.

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

v2.23.0 | Report a Bug | By Email