[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
- [TLS] 0-RTT encrypted data limits Hubert Kario
- Re: [TLS] 0-RTT encrypted data limits Eric Rescorla
- Re: [TLS] 0-RTT encrypted data limits Ilari Liusvaara
- Re: [TLS] 0-RTT encrypted data limits Hubert Kario
- Re: [TLS] 0-RTT encrypted data limits Eric Rescorla
- Re: [TLS] 0-RTT encrypted data limits Hubert Kario
- Re: [TLS] 0-RTT encrypted data limits Ilari Liusvaara
- Re: [TLS] 0-RTT encrypted data limits Eric Rescorla
- Re: [TLS] 0-RTT encrypted data limits David Benjamin
- Re: [TLS] 0-RTT encrypted data limits Ilari Liusvaara
- Re: [TLS] 0-RTT encrypted data limits Eric Rescorla
- Re: [TLS] 0-RTT encrypted data limits David Benjamin
- Re: [TLS] 0-RTT encrypted data limits Eric Rescorla
- Re: [TLS] 0-RTT encrypted data limits Ilari Liusvaara
- Re: [TLS] 0-RTT encrypted data limits Martin Thomson