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
