Having risk management experience as well as policy establishment and enforcement, I would rather see the clear notification that something is not secure. Then the organization makes the decision to take that risk based on likelihood/impact considerations. This factors in risk tolerance and business objectives. I am an author on the draft, and don’t think this is the place for those business decisions to be made.
Best regards, Kathleen Sent from my mobile device > On Dec 1, 2020, at 12:52 AM, Ben Smyth <resea...@bensmyth.com> wrote: > > > I haven't followed all the nuances of this discussion, but it seems to boil > down to use of "MUST NOT" when certain "EXCEPTIONS MAY" exist for private > enterprise running legacy kit, which makes decision makers anxious, since > they don't want responsibility for something they "MUST NOT" do: A solution > might be to introduce "MUST NOT...EXCEPTIONS MAY" language, thereby allowing > sectors to define their standards/principles/expectations. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls