IETF Logo Mail Archive

Re: [TLS] Simple, secure 0-RTT for the masses

Nicholas Sullivan <nicholas.sullivan@gmail.com> Wed, 16 March 2016 19:07 UTC

Return-Path: <nicholas.sullivan@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD4812D675 for <tls@ietfa.amsl.com>; Wed, 16 Mar 2016 12:07:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 VdM2vwqG90ha for <tls@ietfa.amsl.com>; Wed, 16 Mar 2016 12:07:45 -0700 (PDT)
Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (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 7BAB712D59D for <TLS@ietf.org>; Wed, 16 Mar 2016 12:07:45 -0700 (PDT)
Received: by mail-pf0-x22d.google.com with SMTP id n5so85888085pfn.2 for <TLS@ietf.org>; Wed, 16 Mar 2016 12:07:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ouGgKZqvx9kbhc2waFDsjYw4nrjH5ED7iKGFA9U7AMI=; b=iQc8vptVgFzRsgOQFX1plOfUSJhXUq6OZDgL3/DNkEF1pOYemqrpBn9W/hx3uzDjHF T553r+W74pNYR//bCqMAc/Te+rnz0q3Q4qskikkBb3gOqsuKEIyzjyKUsygVsoGLUbm0 wCz+JTQxx5N20JE0pj5sNjzGSXwagq5vwzMf8u2jfIb4zeZadA4/WDpol4UiMiKfkjM0 tQpxGRHVOEaEt59XsI0pg7J7TCykqKOZ+d6jj8GL9E8h9eWOK/SFkLO+KNOHrHkFC8qo GcctQjk7jcycJr8UGr2O2mABygLdCK57knqypO4csH7Jjs921BIbUrzXEsdgIzQqz0q6 uQhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ouGgKZqvx9kbhc2waFDsjYw4nrjH5ED7iKGFA9U7AMI=; b=m4j0BzUYbKew4m2IGx3/s1wO8qvhReIIMm/ea/i1XuhXErE00cvE/Sr4cFmwGsIFx4 6cwd2BeOvBFchrwN/psuXz1pryjr0tOrhX3+1wQXOQCktdP/TFWG6DDLEH5qbHb8ye2D C8TJFyLX5Qyko8OnMCOOFeeif0rYyyP1SvYGjWI5OzCwW+shcDMdT3ESzHDHZYIiDnTz k13Vmopu6fVt4ckwJzES30h5/6rXTQDa0Ja0dE1FpJuuOqXbnzTlO0MvBjO+SLH2/vBu loh3q2NhFy37aZlZ+dsZ0coIb1UrjS1HWWmqKoy1ZCJHQRbPaR1CLSQpfe+XdMQY1dyI dXSw==
X-Gm-Message-State: AD7BkJL9nu6X2l26F2l88DZx+qaWaoFgJaYYPEN9GW5dVLu/xF01JlA29PFScvlpjN2HBg==
X-Received: by 10.98.72.213 with SMTP id q82mr8494415pfi.164.1458155265041; Wed, 16 Mar 2016 12:07:45 -0700 (PDT)
Received: from [10.106.196.252] (mobile-166-137-176-021.mycingular.net. [166.137.176.21]) by smtp.gmail.com with ESMTPSA id f66sm7485364pff.8.2016.03.16.12.07.43 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Mar 2016 12:07:43 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Nicholas Sullivan <nicholas.sullivan@gmail.com>
X-Mailer: iPhone Mail (13D15)
In-Reply-To: <20160316164539.GB21439@LK-Perkele-V2.elisa-laajakaista.fi>
Date: Wed, 16 Mar 2016 12:07:42 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <51A8A7B6-D28F-49AE-AA45-6645DDBD9356@gmail.com>
References: <CAH9QtQGdZ9=XG-Qc5G6amM1pOnBse5jZndL0kExxArWXoQbhsQ@mail.gmail.com> <CAAF6GDegiWr3cWPpQAiVTZ5RhWFg24C-=SB=b=tKVTpaPn3V5g@mail.gmail.com> <CAH9QtQHvrz0guqGeMxD-C1ifCLOvOuADGdeqtCMHkEnRZ=y+hw@mail.gmail.com> <CAAF6GDc+Lnzpx38YT0gvgetb8E9yVsgMkLMh1SB7tu=fw_SK4A@mail.gmail.com> <CAH9QtQF02zwnB6dOGjFfWX2RLc4_RSODFpHaVLZkK_5KDf93sg@mail.gmail.com> <CAAF6GDd0h=1--pViASw3pT5nMAM4SRy2C2hzA6XF7Ba_g+oL4w@mail.gmail.com> <20160316081717.GA21439@LK-Perkele-V2.elisa-laajakaista.fi> <CAAF6GDcAojmjOwuuwL-Vtk-U2VXa0JyXcqdZaDXrYmEuj=6eEA@mail.gmail.com> <20160316164539.GB21439@LK-Perkele-V2.elisa-laajakaista.fi>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Lgvm7p0o3C-UdoOhFGykuhoMPuA>
X-Mailman-Approved-At: Wed, 16 Mar 2016 18:18:42 -0700
Cc: "tls@ietf.org" <TLS@ietf.org>
Subject: Re: [TLS] Simple, secure 0-RTT for the masses
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 16 Mar 2016 19:10:52 -0000

What problem are you trying to solve here?

The forward secrecy properties of 0-RTT data in PSK mode are tied to the lifetime of the resumption secret, not a long-lived secret like the private key. If we limit the maximum lifetime of a given session ticket (say to 7 days as previously proposed on this mailing list) and recommend a similar lifetime for session ticket encryption keys, then what is the forward secrecy risk?

> On Mar 16, 2016, at 9:45 AM, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
> 
>> On Wed, Mar 16, 2016 at 08:12:48AM -0400, Colm MacCárthaigh wrote:
>> On Wed, Mar 16, 2016 at 4:17 AM, Ilari Liusvaara <ilariliusvaara@welho.com>
>> wrote:
>>> 
>>> - Duplication of 0-RTT data into 1-RTT data of _different_ connection.
>> 
>> I think using a different content type solves this; the early data is
>> illegal in the 1-RTT phase and the content type would distinguish it.
> 
> Nope, this can not be realistically solved, _even_ with server state
> (the 0-RTT to 0-RTT duplication is unsolveable without state, but can
> be solved with server state).
> 
> 
>> As an aside: an application protocol where latency is so sensitive that
>> 0RTT is attractive would hardly have its own back-and-forth with banners in
>> the first place.
> 
> The problem is that such banners would not be bound to the TLS connection
> in any way, which causes problems (TLS has no facility to transport data
> from application inside extension).
> 
> 
> -Ilari
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email