Re: [TLS] Initial draft of DH-based key exchange

Dave Garrett <davemgarrett@gmail.com> Mon, 23 March 2015 22:53 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 112601A0100 for <tls@ietfa.amsl.com>; Mon, 23 Mar 2015 15:53:02 -0700 (PDT)
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 2hpbGLo_DI9z for <tls@ietfa.amsl.com>; Mon, 23 Mar 2015 15:53:00 -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 9C9791A0162 for <tls@ietf.org>; Mon, 23 Mar 2015 15:53:00 -0700 (PDT)
Received: by qgep97 with SMTP id p97so40516368qge.1 for <tls@ietf.org>; Mon, 23 Mar 2015 15:53:00 -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=Sfa46smDvAw/HxK08ptwAtPbwIZsYUzQMYs1kk/tGn4=; b=VsD5YCpSrSFm/N1cswqisnp51jx4eKc1Hrx7OUKgJd36i6dtChUPSe+bnwJIfeInze bbBiSnxxmf2iOAQH71Zw5Sa/vptvMzdq+Eq48p7UXB3TvocReFGq8trB2vAuboMEpoIW p9n3UHyNoLa7pS3uu69vXA3meaYC+gTNAy2nCtTz5Dt+BxurBoPLnJ+PuA6xPD6sKGna Y0EP39eRq7IENGrnJ9sVLE68PLQJ1/hyI7dmAhm2IBdTEw9bs/etA0LzYtjYSdg1H0tP 4JfCfpS1PJexKNrzlL3+/nhc7+cMNlES72zl3kSDqc0rf+WiQ3G1Pfw4N1AEP3pf1CVl pbZw==
X-Received: by 10.140.28.36 with SMTP id 33mr2104015qgy.6.1427151179935; Mon, 23 Mar 2015 15:52:59 -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 z18sm1466630qkz.33.2015.03.23.15.52.59 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 23 Mar 2015 15:52:59 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org, "Salz, Rich" <rsalz@akamai.com>
Date: Mon, 23 Mar 2015 18:52:57 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; )
References: <CABcZeBNmufvfJ_2Nvw1YwvwGZ2u1=WvL45rPGJXARN1tAxOEfw@mail.gmail.com> <CADi0yUMxvN3hHJ2zx7m5hOrPdu080DjvyOGim8c3++QETcx3bA@mail.gmail.com> <35f81edc61614437b1437c74f0b230e9@usma1ex-dag1mb2.msg.corp.akamai.com>
In-Reply-To: <35f81edc61614437b1437c74f0b230e9@usma1ex-dag1mb2.msg.corp.akamai.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201503231852.58112.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/YffU5XOT8GySzbAchtDZVMH-MtQ>
Subject: Re: [TLS] Initial draft of DH-based key exchange
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: Mon, 23 Mar 2015 22:53:02 -0000

On Monday, March 23, 2015 05:15:41 pm Salz, Rich wrote:
> So this is pretty amazing.  We have a proposed uniform key exchange method that uses one primitive and covers all the use cases.  And we have a proposed uniform KDF function that also covers all use cases.
> 
> How can you not like this?  :) Let's call it 2.0, drop record version, IV duplication, etc.  Just have to keep the existing hello messages for interop.

I'm in favor of naming this TLS 2.0 as well, but the on-the-wire version number should stay {3,4} and not {4,0} because TLS version intolerance >1.x is even worse. Probably time to change ProtocolVersion to a 16-bit enum with values based on the existing pattern instead of keeping up the {major,minor} farce. ;)


Dave