Subject: Re: [TLS] Last Call: <draft-ietf-tls-tls13-vectors-06.txt> (Example Handshake Traces for TLS 1.3) to Informational RFC

From: Mark O <[email-masked]>
Date: Fri, 27 Jul 2018 16:57:57 +0000

A couple of comments on draft-ietf-tls-tls13-vectors-06:
Ordering of messages:

  *   Whenever the steps '{server}  derive secret "tls13 c hs traffic":' and '{server}  derive secret "tls13 s hs traffic":' appear, this is corresponding to the steps in the second phase of the key schedule (section 7.1 of tls13-28)
  *   To complete these you need to have the encoded ServerHello message (as seen in 'Derive-Secret(., "c hs traffic", ClientHello...ServerHello)').
  *   The description of the ServerHello message doesn't come until several steps later. Someone using the test vectors to create unit tests would need to look ahead to the ServerHello payload (after '{server}  send handshake record:', starting with 'payload (90 octets):  02 00 00') before they can recreate the steps above.
Coalescence of records:
There are several examples where multiple messages are shown concatenated, both in their payload and ciphertext forms, which makes it much harder to test them. Concatenating them (or not) has no effect on the protocol, so it's not a requirement. It would be helpful to split out the messages so that it's clearer which bytes belong to which message. The first example of this is after "{server}  send a EncryptedExtensions handshake message", "{server}  send a Certificate handshake message", "{server}  send a CertificateVerify handshake message", and "{server}  send a Finished handshake message"; starting with "payload (657 octets):  08 00 00".

  *   Mark

This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to [email-masked]

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Jul 2018 11:02:05 +1000

Thanks Mark,

I hadn't recorded the messages individually because it was a little
tricky, but by doing so both of your concerns should be addressed (at
a modest cost of 7 extra pages of hex).

For example, this now shows:

   {server}  send a ServerHello handshake message

      ServerHello (90 octets):  02 00 00 56 03 03 77 bd a6 37 17 c6 c7
         06 9e ae bc df d0 49 d9 c9 07 ca 6c d4 7e 87 8f 4e 0c 26 86 07
         37 1d 71 4f 00 13 01 00 00 2e 00 33 00 24 00 1d 00 20 37 b6 e5
         9f 38 84 d0 51 93 52 d9 48 cb 26 20 d3 c9 2f 61 5e 8e e4 17 eb
         d0 f1 69 e4 6e fe 0b 72 00 2b 00 02 03 04

   {server}  derive secret for handshake "tls13 derived":

I haven't pushed a new revision because it is currently under review
by the IESG, but will do so at the next opportunity.  You can see a
preview here (noting that this uses the draft version identifier of
0x7f1c rather than the final 0x0304):
https://tlswg.github.io/draft-ietf-tls-tls13-vectors/draft-ietf-tls-tls13-vectors.html
On Sat, Jul 28, 2018 at 2:58 AM Mark O
<Mark.O=[email-masked]> wrote:
> Whenever the steps ‘{server}  derive secret "tls13 c hs traffic":’ and ‘{server}  derive secret "tls13 s hs traffic":’ appear, this is corresponding to the steps in the second phase of the key schedule (section 7.1 of tls13-28)
> To complete these you need to have the encoded ServerHello message (as seen in ‘Derive-Secret(., "c hs traffic", ClientHello...ServerHello)’).
> The description of the ServerHello message doesn’t come until several steps later. Someone using the test vectors to create unit tests would need to look ahead to the ServerHello payload (after ‘{server}  send handshake record:’, starting with ‘payload (90 octets):  02 00 00’) before they can recreate the steps above.
>
> Coalescence of records:
> There are several examples where multiple messages are shown concatenated, both in their payload and ciphertext forms, which makes it much harder to test them. Concatenating them (or not) has no effect on the protocol, so it’s not a requirement. It would be helpful to split out the messages so that it’s clearer which bytes belong to which message. The first example of this is after "{server}  send a EncryptedExtensions handshake message", "{server}  send a Certificate handshake message", "{server}  send a CertificateVerify handshake message", and "{server}  send a Finished handshake message"; starting with "payload (657 octets):  08 00 00".
>
> Mark
>
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls