Skip to main content

Last Call Review of draft-ietf-ace-extend-dtls-authorize-05
review-ietf-ace-extend-dtls-authorize-05-secdir-lc-reddyk-2023-01-19-00

Request Review of draft-ietf-ace-extend-dtls-authorize
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2023-01-24
Requested 2023-01-10
Authors Olaf Bergmann , John Preuß Mattsson , Göran Selander
I-D last updated 2023-01-19
Completed reviews Secdir Last Call review of -05 by Tirumaleswar Reddy.K (diff)
Opsdir Last Call review of -06 by Yingzhen Qu (diff)
Genart Last Call review of -05 by Paul Kyzivat (diff)
Assignment Reviewer Tirumaleswar Reddy.K
State Completed
Request Last Call review on draft-ietf-ace-extend-dtls-authorize by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/IHN42v6eqjoepfODXwQNJRiO_Ww
Reviewed revision 05 (document currently at 07)
Result Has nits
Completed 2023-01-13
review-ietf-ace-extend-dtls-authorize-05-secdir-lc-reddyk-2023-01-19-00
Reviewer: Tirumaleswar Reddy
Review result: Ready with Nits

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document updates the CoAP-DTLS profile for ACE by specifying
that the profile applies to TLS as well as DTLS.

Comments below:

1) In case the ace_profile parameter indicates the
use of the DTLS profile for ACE as defined in [RFC9202],
the Client MAY try to connect to the Resource Server via TLS, or try TLS
and DTLS in parallel
to accelerate the connection setup. It is up to the implementation to
handle the case where the RS reponds to both connection requests.

Comment> DTLS should be given higher precedence than TLS as CoAP over UDP
is the first choice of implementation.

2) As resource-constrained devices are not expected to
support both transport layer security mechanisms, a Client
that implements either TLS or DTLS but not both might fail in establishing
a secure communication channel with the Resource Server altogether.

Comment> If the IoT device cannot support both TLS and DTLS , is it
mandatory for the device to support TLS ?
Otherwise, if a device supports DTLS only and a firewall blocks the
communication channel over UDP with the RS, it will fail to function.

Cheers,
-Tiru