Re: [TLS] Rizzo claims implementation attach, should be interesting

Martin Rex <> Tue, 20 September 2011 23:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D88A21F8BF0 for <>; Tue, 20 Sep 2011 16:12:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.046
X-Spam-Status: No, score=-10.046 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tgndKTTaMtIU for <>; Tue, 20 Sep 2011 16:12:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7123C21F8BE8 for <>; Tue, 20 Sep 2011 16:12:14 -0700 (PDT)
Received: from by (26) with ESMTP id p8KNES2q026545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2011 01:14:33 +0200 (MEST)
From: Martin Rex <>
Message-Id: <>
To: (Geoffrey Keating)
Date: Wed, 21 Sep 2011 01:14:27 +0200 (MEST)
In-Reply-To: <m2boueetaj.fsf@localhost.localdomain> from "Geoffrey Keating" at Sep 20, 11 03:35:32 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Sep 2011 23:12:15 -0000

Geoffrey Keating wrote:
> Martin Rex <> writes:
> > SSL was NEVER designed with a promise that you could multiplex
> > data from an evil attack with data from a victim over the very same
> > SSL connection and be secure against adaptive chose plaintext
> > attacks trying to recover data from the victim.
> This would imply that you should not use SSL for downloading e-mail
> using POP or IMAP, because that's multiplexing evil data (mail sent to
> you by the attacker) with trusted data (credentials and non-evil
> mail).
You are quite correct in recognizing that you might be helping
the attacker in a known-plaintext or chosen-plaintext attack (and when
you have an automatically polling IMAP client, maybe even an adaptive
chosen-plaintext attack).  So it would be sensible to limit the number
of guesses for the attacker, and to not re-use the same crypto keys
on subsequent accesses to the same IMAP server (TLS does the latter for
you when you create a new TLS connection state for each subsequent access,
i.e. TLS session resume or full handshake, both will do).