Thanks Kazuho! Experiences like your own are critical at this stage. It is encouraging to see that there were so few problems.
As for the key schedule, EKR and I have discussed taking a dump from one of our many test cases and putting that in a draft, including private keys and all the intermediate values. It might get a bit long, so we were thinking of doing a separate companion document. Would that help you? We haven't done anything yet because the draft has been changing quite a bit, but I believe that the changes are now mostly done. I am happy to take ideas on what configurations to trace. The only thing NSS doesn't support right now is KeyUpdate (coming soon after -17 I hope). Did you want to add your implementation to the wiki? https://github.com/tlswg/tls13-spec/wiki/Implementations and you would be most welcome to n join the next hackathon in Seoul. On 13 Oct 2016 5:17 PM, "Kazuho Oku" <kazuho...@gmail.com> wrote: > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
