[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    [TLS] (TLS) RFC5246 - 7.2.1. Closure Alerts - Applied to (DTLS) RFC 6347
From:       Achim Kraus <achimkraus () gmx ! net>
Date:       2021-07-06 14:33:34
Message-ID: 67b202fe-5f31-f7af-121c-48d68ff8f90d () gmx ! net
[Download RAW message or body]

Hi List,

I currently try to get some clarity about usage of DTLS 1.2.

One topic, which comes across, is the

(TLS) RFC5246 - 7.2.1.  Closure Alerts:

 > The client and the server must share knowledge that the connection is
ending in order to avoid a truncation attack.

AFAIK, the protection of the "close_notify" is build on the grants of
TCP. On receiving the "close_notify" in the TLS layer, TCP ensures that
all data before was also passed to TLS. If something would be missing,
the "close_notify" will not be passed to TLS.
(e.g.
https://www.usenix.org/system/files/conference/woot13/woot13-smyth.pdf)

Applying this mechanism to DTLS and UDP, seems for me breaking that
protection. UDP doesn't grant the order nor the completeness and so the
"close_notify" mechanism stops working.

So, are there considerations, if/how a "close_notify" can provide that
protection for DTLS as it does for TLS?
It's not about to protect DTLS in general against message loss (for me,
that must be addressed in the layers above), it's about, how a
"close_notify" can provide that protection, or not.

I found:
https://mailarchive.ietf.org/arch/msg/tls/VNrSd7gv7uFjJNZH6frBt5lb57A/
https://mailarchive.ietf.org/arch/msg/tls/FJM6OHfvLJP_pF5uUcR86pzrdYo/

But I miss a explicit statement about the "truncation attack".
Or is that too obvious?

best regards
Achim Kraus

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[prev in list] [next in list] [prev in thread] [next in thread]