[OASIS Issue Tracker] (MQTT-293) Review Section 3.1.4 CONNECT Response behaviour and Section 5 Security

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/MQTT-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=63406#comment-63406 ] 

Raphael Cohn commented on MQTT-293:
-----------------------------------

Some points to consider:-

- We currently require that the Network Connection is closed. This potentially conflicts with a TLS-transport, which requires a close-notify to be sent. That said, I've never quite satisified myself with TLS1.2's reasoning that simply aborting a connection when things are grossly wrong isn't the better method. I suppose in a TLS handshake scenario it gives the opportunity for a client to avoid unnecessary reconnects

- I would prefer a move to the default being:-
  - It SHOULD => It MAY end an appropriate CONNACK response with a non-zero return code as described in section 3.2 
  - It SHOULD immediately close the connection if it believes that so sending a CONNACK response will create an insecurity, or if it believes it to be under attack (eg DoS) [wording to be improved]

I'd also strongly suggest we register three ALPN Protocol IDs with IANA for MQTT, so that clients can do protocol negotiation securely before CONNECT when using TLS:-

- "mqtt/5" for MQTT 5
- "mqtt/3.1.1" for MQTT 3.1.1

This will allow a client that wants to use MQTT 5, but can downgrade to 3.1.1, to do so without having to make a disconnect and reconnect AFTER negotiating TLS.

In addition, I'd like us to tighten up the TLS stuff we recommend for MQTT. In particular, I'd like to:-
- Move to an appendix where we now say we SHOULD use TLS (or an equivalent transport level tech, eg VPN); SHOULD NOT for plain MQTT unless using domain sockets or loopback devices.
- If using TLS, then only support TLS 1.2 and higher. Clients should not attempt to do TLS version fallback by re-connecting
- If using TLS, then align to best practices. Implementations are encouraged to use cipher suites, etc, that are likely to be in TLS 1.3 [For me, this is - forward secrecy only suites using elliptic curves, AEAD only ciphers (AES and ChaCha20), and no use of RC4, MD5, SHA1, truncated HMACs, etc]
- For embedded devices, be aware that cryptographic technologies are changing rapidly, and that many common algorithms may become vulnerable during your implementation's service lifetime.
- When anticipating high levels of scale, to use TLS Session Tickets for session resumption
- That it is suggested that TLS servers used by MQTT support at least the alpn, tls session ticket, extended master secret, SNI, supported_groups, signature algos, supported_groups and ec_point_formats extensions to maximise interoperability.
- MQTT implementations are encouraged to not use other TLS extensions that could hinder interop
- MQTT clients are encouraged to not use SNI, however, as it can leak DNS-layer details

- When using DNS, MQTT clients are recommended to use encrypted DNS (eg dnscrypt).


> Review Section 3.1.4 CONNECT Response behaviour and Section 5 Security
> ----------------------------------------------------------------------
>
>                 Key: MQTT-293
>                 URL: https://issues.oasis-open.org/browse/MQTT-293
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 5
>            Reporter: Richard Coppen
>
> Jira opened following discussion on TC call 11.08.2016
> Review Section 3.1.4 Connect / Response
> e.g., The Server MAY check that the contents of the CONNECT Packet meet any further restrictions and MAY perform authentication and authorization checks. If any of these checks fail, it SHOULD send an appropriate CONNACK response with a non-zero return code as described in section 3.2 and it MUST close the Network Connection.
> Review Section 5 (Security)



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)