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.
If this is the right fundamental rule, then lets figure out how to make sure we
put the
right instances of this into the right places, like the errata and e.g.:
brski-cloud
Cheers
Toerless
On Wed, Jan 31, 2024 at 09:18:33AM -0500, Michael Richardson wrote:
>
> Toerless Eckert <t...@cs.fau.de> wrote:
> > ~~~~ I think it should say:
>
> > Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is REQUIRED.
> > TLS 1.3 (or newer) SHOULD be available. Registrars MUST and MASA
> > SHOULD support the "server_name" extension as specified in
> > [RFC6066]. This is also called the Server Name Indicator
> > (SNI).
>
> The Registrar does not need to support SNI on it's BRSKI-EST connection.
> In fact, it MUST ignore any SNI that it receives. The pledge can never get
> it correct, so we have to do port/IP address hosting only.
>
> So I disagree with your text: it requires too much, and actually the wrong
> thing for the Registrar.
>
> > Registrars MUST send a valid "server_name" extension when
> > connecting to a MASA.
>
> Sure.
>
>
>
> > - The text "REQUIRED if not TLS 1.3" is confusing because TLS 1.3 does
> > actually require SNI support by the TLS stack. So the proposed text
> > could be read as contradicting TLS 1.3. Therefore suggested rewrite
> > does not mention TLS versions.
>
> uhm. okay. I don't think that this is confusing.
>
> --
> Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
> Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
--
---
t...@cs.fau.de
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
