Re: [TLS] Eric Rescorla's No Objection on draft-ietf-tls-tls13-vectors-06: (with COMMENT)

[Martin Thomson <[e-mail]>]

I'm not excited by editing this, but can do so later.  Until all
comments have been addressed, I'd like to retain the ability to
regenerate the draft as necessary.

I've changed the 0 thing, and am OK with the occasional ordering oddity.
On Wed, Aug 1, 2018 at 10:16 PM Eric Rescorla <[e-mail]> wrote:
>
>
>
> On Tue, Jul 31, 2018 at 10:03 PM, Martin Thomson <[e-mail]> wrote:
>>
>> Thanks for checking on this.  I had a couple of bugs with
>> deduplication that made some of the values unnecessarily repetitious.
>> There are a few values around Finished calculation that I added (the
>> values were there already, but you had to extract them from other
>> values).
>>
>> A preview is available (though that uses the draft version numbers and
>> it doesn't have the Finished values because those changes haven't made
>> it into NSS yet):
>> https://tlswg.github.io/draft-ietf-tls-tls13-vectors/draft-ietf-tls-tls13-vectors.html
>>
>> The diff isn't particularly enlightening because the handshakes are
>> completely different each time, but you should be able to find the
>> specific changes if you look for them.
>>
>> On Wed, Aug 1, 2018 at 9:14 AM Eric Rescorla <[e-mail]> wrote:
>> > Has anyone checked these besides MT?
>>
>> I wasn't aware that openssl was using them, but Kazu provided a ton of
>> feedback when building this.
>>
>> > COMMENTS
>> > >         salt:  (absent)
>> >
>> > ARen't we using the convention 0?
>>
>> Yes, but "salt: 0" is hard to distinguish from "salt (1 octet): 00",
>> so I decided to be more explicit.  I built special code for this, so
>> it could say anything; what would you prefer it to say?   "(zero)"?  I
>> tend to think that this is OK, but I don't care what it says.
>
>
> Yes, I think 0 would be better.
>
>>
>> > 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.
>>
>> The IKM is Z.  I didn't see much point in repeating it.  Besides,
>> because this is driven from logging, it would require a whole bunch of
>> new logging to support recording of the key exchange.
>
>
> I'm suggesting you manually edit the draft.
>
>
>>
>> > S 3.
>> > >      {server}  send a Finished handshake message
>> >
>> > Maybe include more of the finished computaitons.
>>
>> Yeah, the computed HMAC wasn't logged, so I missed it.  If you are
>> willing to review the change to NSS to log the result
>> (https://phabricator.services.mozilla.com/D2589), I can include that
>> in the block explicitly, which is better.
>>
>> > 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.
>>
>> I don't know how else to order this.
>
>
> It's odd that we're computing the handshake keys after the application keys.
> It's just an oddity in NSS.
>
>>
>> > 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.
>>
>> Done.  I've added the other inputs to this as well.
>>
>> > 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
>>
>> I don't think that it's appropriate to document all the design choices
>> here; that this is padded is one from many.  (It's also very hard to
>> pick this sort of exceptional condition out for special treatment.)
>
>
> What's relevant is that the previous one is padded and this is not. I think
> that's a very appropriate thing to note. As for special treatment, again,
> you can edit the output. Once this is approved by the IESG, you're not
> going to be able to regenerate it anyway.
>
>
> -Ekr
>