Draft: draft-ietf-core-coap-tcp-tls

Commentary: I 've reverted to the -08 tag in the initial commit and am gradually ( and manually ) layering in -09 commits that remain applicable . I 've skipped the commits below - please review for a second opinion - 
  commented :
Some environments benefit from the availability of CoAP carried over
reliable transports such as TCP or TLS.  This document outlines the
changes required to use CoAP over TCP, TLS, and WebSockets
transports.  It also formally updates RFC 7252 fixing an erratum in
the URI syntax, RFC 7641 for use with the new transports, and RFC
7959 to enable the use of larger messages over a reliable transport.
Some environments benefit from the availability of CoAP carried over
reliable transports such as TCP or TLS.  This document outlines the
changes required to use CoAP over TCP, TLS, and WebSockets
transports.  It also formally updates RFC 7641 for use with these
transports and RFC 7959 to enable the use of larger messages over a
reliable transport.
URI fixes an erratum on the URI scheme syntax in RFC7252.  bert
defines semantics for a value 7 for the field "SZX" in a Block1 or
Block2 option, updating RFC7959.
The challenge with this configuration is how to identify a resource
in the namespace of the CoAP server.  When the WebSocket protocol is
used by a dedicated client directly (i.e., not from a web page
through a web browser), the client can connect to any WebSocket
endpoint. coap-ws-scheme and coaps-ws-scheme define how the "coap"
and "coaps" URI schemes can be used to enable the client to identify
both a WebSocket endpoint and the path and query of the CoAP resource
within that endpoint.
The challenge with this configuration is how to identify a resource
in the namespace of the CoAP server.  When the WebSocket protocol is
used by a dedicated client directly (i.e., not from a web page
through a web browser), the client can connect to any WebSocket
endpoint. coap-ws-scheme and coaps-ws-scheme define new URI schemes
that enable the client to identify both a WebSocket endpoint and the
path and query of the CoAP resource within that endpoint.
CoAP over UDP RFC7252 defines the "coap" and "coaps" URI schemes.
This document corrects an erratum in Sections 6.1 and 6.2 of RFC7252
and defines how to use the schemes with the new transports.
Section 8 (Multicast CoAP) in RFC7252 is not applicable to these new
transports.
The "coap" URI scheme defined in Section 6.1 of RFC7252 can also be
used to identify CoAP resources that are intended to be accessible
using CoAP over TCP.
The "coaps" URI scheme defined in Section 6.2 of RFC7252 can also be
used to identify CoAP resources that are intended to be accessible
using CoAP over TCP secured with TLS.
If a TLS server does not support the Application-Layer Protocol
Negotiation Extension (ALPN) RFC7301 or wishes to accommodate TLS
clients that do not support ALPN, it MAY offer a coaps endpoint on
the default TCP port 5684.  This endpoint MAY also be ALPN
enabled.  A TLS server MAY offer coaps endpoints on TCP ports
other than 5684; these then MUST be ALPN enabled.
For TCP port 5684, a TLS client MAY use the ALPN extension to
advertise the "coap" protocol identifier in the list of protocols
in its ClientHello.  If the TLS server selects and returns the
"coap" protocol identifier using the ALPN extension in its
ServerHello, then the connection succeeds.  If the TLS server
returns a no_application_protocol alert, then the TLS client MUST
close the connection.  If the TLS server does not negotiate the
ALPN extension, then coaps over TCP is implicitly selected.
For TCP port 5684, if the TLS client does not use the ALPN
extension to negotiate the protocol, then coaps over TCP is
implicitly selected.
The "coap" URI scheme defined in Section 6.1 of RFC7252 can also be
used to identify CoAP resources that are intended to be accessible
using CoAP over WebSockets.
Note that the default port for "coap" is 5683, while the default port
for "ws" is 80.  Therefore, if the port given for "coap" is 80, the
default port for "ws" can be used.  If the port is not given for
"coap", then an explicit port number of 5683 needs to be given for
"ws".
The "coaps" URI scheme defined in Section 6.2 of RFC7252 can also be
used to identify CoAP resources that are intended to be accessible
using CoAP over WebSockets secured by TLS.
The WebSocket endpoint is identified by a "wss" URI that is composed
of the authority part of the "coaps" URI and the well-known path
"/.well-known/coap" RFC5785 I-D.bormann-hybi-ws-wk.  The path and
query parts of the "coaps" URI identify a resource within the
specified endpoint which can be operated on by the methods defined by
CoAP.
Note that the default port for "coaps" is 5684, while the default
port for "wss" is 443.  If the port given for "coap" is 443, the
default port for "wss" can be used.  If the port is not given for
"coaps", then an explicit port number of 5684 needs to be given for
"wss".
The port subcomponent is OPTIONAL.  The default is port 80.
The port subcomponent is OPTIONAL.  The default is port 443.
The WebSocket endpoint is identified by a "wss" URI that is composed
of the authority part of the "coaps+ws" URI and the well-known path
"/.well-known/coap" RFC5785 I-D.bormann-hybi-ws-wk.  The path and
query parts of a "coaps+ws" URI identify a resource within the
specified endpoint which can be operated on by the methods defined by
CoAP.
Initiating multiple instances of the same exchange with the
intention of using only one of the successful results is only safe
for idempotent exchanges (see Section 5.1 of RFC7252).
An important setback in using the UDP or DTLS over UDP transport
through NATs and other middleboxes can be the quick loss of NAT
bindings during idling periods HomeGateway.  This will not be
evident right on the initial exchange.
After the initial exchange, or whenever important information is
learned about which selection to prefer, an endpoint may want to
cache this information; however, the information may become stale
after the endpoint moves or the network changes.  A cache timeout
(possibly enhanced by movement detection) is advisable.
Alternatively, or additionally, the choice of transport may be aided
by configuration and resource directory information; the self-
description of a node may also include target attributes for links
given to resources there.  Details of such attributes are out of
scope for the present document; see for instance I-D.ietf-core-
resource-directory.
The "NoSec" mode is optional-to-implement.  The system simply sends
the packets over normal TCP which is indicated by the "coap" scheme
and the TCP CoAP default port.  The system is secured only by keeping
attackers from being able to send or receive packets from the network
with the CoAP nodes.
"PreSharedKey", "RawPublicKey", or "Certificate" is mandatory-to-
implement for the TLS binding depending on the credential type used
with the device.  These security modes are achieved using TLS and are
indicated by the "coaps" scheme and TLS-secured CoAP default port.
A CoAP client requesting a resource identified by a "coaps" URI
negotiates a secure WebSocket connection to a WebSocket server
endpoint with a "wss" URI.  This is described in coaps-ws-scheme.
The client MUST perform a TLS handshake after opening the connection
to the server.  The guidance in Section 4.1 of RFC6455 applies.  When
a CoAP server exposes resources identified by a "coaps" URI, the
guidance in Section 4.4 of RFC7925 applies towards mandatory-to-
implement TLS functionality for certificates.  For the server-side
requirements in accepting incoming connections over a HTTPS (HTTP-
over-TLS) port, the guidance in Section 4.2 of RFC6455 applies.
Note that this formally inherits the mandatory to implement cipher
suites defined in RFC5246.  However, modern usually browsers
implement more recent cipher suites that then are automatically
picked up via the JavaScript WebSocket API.  WebSocket Servers that
provide Secure CoAP over WebSockets for the browser use case will
need to follow the browser preferences and MUST follow RFC7525.
Note that this formally inherits the mandatory-to-implement cipher
suites defined in RFC5246.  However, usually modern browsers
implement more recent cipher suites that then are automatically
picked up via the JavaScript WebSocket API.  WebSocket Servers that
provide Secure CoAP over WebSockets for the browser use case will
need to follow the browser preferences and MUST follow RFC7525.
The IANA policy for future additions to this sub-registry is "IETF
Review or IESG Approval" as described in RFC5226.
The IANA policy for future additions to this sub-registry is "IETF
Review or IESG Approval" as described in RFC8126.
IANA is requested to assign the port number 5683 and the service name
"coap", in accordance with RFC6335.
IANA is requested to assign the port number 5683 and the service name
"coap+tcp", in accordance with RFC6335.
IANA is requested to assign the port number 5684 and the service name
"coaps+tcp", in accordance with RFC6335.  The port number is
requested also to address the exceptional case of TLS implementations
that do not support the "Application-Layer Protocol Negotiation
Extension" RFC7301.
IANA is requested to assign the port number 5684 and the service name
"coaps+tcp", in accordance with RFC6335.  The port number is
requested to address the exceptional case of TLS implementations that
do not support the "Application-Layer Protocol Negotiation Extension"
RFC7301.