Re: [Anima] Errata 6642: Re: Registrar to MASA connections: SNI required

[Michael Richardson <[e-mail]>]

    Toerless Eckert <[e-mail]> 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   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide