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

[Daniel Migault <[e-mail]>]

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 <[e-mail]> 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 <
> [e-mail]> 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=
>> [e-mail]> 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 <[e-mail]>
>>     Sent: Thursday, February 18, 2021 3:38 PM
>>     To: Daniel Migault <[e-mail]>
>>     Cc: Russ Mundy <[e-mail]>; Stefanie Gerdes <[e-mail]>;
>> Daniel Migault <[e-mail]>; Francesca Palombini <
>> [e-mail]>; Göran Selander <goran.selander=
>> [e-mail]>; Olaf Bergmann <[e-mail]>;
>> [e-mail] <[e-mail]>
>>     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 <
>> [e-mail]> 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 <[e-mail]>
>>     Sent: Wednesday, February 17, 2021 8:51 AM
>>     To: Daniel Migault <[e-mail]>; Daniel Migault <
>> [e-mail]>; Francesca Palombini <
>> [e-mail]>
>>     Cc: Göran Selander <goran.selander=[e-mail]>;
>> Russ Mundy <[e-mail]>; Olaf Bergmann <[e-mail]>;
>> [e-mail] <[e-mail]>
>>     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