Re: [Uta] [Last-Call] Artart last call review of draft-ietf-uta-rfc7525bis-09

Benjamin Kaduk <kaduk@mit.edu> Fri, 15 July 2022 17:47 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE31C15949B; Fri, 15 Jul 2022 10:47:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mit.edu
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id useVE4G5C2qj; Fri, 15 Jul 2022 10:47:47 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1CC3C157B4A; Fri, 15 Jul 2022 10:47:45 -0700 (PDT)
Received: from kduck.mit.edu (c-73-169-244-254.hsd1.wa.comcast.net [73.169.244.254]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 26FHlZjt012426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 15 Jul 2022 13:47:42 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1657907263; bh=1ynMCgzzdePObmTohAQAJQYjgnzhcEOhJj+r1m9N4rk=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=hLE0U2EIzRNRWYd4gUbSFvYyaVnVZ18e08Pd/uvDotrIpYVD5wOJpYUXWI0yD1898 M0Cz+5BpZp68mn47R3sVHLhKckj739Qs2ddJdIU9b32CgFVurBJkWVbezG48uHiIXb 1n12Rzbq4aPwsOg+hkaxDByZlMBILy53gm5BewW7tG2SAKjhyePhC9pZavuWdzPJQi kDxsvBOc9cOrmbUP+Hvk8nL5v/XEc/wpt/J/oAWRLKaRUkc2gU6VMntpT5OWhF3FKB jF/vo4FoooHZH9iPdVf9DJkxE6rXU0PGQmJ383/EcZt9327X7bx0STQ/AmD+7A6WR9 dymRW0DcRMmDQ==
Date: Fri, 15 Jul 2022 10:47:34 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Rob Sayre <sayrer@gmail.com>
Cc: Cullen Jennings <fluffy@iii.ca>, ART Area <art@ietf.org>, draft-ietf-uta-rfc7525bis.all@ietf.org, last-call@ietf.org, uta@ietf.org
Message-ID: <20220715174734.GU26442@kduck.mit.edu>
References: <165728991008.45773.10659091812976572509@ietfa.amsl.com> <CAChr6SzVctA76H5wjjYEbAvSJkb6oag6r=vBs9sXimEZ4EGW8g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAChr6SzVctA76H5wjjYEbAvSJkb6oag6r=vBs9sXimEZ4EGW8g@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/9Tfh7m8svhXHNO1_J2NtBYViR3k>
Subject: Re: [Uta] [Last-Call] Artart last call review of draft-ietf-uta-rfc7525bis-09
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Jul 2022 17:47:52 -0000

On Fri, Jul 15, 2022 at 10:30:55AM -0700, Rob Sayre wrote:
> On Fri, Jul 8, 2022 at 7:19 AM Cullen Jennings via Datatracker <
> noreply@ietf.org> wrote:
> 
> 
> >  I see no evidence of any
> > discussion of how that will work out for things that use HTTP but are not
> > browsers.
> >
> 
> There just aren't that many implementations on the client side. Not only do
> you have to implement all of the HTTP versions and TLS, but you have to
> maintain all of the PKI stuff as well. Obviously, people do it, but they
> are not the ones that need to read this document.
> 
> If the TLS library is not one also used by the OS and a browser (NSS,
> SecureTransport, etc), it's probably OpenSSL. I don't think this is an
> oversight in the document.

I think we need to be really careful with what we're considering as the
relevant population of clients when making statements like this, and what
metric is used to count/weight them.  OpenSSL, for example, is terrible for
embedded/IoT systems -- it's just not designed to produce a small code
size.  Mbed TLS (Apache licensed, just like current OpenSSL) is much more
appropriate in those environments, which also happen to be ones where the
scale/volume of number of devices can become quite relevant quite quickly.
So what do you actually think we are/should be measuring?

-Ben