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