IETF Logo Mail Archive

Re: [Ace] Murray Kucherawy's Discuss on draft-ietf-ace-mqtt-tls-profile-15: (with DISCUSS and COMMENT)

Cigdem Sengul <cigdem.sengul@gmail.com> Thu, 10 March 2022 16:08 UTC

Return-Path: <cigdem.sengul@gmail.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 BDB8B3A1748; Thu, 10 Mar 2022 08:08:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 tG3J4h1WvwLZ; Thu, 10 Mar 2022 08:08:26 -0800 (PST)
Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C1783A1749; Thu, 10 Mar 2022 08:08:26 -0800 (PST)
Received: by mail-vs1-xe33.google.com with SMTP id z85so6470038vsz.5; Thu, 10 Mar 2022 08:08:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LktGt14ufBupdTFot9d8BUzFJlH6AiNL5kr0WEedSDQ=; b=OMGNHbdDWPb6IukOQ6kiFNtJom8poUQDgCtJRa8t4uMAWPgBT03QEUGKS80OANllSD nQ3bPBx5vGmSGE4avAN9efdUDVFBDp60yMEmU3qOt8s1FKSYPeM3J6NZnZJ2TRNOj7Y1 UKDuXimkZOkYeKZa7as070mf4fhMsGQGYwEy4T4BEt8QbkF0e25r7qEJwmWY/YT/xaE3 vaA6rNn0ZPHKGRos90LJL8njaoQ7f1aKXIwIj29Sm5wmoKMo7zPN1J3rWFSl+bN3rKOx O7QeWlvIshDAmFfIA0Hti57hMHGJr9LCxU1zQneBsCtHu+g0DZEsMnD3qTxxilY6dqGl AiiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LktGt14ufBupdTFot9d8BUzFJlH6AiNL5kr0WEedSDQ=; b=5Z0wc++ZWmNm/MpZB4ChivKiOiMR17jbi2fWqx7e9ik6LUzzWONjo21w2IUU8oDb7B Yhejc+nSOBNtQVy8I45CHl9rpiLHb2HvP7FrKkGSQXCuzwBAHk+s8jW7NJkLTEhkXp39 YXu+MGmKt9RyT5SFUwCLApNh8B/jlJhIf5RYVjnNa+VKBWc3rSNK9JXA+Kyp21UbFec0 dcT4rS8bnVJvTj2y2448fe71ikF888GmjOGq4smgBinYRzqjz8HqA/k7cNNXQOTf+z6b BlzgJO2CQwZBBsrhpHT+IdsdrI+iIiMYyDp8Qzebk5GvJ1HiRCPkS8QgkkKJLwG/MKEY xttQ==
X-Gm-Message-State: AOAM533TziRrhFXj8XWXCZw0y/H6HlxCBHfZBwwtrGXhV4kD1Ltmu027 0NYfJOze5RDQQgOHbY1+vxhU4Pv6d/c55rfBuEN4N8pCT48qsA==
X-Google-Smtp-Source: ABdhPJx+AV3+k7aAt09xJJsQbfYAMEEOmVsPat43qZGQ0wuqTEqBmuv73ey0/ejRUz+PW26MUklbFqLoXKpxP3td0KU=
X-Received: by 2002:a67:2f88:0:b0:31e:c163:ee53 with SMTP id v130-20020a672f88000000b0031ec163ee53mr2843801vsv.78.1646928505053; Thu, 10 Mar 2022 08:08:25 -0800 (PST)
MIME-Version: 1.0
References: <164689410177.27262.13773022528008084974@ietfa.amsl.com> <20220310063715.GY22457@mit.edu> <CAA7SwCOvyZ7zoaFnSgs9VNp2dAh+mKV5Y5_f_tWc-MLtyk0q+A@mail.gmail.com> <CAL0qLwYgwzf38wKdfmbKf_N1aqHZSSH610qjA7QLZ033=-f60A@mail.gmail.com>
In-Reply-To: <CAL0qLwYgwzf38wKdfmbKf_N1aqHZSSH610qjA7QLZ033=-f60A@mail.gmail.com>
From: Cigdem Sengul <cigdem.sengul@gmail.com>
Date: Thu, 10 Mar 2022 16:08:14 +0000
Message-ID: <CAA7SwCMCq2dooQYSkdAx6fev8esBkvrjZRF3+P=H8k809U6V8g@mail.gmail.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Cc: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>, draft-ietf-ace-mqtt-tls-profile@ietf.org, Daniel Migault <daniel.migault@ericsson.com>, ace-chairs@ietf.org, Ace Wg <ace@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000083a5e405d9df6c74"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/hEhRpmPG3qiJ7kz750I5u3X9NiM>
Subject: Re: [Ace] Murray Kucherawy's Discuss on draft-ietf-ace-mqtt-tls-profile-15: (with DISCUSS and COMMENT)
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: Thu, 10 Mar 2022 16:08:32 -0000

Dear Murray,

Got it - I realise I wasn't clear with SHOULD  -  indeed the implementer
has limited discretion on what can happen: send the DISCONNECT, close
connection or drop the connection. I will discuss this with Ben but am
happy to add the additional text about dropping the connection.

Kind regards,
--Cigdem

On Thu, 10 Mar 2022 at 15:23, Murray S. Kucherawy <superuser@gmail.com>
wrote:

> Hi Cigdem,
>
> On Thu, Mar 10, 2022 at 12:54 AM Cigdem Sengul <cigdem.sengul@gmail.com>
> wrote:
>
>> Thank you for your review. Our thinking was as Ben explained.
>> In the draft, we used MUST/MUST NOT for the behaviour that affected
>> security, and SHOULD for desired behaviour.
>>
>
> This doesn't match my understanding of how BCP 14 is supposed to be used.
> MUST describes something obligatory for either interoperability, security,
> or operational reasons, and SHOULD is something where the implementer has
> limited discretion; when using SHOULD (or SHOULD NOT), it's desirable to
> include text describing when one might legitimately do something other than
> what's being stated.
>
> In this particular case, what I'm reading is paraphrased as: "In this
> situation, there's exactly one thing you can legitimately do within this
> protocol, and you SHOULD do that."  This doesn't make sense to me.  What
> Ben is saying is that there is a second option, which is to simply close
> the connection.  If you want to leave this as a SHOULD, I suggest adding
> text saying exactly that.
>
> Would the following revision make it more clear:
>> "The Broker MUST NOT forward messages to unauthorized subscribers and
>> SHOULD inform them of authorisation failure.
>> The only way to inform the client, in this case, would be sending a
>> DISCONNECT packet.
>> Therefore, the Broker SHOULD send a DISCONNECT packet with the reason
>> code '0x87 (Not authorized)'. "
>>
>
> That's also less dissonant, yes.  This was just discussed with Ben on the
> IESG call and I'll let him guide you on which change is more aligned with
> what you're trying to do.
>
> -MSK
>

v2.23.0 | Report a Bug | By Email