> Wouldn’t be the first case an RFC gets misinterpreted. I don't think the IETF's decisions should be dictated by the risk that someone might potentially misread their documents. That's always a risk. Someone might misread RFC 8446 as saying "use SSL 3.0 only." Does that mean the IETF shouldn't publish RFC 8446?
> use depreciation as an excuse to remove support of deprecated algorithms and protocols. I'm not sure what the issue is here. Deprecation isn't just an excuse to remove support of deprecated protocols; it's a good reason to do so. If, however, they need to interface with legacy systems, they can continue to do so in spite of official deprecation. No one is going to arrest them for continuing to use FFDHE. Carrick On Wed, Dec 14, 2022 at 5:01 AM Blumenthal, Uri - 0553 - MITLL < u...@ll.mit.edu> wrote: > True - but, unfortunately, quite a few readers misunderstand that and use > depreciation as an excuse to remove support of deprecated algorithms and > protocols. > > Wouldn’t be the first case an RFC gets misinterpreted. > > Regards, > Uri > > On Dec 14, 2022, at 02:30, Rob Sayre <say...@gmail.com> wrote: > > > On Tue, Dec 13, 2022 at 8:14 PM Blumenthal, Uri - 0553 - MITLL < > u...@ll.mit.edu> wrote:\ > >> >> >> I think I’ve made my point already – there are devices that use FFDHE, >> which remain secure (so far), and may require access by new <whatever>. >> Thus, an RFC that would prohibit it, sounds, as you said yourself, >> premature. >> > > Deprecated does not mean prohibited. > > thanks, > Rob > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
