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.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
