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?  and you would be
most welcome to n join the next hackathon in Seoul.

On 13 Oct 2016 5:17 PM, "Kazuho Oku" <> 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 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
> 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
>, and
> a mistake in encoding draft 16 as 0x16
> (
> 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 mailing list

Reply via email to