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

Kyle Hamilton <aerowolf@gmail.com> Wed, 25 November 2009 18:20 UTC

Return-Path: <aerowolf@gmail.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 31D7D3A6983 for <tls@core3.amsl.com>; Wed, 25 Nov 2009 10:20:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.561
X-Spam-Level:
X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599]
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 fVZ65DGxDeAr for <tls@core3.amsl.com>; Wed, 25 Nov 2009 10:20:23 -0800 (PST)
Received: from mail-px0-f186.google.com (mail-px0-f186.google.com [209.85.216.186]) by core3.amsl.com (Postfix) with ESMTP id 79E383A67B1 for <tls@ietf.org>; Wed, 25 Nov 2009 10:20:19 -0800 (PST)
Received: by pxi16 with SMTP id 16so5653995pxi.29 for <tls@ietf.org>; Wed, 25 Nov 2009 10:20:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=g0u45bxatwOfY3USJm+zdalyNkan9oYBZ+5caN6Dlwg=; b=CSbdfC0wR0vwPwUCdZsjrbqP5RU0tzGhRJJQDN0YhDuLb6/tdS5E/mgc1nunGKFKBL 4pnp/cA0D7L37V/5JQvvup7CRV450kG0lsqfr53736dAepTV8X+Wu3yldbKQVI2q2ubz umucgpa8GAWZ0+Neb9IhbcLRuVhXL81iOfL1c=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ZiBg358J6NtBXXXXL7Mpr5biUj59moHBq3m+8It2ilwDUC5SFUB/BDc2sJdQBx+ttB 93Odi/6zSSg2l/4T5gHviALEj0EADfSpdHtNQSPkfW6QU7cI+R3T5enYikbMaMZldpZT vb9FZUwpOEZORk52vJJ1u7hf4LPbusj4GMG18=
MIME-Version: 1.0
Received: by 10.142.75.12 with SMTP id x12mr801951wfa.157.1259173210634; Wed, 25 Nov 2009 10:20:10 -0800 (PST)
In-Reply-To: <200911250034.nAP0YLIQ014338@fs4113.wdf.sap.corp>
References: <6b9359640911241522q6e31633bp3fd48bc2922c0cdf@mail.gmail.com> <200911250034.nAP0YLIQ014338@fs4113.wdf.sap.corp>
Date: Wed, 25 Nov 2009 10:20:10 -0800
Message-ID: <6b9359640911251020j469c9bb2i4cd12a759e7c5ca2@mail.gmail.com>
From: Kyle Hamilton <aerowolf@gmail.com>
To: mrex@sap.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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
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 18:20:24 -0000

On Tue, Nov 24, 2009 at 4:34 PM, Martin Rex <mrex@sap.com> wrote:
> 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.
>>
>> 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.

I don't think that many conforming clients are going to be okay with
that, since they're sending {0x03 0x04}, and you're having the server
send back {0x83 0x04} or {0x03 0x84}.

The spec of TLS 1.0 implies that the client SHOULD terminate the
connection if it receives back a higher major version number (or minor
version number) than it was expecting.  It is specified as "the lower
of the client-suggested protocol version, and the protocol version
supported by the server".  It would be very easy to (falsely, in this
case, but that doesn't matter) identify it as an MITM with a version
modification attack going on.

I think that conforming, unpatched TLS 1.0 implementations will
terminate connections if they see a major version of 131, or a minor
version of 132.

-Kyle H

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