Hi everyone, This is just a follow-up. I would like to be able to close this issue by the end of the week, and so far I have not heard any issues for profile mandating a protocol. On the other hand, not mandating a specific protocol comes with interoperability issues. So unless more feed back is provided, I am currently leaning toward ensuring interoperability.
It would be good for me to hear from the WG and 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 On Mon, Feb 22, 2021 at 10:00 AM Daniel Migault <mglt.i...@gmail.com> wrote: > Thanks Gorand, > > I think the text goes in the right direction. I am reading this as > the framework defines the protocol should be used between the client and AS > or client and RS. It is not mandatory, sure, but at that point, my > understanding is that it makes it clear that if you do not follow the > recommendations you are at your own risks and so that interoperability is > provided by this recommendation. > I am wondering if the framework prevents a profile to mandate a protocol > ?. I assume not > > The one point I need to document in my shepherd is why recommendation is > sufficient to provide interoperability. I am happy to hear why the WG > thinks it is sufficient other than we want to leave that open. > > It would be good for me to hear from the WG and 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 > > On Mon, Feb 22, 2021 at 4:53 AM Göran Selander < > goran.selan...@ericsson.com> wrote: > >> 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" <daniel.migault= >> 40ericsson....@dmarc.ietf.org> 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 <mu...@tislabs.com> >> Sent: Thursday, February 18, 2021 3:38 PM >> To: Daniel Migault <daniel.miga...@ericsson.com> >> Cc: Russ Mundy <mu...@tislabs.com>; Stefanie Gerdes <ger...@tzi.de>; >> Daniel Migault <mglt.i...@gmail.com>; Francesca Palombini < >> francesca.palomb...@ericsson.com>; Göran Selander <goran.selander= >> 40ericsson....@dmarc.ietf.org>; Olaf Bergmann <bergm...@tzi.org>; >> ace@ietf.org <ace@ietf.org> >> 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 < >> daniel.miga...@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 <ger...@tzi.de> >> Sent: Wednesday, February 17, 2021 8:51 AM >> To: Daniel Migault <daniel.miga...@ericsson.com>; Daniel Migault < >> mglt.i...@gmail.com>; Francesca Palombini < >> francesca.palomb...@ericsson.com> >> Cc: Göran Selander <goran.selander=40ericsson....@dmarc.ietf.org>; >> Russ Mundy <mu...@tislabs.com>; Olaf Bergmann <bergm...@tzi.org>; >> ace@ietf.org <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 >> >> >> >> >> >> >> >> > > -- > Daniel Migault > Ericsson > -- Daniel Migault Ericsson
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace