Hi Keith, A few things I'll try to unpack here and get more input from you on... On Mon, Nov 16, 2020 at 02:47:49PM -0500, Keith Moore wrote: > On 11/10/20 1:02 PM, John C Klensin wrote: > > > For all of the obvious reasons, I think reclassifying these > > documents to historic is a good idea. _However_ if we are > > really trying to say "don't use these, they are obsolete and > > unsafe" rather than just "no current specification refers to > > them but do what you like", I believe that it would be better to > > publish a short RFC explaining the issues with them rather than > > simply making a datatracker note that points to a "supporting > > document", particularly one that doesn't actually say much of > > anything. > > I agree that some sort of RFC is appropriate. One of my growing > concerns is that deprecating old TLS ciphersuites is breaking old When you say "deprecating old TLS ciphersuites" are you thinking specifically the single-DES and IDEA ciphersuites of this action, or extrapolating to a broader class of things? > systems that are still in use, and actually preventing them from having Us publishing an RFC doesn't break things; implementations changing breaks things. And there are, of course, two endpoints to any TLS communication; issues occur when only one is upgraded to a software that removes support for the deprecated stuff (upgrading both would seem to allow a clean transition)... > any of their software upgraded, because there are no web browsers that > run on those systems that support the ciphersuites used by current servers. ...and you seem to be concerned about the case where a server is upgraded to remove support for old stuff (see above question about these specific ciphers vs "stuff" generically), but a client is stuck with old software. What about the reverse case, where the client can upgrade/has upgraded but the server is stuck on old software? > So IMO, simply saying "don't use these" is NOT good advice, and instead > the advice should be something like "treat these ciphersuites as if they > were unencrypted connections". I realize that this will make the > purists uncomfortable, but I think the discussion needs to be had. I'm not sure that we have a great way to reflect such sentiment in terms of our formal document statuses. I note that openssl, for example, is exercising a fairly considered approach to this sort of thing, moving weaker ciphers/algorithms out of the default "security level" but leaving them implemented for a while, so you can opt in to using the weak stuff but the out-of-the-box default is still secure. Only after an additional deprecation period are the weak ciphers actually removed. So, I am okay with the IETF saying that this stuff is historic, and letting implementations choose whether or not they want to keep historic stuff around for an extended transition period. If you are specifically concerned about the major browsers and their deprecation+removal schedules, that seems to be a recurring conversation that comes up periodically; I will summarize my stance on that question as being that the browsers have a given target market that they are providing a free product to, and if you are outside of that target market, it's unfortunate, but the browsers don't have an economic incentive to provide free support to everyone and I don't see the IETF changing that. Thanks, Ben -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
