Ben Kaduk's review requested a number of example fixes.

[ekr]

Section 5.6

Numbering the flights like this with absolute identifiers could be quite useful, but the current formulation leaves a bit to be desired, since we don't have much consistency in numbering across the various scenarios. If we are going to have to fall back to "client's second flight" to refer to the given scenario in question, then perhaps it is not worth giving different numbers to client vs server flight. Figure 6: Message flights for a full DTLS Handshake (with cookie exchange)

I'd consider (but possibly not actually end up) noting that flights 2 and 3 are skipped when the cookie exchange is not needed.

Filed under "need to fix examples"

It's also a bit surprising to see pre_shared_key as an important/noteworthy extension in the sample full (i.e., non-resumption) handshake alongside key_share.

Filed under "need to fix examples"

       Figure 8: Message flights for the Zero-RTT handshake

Why do we include psk_key_exchange_modes for the zero-RTT example but not the other ones? I don't think it's particularly more notable for 0-RTT than other handshakes.

Filed under "need to fix examples"

Note: The application data sent by the client is not included in the timeout and retransmission calculation.

This note also appears a little out of place here, since we don't really get into timeout and retransmission until the next section

Filed under "need to fix examples"

Section 5.7.1

The state machine says "receive record, send ACK"; does that hold for all records? (I guess maybe it does, for all records that do not complete a flight.)

Filed under "need to fix examples"

Section 6

Figure 11 seems to show that the initial ServerHello has message_seq=1, but §5.2 says that "[t]he first message each side transmits in each association always has message_seq = 0". Which one is it? (A change here would affect all the server's messages except the final ACK.)

It's 0. I think this example may have had an HRR. Will fix. Filed under "need to fix examples"

Also in Figure 11, the client has to send an empty ACK because Record 1 could only be ACK'd in epoch 2, but the client doesn't have the epoch 2 keys yet. We should at least forward-reference §7.1 and acknowledge (pun intended) that the empty ACK is correct in this case even if we don't go into the details of why it is correct yet.

Filed under "need to fix examples"

The use of the ACK for the second case is mandatory for the proper functioning of the protocol. For instance, the ACK message sent by the client in Figure 12, acknowledges receipt and processing of record 2 (containing the NewSessionTicket message) and if it is not

The records in Figure 12 are not labeled (anymore?).

Filed under "need to fix examples"

[ekr]

@hannestschofenig can you take these?

[hannestschofenig]

PRs for the example updates are https://github.com/tlswg/dtls13-spec/pull/188 https://github.com/tlswg/dtls13-spec/pull/190 https://github.com/tlswg/dtls13-spec/pull/191

[ekr]

Fixed