Gorry, Mike, Paul,

I've reworked the text based upon your suggestions.
I've also moved it from a somewhat deep sub-subection into a new section 4.1,
as section 4 already deals with relationship to RFC8995.
I've kept the mention of FIPS-140, but as an example of a certification scheme.
(I just love how everything in the UK is a "scheme")

(I'm actually rather concerned that mTLS 1.3 might be dead in the water for
the browser side of things.  I sure hope I'm wrong here)

https://github.com/anima-wg/anima-brski-prm/pull/149/files

---

## TLS support required

As already stated in {{!RFC8995}}, and required by 
{{?I-D.ietf-uta-require-tls13}}, the use of TLS 1.3 (or newer) is encouraged.
TLS 1.2 or newer is REQUIRED on the Registrar-Agent side.
TLS 1.3 (or newer) SHOULD be available on the registrar, but TLS 1.2 MAY be 
used.
TLS 1.3 (or newer) SHOULD be available on the MASA, but TLS 1.2 MAY be used.

{{?I-D.ietf-uta-require-tls13}} allows for continued use of TLS 1.2 for 
operational reasons.
{{RFC8995}} specified TLS 1.2 was the minimum, consistent with {{?RFC8996}}.
{{RFC8995}} requires mutual TLS, and many frameworks, embedded SDKs and 
hardware load balancers did not, at the time of writing, have APIs that 
permitted mutual TLS to be done consistently across TLS 1.2 and TLS 1.3.
While TLS 1.3 is common in browsers, the use of mutual TLS with 1.3 is uncommon 
in browsers, and so working support for mutual TLS in frameworks is also 
uncommon.

On the Registrar and MASA side, mutual TLS authentication combined with 
hardware TLS offload requires specific support for extensions, such as those 
provided by
TLS 1.2 and TLS 1.3 do client authentication at a different point in the state 
machine.
Frameworks do not at the time of this writing support this.
Sometimes this is due to lack of support for {{?RFC9440}} or an equivalent.

Many security certification schemes, such as FIPS-140, do not certify source 
code, but rather the resulting binary executable.  Even while TLS 1.3 source 
code is available, and new software can be added to existing platforms, 
replacing the TLS libraries on many embedded systems requires that the SDK 
vendor recertify the platform first.
In industrial settings, these platforms have long lifecycles.

Thus, {{RFC8995}} and this document can not turn off TLS 1.2 until all parts of 
the ecosystem can run TLS 1.3.
That does not stop any of the parts of this ecosystem from deploying TLS 1.3 
when possible, and for each part of the two or three transactions from 
negotiating TLS 1.3 in preference to TLS 1.2.

--
Michael Richardson <[email protected]>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*



Attachment: signature.asc
Description: PGP signature

_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to