There's no longer an informative reference to this expired draft. Originally, it was included in the Introduction of draft-savolainen-core-coap-websockets-07.

https://core-wg.github.io/coap-tcp-tls/#max-message-size-capability-indication-option

Missed this one while simplifying the option names.

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 HTTP/2 TLS 1.2 Features 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 INADEQUATE_SECURITY.

We need to decide whether this feature is required. If not, then I don't think that it's useful to include speculative text:

Using the Capability and Settings message for version negotiation

CoAP is defined in RFC 7252 with a version number of 1. In contrast
to the message layer for UDP and DTLS, the CoAP over TCP message layer
does not send the version number in each single message. Instead,
options for the Capability and Settings message can be used to perform
a version negotiation.

At the time of writing, there is no known reason for supporting
version numbers different from 1. The details of a version
negotiation, once it is actually needed, will depend on the specifics
of the new version(s), so the present specification makes no attempt
to specify these details. However, Capability and Settings messages
have been specifically designed with a view to supporting such a
potential future need.

This is really about requests for which responses (or notifications) are outstanding (i.e., the above, as well as the ones which are to receive notifications for Observe), and the wording is wrong.

Thanks, Roland Paterson-Jones.

Michel Veillette points out that a peer that wants to use a new connection has an uncertainty whether a CSM message with capability indications will come or not, so it is hard to decide when to send the first request (either based on default capabilities or waiting for the CSM to come in). One way out of having to do arbitrary waits would be to require the exchange of a CSM message (even an option-less one) after connection setup. The burden is very low, as a minimal implementation would just need to send a constant message of 0x00 0xe1 at setup.

This requirement could be stated without giving a sequence, effectively allowing both sides to send the initial CSM in parallel, or it could give the listener the opportunity to not send its CSM until the connection opener has sent theirs, trying to avoid the need to answer right away to a connection setup -- this makes it too easy to scan for ports (OK, we also have a default port, and making scanning harder does not by itself provide any security, but it sure makes life a little harder for the attacker). (To avoid deadlock, the connection opener would not have the opportunity to wait sending the CSM.)

Captured from Ticket 387, @cabo wrote:

Section 6.2 of says:

When CoAP is exchanged over TLS port 443 then the "TLS Application Layer Protocol Negotiation Extension" [RFC7301] MUST be used to allow demultiplexing at the server-side unless out-of-band
information ensures that the client only interacts with a server that is able to demultiplex CoAP messages over port 443. This would, for example, be true for many IoT deployments where clients are pre-configured to only ever talk with specific servers.

QUESTION: Shouldn't we simply always require ALPN? The protocol should not be defined in such a way that it depends on some undefined pre-configuration mechanism. --cabo

Captured from Ticket 409:

CoAP has been designed to support small data transmissions. For device management it is, however, necessary to also deal with the transmission of larger payloads as well. Such larger payloads may be, for example, firmware/software updates.

The maximum payload size of CoAP is determined by the length field of the length field provided in the UDP header. It is ~64KB. For practical purposes the usable payload size is, however, much smaller due to performance issues introduced by fragmentation provided at the IP layer and/or adaption layers. For this reason the block-wise transfer mechanism has been defined.

Block-wise transfer is a mechanism that can be used to transfer larger payloads by chunking them into smaller parts (each part with a maximum size of 1024 bytes each). The block-wise transfer depends on CoAP and therefore uses the stop-and-wait defined in RFC 7252 (as a simple congestion control mechanism). The transfer of large payloads does, however, not block the transmission of other pending messages since they can easily be interleaved due to the nature of the block-wise transfer design.

When large payloads are transferred by CoAP over TCP then a large transfer blocks any other requests unless multiple TCP connections are opened. The question is therefore what should the CoAP over TCP state regarding the use of multiple TCP connections? Using multiple TCP connection increases RAM requirements; a single TCP connection introduces head-of-line blocking.

When CoAP over TCP is used with Block-wise transport in combination with BERT, see ​https://tools.ietf.org/html/draft-bormann-core-block-bert-00, then the previously described problem of large transfers that block other ongoing activities is (partially) mitigated. BERT changes the interpretation of the length information and changes it as a multiple of 1024 bytes (and thus increasing the size of the chunks).

The question is therefore whether CoAP over TCP should recommend the use of Block-wise Transfer for large file transfers and incorporate BERT into the CoAP over TCP draft.

(I would like to thank Achim Kraus for raising this issue during the OMA face-to-face meeting.)

