Re: [TLS] consensus on backwards compatibility changes

Dave Garrett <> Fri, 20 February 2015 18:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2DE1F1A88AF for <>; Fri, 20 Feb 2015 10:45:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NNwewi6cv5vd for <>; Fri, 20 Feb 2015 10:45:54 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 45AD41A883A for <>; Fri, 20 Feb 2015 10:45:54 -0800 (PST)
Received: by with SMTP id a108so15476478qge.7 for <>; Fri, 20 Feb 2015 10:45:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=U2IM3CoFognErfG0k3sCva2ZcC0JVbXfUpogyU0/WUg=; b=t3WBOn3BNtkaeBotYW05IOM9PaEDc55pSnDdGPzphXQuZa29OresFmaXVx6ldNMpO8 t2cDIj5dwkzjDeSgVLU2DMnT4GfLUE46j/wGgKyYQW4dcGxjxyDKb7tQPeuV/yqihCxD XXE9X+YbDaXXG988V95YZxe+/7Y8neMVjjJVhcK8FjzPmn/eByOz3XnmSDIwAoA4mXWZ nW84DAfRKZxIEMzLsMglgVl7e88HQcMnYFhgzv3sahQToC5WUuoFkshwPM1jYRHj83vq eahM1sVZgUgoyIm7Gx9RzXg9LrGlbZ+FCW8+MrAd0vadA2TygmEajenXsB6s5nrH9+G0 yxfg==
X-Received: by with SMTP id a91mr25834473qgf.46.1424457953516; Fri, 20 Feb 2015 10:45:53 -0800 (PST)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id f20sm5124030qax.37.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 20 Feb 2015 10:45:52 -0800 (PST)
From: Dave Garrett <>
To: Michael Clark <>, David Benjamin <>
Date: Fri, 20 Feb 2015 13:45:51 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; )
References: <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <>
Archived-At: <>
Cc: " (" <>
Subject: Re: [TLS] consensus on backwards compatibility changes
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Feb 2015 18:45:56 -0000

I've made some editorial improvements to PR 107. I've rewritten a few little bits of prior existing text and simplified the sectioning. I've also fixed some section linking. Insecure fallback is now explicitly listed as "NOT RECOMMENDED" as suggested by Michael Clark.

There is one new remaining issue to discuss that was brought up by David Benjamin on GitHub. Essentially, we want to make sure that the wording of what versions are to be used in the record layer is precise, including error cases, such that implementations are consistent here. I'd like to see what the opinion of the list is on the topic.

Current PR 107 wording for the record layer version field:
TLS clients MUST set this version to { 3, 1 } for the initial ClientHello.
For the ServerHello and all other TLS records this MUST be equal to the negotiated version.

My current consideration (not yet in PR):
Prior to version negotiation, this value MUST be { 3, 1 }. This includes the ClientHello, records sent during negotiation, and errors aborting the negotiation.
After version negotiation, this MUST be equal to the negotiated version. This includes the ServerHello and all following records.

I explicitly mention records and errors so as to make sure records in EarlyDataExtension are included. Maybe just call it out by name instead? Anyone think of some better wording here?

Once we can agree on the wording of this, I think this set of changes should be ready unless someone else has a concern that has not been addressed.