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:
>=20
> 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 =3D { 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 =3D { 3, 1 }
ClientHello.client_version =3D { 3, 0 }
ServerHello.server_version =3D { 3, 0 }

Scenario II:
TLSPlaintext.version =3D { 3, 1 }
ClientHello.client_version =3D { 3, 1 }
ServerHello.server_version =3D { 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.

--=20
Stephen Checkoway