IETF Logo Mail Archive

Re: [TLS] Do we actually need semi-static DHE-based 0-RTT?

Eric Rescorla <ekr@rtfm.com> Fri, 19 February 2016 18:16 UTC

Return-Path: <ekr@rtfm.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 73F361B2CF5 for <tls@ietfa.amsl.com>; Fri, 19 Feb 2016 10:16:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 j4QV2rsKmBUg for <tls@ietfa.amsl.com>; Fri, 19 Feb 2016 10:16:51 -0800 (PST)
Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (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 031281B2B1C for <tls@ietf.org>; Fri, 19 Feb 2016 10:16:51 -0800 (PST)
Received: by mail-yk0-x232.google.com with SMTP id z13so38273264ykd.0 for <tls@ietf.org>; Fri, 19 Feb 2016 10:16:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=F1bsW50iADdECYM2APU7WLTVTiEAzrS/9JJNCe9a4NA=; b=uXIQZZDrHpZUmFM7jAN+pn3d6KU133P++06h1EkWfvKFhvvBEAkYuHXiFl4ZMfxGKj jrbwEXAYOotqhaA2s4/dr9W51Qcrx571cpWc9NlZR/SQ82z9Sbo2UaHxMo04tjphNJ6o 2/MBYZMhRMCXf2stJW9PUXuP2/jvKQsuducf49cagNlvuAnc9h5cX5HJMC/lNrbkuf/j OBmvr8FCyPv0XOGW14TZ7+Ja2rHXt+MZR/Dd8eyG3CzlDVSf+jFVBOShVK5VHAPmG2PB bEE0wlXacTUjLIfHQMGCq/lUOSahScUExpICDJir44Z+LMiIi0Nq+0oswGKQMUGZN7+w mWtw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=F1bsW50iADdECYM2APU7WLTVTiEAzrS/9JJNCe9a4NA=; b=iPs9V63mNg4ikcxyDgPoYsD3GEBKkljEAIhr3xK6eDln4EEIgfsSZR0nwMDdtRO//L 37fCeksh5Divf9go6BmeS09qdYgX7CILoh0ALNiv1Zzz2z0wm/UsA5aWQ5Ks/1j5Q74q Da/NtzKd2872rhUUnzSoLvhJmaw+gs20f6gDVfRfZ1Vu2OvS+TimicDNkhT81Y7cusI6 pYogilJfBDY4jx/y8xtwH31lsibONsm8nuvDrH2M686ZHM6brJyBISWz6hIII4+rGY0/ iXkw+5bIjFotJDgtj9358NsYWz4vbQfkvjj8WoxPmsaSZwU/AmenrXV3f5o1pLeRw9Is R0NQ==
X-Gm-Message-State: AG10YOR6T5YWWJ4WJ2rlY2dHBrSGiBxT8hraoMdjBf1Ei8G9xcJ2fhbT4qSukoBCRfCm5+pGEiKHDDldBPdeHw==
X-Received: by 10.37.231.146 with SMTP id e140mr7956317ybh.146.1455905810362; Fri, 19 Feb 2016 10:16:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.249.5 with HTTP; Fri, 19 Feb 2016 10:16:10 -0800 (PST)
In-Reply-To: <CABcZeBPR9fU9SVLAsVbfQPuwQ1nkbF6S1GmU=kfzMWJPYEFZrw@mail.gmail.com>
References: <CABcZeBMFE24o-F7JO8E2=xFmasR3iqabZhn6Qv4fw+ihYfTc6g@mail.gmail.com> <75b91c8af44e4520a5433d48c97582b0@ustx2ex-dag1mb1.msg.corp.akamai.com> <CABcZeBPR9fU9SVLAsVbfQPuwQ1nkbF6S1GmU=kfzMWJPYEFZrw@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 19 Feb 2016 11:16:10 -0700
Message-ID: <CABcZeBO1eMm3cZBZdjhc0Ajn7FC3ZGnxpzSMM=GDRv9hg3ARNg@mail.gmail.com>
To: "Salz, Rich" <rsalz@akamai.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0b12e8a76c1f052c237cd0"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/dgYwQKArfwb81zL2c37FrdQ-82o>
Subject: Re: [TLS] Do we actually need semi-static DHE-based 0-RTT?
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 19 Feb 2016 18:16:52 -0000

+ TLS WG

On Fri, Feb 19, 2016 at 8:46 AM, Eric Rescorla <ekr@rtfm.com> wrote:

>
> On Fri, Feb 19, 2016 at 8:01 AM, Salz, Rich <rsalz@akamai.com> wrote:
>
>> I greatly prefer one way to do things.  (Python not perl, if you will :)
>>
>> On the other hand, there is an elegance about using a single
>> well-understood mechanism even if it has operational burdens.  We all know
>> how to secure PSK material, though, right? :)  But what dose this do about
>> encrypted-SNI?
>>
>
> Funny you should mention that. There's actually a very elegant way to do
> encrypted
> SNI here (due to Cedric Fourney). The basic idea is that you initially
> contact the hidden
> server and do a TLS handshake establishing a ticket. That ticket actually
> has two parts:
>
> - The ordinary ticket
> - The identity of the hidden cipher enciphered for the gateway
>
> Then when you connect to the gateway, you do an apparent PSK+(ECDHE)
> handshake with it and provide the ticket. It unwraps the identity of the
> hidden
> server and then forwards the ClientHello to the hidden server for
> processing
> and the rest of the handshake just completes as normal, but with the hidden
> server [0]. And because each handshake provides a new ticket, this
> is unlinkable.
>
> The major drawback of this design is that the first ticket establishment
> requires
> contacting the hidden server, but you can either do this directly (as we
> have
> been assuming) or just tunnel through the gateway the first time with
> TLS-in-TLS.
>
> -Ekr
>
> [0] I originally thought this might need a change to the ticket signaling
> mechanism, but I'm less sure that that's true. In any case, that should
> be minor.
>
>
>> --
>> Senior Architect, Akamai Technologies
>> IM: richsalz@jabber.at Twitter: RichSalz
>>
>>
>>
>

v2.23.0 | Report a Bug | By Email