On 2021-07-10, at 12:07, Ludwig Seitz <[email protected]> wrote: > > I can remove the text entirely, since we don't seem to agree on the details. > Would that be acceptable?
I can’t answer that question, but it seems to me that we both have a requirement in mind. The text that resulted from processing my version is: > Profiles are expected to prepare for being combined with others by clearly > specifying their security requirements. While you had: > The security of a profile MUST NOT depend on the assumption that this profile > is used in all steps of the authorization flow (C-AS, C-RS, RS-AS). The difference is that you want to impose a requirement on all profiles, a requirement that I believe is hard to provably fulfill in general. While I was mainly putting out a requirement that profiles document their properties in this space, which is both more practical and more general. Maybe we can combine these two into one sentence that covers a common requirement? Grüße, Carsten > /Ludwig > > Sent from my smartphone > > > ---- Carsten Bormann wrote ---- > > How do we get this done before Monday’s I-D deadline? > > On 2021-07-06, at 08:22, Ludwig Seitz <[email protected]> wrote: > > > > Hello Francesca, Carsten, > > > > Sorry but I do not like what you did in the first sentence. Combining > > profiles does not necessarily equate to creating a new one, and I still > > don't see why we should needlessly request that it be so. > > The devil is in the details. If we have pairs profiles that combine, the > component profiles should say so and say how. > > > Given an example use case where a client talks dtls-profile to the AS and > > gets token and parameters for an oscore-profile back for the client-RS leg, > > why should there be a need for a new profile to support this? > > Because the interaction e.g. with the DTLS and OSCORE/LAKE security setup has > details that need to be covered in the component profiles. > > > I also do not like that you removed the requirement to design profiles so > > that the security for the different legs of the communication (C-AS, C-RS, > > RS-AS) stands on its own. > > Some of the security can stand on its own, but the overall security derives > from the properties of the legs combining. > > > What could happen now is that someone designs clever protocol foo that has > > a dependency between the C-AS and the C-RS communication for its security, > > and thus breaks when it is used on only one leg of this communication. I > > don't think you need to know all possible future profiles to design yours > > to be secure in that way. Note that the framework puts requirements on the > > security of future profiles, so you can assume e.g., that communication > > will be secure. > > We may be better off writing a separate document that explains how to exactly > do this mixing-and-matching. > > I’d like to hear from others how they see this issue. > > Grüße, Carsten > > _______________________________________________ > Ace mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
