On Mon, May 12, 2025 at 9:25 AM Michael Richardson <mcr+i...@sandelman.ca> wrote:
> > Hi, how about this text: > > https://github.com/anima-wg/anima-brski-prm/pull/149 > > {{?I-D.ietf-uta-require-tls13}} allows for continued use of TLS 1.2 for > operational reasons. > > {{RFC8995}} restricted itself to requiring TLS 1.2 (but not less) for a > number of reasons including: the need for mutual TLS, and the need for FIPS > certified modules on router and IoT platforms that have long software > lifecycles, I would remove the "need for mutual TLS" as that was supposed by TLS 1.1/1.0 as well. > and often also include hardware offload of cryptographic options. > FIPS certification is not done on software, but on the binary, and those > binary distributions are often part of a different software lifecycle than > the applications that run on top of it. > I would remove the two occurances of "FIPS", to make the document apply more generically in other parts of the world as well. On the Registrar and MASA side, mutual TLS authentication combined with > hardware TLS offload requires specific support for extensions, such as > those > provided by {{?RFC9440}}. > Looks fine. > TLS 1.2 and TLS 1.3 do client authentication at a different point in the > state machine, many frameworks do not at the time of this writing support > both in a bug free manner. > I would rewrite this or delete it. An RFC mentioning "bugs at this time" will age poorly. Perhaps something along the lines of "While TLS 1.3 is widely supported in clients and servers on generic OS and mobile platforms, its support is less widespread in other types of devices, necessitating continued support for TLS 1.2. Implementations that support both TLS 1.2 and 1.3 should follow the generic guidlines of RFC8449 to negotiate the highest mutually shared version of TLS." Paul
_______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
