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

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Wed, 30 September 2020 13:09 UTC

Return-Path: <prvs=7542662279=uri@ll.mit.edu>
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 DBF8C3A08C5 for <tls@ietfa.amsl.com>; Wed, 30 Sep 2020 06:09:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 j0CEsqAYQMEE for <tls@ietfa.amsl.com>; Wed, 30 Sep 2020 06:09:56 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) (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 0D48A3A08C1 for <tls@ietf.org>; Wed, 30 Sep 2020 06:09:55 -0700 (PDT)
Received: from LLE2K16-MBX04.mitll.ad.local (LLE2K16-MBX04.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTPS id 08UD9mCe040446; Wed, 30 Sep 2020 09:09:48 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=Pz9aS5RU6scHO0Xk5UMMmkz+AQdYqM+QLClIFEt1SCeLzi/VMFN1kGCo2tldk3vHmzDNe8fGMOtcwUu27QDMbgr5FvXJ5Vo1hIUOzdZPl/q3ngrqBrxo90zpA9/u1sm55a7Ij7/ZTs7VmwPy6rLgxAzt9bUv7nfina61Nn0EkDJuk7wc/TZH921kaA5/EzqHtfp6fQQ44f8Lr8g9C4MptVICDpd9Gj/h7A4fjrqstNOVS1bHe8fzrNyDp6EQCxOt6L6ft6QqpgaHcmv0QEdc3NBK+6Fkx7HpKs+djdw9yV9UoEOzfvZy6S/wmZecLMq+YKzQIbzxuauVXmq0vXLXAg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CMA2ktzpIXkB8RhVtPEu9FeMkqxB13iUnu7cYWDz76A=; b=iyOR+mnvrEx6N5em1YgSQx8FDL7kpJbtInjK1zgCBW0TR7hFmgORLKz3C6YJxLI37UR6Hi5GyD4oc+Um3AT9U3NWpYj3a98GsJBkcmzfoMfkcKgVLMkhEMJyY/UkyZ53maBmTDX5p4afGyDRjipKg877BGco4ouXkSn7lrwLya+91V/Dypql9B/B4WCXwgP0StfbHUfGTUbhO3kByPTofE2QxLa6qQrk6gGifVmowVBNNCrp37lLNHW2QRRrjbMt7jHc/G+ieyi7gnK08/FoRfyW9S1kxJzANVhAU9tGk1HHnmxdr1VlIw8rcZ8FuIQMqIUovFJCUPqQfDlt0ULjCw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ll.mit.edu; dmarc=pass action=none header.from=ll.mit.edu; dkim=pass header.d=ll.mit.edu; arc=none
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Watson Ladd <watsonbladd@gmail.com>
CC: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] The future of external PSK in TLS 1.3
Thread-Index: AQHWln4J7ZaqYmyU4UKtYjPn2cuI8Kl/kNWAgADDroCAAHYagIAAWPaAgAAFXAA=
Date: Wed, 30 Sep 2020 13:09:43 +0000
Message-ID: <4EAEBBD9-CB4D-4036-8305-06B269154552@ll.mit.edu>
References: <CACsn0ckAsga5en3OJDWA5DD+QxZgpp8a7=F+sCeF4ORPA2P+sg@mail.gmail.com>
In-Reply-To: <CACsn0ckAsga5en3OJDWA5DD+QxZgpp8a7=F+sCeF4ORPA2P+sg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=ll.mit.edu;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0655908d-3274-4b89-fa88-08d86542194a
x-ms-traffictypediagnostic: BN3P110MB0372:
x-microsoft-antispam-prvs: <BN3P110MB03729D84E65716D57F5E8F8E90330@BN3P110MB0372.NAMP110.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:2733;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN3P110MB0241.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(26005)(64756008)(71200400001)(66446008)(66556008)(66476007)(66616009)(8936002)(2616005)(956004)(186003)(4326008)(2906002)(76116006)(5660300002)(966005)(66946007)(75432002)(498600001)(86362001)(33656002)(53546011)(6506007)(99936003)(8676002)(83380400001)(6486002)(6916009)(54906003)(6512007); DIR:OUT; SFP:1102;
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; boundary="Apple-Mail-3E19064C-5F07-48E2-B2CF-19C19D71D396"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN3P110MB0241.NAMP110.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 0655908d-3274-4b89-fa88-08d86542194a
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2020 13:09:43.7921 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 83d1efe3-698e-4819-911b-0a8fbe79d01c
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3P110MB0372
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-30_07:2020-09-30, 2020-09-30 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2006250000 definitions=main-2009300104
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ZF795LhkVJ7VGUnqT0r-YewncFw>
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 13:09:58 -0000

> On Sep 30, 2020, at 08:51, Watson Ladd <watsonbladd@gmail.com> wrote:
> 
> Recommended N doesn't stop people from using PSK when appropriate if
> other constraints make it the most appropriate choice.

It does, because this "stop" occurs on a business level, not the technical... Realm of advertisement, claimed security and compliance, etc. Where a business manager is afraid to scare potential customers away by implementing/selling something "not recommended", because even if he himself managed to read the doc to the end and understand what that's about, he cannot trust all the customers to do so... Plus the potential legal cases when a customer who was cyber-hit, sues the manufacturer because he "did something against recommendations"... That's not your favorite Ivory tower, and not a peer-reviewed academic publication/conference. 

Now, since it's a rough morning and I feel grumpy - let me be blunt, and say that IMHO this whole "recommend" idea sounds *stupid*. Recommended by who and for who? WT... do the "recommenders" know about the spectrum of use cases? Based on the above exchange - not a lot. If you want to "recommend" for the Web browsers (which seems a fairly safe niche to pontificate) - say so explicitly, and enjoy. Otherwise - ....


> 
>> 
>> 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