IETF Logo Mail Archive

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

Filippo Valsorda <filippo@ml.filippo.io> Thu, 24 September 2020 14:12 UTC

Return-Path: <filippo@ml.filippo.io>
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 A0FA83A0A3B for <tls@ietfa.amsl.com>; Thu, 24 Sep 2020 07:12:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.019
X-Spam-Level:
X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=filippo.io header.b=rq0DZkj/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kRuR9hzl
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 xBneYu8xqw6M for <tls@ietfa.amsl.com>; Thu, 24 Sep 2020 07:12:06 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FB9B3A09DA for <tls@ietf.org>; Thu, 24 Sep 2020 07:12:06 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 6AC945C0059; Thu, 24 Sep 2020 10:12:05 -0400 (EDT)
Received: from imap1 ([10.202.2.51]) by compute3.internal (MEProxy); Thu, 24 Sep 2020 10:12:05 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=filippo.io; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm1; bh=SpV/OTvE/f1FN2ImPTsgI57L054d7pv sNw5krd3PUyY=; b=rq0DZkj/31SxkhF19/vCF2JXBEk99EQbcDJzLfhIUPI9Jhm sP/pxdNJT5cDJk781GP5AWRUl89Ka2PqnrVSf46D5GBtNv0qcH+qkO2wYOhH+7Xd kUb+6X5e60m6yhFQefHEITRtN6nOEnrbbBBoprdfpKlHbSV6CQc/VblO5vvXVMvY fHIITv7Rx3mGl2o93uKh+Ud9vpJjatp/CkxM0rtQKwsm+4DuipGdjtVVKqQ0rR8c /wehhmDbl4JCYT/ZY6kYW9HxSu6W8FOvyJAYvjK/ek0wGNOQ+Wf1t27dYVpAroMH HhVbLo73DgQvLQP57Np5+2h/5UdTQJGj8RxFBww==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=SpV/OT vE/f1FN2ImPTsgI57L054d7pvsNw5krd3PUyY=; b=kRuR9hzlGshI5ZIR7rcunM uyGfpYQJ8ZWV5gLIOwpubbsBSsK2s/x/Ds2S6y2hLQK+L00P7PWKoqiBKWPwYXwC VR9QMRV/67lvY25hGsefA4T3IOo7d+gNaZQ1pUJlE0uliAt38TFc1AX8z4QY3/TP l21Y5tFlTnNyxUVwmLtLfH5xJsmHD8ZCU+jXwri/XKfwxsyl8xf+HNzWSCvdlj43 FYy10fSGFwOpwGSqS2lwP+XwaRMWuMhl5ZmpmPXBkxnRKiNu2Irf5tEdpL9aT21K lNqOGwsJKQe6U2JlGcQPIxc18VP/CPucEyKJUilt+kGYvhJ7rBXsxiHXa216fJHg ==
X-ME-Sender: <xms:NKlsX1npI42STOBTCz3PNNZFIJKiNGTaxdEFL07hkLytEDTME2S41w> <xme:NKlsXw1t8u_YEmkX_RcE6vMACobB-GobFOAoE3tVJU12rmyPyvg_BDhr5EsbhP16N hG1v2cuRv0ndwgb8g>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudekgdejhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfhfhilhhi phhpohcugggrlhhsohhruggrfdcuoehfihhlihhpphhosehmlhdrfhhilhhiphhpohdrih hoqeenucggtffrrghtthgvrhhnpeegtdevleeftdejkeeflefgieegudeiudellefgvefg keeikeeitdelffekkeeutdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpehfihhlihhpphhosehmlhdrfhhilhhiphhpohdrihho
X-ME-Proxy: <xmx:NKlsX7p0jr3c1z2BryGdCmaouW_cTNccLF2PsqOXjzOLfZMHs8Sn2g> <xmx:NKlsX1k74t7FzjB5vMQIYho48l32sPFxLjwWCs3eCRRlSFo9RJw-cA> <xmx:NKlsXz3_9EfcBiQCAEu0vm_d6MXVzzeZqKBWM1hnQtjNHwR-i2-qXQ> <xmx:NalsX8_4OTRLWoDHdCULJGLjZmippqmmesmV2Xja-IT2MOwvQAl7RQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 26E91C200A5; Thu, 24 Sep 2020 10:12:04 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-355-g3ece53b-fm-20200922.004-g3ece53b9
Mime-Version: 1.0
Message-Id: <7fd5793b-ca6c-40de-a5e4-b1d5204dc27b@www.fastmail.com>
In-Reply-To: <1600941749816.32242@cs.auckland.ac.nz>
References: <77039F11-188E-4408-8B39-57B908DDCB80@ericsson.com> <1600516093048.75181@cs.auckland.ac.nz> <2f2ecb30-bef5-414a-8ff7-d707d773c7ea@www.fastmail.com> <FDD012C2-9B37-461D-BC81-854135EE994E@icloud.com> <AM0PR08MB3716861B782527DAB3C1EA1BFA3A0@AM0PR08MB3716.eurprd08.prod.outlook.com> <DF3B268F-2E80-4444-B643-D33BC0C7151E@icloud.com> <AM0PR08MB371678103D9EEB89C9AA44C1FA380@AM0PR08MB3716.eurprd08.prod.outlook.com> <ff5f77a9-ea45-4a72-b075-65c2d5e8ab45@www.fastmail.com> <1600941749816.32242@cs.auckland.ac.nz>
Date: Thu, 24 Sep 2020 16:11:09 +0200
From: Filippo Valsorda <filippo@ml.filippo.io>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, Hannes Tschofenig <Hannes.Tschofenig@arm.com>, Carrick Bartle <cbartle891@icloud.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="f60367f178d0489dac345db03eba3325"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/k_GxH5rvXcnlX6iio3Lws-69avc>
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: Thu, 24 Sep 2020 14:12:08 -0000

2020-09-24 12:02 GMT+02:00 Peter Gutmann <pgut001@cs.auckland.ac.nz>:
> Taking "SCADA/IoT/etc" to be a placeholder for M2M or more
> generally "non-web use", [...]

"The web" and "resource-constrained use cases which can't afford ECDH" feels like a false dichotomy, and it sounds unlikely that most M2M cases would fit the latter description.

Anyway, David has made a better case than I did for marking psk_ke as N, like TLS_PSK_WITH_AES_128_GCM_SHA256 already is, so I don't want to distract from that thread.

v2.27.8 | Report a Bug | By Email | System Status