Subject: [Anima] MichaelR/Rob/*: RFC8995 errata concerns

From: Toerless Eckert <[email-masked]>
Date: Thu, 5 Aug 2021 23:17:14 +0200

Michael, *:

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

I am pretty sure the WG would agree that we really should have written
SNI/RFC6066 requirement and maybe where just not aware that SNI wasn't
part of RFC5246 (TLS 1.2), given how it is part of RFC8446 (TLS 1.3).

However, once we hear from Rob re. the ability to validate an errata
asking for RFC6066, i would still ask that we revisit and fix up the
proposed errata replacement text, because there are other issues
with the text in question which may be more fundamental,
let me explain the example of just one of the errata:

Errata 6648:

Original text:
   Use of TLS 1.3 (or newer) is encouraged.  TLS 1.2 or newer is
   REQUIRED on the pledge side.  TLS 1.3 (or newer) SHOULD be available
   on the registrar server interface, and the registrar client
   interface, but TLS 1.2 MAY be used.  TLS 1.3 (or newer) SHOULD be
   available on the MASA server interface, but TLS 1.2 MAY be used.

My concerns:

a) There is no REQUIRED for what version of TLS the registrar
   must support towards the pledge. Could use TLS 1.1 and be
   in compliance with RFC8995. And fail.
b) "newer" is wrong, because it also does not establish mandatory
   interoperability: There is no requirement for any RFC8446
   implementation to interoperate with an RFC5246 peer. And "newer"
   TLS version beyond 1.3 may not even support negotiation into TLS 1.2.
   Aka: could get TLS 1.2 vs TLS 1.3 (without TLS 1.2 implementation)
   between BRSKI peers.
c) Editorial: Mentioning of MASA leg is out of scope as that is
   section 5.4.

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.
   
I think 1. and 2. establish the clear intent of the WG for TLS 1.2
as the mandatory to implement to ensure interop. And TLS 1.3 being
optional. This is also what RFC8994 says.

See into for arguing that we did intend to have SNI supported

I have not figured out for RFC8446 whether we also need additional SNI
requirements text or if sending SNI is mandatory in RFC8446.

Given how we currently have the requirements split up into 5.1 and 5.4, the
actual errata text would need to be split up into those two sections,
but maybe we really also simply should start an rfc8995bis so that
we have more freedom to simplify our text structure as well.

Cheers
    Toerless

---

From: Michael Richardson <[email-masked]>
Date: Thu, 05 Aug 2021 17:57:25 -0400

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

When I say "multi-tenant", I mean any cloud provider that has, for instance,
"hardware" TLS offload.

    > get "validated" status from Rob (hi Rob!).

It's not a significant amount of work.

    > 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.
(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   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 6 Aug 2021 02:31:34 +0200

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

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.

> It's not a significant amount of work.

No, but a significant amount of understnding the rules first. Because they
are insufficiently (IMHO) written.

> connections.    Pledges ought to not send it, since they don't really know

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

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Sat, 07 Aug 2021 19:15:47 -0400

> DNS names ? Isn't that at least commonly expected for BRSKI cloud ?

BRSKI-cloud pledges are code to connect to their cloud register by some
method.  A DNS name + DNS-lookup + RFC6125 DNS-ID validation (with SNI)
against WebPKI, sounds reasonable.
But, it could also be via TLS-PSK authentication to a hard coded IP address.
(That would be stupid, and maybe even seriously insecure, but you could do it)

But, the BRSKI-cloud connection is not the prospective TLS connection that
section 5.1 defines.

    > Aka: I'd opt for not having to require an additional MUST IGNORE SNI..

What does a Registrar called "frank.example" do when it receives a BRSL-EST TLS
connection for "jones.example"?   Fail it?   That's silly.

For all we know, the pledge did a mDNS discovery to find a join proxy and
that's why it's using the wrong name.