Michael, *: You asked in another thread for verificiation of errata 6642:
https://www.rfc-editor.org/errata/eid6642 Currently it says: ~~~ Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is REQUIRED. TLS 1.3 (or newer) SHOULD be available. It should say: TLS 1.2 [RFC5246] with SNI support [RFC6066] is REQUIRED if TLS 1.3 is not available. The Server Name Indicator (SNI) is required when the Registrar communicates with the MASA in order for the MASA to be hosted in a modern multi-tenant TLS infrastructure. ~~~~ I think it should say: Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is REQUIRED. TLS 1.3 (or newer) SHOULD be available. Registrars MUST and MASA SHOULD support the "server_name" extension as specified in [RFC6066]. This is also called the Server Name Indicator (SNI). Registrars MUST send a valid "server_name" extension when connecting to a MASA. ~~~~ Explanations: - The suggested rewrite fully eliminated the MUST TLS 1.2, SHOULD TLS 1.3 requirements, whereas in reality, we want to simply add the SNI text and keep the TLS version requirements unchanged. - The text "REQUIRED if not TLS 1.3" is confusing because TLS 1.3 does actually require SNI support by the TLS stack. So the proposed text could be read as contradicting TLS 1.3. Therefore suggested rewrite does not mention TLS versions. - "server_name" is what's used in RFC8446, and the sentences are modelled around the RFC8446 text from the last paragraph of section 9.2 of that RFC. - For readers searching for the feature i thought its important to have both terms (SNI and "server_name") mentioned (i often search for terms on google and want to find RFCs... - The last sentence is an instance of RFC8664: Servers MAY require clients to send a valid "server_name" extension. Aka: Its a separate requirement to support SNI from actually sending it ~~~~ Lets see that we agree on the final text before asking Rob to approve ?! and then i don't know how to get the errata updated with that text, but given how you opened the errata, maybe you should do the honors (unless somehow i as a chair could do it easier...) Cheers Toerless On Wed, Jul 07, 2021 at 08:52:01AM +1200, Brian E Carpenter wrote: > below.. > > On 07-Jul-21 05:15, Michael Richardson wrote: > > > > In section 5.1 of RFC8995, we say: > > > >> 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. > > > > and in section 5.4: > > > >> Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is > >> REQUIRED. TLS 1.3 (or newer) SHOULD be available. > > > > In TLS 1.3, the "SNI" is mandatory. > > In TLS 1.2, SNI is defined at: > > https://datatracker.ietf.org/doc/html/rfc6066#section-3 > > and it's not mandatory, but it's highly recommended, and all browsers > > implement it today, and so one can depend upon it being present at the > > server > > side. > > > > Without SNI, each HTTPS tenant needs it's own IP address. > > In IPv6, this isn't a big deal. In IPv4, it is. > > TLS has been a justification to ask for multiple IPv4 in the past, but this > > is not flying as often anymore. > > > > I guess that I regret we did not write: > > > >> Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer (with RFC6066 > >> SNI support) is REQUIRED. TLS 1.3 (or newer) SHOULD be available. > > > > I don't know if is worth an errata. > > RFC8995 refers to TLS 1.2 but gives no reference for it. Even for TLS 1.3, it > doesn't cite RFC8446 in the above extracts, where I think it should. So I > think what you really want to say is more like: > > Use of TLS 1.3 [RFC8446] (or newer) is RECOMMENDED. TLS 1.2 [RFC5246] with > SNI support [RFC6066] is REQUIRED. > > Or should that last bit be: > > TLS 1.2 [RFC5246] with SNI support [RFC6066] is REQUIRED if TLS 1.3 is > not available. > > I'd say, yes, submit an erratum, even if it ends up as "Held for Document > Update". > > Brian > > > > -- --- t...@cs.fau.de _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
