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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
