On 12/2/20 6:00 PM, Ackermann, Michael wrote:
I don't disagree with anything you say on the TLS subject, which is
essentially that prior versions of TLS may be considered insecure, etc. and
should be deprecated.....
RFC 2119 equates, semantically, at least in English, MUST NOT with
prohibition (_not_ deprecation).
draft-ietf-tls-oldversions-deprecate-09.txt uses MUST NOT in §4 and §5.
It does use the term "Deprecation": prominently, and likely inadvisedly,
in §2. Re-worded, the title of §2 should be "Support for Prohibition"
(particularly as its prior sibling is §1.2 "Terminology", which is
inescapable boiler-plate and likely is invisible to any RFC readers).
I cannot resist citing H. L. Mencken's definition of Puritanism here.
My associated point is that Enterprises are generally not aware of this and
that it is not currently on our Planning or Budget Radars.
Perhaps such lack of awareness could be considered as the difference
between (Aquinian) vincible and invincible ignorance.
Whether such is a mortal or venial sin, or no sin at all, could be
considered in light of risk evaluation and management. Or one's
tolerance for the wages of sin. Steely determination for continued use
of flawed protocols can be admired while simultaneously lamented.
In other words, is a _prohibition_ (à la, e.g., PCI DSS) of TLS versions
prior to TLS 1.2 (and prior to 1.3 for that matter) sufficient to demand
upside-down crucifixion for failure to comply, or something more
family-oriented. In either case, perhaps an appendix expressing the
tension between prohibition and tolerance might suffice, rather than
watering down §4 and §5. But such an appendix would be necessary in any
normative RFC, so, in my opinion, the draft can be published without
such an appendix.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
