Example Handshake Traces for TLS 1.3
draft-ietf-tls-tls13-vectors-07

I read each and every octet of this document; I'd thought I'd found a typo on page 7, but I'd forgotten to carry the 1 (....and if you believe this, I've also got a very nice bridge for sale :-))

I do agree with Spencer - I think it would be very useful to even more clearly state that you really really really shouldn't use the crypto material here for anything other than testing implementations / understanding the protocol flow.
Also:
"It probably isn't a good idea to use the private key here.  If it
   weren't for the fact that it is too small to provide any meaningful
   security, it is now very well known."
doesn't actually make sense to me -- surely it is "In addition to the fact that..."? ("weren't" makes it sound like, because it is too small it isn't well known (or something!) - "If it weren't for A, then B"...)

Thanks for all the work that went into this document. I think it's very useful
to have a set of test vectors for future implementations to develop against. I
have a couple of minor comments.

---------------------------------------------------------------------------
§1:

>  Note:  Invocations of HMAC-based Extract-and-Expand Key Derivation
>     Function (HKDF) [RFC5869] are not labelled, but can be identified
>     through the use the labels used by HKDF.

This doesn't parse. Probably should say "...through the use of labels..." or
something similar.

---------------------------------------------------------------------------

§6:

>  Note that private keys for this
>  example are not included in the draft.
>
>  {client}  create an ephemeral x25519 key pair:
>
>     private key (32 octets):...

I'm not sure what to make of this. Should it say "...private RSA keys for this
example..." or something like that? It may also be useful to include a sentence
or clause explaining why the omitted private key is not useful for users of this
document.

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3562


Has anyone checked these besides MT?

COMMENTS
S 3.
>            03 05 03 06 03 02 03 08 04 08 05 08 06 04 01 05 01 06 01 02 01
>            04 02 05 02 06 02 02 02 00 2d 00 02 01 01 00 1c 00 02 40 01
>   
>      {server}  extract secret "early":
>   
>         salt:  (absent)

ARen't we using the convention 0?


S 3.
>      {server}  extract secret "handshake":
>   
>         salt (32 octets):  6f 26 15 a1 08 c7 02 c5 67 8f 54 fc 9d ba b6 97
>            16 c0 76 18 9c 48 25 0c eb ea c3 57 6c 36 11 ba
>   
>         IKM (32 octets):  81 51 d1 46 4c 1b 55 53 36 23 b9 c2 24 6a 6a 0e

You should specify Z above with the DH.


S 3.
>            64 00
>   
>         output (32 octets):  a8 0c b7 d1 5d b3 4a 17 ab b0 c2 37 65 be 68
>            c2 6d 3f 10 da 34 90 5b 09 99 47 e5 5e 37 db 17 b3
>   
>      {server}  send a Finished handshake message

Maybe include more of the finished computaitons.


S 3.
>         key output (16 octets):  26 79 a4 3e 1d 76 78 40 34 ea 17 97 d5 ad
>            26 49
>   
>         iv info (12 octets):  00 0c 08 74 6c 73 31 33 20 69 76 00
>   
>         iv output (12 octets):  54 82 40 52 90 dd 0d 2f 81 c0 d9 42

This is kind of an odd order.


S 3.
>   
>         IKM (32 octets):  81 51 d1 46 4c 1b 55 53 36 23 b9 c2 24 6a 6a 0e
>            6e 7e 18 50 63 e1 4a fd af f0 b6 e1 c6 1a 86 42
>   
>         secret (32 octets):  5b 4f 96 5d f0 3c 68 2c 46 e6 ee 86 c3 11 63
>            66 15 a1 d2 bb b2 43 45 c2 52 05 95 3c 87 9e 8d 06

Aren't these the same as the server too?


S 3.
>         key output (16 octets):  c6 6c b1 ae c5 19 df 44 c9 1e 10 99 55 11
>            ac 8b
>   
>         iv info (12 octets):  00 0c 08 74 6c 73 31 33 20 69 76 00
>   
>         iv output (12 octets):  f7 f6 88 4c 49 81 71 6c 2d 0d 29 a4

This is the same as the server write side, right?


S 3.
>         server read traffic keys)
>   
>      {client}  derive read traffic keys for application data (same as
>         server write traffic keys)
>   
>      {client}  calculate finished "tls13 finished":

This isn't calculating the finished but rather the finished keys.


S 4.
>         secret (32 octets):  04 8b 40 aa 09 ff d4 c6 76 9c 54 1a 2f 46 e2
>            84 66 06 f7 0d 62 a6 15 97 77 29 c5 b2 81 c7 e7 15
>   
>      {client}  send a ClientHello handshake message
>   
>      {client}  calculate finished "tls13 finished":

You should label this as the binder.


S 4.
>         output (32 octets):  a8 19 28 e3 08 5c 3a 85 63 ed 82 2d a9 af 7a
>            b7 1a c5 43 2a 5f 9d 1e 6f 71 32 f1 8b 36 e2 c7 05
>   
>      {client}  send handshake record:
>   
>         payload (512 octets):  01 00 01 fc 03 03 88 09 d2 a3 9b f9 ae b3

You should explain why this is 512


S 4.
>            36 db da 6a 62 6f 02 70 e2 0e eb c7 3d 6f ca e2 b1 a0 da 12 2e
>            e9 04 2f 76 be 56 eb f4 1a a4 69 c3 d2 c9 da 91 97 d8 2f d3 99
>            32 00 21 20 3c e6 69 de de c4 4e 5e 75 53 8f cc ab 3d b0 45 fb
>            5d 21 01 19 99 e1 45 12 ee 3a b3 5f 2a f4 e9
>   
>         ciphertext (517 octets):  16 03 01 02 00 01 00 01 fc 03 03 88 09

I should have noted this earlier, but it's not really ciphertext.


S 5.
>            f5 71 06 36 c0 5b 88 ab a0 35 38 0c 00 2b 00 03 02 03 04 00 0d
>            00 20 00 1e 04 03 05 03 06 03 02 03 08 04 08 05 08 06 04 01 05
>            01 06 01 02 01 04 02 05 02 06 02 02 02 00 2d 00 02 01 01 00 1c
>            00 02 40 01
>   
>      {server}  send a ServerHello handshake message

Maybe note that this is a HRR

Why is it really necessary to publish the test vectors in an RFC?

Thank you folks for producing this document. I have two cynical observations, so please decide how cynical you want to be, and do the right thing.

I think 

8.  Security Considerations

   It probably isn't a good idea to use the private key here.  If it
   weren't for the fact that it is too small to provide any meaningful
   security, it is now very well known.

is awesome, but I remember that the SIP community spent a couple of decades with implementers who coded to call flows and read the protocol specifications as a last resort. You might consider saying this at the beginning of Section 2, because it's a long way from page 2, to page 60.

Section 8 is really polite ("probably isn't a good idea" might be true, but I bet "is a horrible idea" is equally true!), but do the right thing, of course!