Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14

Russ Mundy <mundy@tislabs.com> Thu, 18 February 2021 20:38 UTC

Return-Path: <mundy@tislabs.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 3D4453A182E for <ace@ietfa.amsl.com>; Thu, 18 Feb 2021 12:38:13 -0800 (PST)
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=unavailable 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 P_svkDvCBgNz for <ace@ietfa.amsl.com>; Thu, 18 Feb 2021 12:38:10 -0800 (PST)
Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 583093A182C for <ace@ietf.org>; Thu, 18 Feb 2021 12:38:10 -0800 (PST)
Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 04F0328B003B; Thu, 18 Feb 2021 15:38:09 -0500 (EST)
Received: from [127.0.0.1] (nova.tislabs.com [10.66.1.77]) by nova.tislabs.com (Postfix) with ESMTP id 7C29C1F8051; Thu, 18 Feb 2021 15:38:08 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_8AEDD0F1-DFDF-4419-9733-631168E03E46"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Russ Mundy <mundy@tislabs.com>
In-Reply-To: <DM6PR15MB23798EE51BDED9BB7D0438E3E3869@DM6PR15MB2379.namprd15.prod.outlook.com>
Date: Thu, 18 Feb 2021 15:38:08 -0500
Cc: Russ Mundy <mundy@tislabs.com>, Stefanie Gerdes <gerdes@tzi.de>, Daniel Migault <mglt.ietf@gmail.com>, Francesca Palombini <francesca.palombini@ericsson.com>, =?utf-8?Q?G=C3=B6ran_Selander?= <goran.selander=40ericsson.com@dmarc.ietf.org>, Olaf Bergmann <bergmann@tzi.org>, "ace@ietf.org" <ace@ietf.org>
X-Mao-Original-Outgoing-Id: 635373485.807523-55ca12d6ddd3c746d5af64574dbbf60f
Message-Id: <2C5A1AA5-6124-407B-A342-AA367CB6D536@tislabs.com>
References: <871rdqihww.fsf@wangari> <FD569111-85F8-40A2-8C97-764977309B87@ericsson.com> <CADZyTk=HB26o=mUpUdbYEhfhrGZar+oe28c5PZ2_j-vKYVA6xg@mail.gmail.com> <c6d42d18-f1f3-ec00-fff9-3540fa222d23@tzi.de> <9911269D-AA7F-458C-AA1A-2D59A79C5A00@ericsson.com> <CADZyTkn=3GigtTiihQX0ORYyO0dV0qCfVMtTn37vbsqJuQUJxw@mail.gmail.com> <026242c2-2c6a-485b-cb51-34b2b2d70975@tzi.de> <DM6PR15MB23796DF01885DC7F86C15583E3879@DM6PR15MB2379.namprd15.prod.outlook.com> <6b5368a6-b8ba-81eb-0c10-6a052fcbad67@tzi.de> <DM6PR15MB23798EE51BDED9BB7D0438E3E3869@DM6PR15MB2379.namprd15.prod.outlook.com>
To: Daniel Migault <daniel.migault@ericsson.com>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/YalvLoT6Sd9L2Lw9sXA2V7JMlVA>
Subject: Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14
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, 18 Feb 2021 20:38:13 -0000

Hi Daniel & others,

Thanks for the continuing effort to make the documents more clear and understandable. 

I think that there may be a fairly fundamental difficulty understanding (possibly on my part) about the intended relationship between the ACE framework and profile documents.  It seems appropriate to me that the framework would define the overall requirements (especially security requirements) that implementers need to meet and profiles provide the ‘how’ for implementers so the result is secure, interoperable implementations potentially from multiple different implementers of the framework using a particular profile for that framework.

If I’m following the discussion correctly, the changes being proposed to the framework would only require a profile to define one ‘example (or description)’ definition that met the security requirements of the framework (even if it was the RECOMMENDED protocol set) but other protocol set(s) could be used (MAY) within the definition of a profile.  Including what amounts to unspecified protocol set(s) that do not define how they will meet security requirements of the framework will likely result in different implementations that comply with the profile but do not interoperate from either a protocol or a security basis (or both).

Regards,
Russ

> On Feb 17, 2021, at 11:16 AM, Daniel Migault <daniel.migault@ericsson.com <mailto:daniel.migault@ericsson.com>> wrote:
> 
> Hi, 
> 
> I think that could work for me. If the changes address the initial concerns, we may publish these changes in the coming days. 
> 
> Yours,. 
> Daniel
> From: Stefanie Gerdes <gerdes@tzi.de <mailto:gerdes@tzi.de>>
> Sent: Wednesday, February 17, 2021 8:51 AM
> To: Daniel Migault <daniel.migault@ericsson.com <mailto:daniel.migault@ericsson.com>>; Daniel Migault <mglt.ietf@gmail.com <mailto:mglt.ietf@gmail.com>>; Francesca Palombini <francesca.palombini@ericsson.com <mailto:francesca.palombini@ericsson.com>>
> Cc: Göran Selander <goran.selander=40ericsson.com@dmarc.ietf.org <mailto:goran.selander=40ericsson.com@dmarc.ietf.org>>; Russ Mundy <mundy@tislabs.com <mailto:mundy@tislabs.com>>; Olaf Bergmann <bergmann@tzi.org <mailto:bergmann@tzi.org>>; ace@ietf.org <mailto:ace@ietf.org> <ace@ietf.org <mailto:ace@ietf.org>>
> Subject: Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14
>  
> Hi Daniel,
> 
> On 02/16/2021 04:53 PM, Daniel Migault wrote:
> 
> > Section 5:
> > OLD
> > "Profiles MUST specify a communication security protocol that provides
> >    the features required above."
> > NEW
> > "Profiles MUST specify at least one communication security protocol that provides the features required above."
> > 
> > <mglt>
> > I have the impression that with MUST specify one expects a mandatory protocol to be provided. Would the following text be acceptable ?
> > 
> > NEW2:
> > "Profiles RECOMMENDs at least one communication security protocol that provides the features required above."
> > </mglt>
> 
> I don't understand it like that but I see your point. But I think
> "RECOMMENDS" leaves too much wiggle room :). The profiles could then
> omit the protocols completely, which I think is a bad idea. Implementers
> should have at least one example how the communication between C and AS
> is protected. Since we don't provide it in the framework we must have it
> in the profiles. How about:
> 
> NEW3:
> "Profiles MUST specify at least one communication security protocol that
> provides the features required above as an example how the respective
> communication can be secured."
> 
> Viele Grüße
> Steffi