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

Achim Kraus <achimkraus@gmx.net> Wed, 30 September 2020 05:21 UTC

Return-Path: <achimkraus@gmx.net>
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 273563A1240 for <tls@ietfa.amsl.com>; Tue, 29 Sep 2020 22:21:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.313
X-Spam-Level:
X-Spam-Status: No, score=-1.313 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, GB_AFFORDABLE=1, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 kx1azU5MkjxN for <tls@ietfa.amsl.com>; Tue, 29 Sep 2020 22:21:53 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 4726F3A123E for <tls@ietf.org>; Tue, 29 Sep 2020 22:21:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1601443307; bh=jFjdpuQbUyVt+jpZONesNer6rwkj/fvL8d6lzNjWisY=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=KP4bp2HfG7yttEtuuR1Ow7te6qksQk+UfI8Ad0s5rRXtdBYg2b9Ohq73rh/4x3NB5 vJLTS8RuxAbNN3/KwaxyVtZ6AitUYXVjJXXMe+iRf8ut/RiBTCwbuxYqzfhqLORbdN LKR2N5sl6Ar1fV98C2J0Dev7eXOw75dF5hNonOzQ=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.100] ([88.65.148.189]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MxUnp-1kdMUE2dHl-00xuQq for <tls@ietf.org>; Wed, 30 Sep 2020 07:21:47 +0200
To: tls@ietf.org
References: <CACsn0c=5gsp0ivVmB-prBMXg=Ot9mo8YVzFgt-bW3G6osveggg@mail.gmail.com> <8EE5C9C0-8C51-4148-916D-54017101B2B5@ll.mit.edu>
From: Achim Kraus <achimkraus@gmx.net>
Message-ID: <0a38bf36-55e5-efbe-b5bb-66e0d5e85f4b@gmx.net>
Date: Wed, 30 Sep 2020 07:21:45 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <8EE5C9C0-8C51-4148-916D-54017101B2B5@ll.mit.edu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:rWqH7nldSK6Xd2tdufw5jkqN3PHAMdV+pDp6JCWeYUhtY6bX7Eg nPAMyFZ1mOt2v6k6sStzKa7GZ3wKO6Xee6A1KK5c/4h00wLEzzGs/qBXmj3rcTO9yj8PwXi gz3Y5YQ+Z7jM8COWDQX4xOtlztBk6tIWaylMf0dg1vyydI7yDxZRr47nVfNPExRiuCFm19Z jeH9L0gcscu+hxF9zcCag==
X-UI-Out-Filterresults: notjunk:1;V03:K0:jhf0OiOgBdw=:3nI8LXljv4Pz0JF9MWQ93S aDJRA8JzXSFVcKbEjKRM+fP+HoONluU9cwHhDDJP/EJzyo0n9LKinhyANHeweY4jM65rToqCN RDOOFURVcKX+RhxYseqr1hBFs9k4MKfVgOh0in3AApw3qzLMPa/KAjuQlB1dV7JOfUGI1mrcF qiKXRIJqHpeYKXRZzjp0vsYNHKAdYRatskH5RmSXLk3Vi+S4LAaJuuDz3dexIlRtov6Z0wHU/ MmuHCG0yK1atXXjR1+jHFiJpOTy/bizrdks1lINR9ho/Eoz1Y1rXcu7J4D2OrMpQCuRoJJYyJ fbnT9TYqEnd+whTlahLSwk3fvtM3RHmNrsoCoYSRqfTlPAsOfXvVTcYBZCnpdZQ0DrD1xrBwT EGChiDxZR1OzUmyPjjVJqr9akiSnFLxlk+l07Sa94ja9J4P1iAivQSDQcXg3yLJEfyXqkxdpy oTV8GbZ3gHy9I8x5qft5cZFhTqp7amWJnZ8TJRdnFxXfVCUD9+oj96xBMBkTpe6c6+Jjwm59e naWVahF24p+Xp7lJJpVrelEjY4/8dxAudl0AmjNHzlo4VN1RgWSLKNDLxxU87/E1IxKAB512k h32j5GzNsIufwIO+sgAf77kdIiUmFgHV0P/kGbukjBE+rZCdOkxSTD1uSSALr0H3AizsylY3k r2+bmvzDlZH2SEz1X9LndG69l1TiH2jsfb1fdiYDeub7BL0PQZDUXNusSMlu2A8oz5TRYyV+x +kLHhVdSsZVKkjEdMbP3REaWXm2RV33PsMprwpZvehqjHefx6yxqEb7oh3FnPwEN7pKOx9UZ5 cjYjf/3rzx7fFBKWxvW+3/+c2q3q6SfpAvx5pX6XdCp1nZpVr+z4+6wlqIvaWi/qdhNuXNxdg g6SJWHMAtqc0prS/lZemMrEp1EJQxJtU/PDjNfLS2+Y5I2U8Ra4cExaUNNB50McGtPIlw9uUR Auu31H8SYKcSVSeJRQDnGaR/5Ou+wB9wYCJ+IP48PeW4v3jBS9M0zaTQqf3yKPybpsw2mZXQ8 em2CCqHYYdQWWODiqdYaYPxX5enCP1lbaaDCicUXa2UCYBl0quXO9rX+YyX7oWpWsRiwpHhb6 6D4eWNMKKukvtPecaGKza/HCHokmHfb6LUPBWWcBUdECbyP8knFVT8gyGme4dEL5NL+tCTx4U MUWiMJNA6g14HWwEaNM65619UwmIu5q9Mq7+nGpAT809hxH2jGCvxA4qWdf/brdfEO+CjmsTR ZTPeArLtBnoQOxCCliVpwBYJpSH2EKR1iGNh8mQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/lWVxXW4k4SEDvrk91WF_CEkUjZA>
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 05:22:02 -0000

Hi list,

exchanging arguments for N or Y again seems for me to be in vain.

Therefore my proposal to add the Y-period. For me that documents more
the fact, that the security trade off between security and resources is
changing over time. And so will the implementations and deployments.

best regards
Achim Kraus

Am 30.09.20 um 02:48 schrieb Blumenthal, Uri - 0553 - MITLL:
> Because PSK is one of the affordable and reliable quantum-resistant key exchanges that work *today*? And done environments do not wish to do any EC operations.
>
> Yes, key management issues are real. Those who need it, understand the implications.
>
> Regards,
> Uri
>
>> On Sep 29, 2020, at 20:30, Watson Ladd <watsonbladd@gmail.com> wrote:
>>
>> ´╗┐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