> It is incredibly difficult to draw a line so precisely as to where the threat to a > device begins and ends, given the wide range of deployment scenarios. If a > device can be at all critical (and even if it isn’t), then it should be upgraded or > replaced. Better that this be out there in its current form so that other > organizations that specify TLS requirements can pick this document up > without any wiggle room or ambiguity. Also, we do not have a “Sometimes > Deprecated” category, nor do I think we should start here. > > Eliot Speaking as someone who has participated in internal discussions on whether to ignore something like this (e.g., even after Wi-Fi Alliance deprecated WEP there was a decision to continue to support WEP for a few years because of the embedded base of non-upgradable devices; same for WPA1), I would suggest the strong, unambiguous statement with explanation for why the statement is being made. There is no need to describe (possible) exceptions. If someone feels a strong need to ignore this in their own network, they will have no difficulty doing so (and have no difficulty justifying it to themselves and others inside their org). I don't think IETF help is needed to figure out these scenarios/reasons/justifications. Barbara > > On 1 Dec 2020, at 10:29, Peter Gutmann <pgut001@xxxxxxxxxxxxxxxxx> > wrote: > > > > Stephen Farrell <stephen.farrell@xxxxxxxxx> writes: > > > >> That said, if someone had words to suggest that might garner consensus, > that > >> would be good. > > > > I think all it needs is something along the lines of "This BCP applies to TLS > > as used on the public Internet [Not part of the text but meaning the area > that > > the IETF creates standards for]. Since TLS has been adopted in a large > number > > of areas outside of this, considerations for use in these areas are left to > > relevant standards bodies to define". > > > > Peter. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