https://www.ietf.org/mail-archive/web/core/current/msg08053.html

Cl.6.2: This indicates ABNF is used for the definitions. However clause 6.1.1 and 6.1.2 make no mention of the ABNF syntax or reference to RFC3986. The descriptions of the definitions of the URI schemes in 6.2, 6.1.1 and 6.1.2 should be harmonised.

This could be more consistent. Currently, coap+tcp and coaps+tcp rely on references to coap and coaps in RFC7252:

The semantics defined in [RFC7252], Section 6.1, apply to this URI scheme, with the following changes

and require that the reader is also familiar with https://tools.ietf.org/html/rfc7252#section-6

The syntax of the "coap" and "coaps" URI schemes is specified in this
section in Augmented Backus-Naur Form (ABNF) [RFC5234]. The
definitions of "host", "port", "path-abempty", "query", "segment",
"IP-literal", "IPv4address", and "reg-name" are adopted from
[RFC3986].

Capturing embedded issues in #2:

[I-D.ietf-core-block] uses a message size of maximum 1024 bytes and this specification extends this maximum size to 1024 KiB (= 1 MiB) by re-interpreting the length information.

@cabo wrote:
1 MiB is an arbitrary limit. This will be fixed if we have something like Max-Message-Size in the signalling draft.

https://www.ietf.org/mail-archive/web/core/current/msg08053.html

Cl.8.5: The section references both [RFC7595] and [RFC4395]. RFC7595 obsoletes RFC4395.

Hi,

Is there an error, or is there a reason why the longer lengths are calculated with minus N bytes. The length field is always followed by code and token. What is the reason that e.g. 269 bytes would be subtracted from the option/payload length? The message header fixed length can be calculated from token length, so the option/payload length could be MAX unsigned 16-bit?

13:
: An 8-bit unsigned integer follows the initial byte and indicates
the length of options/payload minus 13.

14:
: A 16-bit unsigned integer in network byte order follows the
initial byte and indicates the length of options/payload minus
269.

15:
: A 32-bit unsigned integer in network byte order follows the
initial byte and indicates the length of options/payload minus
65805.

https://www.ietf.org/mail-archive/web/core/current/msg08053.html

Cl. 8.2: The text of 12.2/RFC7252 indicates a number of criteria that must be included for registration. The options in the tcp draft don't address all the points. Some criteria aren't relevant but if 12.2 is referenced then they need to be discussed.

I'm finding "CoAP over protocol" to be too verbose - especially in text that references or compares multiple protocol bindings. Can we agree on a shorthand?

• CoAP protocol such as CoAP UDP, CoAP TCP/TLS, CoAP WebSockets
• CoAP+protocol such as CoAP+UDP, CoAP+TCP/TLS, CoAP+WebSockets

