Re: [TLS] The future of external PSK in TLS 1.3

Watson Ladd <watsonbladd@gmail.com> Wed, 30 September 2020 12:50 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F013A0B3B for <tls@ietfa.amsl.com>; Wed, 30 Sep 2020 05:50:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Uvx2G4D4tx0Q for <tls@ietfa.amsl.com>; Wed, 30 Sep 2020 05:50:46 -0700 (PDT)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 965C63A041B for <tls@ietf.org>; Wed, 30 Sep 2020 05:50:45 -0700 (PDT)
Received: by mail-lf1-x131.google.com with SMTP id y17so1985241lfa.8 for <tls@ietf.org>; Wed, 30 Sep 2020 05:50:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=gDGX2ASOQheC441Btse8TIJmU6Z8BZswKfUfSvPQrw8=; b=Bo5n2DeE/K9XX1h9bqFqGscwpL38jGoub3vuaX9212XOnAqN9Lod7gFHE5Avujgm/2 fZklW6eQANcvnC0pHYnW7EJnWi4yYRbF9m/edUpKPac9nfT9Aej49nkfsoaVRdgoNVIx TSxeU8DSXaSzUjj8iyuXMBGDJrr19yhCggivsJi1wKG8l49rNUHR2iR9KklFAjtyCFuS vw3OAQ2zsJJsgyA0My3E5Vc2dA+mF593iHx/AC1btOePHSO5Anj/LrQF520bavUo7xFu 4FQZ3c/wkNrutBffArgXwSaqUmBoZhQGfutL/Zw6s3iB3eUU+yLoHTm6NJ1cRICKgLeI GyBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=gDGX2ASOQheC441Btse8TIJmU6Z8BZswKfUfSvPQrw8=; b=pSVtG94bmArY4BDjrfoDoYvW/iP1wJ1GrMACm/2e67XpYCx2mUwpHO9Xpw8jHPsCm+ aJRR3/OoMMi7/nV2xEXzMBWPE+QsaCue5+Qq62VzPSEdbEM+FZelnzLr4dKKOswW29MI zVPWZp3VfMj4jRYG8Ibk0MdTAQlK2BsXocPh6JEKYMxRSpqDFwkVN9O4MPO98yW8jTRm kVoKVs3K+va3MGtHxrR5KDyowxNgVcVmJWF82FDLq2nSWDHLPXUNKULZ88j/h75kgOlX Nz2ps6rrbhWsMVg5C3YpJwtsmdoYTMyj4+5x5h420aKl2sjJiJ1bkAjTn5xamSlsNgNV EqsA==
X-Gm-Message-State: AOAM532L62QYy3szKTYy+PiJEp1bu2kTkm5KqqdHk/BLfndzwgfUrz2g L5e7of8D9k1z/NftwAW7RQcsH+9qeX0Z1Hyjris=
X-Google-Smtp-Source: ABdhPJygAtmqFlx/wpQEFvonJk5hy0wHtwS6Jr+mq6QvCyCBEXfKnN/4+oLSOzLy0ps1LUeR8kHk9TNv/FvKC7azybY=
X-Received: by 2002:a19:1c8:: with SMTP id 191mr770303lfb.585.1601470243502; Wed, 30 Sep 2020 05:50:43 -0700 (PDT)
MIME-Version: 1.0
References: <a4d46445-945d-d5fb-7d64-8688bf5abcab@gmx.net> <436AC97A-6929-4818-B288-A8053D073579@ll.mit.edu> <CACsn0c=5gsp0ivVmB-prBMXg=Ot9mo8YVzFgt-bW3G6osveggg@mail.gmail.com> <AM0PR08MB37165FF80D05A52A9D754E90FA330@AM0PR08MB3716.eurprd08.prod.outlook.com>
In-Reply-To: <AM0PR08MB37165FF80D05A52A9D754E90FA330@AM0PR08MB3716.eurprd08.prod.outlook.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Wed, 30 Sep 2020 08:50:31 -0400
Message-ID: <CACsn0ckAsga5en3OJDWA5DD+QxZgpp8a7=F+sCeF4ORPA2P+sg@mail.gmail.com>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>, "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/1FTpp1178AYGbTnrKxdoRJdu-m4>
Subject: Re: [TLS] The future of external PSK in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2020 12:50:47 -0000

On Wed, Sep 30, 2020 at 3:32 AM Hannes Tschofenig
<Hannes.Tschofenig@arm.com> wrote:
>
> Hi Watson,
>
> through Arm I deal with customers who use microcontrollers that have all sorts of limitations. So, the question is not so much whether these limitations exist but rather whether you care and what exactly these limitations are (CPU processing, RAM, flash memory, energy, networking bandwidth, cost, physical size limitations, limitations caused by the environment these devices operate in, etc.).
>
> PSK is the most efficient mechanism we have. Not only does it perform extremely well when it comes to CPU performance it also reduces the size of code size, and RAM utilization. Also the bandwidth requirements are minimal.
> Of course, regular 32-bit microcontrollers are all able to do public key crypto operations (see a presentation I did a while ago in the LWIG group -- https://www.ietf.org/proceedings/92/slides/slides-92-lwig-3.pdf). There are, however, some environments where you just cannot wait multiple seconds for a handshake to complete.

This presentation doesn't mention many well known optimization
opportunities, and seems to show an M3+ device having ~100ms for an
operation. Obviously this is more expensive than the M0, but in some
cases it's worth paying. Then of course one can optimize the handshake
through extensions. RSA verification (not signing) is very cheap.

Recommended N doesn't stop people from using PSK when appropriate if
other constraints make it the most appropriate choice.

>
> In discussions in the IETF I notice for some the IoT computing world starts with Cortex A-class devices, as they are found in Raspberry Pis, tablets and phones. Those are high performance processors where crypto is lightning fast. But don't forget the other family of processors, of which there are probably more than a 80 billion out in the wild already.
>
> Ciao
> Hannes
>
> -----Original Message-----
> From: TLS <tls-bounces@ietf.org> On Behalf Of Watson Ladd
> Sent: Wednesday, September 30, 2020 2:29 AM
> To: Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu>
> Cc: tls@ietf.org
> Subject: Re: [TLS] The future of external PSK in TLS 1.3
>
> On Tue, Sep 29, 2020 at 12:49 PM Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu> wrote:
> >
> > I share Achim's concerns.
> >
> > But I believe the explanations will turn out mostly useless in the real world, as the "lawyers" of the industry are guaranteed to steer away from something "not recommended".
> >
> > In one word: bad.
>
> Why is PSK so necessary? There are very few devices that can't handle the occasional ECC operation.  The key management and forward secrecy issues with TLS-PSK are real. Steering applications that can afford the CPU away from PSK and toward hybrid modes is a good thing and why this registry exists imho.
>
>
> --
> Astra mortemque praestare gradatim
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.



-- 
Astra mortemque praestare gradatim