Draft: draft-ietf-tls-dtls13

Commentary: Thanks for this document -- badly needed and easy to read . Thanks also to   for his recent tsvart review . I support his comments . COMMENTS : Sec 2 . It might be useful to introduce the term " epoch " in the glossary , for those who read this front to back .  4.2.3 : " The encrypted sequence number is computed by XORing the leading bytes of the  with the sequence number . Decryption is accomplished by the same process . " The text is unclear if the XOR is applied to the expanded sequence number or merely the 1 - 2 octets on the wire . I presume it 's the latter , but this should be clarified . Sec 4.2.3 : It 's implied here that the snkey rotates with the epoch . As this is different from QUIC , it 's probably worth spelling out . Sec 5.1 is a bit vague about the amplification limit ; why not at least RECOMMEND 3 , as we 've converged on this elsewhere ? Sec 5.1 . Reading between the lines , it 's clear that the cookie ca n't be used as address verification across connections in the way that a NEWTOKEN token is . It would be good to spell this out for clients -- use the resumption token or whatever instead . Sec 7.2 " As noted above , the receipt of any record responding to a given flight MUST be taken as an implicit acknowledgement for the entire flight . " I think this should be s / entire flight / entire previous flight ? Sec 7.2 " Upon receipt of an ACK that leaves it with only some messages from a flight having been acknowledged an implementation SHOULD retransmit the unacknowledged messages or fragments . " This language appears inconsistent with Figure 12 , where   has not been acknowledged but is also not retransmitted . It appears there is an implied handling of empty ACKs that is n't written down anywhere in Sec 7.2 Sec 9 . Should there be any flow control limits on newconnectionid ? Or should receivers be free to simply drop CIDs they ca n't handle ? It might be good to specify . Finally , a really weird one . Reading this document and references to connection ID prompted to me to think how QUIC - LB could apply to DTLS . The result is here : Please note the rather unfortunate third - to - last paragraph . I 'm happy to take the answer that this use case does n't matter , since I made it up today . But if it does , it would be very helpful if ( 1 ) DTLS 1.3 clients MUST include a connectionid extension in their ClientHello , even if zero length , and/or ( 2 ) this draft updated 4.1.4 of 8446 to allow the server to include connectionid in HelloRetryRequest even if the client did n't offer it . Thoughts ? NITS : 2 s / select(HandshakeType)/select(msg_type ) . Though with pseudocode your mileage may vary as to what 's clearer . 7 s / consitute / constitute  5.7 In table 1 , why include one ACK in the diagram but not the other ? It 's clear from the note , but the figure is a weird omission . 
 Addressed in
Paragraph (version B):
epoch: one set of cryptographic keys used for encryption and
decryption.
Paragraph (version A):
The reader is assumed to be familiar with the TLS 1.3 specification.
As in TLS 1.3 the HelloRetryRequest has the same format as a
ServerHello message but for convenience we use the term
HelloRetryRequest throughout this document as if it were a distinct
message.
Paragraph (version B):
The reader is assumed to be familiar with TLS13.  As in TLS 1.3, the
HelloRetryRequest has the same format as a ServerHello message, but
for convenience we use the term HelloRetryRequest throughout this
document as if it were a distinct message.
Paragraph (version A):
The encrypted sequence number is computed by XORing the leading bytes
of the Mask with the sequence number.  Decryption is accomplished by
the same process.
Paragraph (version B):
The encrypted sequence number is computed by XORing the leading bytes
of the Mask with the on-the-wire representation of the sequence
number.  Decryption is accomplished by the same process.
Paragraph (version A):
DTLS servers SHOULD perform a cookie exchange whenever a new
handshake is being performed.  If the server is being operated in an
environment where amplification is not a problem, the server MAY be
configured not to perform a cookie exchange.  The default SHOULD be
that the exchange is performed, however.  In addition, the server MAY
choose not to do a cookie exchange when a session is resumed or, more
generically, when the DTLS handshake uses a PSK-based key exchange.
Servers which process 0-RTT requests and send 0.5-RTT responses
without a cookie exchange risk being used in an amplification attack
if the size of outgoing messages greatly exceeds the size of those
that are received.  A server SHOULD limit the amount of data it sends
toward a client address before it verifies that the client is able to
receive data at that address.  A client address is valid after a
cookie exchange or handshake completion.  A server MAY apply a higher
limit based on heuristics, such as if the client uses the same IP
address as the connection on which the cookie was created.  Clients
MUST be prepared to do a cookie exchange with every handshake.
Paragraph (version B):
DTLS servers SHOULD perform a cookie exchange whenever a new
handshake is being performed.  If the server is being operated in an
environment where amplification is not a problem, the server MAY be
configured not to perform a cookie exchange.  The default SHOULD be
that the exchange is performed, however.  In addition, the server MAY
choose not to do a cookie exchange when a session is resumed or, more
generically, when the DTLS handshake uses a PSK-based key exchange
and the IP address matches one associated with the PSK.  Servers
which process 0-RTT requests and send 0.5-RTT responses without a
cookie exchange risk being used in an amplification attack if the
size of outgoing messages greatly exceeds the size of those that are
received.  A server SHOULD limit the amount of data it sends toward a
client address to three times the amount of data sent by the client
before it verifies that the client is able to receive data at that
address.  A client address is valid after a cookie exchange or
handshake completion.  Clients MUST be prepared to do a cookie
exchange with every handshake.  Note that cookies are only valid for
the existing handshake and cannot be stored for future handshakes.
Paragraph (version A):
taken as an implicit acknowledgement for the entire flight.
Paragraph (version B):
taken as an implicit acknowledgement for the entire flight to which
it is responding.
Paragraph (version A):
Endpoints SHOULD use receiver-provided CIDs in the order they were
provided.  Endpoints MUST NOT have more than one NewConnectionId
message outstanding.
Paragraph (version B):
Endpoints SHOULD use receiver-provided CIDs in the order they were
provided.  Implementations which receive more spare CIDs than they
wish to maintain MAY simply discard any extra CIDs.  Endpoints MUST
NOT have more than one NewConnectionId message outstanding.