Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06

Jim Schaad <ietf@augustcellars.com> Mon, 17 August 2020 23:14 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9473A142D; Mon, 17 Aug 2020 16:14:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2KbTUKiqxJw; Mon, 17 Aug 2020 16:14:19 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A5C23A142A; Mon, 17 Aug 2020 16:14:18 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 17 Aug 2020 16:14:09 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Cigdem Sengul' <cigdem.sengul@gmail.com>
CC: draft-ietf-ace-mqtt-tls-profile@ietf.org, 'Ace Wg' <ace@ietf.org>
References: <00dd01d6734e$09020920$1b061b60$@augustcellars.com> <CAA7SwCMAQw84Qr3z+3oPrfjyFoYF2pfCCt7a+zoFHDcKwLxtiA@mail.gmail.com> <00f601d67409$4a3f04e0$debd0ea0$@augustcellars.com> <CAA7SwCPCBknichaNZwrS3ig-hSUGTP=Gfsd3=gAFhH0PRmuc6Q@mail.gmail.com> <014901d674b3$d16e19b0$744a4d10$@augustcellars.com> <CAA7SwCONyAOpO9+TKZNB3UHsuBOQzQ99+b1KP57ek+d-k8LCsg@mail.gmail.com> <015c01d674c2$8dd3be30$a97b3a90$@augustcellars.com> <CAA7SwCPr8sJwnjBEzPMTqcbHEW-V5dFa-eTXO1VTQGL5xi0ndg@mail.gmail.com>
In-Reply-To: <CAA7SwCPr8sJwnjBEzPMTqcbHEW-V5dFa-eTXO1VTQGL5xi0ndg@mail.gmail.com>
Date: Mon, 17 Aug 2020 16:14:07 -0700
Message-ID: <017d01d674ec$1d3959d0$57ac0d70$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_017E_01D674B1.70DCA4B0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQMqeFZNts+Ba8La03OrSbr3Xch6qAHBpxSwAaRV0WACqZVhnAIUe3k4Ad1+eg4B3yff1gLyNynuph5QA/A=
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/0cWtATxEOy8ParI-oiZL7bmM0CY>
Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Aug 2020 23:14:22 -0000

 

 

From: Cigdem Sengul <cigdem.sengul@gmail.com> 
Sent: Monday, August 17, 2020 2:25 PM
To: Jim Schaad <ietf@augustcellars.com>
Cc: draft-ietf-ace-mqtt-tls-profile@ietf.org; Ace Wg <ace@ietf.org>
Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06

 

Hello Jim, 

 

I understand that it's an optimization to improve message delay. I wonder also if a client then can do CONNECT - PUBLISH - DISCONNECT before receiving a CONNACK as a best-effort publish? assuming CONNECT succeeds...

Should we just not cater to those cases?

 

What about stating in 2.2.6.1 - after "the Broker MUST

   send a CONNACK message to the Client." (or maybe somewhere higher up):

 

-> The client MUST NOT send any packets other than DISCONNECT or an AUTH in response to the broker AUTH's message until it has received a CONNACK.

-> The server MUST NOT process any packets other than DISCONNECT or an AUTH in response to its AUTH message before it has sent a CONNACK.

 

--Cigdem

 

 

[JLS] I think that not catering to these cases is just fine.  People who really expect them to work probably shouldn’t.

 

Jim

 

 

 

 

 

 

 

On Mon, Aug 17, 2020 at 7:16 PM Jim Schaad <ietf@augustcellars.com <mailto:ietf@augustcellars.com> > wrote:

 

 

From: Cigdem Sengul <cigdem.sengul@gmail.com <mailto:cigdem.sengul@gmail.com> > 
Sent: Monday, August 17, 2020 10:45 AM
To: Jim Schaad <ietf@augustcellars.com <mailto:ietf@augustcellars.com> >
Cc: draft-ietf-ace-mqtt-tls-profile@ietf.org <mailto:draft-ietf-ace-mqtt-tls-profile@ietf.org> ; Ace Wg <ace@ietf.org <mailto:ace@ietf.org> >
Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06

 

 

 

I've got that from MQTT v5 spec:

If a Client sets an Authentication Method in the CONNECT, the Client MUST NOT send any packets other than AUTH or DISCONNECT packets until it has received a CONNACK packet [MQTT-3.1.2-30].

 and:

If the Server rejects the CONNECT, it MUST NOT process any data sent by the Client after the CONNECT packet except AUTH packets [MQTT-3.1.4-6]. 

 

[JLS] I read this as the following would not do the publish

CONNECT -->

PUBLISH -->

                <-- AUTH

AUTH -->

                <-- CONNACK fail

The PUBLISH can be received but is not processed unless the CONNACK is going to be a success.

[/JLS]

 

[CS] I think this sequence should not happen, as Client MUST NOT send PUBLISH before CONNACK.

I did not know what brokers do if they receive PUBLISH (and still processing a CONNECT) - drop or buffer until process. I quickly browsed mosquitto src. 

It looks like the broker sets a context flag to mark the session active after CONNECT is processed and accepted. 

If this flag is not set when processing publish,  it goes to an error state and doesn't look like it keeps the packet. 

 

[JLS] No, Clients are allowed to send further MQTT Control Packets immediately after sending a CONNECT packet; Clients need not wait for a CONNACK packet to arrive from the Server. – this is the preceding two sentences to requirement MQTT-3.1.4-6.  I would agree that this is going to be server specific.  The following paragraph suggests that clients SHOULD wait for the CONNACK but it is non-normative.  I think that I would write my client code to wait.  I would have to work really hard to figure out what my code base would do for this as I know it does queue packets for later processing but I am not sure what it would do for this case.

 

 

[CS] Ok, this is confusing.  I assumed that sentence regarding clients about not having to wait was when no Authentication Method set. 

Because there is: If a Client sets an Authentication Method in the CONNECT, the Client MUST NOT send any packets other than AUTH or DISCONNECT packets until it has received a CONNACK packet [MQTT-3.1.2-30].

 In the profile, we do set an authentication method in connect to "ace". 

 

[JLS] Looks like there might be some conflicting statements here.  I don’t know the best way to resolve it.

Jim

 

 

--Cigdem