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

[Toerless Eckert <[e-mail]>]

On Mon, Feb 12, 2024 at 09:01:50AM -0500, Michael Richardson wrote:
> 
> 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.
> 
> 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.

Just to double check: in this thread we're only talking registrar to MASA (no pledges).

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.

Aka: IMHO serious enough that it justifies the one sentence we can write upfront to
avoid this.

> Where we could go into trouble is when there are 307 redirects.

Explain ? Or separate thread ?
> 
>     > Lets just agree on the final text for this errata so Rob can close the
>     > book on it.
> 
> Pledges MUST include SNI for 1.2 and 1.3.

Right. Except for language maybe using the "server-name" terminology as the TLS 1.3 RFC.

> (Registrar's with provisional-TLS connections MUST ignore the SNI: they can
> not be virtual-hosted)
> 
> If you didn't like my errata text, then let's come back to that.
> (I wish errata was on gitlab)
> 
> https://www.rfc-editor.org/errata/eid6642
> 
> says:
> Held for Document Update by: Rob Wilton
> Date Held: 2024-01-15
> 
> so we get another chance to fix the text when we do a document update.
> Does the text that is there upset you?

Yes, to repeat what i said in the first email of this thread:

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

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

   Aka: 

   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.

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



-- 
---
[e-mail]