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

[Toerless Eckert <[e-mail]>]

Hah, forgot to discuss this topic today. Well, it's not running away.

I am really only interested to be diligent with pledge requirements because those will have
the biggest variety of potentially crappy software stacks. Registars/MASA ci expect to be much
more software 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. 

Now, cloud is a separate case from this threads subject (registar->masa), but i think technically
it is correct to ask for SNI support on Registrar. But i am not adament to make a fuzz about it.

Lets just agree on the final text for this errata so Rob can close the book on it.

Cheers
   toerless

On Fri, Feb 02, 2024 at 08:49:06AM -0500, Michael Richardson wrote:
> 
> Toerless Eckert <[e-mail]> wrote:
>     > Lets maybe finalize next tuesday during our meeting.
> 
>     > In general i think that whenever a TLS initiator did learn the TLS
>     > responder through a URL with a domain name, then it needs to insert the
>     > domain name as the SNI "server_name".
> 
>     > If thats not an unwritten rule, then i'd like to understand why not.
> 
> I think it is.  I'm not objecting to that.
> As you said, sometimes old/rusty TLS libraries don't do this.
> But, the manufacturer knows that, and this can build their MASA based upon
> SNI (or not) assumption, and it's fine.
> 
> But, for BRSKI-EST link, we can assume enough modern TLS to allow for SNI
> based virtual hosting.
> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 



-- 
---
[e-mail]