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=40ncsc.gov...@dmarc.ietf.org> wrote:
>
>
>
> 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 ncscinfo...@ncsc.gov.uk
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
