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

Peter Saint-Andre <stpeter@stpeter.im> Fri, 15 July 2022 19:29 UTC

Return-Path: <stpeter@stpeter.im>
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 8F92DC13C50C; Fri, 15 Jul 2022 12:29:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 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, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=FPDbgGn0; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TSxdDlSE
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 7_2fSGTM7imq; Fri, 15 Jul 2022 12:29:40 -0700 (PDT)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59F88C13C50B; Fri, 15 Jul 2022 12:29:35 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 918693200D5F; Fri, 15 Jul 2022 15:29:31 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Fri, 15 Jul 2022 15:29:32 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1657913371; x= 1657999771; bh=08Ux2TnykDeylqdd3HbWS1ls6mrMvDT29qgq4tcZGQI=; b=F PDbgGn0y3EWluwpgUi30HpEWJtwPDsk3VgUi4VPVtrdNnGNBl6wXpMvK2I3C4ZNk uqUU0eISFIuWALmCb8EoMWTKc7hPB2+qpyG1hQqKrxBHy+Lvj8nUpUo1452/Teq9 xhHPXpYA879KrgGRHxqu5I9KW6ceczU4ykKmC6GDMar9BASMFhSWLgxkl3+ASCPq PTPcdmyzGLomaQ3cpsd57FdFKnx4PZkTNAtir2CVEiWBxPaABFKn7YU9LnVDg0UQ Tk0kHi2DadNimWzyV0DECegO/37PQ8cw2pkTsjhs5k5qSJc8pSjfXEjBWKxNay6Z paJ4KCugDGOEWf++EGDpA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1657913371; x= 1657999771; bh=08Ux2TnykDeylqdd3HbWS1ls6mrMvDT29qgq4tcZGQI=; b=T SxdDlSEr4nLIA1yCC+k/hUM9kFsmi+47EplqamMPQk4voH4eORoaduDYeqVg3z10 WtZBeubGukZNe3EUAQ9yGtPKCVYoI+YpcgZe6L0Czv9RxOoZxZ/kXlU9R3lEZNQf LkzQw+NF+62rXH5HOEECqEUtf9TLlEYK9LfJjKQYuifqTg5JMJH0eBgkaRVXN1Zk OaXiECTD13feCseLZvStQ4aZAEVxRarBJPGvKStsI8Q/5ec0cOn1HdP+sckX16Gx wDMPqWHfwJovvHMW3AiXbgeGSjZbZvDLj200ZZqoPH47d0KunM9vuPDWClzxiq1I +7IzMy/OfEqx1aR9jE8gw==
X-ME-Sender: <xms:GsDRYgM6FUwZwsEcWCsZu7Q0WANsDW8NXOxeuGFImeGfvjzbyCb1YQ> <xme:GsDRYm-B4tN3mC0ZWT1Ax-2MRFhtAtHIsH7ivvdQoXKcDcftIfV-kRc2K_95O56ip zM4tZufPARKGd2sbQ>
X-ME-Received: <xmr:GsDRYnQub0PkYaWX5US9cCfoLXOADEHmrDWare3yFE8I0NNZzjzpK1EQwn3FFYMm>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudekuddgudegtdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthekredttdefjeenucfhrhhomheprfgv thgvrhcuufgrihhnthdqtehnughrvgcuoehsthhpvghtvghrsehsthhpvghtvghrrdhimh eqnecuggftrfgrthhtvghrnhepieduffevjeehveeflefhtdfgvdefheffheevledvhfdu ieelteevvddthfffieejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepshhtphgvthgvrhesshhtphgvthgvrhdrihhm
X-ME-Proxy: <xmx:GsDRYotr5kmbXM2mFQ-0Fyiboe79D804brDWA5U5iLMa2PIsXsJVaQ> <xmx:GsDRYodwImbafw7HaS8JNpyl-9TD433IdriDB9zRvn4gdbvY_ZZDAQ> <xmx:GsDRYs3PHb0VUIpWTQS-TDey32vHZODv2ExHYiS7Zp8VHO8TDdbkyg> <xmx:G8DRYgQmoZBkXKsaMS9j6GsKWde7OWJp9nulh9uuNf5rt0s3TspT0w>
Feedback-ID: i24394279:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 15 Jul 2022 15:29:29 -0400 (EDT)
Message-ID: <a0372b9d-d59f-81d7-52b8-5ae9362489ed@stpeter.im>
Date: Fri, 15 Jul 2022 13:29:29 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
Content-Language: en-US
To: Rob Sayre <sayrer@gmail.com>, Benjamin Kaduk <kaduk@mit.edu>
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
References: <165728991008.45773.10659091812976572509@ietfa.amsl.com> <CAChr6SzVctA76H5wjjYEbAvSJkb6oag6r=vBs9sXimEZ4EGW8g@mail.gmail.com> <20220715174734.GU26442@kduck.mit.edu> <CAChr6SyvY1O1pXep9XNFxGkgfhz7abF64opDb35HNFEjgHMkzw@mail.gmail.com>
From: Peter Saint-Andre <stpeter@stpeter.im>
In-Reply-To: <CAChr6SyvY1O1pXep9XNFxGkgfhz7abF64opDb35HNFEjgHMkzw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/WpWZIjiiOg-tW9-Evnz_P3FCQJM>
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 19:29:45 -0000

On 7/15/22 11:54 AM, Rob Sayre wrote:
> 
> 
> On Fri, Jul 15, 2022 at 10:47 AM Benjamin Kaduk <kaduk@mit.edu 
> <mailto:kaduk@mit.edu>> wrote:
> 
>     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 <mailto: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, 
> 
> 
> Sorry, I tried to leave a caveat in there for exactly this concern, but 
> that seems to have failed.
> 
>     Mbed TLS (Apache licensed, just like current OpenSSL) is much more
>     appropriate in those environments,
> 
> 
> I don't think people that write programs like that will get a lot out of 
> this document. I think they're not the audience (they will drop TLS 1.2 
> or support TLS 1.1 if they want/need to).

And, surprisingly enough, that's already mentioned in the applicability 
statement section of this document:

    This document does not discuss the use of TLS in constrained-node
    networks [RFC7228].  For recommendations regarding the profiling of
    TLS and DTLS for small devices with severe constraints on power,
    memory, and processing resources, the reader is referred to [RFC7925]
    and [I-D.ietf-uta-tls13-iot-profile].

Peter