Consider either removing the UDP to TCP gateway section (https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-05#section-2.2) or merging into another section as an example. Given the differences in message format in UDP vs TCP, this is a topic that may be useful as an example, but left as an implementation detail of a gateway.

Capturing TBD in https://tools.ietf.org/html/draft-bormann-core-coap-sig-02#section-10.1

In Security Considerations:

TLS does not protect the TCP header. This may, for example, allow an
on-path adversary to terminate a TCP connection prematurely by
spoofing a TCP reset message.

This seems non-specific to coap-tcp-tls. I propose that it be removed.

https://www.ietf.org/mail-archive/web/core/current/msg08053.html

Cl.4.5/4.6: The text mentions a "diagnostic payload", is some standard envisaged for this or is it implementation dependent?

This is implementation dependent, although it might be helpful to adapt or
reference - https://tools.ietf.org/html/rfc7252#section-5.5.2

https://www.ietf.org/mail-archive/web/core/current/msg08053.html

General - It's not clear "how" mandatory the use of the CSM is. Clause 2.3 on TCP/TLS indicates that the CSM message must be sent at the start of the connection. Clause 3.1 on Websockets makes no mention of CSM messages. Clause 4.3 indicates that the CSM MUST be sent at the start of the connection also and makes no distinction between TCP/TLS and Websockets. Clause 2.3 also indicates that the connection must be aborted if the CSM is missing or invalid as the first message on the connection. Given the discussion about address changes does more information need to be provided what start of connection means?

Capturing TBD in https://tools.ietf.org/html/draft-bormann-core-coap-sig-02#section-10.2

Observe RFC7641, 3.5

If a client does not recognize the token in a confirmable
notification, it MUST NOT acknowledge the message and SHOULD reject
it with a Reset message; otherwise, the client MUST acknowledge the
message as usual. In the case of a non-confirmable notification,
rejecting the message with a Reset message is OPTIONAL.

3.6

When the server then
sends the next notification, the client will not recognize the token
in the message and thus will return a Reset message.

May be I have overseen a already provided solution (issue #5 ?).
In my opinion, a client MUST use a GET with OBSERVE 1 in cases of UDP/RST.

https://www.ietf.org/mail-archive/web/core/current/msg08053.html

Cl.8.5: I think it would be easier for IANA if the coaps+tcp and coap+tcp URI schemes were described like the websockets ones in 8.5.1 and 8.5.2.

This is another case with a heavy dependency on RFC7252 references.

In Section 4.3.1 - It has the same restrictions as the Uri-Host Option (Section 5.10 of [RFC7252] ...

This should be Section 5.10.1

https://www.ietf.org/mail-archive/web/core/current/msg08053.html

Cl.4.3: "Both capability and settings options are cumulative. ... An option that is sent might override a previous value for the same option. The option defines how to handle this case if needed." The options in 4.3.1, 4.3.2 and 4.3.3 don't say if this is possible.

Since the signaling section originated in:

https://tools.ietf.org/html/draft-bormann-core-coap-sig-02

@cabo - can you clarify your original intentions for this case?

Another bike shed, but I think we were trying to make the "communication security is active" part visible as "coaps+...", and we should do it here, too.

In the Section 3.4 Connection Health, the intent of this statement is unclear:

There is no way to retransmit a request without creating a new one.
Re-registering interest in a resource is permitted, but entirely
unnecessary.

Currently, the draft separates out the main sections for CoAP over TCP and CoAP over WebSockets. (URIs and IANA details are merged). After we complete the entire merge, Klaus suggests
that we review the material to see if it makes more sense (due to redundant material) to have something more like:

Opening Handshake

• CoAP+TCP
  -CoAp+WebSockets

Message Format

• CoAP+TCP
  -CoAp+WebSockets

I definitely agree that sections like message transmission are redundant. Other sections like message format are quite different. It may be confusing for readers if TCP message format was followed by WebSockets message format - almost but entirely unlike.

Replacing "CoAP over TCP, TLS and Websockets" with "CoAP over reliable transports" is a good idea to reduce repetition. I feel it might be a good idea to clarify when we refer to reliable transports, that we actually refer to stream-based reliable transports.

Datagram-based reliable transports (eg DCCP, QUIC, etc) exist, which render the Message Framing layer in Figure 1 unnecessary. I'm not advocating that we run CoAP over QUIC, DCCP etc but perhaps clarification would be wise.

The draft header indicates that this document updates RFC7641, but the abstract doesn't seem to mention this, which it should.

There needs to be guidance about the intersection of WebSocket Ping-Pong and Signaling Ping-Pong.

In Section 4.4 Ping and Pong Messages:

Upon receipt of a Ping message, a single Pong message is returned with the identical token.

This should be MUST be returned ?

Currently section 1 motivates why TCP as a transport is needed, but doesn't motivate why using COAP (as opposed to HTTP/2) over TCP is desirable. Such motivation should be added, since there's a document proposed in httpbis (draft-montenegro-httpbis-h2ot) to do an HTTP/2 profile for IoT and hence seems to target the same use cases. So additional text should be added explaining the rationale for using coap even when going over tcp.

Both capability and and setting options are cumulative ... An option that is given might override a previous value for the same option; the option defines how to handle this, if needed.

My model for options is simpler. New options replace existing options. The value of an option is the last value received by the peer.

What does cumulative mean in the current text and how does it relate to might override.?

https://www.ietf.org/mail-archive/web/core/current/msg08053.html

Cl.8.2: IANA is requested to create a sub-registry for signaling options similar to the CoAP Option Numbers Registry (Section 12.2 of [RFC7252]), with the single change that a fourth column is added to the sub-registry that is one of the codes in the Signaling Codes subregistry (Section 8.1).

The table 2 below isn't correct as it includes names not the signal codes from Table 1

These labels are confusing and should be rewritten more in the style of RFC6455 with "Length" and "Extended Length" for clarity.

Captured from Ticket 393:

There needs to be a section on how resources can be observed over TCP/TLS. Questions include:

• Do servers need to include a sequence number in notifications, given that TCP/TLS provides reliable, in-order delivery?
• How do servers throttle the stream of notifications when the resource changes its state more frequently than the server can send notifications?
• Does a client have to re-register its interest in a resource if it hasn't received a notification for a while but the connection is still up?

https://www.ietf.org/mail-archive/web/core/current/msg08053.html

Cl.4.3.1: For TLS and Websocket I take the comments to mean that the Server-Name setting option shouldn't be used, or?

Based on the related issue - https://trac.ietf.org/trac/core/ticket/391, my perception was that this feature was intended for CoAP over TCP.

I did update the use of "initial value":

For TLS, the initial value for the Server-Name Option is given by the
SNI value.

For Websockets, the initial value for the Server-Name Option is given
by the HTTP Host header field.

to "base value":
6ea12a7

As noted in https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-05#section-4.3:

Base values are listed below for CSM Options. These are the values
for the Capability and Setting before any Capability and Settings
messages send a modified value.

But I'd also note that https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-05#section-7.1 is somewhat
ambiguous about "cannot be used ..."

o SNI vs. Server-Name: Any security negotiated in the TLS handshake
is for the SNI name exchanged in the TLS handshake and checked
against the certificate provided by the server. The Server-Name
Option cannot be used to extend these security properties to the
additional server name.

@cabo - can you clarify your intentions for this case?

RFC7252 has Table 4 for Options which includes:

• Critical
• Name
• Format
• Length
• Default

A similar table should be added for Signaling Options at a glance.

https://www.ietf.org/mail-archive/web/core/current/msg08091.html

This document assumes that readers are familiar with the terms and concepts that are used in [RFC6455], [RFC7252], and [RFC7641].

and RFC 7959.

With the merge of websockets-07, the scope of coap-tcp-tls is extended to include CoAP over WebSockets. The draft title should reflect that change in scope.

@cabo wrote:

Let's also add a Contributors section (7322, 4.11.) after that (hmm,
that's what 7322 says; I'd put it before the acknowledgements, but then
with the 7322 placement it's close to Authors' addresses) and move the
inactive authors there; just make it look like the items in the authors'
addresses.

@cabo wrote:

Hmm, setting a default value for Max-Message-Size means that the option is virtually present in any CSM message, setting that value. In other words, an empty CSM resets Max-Message-Size to 1152. That is probably not what we want.

It is probably best to point out that pitfall when introducing CSM options -- they never should have default values (the settings expressed by these options very well can).

The original text in sig-02:

As per Section 4.6 of [RFC7252], the default value (and the value used when this Option is not implemented) is 1152.

Could you clarify what you're proposing? I'm also still unclear about this notion of empty CSM(s) resetting all options to default values.

In #28, there was a dissent about whether a cocoa reference is needed. I'm capturing the text. If cocoa is adopted as a working group item, then we can discuss adding before WGLC.

informative:
I-D.bormann-core-cocoa: cocoa

And from the Introduction:

Some environments may also benefit from the ability of TCP to exchange larger payloads, such as firmware images, without application layer segmentation and to utilize the more sophisticated congestion control capabilities provided by many TCP implementations.

Note that there is ongoing work to add more elaborate congestion control to CoAP as well, see {{-cocoa}}.)

Both capability indication options and setting options are cumulative, i.e., a capability message without any option is a no-operation (and can be used as such).

Could you clarify the meaning/intent of this text?

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.

When I submitted the original pull request, I also posed a question on the mailing list but did not receive a response.

One open question is whether we want to allow a client to immediately send messages after sending its CSM without waiting for the server CSM. This would be similar to HTTP/2:

https://tools.ietf.org/html/rfc7540#section-3.5

To avoid unnecessary latency, clients are permitted to send
additional messages to the server immediately after sending the client
connection preface, without waiting to receive the server connection
preface. It is important to note, however, that the server
connection preface SETTINGS frame might include parameters that
necessarily alter how a client is expected to communicate with the
server. Upon receiving the SETTINGS frame, the client is expected to
honor any parameters established. In some configurations, it is
possible for the server to transmit SETTINGS before the client sends
additional frames, providing an opportunity to avoid this issue.

Capturing embedded issues from #2:

a UDP-to-TCP gateway may simply not have the context to convert a message with a Block option into the equivalent exchange without any use of a Block option.

@cabo commented: I don't understand this argument.

sig-02 did not define the length for options with uint values. Can you confirm whether 0-4 is correct? I note that there are variants in the RFC7252 options with uint values.

3.5. Closing the Connection

All requests for which the CoAP client has not received a response
yet are cancelled when the connection is closed.

Does this mean, only the client must cancel the requests?
Or should the server do this also? Then a clarfication may be useful.