IETF Logo Mail Archive

Re: [TLS] Re-thinking OPTLS

Nico Williams <nico@cryptonector.com> Mon, 24 November 2014 06:33 UTC

Return-Path: <nico@cryptonector.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 AC2D41A1BDD for <tls@ietfa.amsl.com>; Sun, 23 Nov 2014 22:33:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.634
X-Spam-Level: *
X-Spam-Status: No, score=1.634 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 SSlR48AtCT4x for <tls@ietfa.amsl.com>; Sun, 23 Nov 2014 22:33:07 -0800 (PST)
Received: from homiemail-a84.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id AA75E1A1BE5 for <tls@ietf.org>; Sun, 23 Nov 2014 22:33:07 -0800 (PST)
Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 3946E1DE060; Sun, 23 Nov 2014 22:33:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=0Ge6GUpn/osXem h+hxW1Xjk3NcY=; b=RnWTb6SVfP8UOGFoKWJgDWQ6Hdlk2XpfAxz40sRjo5kAYs 9GiQHPNQRESVILTmm6fKSknWaZtVbeevFnmoAKZZpfovL9CRlF7kxMzzox3DUp/k gYsUdiuZToljkDjx9o4Zeny+SLZSs0CGKKswrItvCKYLxctRsLGyplQD8eeRs=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPA id D9E741DE05D; Sun, 23 Nov 2014 22:33:06 -0800 (PST)
Date: Mon, 24 Nov 2014 00:33:06 -0600
From: Nico Williams <nico@cryptonector.com>
To: Hugo Krawczyk <hugo@ee.technion.ac.il>
Message-ID: <20141124063304.GA3200@localhost>
References: <CADi0yUMCGuYbqrJWa-KXNmgNvc19xOWwpx2DCLOvgv62haedCQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CADi0yUMCGuYbqrJWa-KXNmgNvc19xOWwpx2DCLOvgv62haedCQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gpcGfbbVMfxXaUy08CtY7mtlg3Q
Cc: "tls@ietf.org" <tls@ietf.org>, Hoeteck Wee <hoeteck@alum.mit.edu>
Subject: Re: [TLS] Re-thinking OPTLS
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, 24 Nov 2014 06:33:08 -0000

I'm in favor of using static server (EC)DH keys for server
authentication and possible 0-RTT, particularly in connection
with DANE.

I *don't* think that OPTLS is worthwhile without connection to DANE, but
only because OPTLS is just an optimization with roughly the same
applicability as an existing optimization that is much faster: session
resumption [with encrypted session state tickets].

But since I think sprinkling DANE on is the obvious thing to do given
OPTLS as part of the protocol, I'm in favor.

Security-wise the use of static (EC)DH keys is well-understood (as well
understood as (EC)DH is in general).

The g^xs plus (not the arithmetic operator) g^xy method of obtaining PFS
is also OK, and heck, if need be the client could use two different x's,
and the protocol ought to allow it (not least because the client might
want to use different groups/ curves for PFS key agreement than for
authentication key agreement).

Nico
--

v2.23.0 | Report a Bug | By Email