Subject: [core] Alt Transports: using "coap+" vs "coaps+"

From: Bill Silverajan <[email-masked]>
Date: Wed, 19 Nov 2014 15:20:48 +0200

Hi all,

In draft-silverajan-core-coap-alternative-transports-06, we carry 
transport information in the scheme component of a URI. Currently we 
have adopted a namespace-like convention within the scheme, by using 
"coap+" and the name of the transport, e.g. coap+tcp://..  coap+sms:// 
and so on. But up until now, not much attention has been paid towards 
considering how to properly express security protocols in the scheme.

I'd like to recommend using "coap+" to convey transmitting CoAP messages 
over alternative transports, and "coaps+" to convey transmitting *DTLS* 
encoded CoAP messages over alternative transports.

In other words,  use "coap+" prefix for : "coap+tcp" for CoAP over TCP, 
"coap+tls" for CoAP over TLS, "coap+ws" for CoAP over WebSockets, 
"coap+wss" for CoAP over secure WebSockets (which uses TLS).

This then paves the way for "coap+sms" for CoAP over SMS in 
draft-becker-core-coap-sms-gprs-05 and "coaps+sms"  for CoAP messaging 
over DTLS over SMS (draft-fossati-dtls-over-gsm-sms). Since DTLS can use 
other non-UDP transports e.g. SCTP (RFC6083),  or even extended with 
SRTP (RFC 5764), this enables expressing them at some future point, 
assuming such a need will ever arise (eg "coaps+sctp").

The main reason I propose this is to avoid overloading the semantics of 
what "coaps" stands for and keep it consistent with the usage of "coap" 
and "coaps" in RFC 7252, to avoid all kinds of misinterpretations: Does 
"coaps+tcp" mean CoAP over TLS or CoAP-over-DTLS-over-TCP? If "coaps+" 
means CoAP-over-TLS, is "coaps+ws" then equivalent to "coap+wss"? If we 
wish to send DTLS-encoded CoAP messages over other transports, does that 
also use "coaps+sms" or something else?

The second reason is that from a practical standpoint, it makes it far 
easier for lightweight implementations to know what "coaps" really 
means, when parsing such a URI. Also, "coap+tls" is 11.11% shorter than 
"coaps+tcp" :-)

The drawback to this is that should we intend to convey CoAP-over-TLS 
messages over a non-TCP transport, a workaround should be agreed upon. 
In early work, we overcame this by further subdividing the transport 
suffix into a namespace: e.g. "coap+l2cap.ble" vs "coap+l2cap.bt" to 
give a hypothetical example.

I'd appreciate your thoughts and comments on this.

Regards,
Bill

-- 
| Bilhanan Silverajan                       Tel: +358 (0)40 849 0757  |
| Tampere University of Technology, Finland                           |

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 19 Nov 2014 09:23:48 -0800

Hi Bill,

> I'd like to recommend using "coap+" to convey transmitting CoAP messages over alternative transports, and "coaps+" to convey transmitting *DTLS* encoded CoAP messages over alternative transports.

Interesting.

This is a different approach from what we said in Honolulu about TCP — see the provisional minutes at http://www.ietf.org/proceedings/91/minutes/minutes-91-core (comments on the raw minutes welcome, the structured minutes will only be done next week).

I do think it would help security to have a consistent indicator of “CoAP over a protected Transport”, and that would be the coaps element of the scheme name.  (There is no indication what kind or level of protection assurance is implied, but that is true of all the ___s:// schemes.)

I think we need to look at a table of plausible stacks (not every theoretical combination makes a lot of sense) and see how the two approaches look like.

Grüße, Carsten

---

From: Bill Silverajan <[email-masked]>
Date: Thu, 20 Nov 2014 10:46:45 +0200

Hi Carsten,

> This is a different approach from what we said in Honolulu about TCP — see the provisional minutes at http://www.ietf.org/proceedings/91/minutes/minutes-91-core (comments on the raw minutes welcome…

Thanks, I attended the session remotely and my comment on Jabber on this 
during your presentation, unfortunately went unnoticed. Perhaps I could 
ask again now, as to why "coaps+tcp" was preferred over "coap+tls" 
(which would have been more consistent with 
draft-silverajan-core-coap-alternative-transports)? "coaps+tcp" seems to 
suggest that some security mechanism is used to encode CoAP over TCP, 
but not necessarily TLS, while the work explicitly calls for using TLS?

> I do think it would help security to have a consistent indicator of “CoAP over a protected Transport”, and that would be the coaps element of the scheme name.  (There is no indication what kind or…

Yes. In general, it appears to be perfectly acceptable to assume the 
"___s://" scheme refers to the "secure" version of a specific protocol 
when the "s" character is appended to the _end_ of the scheme component. 
And then, a specific RFC explicitly explains the specific security 
mechanism used for that scheme.

In the "coaps+" case however, the "s" character is appended to the 
prefix (or in the _middle_ of the scheme component, if you wish), which 
can potentially impact all the alternative transports that then follow 
the "coaps+" prefix and then we are faced with multiple RFCs which might 
vary in their interpretations of what the security mechanism really is, 
per transport used. Hence my proposal, as I feel it's a simple solution 
to an otherwise arbitrary interpretation of what "coaps+" really means.

To avoid confusion in the future, I feel usage of the "coaps+" prefix 
needs some explanation in our draft. We can't register scheme prefixes 
and the draft doesn't request IANA allocation for any specific scheme. 
So we can't mandate implementers to choose one way or the other, but I 
feel a suitable guideline should be provided.

> I think we need to look at a table of plausible stacks (not every theoretical combination makes a lot of sense) and see how the two approaches look like.

It won't be a large table imho, so it shouldn't be the primary 
requirement for understanding how to use the "coaps+" prefix. Hence I 
outlined a few other reasons that I feel tip the scales in favour of 
letting "coaps+" mean DTLS-encoded CoAP messages, as opposed to a more 
generic definition. But I can revise my opinion certainly if there are 
other compelling factors I didn't take into account (eg TLS not using 
TCP, etc).

Best regards,
Bill