Re: [TLS] Prohibiting SSL 3.0

Geoffrey Keating <geoffk@geoffk.org> Fri, 31 October 2014 03:12 UTC

Return-Path: <geoffk@geoffk.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4CE1A8A9A for <tls@ietfa.amsl.com>; Thu, 30 Oct 2014 20:12:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.003
X-Spam-Level:
X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UK2Uid93dPtx for <tls@ietfa.amsl.com>; Thu, 30 Oct 2014 20:12:11 -0700 (PDT)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FB3C1A8A83 for <tls@ietf.org>; Thu, 30 Oct 2014 20:12:10 -0700 (PDT)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id E43DD33D067; Fri, 31 Oct 2014 03:12:09 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: mrex@sap.com
References: <CACsn0cn0CFxt-tnnkTr8OF41uLxx8SGTNM8yK90SUiJDPgcN_Q@mail.gmail.com> <20141031023139.CBB741AF6E@ld9781.wdf.sap.corp>
From: Geoffrey Keating <geoffk@geoffk.org>
Date: Thu, 30 Oct 2014 20:12:09 -0700
In-Reply-To: <20141031023139.CBB741AF6E@ld9781.wdf.sap.corp>
Message-ID: <m261f1rkza.fsf@localhost.localdomain>
Lines: 24
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2BWkS7LRpDJZj21NT-qo6sPN9Yk
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Oct 2014 03:12:14 -0000

mrex@sap.com (Martin Rex) writes:

> To me, the second sentence of Appendix F:
> 
>    This document makes several traditional assumptions, including that
>    attackers have substantial computational resources and cannot obtain
>    secret information from sources outside the protocol.
> 
> says pretty clearly that TLS is not designed to provide protection from
> an attacker who can gain almost full control over one of the communication
> endpoints and can exploit this to get data of his own liking and data
> that the attacker would like to discover mixed according to the attackers
> choice with attacker supplied data and sent over the very same TLS-protected
> communication channel.

Surely one traditional assumption is that an attacker can create
messages of his own and get them inserted into the stream?  Including
the possibility of intentionally causing a lot of traffic?

I'm fairly sure that one of the tactics used in WW2 to get 'cribs' to
break ENIGMA was to intentionally do things that would cause the enemy
to send a message with known contents, like sending an apparently
valuable target within vision of a U-boat that could not attack it, in
the hope the U-boat would report.