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
