Re: [TLS] New TLS version negotiation mechanism extension

Dave Garrett <davemgarrett@gmail.com> Sun, 29 March 2015 06:04 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 5668F1A9240 for <tls@ietfa.amsl.com>; Sat, 28 Mar 2015 23:04:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level:
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 EOfWhJdhIQQ7 for <tls@ietfa.amsl.com>; Sat, 28 Mar 2015 23:04:52 -0700 (PDT)
Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D71981A924B for <tls@ietf.org>; Sat, 28 Mar 2015 23:04:51 -0700 (PDT)
Received: by qgep97 with SMTP id p97so164747626qge.1 for <tls@ietf.org>; Sat, 28 Mar 2015 23:04:51 -0700 (PDT)
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=Fs8jAMqsfcUpeyQSTM6S9SofELAHwztb69LsG2ve6AQ=; b=rIuqjJIK/p2r3GxYd98F66T4xTfDcAoCaWDKIMI8EgrIdECItz5ZF58el/lj4XwdHt ntdOlLBtOFLL0teZtqEJujuIdTZA6fwWvt0di8t813lhHxhnFQp4gcD89m9ER8TQYMrX tkWHI55dBnU0vvRe4wumUQx3AxK+QDEgex+BNCyFGNzU+aAf8+X0912NhqI0ZtJZ4gvE 6+eFL1GoViqfQRbcHEtqTmbNT+KoPxOoGsFcEk3nmatu60LLHIIaevc7dvkwjg4yS7+e uSsX7xgrQ+cJUK6Lo7UQ8TzsoOsM+YaTm6BMQQEig+mkGKzDo5gVR/LUhA8wArA6x1db VS7Q==
X-Received: by 10.140.146.68 with SMTP id 65mr35519207qhs.101.1427609091155; Sat, 28 Mar 2015 23:04:51 -0700 (PDT)
Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id g51sm5184690qgg.23.2015.03.28.23.04.50 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 28 Mar 2015 23:04:50 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Date: Sun, 29 Mar 2015 02:04:49 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; )
References: <201503260330.43588.davemgarrett@gmail.com> <BAY180-W16CB11289DEAA0E2A2681BFF090@phx.gbl> <201503272253.30495.davemgarrett@gmail.com>
In-Reply-To: <201503272253.30495.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201503290204.49549.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/8jPzs0vnFb3iPHV75fEn6yS1U3Y>
Subject: Re: [TLS] New TLS version negotiation mechanism extension
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: Sun, 29 Mar 2015 06:04:53 -0000

After rewriting the list based approach, I think it really is the best way forward. I've updated my WIP branch. It's simpler and far more thorough than the prior drafts.

https://github.com/davegarrett/tls13-spec/compare/patch-3...davegarrett:EVN

This simplifies the handling of backward capable version negotiation and does everything through the extension. I think it's overall easier to follow in comparison to the other approach, or the prior spec. I think that by requiring implementations to switch over to a general list comparison approach and drop their old logic, this can create a far more reliable process. (the basic list comparison mechanism is done for plenty of other areas in TLS)

Note that the little pseudocode bit is really only there to point out the simplicity. It's probably not needed.


Dave