[TLS] 0-RTT encrypted data limits

Hubert Kario <hkario@redhat.com> Wed, 31 August 2016 18:14 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 D550112D630 for <tls@ietfa.amsl.com>; Wed, 31 Aug 2016 11:14:36 -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 rMoLhXUhL8px for <tls@ietfa.amsl.com>; Wed, 31 Aug 2016 11:14:35 -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 B8C0112D624 for <tls@ietf.org>; Wed, 31 Aug 2016 11:14:35 -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 2AA7481112 for <tls@ietf.org>; Wed, 31 Aug 2016 18:14:35 +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 u7VIEXex022115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <tls@ietf.org>; Wed, 31 Aug 2016 14:14:34 -0400
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Wed, 31 Aug 2016 20:14:33 +0200
Message-ID: <6918283.boJRZ9WqjH@pintsize.usersys.redhat.com>
User-Agent: KMail/5.2.3 (Linux/4.6.7-300.fc24.x86_64; KDE/5.25.0; x86_64; ; )
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart6140466.7ZuFn2xtLx"; 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.27]); Wed, 31 Aug 2016 18:14:35 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/MSyz9YCQCdTj4-AVJkCPwvAGnbo>
Subject: [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: Wed, 31 Aug 2016 18:14:37 -0000

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. All using slow path (thinking exception handling in 
particular).

Is my understanding correct?

Why is there no limit on the amount of data that can be encrypted using PSK 
keys (0-RTT)?
-- 
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