Subject: [TLS] [PSA] 0-RTT tolerance is mandatory

From: Hubert Kario <[email-masked]>
Date: Wed, 04 Jul 2018 14:42:51 +0200

All the implementations I deal with in my day-to-day work fail to handle the 
0-RTT client hello correctly when the 0-RTT support is not enabled on the 
server.

I.e. they ignore the MUST clause from
https://tools.ietf.org/html/draft-ietf-tls-tls13-28#page-58 stating that the 
server can handle an early_data extension (and following encrypted data) in 
only one of three ways, neither which allows for unconditional connection 
abort.

This also runs afoul the recommendation from https://tools.ietf.org/html/
draft-ietf-tls-tls13-28#section-D.3 on 0-RTT backwards compatibility.

Quick test can be performed by running the tlsfuzzer script.
Start a server on port 4433 (or use the -p switch to the test case to change 
it) on localhost (or use -h switch to provide ip or hostname) with support for 
draft-28, a RSA server key, support for P-256 ECDH, AES-128-GCM cipher and 
SHA-256 signature hash. The server needs to be able to respond to a record 
with an HTTP GET query (i.e. either HTTP server or an echo server will work).

Download the requirements:
git clone https://github.com/tomato42/tlsfuzzer
pushd tlsfuzzer
# won't be needed after tlsfuzzer#423 PR is merged
git checkout 0rtt-garbage-resumption
git clone https://github.com/tomato42/tlslite-ng .tlslite-ng
ln -s .tlslite-ng/tlslite tlslite
git clone https://github.com/warner/python-ecdsa .python-ecdsa
ln -s .python-ecdsa/ecdsa ecdsa

Run the test case:
PYTHONPATH=. python scripts/test-tls13-0rtt-garbage.py

successful run will print
Test end
successful: 3
failed: 0

at the end

the test case supports also --num-bytes switch to provide how big the early 
data should be (sends 2^14B by default).
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 4 Jul 2018 16:06:27 +0300

> draft-ietf-tls-tls13-28#section-D.3 on 0-RTT backwards compatibility.

OTOH, such servers probably do not send out tickets allowing 0-RTT, so
any client attempting 0-RTT with such server is very broken.

-Ilari

---

From: Hubert Kario <[email-masked]>
Date: Wed, 04 Jul 2018 15:27:08 +0200

On Wednesday, 4 July 2018 15:06:27 CEST Ilari Liusvaara wrote:
> > All the implementations I deal with in my day-to-day work fail to handle
> > the 0-RTT client hello correctly when the 0-RTT support is not enabled on
> > the server.
> > 
> > https://tools.ietf.org/html/draft-ietf-tls-tls13-28#page-58 stating that
> > the server can handle an early_data extension (and following encrypted
> > data) in only one of three ways, neither which allows for unconditional
> > connection abort.
> > 

please read Section D.3, it is spelled out in detail there why that's not the 
case

the short of it: the client has no way of knowing if it is connecting to the 
same server/instance/process it received the ticket from

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 4 Jul 2018 09:50:14 -0700

> same server/instance/process it received the ticket from

That's true if you have some kind of mixed rollout, but if you never
supported
0-RTT, then there is something wrong with the client.

-Ekr

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Hubert Kario <[email-masked]>
Date: Fri, 06 Jul 2018 16:51:58 +0200

On Wednesday, 4 July 2018 18:50:14 CEST Eric Rescorla wrote:
> > > > All the implementations I deal with in my day-to-day work fail to
> > 
> > handle
> > 
> > > > the 0-RTT client hello correctly when the 0-RTT support is not enabled
> > 
> > on
> > 
> > > > the server.
> > > > 
> > > > https://tools.ietf.org/html/draft-ietf-tls-tls13-28#page-58 stating
> > 
> > that
> > 
> > > > This also runs afoul the recommendation from
> > 
> > https://tools.ietf.org/html/
> > 

yes, from omniscient point of view, there is something wrong from the client

but I think we can agree that there are no omniscient TLS server 
implementations and there won't be for quite some time :)

(e.g. there could be a situation with a TLS-enabled transparent proxy between 
a client and a server that was later removed – internal corporate network vs. 
coffee shop)
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic