IETF Logo Mail Archive

Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context)

Ilari Liusvaara <ilariliusvaara@welho.com> Sat, 26 March 2016 20:10 UTC

Return-Path: <ilariliusvaara@welho.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 ED0A512D19E for <tls@ietfa.amsl.com>; Sat, 26 Mar 2016 13:10:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 Au0YoN_MfyJ8 for <tls@ietfa.amsl.com>; Sat, 26 Mar 2016 13:10:17 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD4012D14D for <tls@ietf.org>; Sat, 26 Mar 2016 13:10:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 329984C57; Sat, 26 Mar 2016 22:10:16 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id lstf7N9HkNmh; Sat, 26 Mar 2016 22:10:15 +0200 (EET)
Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id B9E182310; Sat, 26 Mar 2016 22:10:15 +0200 (EET)
Date: Sat, 26 Mar 2016 22:10:13 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <20160326201013.GA14675@LK-Perkele-V2.elisa-laajakaista.fi>
References: <BC748097-6833-4BEB-9282-AF278B00FB96@inria.fr> <CAAF6GDefiSCnggjgQJT3NG0DJMC2SDJ=r__npg5L6ycicuzpJQ@mail.gmail.com> <CABcZeBOigwqtBsuKTNTVAztFKuv75m+GmdVdYWX+nWGAkRJM5g@mail.gmail.com> <CAAF6GDdRzFZ_9YO4KguwTuR2Mi+pvUY6e=yS1MjD0hH9ymC=Ng@mail.gmail.com> <CABcZeBOThQ05O9WQsA5VfsZXv=DqZ83pV1EXH+ePcTugnr+8fA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CABcZeBOThQ05O9WQsA5VfsZXv=DqZ83pV1EXH+ePcTugnr+8fA@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: ilariliusvaara@welho.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/YVDP9LoHFa1QzYEbmx_XKAZ-6ZU>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context)
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: Sat, 26 Mar 2016 20:10:20 -0000

On Fri, Mar 25, 2016 at 12:24:32PM -0700, Eric Rescorla wrote:
> On Fri, Mar 25, 2016 at 12:23 PM, Colm MacCárthaigh <colm@allcosts.net>
> wrote:
> >
> > An implementation would have to be willing to sacrifice replay protection,
> > some cryptographic safety and forward secrecy for the 0RTT data. I'm sure
> > there are implementations that would sacrifice these things to get lower
> > latency more cheaply, but should they be encouraged?
> >
> 
> The issue isn't encouraged. It's whether we should design the protocol so
> that it cannot be implemented any other way.

Also, implementing protocol that it can't be done another way isn't
trivial (aside from limiting session IDs to some small size or something
line that...

If one has enough space to offload state, one can just ignore state
updates, making things replayable...


-Ilari

v2.23.0 | Report a Bug | By Email