Re: [TLS] consensus on backwards compatibility changes
Dave Garrett <davemgarrett@gmail.com> Tue, 27 January 2015 23:00 UTC
Return-Path: <davemgarrett@gmail.com>
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 AB0471A90CA for <tls@ietfa.amsl.com>; Tue, 27 Jan 2015 15:00:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 FtVvVUX_MRzb for <tls@ietfa.amsl.com>; Tue, 27 Jan 2015 15:00:14 -0800 (PST)
Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A578B1A90CE for <tls@ietf.org>; Tue, 27 Jan 2015 15:00:09 -0800 (PST)
Received: by mail-qa0-f51.google.com with SMTP id f12so13729692qad.10 for <tls@ietf.org>; Tue, 27 Jan 2015 15:00:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=1tMES7vfuozJiVKhoUFPZ340HBU7fEx3EilNuC7ILN0=; b=FpHx9ft2ghgPYrmxTjgCg1l76MVHYDl244ci/r7O6BiFV65hTDmZo7BLt8nEsiH0XJ yPlrFvt03oixcpYIa6xuFONetT8xRlj5zPomctQLcFjio08OEiQC7XxoOQ82JaHQdaf5 VF35bssAWFqP+vJZd92CpfteB+o4iUjgAcHN6KR5EfusGacVmiRUVrRnziscLhM2dtFt rbWDpkY0Bv5rMMYAfXvdLPO0OxInOPSr0kSpOSHLwbTWEMSBz6k99FyADLaS+TUSvFAX nigfZ158Q/pZ0Q5494HHC4QB4HoFWQPLZhyxYuFJWA3MVcFqvix1MMDDmkFWkMcExo56 OINg==
X-Received: by 10.140.23.84 with SMTP id 78mr6434249qgo.93.1422399608839; Tue, 27 Jan 2015 15:00:08 -0800 (PST)
Received: from dave-laptop.localnet (pool-72-92-42-38.phlapa.fios.verizon.net. [72.92.42.38]) by mx.google.com with ESMTPSA id t2sm2411966qae.6.2015.01.27.15.00.08 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 27 Jan 2015 15:00:08 -0800 (PST)
From: Dave Garrett <davemgarrett@gmail.com>
To: Joseph Salowey <joe@salowey.net>, mrex@sap.com
Date: Tue, 27 Jan 2015 18:00:06 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-70-generic-pae; KDE/4.4.5; i686; ; )
References: <201412300503.03923.davemgarrett@gmail.com> <201501251833.50963.davemgarrett@gmail.com> <CAOgPGoDvPm4GxbhBYbuhDOc1D5iYf0VvCLs+ZORu8n82sfrQKg@mail.gmail.com>
In-Reply-To: <CAOgPGoDvPm4GxbhBYbuhDOc1D5iYf0VvCLs+ZORu8n82sfrQKg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201501271800.06852.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Cxp0hgCHq6xGmvtWLSoMPxDA5Xg>
Cc: "TLS@ietf.org (tls@ietf.org)" <tls@ietf.org>
Subject: Re: [TLS] consensus on backwards compatibility changes
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, 27 Jan 2015 23:00:20 -0000
On Tuesday, January 27, 2015 11:42:22 am Joseph Salowey wrote: > [Joe] I think this makes sense. I added to comments to the PR. I propose > to move the bit about the server accepting versions {3,x} to the same place > and change the wording of the existing test to say: > > "The client MUST set the version to {3, 1} for the initial ClientHello." Language changed and {3,X} backward compatibility sentence added. > > 5) Explicitly prohibit EXPORT ciphers and any others <100 bits. > > (100 bit line is arbitrary; could be 112 if preferred) > [Joe] draft-ietf-uta-tls-bcp-08 recommends 112 so we probably would match > that. No objection. Updated. On Tuesday, January 27, 2015 01:49:04 pm Martin Rex wrote: > > "The client MUST set the version to {3, 1} for the initial ClientHello." > > The primary reason why several implementors goofed the TLS version > negotiation in TLSv1.0 is that lack of clarity in the language. > > If your above statement refers to the client_version member of the > ClientHello handshake message, please say so. The language is proposed for within the version field definition for the record layer version. Would we want a paragraph somewhere explicitly mentioning possible confusion between record layer version, hello version, & negotiated version? On Tuesday, January 27, 2015 02:20:38 pm Martin Rex wrote: > > Implementations MUST NOT send a ClientHello or ServerHello with > > the protocol version set to { 3, 0 } or less. Any endpoint receiving a > > Hello message with the protocol version set to { 3, 0 } MUST respond > > with a "protocol_version" alert message and close the connection. > > A description similar to this caused the TLS version negotiation problems. > The structure members in the handshake message PDUs are called > ClientHello.client_version and ServerHello.server_version. > > If the above paragraph is meant to apply to the structure members > (client_version, server_version) of the respective TLS handshake message PDUs > (ClientHello, ServerHello), then please use the names of these structure > members for disambiguation. Yes, Eric asked for that same change. I updated the PR a couple days ago. Dave
- [TLS] consensus on backwards compatibility changes Dave Garrett
- Re: [TLS] consensus on backwards compatibility ch… Eric Rescorla
- Re: [TLS] consensus on backwards compatibility ch… Kurt Roeckx
- Re: [TLS] consensus on backwards compatibility ch… Dave Garrett
- Re: [TLS] consensus on backwards compatibility ch… Dave Garrett
- Re: [TLS] consensus on backwards compatibility ch… Kurt Roeckx
- Re: [TLS] consensus on backwards compatibility ch… Dave Garrett
- Re: [TLS] consensus on backwards compatibility ch… Kurt Roeckx
- Re: [TLS] consensus on backwards compatibility ch… Joseph Salowey
- Re: [TLS] consensus on backwards compatibility ch… Sean Turner
- Re: [TLS] consensus on backwards compatibility ch… Ira McDonald
- Re: [TLS] consensus on backwards compatibility ch… Martin Rex
- Re: [TLS] consensus on backwards compatibility ch… Martin Rex
- Re: [TLS] consensus on backwards compatibility ch… Joseph Salowey
- Re: [TLS] consensus on backwards compatibility ch… Dave Garrett
- Re: [TLS] consensus on backwards compatibility ch… Florian Weimer
- Re: [TLS] consensus on backwards compatibility ch… Martin Rex
- Re: [TLS] consensus on backwards compatibility ch… Florian Weimer
- Re: [TLS] consensus on backwards compatibility ch… Eric Rescorla
- Re: [TLS] consensus on backwards compatibility ch… Dave Garrett
- Re: [TLS] consensus on backwards compatibility ch… Michael Clark
- Re: [TLS] consensus on backwards compatibility ch… Dave Garrett
- Re: [TLS] consensus on backwards compatibility ch… Nikos Mavrogiannopoulos
- Re: [TLS] consensus on backwards compatibility ch… Dave Garrett
- Re: [TLS] consensus on backwards compatibility ch… Ilari Liusvaara