IETF Logo Mail Archive

Re: [TLS] AES and SSLv3 (was Re: Unfortunate current practices for HTTP

Wan-Teh Chang <wtc@google.com> Wed, 19 January 2011 21:56 UTC

Return-Path: <wtc@google.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 4F41D3A71D6 for <tls@core3.amsl.com>; Wed, 19 Jan 2011 13:56:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level:
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 UetM-mYs9dZr for <tls@core3.amsl.com>; Wed, 19 Jan 2011 13:56:42 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 346A03A71C5 for <tls@ietf.org>; Wed, 19 Jan 2011 13:56:41 -0800 (PST)
Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id p0JLxL2x021630 for <tls@ietf.org>; Wed, 19 Jan 2011 13:59:22 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1295474362; bh=CpidGTNPu6YC2RWBQEXAV5/V6m4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=kSN+CE/M9dwuZmP0qp/HCTWPo7lBcLyA6VxQJGslHX+qQeeJpROXHnKLimlLf3axN Qw/tqKSAHBh1fJIquZw2g==
Received: from gyf1 (gyf1.prod.google.com [10.243.50.65]) by wpaz1.hot.corp.google.com with ESMTP id p0JLxKHM030726 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <tls@ietf.org>; Wed, 19 Jan 2011 13:59:20 -0800
Received: by gyf1 with SMTP id 1so675991gyf.7 for <tls@ietf.org>; Wed, 19 Jan 2011 13:59:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=s/fG1qXMB85YnPPJqmPb23VfZ+MVkbnwYntVajsesho=; b=tMzO1NpDYIVaZfkdZGRVZxwYZm0x34rCeR4yAKO9jZVbTbNn67MCoIpBD1Yu1us+9o KkAOvIA4f8ZBZ+TDC8Lg==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=eU0AcKTUuDJiIGeO9eT6E5BxgpgUQfHHfzlN8QkzMMqFUo4YTPSmV7j6oFXkg7wAMR P54DAMwvsJBKJ0YRpI2Q==
MIME-Version: 1.0
Received: by 10.216.22.131 with SMTP id t3mr1220344wet.2.1295474359747; Wed, 19 Jan 2011 13:59:19 -0800 (PST)
Received: by 10.216.6.81 with HTTP; Wed, 19 Jan 2011 13:59:19 -0800 (PST)
In-Reply-To: <4D374855.20207@extendedsubset.com>
References: <201101191907.p0JJ723Z018557@fs4113.wdf.sap.corp> <4D374855.20207@extendedsubset.com>
Date: Wed, 19 Jan 2011 13:59:19 -0800
Message-ID: <AANLkTim8dQbSyX_25N1fz7PogpWPh+5kkhCwMs621qZ+@mail.gmail.com>
From: Wan-Teh Chang <wtc@google.com>
To: Marsh Ray <marsh@extendedsubset.com>
Content-Type: text/plain; charset="ISO-8859-1"
X-System-Of-Record: true
Cc: tls@ietf.org
Subject: Re: [TLS] AES and SSLv3 (was Re: Unfortunate current practices for HTTP
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, 19 Jan 2011 21:56:43 -0000

On Wed, Jan 19, 2011 at 12:23 PM, Marsh Ray <marsh@extendedsubset.com> wrote:
>
> The problem is that the client is in some sort of "fall back to SSLv3"
> heuristic mode. The reason clients are forced to do that is the occasional
> presence of poorly interoperating servers.
>
> The root cause is thus the poorly interoperating servers.

For the SSLv3 AES cipher suite problem, it is the client (in SChannel)
that is poorly interoperating.

Another problem is how an RFC of a TLS feature references TLS.  It
usually references the latest version of TLS only.  For example, RFC
5746 (the TLS renegotiation indication extension) references the TLS
1.2 RFC (RFC 5246) only.  An implementor could be misled into thinking
the TLS feature is only applicable to that version of TLS.

Wan-Teh

v2.23.0 | Report a Bug | By Email