Re: [TLS] Comments on draft-rescorla-tls-renegotiation-01.txt

Martin Rex <mrex@sap.com> Wed, 25 November 2009 00:34 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3950E3A6857 for <tls@core3.amsl.com>; Tue, 24 Nov 2009 16:34:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.154
X-Spam-Level:
X-Spam-Status: No, score=-6.154 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EE1bZKpAPRcF for <tls@core3.amsl.com>; Tue, 24 Nov 2009 16:34:28 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 2A1AB3A67BD for <tls@ietf.org>; Tue, 24 Nov 2009 16:34:27 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAP0YLFg014903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 01:34:21 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911250034.nAP0YLIQ014338@fs4113.wdf.sap.corp>
To: aerowolf@gmail.com
Date: Wed, 25 Nov 2009 01:34:21 +0100
In-Reply-To: <6b9359640911241522q6e31633bp3fd48bc2922c0cdf@mail.gmail.com> from "Kyle Hamilton" at Nov 24, 9 03:22:57 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Comments on draft-rescorla-tls-renegotiation-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
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/listinfo/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: Wed, 25 Nov 2009 00:34:29 -0000

Kyle Hamilton wrote:
> 
> 4.3.1:
> Clients which choose to fall back to an extensionless mode of
>    operation MUST include the magic cipher suite [TBD] in any such
>    handshake.  Servers MUST reject any ClientHello which uses this
>    cipher suite but does not include RI with a fatal "handshake_failure"
>    alert.  Because servers ordinarily ignore unknown cipher suites, this
>    cipher suite can be added safely on any handshake, thus allowing
>    detection and prevention of the MITM attack described above.
> 
> This is absolutely essential.  TLS extensions exist, but SSL 3 is
> still commonly used.  There's no reason why SSL 3 shouldn't benefit
> from anything that happens after-the-fact, even though it was never an
> actual IETF protocol.
> 
> The only issue I see is... we've got an issue in signalling back to
> the client that it knows how to do the updated handshake.  Would a
> slightly modified HelloRequest do it?

Aha.  Someone noticed that the S->C signaling is missing.

I suggest using a bit in ServerHello.server_version.

So far, the magic cipher suite idea in TLS extension RI
is a "solution" to the downgrade vulnerability
from the automatic reconnect fallback in TLS clients.

So as far as SSLv3 support is concern, TLS extension RI
is still firmly determined to exterminate SSLv3  and with the
magic cipher suite, it'll kill conservative TLS clients along with it.

-Martin