[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] Last Call: <draft-ietf-tls-tls13-vectors-06.txt> (Example Handshake Traces for TLS 1.3) to
From:       Martin Thomson <martin.thomson () gmail ! com>
Date:       2018-07-30 1:02:05
Message-ID: CABkgnnV02PwHPTMBnJ=XA1vTY5TnA-T+6P+YuLqsnLZsvQRMhw () mail ! gmail ! com
[Download RAW message or body]

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.uk@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 \
> ncscinfoleg@ncsc.gov.uk _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


[prev in list] [next in list] [prev in thread] [next in thread]