Change:
The security considerations of RFC7252 apply. <del> Implementations of CoAP MUST use TLS version 1.2 or higher for CoAP over TLS.  The general TLS usage guidance in RFC7525 SHOULD be followed. </del> <ins> TLS version 1.2 or higher is mandatory-to-implement and MUST be enabled by default.  An endpoint MAY immediately abort a CoAP over TLS connection that does not meet this requirement (see sec-abort) and SHOULD include a diagnostic payload. </ins> <del> Guidelines for use of cipher suites and TLS extensions can be found in I-D.ietf-dice-profile. </del> <ins> The TLS usage guidance in RFC7925 SHOULD be followed. </ins> TLS does not protect the TCP header.  This may, for example, allow an on-path adversary to terminate a TCP connection prematurely by

Discussion:
Updated ietf-dice-profile reference to RFC7925
Issue was raised to see if we should consider making TLS a must instead of a recommendation. Since most of the motivation for either TCP or WebSocket is enterprise driven, security should also be required by the party using the technology.
It is currently neither (a MUST or even a recommendation), and I have no idea why it should be. If application layer security ("object security") is in use, there is no need for TLS. In other words, Security is not an option, but using TLS for security is. (It even is in HTTP/2...) (Same argument for coap+ws vs. coap+wss.)
I do not see extra effort when enabling TCP as transport. I only see possible issues when disabling TCP as an option by making TLS as must: TLS does not work across intermediaries, so mechanisms such as object security might become popular or even pre-dominant (wild guess!). The TLS handshake might just be an obstacle that wants to be avoided then. RD or discovery in general often assumes CoAP (without S) interactions (e.g., simple registration or public lookups) The benefit for adoption, testing, and debugging when encryption can be disabled. It helped a lot for normal CoAP and the nice thing is that once it works over TCP, it is rather trivial to enable security for production by switching to TLS. (The reason why most CoAP deployments did not use CoAPS for a long time was the lack of proper DTLS 1.2 implementations. We do not have this problem for TLS.) So: -1 for making TLS a must +1 for keeping TCP
There was no interest in eliminating TCP. Zach's suggested language - TLS is mandatory to implement and on by default. Also should compare guidance in
Reopening to track potential WGLC discussion - URL
Summarizing, with my words, the latest mail duscussion on the list regarding this sentence: "TLS version 1.2 or higher is mandatory-to-implement and MUST be enabled by default." RFC7252 allows UDP or DTLS. Section 9 in RFC7252 specifies the binding to DTLS, and, given that binding, what is mandatory to implement (NoSec and RPK with a certain ciphersuite).

The analogy would be that this draft specifies CoAP over TCP, the binding to TLS and what is mandatory to implement with this binding. (Göran) Considering that CoAP over TCP may be protected on other layers than transport layer, e.g. on application layer using OSCOAP, and that a constrained device may not be able to support multiple security protocol implementations, the statement about mandating implementation of TLS should be removed. OSCOAP was not adopted at the time when the previous discussion was held and was not sufficiently understood and considered in that discussion. (Göran) It is not clear what "on by default" means. Security is a process and unless people follow the process, "switching on security" in a protocol implementation isn't giving you any. (Carsten) What does "use TLS" mean on a constrained device? I do not believe this question should be answered in the CoAP-over-TLS draft; security processes for IoT are a subject of active research, not something where we have enough solid knowledge for an MTI. (Carsten) I guess you are saying that CoAP itself is a building block and the way how IoT is used today it does not really make any sense to talk about randomly plugging things together. (Hannes) Indeed, and that means to me that "on by default", which would mean some such random plugging, is not we what can seriously recommend. (Carsten)
Doing the analogous for coap-over-tcp (and TLS) sounds very reasonable to me. In particular because there are many implementations of TLS available (as opposed to DTLS as Matthias pointed out), I don't think that it is sufficient to say "TLS must be implemented". If the spec makes TLS mandatory (to implement or/and to enable by default) it should also define which cipher suites are mandatory to implement. This is of practical importance in particular to constrained devices which probably cannot do the same sort of RSA based security as e.g. gateway components can ...
URL There are several MUSTs in that document. Do we want to turn them into SHOULDs? No. -> The TLS usage guidance in [RFC7925] applies.
Shared proposal on the mailing list - URL
CoAP MUST NOT be used with older versions of TLS.

Guidelines for use of cipher suites and TLS extensions can be found in {{I-D.ietf-dice-profile}}. This should be phrased in the positive: Implementations of CoAP MUST use TLS version 1.2 or higher for CoAP over TLS. The general TLS usage guidance in [TLSBCP] SHOULD be followed ... What is the appropriate behavior when an older version is used? For example, compare with for possible connection errors and further TLS 1.2 restrictions. An endpoint MAY immediately terminate an HTTP/2 connection that does not meet these TLS requirements with a connection error of type INADEQUATESECURITY._
One interesting question is how TLS libraries export that functionality -- can a listener be configured to only allow 1.2+? Is the actual protocol chosen signaled up?
URL
URL
This may a case where an Inadequate-Security option could be added to Abort (Signaling)?
Right. Generally we should create machinery only where the recipient of some information can react to it in a programmatic way. I don't expect a client to be automatically able to set up a new connection with a better TLS version upon reception of such an Inadequate-Security option. So I think this is better handled in a diagnostic payload, which we don't need to standardize.