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

Commentary: (  's COMMENT that used to be DISCUSS number 1 ) 
 (  's DISCUSS number 2 ) This is probably the only DISCUSS - level issue that is likely to be significantly controversial in the WG . Mapping all six transports to coap:// and coaps:// also has the side effect of making moot , as there can only be one default port per scheme . 
 (  's issue number 2 ) 
 ( This issue is essentially preempted by , but I wanted to keep it visible separately . ) 
 (  's Discuss issue 1 ) 
 This already has been partially addressed by There is now a new draft that we can simply reference . 
 The recommendations in the document ( in 7925 Section 4.2 , 4.3 ) are good for CoAP over TCP / TLS in the constrained - to - cloud use case . For backend interfacing , and in particular for the WebSockets case , you would use what you have in those environments . 
 Is that true ? The WebSocket use case was about browser to IoT device and I believe RFC 7925 is also applicable as well and the doc even talks about that case . Where RFC 7525 may be applicable is in the context of gateways - to - cloud . I am not sure that 's a realistic use case though since why not use HTTP there right away . 
 The WebSocket case is about the browser to proxy hop , which might ( read : will ) have different cipher suites available to it than the proxy to Thing hop . 
 EKR advises : ( s/7295/7925/ ) 
 - do you want to assign to EKR for review or close based on your earlier PR since there has been no further concerns raised by the WG ? 
 For now , I think a good look from Hannes will help making sure that we do the right thing here . 
 - please review and comment before 8/28 . 
 What about this text proposal : FROM : TLS binding for CoAP over TCP The TLS usage guidance in [ RFC7925 ] applies , including the guidance about cipher suites in that document that are derived from the mandatory to implement ( MTI ) cipher suites defined in [ RFC7252 ] . ( Note that this selection caters for the device - to - cloud use case of CoAP over TLS more than for any use within a back - end environment , where the standard TLS 1.2 cipher suites or the more recent ones defined in [ RFC7525 ] are more appropriate . ) TO : TLS binding for CoAP over TCP The TLS usage guidance in [ RFC7925 ] applies to the use of CoAP over TCP / TLS when it is implemented on constrained devices , including the guidance about ciphersuites in that document that are derived from the mandatory to implement ( MTI ) ciphersuites defined in [ RFC7252 ] . CoAP over TCP / TLS has , however , a wider applicability . It may , for example , be implemented on a gateway or on a device that is not constrained ( like a smart phone or a tablet ) . In this case , the guidance in RFC 7925 is not appropriate and the recommendations in [ RFC7525 ] is appropriate . Since the guidance offered in [ RFC7925 ] and [ RFC7525 ] differs in terms of algorithms , and credential types it is assumed that the CoAP over TCP / TLS server implements the recommendations offered by both specifications if the range of supported devices include constrained and unconstrained devices . 
 Add :       
 LGTM
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, RFC 7959 to enable the use of larger messages over a
reliable transport, and RFC 6455 to extend the well-known URI
mechanism (RFC 5785) to the ws and wss URI schemes.
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.
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 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.
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.
Resources made available via these schemes have no shared identity
even if their resource identifiers indicate the same authority (the
same host listening to the same TCP port).  They are hosted in
distinct namespaces because each URI scheme implies a distinct origin
server.
Section 8 (Multicast CoAP) in RFC7252 is not applicable to these
schemes.
As with the "coap" and "coaps" schemes defined in RFC7252, all URI
schemes defined in this section also support the path prefix "/.well-
known/" defined by RFC5785 for "well-known locations" in the
namespace of a host.  This enables discovery as per Section 7 of
RFC7252.
The "coap+tcp" URI scheme identifies CoAP resources that are intended
to be accessible using CoAP over TCP.
The "coaps+tcp" URI scheme identifies CoAP resources that are
intended to be accessible using CoAP over TCP secured with TLS.
The port subcomponent indicates the TCP port at which the TLS
server for the CoAP server is located.  If it is empty or not
given, then the default port 443 is assumed (this is different
from the default port for "coaps", i.e., CoAP over DTLS over UDP).
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+tcp
endpoint on TCP port 5684.  This endpoint MAY also be ALPN
enabled.  A TLS server MAY offer coaps+tcp endpoints on ports
other than TCP port 5684, which MUST be ALPN enabled.
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.
The port subcomponent indicates the TCP port at which the TLS
server for the CoAP Connection Acceptor is located.  If it is
empty or not given, then the default port 5684 is assumed.
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+tcp is implicitly selected.
For TCP port 5684, if the TLS client does not use the ALPN
extension to negotiate the protocol, then coaps+tcp is implicitly
selected.
The "coap+ws" URI scheme identifies CoAP resources that are intended
to be accessible using CoAP over WebSockets.
The port subcomponent is OPTIONAL.  The default is port 80.
The "coaps+ws" URI scheme identifies CoAP resources that are intended
to be accessible using CoAP over WebSockets secured by TLS.
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.  The present specification formally
updates RFC6455, extending the well-known URI mechanism defined in
RFC5785 to also cover the "wss" URI scheme defined in that document.
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.
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".
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 TLS usage guidance in RFC7925 applies.
The "NoSec" mode is optional-to-implement.  The system simply sends
the packets over normal TCP which is indicated by the "coap+tcp"
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+tcp" scheme and TLS-secured CoAP default
port.
A CoAP client requesting a resource identified by a "coaps+ws" 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+ws" 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.
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.
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 5683 and the service name
"coap", 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 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 also to address the exceptional case of TLS implementations
that do not support the "Application-Layer Protocol Negotiation
Extension" RFC7301.
URI schemes are registered within the "Uniform Resource Identifier
(URI) Schemes" registry maintained at
http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml [1].
IANA is requested to register the Uniform Resource Identifier (URI)
scheme "coap+tcp".  This registration request complies with RFC7595.
The scheme is used by CoAP endpoints to access CoAP resources
using TCP.
IANA is requested to register the Uniform Resource Identifier (URI)
scheme "coaps+tcp".  This registration request complies with RFC7595.
The scheme is used by CoAP endpoints to access CoAP resources
using TLS.
IANA is requested to register the Uniform Resource Identifier (URI)
scheme "coap+ws".  This registration request complies with RFC7595.
The scheme is used by CoAP endpoints to access CoAP resources
using the WebSocket protocol.
IANA is requested to register the Uniform Resource Identifier (URI)
scheme "coaps+ws".  This registration request complies with RFC7595.
The scheme is used by CoAP endpoints to access CoAP resources
using the WebSocket protocol secured with TLS.