On Thu, Aug 05, 2021 at 05:57:25PM -0400, Michael Richardson wrote:
> Toerless Eckert <t...@cs.fau.de> wrote:
> > Wrt to the erratas:
> > https://www.rfc-editor.org/errata_search.php?rfc=8995&rec_status=0
> > I do agree that support for rfc6066 SNI would be great to have.
> It's not really about it being "great" :-)
> It's REQUIRED by TLS1.3, and in order for multi-tenant to work, it is a MUST.
Actually, RFC8446 only mandates that application must use RFC6066, and RFC6066
only
says that you SHOULD include the server_name, so i guess we need to
create a MUST include server_name requirement, if MASA is addressed with a DNS
name.
Independent of which TLS version is used.
> When I say "multi-tenant", I mean any cloud provider that has, for instance,
> "hardware" TLS offload.
AFAIK, some data centers are also assigning different IPv6 addresses to
different
virtual servers given how there are close to infinite IPv6 host addreses
available
for physical servers. No idea about the feature set for HW oflload. Is there
anything
public one could refer to ?
Obviously its mandatory for IPv4 hosted MASA.
> > I do not know if/what difference to implementations it would make
> > if an errata is "validated" or if it is just assessed as
> > "hold for document update", e.g.: if we do need/want/have-to-f ight to
> > get "validated" status from Rob (hi Rob!).
>
> It's not a significant amount of work.
No, but a significant amount of understnding the rules first. Because they
are insufficiently (IMHO) written.
> > So, IMHO the real requirement we have are:
>
> > 1. Pledge, Registrar and MASA MUST support RFC5246 (TLS 1.2)
> > 2. Pledge, Registrar and MASA SHOULD support RFC8446 (TLS 1.3).
> > 3. Registrars MUST signal SNI according to RFC6066 when connecting to
> an RFC5246 MASA.
>
> The other bit is that Registrars MUST IGNORE SNI when accepting Pledge
> connections. Pledges ought to not send it, since they don't really know
> what to put.
Are there never methods by which pledges or proxies discover registrar
DNS names ? Isn't that at least commonly expected for BRSKI cloud ?
RFC6066: It is RECOMMENDED that clients include an extension of type
"server_name" in the client hello whenever they locate a server by a
supported name type.
Aka: pledges wouldn't find in RFC6066 any text saying if/what to do with
server_name when there is no supported name type.
If this was a problem, it should be a problem already with a lot more
TLS use-cases ?!
Aka: I'd opt for not having to require an additional MUST IGNORE SNI..
Cheers
Toerless
> (Is that a SHOULD NOT, or a MUST NOT, or what, I am not sure. The requirement
> is on the receiver to ignore it)
>
>
> That's a second errata.
>
> --
> ] Never tell me the odds! | ipv6 mesh networks [
> ] Michael Richardson, Sandelman Software Works | IoT architect [
> ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails
> [
>
>
> --
> 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
