Extension of the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) to Transport Layer Security (TLS)
draft-ietf-ace-extend-dtls-authorize-07

# Internet AD comments for draft-ietf-ace-extend-dtls-authorize-06
CC @ekline

## Comments

### S4

* If it's up to the implementation to handle connection racing where both
  succeed should there be a comment about whether or not Early Data should
  be avoided (for non-idempotent operations)?

  Perhaps there is already text about this in the related docs?

Nits:

- Please expand RS on first use. (It’s first expanded in Section 4 but first used in Section 1.)

- “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.” Is this supposed to be one sentence, with a comma between clauses? If not, then I don’t understand the first sentence (fragment). For that matter even if you make the period into a comma, I don’t immediately see how the second clause follows causally from the first, but I’m not too bothered about this.

Thanks to Yingzhen Qu for the helpful OpsDir review: https://datatracker.ietf.org/doc/review-ietf-ace-extend-dtls-authorize-06-opsdir-lc-qu-2023-02-09/

I encourage the authors to review this, and respond to the "In case both the client and server support both TLS and DTLS, it says here “It
is up to the implementation to handle”. However it also says “the client typically first tries using DTLS”, this seems to give priority to DTLS. Please
clarify."

(Edit: Selected the NoObj position - I'd balloted, but forgotten to actually select the position...)

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.

# GEN AD review of draft-ietf-ace-extend-dtls-authorize-06

CC @larseggert

Thanks to Paul Kyzivat for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/PI2PU9rH6uMLt8nwTo5l5xtjvRg).

## Comments

### Section 1, paragraph 1
```
     [RFC9202] only specifies the use of DTLS [RFC9147] but works equally
     well for TLS [RFC8446].  
```
The use of DTLS *for what*?

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 4, paragraph 2
```
-    RS reponds to both connection requests.
+    RS responds to both connection requests.
+         +
```

#### Section 4, paragraph 3
```
-    transport layer security mechanisms.  Clients and Resource Servers
-             ^                         ^^
+    transport-layer security mechanisms, Clients and Resource Servers
+             ^                         ^
```

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

Minor level comments:

(1) p 2, sec 4.  Connection Establishment

     Clients and Resource Servers
   SHOULD support DTLS and MAY support TLS.

This seems to make successful interop a bit less likely to me.  Perhaps it would be sensible to suggest that Resource Servers SHOULD support both DTLS and TLS?


Nit level comments:

(2) p 1, sec 1.  Introduction

    UDP
   might be blocked on the path between the client and the RS, and the

Trivial nit (which the RFC editor will fix anyway), you are using RS here in the introduction before it is defined in section 4.


(3) p 2, sec 4.  Connection Establishment

   As resource-constrained devices are not expected to support both
   transport layer security mechanisms.

Another nit, this sentence doesn't stand well on its own please drop the "As" or link this sentence with the next.