Re: [TLS] 0-RTT encrypted data limits

Hubert Kario <hkario@redhat.com> Thu, 01 September 2016 13:39 UTC

Return-Path: <hkario@redhat.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 7438912D973 for <tls@ietfa.amsl.com>; Thu, 1 Sep 2016 06:39:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.47
X-Spam-Level:
X-Spam-Status: No, score=-7.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 JliqpOpsotRH for <tls@ietfa.amsl.com>; Thu, 1 Sep 2016 06:39:46 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB76912D980 for <tls@ietf.org>; Thu, 1 Sep 2016 06:09:17 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4168061E7E; Thu, 1 Sep 2016 13:09:17 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-191.brq.redhat.com [10.34.0.191]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u81D9FM5022835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Sep 2016 09:09:17 -0400
From: Hubert Kario <hkario@redhat.com>
To: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 01 Sep 2016 15:09:10 +0200
Message-ID: <13153781.Czt0kPasXn@pintsize.usersys.redhat.com>
User-Agent: KMail/5.2.3 (Linux/4.6.7-300.fc24.x86_64; KDE/5.25.0; x86_64; ; )
In-Reply-To: <CABcZeBN_TPyYD63u4t41SKn-T6ugZdpxgM8i7-tJ82tU13+yUA@mail.gmail.com>
References: <6918283.boJRZ9WqjH@pintsize.usersys.redhat.com> <6822534.tPWjKYA1SU@pintsize.usersys.redhat.com> <CABcZeBN_TPyYD63u4t41SKn-T6ugZdpxgM8i7-tJ82tU13+yUA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart3800068.3iEQ9J9RWH"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Thu, 01 Sep 2016 13:09:17 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/fBw-t5yx7zbUfmnf4eZxfvWO4xc>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] 0-RTT encrypted data limits
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: Thu, 01 Sep 2016 13:39:48 -0000

On Thursday, 1 September 2016 05:48:02 CEST Eric Rescorla wrote:
> On Thu, Sep 1, 2016 at 3:31 AM, Hubert Kario <hkario@redhat.com> wrote:
> > On Wednesday, 31 August 2016 11:23:11 CEST Eric Rescorla wrote:
> > > On Wed, Aug 31, 2016 at 11:14 AM, Hubert Kario <hkario@redhat.com>
> > 
> > wrote:
> > > > Current draft has the following text in it:
> > > >     If any of these checks fail, the server MUST NOT respond
> > > >     with the extension and must discard all the remaining first
> > > >     flight data (thus falling back to 1-RTT). If the client attempts
> > > >     a 0-RTT handshake but the server rejects it, it will generally
> > > >     not have the 0-RTT record protection keys and must instead
> > > >     trial decrypt each record with the 1-RTT handshake keys
> > > >     until it finds one that decrypts properly, and then pick up
> > > >     the handshake from that point.
> > > > 
> > > > My understanding of that, in case client does 0-RTT but server rejects
> > 
> > it
> > 
> > > > (because the PSK is too old or its time is different enough) is that
> > 
> > the
> > 
> > > > server needs to keep on reading arbitrarily large amounts of data it
> > 
> > has
> > 
> > > > no
> > > > idea what to do with
> > > > 
> > > > Why is there no limit on the amount of data that can be encrypted
> > > > using
> > > > PSK keys (0-RTT)?
> > > 
> > > I don't think this would usefully improve things.
> > 
> > there's also second angle:
> > 
> > I'm afraid that requiring the server to keep the connection open for
> > essentially arbitrary amount of time while it consumes garbage data is not
> > unlike the Apache slowloris attack.
> 
> It's not required to. It can close the connection at any time.

Then how about making it explicit by including following paragraph:

    To protect against denial of service attacks, servers MAY close the 
    connection at any point when processing records with
    trial decryption, but SHOULD process at least four records before doing 
    so. This is so that server can find the second Finished message in case 
    client sent just one record of Application Data.

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky┼łova 99/71, 612 45, Brno, Czech Republic