Hi Daniel and all, It seems to me that there is no full consensus, so we probably have to inform the AD about the disagreement. However, we do seem to agree that we want to clarify some parts of the framework. Here is yet another proposal:
Section 5: OLD "Profiles MUST specify a communication security protocol that provides the features required above." NEW "Profiles MUST specify a communication security protocol between client and RS that provides the features required above. Profiles MUST specify a communication security protocol RECOMMENDED to be used between client and AS that provides the features required above. Profiles MUST specify a communication security protocol RECOMMENDED to be used between RS and AS that provides the features required above." Section 6.2: OLD "Profiles MUST specify how communication security according to the requirements in Section 5 is provided." NEW "The requirements for communication security of profiles are specified in Section 5." If there is an unequivocal positive response from the WG then I may be able to publish a new version today. Göran On 2021-02-18, 23:03, "Daniel Migault" <[email protected]> wrote: Hi Russ, Thanks for the follow-up. I was waiting clearer agreement from eth WG before pinging you back. I think I agree with your understanding. My understanding is that the WG is willing to specify one way (RECOMMMEND) and not leave that unspecified while not preventing other configurations (MAY). This obviously results in implementation not following the RECOMMENDED way do not interoperate with those following these recommendations. The question remains open on whether we should favor openness or inter-operability. I suppose that this will be raised at the IESG so we need to address this issue clearly. Going back to the profiles, it would be good to understand what concrete deployment issues the two statements below would raise: * OSCORE profile mandating the AS to support OSCORE and have the C <-> AS using OSCORE. * DTLS profile mandating the AS to support DTLS and have the C <-> AS using DTLS. Yours, Daniel ________________________________________ From: Russ Mundy <[email protected]> Sent: Thursday, February 18, 2021 3:38 PM To: Daniel Migault <[email protected]> Cc: Russ Mundy <[email protected]>; Stefanie Gerdes <[email protected]>; Daniel Migault <[email protected]>; Francesca Palombini <[email protected]>; Göran Selander <[email protected]>; Olaf Bergmann <[email protected]>; [email protected] <[email protected]> Subject: Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14 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 <[email protected]> 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 <[email protected]> Sent: Wednesday, February 17, 2021 8:51 AM To: Daniel Migault <[email protected]>; Daniel Migault <[email protected]>; Francesca Palombini <[email protected]> Cc: Göran Selander <[email protected]>; Russ Mundy <[email protected]>; Olaf Bergmann <[email protected]>; [email protected] <[email protected]> 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 _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
