Toerless Eckert <t...@cs.fau.de> wrote:
>> agile. But SNI is one such
>> example, where the pledge does need to
>> signal the right info (SNI)
>> to enable "cheaper" cloud registrars, aka:
>> those not owning a
>> separate IPv4 address. See e.g.: AWS cost for IPv4 > address.
On Mon, Feb 12, 2024 at 09:01:50AM -0500, Michael Richardson wrote:
>> Right, but it's self-righting. A manufacturer that uses an SNI-only
>> cloud registrar and does not do SNI will fail immediately: they won't
>> get out of the lab. And the manufacturer controls both initial sides
>> of this.
tte> Just to double check: in this thread we're only talking registrar to
tte> MASA (no pledges).
The text I quote from you above, says, "pledge"
> Then the biggest risk is when there are a lot of Registrar instances
> out in the field and the company wants to make the MASA service cheaper
> by putting it into some cloud service data center from a third party,
> and only then wake up and see that that cloud data center (opposed to
> the vendors original own data center) does require SNI. So now, the
> vendor needs to update all Registrars in the field.
I really think you are overthinking this.
SNI is mandatory to send.
> Aka: IMHO serious enough that it justifies the one sentence we can
> write upfront to avoid this.
So maybe it goes here:
https://www.ietf.org/archive/id/draft-richardson-anima-registrar-considerations-08.html#name-masa-client-northbound-inte
> 1. the way you wrote it, you replace the whole two sentences, aka: you
> remove:
> Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is
> REQUIRED. TLS 1.3 (or newer) SHOULD be available.
> I am sure you wanted your text to be ADDED after those two
> sentences.
> 2. "TLS 1.2 [RFC5246] with SNI support [RFC6066] is REQUIRED if TLS 1.3
> is not available."
It seems to me ethat it says that same thing.
> This does not say that Registrars must send SNI/"server-name". It
> just means the TLS stack on registrars/MASA needs to be able to support
> SNI. And i am a fourth degree burn victim of text like this. Many
> customers who could not deploy multicast appropritely because they
> believed vendor text "device supports IGMPv3" was sufficient, when
> instead what was required was: "(IPTV) application MUST use SSM
> signalling via IGMPv3". (see also the TLS 1.3 text related to this
> "server-name" support vs. application support).
I'm sorry that you were burnt, but that doesn't mean you have to wear a
fireman's suit everywhere.
If you want it to say, "Clients must send SNI.", I'm okay with that.
In general, it's rather hard to turn SNI off with most libraries.
> Append to the section 5.4 text from above the following:
> When the MASA is known to the registrar by its domain name, the
> registrar MUST send the domain name of the MASA in the TLS "Server Name
> Indicator" (SNI) option (also called "server-name") [RFC6066] whether
> TLS 1.2 [RFC5246] or TLS 1.3 [RFC8446] is used.
> 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 where it shares its IP/IPv6 address with other HTTPS
> services.
I'm fine with this. But, since it's hold for document update, we don't have
to wordsmith it now, as long as we get across the right idea in the patch.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
