Michael, *: Wrt to the erratas:
https://www.rfc-editor.org/errata_search.php?rfc=8995&rec_status=0 I do agree that support for rfc6066 SNI would be great to have. I do not know if/what difference to implementations it would make if an errata is "validated" or if it is just assessed as "hold for document update", e.g.: if we do need/want/have-to-f ight to get "validated" status from Rob (hi Rob!). I am pretty sure the WG would agree that we really should have written SNI/RFC6066 requirement and maybe where just not aware that SNI wasn't part of RFC5246 (TLS 1.2), given how it is part of RFC8446 (TLS 1.3). However, once we hear from Rob re. the ability to validate an errata asking for RFC6066, i would still ask that we revisit and fix up the proposed errata replacement text, because there are other issues with the text in question which may be more fundamental, let me explain the example of just one of the errata: Errata 6648: Original text: Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is REQUIRED on the pledge side. TLS 1.3 (or newer) SHOULD be available on the registrar server interface, and the registrar client interface, but TLS 1.2 MAY be used. TLS 1.3 (or newer) SHOULD be available on the MASA server interface, but TLS 1.2 MAY be used. My concerns: a) There is no REQUIRED for what version of TLS the registrar must support towards the pledge. Could use TLS 1.1 and be in compliance with RFC8995. And fail. b) "newer" is wrong, because it also does not establish mandatory interoperability: There is no requirement for any RFC8446 implementation to interoperate with an RFC5246 peer. And "newer" TLS version beyond 1.3 may not even support negotiation into TLS 1.2. Aka: could get TLS 1.2 vs TLS 1.3 (without TLS 1.2 implementation) between BRSKI peers. c) Editorial: Mentioning of MASA leg is out of scope as that is section 5.4. So, IMHO the real requirement we have are: 1. Pledge, Registrar and MASA MUST support RFC5246 (TLS 1.2) 2. Pledge, Registrar and MASA SHOULD support RFC8446 (TLS 1.3). 3. Registrars MUST signal SNI according to RFC6066 when connecting to an RFC5246 MASA. I think 1. and 2. establish the clear intent of the WG for TLS 1.2 as the mandatory to implement to ensure interop. And TLS 1.3 being optional. This is also what RFC8994 says. See into for arguing that we did intend to have SNI supported I have not figured out for RFC8446 whether we also need additional SNI requirements text or if sending SNI is mandatory in RFC8446. Given how we currently have the requirements split up into 5.1 and 5.4, the actual errata text would need to be split up into those two sections, but maybe we really also simply should start an rfc8995bis so that we have more freedom to simplify our text structure as well. Cheers Toerless _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima