[TLS] Martin Duke's Discuss on draft-ietf-tls-dtls13-41: (with DISCUSS and COMMENT)

[Martin Duke via Datatracker <[e-mail]>]

Martin Duke has entered the following ballot position for
draft-ietf-tls-dtls13-41: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

In Sec 5.8.2, it is a significant change from DTLS 1.2 that the initial timeout
is dropping from 1 sec to 100ms, and this is worthy of some discussion. This
violation of RFC8961 ought to be explored further. For a client first flight of
one packet, it seems unobjectionable. However, I'm less comfortable with a
potentially large server first flight, or a client second flight, likely
leading to a large spurious retransmission. With large flights, not only is a
short timeout more dangerous, but you are more likely to get an ACK in the
event of some loss that allows you to shortcut the timer anyway (i.e. the cost
of long timeout is smaller)

Relatedly, in section 5.8.3 there is no specific recommendation for a maximum
flight size at all. I would think that applications SHOULD have no more than 10
datagrams outstanding unless it has some OOB evidence of available bandwidth on
the channel, in keeping with de facto transport best practice.

Finally, I am somewhat concerned that the lack of any window reduction might
perform poorly in constrained environments. Granted, doubling the timeout will
reduce the rate, but when retransmission is ack-driven there is essentially no
reduction of sending rate in response to loss.

I want to emphasize that I am not looking to fully recreate TCP here; some
bounds on this behavior would likely be satisfactory.

Here is an example of something that I think would be workable. It is meant to
be a starting point for discussion. I've asked for some input from the experts
in this area who may feel differently. - In general, the initial timeout is
100ms. - The timeout backoff is not reset after successful delivery. This
allows the "discovery" in bullet 1 to be safely applied to larger flights. -
For a first flight of > 2 packets, the sender MUST either (a) set the initial
timeout to 1 second OR (b) retransmit no more than 2 packets after timeout. -
flights SHOULD be limited to 10 packets - on timeout or ack-indicated
retransmission, no more than half (minimum one) of the flight should be
retransmitted

The theory here is that it's responsive to RTTs > 100ms, but small flights can
be more aggressive, and large flows are likely to have ack-driven
retransmission.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this document -- badly needed and easy to read.

Thanks also to Bernard Adoba 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.

Sec 4.2.3: "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."

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 sn_key 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 can't be used as
address verification across connections in the way that a NEW_TOKEN 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 Record 1 has not been
acknowledged but is also not retransmitted. It appears there is an implied
handling of empty ACKs that isn't written down anywhere in Sec 7.2

Sec 9. Should there be any flow control limits on new_connection_id? Or should
receivers be free to simply drop CIDs they can'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:
https://github.com/quicwg/load-balancers/pull/106/files. Please note the rather
unfortunate third-to-last paragraph. I'm happy to take the answer that this use
case doesn'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 connection_id 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 connection_id in HelloRetryRequest even if the
client didn't offer it. Thoughts?

NITS:
5.2 s/select(HandshakeType)/select(msg_type). Though with pseudocode your
mileage may vary as to what's clearer.

5.7 s/consitute/constitute

Sec 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.