Re: [TLS] Deprecating SSLv3

Stephen Checkoway <s@pahtak.org> Tue, 11 November 2014 22:40 UTC

Return-Path: <s@pahtak.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 0BE4F1A1B2B for <tls@ietfa.amsl.com>; Tue, 11 Nov 2014 14:40:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 Xf3mi8PbcsMC for <tls@ietfa.amsl.com>; Tue, 11 Nov 2014 14:40:33 -0800 (PST)
Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27B151A1A2A for <tls@ietf.org>; Tue, 11 Nov 2014 14:40:33 -0800 (PST)
Received: by mail-qa0-f54.google.com with SMTP id u7so7749248qaz.13 for <tls@ietf.org>; Tue, 11 Nov 2014 14:40:32 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=fEX2QeatzfuTawgD29HIUkyVovOKBKoKpDkjXFDjEXc=; b=lMaKCN5CEs+ttyzXwb5/hlein9rUlwEp9rkYf/zLBgLHN1Ntlbw4miwDyhHRmxXisZ 9vrZiGrOkJkyBpUKdOE8iFb6sEeUVLQQQJu3ojYHpGnTMyyc+PY6coLomwTy/E7Vpjs6 OIaDqHM/2HYeihW6IfwnFU3eiyZBdbyqAztT/UEI1Ga7OiHkYHZ5h22iWRn4UbJTJK+G QKdWtGs1mIk6Fymio9wkDRNrYfK5S/d+oZUFTotyq1kp7VuQL2ljBzlb7cNhdSk/LuUn waCUAM48tVyly36NwZ2Gd4hSnGDv/GCbaLiZpRL99lz9cIU5bKZROYJIzDi1yElqzX4J nkmw==
X-Gm-Message-State: ALoCoQlNoP3o0p83ISX5HuNd2FAjMvLerg4KJpQKS0h08TpoZrfLZPxZ53SOiZ57aDW+MTci0Io0
X-Received: by 10.140.27.194 with SMTP id 60mr52517148qgx.57.1415745632350; Tue, 11 Nov 2014 14:40:32 -0800 (PST)
Received: from zbox.pahtak.org (c-68-48-196-126.hsd1.md.comcast.net. [68.48.196.126]) by mx.google.com with ESMTPSA id k6sm19469062qaz.41.2014.11.11.14.40.30 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Nov 2014 14:40:31 -0800 (PST)
Received: from [128.220.247.217] (unknown [128.220.247.217]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id 489A6AC2867; Tue, 11 Nov 2014 17:40:29 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Stephen Checkoway <s@pahtak.org>
In-Reply-To: <CABkgnnWw9zsrqQzHVU0vXLJM+HBK3QYxJAZE+0kgGkEQEzwS=w@mail.gmail.com>
Date: Tue, 11 Nov 2014 17:40:23 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <32DFF6C4-DF27-4E23-9A08-44CA3E22CE50@pahtak.org>
References: <CABkgnnWw9zsrqQzHVU0vXLJM+HBK3QYxJAZE+0kgGkEQEzwS=w@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TKsQFXQ-xdxPq6z4vXrY4SuMEGQ
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Deprecating SSLv3
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: Tue, 11 Nov 2014 22:40:35 -0000

On Nov 10, 2014, at 6:17 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

> Richard, Alfredo, Adam and I have proposed such a statement:
> 
> https://datatracker.ietf.org/doc/draft-thomson-sslv3-diediedie/

Is there any harm associated with having 03 00 in the record layer? It seems like the three statements you want are:

1. The client MUST NOT send a ClientHello with ClientHello.client_version set to { 3, 0 }.
2. The server MUST NOT send a ServerHello with ServerHello.server_version set to { 3, 0 }.
3. If the client receives a ServerHello with ServerHello.server_version set to { 3, 0 }, the client MUST send a "protocol_version" alert message and close the connection.

I think these three are sufficient to forbid negotiating SSLv3 and the advice given in Appendix E still applies:

   TLS clients that wish to negotiate with older servers MAY send any
   value {03,XX} as the record layer version number.  Typical values
   would be {03,00}, the lowest version number supported by the client,
   and the value of ClientHello.client_version.  No single value will
   guarantee interoperability with all old servers, but this is a
   complex topic beyond the scope of this document.

1 isn't necessary as long as you have 3, but it seems pointless to have ClientHello.client_version = { 3, 0 } and then close the connection.

The current draft seems to allow the following two scenarios where the client adheres to the draft but the server does not.

Scenario I:
TLSPlaintext.version = { 3, 1 }
ClientHello.client_version = { 3, 0 }
ServerHello.server_version = { 3, 0 }

Scenario II:
TLSPlaintext.version = { 3, 1 }
ClientHello.client_version = { 3, 1 }
ServerHello.server_version = { 3, 0 }

The first scenario is pretty unlikely (why would the client be compliant with the draft but have a maximum version of SSLv3?) but would seem to work with a TLSv1.2 server that was willing to negotiate SSLv3.

The second scenario seems more likely with a SSLv3 server (which accepts 03 xx in the record layer).

Maybe I'm missing something that rules those two cases out. But even if so, a clear MUST NOT regarding the client_version and server_version and a MUST on the protocol_alert if the server wants SSLv3 seems better overall.

-- 
Stephen Checkoway