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

From: Brian Raymor <[email-masked]>
Date: Thu, 11 Aug 2016 01:05:18 +0000

I've started to address the open coap-tcp-tls issues - https://github.com/core-wg/coap-tcp-tls/issues -  discussed at the IETF 96 meeting in Berlin. My intention is to publish coap-tcp-tls-04 on or before August 22nd.

For the TLS related issues:

https://github.com/core-wg/coap-tcp-tls/issues/8
https://github.com/core-wg/coap-tcp-tls/issues/11

I've created a draft pull request - https://github.com/core-wg/coap-tcp-tls/pull/52

For the ALPN issue:

https://github.com/core-wg/coap-tcp-tls/issues/4

I've created a draft pull request - https://github.com/core-wg/coap-tcp-tls/pull/53

Please review and feel free to comment on either the mailing list or in the pull requests. 

Thanks,
...Brian

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 11 Aug 2016 08:29:30 +0200

Hi Brian,

thanks for the update.

Regarding the TLS / ALPN case you have proposed the following wording:

With the exception of TCP port 5684, implementations that support CoAP
over TLS MUST perform protocol negotiation in TLS {{-alpn}} using the
"coap" protocol identifier defined in <xref target="alpnpid"/>.

What about using the following wording instead:

Implementations that support CoAP over TLS MUST perform protocol
negotiation in TLS {{-alpn}} using the "coap" protocol identifier
defined in <xref target="alpnpid"/> unless in deployments where ALPN
is not supported in the TLS protocol stack. Implementations MUST use
port number 5684 for those TLS implementations that do not support ALPN.

Regarding the pointers to RFC 7525 and RFC 7925. We should only
reference RFC 7925 since the recommendations in the two documents are
different and would lead to non-interoperable implementations. I did, of
course, point this out in my reviews but the authors were not interested
in IoT related concerns.

Ciao
Hannes

On 08/11/2016 03:05 AM, Brian Raymor wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Brian Raymor <[email-masked]>
Date: Thu, 11 Aug 2016 20:09:27 +0000

Hi Hannes-

Thanks for the edit and the guidance about the TLS-related RFC(s). I'll incorporate into the pull request before I merge later today.

...Brian

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Wednesday, August 10, 2016 11:30 PM
To: Brian Raymor <[email-masked]>; [email-masked]
Subject: Re: [core] Updates to coap-tcp-tls

Hi Brian,

thanks for the update.

Ciao
Hannes

<snip>

---

From: Christian Groves <[email-masked]>
Date: Fri, 12 Aug 2016 14:14:25 +1000

Hello,

To me the proposed update doesn't seem to read right having criteria at 
the start and end of the first sentence. Would the following be clearer?

Implementations that support CoAP over TLS with ALPN support MUST 
perform protocol
negotiation in TLS {{-alpn}} using the "coap" protocol identifier
defined in <xref target="alpnpid"/>. In deployments where the TLS 
protocol stack does not support ALPN,
implementations MUST use port number 5684.

Regards, Christian

---

From: Brian Raymor <[email-masked]>
Date: Fri, 12 Aug 2016 16:09:19 +0000

Hi Christian,

Here's what I actually merged in my pull request yesterday which is available in the editor's draft - https://core-wg.github.io/coap-tcp-tls/

If the Application-Layer Protocol Negotiation Extension (ALPN) [RFC7301] is available in the TLS protocol stack, CoAP over TLS implementations MUST perform protocol negotiation in TLS using the "coap" protocol identifier defined in Section 8.7. In exceptional cases where ALPN is unavailable, CoAP over TLS implementations MUST use port number 5684.

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Christian Groves
Sent: Thursday, August 11, 2016 9:14 PM
To: [email-masked]
Subject: Re: [core] Updates to coap-tcp-tls

Hello,

Regards, Christian

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 12 Aug 2016 23:57:38 +0200

Hi Brian,

this text doesn't seem to address the case where the ALPN functionality
isn't available at the other end.  E.g., a server instance may very well
have ALPN implemented, but still elects to offer a coaps://....:5684
server for clients that don't.

Grüße, Carsten

---

From: Brian Raymor <[email-masked]>
Date: Mon, 15 Aug 2016 16:49:30 +0000

Hi Carsten,

Good point.

How about:

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.

...Brian

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: Friday, August 12, 2016 2:58 PM
To: Brian Raymor <[email-masked]>
Cc: Christian Groves <[email-masked]>; [email-masked]
Subject: Re: [core] Updates to coap-tcp-tls

Hi Brian,

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 15 Aug 2016 21:10:21 +0200

> 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 negotiat…

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

---

From: Christian Groves <[email-masked]>
Date: Tue, 16 Aug 2016 14:18:27 +1000

"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

---

From: Brian Raymor <[email-masked]>
Date: Tue, 16 Aug 2016 05:45:48 +0000

I had been attempting to limit complexity and de-emphasize the use of port 5684 in favor of being clear about the requirement to use ALPN where available; however, it's obvious that I need to document all the potential client and server configuration/combinations in detail. I'll take another pass tomorrow.  Thanks for the feedback.

There was also a statement at IETF 96 that the use of port 5684 would be "similar to prior knowledge in HTTP/2". I reviewed RFC7540. Actually, ALPN is always required for HTTP/2 over TLS:

https://tools.ietf.org/html/rfc7540#section-3.4
... implementations that support HTTP/2 over TLS MUST use protocol negotiation in TLS [TLS-ALPN].

CoAP over TLS is setting a precedent in this case?

...Brian

-----Original Message-----
From: Christian Groves [mailto:[email-masked]] 
Sent: Monday, August 15, 2016 9:18 PM
To: Carsten Bormann <[email-masked]>; Brian Raymor <[email-masked]>
Cc: [email-masked]
Subject: Re: [core] Updates to coap-tcp-tls

Regards, Christian

---

From: Brian Raymor <[email-masked]>
Date: Tue, 16 Aug 2016 23:57:08 +0000

Here is an updated draft proposal based on the feedback. 

If a server does not support ALPN or wishes to accommodate 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 server MAY offer coaps+tcp endpoints on ports other than TCP port 5684, which MUST be ALPN enabled.

For TCP ports other than port 5684, the client MUST use the ALPN extension to advertise the "coap" protocol identifier (defined in Section 8.7) in the list of protocols in its ClientHello. If the server selects and returns the "coap" protocol identifier using the ALPN extension in its ServerHello, then the connection succeeds. If the server either does not negotiate the ALPN extension or returns a no_application_protocol alert, the client MUST close the connection.

For TCP port 5684, a client MAY use the ALPN extension to advertise the "coap" protocol identifier in the list of protocols in its ClientHello. If the server selects and returns the "coap" protocol identifier using the ALPN extension in its ServerHello, then the connection succeeds. if the server returns a no_application_protocol alert, then the client MUST close the connection. If the server does not negotiate the ALPN extension, then coaps+tcp is implicitly selected.

For TCP port 5684, if the client does not use the ALPN extension to negotiate the protocol, then coaps+tcp is implicitly selected.

-----Original Message-----
From: Christian Groves [mailto:[email-masked]] 
Sent: Monday, August 15, 2016 9:18 PM
To: Carsten Bormann <[email-masked]>; Brian Raymor <[email-masked]>
Cc: [email-masked]
Subject: Re: [core] Updates to coap-tcp-tls

Regards, Christian