Re: [core] Updates to coap-tcp-tls

[Christian Groves <[e-mail]>]

"If the Application-Layer Protocol Negotiation Extension (ALPN) 
[RFC7301] is available in both the client and server TLS protocol 
stacks..." seems to me to imply there's some prior knowledge of whether 
ALPN is supported in both the client and server. A CoAP client (TLS 
Client) will know whether it supports ALPN but not necessarily what the 
TLS server supports. A Client will send a clientHello with APLN "CoAP" 
and if the TLS server doesn't support the "CoAP" ALPN value, RFC7301 
specifies that it should respond with a fatal alert. In that case the 
fallback would be to use port number 5684.

Regards, Christian



On 16/08/2016 5:10 AM, Carsten Bormann wrote:
> Brian Raymor wrote:
>> If the Application-Layer Protocol Negotiation Extension (ALPN) [RFC7301] is available in both the client and server TLS protocol stacks, CoAP over TLS implementations MUST perform protocol negotiation in TLS using the "coap" protocol identifier defined in Section 8.7. The server MAY also offer CoAP over TLS only on port number 5684 for exceptional cases where ALPN is unavailable on the client or the server.
> That works for me.  With these interoperability mandates, I'm generally
> in favor of being very specific about what an implementation is supposed
> to do or not supposed to do.  Let me try to summarize:
>
> -- A TLS server MAY offer a coaps+tcp endpoint on TCP port 5864 if it
> doesn't support ALPN and/or to accommodate TLS clients that don't.  A
> TLS server MAY offer coaps+tcp endpoints on TCP ports different from
> 5684 if it does support ALPN.
> -- On TCP ports different from 5684, a coaps+tcp TLS client MUST offer
> ALPN value 'coap', and the coaps+tcp TLS server only becomes active if
> the TLS server selects the ALPN value 'coap'.  (If a different ALPN
> value is negotiated, or if the ALPN negotiation fails and thus causes a
> fatal alert, the present specification does become active.)
> -- On TCP port 5684, a TLS client MAY offer ALPN value 'coap' and a
> coaps+tcp TLS server MAY then select ALPN value 'coap'.  (If a different
> ALPN value is negotiated, or if the ALPN negotiation fails and thus
> causes a fatal alert, the present specification does not become active.
> **)  If the client does not send ALPN at all, coaps+tcp is assumed to be
> selected on port 5684 only.  If the client does send ALPN, and the
> server does not support ALPN, the negotiation will result in no ALPN
> value being explicitly selected [check this], and, again, coaps+tcp is
> assumed to be selected on port 5684 only.
> **) If a different ALPN is selected on port 5864, [define behavior here].
>
> Phew.  Are these all the cases we need to worry about?
>
> Should it be allowed to negotiation ALPN ≠ 'coap' on port 5684?
> (Probably yes, to enable the negotiation of a 'coap2' etc.; we can't
> really restrict what can be negotiated here without predicting the
> future.  Or we could completely disallow the use of ALPN on port 5684.)
>
> Grüße, Carsten
>