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

[Ballot comment]
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

[Ballot comment]
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"...)

[Ballot comment]
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.

[Ballot comment]
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!

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-tls-tls13-vectors-06, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-07-24):

From: The IESG
To: IETF-Announce
CC: tls-chairs@ietf.org, Sean Turner , draft-ietf-tls-tls13-vectors@ietf.org, tls@ietf.org, sean@sn3rd.com, kaduk@mit.edu
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Example Handshake Traces for TLS 1.3) to Informational RFC


The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'Example Handshake Traces for TLS 1.3'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-07-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  Examples of TLS 1.3 handshakes are shown.  Private keys and inputs
  are provided so that these handshakes might be reproduced.
  Intermediate values, including secrets, traffic keys and IVs are
  shown so that implementations might be checked incrementally against
  these values.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

This document provides examples TLS 1.3 handshakes.  Private keys and inputs are provided so that these handshakes might be reproduced with are shown.  As the examples are illustrative the draft is intended to be Informational.

Sean Turner is the Document Shepherd.
Benjamin Kaduk is the responsible Area Director.

2. Review and Consensus

There's always interest in having examples and this draft fills that gap for TLS, which some would say have been sorely need for a very long time.  While there wasn't a lot of list traffic on this draft, you could argue that there's lots of review because the vectors are automatically generated using the NSS test suite.  NSS is used to do interop with a number of implementations.

3. Intellectual Property

I confirmed with Martin that his direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79.

4. Other Points

There are no DOWNREFs; there is only one normative reference and it's to the TLS1.3 RFC.

There are also no IANA considerations.