On Thu, Mar 5, 2020, at 7:28 AM, Hanno Becker wrote:
> Hi Ekr,
>
> > I don't really agree with (b) for the reasons above. It introduces new
> > complications. As for (a) I believe that in practice the state that
> > must be kept is quite small (in general, there will only be no
> > retransmission at all and so you will only need one or slightly more
> > extant flight). The TLS handshake already requires you to store quite
> > a bit of state (hashes, etc.) so I'm not persuaded by this argument.
>
> DTLS 1.3 should suit the case of IoT devices and lossy IoT networks,
> together with the long-term prospect of post-quantum cryptography
> and the large cryptographic material that goes along with it. In such
> context, it is / will be important to be able to deal with excessive
> fragmentation and retransmission efficiently.
>
> Moreover, note that in the face of a PMTU change, retransmission on the
> basis of buffered opaque record content without knowledge of the
> underlying
> handshake structure doesn't work, and will require retransmission of
> the entire flight.
> This is avoided with ACKing at the handshake level, which makes
> retransmissions
> agnostic to PMTU changes.
>
> > I think we're down to a difference of technical judgement now, so
> > I'll leave it to the chairs to determine how to address this comment.
>
> It would be nice to hear some more opinions on this here, too.
>
> Thanks for the discussion,
There are two primary issues raised in this thread:
1. Lack of clarification regarding when ACKs should be sent.
2. Record-level ACKs make efficient implementations for IoT devices
harder. (draft
The latest version of the specification addresses (1) with the following
text:
~~~
record_numbers: a list of the records containing handshake messages
in the current flight which the endpoint has received and either
processed or buffered, in numerically increasing order.
Implementations MUST NOT acknowledge records containing non-
duplicative handshake messages or fragments which have not been
processed or buffered. Otherwise, deadlock can ensue.
During the handshake, ACKs only cover the current outstanding flight
(this is possible because DTLS is generally a lockstep protocol).
Thus, an ACK from the server would not cover both the ClientHello
and
the client's Certificate. Implementations can accomplish this by
clearing their ACK list upon receiving the start of the next flight.
After the handshake, ACKs SHOULD be sent once for each received and
processed record (potentially subject to some delay) and MAY cover
more than one flight.
~~~
Regarding (2), given that record-level ACKs align with QUIC and also do
not seem to be insurmountable implementation obstacles (e.g., stacks can
re-generate large handshake messages on-demand instead of buffering
them), the chairs do not think any change here is required.
Thanks,
Chris, on behalf of the chairs
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
