Hi Martin, 2016-10-13 16:07 GMT+09:00 Martin Thomson <martin.thom...@gmail.com>: > 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?
Yes. That would have helped. Especially it would be great if there was an example of generating AEAD key and IV from the handshake messages. The logic (e.g. HKDF-Expand-Label and Derive-Secret defined in section 7.1) and the parameters that the logic takes as input are defined in different sections of the draft. For example, you have to look at section 2 and 7.3 to find out the correct parameters. So I had to concentrate on getting all them together to form an interoperable code. I won't say it was hard, but having a test vector that goes though the process step by step would have helped a lot. > 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. Thank you for the offer. I added my implementation to the wiki. > > > 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 -- Kazuho Oku _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
