TLDR: the spec. was clear and easy to implement, but some test vectors and clarification on what constitutes a Handshake Context would have helped.
FWIW, please let me share my experience of implementing TLS 1.3. This month, I have written a TLS 1.3 implementation (named picotls, available at https://github.com/h2o/picotls) based on draft 16 from scratch. This has been my first time to implement TLS. I wrote my implementation by going through the draft. While writing my code, I did not refer to other implementations except for looking into OpenSSL to see if there was an optimized path for implementing AES-GCM for TLS 1.3 (which turned out to not exist in 1.0.2; it has been introduced in OpenSSL 1.1.0). After my own implementation of server and client started talking to each other, I started to test interoperability by using Firefox Nightly. I had to fix five issues before picotls started talking with Firefox, which took about half a day of work (some errors are not strictly related to TLS). Commit 479f25f, ddd50b7 fixed errors in AEAD construction. Commit 5cb99c5 fixed an error in RSA signing. Commit 2d20c86 fixed a mis-optimization in my implementation of Derive-Secret. Commit 5780bfc fixed a silly mistake in generating a CertificateVerify. Details of each commit can be found at https://github.com/h2o/picotls/commits/master It was possible to fix the errors by observing the fatal alert sent by Firefox and going back to the Internet Draft. But it would have been even more easier if the draft included test vectors especially for the cryptographic operations. Aside from the bugs I fixed, it seemed to me that the draft was vague on whether if msg_type and length of Handshake should be considered as part of the Handshake Context (please forgive me if I missed somewhere that mentions it). In section 4.4, the draft states that, quote: a Handshake Context based on the hash of the handshake messages. This text seems to imply that msg_type and length should be considered part of the Context, but I could not find a formal definition of what a “handshake message” is. OTOH, other parts of the Draft seem to refer to Handshake Context as a list of Handshake bodies. For example, the table in section 4.4 states that the Handshake Context for 0-RTT mode is ClientHello. I think this could be interpreted that the Context is not expected to include msg_type and length, since ClientHello is a structure that is used as a message body. So even though my interpretation (the former of the two) was correct in sense that it matched that of Firefox, I needed to check if the browser was interpreting the draft in the latter way, while I tried to fix the AEAD error. The other two issues I had are my confusion on why a Handshake Context may contain Certificate and CertificateVerify after ServerFinished (answered by Illari at https://www.ietf.org/mail-archive/web/tls/current/msg21476.html), and a mistake in encoding draft 16 as 0x16 (https://github.com/tlswg/tls13-spec/issues/682). To summarize, the draft was clear enough for a newcomer to implement the specification, but I think some test vectors and clarification on what consists a Handshake Context might help others trying to implement the protocol. Thank you very much for the great draft, and providing answers to my issues. I am looking forward to seeing it formalized. -- Kazuho Oku _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
