Re: [Last-Call] [TLS] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <research@xxxxxxxxxxxx> 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@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/tls

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux