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

Toerless Eckert <tte@cs.fau.de> Fri, 06 August 2021 00:31 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F823A136A for <anima@ietfa.amsl.com>; Thu, 5 Aug 2021 17:31:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjQgixaBDJHx for <anima@ietfa.amsl.com>; Thu, 5 Aug 2021 17:31:41 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32A343A1371 for <anima@ietf.org>; Thu, 5 Aug 2021 17:31:41 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 9F21354804C; Fri, 6 Aug 2021 02:31:34 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 9695A4E7C55; Fri, 6 Aug 2021 02:31:34 +0200 (CEST)
Date: Fri, 06 Aug 2021 02:31:34 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Robert Wilton <rwilton@cisco.com>, "anima@ietf.org" <anima@ietf.org>
Message-ID: <20210806003134.GA47840@faui48e.informatik.uni-erlangen.de>
References: <20210805211714.GC57091@faui48e.informatik.uni-erlangen.de> <9465.1628200645@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <9465.1628200645@localhost>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/OlLdQyct3jRHjTrhzKx4anQaIJY>
Subject: Re: [Anima] MichaelR/Rob/*: RFC8995 errata concerns
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Aug 2021 00:31:46 -0000

On Thu, Aug 05, 2021 at 05:57:25PM -0400, Michael Richardson wrote:
> Toerless Eckert <tte@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   [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
> 
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 



-- 
---
tte@cs.fau.de