Re: [TLS] Re-thinking OPTLS

Hugo Krawczyk <hugo@ee.technion.ac.il> Tue, 25 November 2014 00:06 UTC

Return-Path: <hugokraw@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 24CC71A89F5 for <tls@ietfa.amsl.com>; Mon, 24 Nov 2014 16:06:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.677
X-Spam-Level:
X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001] 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 zRSGwKxzwN5w for <tls@ietfa.amsl.com>; Mon, 24 Nov 2014 16:06:51 -0800 (PST)
Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E44F61A89B5 for <tls@ietf.org>; Mon, 24 Nov 2014 16:06:49 -0800 (PST)
Received: by mail-lb0-f171.google.com with SMTP id n15so2607922lbi.2 for <tls@ietf.org>; Mon, 24 Nov 2014 16:06:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=sGpW3wR7kcT4alynrEX2+Qf3xlHfqPInmIap71W/ZwQ=; b=GXRDbimMh5AnSiNx+XmIYEeSn65riIUBu1pofe//tALF1hSHrz3iWKCu1rFwzWkxUA bnMionQ3nXurE8x/PpRH46bCvGosaDE6fLdIMDsXJOQHp5kCyEgO90oNzew/FwCqbv+k X9WasfgMs6txW9Mm5Is3nJJSnm0LUGUfDPiNMPgyHZWGH5AphvCKiTDdnEJvbW5eCuXy wyOE8bye7pRyp5/X6i9Auq/gnhi08ZQpqWJ5L2R9jgnQubzjM8NXJuw1Nk6PL7nCE4YT 7ckW5ZeymyU3YJqDn+cIX+LxlLnBs07DHSDsdG2fNCKI/tNTBOPokLNVeMGUP3vGBDEz OQ5A==
X-Received: by 10.152.23.9 with SMTP id i9mr1449168laf.81.1416874008260; Mon, 24 Nov 2014 16:06:48 -0800 (PST)
MIME-Version: 1.0
Sender: hugokraw@gmail.com
Received: by 10.25.78.135 with HTTP; Mon, 24 Nov 2014 16:06:18 -0800 (PST)
In-Reply-To: <20141124063304.GA3200@localhost>
References: <CADi0yUMCGuYbqrJWa-KXNmgNvc19xOWwpx2DCLOvgv62haedCQ@mail.gmail.com> <20141124063304.GA3200@localhost>
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
Date: Mon, 24 Nov 2014 19:06:18 -0500
X-Google-Sender-Auth: Mo0wrzZrwFNuAfg92OTXgmGMgGQ
Message-ID: <CADi0yUMvj7k1JXpa_9H3brUizr4QsLh6gsjzXaRJo79Vv0dqnQ@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: multipart/alternative; boundary="089e0160b870f437190508a3afa6"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9EQUc_sv25g8IuKK3H5aZ_v7FgY
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: Tue, 25 Nov 2014 00:06:52 -0000

On Mon, Nov 24, 2014 at 1:33 AM, Nico Williams <nico@cryptonector.com>
wrote:

>
> 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].
>

​Session resumption is indeed faster if you don't do PFS - otherwise it is
still faster but not by much.
And of course, as I'm sure you agree, there are 0-RTT scenarios that cannot
be  reduced to session resumption as in the QUIC case mentioned by AGL or
any setting where keeping a shared secret state at the client is not
practical.

Hugo
​

>
> 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
> --
>