[Ace] Zaheduzzaman Sarker's No Objection on draft-ietf-ace-extend-dtls-authorize-06: (with COMMENT)

[Zaheduzzaman Sarker via Datatracker <[e-mail]>]

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-ace-extend-dtls-authorize-06: No Objection

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ace-extend-dtls-authorize/



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

Thanks for working on this specification.

Like others I have also stabled upon section 4, where it says -

  "The ace_profile parameter indicates the use of the DTLS profile for ACE as
  defined in [RFC9202]. Therefore, the Client typically first tries using DTLS
  to connect to the Resource Server. If this fails the Client MAY try to
  connect to the Resource Server via TLS. The client can 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.
   As resource-constrained devices are not expected to support both transport
   layer security mechanisms. Clients and Resource Servers SHOULD support DTLS
   and MAY support TLS. A Client that implements either TLS or DTLS but not
   both might fail in establishing a secure communication channel with the
   Resource Server altogether."

It seems to me that according to RFC9202 and as it is already out in the
deployment, there is a preference of using DTLS for secure comm channel with
RS. This specification allows that TLS could also be used that MAY be supported
by some RS and clients. Hence, my understanding would be that clients with only
DTLS support SHOULD at least be able to establish secure communication channel,
and clients with only TLS support MAY also be able to secure the channel to RS.
This is however, is not the interpretation I get by reading the mentioned text
from the specification. I would actually prefer that the RS SHOULD support both
DTLS and TLS, and clients SHOULD support DTLS but MAY support TLS as well. In
that case we can do a failover to TLS or race the DTLS and TLS in parallel. 
This would maximize the use of secure channel. However, the current
recommendation might work hence no objection from me.