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

[Toerless Eckert <[e-mail]>]

On Wed, Feb 14, 2024 at 01:01:56PM -0500, Michael Richardson wrote:
>     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"

Siure, i mean for this thread with subject "Errata 6642" lets only finalize
the text for section 5.4, which is only registrar to MASA.

>     > 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.

If you want to write that as the desired text for the Errata 6642, i will
accept it, even though i think we do not need to write anything about SNI
for the case where the Registrar does only know an IP-address of the
MASA, but not a domain name. I do not care whether or not the Registrar
puts an IP-addrerss into the TLS connection - because that IP-address
will not help. But yes, given how it does not hurt, its fine to just
say 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

If you do want to make that draft an update to RFC8995, then it is fine
to bring it up in this thread, because then the Errata 6642 text
should be aligned with that drafts text. But so far that draft is not
an update to rfc8995, so maybe we move the discussion about that draft
to another thread. I just want to finalize text that Rob can push into
the Errata.

>     > 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.

I am not a native english speaker, but to me the rfc2119 language of
"SHOULD be available" is stronger than "if TLS 1.3 is not available"
(aka: no rfc2119 langauge against TLS 1.3 at all).

I do agree though that "Use of TLS 1.3 (or newer) is encouraged" is redundant
and really superceeded by "TLS 1.3 (or newer) SHOULD be available.", but
i did not bother trying to propose shortening that text in an errata,
because mucking with those two sentences derails from the core purpose of
adding the SNI requirement.

> 
>     >    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.

"Just because i am paranoid does not mean they are not after me".

> 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.

See above. I am Ok, although i prefer to more precisely only demand
the case where we do know that sending SNI brings deployment benefits
(when domain-name of MASA is known), and leave the IP-address case
unmentioned, so developers can decide out what to do about it.
> 
>     >    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.

Well, my understanding is that Rob simply wants a replacement text for the
Errata that we both agree on so he can update the Errata with it.

Cheers
    Toerless
> 
> --
> ]               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
> 
> 
> 
> 



-- 
---
[e-mail]